Fix #71: resync the .agent mirror issue layer; add a parity guard

[laird]

Closes #71

Problem

CLAUDE.md declares mirror parity CRITICAL, but nothing enforced it, and the issue layer under .agent/scripts/ drifted badly from plugins/autocoder/scripts/.

The drift was not cosmetic. .agent/workflows/fix.md calls three verbs its own issue-fns.sh never defined:

verb	called at
issue_any_claimable	fix.md:320
issue_claim	fix.md:532, fix.md:648
issue_release	fix.md:575, fix.md:681, fix.md:1479

The preflight at fix.md:319-323 branches on issue_any_claimable's exit status. An undefined function exits 127, which falls to the *) arm — "Backend error while checking for claimable issues"; exit 1.

So the Antigravity /fix was not running in a degraded mode. It terminated at its first check on every single invocation.

Two further breaks

• --state blocked was forwarded straight to gh issue list, which rejects anything outside {open,closed,all}. The mirror's stale issues-file.py rejected it too. Both list-needs-feedback.md and approve-proposal.md depend on that state.
• The inline _ifns_gh_list applied no blocking-label filter at all, so list --state open did not mean "claimable" as the 9-verb contract requires. (It never had issues-gh.sh list uses invalid no:label search syntax — autonomous loop sees zero issues #57's no:label bug because it had no filter whatsoever.)

Extent

file	before
issues-gh.sh	absent entirely
issues-file.py	438 differing lines; last touched 2026-05-19; no claim/release/any-claimable; 3 bucket refs vs 30
issue-fns.sh	180 differing lines (inline impl vs dispatcher)
issue-config.sh	4 differing lines

Solution

Sync all four shared files forward from the maintained plugins copy — which already implements the full contract the mirror's own workflows assume. Verified nothing outside issue-fns.sh referenced the removed inline internals (_ifns_gh_*, _ifns_file), so there are no orphaned callers.

Guard against recurrence

New tests/test_agent_mirror_parity.sh asserts:

1. the mirror ships every shared file,
2. each is byte-identical across mirrors,
3. all 9 contract verbs resolve on both sides,
4. --state blocked returns JSON rather than a gh usage error.

It runs in a throwaway git repo with a poisoned gh on PATH, so it cannot touch the real tracker — same pattern as test_issue_fns.sh after #58.

Verification

$ bash tests/test_agent_mirror_parity.sh
Results: 13 passed, 0 failed      # before the fix: 6 passed, 7 failed

Replaying the fix.md preflight against the mirror:

populated queue: preflight: work exists -> proceeds
empty queue:     preflight: no claimable work -> clean exit 0

Previously both landed on the backend-error branch with rc=127.

Full suite 14/14 files green; bash -n across plugins, .agent, and tests clean; py_compile clean on both issues-file.py copies.

Out of scope, noted

.agent/workflows/fix.md.backup and fix-loop.md.backup are stale editor backups committed to git.

🤖 Generated with Claude Code

[laird]

⚠️ Base branch check — this PR targets master, not the integration branch

Flagging before merge; not retargeting it, since master and feat/autocoder-planning-pipeline have diverged (#30 records 11 conflicts), so changing the base here would produce a conflicted diff rather than the intended 5-file change.

Per CLAUDE.md, the integration branch — and the ship branch that defines "shipped" for the #35 close gate — is feat/autocoder-planning-pipeline. This branch is based on master and does not contain it:

$ git merge-base --is-ancestor origin/feat/... origin/feature/issue-71   -> does NOT contain integration

$ bash plugins/autocoder/scripts/verify-shipped.sh $(git rev-parse origin/feature/issue-71)
NOT_SHIPPED: c714eb9 has not reached origin/feat/autocoder-planning-pipeline
PARKED_ON:origin/feature/issue-71

Merging as-is lands the work on master only, so the ship gate keeps returning NOT_SHIPPED and #71 can never be closed by the protocol. The swarm, which works on the integration line, also would not receive the fixed .agent/ mirror scripts.

Root cause and the two resolution options are written up in #76 — it's the stale installed autocoder plugin (3.10.0) still shipping the pre-rename /fix, which bases branches on whatever HEAD the worktree happens to sit on. Not a reflection on this change's contents.

[laird]

✅ Correction — retracting my previous comment. This PR's base is right.

I was wrong. master is the repo default branch and all 12 recent merged PRs target master — that is the swarm's actual convention, and this PR follows it.

My error: I ran verify-shipped.sh from a worktree sitting on feat/autocoder-planning-pipeline. That script resolves the ship branch from the local worktree's CLAUDE.md (explicit arg > CLAUDE_CODE_SHIP_BRANCH > CLAUDE.md > repo default), and the integration branch's CLAUDE.md carries a **Ship branch**: feat/autocoder-planning-pipeline line. master's CLAUDE.md has no such line, so a master-based worktree resolves to the repo default — master. I reported a worktree-local answer as if it were universal.

Concretely: once this merges to master, it is shipped by the gate as any master-based worker resolves it. Nothing here blocks #71 from closing.

Sorry for the noise on your PR — no action needed from you. I've retitled #76 to the real (and much smaller) underlying issue: the ship-branch designation is worktree-dependent, and the integration branch's designation goes stale the moment #77 lands.

[laird]

This PR went CONFLICTING when #83 landed — here is a verified resolution

It was MERGEABLE/CLEAN earlier today; #83 (Jira + Azure DevOps backends) landed on master and now it is CONFLICTING/DIRTY. Reproduced locally against current master (a4cc38b).

Exactly one file conflicts: .agent/scripts/issue-fns.sh — one hunk, but a substantive one rather than a textual clash:

side	shape
master	large inline dispatcher — every verb a bash function, case $ISSUE_SOURCE covering github/file/jira/ado
this PR	thin delegating dispatcher — _ifns_BACKEND_BIN + all 9 verbs incl. issue_claim/issue_release/issue_any_claimable

Neither side is correct alone: this PR's version drops the jira/ado backends master just gained, and master's version lacks the three verbs this PR exists to add.

The resolution is simpler than it looks

plugins/autocoder/scripts/issue-fns.sh auto-merged cleanly into exactly the right shape — thin dispatcher plus jira/ado:

  github) _ifns_BACKEND_SCRIPT="issues-gh.sh"   ;;
  file)   _ifns_BACKEND_SCRIPT="issues-file.py" ;;
  jira)   _ifns_BACKEND_SCRIPT="issues-jira.sh" ;;
  ado)    _ifns_BACKEND_SCRIPT="issues-ado.sh"  ;;

