test(opencode): pin every permission rule individually — 39 of 77 deletions were invisible to the gate

[ZacxDev]

The class, not two more instances

#348 restored 52 ask values a blind sed had flattened to allow. An adversarial audit then found it had closed two instances of a coverage class, not the class itself: a permission rule could be deleted outright with the suite fully green, while a realistic command in that family dropped to plain allow at both the glob layer and the layered (glob + guard_core) layer.

This PR closes the class. No permission rule is changed — the config was already correct; the suite could not tell.

---

(a) Deletion sweep — independently constructed, before/after

I did not trust the audit's list. I re-derived the rule set, re-ran the sweep, and report my own numbers.

Scope, re-derived: the audit's "77 rule lines" = every single-line "pattern": "verdict" row in the file. I confirmed the decomposition rather than assuming it: 64 in the bash block (1 allow + 50 ask + 13 deny) + 13 outside it (10 top-level tool permissions + 3 single-line plan-agent rows) = 77.

Method: delete one row, repair the trailing comma, run test_opencode_config.py, attribute the kill by failing test id. Counts parsed from pytest's summary line — never an exit code.

mutant class	before	after
delete a rule	39 / 77 survive	0 / 77
comment a rule out (token stays present)	39 / 77	0 / 77
invert verdict → allow	2 / 68	0 / 68
invert verdict deny → ask	1 / 16	0 / 16
reorder (hoist rule, append broad allow)	0 / 63	0 / 63

Controls (a sweep with no control is a fact about the sweep):

• Negative control — deleting *nixos-rebuild* must go red: RED on both trees (4 failures on main, 5 on HEAD).
• Unmutated baselines — GREEN on both (main 480 passed / 0 failed; HEAD 574 / 0).
• Generator self-validation — every generated mutant asserted to differ from the original, still parse, and have exactly one fewer rule. 0 defective mutants across all four generators. Without this, "all mutants survived" would be indistinguishable from a generator that silently no-ops.

Of the 39 survivors, 17 were real holes — one more than the audit found. A survivor only counts as a hole if a realistic command resolves allow at both layers once the rule is gone; the rest are redundant or guard-backstopped. The extra hole:

sudo* — the anchored rule is the only cover for a sudo not followed by a space. *sudo * requires the literal "sudo ", so sudoedit /etc/nixos/configuration.nix walks straight past it (glob=allow layered=allow with sudo* deleted).

That is the exact mirror of the *sudo * finding the audit's own MUST_ASK comment records having found by mutation testing — the same class, the other half, which is why the class needed closing rather than the instances.

I also confirmed the audit's non-holes rather than taking them on trust: *sops*--decrypt*, *age*--decrypt*, *systemctl*restart*, *nix-collect-garbage* are redundantly covered, and *git*add --all* / *git*add . / *git*clean -f* / *talosctl*reset* / *mke2fs* / *mkswap* are guard-backstopped by design. Two the audit listed as holes are not: *dd if=* and *dd of=* stay deny via guard_core even with the glob gone.

---

(b) Per-family coverage

18 MUST_ASK rows, one per hole, in the house spellings that RULES.md / k8s.md actually mandate (git -C <path> …, KUBECONFIG=$KC_… kubectl -n ns …) — i.e. the habitual spelling is the bypassing one. Each is measured to be decided by exactly one rule, so it kills that rule's mutant and no other.

But 18 hand-written rows rot, and the next rule added would be unpinned again. So the real fix is the sweep as a standing assertion:

• test_every_ask_rule_is_individually_pinned — every ask rule must be the sole decider for some pinned command, or be declared in REDUNDANTLY_COVERED_ASKS with the covering pattern named. The declaration is re-measured, not trusted: an entry that turns out to be load-bearing fails, and so does a stale one. It fails when the rule set grows and when it shrinks.
• test_every_deny_rule_is_individually_pinned — the deny half, asserted at the layer that actually holds it. Guard-backstopped entries are re-measured to still resolve deny with the glob removed, so it fails if someone deletes the guard check believing the glob has it, or vice versa.
• test_tool_level_permissions_are_pinned_exactly — the 10 non-bash rows, which were the entire residue after the bash ledger landed. doom_loop / external_directory are the ones that matter: the only ask rows outside the bash block, and flipping either to allow removed a real control with the suite green.

