rdmsm4x-changelog-20260924-2213-audit-dedupe-inprogress-gap-fixed-estate-levelled

Run 2026-09-24 22:05:30 → 22:13:58 EDT on rdmsm4x by claude@rdmsm4x/dev-c5 (cli session 65c5e356), resuming on Rich's "resume all work" relayed by peer dev-c2. Timestamps from date. Budget hold — Anthropic 7d 93%, resets 2026-09-25 09:59:59 EDT. Worked inline, no subagents, no external spend. Touched nothing near TCC/FDA, xcode-select, or the herdr/ECSToolHost LaunchAgents, per dev-c2's in-flight FDA priming.

One line: the 2026-09-16 audit dedupe fix held for eight nights, its one remaining gap was found and closed, and the git estate was levelled again — 8 pushes, 5 fast-forwards, 0 failures.

1. The 09-16 fix held — eight nights of production evidence

fleet@e4513be repaired a dedupe lookup that had never once matched. The test is simply what the ticket store looks like eight nights later.

Measure	2026-09-16	2026-09-24	If the fix had failed
Open tickets, fleet-wide	345	116	—
Open `nightly-audit` tickets	11	4	~100 (8 nights × 12 checks)
`nightly-audit` tickets filed since	—	1 (09-24)	~96

The surviving audit tickets were filed 09-02, 09-06 ×2 and 09-24 — the audit has been commenting on survivors instead of opening new tickets, which is what the block always claimed to do and never did.

2. The gap that was left — `in-progress` tickets were skipped

One duplicate did appear: ISSUE-20260924-18 (intel-bottles) duplicating ISSUE-20260902-12.

Cause, and it was mine. e4513be filtered status == "open". ISSUE-20260902-12 is in-progress, so the lookup skipped it and the else-branch filed a fresh ticket.

== "open" was the wrong predicate. Excluding resolved is right — a comment on a resolved ticket is silently lost, which is why the filter exists at all. But in-progress, blocked and needs-decision are all live states, and a ticket somebody is actively working is the most important place to record that the condition recurred: that is the person who needs to know. The test is "not terminal", not "is open".

Three of the four survivors were in-progress, so version-cadence (ISSUE-20260906-10) and boot-contract (ISSUE-20260906-11) were primed to duplicate on their next run too.

Fix — `fleet@4c2a16c`

status not in ("resolved", "closed"), applied at both call sites — a second lane had copied the lookup into another check since 09-16, so the same gap existed twice.

Verified both directions on the live store:

positive  intel-bottles   -> ISSUE-20260902-12    (in-progress, previously skipped)
          version-cadence -> ISSUE-20260906-10    (in-progress, previously skipped)
          boot-contract   -> ISSUE-20260906-11    (in-progress, previously skipped)
negative  repos-no-remote, repos-unpushed, dead-sessions, bus-unread-high  -> all empty
          this-check-does-not-exist                                        -> empty

The negative set is the control that matters: those four checks' tickets are all resolved, so returning empty proves terminal-state exclusion still holds and the widened predicate did not swallow everything.

ISSUE-20260924-18 was unclaimed, so it was folded into ISSUE-20260902-12 with its current state carried forward, and resolved. Open nightly-audit tickets: 4 → 3, one per real condition.

3. The two items handed back on 09-16 are done

Re-measured with the audit's own check (sourced lib/repository.zsh, positive control 211 repos):

repos-no-remote = 0 — was 5. All got remotes.
lib/t3code and lib/tokenbar have mirrors — they no longer appear as unbacked.

Both tickets (ISSUE-20260906-04, ISSUE-20260905-03) are resolved. Confirmed against the store, not assumed.

4. `repos-unpushed` = 9, and all nine are false — no work is at risk

Two were real and are now pushed: fleet (4c2a16c) and fleet/maintenance (9bfda0b), both 0/0 on backup and fleet. My own commit had been sitting unpushed, which is exactly the vulnerable state the discipline names.

