Repository navigation
Promote the seam rung to a seventh required context #334
Description
Follow-up to #323. Related to #293, but deliberately NOT a sub-issue of it: this cannot be done while S2.6 is in flight — it is unblocked only after the job has merged to main and reported there — so #293's exit must not depend on it.
#323 added the seam job to .github/workflows/ci.yml (build target 7 of docs/design/stories/293.md). It runs bun run skill-harness — deterministic, offline, secret-free — carries no if:, no matrix and no paths: filter, and can meaningfully fail: bun run skill-harness --inject exits 1 over the five-scenario injection roster.
It is deliberately not yet a required context. Required contexts stand at six, and both scripts/verify-required-checks.sh and scripts/verify-workflow-hygiene.sh PASS at six.
Why the promotion was not done in #323
Two independently sufficient reasons, both measured:
- A required context that has never reported sits
pendingforever and blocks every PR permanently — the decision recorded on S1.6.4 — Build theclaim-lintguard #204, restated inci.yml's own comment.claim-lintwent through exactly this sequence; its promotion commit is15e5a36. story/47-s2-3-execution-skillsand its six open task issues carry no seam job on their heads. Promoting now would permanently block PR S2.3 — Execution skills #313 and every S2.3 task PR (S2.3.1 —task-create#48, S2.3.2 —task-do#49, S2.3.3 —task-verify#50, S2.3.5 —withTasksChecklistmerger, and the checklist on both capability paths #315, S2.3.6 — The hard-failure block emitter #316, S2.3.7 — Reconcile the two references, CONTRIBUTING.md and M2.md #317), because those heads can never report a context whose job they do not contain.
Unblocked when
- The
seamjob has merged tomainand reported on at least one real PR there. -
story/47has mergedmainin, so its head carries the job.
Done when
The four in-tree sites land in ONE commit — the tests in test/ci-workflow.test.ts assert they agree as ordered arrays, so a partial edit goes red:
-
scripts/verify-required-checks.sh— theREQUIRED_CONTEXTSarray -
scripts/verify-required-checks.sh— the inlinerequired_status_checks.contexts[]=list in the branch-protection help text -
scripts/verify-workflow-hygiene.sh— theREQUIRED_JOBSarray -
scripts/verify-workflow-hygiene.sh— therequired = [...]Python list inside the<<'PYEOF'heredoc. This is the one that gets missed: it does not appear in a plain grep forREQUIRED_JOBS
Then, as a separate human action, the two out-of-tree settings:
-
main's branch protection required status checks - ruleset
21656025(story-branch-checks, coveringrefs/heads/story/**)
And finally:
- Both verifiers PASS reporting seven contexts
-
seammoves out ofNOT_REQUIREDintest/ci-workflow.test.tsand into the required list, with the partition still summing to the whole -
ci.yml'sseamcomment is updated to record the promotion — do not leave it asserting it is unpromoted, which is the exact staleness S2.6.6 — The seam rung and its CI job #323 had to correct in theclaim-lintcomment above it
Note for #324
NEVER-293.10's case 13 asserts the required-context count before and after adding the live rung. docs/design/stories/293.md's row for it still says "six contexts before and after". After this promotion the number is seven; the case's own text is count-agnostic, but the Design's prose row will need the correction.
Activity
dev-pmallapp commentedon Sep 23, 2026
The first precondition is now met. The
seamjob has reportedsuccessonmainatdab09ccd5e5f5f73592ca6d97110a51a775a4327(run 35871136833), carried there by PR #312 merging S2.6.That closes the half this issue could not act on: a brand-new required context sits
pendingforever until it has reported on a real PR merged tomain. It has now reported.THE SECOND PRECONDITION IS NOT MET, AND PROMOTING NOW WOULD BLOCK WORK IN FLIGHT.
story/47-s2-3-execution-skillshas not mergedmainin, so it carries noseamjob — its PRs report 7 checks, not 8. Promotingseamto a seventh required context before that merge would leave PR #313 and every remaining S2.3 task PR (#48, #49, #50, #317) permanently blocked on a context that can never report.Order that works:
story/47mergesmainin, acquiring theseamjob.github/workflows/ci.yml, andscripts/verify-required-checks.shandscripts/verify-workflow-hygiene.shwhich each hardcode the job list twice, plusmain's branch protection and ruleset21656025, which no commit can touchtest/ci-workflow.test.tsasserts the four hardcoded lists agree as ordered arrays and that ci.yml's job set partitions into required ∪NOT_REQUIRED— movingseambetween those halves is where the change is declaredBoth verifiers currently read six, and
test/ci-workflow.test.tsis green at that count.#47: merge main into story/47 — the adapter port, the harness, and th…
dev-pmallapp commentedon Sep 23, 2026
Both preconditions are now met. The remaining blocker is out-of-tree and needs a human.
seamhas reported onmain—successatdab09cc(run 35871136833), carried there by PR S2.6 — Skill execution harness #312.story/47has mergedmainin — atcd74902. PR S2.3 — Execution skills #313 now reports 8 checks, all green,seamincluded. Every remaining S2.3 task PR (S2.3.1 —task-create#48, S2.3.2 —task-do#49, S2.3.3 —task-verify#50, S2.3.7 — Reconcile the two references, CONTRIBUTING.md and M2.md #317) will inherit the job, so the permanent-block risk this issue was written to avoid is gone.THE ORDER MATTERS, AND THE OBVIOUS ORDER IS WRONG
Do not land the in-tree change first.
scripts/verify-required-checks.shreadsmain's actual required contexts from the API and compares them against the hardcoded list. Bump the list to seven while branch protection still says six and the verifier fails — on the very PR making the change, which is then blocked by its own edit.Working order:
seamtomain's branch protection and ruleset21656025verify-required-checks.shnow reads seven against the unchanged in-tree list, i.e. it FAILS in the opposite direction.github/workflows/ci.yml, plusscripts/verify-required-checks.shandscripts/verify-workflow-hygiene.sh, each of which hardcodes the job list twiceseamfromNOT_REQUIREDto the required half intest/ci-workflow.test.ts— it asserts the four lists agree as ordered arrays and that ci.yml's jobs partition into required ∪NOT_REQUIREDStep 2 is the one worth not skipping: it proves the verifier is actually reading the API rather than agreeing with itself, which is the failure mode that would make this whole promotion vacuous.
A required job may carry no
if:— a skipped job reports success.seamcurrently has none; keep it that way.Both verifiers read six today and
test/ci-workflow.test.tsis green at that count, so nothing is broken while this waits.