2026-09-01: the day the green lights started meaning something

payload v4 shipped and installed · hq-ext 1.58.0 delivered and verified LIVE · one wall left standing

Scoreboard

PRs merged, 2 repos

releases: ork alpha.67, hq-ext 1.58.0

issues closed: #3858, #1192, #1118

72/0

hook cases, now gating CI

dsp worktrees CC cannot delete

inert deny rules removed

The one lesson, drawn

Every stage reported green for six days while nothing reached a session. Each light was truthful about its own stage and silent about the one that delivers.

   merged to dev      promoted to main      tag + release        installed cache
  ✅ every day        ✅ every 04:30        ⏸ FROZEN at 1.57.1   ❌ pre-fix hooks
       │                    │                    │  6 days             │
       ▼                    ▼                    ▼                     ▼
  "the fix landed"    "main mirrors dev"   ◀── the ONLY stage ──▶  what sessions
                                               that delivers          actually run

The delivery key is the version string. The marketplace fetches by version. Promotes, merges and mirrors are upstream of it. Cutting v1.58.0 was the whole fix.

Live verification, fresh session via herdr

A new agent (verify158) proved the loaded plugin was 1.58.0 three ways, then exercised the guard for real. Reported by the agent with pasted evidence; the ledger line was read back from disk.

attempt	verdict	meaning
commit with the verify-skip flag, no reason	BLOCKED	guard alive, as designed
same command, inline `HQ_DESTRUCTIVE_REASON="..."` prefix	ALLOWED + ledger line	the advertised hatch finally works; audit trail written
the flag quoted inside echo data	ran	the false-positive class that blocked 4 commands yesterday is gone

Mini-finding kept: the ledger line proves the guard's ALLOW verdict, not that the command executed; a later hook can still block.

The wall that is left

28 read-only dsp/* worktrees, all clean, zero unpushed commits. No CC session can delete them: git worktree remove EPERMs on .git/worktrees/<name>/commondir, and unlink, rename and xattr-strip fail the same way with the sandbox off, while new files in the same directory work fine.

  .git/worktrees/18604-read-only-.../commondir      created by dispatched agents, Aug 26
        │ rm / mv / xattr from ANY CC session ──▶  EPERM   (symptom VERIFIED)
        │ cause: macOS provenance on another app's files   (CLAIMED, not proven)
        ▼
  2 reaped partially, 26 intact on purpose: better than 26 half-states

Decide: the 26 stuck worktrees

Pick one. The follow-ups below unlock after the pick.

DECIDE: how do we clear the dsp worktrees? Run the reap from your own terminal
one command, gone in seconds IF the block is CC-scoped; my last measurement says it has not run yet Inspect flags first (ls -lO .git/worktrees/*read-only*/commondir)
recommended: one read tells us whether your terminal will hit the same wall before anything is scripted Leave them
zero risk, but 26 dead entries pollute every worktree listing and the next audit re-finds them

[ ] after the pick: prune metadata, delete the 27 dsp/* branches, re-run the count to 0
[ ] file the provenance finding upstream if the flags prove it (new issue, hq-ext)

Backlog after today, ranked

	item	why it is next
🥇	dsp worktree reap (the decision above)	only item still physically open from today
🥈	hq-ext local `dev` checkout behind origin; one orphan `dsp/` branch	two-minute hygiene, stops the next stale-base mistake
🥉	hq-ext MEMORY.md near size cap	verify158 flagged it; a compaction pass before it truncates
later	ork: 88 open issues, none urgent after today	normal queue, nothing added by this work