The other seven are _scratch/* clones. audit_head_reachable_from_any_remote asks whether HEAD is reachable from that repo's remote-tracking refs, and those clones' only remote is a local path (hub -> /Users/richh/dev/apps/RTTy) whose tracking refs are stale — so HEAD reads unreachable however safe the work is.

Proved safe commit by commit. The three commits the check calls unbacked are all present in the canonical RTTy repo and on backup/main: 4cb35351, be515cd2, f0dea7fc. The other five clones report 0 unbacked against their own origin. The only uncommitted item in any of them is an untracked HANDBACK.md — a lane's hand-off note, not source.

Filed as ISSUE-20260924-34 with the evidence and two candidate fixes (fetch before testing reachability, or scope out local-path-only remotes). A blanket _scratch/* exclusion was considered and rejected — it would hide genuinely unbacked work in a scratch clone, which is the exact data-loss shape the check exists to catch.

5. Pull requests — 0 open

362 GitHub repos swept with a per-repo gh pr list. Zero open PRs; nothing to merge.

6. Git estate — 8 pushes, 5 fast-forwards, 0 failures

Plain git push (never --force), merge --ff-only on clean trees only, each proved a true fast-forward with merge-base --is-ancestor first, and remotes chosen by inclusion (URL under github.com/richhdoty/ or git.ecs0.net).

Pushed: apps/hyperTune→origin · apps/rooDB→origin · apps/scanRoo→origin · apps/Tyrell→backup · issues→backup · scripts→backup · sites/dev.ecs0.net→origin · sites/eastcoastscience.com→origin · plus fleet and fleet/maintenance to both mirrors.

Fast-forwarded and levelled: apps/HyperCPU · apps/sierra/SierraKit · lib/ECSConformance · lib/ECSNetworking · lib/ECSSystem — all now 0/0 on every mirror.

The inclusion filter earned its keep: lib/bumblebee was skipped automatically because its origin is perplexityai/bumblebee, an upstream vendor repo. I did not have to recognise it.

Outgoing diffs were secret-scanned before publishing. No hits.

Left alone, correctly: lib/mole (origin 14/3) and lib/t3code (origin 1273/5) are diverged upstream vendor forks; pushing either would be wrong, not merely risky.

7. How to undo

git -C ~/dev/fleet revert 4c2a16c reverts the predicate change; a pre-edit copy is in this session's scratchpad as nightly_audit.zsh.bak-*.
ISSUE-20260924-18 is in issues/resolved/ with its reason and evidence, and can be reopened.
Every push was a fast-forward that only added commits; old SHAs are in §6's ranges and in each remote's reflog. The five pulls undo with git -C ~/dev/<repo> reset --hard <old-sha> — apps/HyperCPU 29e2ce8, apps/sierra/SierraKit 81b79ef, lib/ECSConformance 990e6aa, lib/ECSNetworking 25e9b1a, lib/ECSSystem 03d9a2e.

No secret value appears in this changelog.

8. Apple Notes publish — PENDING, NOT DONE

The file copy above is complete and is the archive. The Notes entry does not exist yet. Do not read this file as evidence that it does.

launchctl kickstart gui/501/com.rdm.claude-notes-autopublish was run twice (22:14 and 22:29 EDT). The 22:17:50 pass logged published=0 skipped=760 failed=0 without ever naming this file, and the 22:29 pass was still running with no log line and no ledger row at 22:37:48. This changelog's sha is absent from ~/.local/state/claude-notes-autopublish/published.tsv, so it was neither published nor ledger-skipped — the pass is hanging before it reaches the file.

Most likely cause, and why I stopped rather than pushed harder: claude@rdmsm4x dev-c2 is priming Full Disk Access for ECSToolHost on five hosts tonight through a throwaway herdr tab, and asked every lane not to touch TCC/FDA. An unanswered TCC consent prompt makes every AppleEvent hang to timeout, which is exactly this signature. Retrying the publish means driving AppleEvents into a consent dialog somebody else is deliberately holding open — so it was left alone and dev-c2 was notified.

No action needed from Rich. The job runs hourly and is idempotent (sha-keyed ledger, and it replaces a same-titled note rather than duplicating), so it will pick this up on its own once the TCC priming finishes. notes_changelog.zsh must NOT be run directly from a herdr pane — this session is in one, and that path hangs for the same reason.