Two findings from re-running the sweep against my own fix (the reason the "after" column is 0 and not 10):

1. A deny→ask downgrade of *git*add -A* survived everything, because guard_core denies git add -A anyway. Not an equivalent mutant: the deny block exists precisely for the case where guard.js fails to load, where the downgrade would let a human approve it in the TUI. Fixing it exposed the same bug in my own first attempt — reading denies off the config and checking only what is in it cannot see a rule that left the set. The ledger now pins the set first, against declared GLOB_ENFORCED_DENIES / GUARD_BACKSTOPPED_DENIES.
2. That set assertion made the deny ledger's "stale declaration" check unreachable — it can never execute, so it would report safety while testing nothing. Removed, with the reason recorded inline and verified by mutation.

---

(c) The >= 40 floor — decision: raised to 50, the measured count, with no cushion

The slack was the whole defect. Reproduced exactly, and this is the headline:

Delete the four mutating systemctl verbs + kubectl patch/scale/drain + helm upgrade/rollback + flux resume → exactly 40 ask rules remain → main reports 480 passed, 0 failed while all ten resolve glob=allow layered=allow.
The same mutant on this branch: RED, 32 failures, naming each family.

The docstring called 40 "room to prune ten deliberately" without noticing that is the same slack as room to un-gate ten dangerous families.

Why raise rather than delete it. Its unique coverage is now nearly nil and I say so in the docstring: a mass ask→allow flip is already caught by test_no_allow_rule_follows_the_wildcard (that produced the original 117 failures), ask→deny by the ordering assertion, and mass deletion — its one former unique catch — is now caught rule-by-rule and by name by the ledger. What it still buys: it keeps test_all_asks_precede_all_denies's ordering assertion and the prefix-tolerance test non-vacuous (the documented reason it exists), and it fails on the count, localising a mass edit to one obvious assertion before the ledger enumerates it.

The trade, stated: a deliberate prune must now lower the literal in the same commit. That is the point — it makes a prune a visible act instead of free slack — and it is not extra ceremony, since a prune already requires removing the rule's MUST_ASK row.

---

(d) rm -r — the premise is false; no guard_core change

The brief held that guard_core only handles -rf forms. Measured, not read: check_rm_rf_critical tests the recursive flag alone — --recursive, or any short bundle containing r/R — and never requires -f:

command	guard	glob	layered
rm -r /	deny	ask	deny
rm --recursive $HOME	deny	ask	deny
rm -r . / rm -r /etc / rm --recursive /nix	deny	ask	deny
rm -R / / rm -fr /	deny	allow	deny
rm -r /repo/build	allow	ask	ask

