Step order: decide before anything reads the decision, and let the answer reach something

[m2ux]

Summary

Seven places where a decision arrives after the work it was meant to steer, work happens before the decision that steers it, or a gate's answer reaches nothing. None of them fails loudly: each produces a run that completes, having asked the user a question whose answer changed nothing, or having paid for work it then discarded.

Closes the corpus half of #469. The server half is #471, which adopts this commit and adds the guard that keeps the class from returning.

What happens today

An issue is created, and then the user is asked which platform to create it on. The first work-package activity has 52 steps. The variable naming the issue platform is read at 14 of them and written at exactly one: a checkpoint eleven steps after the first read, and one step after the issue has already been created. On the create path the sequence is: verify the issue against a platform nobody has chosen, create the issue, then ask which platform it should be on. The create-issue technique makes up for it by asking for the platform in prose, so the run asks twice and the definition's own gate is the second ask.

A project is chosen for an issue that will never be created. The Jira project gate is conditioned on the platform being Jira and nothing else, and its message reads "Select the Jira project for the new issue." A run that arrived with an existing Jira issue is not creating one, so it stops, asks the user to pick a project, records the answer and never uses it.

A repository is indexed before the run discovers it cannot proceed. Commit signing is a hard precondition — the check has no gate, and its message tells the user to configure signing and re-run. It sits one step after the full repository index. Every run against a repository without signing configured pays for a complete index and is then told to start again.

A gate asks what its follow-on presents an empty answer to. Before marking a pull request ready, one gate asks whether any build-dependent artifacts need user-owned regeneration. If the user says yes, the follow-on gate presents the commands to run — interpolating a variable with two references in the whole corpus: its declaration, and that interpolation. Nothing writes it. The first gate also fires for every project, including the majority whose build produces no such artifacts, where the answer is always "none needed".

A structural inventory is persisted under a classification the next gate can overturn. In workflow-design intake, the inventory is written when the operation is an update or a review, one step before the design-intent gate whose options can reclassify the operation as a create.

A run that supplies an existing issue key binds no platform at all. The reference detector runs before the missing-issue gate, on a request that carried no key. The only other step that parses a supplied key belongs to the create path. So a user who picks "Provide existing issue" leaves all fourteen platform readers with nothing, and none of the verification steps fires. The measured walk takes exactly this path, which is why its platform-gated steps have never appeared in a snapshot.

The deferred-assumptions summary is posted before the gate that asks whether to post it. The Jira posting step sits one step ahead of that gate, and the flag it reads defaults false with its only writer setting false — so the Jira post has never run. The GitHub posting step reads no flag at all, so a user who picks "Skip posting" on a GitHub run gets a comment anyway. The gate's message asks about whichever platform the run is on; only one of the two steps was ever meant to be platform-specific.

The fix

The platform decision moves ahead of its first reader. The gate sits directly after the missing-issue gate that sets the creation flag it is conditioned on, so the verification steps and the issue creation both see the choice. The create-issue technique reads the gate's answer instead of obtaining one itself.

The project gate requires that an issue is being created, which its own message already says it is for.

The cheap hard check runs before the expensive operation. Signing is verified before the index.

The build-artifact gates apply to the projects that have build-dependent artifacts — rust-substrate, the ones with .scale and node metadata — and a step between them derives the regeneration commands from the project's build manifest. The hand-off gate presents commands rather than an empty block, and every other project stops being asked.

The inventory is persisted after the design-intent gate, so the artifact records the classification the run proceeds under.

The reference detector also runs after the missing-issue gate, on the not-creating path, when the platform is still unbound. Its input contract names the gate response as a source alongside the opening request, so one home keeps the rules for parsing a key.

The posting gate precedes both posting steps, and both read its answer — under a name that says what it governs rather than naming one platform. Choosing to skip now skips, on either platform, and choosing to post now posts.

Scope of change

Eight files: three work-package activities, two work-package techniques, the work-package workflow declaration, one work-package reference document, one workflow-design activity. 99 lines added, 58 removed. No new technique, one variable renamed, no schema change.

Acceptance criteria

• All 28 guards pass, including the new decision-order guard, which reports zero on this commit and two on the commit before the fixes — the two real pairs among the 14 the same rule finds with its exemptions removed.
• The full server test suite passes against this corpus: 1029 tests.
• The five committed walk snapshots that change are re-recorded against this commit in the adopting pull request, with the corpus stamp bumped in the same commit.
• The delivery-cost gate passes against a baseline re-recorded on this commit.

What the walk shows

The measured work-package walk takes 10 checkpoint round trips instead of 11 — one fewer yield, respond and resume for every project with no build-dependent artifacts to regenerate.

It also gains a step: the reference detector's second binding, which fires because this walk supplies an existing issue and so never binds a platform. That is the defect the step closes, visible from the runtime side.

Delivery is 1,302,319 characters, 5,559 above the recording before these fixes. Most of it is one extra get_technique — the detector's second delivery is a full 4,054-character fetch rather than a ledger hit, because a technique bundled into get_activity does not satisfy a later standalone get_technique for the same content. That is a delivery-layer observation, not a definition problem; the fixture description records it so the next reader does not have to re-derive it.

Non-goals

• The user is asked no fewer questions. Nothing here merges or removes a decision; only when it is put, and whether the answer reaches anything. Batching the per-iteration gates remains a separate question with a real trade-off — three gates on an irreversible push is a defensible safety design.
• The bundled-delivery gap is not closed here. A technique bundled into an activity does not satisfy a later standalone fetch of the same content. It costs 4,054 characters on this walk and belongs with the delivery layer, not with step order.
• remediate-vuln declares a post_jira_comment variable that nothing reads. A dead declaration in a different workflow, left for whoever sweeps that class.

Investigation detail

Evaluation report and per-dimension analysis

🤖 Generated with Claude Code