Repository navigation
Board-tend contract wording: scope 'never closes on source alone', align pnext draft rule, fix changelog summary #5185
Description
Work level: Delivery · Track: Follow-up · Intended Status: Ready
Owner
Root/fdev assigns the skills owner.
Done when
These non-blocking findings from the independent review of #5168 (35113805) are fixed and mirrored:
lifecycle-contract.md:80reads "C1 never closes a Delivery on source alone while a release, install or readback remains".pnext-item/SKILL.md:61keeps the PR draft "until its required gates pass", matching status-lifecycle line 33.registry/skills.CHANGELOG.md's summary uses the new completes/continues wording.
It rides the next skills PR or the 0.114.2 kit cut, to avoid an extra full CI cycle.
Current deliverable
None.
Next action
Owner selects and starts.
Blocked on
Nothing.
Acceptance evidence
None yet.
Activity
EHotwagner commentedon Nov 1, 2026
Root/fdev, scope addition from a 2026-11-01 incident. Concurrent subagents wrote generic filenames (
pr-body.md) into the coordinator's shared session scratchpad. One worker then pushed another lane's PR body onto Coordination#1116. It was restored within minutes, but it left cross-references on Coordination#50 and .github#5179.Add to pnext-item and the work-board delegation guidance: each owner and critic keeps every working file under its own
~/.fsgg-scratch/<item-or-pr>/, and never writes generic names into a shared scratchpad. PR bodies are written from a per-item file and read back before the PATCH.EHotwagner commentedon Nov 1, 2026
Root/fdev, another scope addition from 2026-11-01. GitHub's closing-keyword parser matches phrases like "does not close #54". FourD#56's merge auto-closed FourD#54 as completed although its acceptance was unmet; Root reopened it. A worker hit the same thing on FS.GG.SDD#1151, where the
closing-keywordscheck caught it. Add to pnext-item: PR bodies never put close/fix/resolve and their inflections immediately before an issue reference, even when negated. Also check that every product repo runs theclosing-keywordsgate; FS.GG.FourD apparently does not.EHotwagner commentedon Nov 1, 2026
Root/fdev: the closing-keyword accident recurred on SC2.Client#52 → #50, and Coordination#1115 currently links Coordination#50. Raising priority within this Delivery:
closingIssuesReferencesand requires[].closing-keywordsgate to the product repos that lack it (FS.GG.FourD, FS.GG.SC2.Client, probably others). This may warrant its own Delivery.EHotwagner commentedon Nov 1, 2026
Root/fdev scope addition: #5171 (PR #5178) put the
fsgg-dispatch:marker paragraph in work-board and pnext-item. The drive-board wrappers that brief workers (drive-board, drive-board-normal and drive-board-best, plus the work-board-normal and work-board-best wrappers) also get a one-line pointer here.EHotwagner commentedon Nov 1, 2026
Root/fdev: correction. The drive-board wrappers contain no brief text, so no marker pointer is needed there (#5178 review F7). That item is removed from this scope.
EHotwagner commentedon Nov 1, 2026
Root/fdev scope addition: interim practice until #5189 lands. Rebind the routine marker in the PR body to the new commit's SHA, which is known locally, before pushing. The push-triggered
routine-eligibilityrun then passes on the new head, and only the superseded head's edit run can fail. Add this to pnext-item's PR steps, pointing at #5189.EHotwagner commentedon Nov 1, 2026
Root/fdev scope addition, from the 2026-11-01 0.114.2 incident (#5136). While a
fsgg:release-window/v1marker is open, any.githubmerge (Root's or a worker's) first runsrelease_source_closure.py check --route coherent-set --source <candidate-source> --live <merge-sha>, and must not merge on a refusal. Add this to host-loop's merge step, and propose it as a merge-gate check, so it is mechanical rather than remembered. Root merged #5191 inside the window without the check, and the publish refused mid-way, leaving FS.GG.Coord.Cli 0.114.2 published without FS.GG.Kit.EHotwagner commentedon Nov 1, 2026
Root/fdev, a process rule to fold into the skills update. A new repository's bootstrap PR cannot be gated by
routine-eligibility. It ispull_request_targetand loads the workflow frommain, which doesn't yet contain it. This is observed on FS.GG.RuneScape#7 and FS.GG.Algorithms#2. The control for bootstrap PRs is independent exact-head review plus Root's--match-head-commitmerge. The first post-bootstrap PR must be checked to confirmroutine-eligibilityruns and passes, as it did on RuneScape #9. Record this in pnext-item and work-board.