So there was nothing to fix, and no behaviour change — which also keeps this PR out of scripts/claude-hooks/**.

What is real is narrower: guard_core deliberately does not fire on an ordinary path (its fatal-target set is /, ~/$HOME, ./.., top-level system dirs), documented as a decision so routine cleanup does not train the operator to route around the guard. So for rm -r /repo/build the glob is the only gate — and nothing pinned it. That is now two MUST_ASK rows (regression coverage), plus test_guard_core_catches_recursive_rm_without_the_force_flag, which is labelled in its own docstring as an invariant guard and is not counted as regression coverage — it exists so the false premise cannot be re-derived into a needless widening.

---

(e) Red/green matrix

This is a coverage fix — opencode.jsonc carries only comments — so "pre-change code" is the pre-change test data, and each regression gets its own isolation.

#	isolation	main / pre-fix	this branch
A	the ledger, with the 18 new MUST_ASK rows removed	RED (482 passed, 1 failed — names the unpinned rules)	GREEN (574 / 0)
B	the audit's exact 10-rule deletion	GREEN — 480 passed, 0 failed ← the defect	RED — 32 failures
C	negative control: *nixos-rebuild* deleted	RED (4)	RED (5)
D	unmutated baseline	GREEN (480 / 0)	GREEN (574 / 0)

Branch reachability — "a test failed" is not enough. A mutant can go red via an earlier assert while the branch you care about never runs. All 9 new assertion branches were individually reached with a mutant chosen for that branch, and each was confirmed to fail with its own message: ask/unpinned, ask/wrongly-redundant, ask/stale, deny/unpinned, deny/unheld, deny/set, deny/downgraded, the floor, and the rm attribution. (This is how I found the dead stale branch in (b).)

---

Verification mechanism — stated per number

🔴 The version trap was avoided deliberately. An ad-hoc nix-shell -p opencode serves 1.18.11 while the tests pin 1.18.4, fabricating ~15 test_opencode_engine.py failures. Every number here comes from one of three mechanisms, all resolving pkgs.opencode from this flake's nixpkgs:

1. nix build .#checks.x86_64-linux.pytests (nix sandbox) — the authoritative gate. Source of the totals below.
2. Direct pytest under a buildEnv built from this flake's nixpkgs — used for the 77×5 mutation sweeps (a full gate run per mutant was not affordable). opencode --version asserted 1.18.4 before use.
3. opencode debug agent build --pure from the same pinned binary — the real engine.

Engine verification (3): all 18 new pins resolve ask against the real engine, and in each case the intended rule is the LAST matching one — none is shadowed. Gotcha recorded: the engine's stdout truncated at exactly 8192 bytes, nondeterministically, when read through a pipe; I write it to a file (9399 bytes) so "changed CLI" and "full buffer" stay distinguishable.

Gate totals (1) — merged tree, per RULES "gate on the MERGED tree":

tree	collected	passed	skipped	failed
origin/main @ 476ed51 (built standalone as the control)	6160	6129	3	28
this branch merged with origin/main	6254	6223	3	28
delta	+94	+94	0	0

The gate is RED on both — for pre-existing reasons this PR does not touch, attributed by CAUSE:

• 27 failures, one single cause: FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/env' inside the nix sandbox (all 27 tracebacks show that identical error). Split by file as I measured it: 11 in test_monitor_blackout.py, 16 in test_rig_control.py — the two sum exactly to the 27 distinct failing test functions. (I was briefed 22/5; my measurement disagrees on the split. It does not affect the conclusion — one cause, pre-existing, unrelated.)
• 1 further failure, and it is a genuine regression already on main, not from this PR — flagged because someone should fix it: test_live_scraper_observes_the_real_config (scripts/collector/keylog/tests/test_espanso_detect.py:544) asserts ":date" in trigs, but espanso: prune :date/:time/:uuid + drop the non-unique framewo ssh term; raise cpu-mon thresholds #351 pruned the :date espanso snippet from nix/home.nix without updating it. Confirmed pre-existing by the discriminating control above — origin/main alone fails it too.
• 2 unpinned skip groups (datapacket-talos clone not present) — also pre-existing on main.

No absolute green claim is made. The claim is the delta: +94 tests, +94 passing, +0 failures.

---

Also in here

bash_ruleset() is memoised as an immutable tuple. The ledger resolves ~63 rules × ~90 commands and took this CI-gated file from 1.7s → 18.5s; it is back to ~1.7s. A tuple because a cached mutable result is poisonable, and this repo has a caller that mutates a parsed config in place (test_opencode_engine.py's add_trailing_git_allow) — which is exactly why load_config() is left uncached.

Two comments added to opencode.jsonc (no rule changes): that *nix-collect-garbage* is covered only by accident — *age*-d* matching "nix-collect-garbage … -d" — so nobody deletes *age*-d* thinking GC is separately gated; and that both sudo rows are load-bearing.

🤖 Generated with Claude Code

---

Audit round 2 — F1, F2, F4 fixed; F3 and most of F8 deferred

The blind audit reproduced every headline number with its own generator. It also found that three of the six redundancy declarations this PR introduced were false by measurement — i.e. the PR's own defect class, in the PR's own new artifact. All three findings are fixed. This round reset the gate: the full battery, the reachability sweep, the engine check and the merged-tree gate were all re-run from scratch, not just for what changed.

🔴 The finding that matters most is one the audit did not report — my own fix had gone dead

While building the F2 control I found that extending the redundancy loop had dropped the elif not killers: unpinned.append(pat) branch. unpinned — the assertion this entire PR exists for — was dead code.

It was invisible to everything:

signal	said
full file	616 passed, 0 failed
delete battery	0 / 78 survive
comment / flip / reorder batteries	0 survive
branch-reachability sweep	9 / 9 branches "reachable"

The mutation battery could not see it because the rules it deletes were still caught by the per-command assertions; only a rule that no pinned command matches exposes it. The ledger's reassuring answer is an empty list, and an empty list is exactly what a ledger wired to nothing returns — the "positive control" hazard, one level up from where I had applied it.

Fixed, and made unrepeatable: test_an_unpinned_ask_rule_is_detected is now a standing positive control that feeds the ledger a synthetic unpinned rule and asserts the list moves (([], ['*terraform*destroy*'])). The ledger body is extracted into one helper both the control and the real test call, so there is no second copy to drift.

F1 — three declarations were false. Measured, at both layers, on model and real engine

rule	spelling that dropped to plain allow with it deleted	was declared
*nix-collect-garbage*	nix-collect-garbage, … --max-freed 1G	"REDUNDANT"
*dd if=*	FOO=1 dd if=/dev/sda, time dd if=/dev/zero bs=1M count=100	guard-covered
*dd of=*	FOO=1 dd of=/tmp/img bs=1M	guard-covered

*age*-d* rescues only spellings containing a literal -d; dd * is anchored, so every prefixed dd rested on the two operand rules alone. All are now pinned in MUST_ASK.

The jsonc comment this PR added — "MEASURED: this rule is REDUNDANT — deleting it changes no verdict" — was false and is corrected. That is the worst kind of wrong comment: it invites a maintainer to delete a live gate. The other three declarations (*sops*--decrypt*, *age*--decrypt*, *systemctl*restart*) I re-verified as genuinely subsumed and kept.

F2 — the declaration was an escape hatch; F1 was that hatch already used

It mapped a pattern to prose, so the ledger could only check "no pinned command moved" — verifying entries against the pinned pool, never against the claim. Now:

pattern -> (covering_pattern, witness_command)

with all three legs re-measured: the coverer exists, the witness really is matched by the redundant rule, and with that rule removed the witness is last-matched by exactly the declared coverer.

Controls (test_opencode_config.py only; direct pytest, flake-pinned 1.18.4):

state	before	after
0. unmutated	GREEN 574	GREEN 617
1. add unpinned "*terraform*destroy*": "ask"	RED	RED
2. …declared covered by an imaginary pattern	GREEN 574 ← the hatch	RED
3. …declared covered by a real but wrong pattern	GREEN	RED
4. …with a witness the rule does not even match	GREEN	RED

F4a — *sudoedit* added to the config

sudo* and *sudo * were presented as complementary halves; their intersection was covered by neither. Measured ALLOW at both layers before this rule:

• FOO=1 sudoedit /etc/nixos/configuration.nix
• EDITOR=vim sudoedit /etc/nixos/configuration.nix — the normal invocation, since sudoedit reads $EDITOR
• /run/wrappers/bin/sudoedit /etc/nixos/configuration.nix — the NixOS path

Unlike a flag spelling, sudoedit is a fixed binary name, so one leading-and-infix * closes the family rather than buying one more spelling. sudo* is re-pinned via sudo-rs whoami — note a bare sudo does not isolate it, because "*sudo *"'s " *" suffix also matches the bare form.

F4b — rm: comment corrected, gap pinned open, not closed

The comment claimed the glob was "the ONLY thing between an agent and a silent recursive delete". It is not even that — rm -R, rm -Rf, rm -fr on an ordinary path are ALLOW at both layers.

I did not widen the glob, deliberately: it is whack-a-mole (-R, then -fR, then -vr), and the candidate that looked like it generalised, "*rm*-*r*", matched rm -R /repo/build only because the path contains an "r" — it fails on rm -R /x. The structural fix is guard_core's target set, which its own docstring reserves as an operator decision needing real measurement, and which is outside this PR's remit.

So the gap is pinned open by test_rm_glob_misses_these_recursive_spellings — labelled a characterization test, asserting today's wrong answer on purpose, and telling you to move the row into MUST_ASK if you close it. Green before and after; not counted as regression coverage.

F8 (partial) — comment scope corrected

The systemctl comment read as exhaustive. Measured ALLOW at both layers: mask, unmask, kill, isolate, set-property, edit, reload. Comment now says so explicitly. The wider verb sweep stays deferred, as agreed.

Floor 50 → 51

*sudoedit* landed, so by this PR's own no-cushion policy the literal moves with it. That is the policy working, not ceremony.

Re-verification after the fix round — everything re-run

Mutant battery (mechanism: direct pytest under a buildEnv from this flake's nixpkgs; opencode --version asserted 1.18.4; 78 rows now, *sudoedit* added):

class	before (main)	after
delete	39 / 77	0 / 78
comment out	39 / 77	0 / 78
flip → allow	2 / 68	0 / 69
flip deny → ask	1 / 16	0 / 16
reorder	0 / 63	0 / 64

Branch reachability: 12 / 12, each failing with its own message — now including the two new bad_claim legs and the positive control. Two ordering facts worth recording: the wrongly_redundant branch had to be re-reached with a different mutant because bad_claim now legitimately fires first, and the earlier round's dead stale branch stayed removed.

Real engine (opencode debug agent build --pure, flake-pinned 1.18.4, stdout read from a file — 9493 bytes; the 8192-byte pipe truncation is real, pre-existing at test_opencode_engine.py:175, and not repeated here): all 26 pins resolve ask, and in each case the intended rule is the LAST matching one — none shadowed.

Merged-tree gate (mechanism: nix build .#checks.x86_64-linux.pytests; control built standalone from current origin/main):

tree	collected	passed	skipped	failed
origin/main @ 0cbc9e6	6160	6129	3	28
this branch merged	6297	6266	3	28
delta	+137	+137	0	0

The failing sets are identical — the set difference is empty in both directions, so nothing here introduces or masks a failure. Both trees are red for the same pre-existing reasons: 27 failures from one cause (/usr/bin/env absent in the nix sandbox; my split, 11 test_monitor_blackout.py + 16 test_rig_control.py, sums exactly to the 27 distinct functions — the audit confirmed this over the 22/5 I was briefed), plus test_live_scraper_observes_the_real_config, still broken on main by #351's :date prune, plus 2 unpinned skip groups.

No absolute green claim. The claim is the delta: +137 tests, +137 passing, +0 failures.

---

Delta-audit round 3 — N1, N2, N4, N5 fixed; N3 softened; N9 recorded

Re-baselined: main is green now. Every earlier statement in this PR about a
pre-existing red gate (27 /usr/bin/env failures, the :date regression, unpinned
skip groups) is superseded — #354–#357 and #350 fixed them. Nothing below is
attributed to a pre-existing failure, because there are none.

🔴 N2 — time defeated BOTH layers at once

time dd bs=1M if=/dev/zero of=/dev/sda   ->  glob=allow  guard=allow  layered=allow

time was missing from _WRAPPER_VALUE_FLAGS, so argv[0] stayed "time" and check_dd_to_block_device bailed at its basename(argv[0]) != "dd". Fixed structurally — time added with GNU time's value-taking flags (-f/--format, -o/--output). \time needs no entry (the tokeniser already normalises it) and /usr/bin/time is covered by the basename(); both are pinned anyway.

And the comment this PR had added said the guard covered it. Corrected — that is the second time this PR shipped a comment asserting a measurement that did not hold, and both times the comment was the part that would have caused harm.

Why dd and nothing else — worth keeping, because it explains the shape rather than the instance: for every other family an unpeeled prefix is still caught by the glob layer. Measured: time rm -rf /, time mkfs.ext4 …, time talosctl … reset, time git stash all still resolve deny on the globs alone. The dd globs are the only spelled ones (dd * anchored, *dd if=*/*dd of=* literal), so dd is the single family where an unrecognised wrapper defeats both layers together.

