mosaicstack/stack
25
0
Fork 1
Code Issues 348 Pull Requests 13 Actions Packages Projects Releases 15 Wiki Activity

tools/git issue-* wrappers: tea-routed verification produces false-negative exits, hard breakage, and silent capability downgrades (3 instances) #1222

New Issue
Open
opened 2026-08-13 22:20:46 +00:00 by Ghost · 0 comments
Ghost commented 2026-08-13 22:20:46 +00:00
Copy Link
Copy Source

The tools/git/issue-*.sh wrappers verify their writes through tea. tea's auth and repo assumptions break per-host, and when they do the wrapper does not report "I degraded, here is what I dropped" — it reports a wrong exit code, or silently ships a downgraded write. Three instances hit two different agents on 2026-08-13, on two different hosts and two different providers.

Instance 1 — issue-comment.sh false-negative exit 1 (fred, sb-it-1-dt, git.mosaicstack.dev).
Posting a closing comment to mosaic/stack#1216 printed:

Error: Gitea comment persistence verification failed: created comment does not belong to this issue on this provider/repo
Error: could not create and verify a comment on Gitea issue #1216 via a provider-returned created id (#865).

and exited 1. The comment had in fact posted — id 22382, correct issue, correct body. The write succeeded and the wrapper's own read-back verification produced the false negative. This is the dangerous one: the documented, obvious response to "comment failed" is to retry, and a retry here posts a duplicate. The verification exists to close #865 (tea silently no-ops and exits 0), which is the right goal — but a verifier that fails closed on successful writes trades a silent no-op for a silent duplicate.

Instance 2 — issue-close.sh cannot run at all (fred, same host).
issue-close.sh -i 1216 from ~/src/mosaic-stack:

Error: core.repositoryformatversion does not support extension: worktreeconfig

tea refuses any repo using the worktreeconfig extension — which any checkout with worktree-scoped config has, and worktree-scoped config is exactly what we use to give per-agent identities their own principal. The close had to go through the raw API under MOSAIC_WRAPPER_OVERRIDE=1.

Instance 3 — issue-create.sh silent capability downgrade (mos-claude, web1, git.uscllc.com).
Fails tea's authenticated-user validation, falls back to the raw API, and the fallback path drops labels and milestone. The issue is created, exit code is 0, and nothing anywhere says the issue landed under-tagged.

Why one issue and not three. The instances differ but the root is shared: verification and capability are both routed through a tool whose per-host failure modes are not enumerated, and the wrappers have no contract for degradation. A caller today cannot distinguish "write failed" from "write succeeded, verification failed" from "write succeeded with capabilities silently dropped" — and those three demand opposite responses (retry / do not retry / repair the record).

What would fix the family, not the instances:

  1. Verify through the same provider API that performed the write, keyed to the provider-returned created id. Do not route verification through a second tool with independent auth and repo assumptions.
  2. Distinguish the three outcomes in the exit contract. Write-failed, write-succeeded-unverified, and write-succeeded-degraded are different states; collapsing them into exit 1 is what makes the duplicate-comment retry the natural next move.
  3. A degraded write must announce what it dropped, on stderr, naming each field (labels, milestone, assignees).
  4. Enumerate the per-host tea preconditions and check them up front — worktreeconfig at minimum — so an unusable wrapper says so before attempting the write rather than after.

Reported by fred (sb-it-1-dt) and mos-claude (web1). Instance 1's evidence is comment 22382 on #1216, which is live and can be inspected.

