story-126: A planned story is published onto the brief it was planned from

[jerodw]

Story

A planned story is published onto the brief it was planned from.

When a brief is planned, the story artifact is written, committed and pushed — and the tracker item the developer has been watching is unchanged. It still shows the brief, the case for the work, and nothing about the plan approved from it. Anyone reading the tracker to see what was decided has to be told the story id and then go and find the repository.

The harness can now publish the planned story onto that item, and l5-plan does.

A projection, not a move

The artifact stays the source of truth and stays what a run reads, and that is not conservatism. The artifact governs the run rather than describing it: its scope decides which edits a stage may make, and its mandate records who approved what and when.

A document living in a tracker is editable by anyone at any moment, including mid-run. A mandate held there would stop being a record of what was approved, and a run that had to read it would stop working whenever the tracker was unreachable — in a harness whose every other tracker interaction is explicitly allowed to fail without stopping anything.

So the item gets a copy, stamped with the story id it was taken from, saying plainly that the artifact in the repository is what runs and that an edit made on the item reaches nothing.

One seam, one command

The publish stands where every other tracker interaction stands: a JSON document in, an exit code as the answer, and no harness knowledge of whether the target appended to a body, added a comment or wrote a file.

It is one command rather than two, taking an optional status beside the optional document, because the sibling brief that moves an item's status through a story's life needs the same seam.

Evidence

• Suite: 5580 passed, 1 skipped (exit 0)
• Clean clone with the story committed: exit 0
• Verification passed, no blocking issues
• 0 retries, 0 self-routes, 1 correction pass, $38.64
• 19 files changed, +2440 / −10

Notes for review

Nothing here has talked to a real tracker. Every call in the suite goes to the stub gh the tests install, so whether GitHub accepts what the new command sends is untested. That is the same gap story-105 had when it wired the project board, where the first real filing was the first real test and it held — but it is worth knowing that the first real publish is the check.

It does nothing until configured. Like the sync and query commands before it, the key has to be set in the target's config. Merging this publishes nothing on its own.

The second unverified note is minor: whether a failed publish's reason stays legible when the command's error output is not valid text. The decode replaces bad bytes rather than failing, but no test drives that.

🤖 Generated with Claude Code

https://claude.ai/code/session_019WkxmJ5ArLEaC2RDPGkbRU