I swept the class rather than fixing the instance. 14 more prefixes are unpeeled and each still defeats both layers on dd:

xargs, watch, script -c, unbuffer, strace -f, ltrace, catchsegv, proxychains, torify, flock <file>, eatmydata, systemd-run, pv, rlwrap

Deliberately NOT added in this round. guard_core's own header records that a wrong flag-arity entry fails OPEN, and several of these take positionals or a command string (flock <file> cmd, script -c "…", systemd-run --unit=x cmd). That is a table-design job needing its own evidence, not a same-round guess. Follow-up.

Tests: 12 time spellings + 5 other-family spellings, RED before the table entry (16 failures), GREEN after. Two further tests — that time ls/time git status stay allowed, and that a bare time does not crash — are green both ways and labelled invariant guards; without them "the guard got stricter" and "the guard got broken" look identical from the green side.

🔴 N1 — my own thesis, applied to the detectors I had just added

Every ledger detector reports health as an empty list — the shape a detector wired to nothing also produces. Neutering any one left the file 617/617 GREEN, including the three bad_claim legs this PR introduced, for which I had written a control covering only the rules dimension and not the declarations one.

Both ledgers are now extracted into _ask_ledger / _deny_ledger over an explicit ruleset, and two parametrized controls drive each detector to non-empty with a case built for it — reported as a pair (clean empty, seeded non-empty), and for the three legs asserting which leg fired so one cannot silently preempt another.

Measured after: all 12 detector-neutering mutants go RED. Twelve, not nine — the extraction split the deny set-check into missing/undeclared and made each bad_claim leg separately mutable.

neutered detector	before	after
ask: unpinned, wrongly_redundant, bad_claim (all 3 legs, and each leg alone), stale	GREEN 617	RED
deny: missing, undeclared, unpinned, unheld, downgraded	GREEN 617	RED

🟡 N4 — two copies of the resolver, collapsed

The ask ledger carried a private resolve() while the deny side went through effective_bash_action. Zero disagreements today and nothing pinning that. Both now route through one _resolve_over(rules, command) + _rules_without(rules, drop).

🟡 N5 — the floor's paragraph was prose, not a gate

It claimed "the literal is still raised when one lands, so the number never drifts back into being a cushion". Measured: adding an ask rule and pinning it, literal left at 51, was GREEN under >= — the cushion regrows one rule at a time until it is exactly the slack the same docstring spends two paragraphs condemning.

Now == 51, with a message naming both directions:

case	>= (old)	== (new)
+1 rule, pinned, literal unchanged	GREEN 633 ← the defect	RED
−1 rule (a prune), literal unchanged	RED	RED

Deferred, and honestly labelled

• N3 — the redundancy hatch is narrowed, not closed: the witness is declarer-chosen, so the check establishes "another rule wins on this command" while the claim is "another rule covers the family". Nothing verifies subsumption. The docstring now says exactly that instead of reading stronger than the code. All three current entries are genuinely subsumed (every --decrypt contains -d; every restart contains start).
• N8/N6 — the hard-coded *terraform*destroy* control is gone, replaced by ASK_CONTROLS[0] over a guaranteed-absent SENTINEL, plus a test asserting the sentinel is absent.
• N7 — wrongly_redundant's message still names a scenario bad_claim preempts. Left as-is.
• N9 (pre-existing, not from this PR) — recorded so it is not lost. All measured allow at both layers: nix store gc, nix-store --gc, nix profile wipe-history, nix-env --delete-generations old, home-manager expire-generations; pkexec / run0 bypass the sudo/doas block; FOO=1 sudo-rs whoami and /usr/bin/sudo-rs whoami escape the anchored sudo* — note sudo-rs is the witness this PR picks for sudo*, so that pin is narrower than it looks; rm -vr, rm -Rv, rm -f -R, FOO=1 rm -R are live spellings the characterization test does not pin; and *home-manager*switch* / *systemctl*daemon-reload* survive a trailing-* strip, so the house home-manager switch --flake . --impure form is not itself pinned.
• F3 (from round 2) — the coverage is spelled, not structural; still its own PR, still coupled to respelling 25 rules.