So resolve .agent/scripts/issue-fns.sh by taking the plugins-side file verbatim. The mirrors must be byte-identical anyway — your own test_agent_mirror_parity.sh enforces it.

This works because all four backends already speak the same 9-verb CLI. Verified on master:

issues-jira.sh:  any-claimable claim close comment create get list release update
issues-ado.sh:   any-claimable claim close comment create get list release update
issues-gh.sh:    (added by this PR) same 9

Verified, not assumed

I first hand-wrote the two jira)/ado) lines into .agent and got 17 passed, 1 failed — test_agent_mirror_parity.sh: "issue-fns.sh diverged (4 differing lines)". The divergence was whitespace alignment only. Your parity test caught it, which is a good sign for the test. Copying the plugins file verbatim instead:

mirrors identical ✅
shell:  18 passed, 0 failed
pytest: 59 passed

Not applied

I have not pushed this to your branch — it is yours, and I have already learned this session what happens when I push to a PR I do not own. The change is one cp; happy to apply it if you would rather I did.

For reference, master itself is currently healthy: 17/17 shell, 59/59 pytest, BUILD_OK.

[laird]

Retargeted master → integration per #89's branch model.

Still CONFLICTING, and the base change does not fix it — I checked rather than assuming: feature/issue-71 conflicts with integration on the same single file it conflicted with against master, .agent/scripts/issue-fns.sh. So #87 is still required either way.

Once #87 merges into feature/issue-71, this goes clean — verified the full chain against current integration: #87 → feature/issue-71 → integration is 0 conflicts.

🤖 Autonomous fix workflow

[laird]

This PR is the root of a four-deep stack and is currently blocking two green PRs.

integration
  └── #74  feature/issue-71        ← CONFLICTING (here)
        └── #87  merge/issue-71-master     MERGEABLE
              └── #92  feature/issue-88    MERGEABLE

#87 and #92 both report MERGEABLE, but neither can land while this base is red. Merging #87 into feature/issue-71 clears the conflict — verified: #87 → feature/issue-71 → integration is 0 conflicts.

Suggested order: #87 → #92 → #74 → integration.

Related: #93 records that neither master nor integration is branch-protected, so nothing structurally prevents bypassing a stuck stack like this one.

🤖 Autonomous fix workflow