Issue-verify — close issues from evidence, not narration

An issue is a CLAIM; closing it is BELIEVING the claim. The kernel's one rule, aimed at the tracker: never set a belief bit from what anyone says — set it from a read-back the claimant didn't author. This skill is the dos-witness-claim pattern pointed at GitHub issues: extract the checkable effects, witness each on the right rung, stamp the fold with the kernel's admission verdict, and only then actuate the close. Worked example: #1 — two env-authored witnesses (a green Actions run conclusion + the TestPyPI registry's own JSON), one non-recurrence triage, one dos reward … → ACCEPT, one evidenced close.

Layering. Dev tooling that operates ON the repo (the /release tier) — it names a vendor (gh/GitHub), so it lives in .claude/skills/, never src/dos/skills/ (a shipped SKP skill names no vendor or host). If the screenplay proves out, the promotion path is the usual lift: parameterize the tracker, move the shape into the SKP.

Public-repo note. Every comment this skill posts is a public document — no dev-machine paths, hostnames, or private-process prose (the route-privacy-at-authoring-time rule applies to issue comments too).

The disciplines (the JUDGE-rung hedges, applied to triage):

• Deterministic-first — a witness is a command output or a registry

read-back, never your impression of the thread.

• Fail-to-abstain — a witness you cannot gather (command errors, endpoint

down, no witness exists for the claim) is none, NEVER confirm. No close without a confirming witness.

• Forgeable ⇒ structurally ignored — a "fixed!" comment, a commit

subject, a > **Status:** line are claimant-authored bytes: they may select which witness to gather, never BE the witness. If the best you have is forgeable, pass --forgeable to dos reward and watch it ABSTAIN — that is the structure working, not a gap.

• Advisory until the one actuation — read-only throughout; the single

mutation is the close + its evidence comment. Never edit an issue body, never delete, never close on a REJECT or ABSTAIN fold.

When NOT to use the manual close at all: if the resolving fix is a commit you are about to land in this repo, put Fixes #N in the commit body and let the merge close the issue — the tracker then records the closing commit as the witness (the repo's issues-workflow convention). This skill's manual close is for the other three cases: a fix that already landed without the reference, a fix that lives outside this repo's git (an external service's config — the #1 case), or an issue dissolved by an environment change.

Step 1: Snapshot the claim

gh issue view <N> --json number,title,body,state,createdAt,comments

• state: CLOSED → idempotent: report "already closed", stop.
• --sweep → gh issue list --state open --json number,title and run Steps

1–5 per issue; render one verdict row each; actuate only the ACCEPTs.

Step 2: Extract the checkable effects

From the body (and any proposed fix in it), enumerate the EFFECTS that would be true iff the issue is resolved — each as {claim, rung, gather-command}. If the body proposes a fix, the compound claim is "that fix was applied AND the failure mode no longer reproduces." Pick each claim's witness rung:

Step 3: Gather the witnesses

Run each gather-command and record the raw fact (run ID + conclusion, SHA + ancestry bit, registry field + timestamp). A command that errors or returns ambiguity records none for that claim — fail-to-abstain, do not retry your way to a confirm.

Step 4: The non-recurrence check (newest evidence wins)

A confirming witness older than the latest contrary signal proves nothing. Search for the failure signature in evidence newer than the claimed fix (later runs of the same workflow, later issue comments, later commits):

• Same defect recurring → the fix did not hold → the fold is refute.
• A different defect in the same surface → note it explicitly in the close

comment ("not a recurrence — distinct failure, distinct issue") and, if it matters, open/point to its own issue. Do not let an unrelated red block a witnessed close, and do not let a witnessed close bury an unrelated red. (#1's worked example: the later publish.yml failure was the CI-green gate refusing a red candidate — the TestPyPI leg was skipped, not failed.)

Step 5: Fold and stamp the verdict

Fold the per-claim witnesses (ALL must confirm to accept — conjunctive, like every kernel floor), then stamp the fold with the kernel's admission verdict:

dos reward --claim --witness confirm    # every claim witnessed-confirmed → ACCEPT
dos reward --claim --witness refute     # any claim witnessed-refuted     → REJECT_POISON
dos reward --claim --witness none       # any claim unwitnessable         → ABSTAIN
# only-forgeable evidence? add --forgeable and it ABSTAINs by construction

Step 6: Actuate (skip on --dry-run — print the would-be comment instead)

Only on ACCEPT, one mutation:

gh issue close <N> --comment "<evidence comment>"

The comment is the artifact — it must let a future reader re-derive the verdict without trusting you. Shape (the #1 close is the reference rendering):

Verified resolved — adjudicated the DOS way: the claim is corroborated by
read-backs the claimant didn't author, not by narration.

**Witness 1 — <rung>.** <the raw fact, with run-ID / SHA / URL>
**Witness 2 — <rung>.** <…one block per claim…>

Kernel verdict: `dos reward --claim --witness confirm` → **ACCEPT**.
<one line on WHY this rung and not another, if non-obvious>

<non-recurrence note: what newer evidence was checked, and why any later
failure is a distinct defect, with its pointer>

On REJECT_POISON, the same shape with the refuting witness and no close. On ABSTAIN, no comment by default — report to the operator instead (a public "couldn't verify" comment adds noise, not evidence).

Step 7: Report

• Per issue: `#N — ACCEPT (closed) / REJECT_POISON (left open: <refuting

fact>) / ABSTAIN (left open: <missing witness>)`.

• Any non-recurrence findings that deserve their own issue.
• On --sweep: the verdict table, plus how many opens were not adjudicated

and why.