[hkwuks]

Summary

CHANGELOG.md claimed that 1.1.9 shipped seven changes it did not.

A 2026-10-30 edit inserted the tail of ## [Unreleased] into ## [1.1.9]: seven ### Added entries describing work done after 1.1.9 was tagged, plus a second ### Compatibility heading repeating a bullet already present above it. v1.1.9:CHANGELOG.md contains none of those seven, so the file said a released version included work that did not exist when it was cut.

TaskFlow traceability

• Task: none — documentation maintenance with no task behind it (CONTRIBUTING.md, "Push permission routes the bookkeeping that belongs to no task"). Nothing here has behaviour to review, and inventing a PRD/Plan for a 17-line text correction would be a heavier record than the change.
• Scope: CHANGELOG.md only — delete the duplicated block, restore the sentence it displaced.
• Base branch: main
• Target repository: hkwuks/TaskFlow

How the damage is traced

Reading the file against 5cba1dd (the merge before the edit) shows both halves in one hunk:

1. The Unreleased ### Fixed block, headings and all, copied down into 1.1.9.
2. The original Unreleased ### Compatibility bullet — the one naming all five archived Plans — replaced in place by a pointer to the copy: (unchanged from the entry below).

The pointer is what made the duplication read as deliberate. With the copy removed, the pointer dangles, so it is turned back into the sentence it replaced, recovered verbatim from 5cba1dd.

Verification

• The Hooks workflow reports pass for this branch — linked below once it runs
• git diff --check — clean
• bash hooks/release-check . — STATUS: pass (it reads the first section's version, which this does not move)
• ## [1.1.9] is byte-identical to v1.1.9:CHANGELOG.md after the change — diff empty
• Results recorded here; no TaskFlow Plan exists for this change

Review boundaries

• No secrets or opaque remote payloads included
• No unrelated task or user files changed
• Remote/base assumptions are stated
• Known limitation: nothing in CI compares a CHANGELOG section against its tag, which is why this survived review. release-check validates only that the newest section names the current version.