Enforce coordination change-risk authority boundaries

.agents/skills/check-board/references/deep-detail.md

@@ -229,6 +229,8 @@ Each finding has a code, a ground truth, and a fix — or an explicit refusal to
 | `CLAIM-STATUS-LAG` | held claim, and board `status` is one of `Ready`/`Backlog`/*(no status)* — the columns a claim SHOULD have overwritten. A held `Blocked`/`In review` is the holder's own decision and is **deferred, not reconciled** (#331) | `set-field --batch <i> "Status=In progress"` |
 | `CLAIM-REVIEW-LAG` | held claim, a freshly observed item PR is open, and board `status != In review` | `set-field --batch <i> "Status=In review"` |
 | `LIFECYCLE-PROJECTION-LAG` | a fresh complete lifecycle observation disagrees with Project Status and no legacy Chore owns that Status write | `set-field --batch <i> Status=Ready/Backlog/In progress/Blocked/In review/Done` |
+| `PREMATURE-COMPLETION` | the issue closed without authoritative completion evidence; reconciliation persists a correction receipt and restores a safe nonterminal projection | reopen issue, then `set-field --batch <i> Status=Blocked/In review` |
+| `COMPLETION-PROJECTION-LAG` | a verified typed completion receipt exists but issue closure or Project Status is incomplete | close issue as completed, then `set-field --batch <i> Status=Done` |
 | `AUTO-DONE-LIVE-CLAIM` | held claim and board `status == Done` — merge/issue-close automation may have projected completion while the holder still owes release, publication, dispatch, or deployment verification | **report and message the holder; never count terminal** — the holder reopens the issue and freshly restores `In review`, or produces the exact green `FSGG-DONE` evidence and drops the claim |
 | `UNDECLARED-PATHS` | open, unclaimed, not `Done`, and the issue body declares no `Paths:` | **ask** (§5) — the fix is an *issue* edit, so it takes an answer |
 | `ON-BOARD-NO-STATUS` | open, **unclaimed**, on the board, with an empty `Status` column (`""` — `NoStatus`) | **report only** — a human must choose `Ready` vs `Backlog`; the reconciler cannot invent the missing fact (§5's *never guess*), so it names the drift and writes **nothing** |

.agents/skills/cross-repo-coordination/references/deep-detail.md

@@ -329,7 +329,7 @@ by printing a success line; **earn** it — have the tool confirm both facts fir
 ```sh
 scripts/fsgg-coord done <issue>            # verify BOTH; green FSGG-DONE stamp (exit 0) or
                                            # red FSGG-NOT-DONE stamp naming the failing check (exit 1)
-scripts/fsgg-coord done <issue> --flip     # once the PR is merged, also set Status=Done, then stamp
+scripts/fsgg-coord delivery <issue> --pr <pr> --flip --apply  # verify the merge, receipt it, then project Done
 scripts/fsgg-coord done <issue> --pr <N>   # name the closing PR explicitly (else the first merged closer)
 ```
 
@@ -403,7 +403,7 @@ wrong and the registry advertises a version the feed can't serve. The universal
    (e.g. `FS.GG.Templates` → `providers/<provider>.providers.yml` `source: <PkgId>::<V>`); its
    own CI (e.g. `composition`) must pass.
 4. **Land + record.** Merge both PRs, confirm the producer issue closed, then close out each board
-   item with `scripts/fsgg-coord done <issue> --flip` (see *Signal an item is finished*) — it flips
+   item with `scripts/fsgg-coord delivery <issue> --pr <pr> --flip --apply` (see *Signal an item is finished*) — it flips
    `Status: Done` only after re-confirming the merge, the green stamp is your proof, and the parent
    epic rolls up to `Done` on its own once the last child stamps green.
 

.agents/skills/intra-repo-parallel-work/references/deep-detail.md

@@ -65,7 +65,7 @@ Whatever named you, the claim marker records `harness=<name> session=<id>` as pr
 | A repo owner is a **person you can ask** | Workers cannot see or talk to each other | **`who`** (what is running) + **`say`/`inbox`** (a channel) |
 
 Everything else is inherited: the board is still the source of *order*, the registry of
-*contracts*, ADRs of *decisions*; `fsgg-coord done <issue> --flip` still earns the done-stamp
+*contracts*, ADRs of *decisions*; `fsgg-coord delivery <issue> --pr <pr> --flip --apply` earns typed completion authority
 and rolls epics up.
 
 ## When to use this skill
@@ -107,7 +107,7 @@ jq -e '.markerObserved and .converged' <<<"$receipt" >/dev/null
 git fetch origin                               # NOTHING else does — the base is otherwise the PAST (#622)
 git worktree add ../<repo>-<n> -b item/<n>-<slug> origin/main   # name the base (#319)
 # ...implement, commit with the printed FSGG-Worker trailer, PR into main...
-scripts/fsgg-coord done <issue> --flip         # earn the stamp
+scripts/fsgg-coord delivery <issue> --pr <pr> --flip --apply  # verify and project completion
 ```
 
 `take` is the entry point. It asks `batch` what is schedulable *right now* (disjoint from
@@ -387,7 +387,7 @@ dead queue ([#601](https://github.com/FS-GG/.github/issues/601)).
 ## 5. Finish — the earned done-stamp (unchanged)
 
 ```sh
-scripts/fsgg-coord done <issue> --flip     # green FSGG-DONE only after PR merged AND Status=Done
+scripts/fsgg-coord delivery <issue> --pr <pr> --flip --apply  # receipt only after exact PR merge verification
 ```
 
 Same stamp and epic roll-up as cross-repo. Check your PR stayed inside its declaration:

.agents/skills/pnext-item/SKILL.md

@@ -389,9 +389,11 @@ load [deep detail](references/deep-detail.md).
 ## 7. Stamp and stop
 
 ```bash
-scripts/fsgg-coord done <ref> --flip --pr <pr>
+scripts/fsgg-coord delivery <ref> --pr <pr> --flip --apply --json
 ```
 
-The exact green done stamp, closed issue, `Done` column, released claim, zero pending board writes, and
-fresh board confirmation are completion. If any is missing, repair it before reporting. Clean the
-worktree and branch only after verification. Report the exact stamp and stop; one invocation owns one item.
+This completion call re-inspects the exact merge and declared obligations, appends the typed completion
+receipt first, and only then projects the closed issue, `Done` column, released claim, and cleanup state.
+The exact green done stamp, zero pending board writes, and fresh board confirmation are completion. If any
+is missing, repair it and repeat this same idempotent delivery call before reporting. Clean the worktree
+and branch only after verification. Report the exact receipt/stamp and stop; one invocation owns one item.

.agents/skills/pnext-item/references/command-contracts.md

@@ -95,7 +95,7 @@ no PR of its ever carries the marker and doing so would wedge it forever.
 | **0** | GREEN — the PR is finished work: it merges cleanly, and every workflow run and check-run scored on its head SHA passed. The ONLY code that means merge it. | Merge it. This is the only code that says so. |
 | **7** | PENDING — the verdict has not SETTLED: checks are still running, none have registered yet, the run set is still growing, GitHub has not finished computing the PR's mergeability (it does so in a BACKGROUND job, and `null` is the normal first answer for a PR you just opened — #950), GITHUB ITSELF SAYS IT WILL REFUSE THIS MERGE — its `mergeable_state` for the gated head is `blocked` (the base branch policy is not satisfied: a required context that failed, or that has NO CHECK RUN AT ALL because the workflow producing it is not on this branch, or a required review, or an unresolved conversation), `behind` (a strict base moved) or `draft` (#1575) — or an assertion you added (`--require`, `--sha`) is not yet met. The ONE retryable verdict, which is why it has a code of its own rather than sharing one with a way to stop. | Keep waiting — this is the only code that says wait. Prefer `--wait`, which polls until the verdict settles rather than believing an early green. A `pending` that NEVER resolves is a finding, and the remedies are OPPOSITE, so read which one you were handed. GitHub refused the merge (`blocked`/`behind`/`draft`, and the line names the state and the base branch): REBASE onto the current base so the required workflow exists on this head and can fire; mark a DRAFT ready for review; or stop requiring a context nothing on this branch can produce. WAITING CANNOT CREATE A CHECK RUN FOR A WORKFLOW THAT DOES NOT EXIST ON THIS BRANCH — no amount of polling makes an absent producer report, which is why this arm names the context rather than telling you to wait harder. Otherwise: the job was RENAMED, its workflow's `paths:` filter no longer matches, `--sha` named the wrong commit, or GitHub never finished computing mergeability (rare, and not something waiting longer fixes — read the PR yourself). |
 | **3** | RED or CONFLICTED — two words, one code, because both mean STOP and neither improves by waiting. Red: a run or check-run failed. Conflicted: the PR does not merge cleanly, so GitHub cannot build `refs/pull/N/merge` and gives it NO CI at all — which is why it is returned immediately rather than polled. | Stop. Do NOT wait — 3 is the code the recipe used to call `pending`, and a loop that waits on it never terminates. A red check is a finding; a conflicted PR needs a rebase, which is AUTHORING, not landing. |
-| **10** | MERGED, or CLOSED without merging — the PR is NOT OPEN, so there is nothing left to gate (#1680). The word on stdout tells the two apart: `merged` means the work LANDED, `closed` means it was abandoned or rejected and nothing landed. Terminal, and deliberately NOT 7: GitHub reports `mergeable: null` for a merged PR, which used to read as "still computing" and return PENDING — the ONE code the contract defines as worth retrying — for the most terminal state there is. `landable <merged-pr> --wait` therefore spent its entire 600s budget (30 tries x 20s) on a settled fact, every time, and the caller that meets this most is the RECOVERY path (`pnext-item` §5, `adopt`), which re-gates a PR whose worker died between merge and stamp. It was told to wait forever on work that was already landed. It is also not 3: `merged` is a success, and folding it into the red/conflicted code would tell that same successor to stop rather than to stamp. | Stop polling — no amount of waiting reopens a PR, and `--wait` does not poll this at all. READ THE WORD, because the next act is opposite. `merged`: the work is LANDED. Do not merge it again and do not treat it as a failure — if you are recovering an item whose worker died mid-flight, go STAMP it (`done <ref> --flip --pr <pr>`). `closed`: nothing landed, so do NOT stamp it done; the branch was abandoned or the PR rejected, and the item needs re-work or release, not a merge. |
+| **10** | MERGED, or CLOSED without merging — the PR is NOT OPEN, so there is nothing left to gate (#1680). The word on stdout tells the two apart: `merged` means the work LANDED, `closed` means it was abandoned or rejected and nothing landed. Terminal, and deliberately NOT 7: GitHub reports `mergeable: null` for a merged PR, which used to read as "still computing" and return PENDING — the ONE code the contract defines as worth retrying — for the most terminal state there is. `landable <merged-pr> --wait` therefore spent its entire 600s budget (30 tries x 20s) on a settled fact, every time, and the caller that meets this most is the RECOVERY path (`pnext-item` §5, `adopt`), which re-gates a PR whose worker died between merge and stamp. It was told to wait forever on work that was already landed. It is also not 3: `merged` is a success, and folding it into the red/conflicted code would tell that same successor to stop rather than to stamp. | Stop polling — no amount of waiting reopens a PR, and `--wait` does not poll this at all. READ THE WORD, because the next act is opposite. `merged`: the work is LANDED. Do not merge it again and do not treat it as a failure — if you are recovering an item whose worker died mid-flight, complete delivery (`delivery <ref> --pr <pr> --flip --apply`). `closed`: nothing landed, so do NOT project it done; the branch was abandoned or rejected and the item needs re-work or release, not a merge. |
 | **4** | UNKNOWN — no verdict, and this is the FAIL-CLOSED one (#266). The read could not be made or its answer was not conclusive: a rate limit, a 404, a PR whose `mergeable` field is ABSENT entirely. Note what it is NOT. An UNREADABLE BRANCH POLICY is NOT one of these causes (#1575): when GitHub says it will refuse the merge, the refusal stands on GitHub's OWN word (`mergeable_state`, already in the PR body) and the policy read is DIAGNOSIS ONLY — a 403 or a rate limit on it costs you the SENTENCE naming which context is unmet, never the verdict, which stays PENDING (7). A gate that failed closed on a read the fleet's token cannot make would not fail closed; it would fail ALWAYS (#463). A `mergeable` GitHub has not computed YET is PENDING (7), not this — it is guaranteed to change, and calling it unknown made `--wait` settle at once and abandon a seconds-old PR (#950). And there is no EX_RATE (75) here, unlike `take`: an exhausted budget arrives as this code, because `landable` has no error channel to carry a budget on. | Do not merge, and do not treat it as a red. An unreachable answer is not a negative one. Look at why the read failed — check `budget` if you suspect a rate limit — and ask again. |
 | **1** | REFUSED — the engine rejected your INPUT before it ever looked at the PR: no `--repo` (so which repo the PR is in is undefined), a ref that is not a PR number, or the wrong number of arguments. It is not a verdict about the PR, and no word is printed. | Read the message and fix the call. Not retryable — it will refuse identically. |
 | **2** | The ENGINE broke — an unhandled defect, with a stack trace. Its own code, so a broken engine cannot hide behind a stream of what look like bad inputs. | Report it. Do not retry, and do not merge a PR you have no verdict on. |

.agents/skills/pnext-item/references/deep-detail.md

@@ -1161,7 +1161,7 @@ scripts/fsgg-coord set-field <issue> Status "In review"
 scripts/fsgg-coord ready --repo <repo> --all --json \
   | jq -e '.[] | select(.number == <n> and .status == "In review")' >/dev/null
 # Run and verify every named release/publication/dispatch/deployment obligation here.
-# Once all are verified, close the issue again; only then can `done --flip` earn FSGG-DONE below.
+# Once all are verified, let `delivery --apply` append the typed completion receipt and reconcile closure below.
 gh api -X PATCH repos/FS-GG/<repo>/issues/<n> -f state=closed
 ```
 
@@ -1384,7 +1384,7 @@ A red check is a finding, not an obstacle.
 Then earn the stamp:
 
 ```sh
-scripts/fsgg-coord done <issue> --flip      # green FSGG-DONE only if PR merged AND Status=Done
+scripts/fsgg-coord delivery <issue> --pr <pr> --flip --apply --json  # receipt first; then closure and Done
 ```
 
 Capture and report the exact `FSGG-DONE` line. The board's `Done` column is only a projection and may

.claude/skills/check-board/references/deep-detail.md

@@ -229,6 +229,8 @@ Each finding has a code, a ground truth, and a fix — or an explicit refusal to
 | `CLAIM-STATUS-LAG` | held claim, and board `status` is one of `Ready`/`Backlog`/*(no status)* — the columns a claim SHOULD have overwritten. A held `Blocked`/`In review` is the holder's own decision and is **deferred, not reconciled** (#331) | `set-field --batch <i> "Status=In progress"` |
 | `CLAIM-REVIEW-LAG` | held claim, a freshly observed item PR is open, and board `status != In review` | `set-field --batch <i> "Status=In review"` |
 | `LIFECYCLE-PROJECTION-LAG` | a fresh complete lifecycle observation disagrees with Project Status and no legacy Chore owns that Status write | `set-field --batch <i> Status=Ready/Backlog/In progress/Blocked/In review/Done` |
+| `PREMATURE-COMPLETION` | the issue closed without authoritative completion evidence; reconciliation persists a correction receipt and restores a safe nonterminal projection | reopen issue, then `set-field --batch <i> Status=Blocked/In review` |
+| `COMPLETION-PROJECTION-LAG` | a verified typed completion receipt exists but issue closure or Project Status is incomplete | close issue as completed, then `set-field --batch <i> Status=Done` |
 | `AUTO-DONE-LIVE-CLAIM` | held claim and board `status == Done` — merge/issue-close automation may have projected completion while the holder still owes release, publication, dispatch, or deployment verification | **report and message the holder; never count terminal** — the holder reopens the issue and freshly restores `In review`, or produces the exact green `FSGG-DONE` evidence and drops the claim |
 | `UNDECLARED-PATHS` | open, unclaimed, not `Done`, and the issue body declares no `Paths:` | **ask** (§5) — the fix is an *issue* edit, so it takes an answer |
 | `ON-BOARD-NO-STATUS` | open, **unclaimed**, on the board, with an empty `Status` column (`""` — `NoStatus`) | **report only** — a human must choose `Ready` vs `Backlog`; the reconciler cannot invent the missing fact (§5's *never guess*), so it names the drift and writes **nothing** |

.claude/skills/cross-repo-coordination/references/deep-detail.md

@@ -329,7 +329,7 @@ by printing a success line; **earn** it — have the tool confirm both facts fir
 ```sh
 scripts/fsgg-coord done <issue>            # verify BOTH; green FSGG-DONE stamp (exit 0) or
                                            # red FSGG-NOT-DONE stamp naming the failing check (exit 1)
-scripts/fsgg-coord done <issue> --flip     # once the PR is merged, also set Status=Done, then stamp
+scripts/fsgg-coord delivery <issue> --pr <pr> --flip --apply  # verify the merge, receipt it, then project Done
 scripts/fsgg-coord done <issue> --pr <N>   # name the closing PR explicitly (else the first merged closer)
 ```
 
@@ -403,7 +403,7 @@ wrong and the registry advertises a version the feed can't serve. The universal
    (e.g. `FS.GG.Templates` → `providers/<provider>.providers.yml` `source: <PkgId>::<V>`); its
    own CI (e.g. `composition`) must pass.
 4. **Land + record.** Merge both PRs, confirm the producer issue closed, then close out each board
-   item with `scripts/fsgg-coord done <issue> --flip` (see *Signal an item is finished*) — it flips
+   item with `scripts/fsgg-coord delivery <issue> --pr <pr> --flip --apply` (see *Signal an item is finished*) — it flips
    `Status: Done` only after re-confirming the merge, the green stamp is your proof, and the parent
    epic rolls up to `Done` on its own once the last child stamps green.
 

.claude/skills/intra-repo-parallel-work/references/deep-detail.md

@@ -65,7 +65,7 @@ Whatever named you, the claim marker records `harness=<name> session=<id>` as pr
 | A repo owner is a **person you can ask** | Workers cannot see or talk to each other | **`who`** (what is running) + **`say`/`inbox`** (a channel) |
 
 Everything else is inherited: the board is still the source of *order*, the registry of
-*contracts*, ADRs of *decisions*; `fsgg-coord done <issue> --flip` still earns the done-stamp
+*contracts*, ADRs of *decisions*; `fsgg-coord delivery <issue> --pr <pr> --flip --apply` earns typed completion authority
 and rolls epics up.
 
 ## When to use this skill
@@ -107,7 +107,7 @@ jq -e '.markerObserved and .converged' <<<"$receipt" >/dev/null
 git fetch origin                               # NOTHING else does — the base is otherwise the PAST (#622)
 git worktree add ../<repo>-<n> -b item/<n>-<slug> origin/main   # name the base (#319)
 # ...implement, commit with the printed FSGG-Worker trailer, PR into main...
-scripts/fsgg-coord done <issue> --flip         # earn the stamp
+scripts/fsgg-coord delivery <issue> --pr <pr> --flip --apply  # verify and project completion
 ```
 
 `take` is the entry point. It asks `batch` what is schedulable *right now* (disjoint from
@@ -387,7 +387,7 @@ dead queue ([#601](https://github.com/FS-GG/.github/issues/601)).
 ## 5. Finish — the earned done-stamp (unchanged)
 
 ```sh
-scripts/fsgg-coord done <issue> --flip     # green FSGG-DONE only after PR merged AND Status=Done
+scripts/fsgg-coord delivery <issue> --pr <pr> --flip --apply  # receipt only after exact PR merge verification
 ```
 
 Same stamp and epic roll-up as cross-repo. Check your PR stayed inside its declaration: