Summary
A step's position in an activity decides when it runs relative to everything else. Four steps in the two heaviest work-package activities sit in a position that makes them useless or expensive: a decision is taken after the work it was meant to steer, a question is asked about work that will never happen, a check that costs nothing runs after an operation that costs a great deal, and a gate asks the user something the run could answer itself.
None of these 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.
What happens today
An issue is created, and then the user is asked which platform to create it on. The first activity has 52 steps. The variable naming the issue platform is read at 14 of them — nine as step gates, the rest as checkpoint conditions — and written at exactly one: a checkpoint at step 31. The first read is at step 20, eleven steps earlier. The issue-creating step is at step 30, and the platform gate is at step 31, so 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. Both steps are gated on the same flag, so this is the ordinary create path rather than an edge case.
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. Every Jira run with an existing issue pays this: four server calls, two turn boundaries and the checkpoint response floor.
A repository is indexed before the run discovers it cannot proceed. Commit signing is a hard precondition — the check is a validate action with no gate, and its message tells the user to configure signing and re-run. It sits at step 14. The full repository index sits at step 13. So 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 gate assumes is already known. 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 that has exactly two references in the whole corpus: its declaration, and that interpolation. Nothing writes it. So the run asks the user a question it could answer by looking at what the repository builds, and then shows them an empty commands block.
The fix
Move the platform decision ahead of its first reader. The gate belongs before the verification steps that read the platform, not after the step that consumes the decision. That is a position change rather than new logic.
Condition the project gate on creation, not on platform. The gate's own message says the project is for a new issue, so the condition should say so too: platform is Jira and an issue is being created.
Put the cheap hard check before the expensive operation. The signing precondition moves ahead of the repository index. Ordering hard-fail checks by cost is the general form; this is the one instance measured.
Give the build-artifact question a producer, or stop asking it. Two honest resolutions: detect what the repository's build produces and set the pending flag from that, so the first gate goes away; or, if the answer genuinely needs a human, drop the second gate's interpolation until something writes it. Asking, then presenting an empty answer, is the one option to rule out.
Extend the checkpoint-entry guard to catch the class. The guard already refuses an activity that opens with a checkpoint. Adding one rule — a checkpoint whose variable writes are read by an earlier step of the same activity — would have caught the first defect mechanically, and catches the next one without anyone reading step lists again.
Why now is cheap
Four definition edits and one guard rule, with no server change. Three of the four are a step moving position or a condition gaining a clause; the fourth is the only one that needs a decision about what the run should detect.
The definition ceremony is fixed per landing rather than per edit — a corpus commit, a pointer bump, six walk snapshots, a corpus stamp, regenerated site data and a re-recorded delivery baseline — so these four belong in one landing. The walk snapshots will move, which is the point: they record the path a run takes, and the path is what changes.
Scope of change
Two activity files in work-package — the first activity and submit-for-review — plus one guard script and its test. The build-artifact resolution may add a detection step or remove a gate depending on which way it is decided.
Acceptance criteria
- The platform gate is presented before any step that reads the platform, and the create path no longer creates an issue ahead of it.
- A run holding an existing Jira issue is not asked to choose a project.
- A repository without commit signing configured fails before the index runs, not after.
- The build-artifact question either has a producer that answers it, or the gate that shows the commands no longer interpolates a variable nothing writes.
- The checkpoint-entry guard reports a checkpoint whose writes are read earlier in the same activity, and the four fixes leave it green.
- All guards pass and the six walk snapshots are re-recorded in the same commit as the corpus stamp.
Non-goals
- Merging the interleaved gates is a separate question. The same analysis proposes collapsing per-iteration gates into batched presentations, which is a larger change with a real trade-off: three gates on an irreversible push is a defensible safety design, not friction to remove. Nothing here reduces the number of decisions the user is asked to make — only when they are asked.
- The unproduced-variable class is not swept here. The build-artifact commands variable is one of eighteen consumed with no producer; the general fix is a guard rule that stops a declared workflow variable counting as its own producer, which is its own piece of work.
- No server change. Step position is a definition property, and the delivery layer already reads gates it can answer.
Relationship to #400
The platform gate is the shape #400 names as "gates that fire can still decide nothing" — a user answers, and nothing downstream is different — but arriving by a different cause: position rather than a missing effect. The signing-check defect is not a gate concern at all. Fold this into that epic if the grouping is preferred; kept separate here because two of the four are sequencing and cost rather than decision integrity.
Investigation detail
Ordering defects and the coupling analysis they came from · evaluation report
Step positions in this issue were re-derived from the current corpus rather than taken from the report; the report counts the platform variable's nine step gates, where the figure above counts all 14 read sites.
Summary
A step's position in an activity decides when it runs relative to everything else. Four steps in the two heaviest work-package activities sit in a position that makes them useless or expensive: a decision is taken after the work it was meant to steer, a question is asked about work that will never happen, a check that costs nothing runs after an operation that costs a great deal, and a gate asks the user something the run could answer itself.
None of these 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.
What happens today
An issue is created, and then the user is asked which platform to create it on. The first activity has 52 steps. The variable naming the issue platform is read at 14 of them — nine as step gates, the rest as checkpoint conditions — and written at exactly one: a checkpoint at step 31. The first read is at step 20, eleven steps earlier. The issue-creating step is at step 30, and the platform gate is at step 31, so 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. Both steps are gated on the same flag, so this is the ordinary create path rather than an edge case.
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. Every Jira run with an existing issue pays this: four server calls, two turn boundaries and the checkpoint response floor.
A repository is indexed before the run discovers it cannot proceed. Commit signing is a hard precondition — the check is a validate action with no gate, and its message tells the user to configure signing and re-run. It sits at step 14. The full repository index sits at step 13. So 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 gate assumes is already known. 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 that has exactly two references in the whole corpus: its declaration, and that interpolation. Nothing writes it. So the run asks the user a question it could answer by looking at what the repository builds, and then shows them an empty commands block.
The fix
Move the platform decision ahead of its first reader. The gate belongs before the verification steps that read the platform, not after the step that consumes the decision. That is a position change rather than new logic.
Condition the project gate on creation, not on platform. The gate's own message says the project is for a new issue, so the condition should say so too: platform is Jira and an issue is being created.
Put the cheap hard check before the expensive operation. The signing precondition moves ahead of the repository index. Ordering hard-fail checks by cost is the general form; this is the one instance measured.
Give the build-artifact question a producer, or stop asking it. Two honest resolutions: detect what the repository's build produces and set the pending flag from that, so the first gate goes away; or, if the answer genuinely needs a human, drop the second gate's interpolation until something writes it. Asking, then presenting an empty answer, is the one option to rule out.
Extend the checkpoint-entry guard to catch the class. The guard already refuses an activity that opens with a checkpoint. Adding one rule — a checkpoint whose variable writes are read by an earlier step of the same activity — would have caught the first defect mechanically, and catches the next one without anyone reading step lists again.
Why now is cheap
Four definition edits and one guard rule, with no server change. Three of the four are a step moving position or a condition gaining a clause; the fourth is the only one that needs a decision about what the run should detect.
The definition ceremony is fixed per landing rather than per edit — a corpus commit, a pointer bump, six walk snapshots, a corpus stamp, regenerated site data and a re-recorded delivery baseline — so these four belong in one landing. The walk snapshots will move, which is the point: they record the path a run takes, and the path is what changes.
Scope of change
Two activity files in
work-package— the first activity and submit-for-review — plus one guard script and its test. The build-artifact resolution may add a detection step or remove a gate depending on which way it is decided.Acceptance criteria
Non-goals
Relationship to #400
The platform gate is the shape #400 names as "gates that fire can still decide nothing" — a user answers, and nothing downstream is different — but arriving by a different cause: position rather than a missing effect. The signing-check defect is not a gate concern at all. Fold this into that epic if the grouping is preferred; kept separate here because two of the four are sequencing and cost rather than decision integrity.
Investigation detail
Ordering defects and the coupling analysis they came from · evaluation report
Step positions in this issue were re-derived from the current corpus rather than taken from the report; the report counts the platform variable's nine step gates, where the figure above counts all 14 read sites.