release lane: Back-fill's first release cannot clear step 3, plus six lesser gaps (blind run 18)

[SUaDtL]

Blind agent-judgment exercise run 18 (2026-08-01), 58 commands, against the
release skill at 33e82a6a (commit b74ace58). This is the run recorded in
.codearbiter/reports/agent-lane-proof.json.

Run 18 verified that every fix from runs 16 and 17 holds — helpers survive a
plugin root containing a space, the :/ + ,top clean-tree spelling gives the
same answer from a subdirectory and filters both remedy-written paths, the
step-6c marker no longer trips step 7, and the rebuild subshell contains its
cd. The bare-. counterfactual reproduces the documented silent pass exactly.

Run 18's HIGH-2 (a step-3 parenthetical instructing an interactive rebase
over already-published commits) was fixed immediately rather than filed — it
was a destructive instruction. That fix is the post_exercise_delta recorded in
the proof artifact, and it is why proof_current is false.

Everything below is open.

---

HIGH — Back-fill's own first release cannot clear Phase 1 step 3

The adoption floor that bounds the footer check is derived from
.codearbiter/CONTEXT.md. Pre-flight states explicitly that a consumer which
reached this skill through the Back-fill lane has no CONTEXT.md yet, by
design — that lane exists precisely so a release-only consumer can skip full
onboarding.

Empty floor → nothing to floor against → the entire history is footer-checked.
Reproduced in a scratch repo: 4 commits, 4 [NEEDS-TRIAGE] lines. On a real
repository that is the unbounded triage block A-5.5 exists to prevent, on the
only path the Back-fill lane serves.

This is a design gap, not a sentence. The floor needs a source that does not
presuppose onboarding — the first commit touching the declared payload, or the
back-fill marker's own commit, are the obvious candidates.

MEDIUM — the rebuild's exit code is never checked

Pre-flight says to run the declared rebuild and then assert the artifacts are
in sync. Nothing says the rebuild must have SUCCEEDED. A failed build leaves the
previous artifacts in place, so the freshness assertion passes on a stale
bundle that a broken build failed to update.

MEDIUM — run-pre-tag exit 5 is reported as "drift" regardless of why the command failed

Exit 5's remedy is "reconcile the drift the command reported". A declared
command can exit non-zero for reasons that are not drift at all — a missing
interpreter (see #583, #584), a missing dependency, a network failure. The
operator is handed a confident diagnosis of the wrong problem. Same house rule
as elsewhere in this campaign: "could not run" is not "ran and disagreed".

MEDIUM — the one number that matters is the only step left to the eye

Step 4 has the operator apply the bump word to $BASE_VERSION by hand. None of
the fifteen subcommands does this arithmetic. The downstream guards do not close
it: a minor window mis-applied as a patch gives semver-greater 2.11.1 2.11.0
→ exit 0; check-manifests compares the manifests against the same wrong value
step 6a just wrote → exit 0; classify receives a carried <tag_version> and a
re-read <manifest_version> that agree → publish_fresh.

So the file's own hard rule — "a feat in the window cannot ship as a
patch" — has no enforcement anywhere in the lane. It is the single
unmechanized judgment left in a lane whose stated doctrine is "never by eye",
and it is the one an unenforced hard rule points directly at.

Fix direction: an apply-bump <base> <word> subcommand, asserted against
the classify-window output.

LOW — three

• Multi-valued fields come back comma-separated and the splitting is never
  spelled out, so each consumer of $ARTIFACTS/$PRE_TAG invents its own.
• LAST_TAG is resolved from local tags with no fetch; a stale clone silently
  bases the window on the wrong baseline. (Run 18 confirmed local and remote
  tag sets are currently identical here, so this did not fire.)
• A cross-reference to $REBUILD went stale when the subshell landed.

[SUaDtL]

Independent confirmation, plus one more Major.

Two CodeRabbit review threads sat past the first page of reviewThreads(first:100)
on #576 (totalCount was 102) and so were missed by the first resolve pass. Both
were Major and neither was outdated. Recording them here rather than letting a
resolved-but-unfiled thread be the only trace.

1. "Persist and use an adoption boundary for Back-fill releases" — this is the
same defect as this issue's HIGH, found independently by a different reviewer
against a different payload (plugins/ca-codex/routines/release/SKILL.md). Two
reviewers reaching it separately is a reasonable signal that the adoption floor's
dependence on CONTEXT.md is the real design gap here, not a corner case.

2. "Make governance-path exclusions conditional on target scope" — NEW, not
otherwise filed.

The clean-tree check now excludes .codearbiter/gate-events.log and
.codearbiter/.markers/ unconditionally, in every payload, for every target. The
skill's own prose already anticipates the problem — "If your project's declared
row treats either of these paths as a release surface, do not exempt it" — but
that is a sentence addressed to a human, with nothing mechanical behind it. A
project whose declared payload legitimately includes .codearbiter/ would have
real uncommitted work filtered out of the gate that exists to catch it, silently.

Fix direction: derive the exclusion set from the resolved row rather than
hardcoding it — exempt a governance path only when it falls outside the target's
declared payload. That also makes the exemption self-documenting per target
instead of a global carve-out a reader has to trust.