(claim): Green runs strand org-repo claims — author_association

[evanharmon1]

Invariant

When claim-release.yml reports success, the claim is actually released — or the job goes red. A green run must never leave the assignee and claim:* label in place, because nothing downstream re-checks a run that said it succeeded.

Current violation (observed 2026-08-16, first org-repo field failure)

ponderousdev/lawnomator-site#100 was closed COMPLETED by merging PR #110. claim-release.yml ran, concluded success, and left both markers on the issue:

assignees=evanharmon1  labels=claim:claude

The run log (31920664204) says:

ponderousdev/lawnomator-site#100 has no trusted claim comment — nothing to release

That is exit 3, which the workflow deliberately treats as benign ([ "$rc" -eq 0 ] || [ "$rc" -eq 3 ] || exit "$rc") — correct for a genuinely unclaimed issue, and exactly what makes this failure silent.

A trusted claim comment did exist, posted by the claimant:

author=evanharmon1  type=User  author_association=MEMBER  created=2026-08-15T21:38:07Z

…with a well-formed v1 claim record naming claim:claude and assignee added by this claim: yes.

The same script, with the workflow's exact flags, releases it correctly when run locally:

./.claude/skills/track-work/assets/release-claim.sh --repo ponderousdev/lawnomator-site --issue 100 \
  --reason "issue closed (completed)" --not-after "2026-08-16T01:55:16Z" --require-closed --dry-run
# → DRY-RUN: gh issue edit ... --remove-label claim:claude
# → DRY-RUN: gh issue edit ... --remove-assignee evanharmon1
# → ponderousdev/lawnomator-site#100: claim released      (exit 0)

Same file (.agents/skills/track-work is a symlink to .claude/skills/track-work; md5 173443cc0e059da4adf77132d5c396ba both). Same flags. Opposite verdict. The only difference is the token.

Root cause (strong hypothesis — the one thing I could not mint a token to prove)

The trust predicate requires write-shaped author_association:

