story-127: A story carries its brief's key, and three moments move the item's status

[jerodw]

Story

A story carries its brief's key, and three moments move the item's status.

A brief filed in a tracker is what a human looks at to know what is happening, and its status never moved. It was filed once, planned once, and left where it was filed while a story was written from it, run, and finished with an open pull request — so a reader saw a backlog of things nobody had started, while the only record of the truth was a run directory on one machine.

Nothing linked a story back to its brief either. The brief was a plan-time input and the only trace of it afterwards was its key in the story's description, as prose. There was no field holding that key, so a run had nothing to name even if it wanted to: the run side of the harness had never heard of a brief.

What it does

The story artifact now carries the key of the brief it was planned from, and three moments report against it — planned when the artifact is written, in progress when its run starts, and complete when that run finishes.

The transport already existed: story-126 built the item-update seam, so this uses it rather than adding a second way to write to a tracker.

Evidence

• Suite: 5635 passed, 1 skipped (exit 0)
• Clean clone with the story committed: exit 0
• Verification passed, no blocking issues
• 0 retries, 0 self-routes, no correction pass, $35.20
• 18 files changed, +2458 / −165

Notes for review

It is inert on this target until configured. The installed item script names no project, so every status move it is asked to make reports a failure. That is a value this deployment supplies, the way the project number was supplied by hand when story-105 landed.

Two of the three status names also differ from this board in case — the script says In progress and Ready to merge, the board says In Progress and Ready to Merge — and option names are matched verbatim on purpose.

Configuring it is not as simple as it was for the sync command, and that is worth knowing before merging. This story ships a test asserting the installed item script is byte-identical to its template, so its values cannot be edited into the installed copy the way the sync command's were. Two commands, two different rules.

Nothing here has talked to a real board. Every call in the suite goes to the stub. The first real status move is the first real test.

A follow-on is being filed rather than fixed here. Three scripts now answer this target's tracker and they share most of what they know — the project settings, how a field's name is matched, how a field and option id are resolved. story-129 made a field name match case-insensitively and changed only the sync script, so the two now disagree about the same board. Applying that rule here by hand would have been its third writing; the brief proposes one file with three entry points instead, which needs nothing new from the harness since a configured command may carry arguments.

🤖 Generated with Claude Code

https://claude.ai/code/session_019WkxmJ5ArLEaC2RDPGkbRU