Incoming conflict to expect

The concurrent session's uncommitted WIP in scripts/claude-hooks/tests/test_guard_core.py adds a git add block and states it will remove "*git*add ." from opencode.jsonc. This PR's GUARD_BACKSTOPPED_DENIES declares that rule, and the deny ledger pins the deny set — so whichever lands second must move that entry, and the test will say so by name. My time tests are appended at EOF specifically to avoid a textual clash with their insert at lines 412-498. I read that file read-only and did not modify their WIP.

Verification — mechanism stated for every number

1. nix build .#checks.x86_64-linux.pytests — the flake-pinned sandbox gate.
2. Direct pytest under a buildEnv from this flake's nixpkgs, opencode --version asserted 1.18.4 (an ad-hoc nix-shell -p opencode serves 1.18.11) — the mutation batteries and the N1/N2/N5 matrices.
3. opencode debug agent build --pure from that same pinned binary, stdout read from a FILE — the 8192-byte pipe truncation at test_opencode_engine.py:175 is real and pre-existing; not fixed here, not repeated here.

Full mutant battery, re-run from scratch on the final tree (78 rows; baseline 628 passed / 0 failed):

class	main	this branch
delete	39 / 77	0 / 78
comment out	39 / 77	0 / 78
flip → allow	2 / 68	0 / 69
flip deny → ask	1 / 16	0 / 16
reorder	0 / 63	0 / 64

Branch reachability: 12 / 12, each failing with its own message. One case had to be retargeted — deny/downgraded's mutant patched a function the ledger no longer calls after the N4 dedupe, and it went green; that is the same shadowing hazard the harness exists to catch, so it is worth naming.

Engine: all 26 pins resolve ask against the real 1.18.4 engine with the intended rule LAST — none shadowed. guard_core suite: 1156 passed. #350's new scanners pass against my edits (1817 passed across the two scanners + test_guard_core.py + test_opencode_config.py), so the count it pins in test_guard_core.py is intact.

Both tiers, both green:

tree	collected	passed	skipped	failed
origin/main @ 60e6d9d (built standalone as control)	6311	6310	1	0
this branch merged with origin/main	6486	6485	1	0
delta	+175	+175	0	0

(I measured the control rather than reusing the briefed 6164/6163 — that figure predates #350, which added ~147 tests.)

🔴 Deploy note

~/.config/opencode/opencode.jsonc is a home.file copy resolving into /nix/store. Merging does not activate the new "*sudoedit*" rule, and merging does not deploy the time fix to ~/.claude/hooks/ either. Both need home-manager switch (or scripts/ship.sh) on each host. Merged ≠ deployed.