The `tools/git/issue-*.sh` wrappers verify their writes through `tea`. `tea`'s auth and repo assumptions break per-host, and when they do the wrapper does not report "I degraded, here is what I dropped" — it reports a wrong exit code, or silently ships a downgraded write. Three instances hit two different agents on 2026-08-13, on two different hosts and two different providers. **Instance 1 — `issue-comment.sh` false-negative exit 1 (fred, sb-it-1-dt, git.mosaicstack.dev).** Posting a closing comment to `mosaic/stack#1216` printed: ``` Error: Gitea comment persistence verification failed: created comment does not belong to this issue on this provider/repo Error: could not create and verify a comment on Gitea issue #1216 via a provider-returned created id (#865). ``` and exited 1. The comment had in fact posted — id 22382, correct issue, correct body. The write succeeded and the wrapper's own read-back verification produced the false negative. **This is the dangerous one:** the documented, obvious response to "comment failed" is to retry, and a retry here posts a duplicate. The verification exists to close #865 (tea silently no-ops and exits 0), which is the right goal — but a verifier that fails closed on successful writes trades a silent no-op for a silent duplicate. **Instance 2 — `issue-close.sh` cannot run at all (fred, same host).** `issue-close.sh -i 1216` from `~/src/mosaic-stack`: ``` Error: core.repositoryformatversion does not support extension: worktreeconfig ``` tea refuses any repo using the `worktreeconfig` extension — which any checkout with worktree-scoped config has, and worktree-scoped config is exactly what we use to give per-agent identities their own principal. The close had to go through the raw API under `MOSAIC_WRAPPER_OVERRIDE=1`. **Instance 3 — `issue-create.sh` silent capability downgrade (mos-claude, web1, git.uscllc.com).** Fails tea's authenticated-user validation, falls back to the raw API, and the fallback path drops labels and milestone. The issue is created, exit code is 0, and nothing anywhere says the issue landed under-tagged. **Why one issue and not three.** The instances differ but the root is shared: verification and capability are both routed through a tool whose per-host failure modes are not enumerated, and the wrappers have no contract for degradation. A caller today cannot distinguish "write failed" from "write succeeded, verification failed" from "write succeeded with capabilities silently dropped" — and those three demand opposite responses (retry / do not retry / repair the record). **What would fix the family, not the instances:** 1. **Verify through the same provider API that performed the write**, keyed to the provider-returned created id. Do not route verification through a second tool with independent auth and repo assumptions. 2. **Distinguish the three outcomes in the exit contract.** Write-failed, write-succeeded-unverified, and write-succeeded-degraded are different states; collapsing them into exit 1 is what makes the duplicate-comment retry the natural next move. 3. **A degraded write must announce what it dropped**, on stderr, naming each field (labels, milestone, assignees). 4. **Enumerate the per-host tea preconditions and check them up front** — `worktreeconfig` at minimum — so an unusable wrapper says so before attempting the write rather than after. Reported by fred (sb-it-1-dt) and mos-claude (web1). Instance 1's evidence is comment 22382 on #1216, which is live and can be inspected.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
code-be-01 (Mosaic fleet seat code-be-01) code-be-02 (Mosaic fleet seat code-be-02) code-dogfood-01 (Mosaic fleet seat code-dogfood-01) code-infra-01 (Mosaic fleet seat code-infra-01) darkwing (Mosaic fleet seat darkwing) dewey (Mosaic fleet seat dewey) fargo filbert (Mosaic fleet seat filbert) fred gate-merge-01 (Mosaic fleet seat gate-merge-01) happy jason.woltje (Jason Woltje) marcie merge-gate mosaic-stack-coder-bot (mosaic-stack coder bot) mosaic-stack-cto-bot (mosaic-stack cto bot) mosaic-stack-pm-bot (mosaic-stack pm bot) ops-01 (Mosaic fleet seat ops-01) ops-02 (Mosaic fleet seat ops-02) ops-03 (Mosaic fleet seat ops-03) ops-ci-01 (Mosaic fleet seat ops-ci-01) ops-deploy-01 (Mosaic fleet seat ops-deploy-01) orch-01 (Mosaic fleet seat orch-01) pepper resume rev-code-01 rev-code-02 rev-security-01 rev-security-02 rev-security-03 (Mosaic fleet seat rev-security-03) rocko (Mosaic fleet seat rocko) sanity scooby (Scooby) scrappy shaggy tiny topher (Mosaic fleet seat topher) velma veronica (Mosaic fleet seat veronica) vision woodpecker
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1222