release skill: two states the lane cannot resolve without a remote, and an ancestry-blind baseline

[SUaDtL]

Deferred findings from the third blind agent-judgment exercise of the portable /ca:release skill (#563). The run found no HIGHs; these are the MEDIUM/LOW remainder, filed rather than fixed because each edit to the skill invalidates the recorded agent-judgment proof (.codearbiter/reports/agent-lane-proof.json) and forces a re-run. The three findings that were pure prose gaps were fixed in the same batch; these four need design decisions, not wording.

1. release_nondraft has no local source, and gh cannot distinguish why it failed

Its only stated origin is gh release view. In a consumer with no remote:

$ gh release view v1.3.0 --json url,isDraft,tagName
no git remotes found
exit=1

gh reports "no remote configured" and "no such release" through the same non-zero exit. Harmless on a fresh tag — tag_exists=false short-circuits before the argument is read — but it matters precisely in the resume_publish / already_published branch, which is where the answer decides whether an already-published release gets republished.

The skill now STOPs on an ambiguous gh failure rather than passing a guess, which closes the unsafe path. What it does not do is give a local-only consumer any way to proceed. Open question: is a --assume-unpublished style explicit operator assertion warranted, or is STOP the correct terminal state?

2. --latest is unevaluable without a remote

The rule is: assert --latest only when the row declares latest-eligible: true and this tag is newest across every declared series (compare against gh release list). gh release list fails identically with no remote. So a row can declare eligibility while the second condition cannot be evaluated, and the skill gives no instruction for that state.

3. last_tag_select is ancestry-blind — documented, reproducible, and cheap to close

Reproduced trivially in the exercise: v1.3.0 was tagged on one branch; a sibling branch that diverged at v1.2.3 and does not contain v1.3.0 still resolved LAST_TAG=v1.3.0, because resolution is by highest semver across the series with no reachability check.

$ git merge-base --is-ancestor v1.3.0 HEAD
→ LAST_TAG IS NOT an ancestor of HEAD

The window came out right (the branches diverge), but the base version did not: that branch would derive 1.4.0 instead of 1.3.0. The skill documents this accurately as a known residual. The point of this item is that it costs exactly one git merge-base --is-ancestor to detect, and the lane never spends it.

4. The back-fill lane has no unattended path, and names its target from a module constant

Two facets of the same lane:

• backfill-detect proposes a row named app, from _BACKFILL_DEFAULT_TARGET in _releaselib.py — not from anything in the consumer repo (the exercise's fixture named itself scratch-consumer in package.json). The operator is asked to confirm verbatim a name derived from a module constant.
• Back-fill step 2 requires explicit confirmation before writing, so the lane cannot complete unattended by construction. That is correct and deliberate for an interactive operator, but it means there is no automation path at all through first-time target declaration.

Whether to derive the default name from the manifest, and whether an unattended path should exist, are both design calls.

Low

The prose's literal TAG_PREFIX=$(python3 … tag-prefix $TARGET) form has no exit-code check; on failure it captures empty and the lane derives a base version of 0.0.0 — silent, plausible-looking, wrong. Caveated by the exercising agent itself: a compliant agent STOPs earlier, so this is an exposure in the written form rather than a reachable defect.

---

Full run record, including the five scenarios and what each proved: .codearbiter/reports/agent-lane-proof.json.

[SUaDtL]

Run 4 additions

The fourth blind exercise found two HIGHs (both remediated in fd3d8d6; the tag-cleanup one was #569, already filed and shipped unfixed). It also produced these deferred items, which join the four above.

Back-fill's proposed row is not derived from the consumer. Beyond the app name already noted: prefix: v is a constant too. Nothing in scan_backfill_candidates / detect_candidate_target reads git tags at all. A consumer whose series is release-1.2.0 gets prefix: v anyway, so last-tag returns <none>, base becomes 0.0.0, and the derived version is 0.1.0 — which satisfies the "strictly greater than LAST_TAG" check while shipping a version below the manifest's own 1.2.0. The block is presented for confirmation, so an alert operator can catch it, but nothing directs attention to the prefix specifically.

Also: detect_candidate_target accepts target=/prefix= kwargs, but the CLI never exposes them — backfill-detect's one optional positional is the scan root, not the target name.

LAST_TAG=<none> is a literal string that breaks every following command. Pre-flight says "No matching tag → LAST_TAG=<none>, treat the full history as the window", and every subsequent step is written as git log LAST_TAG..HEAD. Run verbatim:

$ git log <none>..HEAD
fatal: bad revision '<none>..HEAD'

The prose never says how to turn the sentinel into a usable range. This bites precisely the first-release consumer the back-fill lane exists to serve.

The back-fill lane sits before the branch check. File order is Targets → Back-fill → Pre-flight. Back-fill says to commit the new declaration "on the current branch"; Pre-flight, read afterwards, requires HEAD not be the default branch, and the hard rules forbid writing to main. An operator invoking /release on main with no declared file is told to commit there, then stopped for being there.

"This lane never runs again for this project" is branch-scoped, not project-scoped. release-targets.md is a tracked file, so on a branch created before the declaration commit it simply does not exist and the back-fill trigger fires again. Step 4's claim is empirically false across branches.

Back-fill routes its commit through commit-gate, which reads .codearbiter/ state that a release-only consumer deliberately does not have — the lane exists to let consumers skip onboarding. Both exercising agents substituted a plain git commit and said so.

Two-scratch-file ambiguity. Phase 1 step 5 says one scratch file holds the section and that Phase 2's <message-file> and Phase 3's notes file both read it back — but Phase 2's message is the section plus a Released-at: footer. One file mutated in place, or two? Invisible to every guard (notes-match only checks the first heading), so it surfaces only if someone diffs the tag message against the release notes.

notes-match raises a raw UnicodeDecodeError on a non-UTF-8 notes file rather than refusing cleanly. The module's stated invariant is "never raise on malformed input", and the skill's own prescribed heading contains an em dash — the character most likely to be mis-encoded by a Windows tool.

[SUaDtL]

Run 5 re-rated the <none> sentinel item above as HIGH, and the argument holds: the affected population is precisely the Back-fill lane's own audience — a consumer that has just declared its first target has, by construction, no tag in that series — and the prose called that state "normal, not an error" while handing over git log <none>..HEAD, which exits 128. Fixed in 02caf16; the window is now derived into $WINDOW before any command consumes it.

Also fixed there, from run 5: the unquoted empty <tag_sha> (which vanishes rather than becoming an empty positional, so classify exits 2 on the fresh-publish path), <manifest_version> naming no extraction command, and the tag round-trip check reading %(contents) — a reconstruction that appends a newline and cannot detect a byte difference even in principle.

Still open here: back-fill's hardcoded app name and prefix: v (run 5 adds that display-name is likewise never emitted, so every back-filled project's Release titles read app X.Y.Z: …), the branch-ordering issue, the branch-scoped "never runs again" claim, commit-gate in a consumer without .codearbiter/ state, the two-scratch-file ambiguity, gh release list asymmetry, and notes-match's UnicodeDecodeError.

One new LOW from run 5: Phase 1 step 5 prescribes ## [X.Y.Z] — DATE with an em dash while invoking "the Keep-a-Changelog bracket heading", which uses -. Following it literally leaves a CHANGELOG mixing both separators. Harmless to the guards (_CHANGELOG_DATE_RE accepts either) but inconsistent.

[SUaDtL]

Run 6 additions (fixed in 91c36b7, not deferred): the never-tagged manifest-floor HIGH, the missing semver-greater tool for arithmetic the hard rules say must never be guessed, dates-match absent from the usage banner, and a factual error in the skill's own rationale (git show-ref --tags -d exits 1 with zero tags, not 0 as claimed).

Still open and newly added from run 6:

• latest-eligible uniqueness is prose-only. A declared file with two rows both setting latest-eligible: true parses fine — list-targets returns both, exit 0. The skill documents badge-theft as a measured real-world failure in this repo, so the only thing preventing it is an agent remembering prose at Phase 3. Parser enforcement is a mechanism change with its own blast radius, hence filed rather than batched.
• Back-fill step 3 tells you to commit on a branch the hard rules forbid. It says commit "on the current branch"; Pre-flight's non-default-branch check runs after. On a fresh consumer the current branch is the default branch. (Related to, but distinct from, the ordering item already filed above — this is the direct rule conflict, not just sequencing.)
• [NEEDS-TRIAGE] lines have a specified shape but no producer and no ordering rule. Each run has emitted them in a different order.
• Unspecified: the release commit's own type/message, and the working directory pre-tag commands run in.
• Nothing creates .codearbiter/ before back-fill's write — it works only as a side effect of the marker mkdir -p, so an operator who correctly observes no write-guards are active in a fresh consumer and skips the marker dance hits a failed write.

Open design question from the floor fix: should a fresh project whose manifest reads 1.0.0 (the npm init default) with commits since take its first release as 1.0.0 or 1.1.0? The fix derives 1.1.0 — defensible, since there are commits the manifest predates — but it is a judgment call, not a derivation.

[SUaDtL]

Run 7 additions

Run 7 found a HIGH caused by run 6's fix (tagged project + leading manifest → derived off the tag alone → hard-blocked by its own manifest floor, with no remedy stated). Fixed in c46090d by collapsing the two floors into a single $BASE_VERSION. Three MEDIUMs from that run were fixed in the same commit: the unrunnable <none> comparison, the JSON-only manifest reader, and the unstated max-vs-first-manifest coupling.

Two LOWs remain open here:

• The back-fill lane leaves an empty .codearbiter/.markers/ directory. It mints release-targets-authoring and removes the marker file, not the directory. Harmless (git ignores empty directories) but it is litter the lane creates and does not clean up.
• The default-branch fallback's failure is invisible to $?. git symbolic-ref refs/remotes/origin/HEAD --short 2>/dev/null | sed 's@^origin/@@' prints nothing and the pipeline exits 0, because the status is sed's. The prose's instruction ("or ask the user if that resolves to nothing") is correct and covers it, so this is cosmetic — but an operator checking the exit code sees success where there was none.

Also worth recording against the back-fill items already open above: run 7 independently confirmed backfill-detect proposes [app] for a package named freshly, and that the operator gets that generic name unless they edit the block.

[SUaDtL]

Run 8 — no HIGHs, campaign stopped here

Run 8 probed the same region run 7's fix rewrote (version derivation) and returned no HIGH. That was the stated stopping condition. Final HIGH sequence across eight runs: 4 → 2 → 0 → 2 → 1 → 1 → 1 → 0.

Its MEDIUMs are filed here rather than fixed, because fixing any of them edits the skill and invalidates the recorded agent-judgment proof. Two of them are genuinely sharp:

$BASE_VERSION is defined as a MAXIMUM but no command computes it. This is the same defect class the semver-greater subcommand was added to close, one level up: the comparison now has a tested helper, but the max it compares against is still taken by hand, and so is stripping the prefix off LAST_TAG (_bare_version exists in the module with no CLI subcommand). The hard rules say the version MUST NOT be guessed. On the two-manifest fixture the agent took max(2.0.0, 2.3.1) by eye and only afterwards confirmed it pairwise with semver-greater — which the prose never tells anyone to do.

Phase 1 step 6's write side names no command, and for TOML no stdlib one exists. The read side now names a parser per format, but "update every path in $MANIFEST to the derived version" names nothing. tomllib is read-only and Python ships no TOML writer, so the agent hand-rolled a string replace on version = "2.3.1" — precisely the "typed" edit the step's own heading forbids ("mechanically derived, never typed"), on the one format the prose explicitly anticipates.

The first-release window re-publishes already-changelogged entries. With LAST_TAG=<none> the window is full history, so a feat whose footer already appears under an existing ## [1.4.0] section was rolled verbatim into the new ## [1.5.0] section. The prose handles the version overlap via the $BASE_VERSION maximum but says nothing about the content overlap, and nothing instructs trimming entries already present in $CHANGELOG. This produces a wrong changelog, not a wrong tag — which is why it is MEDIUM — and it lands on the back-fill population specifically.

The non-HEAD footer remedy has no non-interactive form. Step 3 names git commit --amend for HEAD and "an interactive rebase onto it" otherwise, and offers nothing else. The amend path works exactly as written.

No instruction for a consumer with no test suite. The hard rule is "MUST NOT tag on a red suite — commit-gate enforces green on every commit reaching HEAD." A plain project has neither, and the prose does not address that state.

commit-gate is required twice in a lane built for consumers that lack it. Already filed above; run 8 sharpens it to the internal tension rather than the mere unavailability — the back-fill lane's stated purpose is letting a release-only consumer skip onboarding, yet both of its mandatory commits route through a full governance skill such a consumer does not have.

LOWs: <tag_exists> is the one classify argument with no emitting command (the prose does state the inference); the composed ## [X.Y.Z] — DATE heading uses an em dash the surrounding Keep-a-Changelog file does not, producing style drift inside one file; and the TOML reader hardcodes PEP 621 layout, so [tool.poetry] raises KeyError.

[SUaDtL]

Priority note for whoever picks these up. The two sharpest items above — $BASE_VERSION being defined as a MAXIMUM with no command computing it, and Phase 1 step 6's write side naming no command (with no stdlib TOML writer, forcing the "typed" edit its own heading forbids) — are both in version derivation, which is where runs 6 and 7 each found a HIGH.

They are the same defect class as the one semver-greater was added to close, one level up and one level down: the comparison got a tested helper, the maximum it compares against and the write that follows it did not.

Expect a re-run, not a quick prose patch. Editing the skill invalidates the recorded agent-judgment proof and fails ca's pre-tag gate until a fresh blind exercise is run — which is deliberate, and in this region specifically the history says it earns its cost: three of the campaign's HIGHs were introduced by remediation of an earlier HIGH, and two of those three were here.

[SUaDtL]

Run 9 — the pre-tag runner slice

Two HIGHs, both remediated in f870652 (the pristine-tree assertion that blocked every release, and run-pre-tag executing in the inherited cwd). The MEDIUMs and LOWs below are filed, not fixed.

$BASE_VERSION is a max-of-N with no helper. Pre-flight defines it as the maximum of the tag version and the highest version across every declared manifest, and flags that as load-bearing — citing two runs where getting it wrong walked a version backward or hard-blocked a legitimate release. The CLI ships semver-greater (pairwise) but no semver-max, and the prose names no command for the maximum. On a single-manifest row it is trivial; on the multi-manifest row the prose explicitly warns about, it is hand arithmetic against a hard rule saying the version MUST NOT be guessed. This is the same gap already filed above for $BASE_VERSION, now confirmed by a second independent run.

run-pre-tag leaves the mutation it blocked on in place. After an exit 6, the offending file is still written. The runner's message now tells the operator to revert those paths, but the command does not undo them itself, so a naive re-run sees them as part of the release's own edits.

Declared commands run through cmd.exe on Windows, and nothing says so. subprocess.run(command, shell=True) resolves COMSPEC. Every shell snippet the skill itself writes is POSIX (if [ "$LAST_TAG" = "<none>" ]), so an operator authoring a pre-tag value in the same idiom (test -f dist/bundle.js) gets a portable-looking declaration that passes on Linux and fails on Windows. $PRE_TAG is described only as "check-only commands run in declared order" — there is no stated shell contract.

A pre-tag command may write freely into gitignored paths (LOW). git status --porcelain excludes ignored paths by default, so a command writing into build/ with build/ in .gitignore exits 0 and the runner continues — the check-only rule is unenforced there. Bounded: ignored files cannot reach a release, and committed $ARTIFACTS are tracked and therefore still covered.

A long-but-legal prefix fails at git tag after the bump is already committed (LOW). A 900-char prefix sits under the 1024 cap, resolves fine through tag-prefix, and then fails with Filename too long, exit 128 — after Phase 1 has bumped the manifest, rolled the changelog, and committed both. Nobody sane declares that; what is non-cosmetic is the position of the failure.

ValueTooLongError is undocumented in the file the skill cites as the parser contract (LOW). _releaselib.py's module docstring enumerates twelve exception subclasses and omits this one; SKILL.md mentions no length limit at all. The runtime message is clear — the contract doc simply does not mention the rule.

Cosmetic path formatting in the parse error (LOW): mixed forward and back slashes, doubled by repr.

[SUaDtL]

Run 10 — the pre-tag runner, exercised straight through

Two HIGHs, both remediated in eb94af1: step 7's conditional wording letting a literal traversal tag an uncommitted tree, and the mutation assertion comparing porcelain lines (so a command mutating an already-M $CHANGELOG/$MANIFEST exited 0 undetected). The rest are filed here.

No Phase-1 step ever updates a non-manifest version surface. generate is scoped to $GENERATED_MANIFEST only. So a badge or catalog pre-tag check — the exact use case the skill names for pre-tag ("a version or count badge, a catalog table, anything else that must track the tag") — must fail on the first pass of every release, permanently, because the value it tracks does not exist until step 4 derives it. The skill says what asserts these surfaces and never who updates them.

The prescribed exit-5 remedy commits a state where the target's own declared check is red. Verified: at the sanctioned "commit the reconciliation alone" commit, the badge check exits 1. If that check also runs in CI, the remedy pushes a red commit by design.

"Discard this run's uncommitted release edits" names no command and no scope, and the paragraph puts reconcile before discard — so a blanket git checkout -- . or git reset --hard, equally consistent with the words, destroys the reconciliation the previous sentence just told the operator to make. A path-scoped discard is the safe reading; the prose does not say so.

Exit 6 has no remedy in the skill. Exit 5 gets a full paragraph; exit 6 appears only in a code list, with its recovery text living solely in the tool's stderr. Phase 1's gate wording ("any pre-tag check fails") also does not describe exit 6, which is a check that passed while misbehaving. (The gate wording is fixed in eb94af1; the missing remedy paragraph is not.)

Windows: a POSIX-idiom pre-tag command is reported as drift. subprocess.run(..., shell=True) uses cmd.exe. A command like [ "$(python3 -c "print('x')")" = "x" ] exits 1 under the host shell and surfaces as exit 5, "a command reported drift" — but there is no drift and nothing to reconcile; the check never ran. No exit code distinguishes "not runnable", so the prescribed remedy (reconcile → discard → commit → re-run) cannot terminate.

commit-gate is required at three points and does not exist in a fresh consumer (back-fill step 3, Phase 1 step 7, the exit-5 reconciliation). Also unspecified: the release commit's own type and message convention, which must be non-bumping or the next window inflates — the skill states that requirement only for the back-fill lane's commit, not this one.

LOW: run-pre-tag prints nothing when a row declares no commands, so a log cannot distinguish "declared none" from "ran and passed" — against the skill's own Phase-3 principle that a skipped step must never look like a forgotten one. And <tag_exists> remains the one classify argument with no producing command.

[SUaDtL]

Run 11 — four consumers, Pre-flight to just-before-publish

One HIGH (the exit-6 remedy: non-terminating, destroys the composed section, and inexecutable on a first release) — remediated in 26ad016 along with the A-5.5 first-release floor and the A-3.6 interpreter fallback. The MEDIUMs below are filed.

The two BLOCK-level Phase-1 checks have no command behind them. Every other mechanical step in the lane now has a tested helper — list-targets, tag-prefix, last-tag, semver-greater, dates-match, notes-match, peel-tag, classify, run-pre-tag, adoption-commit. Step 2's Conventional-Commits classification and step 3's footer scan are still hand-rolled, and step 3 is the one the hard rules single out as MUST-level. The exercising agent's parse was subject.split('(')[0].split(':')[0].rstrip('!') — its own reading of the grammar. feat!: versus feat(scope)!: versus a bare BREAKING CHANGE: footer would each be handled by whatever the operator happens to write, so two operators produce two different gates on the check that decides whether a release may proceed. This is the largest remaining prose-arithmetic surface in the lane and the natural next deterministic-helper candidate.

The exit-5 discard mechanism is still unnamed. The skill explains at length why to discard (version floor, stranded section) and never how. Same untracked-changelog hole the exit-6 fix just closed: on a first release the obvious command cannot touch the file it needs to. The exit-6 remedy now spells this out; exit 5's does not.

No Conventional type is specified for the commits the lane itself creates. Step 7's release commit and the exit-5 reconciliation commit both need a type the prose never states. Under a payload: src/-style row it doesn't matter, but backfill-detect emits payload: ., where every lane-authored commit is in-window and the chosen type directly determines the next release's bump.

Pre-flight's default-branch fallback dead-ends when unattended. git symbolic-ref refs/remotes/origin/HEAD --short prints nothing with no remote — the exact state of a fresh consumer — and the prose then says to ask the user. Under an autonomous invocation there is nobody to ask, and the rule it feeds ("HEAD MUST NOT be the default branch") is a hard rule, so a guessed answer makes a guessed gate.

LOW: <tag_exists> remains the one classify argument with no producing command — and it is the argument that short-circuits three of the others.

Verified working this run

Mechanical target resolution beating a bare git describe (which resolved to a decoy sibling series' tag); payload scoping excluding an out-of-payload docs: commit; $BASE_VERSION as a maximum; run-pre-tag's digest-based mutation detection catching both an already-modified file and an untracked one; exit 0 on a zero-command row even with a dirty tree; --cleanup=verbatim storing byte-identical content while the default cleanup destroyed every heading; notes-match against raw git cat-file tag output; the step-3-before-step-4 reordering leaving the manifest provably byte-unchanged at a BLOCK; and the exit-5 recovery converging on the same derived version rather than drifting upward.

Explicitly not covered by that run

Multi-manifest rows — so the "first declared manifest" vs "maximum across all" asymmetry the skill devotes a paragraph to is untested, not passed. Also generated-manifest/generate, artifacts/rebuild, the Back-fill lane, and all of Phase 3.

[SUaDtL]

Run 13 — no HIGHs; the recorded proof

First clean run since run 8, and the first to exercise every fix from runs 9–12 together. The agent's own verdict: "Nothing rated HIGH. Every hard block I hit was a correct block, and every guard the skill names fired where it said it would." Its MEDIUMs and LOWs are filed below.

<summary> has no major branch. The Phase-3 title rule reads: first bullet under ### Added if the window bumped minor, otherwise the first bullet under ### Fixed. A window that bumps major is not-minor, so a literal traversal falls to Fixed — and run 13's 2.0.0 release, whose headline was two breaking feats, would have been titled "Tick indices start at zero". Wrong title, not a wrong release.

Nothing in the composed section says "breaking". Step 5 groups purely on type, so feat! lands under Added and a fix carrying BREAKING CHANGE: lands under Fixed. There is no Breaking group and no marker anywhere. The actual shipped 2.0.0 section reads as an ordinary feature release — and that same text is the changelog, the tag message, and the Release notes. The ! markers that forced the major bump are invisible in every user-facing artifact the lane produces.

The per-commit classification the skill twice requires has no command. Step 4 says present "the version and the per-commit classification"; Phase 2 step 2 repeats it. classify-window prints only the aggregate bump plus [NEEDS-TRIAGE] lines. classify_commit is public API with no CLI subcommand, so the agent ran classify-window once per commit as a workaround — the exact hand-parsing the run-11 note warns against.

commands/release.md has drifted badly from the skill, and it is the surface an operator hits first. Zero mentions of release-targets or $TARGET; it documents <version> / --auto / --dry-run arguments that appear zero times in SKILL.md; and it states LAST_TAG is "the newest ca SemVer tag (v*)" for "the ca plugin only" — a bare-prefix rule the skill explicitly forbids, describing a single-target design the multi-target skill replaced. Not HIGH because the skill wins the moment you reach Pre-flight, but an operator typing /ca:release 2.0.0 --dry-run lands in a skill with no such argument.

The two writes are the only unguarded steps in a guarded lane. Everything that decides now has a tested helper; writing the changelog section and writing the manifest version are left to whatever the operator invents. check-manifests catches a wrong version afterward, but nothing catches a regex that mangled the file's shape while landing the right string, and nothing checks the changelog insert at all. Together with $BASE_VERSION's missing semver-max and the bump arithmetic, that is the remaining hand-done set.

LOW: the first-release changelog covers only the floored window (2 of 9 commits in the fixture) — defensible, since $ADOPTED is the changelog baseline, but "first release" reads like it should summarize the project. A first release also cannot ship the version its manifest already declares, since the bump must be strictly greater than $BASE_VERSION. And step 5's heading template uses an em dash in the same sentence that routes entry prose through the anti-slop no-em-dash rule.

Confirmed working, measured rather than assumed

All three breaking spellings (feat!, feat(api)!, BREAKING CHANGE: footer) → major through one helper. check-manifests caught the deliberately partial two-manifest bump at step 6 and is confirmed to be the only thing that does — continuing past it, classify returned publish_fresh on the same disagreement, exactly as the run-12 correction states. --cleanup=verbatim round-tripped byte-identical while the default-cleanup counterfactual destroyed every heading and notes-match caught it. The <none> sentinel, the zero-tag show-ref | peel-tag pipeline, and the "$TAG_SHA" quoting rule all reproduced as documented. run-pre-tag correctly no-ops on a row with no declared commands.