Skip to content

Correct four task records that said shipped work was not done - #217

Merged
VeryComplexAndLongName merged 1 commit into
mainfrom
chore/task-bookkeeping-catch-up
Sep 4, 2026
Merged

Correct four task records that said shipped work was not done#217
VeryComplexAndLongName merged 1 commit into
mainfrom
chore/task-bookkeeping-catch-up

Conversation

@VeryComplexAndLongName

Copy link
Copy Markdown
Owner

tasks.md decides whether a change may be archived, and four of them were wrong in the same direction.

Change Recorded Actually
run-with-harness-prefills-the-run 0 of 16 done Shipped entirely in #202; initialCommandKind is in AiPanel.tsx, changeset released in webui 1.25.0
usage-from-acp 5.2, 5.3 open Checks run; changeset released in core 0.50.0
event-guard-covers-every-kind 4.2, 4.3 open Checks run; changeset released as a core patch
usage-visible-while-running 5.2, 5.3 open Checks run; changeset released

One cause, not four slips

Tasks were ticked, the files copied into a worktree and committed, and only then were the checks run and npx changeset invoked — after the commit that would have recorded them. The same order produced the same omission four times, always at the last two items of a list: run the checks and add a changeset.

Verified, not recalled

Every tick was checked against main: the symbol the task names existing in the file it names, the test the task names existing by its own title, and for a changeset item the released entry in the relevant CHANGELOG.md. Fifteen of sixteen items in the prefill change verified this way; the sixteenth is human-only.

The diff was then re-read item by item against that list to confirm nothing else was ticked — 21 boxes, matching 15 + 2 + 2 + 2 exactly. Correcting a wrong record by assumption would just make it wrong in the other direction, and harder to notice.

Human-only items all stay open

Including ci-audit-own-job 3.6, where half is observed (the audit is now its own check) and half is not — that the merge gate reports independently when the audit fails needs a failure to demonstrate. Closing it on the observed half is the inference this change exists to refuse.

Stopping it recurring

openspec/README.md gains the order — run, then tick, then commit — and what the failure looks like from outside, since that is how it will be recognised: a change whose work is plainly in main, whose tasks.md reads as untouched, and which the archive step then refuses.

🤖 Generated with Claude Code

`tasks.md` decides whether a change may be archived, and four of them
were wrong in the same direction:

- `run-with-harness-prefills-the-run` recorded 0 of 16 done, having
  shipped entirely in #202.
- `usage-from-acp`, `event-guard-covers-every-kind` and
  `usage-visible-while-running` each left their "run the checks" and "add
  a changeset" items open, with the checks run and the changesets already
  released in 0.50.0.

One cause, not four slips. Tasks were ticked, the files copied into a
worktree and committed, and only then were the checks run and
`npx changeset` invoked — after the commit that would have recorded them.
The same order produced the same omission four times, always at the last
two items of a list.

Every tick here was verified against `main` rather than recalled: the
symbol the task names existing in the file it names, the test the task
names existing by its own title, and for a changeset item the released
entry in the relevant CHANGELOG. Fifteen of sixteen items in the prefill
change verified this way; the sixteenth is human-only and stays open. The
diff was then re-read item by item against that list to confirm nothing
else was ticked — 21 boxes, matching 15 + 2 + 2 + 2 exactly.

Every human-only item stays open, including `ci-audit-own-job` 3.6, where
half is observed (the audit is now its own check) and half is not (that
the merge gate reports independently *when the audit fails*, which needs
a failure to demonstrate). Closing it on the observed half is the
inference this change exists to refuse.

`openspec/README.md` gains the order that avoids this — run, then tick,
then commit — along with what the failure looks like from outside, since
that is how it will be recognised next time: a change whose work is
plainly in `main`, whose `tasks.md` reads as untouched, and which the
archive step then refuses.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@VeryComplexAndLongName
VeryComplexAndLongName merged commit da177cb into main Sep 4, 2026
8 checks passed
@VeryComplexAndLongName
VeryComplexAndLongName deleted the chore/task-bookkeeping-catch-up branch September 5, 2026 05:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant