hazard registry has no entries for destructive GitHub remote operations: 'gh repo delete' and 'gh api -X/--method DELETE repos/{owner}/{repo}' both verdict allow. Field evidence: the user-level guard-bash.sh hook blocks both (repo deletion is human-only; second layer behind the missing delete_repo scope) — that hand-wired hook is the prior art to lift into the bundled registry defaults, same prototype-to-product path as itd-74. Registry entries should mirror the hook's nuances: quote-tolerant token matching (already native), depth-limited api paths (DELETE on deeper repo subpaths stays allowed), and the block message naming the human-only successor.

Frontmatter

.abcd/work/issues/resolved/iss-159-hazard-registry-missing-gh-destructive.md
open on GitHub ↗ · commit history ↗

mentions8

• dcn-26072900000000022026-07-29 — v0.5.0 scoped as "security & consistency" (plan: plans/2026-07-29-v0.5.0-security-and-consistency.md): the security half closes the NEXT.md leak class end-to-end (itd-74/spc-20; the atomic iss-154+157+125+153 detector item; iss-155/156; guard batch iss-159+144+148; boundary fixes iss-30/34), the consistency half retires the record-currency majors (iss-37..44, iss-80) — maintainer added the latter rather than deferring them. Version is derived by launch ship, not declared; 0.5.0 is the prediction given itd-74 additive. Deferred majors listed explicitly in the plan (largest: iss-124); the 2026-07-24 queue's pick-up role is superseded.
• dcn-26080100000000022026-08-01 — guard round (iss-148, iss-159, iss-144): the matcher's wrapper walk now steps over a wrapper's OWN arguments rather than its name alone, off two explicit tables — the flags each wrapper documents as taking a value, and the mandatory operand no flag stepping can reach (`timeout [OPTIONS] DURATION COMMAND...`, where `timeout 30 rm -rf /` read as a command called `30`). That was the sharpest of the three items and the reason to take it first: `sudo -u bob <hazard>` read `-u` as the command name, so one extra token turned an entry the registry DOES describe into an allow, and a guard that has stopped refusing looks identical to one with nothing to refuse. The complementary miss is deliberate and now stated rather than implied — a value flag the table does not name (a bundled `sudo -Hu bob`) is not stepped over, and a miss is a non-match, never a false block. `xargs`, `timeout` and `exec` joined the wrapper set. Backtick substitution reaches command position through the same segment flush the grouping parens already gave `$( … )` by accident, scoped to parity with today's behaviour (unquoted only) rather than POSIX completeness, so the two spellings of one substitution stop disagreeing. Registry content took four additive Pattern fields, each optional and per-repo overridable like the rest: `subcommand2` for a two-level grammar (`gh repo list` and `gh repo delete` share their first level and only one is a hazard), `flag_values` for a flag's SETTING rather than its presence (presence alone would force a choice between missing `-X DELETE` and refusing `-X GET`; the value is compared without regard to case, since a constraint a change of case walks past is not one), `arg_paths` for a root segment AND an exact depth (the depth is the entry's scope: `repos/{owner}/{repo}` IS the repository, while DELETE on a branch ref under it stays ordinary work), and `arg_prefixes` for a hazard carried by an operand with no flag to look at (`git push origin +main:main`). The empty form of each is a load-time rejection, because an empty flag group defangs and an empty prefix over-blocks, and both are invisible in the file. Two behaviours are pinned as tests rather than left to be rediscovered: an api path written as a fully-qualified URL is NOT matched (a stated limit, the family of the payload gap), and `--help` is not an exemption anywhere in this registry — exempting it would mean teaching every entry which of its flags mean 'do nothing', and a guard that reasons about intent can be argued out of refusing. iss-144 needed no code at all: its incident shape was already known-bad fixture #1 and the incident capture already known-good #1, so the only change was adding the three-step form it actually occurred in (mkdir → cd → `rm -rf *`) to the corpus, making the resolve verifiable rather than asserted. Residual and deliberately not acted on: a `cd` in one tool call and an `rm -rf *` in the next is still an allow, since the tokenizer never sees two invocations as one candidate — a harness-level concern, not a registry one.
• dcn-26080100000000032026-08-01 — guard batch (iss-159/144/148), FIX pass after two fresh adversarial reviews returned BLOCK (security) and FIX FIRST (correctness). Detector-first throughout: each fix has a test watched failing before it and passing after. Two claims in the entry above are superseded by it. First, "backtick substitution reaches command position through the same segment flush the grouping parens already gave `$( … )` by accident" — the flush was the bug, not the mechanism. `flushSegment` permanently ENDS the enclosing command's segment, so every flag and operand written after a substitution closed started a new, unrelated command: `cd scratch && rm ` + a backticked substitution + ` -rf *` went from block on main to allow on this branch, a regression this branch introduced, and the identical hole already existed for `$( … )` on main (`rm $(true) -rf *`). Both are fixed together rather than one fixed and one documented, because the mechanism to fix them is the same: a substitution pushes a FRAME that parks the enclosing tokens, accumulates its own content, flushes that as its own segments (a hazard inside a substitution is still matched — the point of the original fix), and restores the enclosing tokens so the segment resumes. Segments come back in SOURCE order rather than at the close boundary, which is what keeps `precededByCD` reading a cd written before a substitution as preceding it. A bare `(` deliberately keeps the old flush: it is a subshell group, not a substitution inside a command, and it genuinely ends the token run before it — `f() { rm -rf *; }` would otherwise glue the body onto the function's name and lose the `rm` from command position. Imbalance degrades rather than errors (a close with no open falls back to the plain flush; an unterminated span is unwound at end of input rather than dropped, since a hazard inside it still executes), consistent with the file's existing philosophy that only an unterminated quote or heredoc — which changes what the REST of the input means — is `ErrUnparsableCommand`; a real shell rejects unbalanced parens itself, and this guard's job is to refuse to misparse into an allow, not to validate shell grammar. Second, "an api path written as a fully-qualified URL is NOT matched (a stated limit)" — it is matched now. `gh` passes an absolute URL through to the API unchanged, so the URL form was a real bypass of a real repository deletion, and documenting it was the wrong end: an operand is normalised to its path (scheme/host, query, fragment dropped) before the depth check, which only ever shortens, so the depth limit that keeps deeper work allowed is untouched. The host is deliberately NOT inspected — deciding which hostnames are the real API is a lookalike-domain problem this guard cannot settle, and normalising every authority away can only make the check see a path it would otherwise have missed. What is left is narrower and now disclosed in all four surfaces rather than in a Go comment and a test: a host that MOUNTS the API under a prefix (GitHub Enterprise Server's `/api/v3/`) is not seen, because matching a root segment wherever it appeared would falsely refuse `DELETE /teams/{id}/repos/{owner}/{repo}`, which removes a repository from a team and destroys nothing. Third item, no supersession: `Validate` rejected a dashed `subcommand`/`subcommand2` but not the two operand fields this branch added, so `"arg_prefixes": ["-f"]` and an `arg_paths` root carrying a slash both loaded clean and could never fire — the "looks armed, never fires" class the validator exists to catch. Both are load-time rejections now, with the well-formed shapes pinned as accepted so the checks cannot quietly take the fields out of use.
• dcn-26080100000000042026-08-01 — guard batch (iss-159/144/148), REVERT of the backtick sub-part after a THIRD adversarial round; the other three sub-parts stand. Following backtick command substitution went in, then grew a frame/stack mechanism intended to hold two properties at once — a substitution's content checked as its OWN segment (so a hazard hidden inside one is matched) while the ENCLOSING command's tokens, chain index and command position survived the boundary. Three rounds, three fresh independent reviewers, three BLOCKER findings, all in that mechanism rather than in one instance of it: (1) a substitution before trailing flags truncated the enclosing segment, so `rm` + substitution + `-rf *` went block to allow; (2) the frame fix for (1) renumbered the enclosing command's chain when a newline fell inside a substitution, defeating every `after_cd` entry (`cd scratch && rm -rf $(\nfind . -name x\n)`); and (3), the one that decided it, a substitution in LEADING command position left a bare `$` as the enclosing command's argv[0], so `commandOf` returned `"$"` and NO entry could match — that is not a hole in `rm-rf-after-cd-chain`, it is a hole in the registry, reachable by prefixing any hazard with `$(true)`. Two more in the same round: a bare `(` nested inside `$( … )` mis-popped the frame and re-opened (1) in a narrower shape, and an unterminated backtick failed OPEN. DECISION: revert rather than patch a fourth time inside one round. A mechanism that has produced a security-relevant regression on every attempt is not converging, and each fix has been strictly worse than the last in blast radius — the third defeats the entire registry. `internal/core/guard/tokenize.go` is restored byte-for-byte to `main`: no backtick handling at all (literal text), `$( … )` exactly as it was, and the four guard.json fixtures the frame mechanism added removed with it. The two claims of the entry above are therefore WITHDRAWN, not superseded: backtick substitution does NOT reach command position, and the enclosing command does NOT survive a substitution. The literal ledger ask ("a backtick command substitution is not followed, while the dollar-paren form is") asked for PARITY with `$( … )` as it behaves today, and parity is what leaving both forms untouched delivers — the gap is disclosed again as a stated v1 limit on all four coverage surfaces (brief, plugin command, CLI long help + generated reference, package map), which is the honest form of it. Recorded rather than quietly carried: `$( … )` on `main` already loses the flags written AFTER a substitution — `rm $(true) -rf *` does not read as a recursive force delete — a pre-existing gap this round's review process surfaced and did not introduce, undisclosed before it and undisclosed still, because closing it is the same design problem as following a backtick and the two should land together or not at all. iss-148 is re-scoped IN PLACE back to open on that one sub-part (the iss-96 precedent: a `capture resolve` would have to state a resolution for scope that is not settled), with the three shipped sub-parts and their commits named in the entry; iss-144 and iss-159 are untouched and stay resolved, neither being implicated in any review finding. Deferred as its own future work, and explicitly NOT a patch to the reverted code: a substitution model that follows the payload AND preserves the enclosing command across the boundary, which needs the tokenizer to carry a command-position stack rather than a segment flush — the reason three attempts to bolt it onto the flush all leaked.
• dcn-26080100000000122026-08-01 — itd-105 / spc-21, coordination note: two independently-running instances of the v0.5.0 loop each reviewed PR #184 at its merge gate concurrently, found different real findings (a self-referential allowlist bypass; a curl config-surface bypass), and pushed both fix commits to `v050/itd-105` minutes apart — rebased together here rather than either overwriting the other. Same collision class the state issue's round-9 comment already disclosed for `v050/iss-159`; recorded again per that precedent, no new action taken beyond the rebase.
• iss-148guard registry coverage gaps found while wiring itd-103 (registry content, not matching semantics): a push whose refspec carries a leading plus is a force in disguise and no entry describes it; xargs, timeout and exec are absent from the matcher's wrappers set, so a hazard launched through one of them is not seen; a backtick command substitution is not followed, while the dollar-paren form is; and a wrapper that IS in the set defangs an entry the moment it carries its own flags, because only the wrapper name is stepped over — `sudo <hazard>` is seen, `sudo -u bob <hazard>` is not, and the same holds for `env -i` and `time -p`. That last one is the sharpest: it turns an entry the registry does describe into an allow with one extra token, and it is the only item here that a facilitator would reasonably assume was covered. Candidates for the admission gate as the registry grows from reality; the wrapper-flag item is matcher-side (`commandOf` in internal/core/guard/match.go), not registry content.
• iss-356round-2 fixed nitpick batch: guard check help omits the disclosed backtick limit; urlguard misses CGNAT 100.64/10 and other RFC 6890 ranges; readHookInput misreports an over-cap payload as malformed (iss-201's class at the shared helper); repolint privacy-hygiene silently skips textual files over the 4 MiB cap; capture reCommitSha refuses 64-hex commits; launch Short hides that --dry-run is required; release.yml verify-tag comment overstates what gh verifies; release.yml header says dispatch runs only the rehearsal job; dependabot covers no pip ecosystem for docs; brief pointer lines enumerate five of nine internals chapters; phase-6 and 06-lint carry change-narration blocks; 05-internals cites a ledger entry that does not exist; 03-evidence names the retired activity record nitpick documentation
• itd-74abcd Keeps the Names You Ban Out of Everything You Publish