def writeauth:
    (.author_association // "") as $a
    | (["OWNER", "MEMBER", "COLLABORATOR"] | index($a)) != null;

author_association is not absolute — GitHub computes it against what the requesting token may see. evanharmon1's membership in the ponderousdev org is private:

gh api orgs/ponderousdev/public_members/evanharmon1
# → HTTP 404: not a public member

A PAT with read:org therefore sees MEMBER (verified above). A bare secrets.GITHUB_TOKEN has no org-membership visibility, so it sees NONE, writeauth fails, the comment is filtered out, and the script correctly concludes there is no trusted claim.

On an org repo the owner prong (ponderousdev) never matches a user, so trust rests entirely on the assignee prong — and that prong is silently disarmed for every private org member. That is every claim this repo will ever make.

Relationship to #217

217 documents the org-repo trust gate stranding claims when the claimant is unassigned. This is a different trigger of the same gate: the claimant was a current assignee the whole time, and the trust still failed because the association degraded under the workflow's token

217's stated prerequisite — "an org repo actually adopting claim-release.yml" — is now met: ponderousdev/lawnomator-site has adopted it, and this is its first real close event. Distinct from #434 (markers with no claim record), since here the record is present and well-formed

Acceptance criteria

• Confirm the hypothesis by reading author_association for this comment from a workflow running under secrets.GITHUB_TOKEN (log it, don't infer it) — release-claim.sh now logs every distinct author_association value a run actually sees, one line, per PR fix(track-work): trust a self-assigned claimant in release-claim.sh #869
• Make the trust gate robust to token-dependent author_association — e.g. resolve membership/permission explicitly via repos/{owner}/{repo}/collaborators/{user}/permission, or grant the workflow the scope needed to see private membership, or trust durable evidence (assignee at claim time via timeline events) as (claim): Org-repo trust gate strands claims when the claimant is #217 suggests — PR fix(track-work): trust a self-assigned claimant in release-claim.sh #869 takes the timeline-evidence path
• Stop exit 3 from being indistinguishable from success when markers survive. A run that finds live claim:*/assignee markers but no trusted claim should not exit green and silent — that is what let this pass unnoticed — PR fix(track-work): trust a self-assigned claimant in release-claim.sh #869 adds a distinct exit 5
• Re-check every org repo that has adopted claim-release.yml for already-stranded claims — swept all 7 (lawnomator-site, ponderous-docs, ponderous-site, ponderous-infra, ponderous-content, foreman, omator) via PR fix(track-work): trust a self-assigned claimant in release-claim.sh #869; ponderousdev/omator#659 and #491 are currently stranded (reported for the maintainer to release by hand, not released by the sweep) and the other 6 are clean — see PR fix(track-work): trust a self-assigned claimant in release-claim.sh #869's body for the full report
• Cover it: a test where the claim author's association is not visible to the acting token — PR fix(track-work): trust a self-assigned claimant in release-claim.sh #869's AC1/AC2/AC3 test cases

Verify

# The predicate that filters the comment out:
grep -n -A3 "def writeauth" .claude/skills/track-work/assets/release-claim.sh

# Is the claimant's org membership private (so a bare GITHUB_TOKEN sees NONE)?
gh api orgs/<org>/public_members/<claimant> --silent && echo public || echo private

# The end-to-end symptom, on any org repo that adopted the workflow:
gh issue list --repo <org>/<repo> --state closed --label claim:claude --limit 50

Any closed issue still carrying claim:claude means claims are being stranded under green runs.

---

Found while shipping ponderousdev/lawnomator-site#100. That claim was released by hand; the underlying gate is unchanged.

[evanharmon1]

Fresh occurrence in ponderousdev/omator, with a side-by-side repro

Hit this today on a private org repo. Diagnosed it independently before finding
this issue, and landed on the same mechanism — recording the evidence since it
is a clean A/B.

Vendored ref: v0.29.0 (e6596fb), per .claude/skills/.SKILLS_PROVENANCE.

What happened

ponderousdev/omator#308 was claimed by evanharmon1 with a well-formed claim
comment, then auto-closed by merging its PR (#345). claim-release.yml fired on
the close and ran green:

run 31934537601 — on-issue-closed — success
ponderousdev/omator#308 has no trusted claim comment — nothing to release

The assignee was left in place on a closed, completed issue — the exact stranded
state /kickoff's sweep exists to catch.

The A/B

Same script, same repo, same issue, same comment — only the token differs.

Context	Auth	author_association seen	Result
claim-release.yml	workflow GH_TOKEN	(degraded — not write-shaped)	exit 3, "no trusted claim comment"
Local gh	evanharmon1 PAT	MEMBER	claim found, released cleanly

Local read of the very comment the workflow could not trust:

{"assoc":"MEMBER","first40":"Claiming — starting implementation on br","login":"evanharmon1"}

And the local dry run resolved it fully:

DRY-RUN: gh issue edit 308 --repo ponderousdev/omator --remove-assignee evanharmon1
ponderousdev/omator#308: claim released

So the claim comment's body grammar and authorship are both fine; the only
variable is what author_association the requesting token is shown. That is
this issue's diagnosis, confirmed from a second repo.

Why the failure is easy to miss

The workflow exits 0 and reads green. release-claim.sh treats exit 3 as
"benign, the common case", which is right for a genuinely unclaimed issue and
wrong here — an org-repo claim that can never be trusted is indistinguishable,
in the run summary, from no claim at all. Whatever the fix, it may be worth
making the org-repo trust failure say so distinctly rather than sharing the
benign exit code, so the next occurrence is visible without someone reading the
log line by line.

Workaround used

Ran release-claim.sh locally with a maintainer PAT; the claim released
correctly (assignee and label both clear now).

Refs ponderousdev/omator#308, ponderousdev/omator#345. Possibly related: #217.

[evanharmon1]

Second field occurrence, three for three, with the root cause narrowed.

ponderousdev/ponderous-site #82, #64, #63 were closed completed by merged PRs #87/#88/#89 on 2026-08-22. claim-release.yml ran on each close, concluded success, and each log reads ponderousdev/ponderous-site#6x has no trusted claim comment — nothing to release (runs 32590678465 / 32595479479 / 32599528482). Markers left: assignees=evanharmon1, and the Claiming — record comment unsuperseded (the claim:claude label had already been released by the shepherd stop, so only the assignee stranded).

Why the trusted-author check fails under the workflow token: the claimant is a current assignee, so the assignee prong matches — it is the writeauth prong that fails. evanharmon1 is a ponderousdev admin with a private org membership (orgs/ponderousdev/public_members/evanharmon1 → 404). author_association on a comment is computed relative to the requester's visibility: read with GITHUB_TOKEN, a private member's comment does not report MEMBER, so (["OWNER","MEMBER","COLLABORATOR"] | index($a)) is null and the comment is untrusted. Read as the user (gh OAuth), the same comment is MEMBER and release-claim.sh --dry-run resolves cleanly — which is how /wrap released all three by hand today.

So this is the same shape as #217's org-repo limitation but a different prong: not "no longer assigned", but "assigned, and the association is invisible to the token". It strands every claim in any org repo whose maintainers keep membership private, and the job is green each time.

Proposed fix (either closes the prong without admitting forged claims from read-only collaborators):

• establish write authority for the claim author via GET repos/{o}/{r}/collaborators/{login}/permission (admin/maintain/write) instead of author_association; or
• for the release read specifically, accept "author is a current assignee" as sufficient — assignment is itself a triage+ write and is already the claim's own marker.
  Plus: claim-release.yml should ::warning:: (not silently exit 3) when a Claiming — comment from a current assignee exists but fails trust.

Filed from the workflow side as evanharmon1/harmon-init#1033 before I found this issue — treat that as the consumer-workflow twin of this one.

[evanharmon1]

Second, independent stranding cause found on ponderousdev/omator (2026-09-08): #866 — release-claim.sh passes the issue timeline to jq --argjson on argv, and Linux runners fail single arguments over 128 KB with Argument list too long, so the run goes red and releases nothing. The two bugs stack: closes that escape the argument cap then hit this issue's trust gap and go green. Twelve claims stranded across both were released by hand on 2026-09-08.

[evanharmon1]

Claiming — starting implementation on branch fix/claim-trust-477 (session claim-trust-477).

Preflight (§3):

• credentials/scopes: ok — evanharmon1 via gh, issues:write on evanharmon1/harmon-devkit (already used to read/comment during this claim); no other external credential is implied by this fix (jq/shell-only change plus bats-style test additions).
• human/out-of-band steps: none — the fix, tests, and PR are all agent-executable; no maintainer-only dashboard/DNS/account step is implied.
• plan-vs-apply blind spots: the fixed trust predicate and new exit code are only exercised against fixture JSON in scripts/test-track-work.sh; the live-org "private membership" scenario from the issue (author_association degraded under a real GITHUB_TOKEN) cannot be reproduced in CI/local — the fixtures model it by setting author_association directly, which is the same shape gh api would return.
• stale references: none — release-claim.sh, its jq predicates near line 267, and scripts/test-track-work.sh's release-claim section were all read live in this checkout; .github/workflows/claim-release.yml already treats any exit other than 0/3 as a job failure, so no workflow edit is needed for the new distinct exit code.

Claim record (for /wrap — undo only what this claim added):

• harness: Claude Code
• model: claude-sonnet-5
• family: claude
• runtime environment: host
• session: claim-trust-477
• dispatched to: none
• assignee added by this claim: yes
• claim: label added by this claim: claim:claude
• claim: model label added by this claim: n/a
• claim: label displaced by this claim: none
• assignee logins owned by this claim chain: evanharmon1
• claim: label owned by this claim chain: claim:claude
• claim: model label owned by this claim chain: n/a
• claim: label displaced by this claim chain: none