…te their intent

Step 3's table gains a `#` key and a Reason column, and stays one line per
comment: what runs past a clause goes to a keyed expansion beneath it. A
`disagreed with` row is marked `(!)` — plain ASCII, so it reads the same in a
terminal as in GitHub's renderer — and its expansion is mandatory. A fix row's
one-clause statement of intent is written once and is the string Step 5 hands
the writer. Steps 4, 5 and 10 now render that one definition rather than
restating it, and the ledger comment carries it as the copy that outlives the
run.

AC 8 — live, read-only verification of the classification as written
====================================================================
Comments read through skills/dev-loop-pr-comments/read-comments.mjs. No `gh`
write of any kind, no worktree provisioned, no gate answered: this exercised
Step 3 only.

cli/cli#14007 — "Guard `pr merge --delete-branch` against worktree conflicts",
7 unresolved comments, all 7 classified. Supplied three of the four reasons:

- out of scope for this branch — babakks, pkg/cmd/pr/merge/merge.go:410,
  discussion_r3719732624 ("In a follow-up we can extract git commands used in
  `pr checkout --worktree`"). Evidence: the separate work is a follow-up
  extracting the git commands `pr checkout --worktree` runs so they can reuse
  this branch's `ToplevelDir` — the commenter names it a follow-up himself.

- already addressed — babakks, merge.go stale anchor 431 (outdated),
  discussion_r3719948135 ("**nitpick:** `len(worktrees)` is always `> 0`").
  Evidence: ea3d3191f "Simplify main-worktree head check, drop misleading len
  guard" drops the `len(worktrees) > 0 &&` conjunct the comment calls
  misleading; merge.go is its only file.
  Two more rows took the same reason: discussion_r3720203296 (same commit — its
  new `if` is that comment's suggestion block character for character) and
  copilot-pull-request-reviewer's review body pullrequestreview-4810038780,
  whose two stated grounds are both met by d7fe64365 "Handle head branch checked
  out in main worktree during pr merge cleanup" — it handles that case in
  `deleteLocalBranch` and adds `TestParseWorktrees` to git/client_test.go, the
  direct unit tests the review says are missing.

- disagreed with (!) — babakks, review body pullrequestreview-4863309209, the
  proposal to restructure `deleteLocalBranch` around "where is the head branch
  checked out". Evidence, in full, is the expansion; in short: the reviewer
  states in the same comment that the scenarios are already covered, so the
  restructure changes no behaviour, and rewriting the whole cleanup flow inside
  a pull request that exists to guard one command widens the blast radius of a
  bug fix. Declined outright rather than deferred, which is what separates it
  from the `out of scope` row above.

Two rows classified fix: discussion_r3719711480 (rename `Worktree.Branch` to
`Ref` at git/objects.go:82) and discussion_r3720001340 (return the errors from
`Worktrees` and `ToplevelDir` instead of discarding them — still `worktrees, _
:=` at head). More than one fix row, so a real run would stop at Step 4.

No comment on 14007 classified `question`: the one opening "**question:** why
can't we simplify this `if`-statement" carries a ```suggestion``` block, so it
asks for a change, and ea3d3191f made it — `already addressed`, above.

cli/cli#13948 — "Add issue field support to gh CLI" — supplied the fourth:

- question — zwick, pkg/cmd/issue/create/create.go:102,
  discussion_r3639448805. Evidence, verbatim: "Can I create an issue with
  multiple Issue Field Values?"

No comment across either pull request came back `unclassified`: every one fit an
intent, and every skip's evidence was produced.

Deviation: the changeset was hand-written at .changeset/142-skip-reasons.md
rather than generated with `npm run changeset`, which names files with a random
human-id. Every existing changeset here is named `<issue>-<slug>.md`.

§3a asserted that `gh pr diff` and the "Files changed" tab use merge-base
semantics. That was inference: the discriminating run I had done measured the
compare API only, and the repo's own history cannot test it -- every merged PR
here was cut from the then-current tip, so base == merge-base for all of them
(checked #379-#382).

Measured on a public PR 42 commits behind its base (cli/cli#13948):

    gh pr diff --name-only      -> 11 files
    pulls/:n/files endpoint     -> 11 files
    compare base...head         -> 11 files
    compare head...base         -> 33 files

The claim holds. The rule and the ledger now state the measurement rather than
the documented intent, per principle 0 -- a doc page states intent, only running
it reports behaviour.

check-invariants.sh: PASS, exit 0.

…rity regressions (#385)

* Intake the 2026-09-15 EDR field report: two adoptions, one correction, one rejection

A session applying the library on a private security product. Every falsifiable
claim was reproduced here before a verdict.

- sota-docs-workflow rules/03 gains §3a: two-dot `git diff main..pr` compares
  tips, so everything main gained after the fork renders as a deletion on the
  branch's side. The error is directional -- it only ever invents regressions, and
  in a lockfile that reads as a supply-chain attack. The reporter concluded a PR
  downgraded a TLS library past the previous day's advisory fix and wrote it into
  a commit message; the PR did not touch that dependency. Measured on a branch
  four commits behind its base: two-dot 15 files / 742 deletions, three-dot and
  the forge compare API zero. The rule adds why the habit survives -- `git log
  main..feature` is correct while `git diff main..feature` is not -- because
  without that the rule contradicts the reader's experience. Ships with its audit
  half.

- sota-secrets-management rules/04: a working-tree scan does not read .gitignore,
  so an untracked artifact invisible to `git status` is in scope for the gate.
  Verified on gitleaks 8.30.1 with a positive control, after a first attempt using
  the canonical AWS documentation key returned "no leaks found" and would have
  refuted a true finding.

- commands/sota-report.md: it told the agent to write the report into the target
  repo's root and justified that with a fact about THIS repo. Followed literally
  during a gate run it dirties the tree and feeds an unreviewed file to a secret
  scanner, which is what happened.

- The proposed sentence for sota/SKILL.md principle 0 is rejected and the
  reasoning recorded. The rule was loaded and broken, which is adherence, not
  coverage; the reporter themselves graded the wording medium-confidence. The
  router is the only file loaded every session and sits at 470/500.

Correction to the report: it says *.local.md is not ignored in the target repo.
It is, via .git/info/exclude:10. The load-bearing half -- that a directory
scanner never consults ignore status -- is untouched, but the framing invites the
wrong fix.

* Measure the gh pr diff claim instead of inferring it

§3a asserted that `gh pr diff` and the "Files changed" tab use merge-base
semantics. That was inference: the discriminating run I had done measured the
compare API only, and the repo's own history cannot test it -- every merged PR
here was cut from the then-current tip, so base == merge-base for all of them
(checked #379-#382).

Measured on a public PR 42 commits behind its base (cli/cli#13948):

    gh pr diff --name-only      -> 11 files
    pulls/:n/files endpoint     -> 11 files
    compare base...head         -> 11 files
    compare head...base         -> 33 files

The claim holds. The rule and the ledger now state the measurement rather than
the documented intent, per principle 0 -- a doc page states intent, only running
it reports behaviour.

check-invariants.sh: PASS, exit 0.