@lannguyensi/harness 0.49.0 → 0.51.0

package/CHANGELOG.md

@@ -7,6 +7,797 @@ and this project adheres to [Semantic Versioning](https://semver.org/).
 
 ## [Unreleased]
 
+## [0.51.0] - 2026-08-27
+
+### Added
+
+- **Understanding gate: operator opt-in auto-approval for allowlisted
+  permission modes** (agent-tasks `74b4b17d`, slice 1 of the ADR
+  `docs/decisions/2026-08-27-ug-auto-mode-approval.md`). A new strict
+  pack-config block `auto_approve: { when: [...], require_report: true }`
+  (`require_report: false`, unknown keys and an empty `when` are
+  `harness validate` errors) lets the `understanding-before-execution`
+  PreToolUse hook write the signed SESSION approval marker itself, with
+  `approvedBy: auto-mode:claude-code:<mode>`, as the last step of its
+  decision order: only after the ordinary marker check, the read-only
+  Bash exemption, the recovery commit and the escape `ask` have each
+  declined, and only when the payload's `permission_mode` is in `when`,
+  the payload `session_id` equals the hook's `$CLAUDE_CODE_SESSION_ID`,
+  the signing key already exists (the hook never creates one), no forged
+  marker was seen, and the newest report bound to the session is exactly
+  `pending` and passes the approve CLI's own validation. The report is
+  consumed (flipped to `approved`, so one report mints at most once), the
+  audit-only ledger fact `understanding-auto-approved:<sid>` is recorded,
+  the `.pending-approval` staging entry is cleared, and the verdict comes
+  from re-running the same marker check. Every missing input fails
+  closed to today's block; the hook's fail-open infrastructure contract
+  is unchanged. New module `src/cli/pack/auto-approve-path.ts`,
+  `signingKeyExists` (non-creating) in `src/runtime/approval-signing.ts`,
+  `selectNewestStrictSessionReport` (no tolerant fallback, newest strict
+  match only) in `persisted-reports.ts`; `validatePersistedReport` and
+  `rewriteReportApproved` are exported from the approve CLI and reused,
+  not copied. Pinned by the ADR's negative controls and mutation probes
+  in `tests/cli/pack-hook-pre-tool-use-auto-approve.test.ts`.
+- **Understanding gate: the opt-in auto-approval path now runs on Codex
+  too, closing parity gap 13** (agent-tasks `57058364`, slice 2 of the
+  ADR `docs/decisions/2026-08-27-ug-auto-mode-approval.md`; commits
+  `cd6a37e`, `9e4ef7b`, `2635ce1`, `3c71b05`, `ab58d84`). `attemptAutoApproval`
+  (`src/cli/pack/auto-approve-path.ts`) becomes runtime-agnostic: the
+  caller names the harness for the minted marker's
+  `approvedBy: auto-mode:<harness>:<mode>` and supplies which
+  session-consistency evidence its runtime actually offers: an env
+  variable for Claude Code (unchanged) or, for Codex, the payload
+  `transcript_path` (Codex exports no session-id environment variable to
+  hook processes, measured live), and that check passes only when the
+  transcript file's own name carries the session id and the file exists
+  on disk. `harness pack hook codex-pre-tool-use` now runs this same
+  attempt at the same point in its decision order as the Claude hook,
+  after the read-only Bash and recovery-commit exemptions, before
+  `.pending-approval` staging (allow only via the marker recheck); it reads
+  `permission_mode` and `transcript_path` from the payload and resolves
+  tool arguments through the shared `tool_input`/`raw_input` precedence
+  (`tool_input` preferred) so the real Codex payload reaches the
+  read-only and recovery-commit exemptions too. The block gains an
+  explicit `harnesses` list (`claude-code`, `codex`; default Claude Code
+  only), so an existing Claude-only opt-in never extends to Codex without
+  naming it, and the Codex exemption call site fails closed on a
+  `tool_input`/`raw_input` pair that disagrees. A registry of measured
+  `(harness, permission_mode, fixture)` triples
+  (`src/policy-packs/builtin/understanding-before-execution/measured-permission-modes.ts`)
+  ships inside the package; a new `harness validate` check
+  (`checkUnderstandingBeforeExecutionAutoApproveMeasured` in
+  `src/cli/validate/checks.ts`) errors on any `auto_approve.when` literal
+  that no harness was measured emitting, and a sync test binds the
+  registry to the checked-in dogfood fixtures in both directions. New
+  dogfood capture scripts (`codex-capture.sh`,
+  `codex-interactive-capture.sh`) and fixtures under
+  `dogfood/ug-auto-mode-signals/payloads/` back the registry; see
+  `docs/okf/understanding-gate-auto-mode-signals.md` for the measured
+  Codex `permission_mode` vocabulary. A separate opencode probe
+  (`dogfood/ug-auto-mode-signals/opencode/`) found no hook-level
+  observability of its `--auto` flag in the probed version, so opencode
+  stays out of scope for auto-approval; see the same okf doc. 33 new
+  Codex hook tests in
+  `tests/cli/pack-hook-codex-pre-tool-use-auto-approve.test.ts`.
+- **Dogfood: interactive `bypassPermissions` and subagent hook-payload
+  captures** (agent-tasks `74b4b17d`): `dogfood/ug-auto-mode-signals/`
+  gains `interactive-capture.sh`, `interactive-ask-probe.sh` and
+  `subagent-capture.sh` with redacted fixtures; results and the closed
+  "unverified" items are recorded in
+  `docs/okf/understanding-gate-auto-mode-signals.md`. A hook
+  `permissionDecision: "ask"` in an interactive `bypassPermissions`
+  session surfaces a real operator prompt (no auto-allow), so the ADR's
+  conditional escape-path `deny` branch is not needed for that mode.
+- **`harness doctor`: auto-approval visibility and settings-drift warnings**
+  (agent-tasks `74b4b17d`, the ADR's Option B visibility half). The
+  understanding-gate section lists the auto approvals found in
+  `harness.generated/.approvals/` by `approvedBy` prefix with the metric
+  "auto approvals in the last N sessions" (N default 20, `--recent-sessions
+  <n>`), and warns about a `permissions.defaultMode` or a hook entry in
+  `.claude/settings.json`, `.claude/settings.local.json` or the user
+  settings file that was absent at the last `harness apply` (compared
+  against the `.last-apply` snapshot; a file that was never an apply
+  target uses an empty baseline). Warnings only, no enforcement. The
+  listing runs when the `understanding-before-execution` pack is declared
+  and enabled; the drift check additionally requires that `harness apply`
+  has run at least once (`harness.generated/` exists).
+
+### Security
+
+- **The honest trust model in `src/runtime/approval-signing.ts` names the
+  hook as a second marker-minting route** (agent-tasks `74b4b17d`): with
+  `auto_approve` opted in, the forgery residual is a disjunction (read
+  the key, or make the hook sign for you) rather than the previous
+  conjunction. Reach is post-approval only (invoking the hook is a gated
+  Bash call before approval), so this is not an escalation over the
+  existing post-approval write class; it is named rather than argued
+  away. The Codex hook did not run the auto path in this slice; slice 2
+  (`57058364`, entry above) wires it and closes
+  `docs/okf/codex-adapter-parity-gaps.md` gap 13.
+
+## [0.50.0] - 2026-08-27
+
+### Security
+
+- **The understanding gate's persisted-report approval path no longer carries
+  gate authority: gate-time approval now flows only through the HMAC-signed
+  marker, in both the Claude and the Codex PreToolUse hook**
+  (task `7402301d`, the "persisted-report approval path is a separate,
+  still-unsigned residual" follow-up that the v0.41.0 marker-signing entry,
+  task `f9485cc7`, tracked). Why: both hooks consulted `checkPersistedReport`
+  as a SECOND approval source with equal authority ("either source
+  approves"), immediately after a forged marker had been rejected, and the
+  report was unsigned. Under the very threat model that motivated marker
+  signing (a future write primitive the `Edit|Write|Bash` blocker matcher
+  does not cover), one unsigned JSON write of `{"approvalStatus":"approved"}`
+  into `.understanding-gate/reports/` forged an approval with LESS effort
+  than the old marker forgery: the gate-read selection used the tolerant
+  sessionId-less fallback (`"any"`, no age limit), so the forged report
+  needed neither a session id nor a key read. Two closures were weighed:
+  (A) sign the report's approval state at approve time with the existing
+  `signMarker` primitive and verify it in the gate, or (B) make the signed
+  marker the only gate-time authority and demote the report to evidence.
+  (B) shipped. It leaves the smallest attack surface (no second signed
+  artefact, no second verification path, no new key consumer, nothing to
+  keep in sync when the approve flip and the post-tool-use expiry both
+  rewrite the report file), it is fail-closed by construction (the new
+  `PersistedReportEvidence` return shape has no `approved` field a hook
+  could read an allow decision out of, and `ApprovalSource` lost its
+  `"persisted-report"` member), and it leaves the approve flow, the
+  post-tool-use expiry, and the approve-time staleness handling (task
+  `adc20a8b`) untouched. (A) would have required choosing a canonical hash
+  form for a file that the approve flip and the expiry both rewrite, which
+  overlaps the C1 staleness cross-check follow-up (task `fa423e9b`); under
+  (B) that follow-up becomes an audit-fidelity gap rather than an authority
+  gap.
+  - Behaviour: `harness pack hook pre-tool-use` and `harness pack hook
+    codex-pre-tool-use` block when only the persisted report says approved,
+    with a distinct, greppable audit reason in the block reason and on
+    stderr, `unsigned persisted-report approval rejected: report <file> has
+    approvalStatus=approved ... but the persisted report is evidence, not
+    authority`, the counterpart of `forged/unsigned marker rejected`.
+    `checkPersistedReport` still runs, for that diagnostic and for the
+    parse-error lookup gate only. Shared in the runtime
+    (`persisted-reports.ts`), not duplicated per hook.
+  - Side effect worth knowing: `approval_lifecycle.max_age` now actually
+    expires an approval. Before, a still-approved persisted report kept the
+    gate open past `max_age` (pinned by the former "persisted-report source
+    wins BEFORE the recovery-commit check" test, now inverted); the
+    recovery-git-commit exemption (task `6e888423`) remains the way a bare
+    `git commit` passes after expiry.
+  - **Back-compat is strict, no migration window**, the same policy as
+    `f9485cc7`: an approval that only ever flipped the report (the
+    standalone `understanding-gate approve` CLI, or a `harness approve
+    understanding` run whose marker write failed) no longer opens the
+    harness gate; run `harness approve understanding` once after upgrading
+    on a machine with a live approval. The package's own standalone blocker
+    for solo users without harness is unaffected.
+  - Adversarial audit before closing, pinned as
+    `tests/cli/pack-hook-persisted-report-evidence.test.ts`: 22 probe
+    classes, each run against both runtimes (44 probes): hand-written
+    approved report; approved report next to an unsigned marker; marker
+    signed under a foreign key; sessionId-less report; report copied from
+    another session; producer-shaped filename with a future timestamp;
+    symlinked report; malformed sibling (parse-errors path); case and
+    whitespace variants of the status; expired marker; boundary-cleared
+    marker with and without a failed report expiry; report written after
+    the boundary (race); key rotation after a real approval; task-scoped
+    marker for another task; unresolvable generatedDir; the real approve
+    flow and a marker without any report (controls); read-only and mutating
+    shell commands. Residuals, named and pinned: a VALID marker plus a
+    report swapped after approval still allows (the operator did approve
+    the session; the marker's `reportContentHash` is not cross-checked at
+    gate time, task `fa423e9b`), and a key read plus an uncovered write
+    still forges a valid marker (the documented honest trust model of
+    `src/runtime/approval-signing.ts`).
+
+### Added
+
+- **`workflows:` gets its first slice of runtime enforcement: a `review_subagent` step with `spawn: "required"` followed by a `merge` step now derives a real merge-time gate, closing the v0.7.0 note that runtime enforcement was a follow-up** (task `99f47307`, Slice 1). `src/runtime/workflow-policies.ts#deriveWorkflowGatePolicies` is a pure function `src/cli/loader.ts#loadManifest` calls right after parse: for every workflow whose steps match that shape, and only when `manifest.hooks[]` declares BOTH `require-review-evidence` and `require-review-evidence-bash` (the pair `harness init --template full` already hand-authors, `src/cli/init/templates.ts`), it appends the byte-identical `review-before-merge` / `review-before-merge-bash` policy pair to `manifest.policies`, renamed `workflow:<name>:...` for provenance. Every `loadManifest` caller inherits this with no `harness apply` round-trip: the real `harness policy intercept` entrypoint (`src/cli/policy/intercept.ts`), `harness list policies`, `harness explain[-policy]`, and `harness doctor`. A hand-authored policy on the same trigger surface (event/match/bash_match) + `requires.ledger_tag` that extracts the same template variables and is at least as strong (`enforcement: block`, no `when:`, not `operator_only`) stands in for the derived gate and nothing is derived for that surface; so does a gate an earlier qualifying workflow in the same manifest already derived. A weaker or differently-extracting hand-authored policy does NOT suppress the derivation: both apply, and `harness validate`/`doctor` name the overlap (see review rounds 2 and 3 below). Fail direction: when the two evidence hooks are NOT wired the derivation returns nothing (never an unenforceable policy pointing at a hook that doesn't exist), closed by a new `error`-severity `harness validate` check, `checkWorkflowGateWiring`, so "declared `spawn: required`, gate never wired" cannot pass silently. The same CLI entrypoint runs on both adapters (`harness policy intercept`; `loadManifest` carries no runtime branching), so a Codex install that wires these hooks inherits the derived policies; not separately exercised — `docs/okf/codex-adapter-parity-gaps.md` gap 8 documents partial, de-facto Codex accommodation in the intercept engine (cwd resolution from the Codex sandbox argv), not a verified parity claim for this specific derivation. Scoped: only the `review_subagent (required) -> merge` pairing is enforced; PR-open gating driven by `workflows:` itself (today only reachable via the separate hand-authored `review-subagent-before-pr-create` / `-bash` policies), step-ordering validation, and `when.task_label`/project-based workflow selection remain schema-only and are left to a follow-up slice. `docs/for-agents.md` updated to describe the scoped, hook-dependent, process-gate-not-hostile-agent-safe behavior in place of the old "schema cannot enforce that today" line.
+
+  **Review round 2** (same task, before this line shipped) reproduced eight
+  reviewer findings against the built CLI and fixed six of them:
+  - **F1 (correctness, MEDIUM):** dedupe was keyed on trigger surface +
+    `requires.ledger_tag` alone, so a hand-authored policy on the identical
+    surface with `enforcement: "warn"` (or scoped via `when:`) silently
+    suppressed the derived BLOCK gate — a `spawn: "required"` workflow step
+    that looked enforced actually degraded to warn-only. Dedupe now only
+    skips deriving against a hand-authored policy that is at least as
+    strong as the gate it would stand in for (`enforcement: "block"`, no
+    `when:`, not `operator_only`); a weaker one no longer suppresses the
+    derivation, and a new warning diagnostic
+    (`checkWorkflowGateWeakOverlap`) names the overlap so it is not
+    silent.
+  - **F2 (correctness, MEDIUM):** `apply` (via `loadManifest`) and
+    `validate` (via `loadMergedRaw` + `parseManifest`) saw DIFFERENT
+    effective policy sets for the identical manifest — a workflow
+    requiring the gate, both evidence hooks wired, no hand-authored
+    policies, no `grounding-mcp`: `validate` reported "0 errors" while
+    `apply --dry-run` refused with "policies declared but grounding-mcp
+    not wired". The derivation is now capsuled in one function,
+    `withDerivedPolicies`, that both `loadManifest` and `validate` call,
+    so the two entrypoints agree.
+  - **F3 (correctness, MEDIUM):** `harness doctor` imported checks
+    selectively and never wired in `checkWorkflowGateWiring`, so a
+    `spawn: "required"` workflow with the merge gate unwired showed green
+    under `doctor` while `validate` errored on the identical manifest.
+    Doctor's Workflows section now runs the same check (plus F1's
+    weak-overlap warning).
+  - **F4 (security, MEDIUM, deliberately NOT closed this slice):**
+    `mcp__agent-tasks__task_merge` and `mcp__agent-tasks__task_finish`
+    (`autoMerge`) still pass the gate uncovered — only
+    `mcp__agent-tasks__pull_requests_merge` and `gh pr merge` are gated,
+    matching the parity `src/cli/init/templates.ts` already had. A
+    follow-up task extends the template pair and this derivation to those
+    two verbs together.
+  - **F5 (correctness, LOW):** `checkWorkflowGateWiring` (and the runtime
+    derivation's own `hasWiredMergeGateHooks`) only checked hook NAME
+    presence; a hook declared under the right name but wired to a stale
+    `match`/`bash_match` or a `command` that is not `harness policy
+    intercept` (`isPolicyInterceptCommand`) is just as unenforced as a
+    missing hook. `checkWorkflowGateWiring` now also verifies the actual
+    trigger surface + command.
+  - **F6 (correctness, LOW):** a workflow with a `merge` step BEFORE its
+    `spawn: "required"` review step derives no gate (silent, by design —
+    step-ordering validation is the later slice the round-1 entry above
+    already scoped out) and previously said nothing about it. A new
+    warning (`checkWorkflowMergeBeforeReview`) names the ordering instead.
+  - **F7 (maintainability, LOW):** derived policies were indistinguishable
+    from hand-authored ones in `harness export`/`list`/`doctor`. A
+    `WeakSet`-backed registry (`isDerivedPolicy`) now lets `export` filter
+    them out of the emitted manifest and `list`/`doctor` mark them
+    "(derived from workflows[])".
+  - **F8 (correctness, LOW):** `harness remove hook require-review-evidence`
+    silently deleted a hook referenced ONLY by a derived merge gate (no
+    hand-authored `policies:` entry named it, so the existing
+    reference-check saw nothing). `remove`'s reference check now also
+    consults the derived view and refuses the same way hand-authored
+    policy references do — though, unlike those, there is no schema-level
+    safety net stopping `--force` here, since a derived gate is not a
+    static YAML reference the schema can see.
+
+  **Review round 3** (same task, before this line shipped) fixed the
+  remaining findings and closed the CLASS rounds 1 and 2 kept finding
+  one member of ("one manifest reader sees the derived policies
+  differently from another": round 1 `apply` vs `validate`, round 2 the
+  two sides of `diff --since`). Every reader that parses a manifest now
+  takes one of two views on purpose, documented as a table in
+  `src/runtime/workflow-policies.ts`'s module doc and pinned by a new
+  parity suite (`tests/cli/manifest-view-parity.test.ts`) that runs ONE
+  on-disk manifest through every reader: the DERIVED view (hand-authored
+  plus the workflow gate pair) for enforcement, validation, display, and
+  comparisons where both sides are derived (`loadManifest`, `validate`,
+  `doctor`, `list`, `describe`, `explain`, `dry-run`, `diff --since` on
+  both sides, `add`'s asset gate, the `.last-apply` restart-hint
+  comparison); the HAND-AUTHORED view for everything written out
+  (`harness export`, the `.last-apply` manifest snapshot, the
+  `add`/`remove`/`adopt`/`pack reseed` file rewrites and the schema gate
+  in front of them). `withDerivedPolicies` and a new
+  `withoutDerivedPolicies` are idempotent and accept either view as
+  input, so a reader on the "wrong" side can no longer double-derive or
+  strip a hand-authored policy.
+  - **F1 (correctness, MEDIUM):** `findWeakGatePolicyOverlaps` re-ran the
+    derivation walk WITHOUT its dedupe set, so a surface an equivalent
+    hand-authored policy already covered (nothing derived) still warned,
+    naming a `workflow:<name>:review-before-merge` policy that did not
+    exist (`harness init --template full` plus a qualifying workflow:
+    `validate` "0 errors, 1 warning", `doctor` 1 warning, `list policies`
+    no `workflow:*` row). The overlap finder and the derivation are now
+    two projections of ONE walk (`deriveWorkflowGates`), so they cannot
+    disagree about what was derived; the full template plus a qualifying
+    workflow yields zero workflow diagnostics.
+  - **F2 (correctness, MEDIUM, repeated class):** `harness diff --since
+    <ref>` parsed the ref side without the derived policies while the
+    working side came from `loadManifest`, so an unchanged manifest with
+    a qualifying workflow diffed as `+ policies[workflow:<name>:review-
+    before-merge(-bash)]` on every run. Both sides now take the derived
+    view (not both stripped): `diff` is an effective-config diff, the
+    same reason override layers are merged on both sides, so flipping a
+    review step from `spawn: optional` to `required` since the ref shows
+    the gate it adds, and an unchanged manifest diffs clean.
+  - **F3 (correctness, MEDIUM):** `harness remove hook
+    require-review-evidence --force` printed no warning at all: the
+    round-2 `derivedGateReferences` was only populated on the dry-run
+    path, hard-coded `[]` on the write path, and never rendered by the
+    CLI on either. It is now populated on both paths and the CLI prints
+    `(forced removal disables the workflows[]-derived merge gate for:
+    <workflows>; ...)` on stderr for `--dry-run --force` and for the
+    real `--force` write.
+  - **F4 (security, LOW):** `trigger.extract` was not part of the dedupe
+    key, so a hand-authored block policy on the derived surface that
+    extracted `PR_NUMBER` from a wrong path counted as equivalent,
+    suppressed the derived gate, and evaluated its own
+    `review:${PR_NUMBER}` against an unresolved variable; under
+    `risk.degraded_fail_posture: fail_open` the merge went through with
+    "template variables unresolved". A differently-extracting policy no
+    longer dedupes (both gates apply, fail-safe) and the overlap warning
+    names the mismatch (`trigger.extract differs (...)`).
+  - **F5 (docs, LOW):** `docs/okf/debug-verb-selection.md` cited
+    `docs/for-agents.md` line 249 for the `dry-run` row; that is the
+    table separator since the round-2 wording landed, the row is line
+    258. Re-pointed and re-stamped.
+  - **F6 (docs, LOW):** the round-1 paragraph above still described the
+    original surface-key-only dedupe ("does not double-intercept"),
+    contradicting the round-2 F1 bullet; corrected in place.
+  - **F7 (tests, LOW):** the `when:`-scoped and `operator_only` weakness
+    reasons of the overlap finder were untested; two cases now assert the
+    exact `reason` (the `operator_only` branch is unreachable from a
+    parsed manifest, which the schema forbids together with `requires:`,
+    and is pinned via a hand-built policy object).
+  - **F8 (maintainability, LOW):** the duplication pin stays at 111
+    (round 2's raise, accepted); this round adds no clone (`doctor`'s
+    Workflows section now calls the same `checkWorkflows` aggregate
+    `validate` runs instead of re-listing the checks, which also gives
+    `doctor` the round-2 `checkWorkflowMergeBeforeReview` warning it was
+    missing).
+  - **New (correctness, LOW):** a hand-authored policy whose NAME equals
+    a derived policy's name is not deduped by name (dedupe keys on
+    surface, not name), so the derived view carried two policies with one
+    name and every by-name reader (`explain`, `explain-policy`, `audit`,
+    `diff`) silently resolved to the hand-authored one. This fires both
+    when the hand-authored policy is on a different surface and when it
+    is on the same surface but weaker (the latter also reported as an
+    overlap by `checkWorkflowGateWeakOverlap`; the two checks are not
+    mutually exclusive). `validate`/`doctor` now error on the collision
+    (`checkWorkflowDerivedNameCollision`); the runtime still enforces
+    both. (Review round 3 follow-up, F3: the message's original "it does
+    not intercept the same surface" claim was wrong in the same-surface
+    case; corrected, with a same-surface test added.)
+  - **F6 follow-up (performance/docs, LOW):** `checkWorkflowGateWeakOverlap`'s
+    message now also notes that a deliberately-not-suppressed overlap means
+    the same event round-trips the ledger twice (once per policy), so the
+    hook's `budget_ms` should be checked against two policies, not one,
+    since `requiredHookBudgetMs` does not scale with the policy count.
+  - Residuals, named rather than fixed: (a) the `.last-apply` manifest
+    snapshot now stores the hand-authored view and the restart-hint
+    reader re-derives with the current code, so a snapshot written by a
+    release without the derivation compares equal and emits no phantom
+    "hooks changed" hint (a derivation-logic change between releases is
+    therefore invisible to restart hints, by design: derived policies
+    do not touch `settings.json`); (b) `harness export` emits the
+    operator-declared manifest without the derived pair, `docs/CLI.md`
+    now says so and points at `list policies`; (c) the round-2 F4
+    residual stands: `mcp__agent-tasks__task_merge` and
+    `mcp__agent-tasks__task_finish` (`autoMerge`) remain ungated until
+    the follow-up task extends both the template pair and this
+    derivation; (d) `diff --since` derives both sides with the CURRENT
+    (working-tree) harness version's derivation logic, since the ref side
+    is parsed in-process rather than checked out and re-derived with its
+    own code, so a change to the derivation logic itself between harness
+    releases does not show up as a diff.
+
+- **Risk Gate: a new, environment-INDEPENDENT deletion-target gate closes the
+  dev-context gap where `gate-prod-destructive*` only fires once the resolved
+  environment is `production`** (task `d03af8f6`). Measured 2026-08-06 (re-
+  verified against 0.49.0): on a task branch (`environment: unknown`) an `rm
+  -rf` against ANY absolute path — a typo'd path, a stale variable, a
+  traversal that walks outside the intended scratch dir — ran unconfirmed,
+  because `risk.severity_at_least`/`risk.category_in` fail-close to
+  matched=true for an unclassified action, so an unscoped policy would
+  instead have gated every unrelated unclassified Bash call in every
+  environment (approval-spam, not a deletion-specific gate). New pieces,
+  additive alongside the existing production-scoped policies (nothing
+  existing changed semantics):
+  - `src/runtime/deletion-target-resolve.ts`: a pure, no-nested-quantifier-
+    regexes (no ReDoS surface) tokenizer (no shell spawned) that recognizes
+    `rm -r*`/`-f*`, `find ... -delete`, and `git clean -f*` across EVERY
+    shell segment of a command and statically resolves each target: an
+    unexpanded `$VAR`/`~`, a relative path, or a `..`-traversal that
+    normalizes outside every declared root is UNRESOLVABLE; an absolute
+    path strictly inside a declared `risk.safe_deletion_roots` entry is
+    not.
+  - `risk.safe_deletion_roots` (new manifest key, schema default `["/tmp",
+    "/private/tmp"]` — the two spellings this harness's own scratchpad
+    convention can use, since macOS symlinks `/tmp` to `/private/tmp`).
+  - `when.action.deletion_target_unresolvable` (new `policy.when:` clause,
+    `src/runtime/when-eval.ts`, only the literal `true` is a meaningful
+    value): deliberately NOT subject to the "unknown is not safe"
+    fail-close the four existing risk/environment clauses share — it reads
+    the deletion resolver's own verdict, not the Risk Classifier's
+    `classified` state, so it never falls back to matched=true for an
+    unrelated unclassified command. This is what lets the new policy below
+    be environment-independent without becoming a blanket gate.
+  - `gate-dev-unsafe-deletion` (new policy, `harness init --template full` +
+    `docs/examples/full-manifest.yaml`, additive alongside
+    `gate-prod-destructive`/`-approval`): `require_approval` on
+    `action.deletion_target_unresolvable: true`, unblocked via `harness
+    approve risk --scope deletion` (its own ledger tag — see the review
+    round 2 fixes below).
+  - The dead alternation in the shipped `dangerous-shell` classifier's
+    `rm\s+-rf\s+(/|/var|/data|/mnt|~)` pattern (the bare `/` branch already
+    matches every absolute path, so `/var`/`/data`/`/mnt` never
+    independently contribute a match) is documented, not changed — see the
+    comment in `docs/examples/full-manifest.yaml`; it only feeds the
+    existing production-scoped policies, out of this task's scope.
+
+  **Review round 2** (same task, before this line shipped) found the
+  first cut had five measured gaps against a real transcript corpus.
+  Fixed, all additive on top of the pieces above:
+  - **Multi-segment recognition (was HIGH):** round 1 inspected only the
+    command's FIRST shell segment — 656 of 1215 real deletion commands in
+    the operator's own transcript corpus (54%) chained the deletion behind
+    `&&`, a newline, or a prior `VAR=value &&` assignment and ran
+    completely ungated. The resolver now walks EVERY segment
+    (`segmentViewOf`, `src/runtime/command-normalize.ts`) and gates if ANY
+    recognized segment is unresolvable.
+  - **Cross-tier ledger tag (was HIGH, security):** `gate-dev-unsafe-
+    deletion` used to reuse `gate-prod-destructive-approval`'s
+    `risk-approved:${SESSION_ID}` tag, so approving one routine dev-context
+    `rm -rf dist` silently cleared the production approval gate for the
+    rest of the session — measured live (`kubectl delete namespace
+    payments` went BLOCKED -> ALLOWED after one unrelated dev approval).
+    The dev arm now writes/consults its own
+    `risk-approved:deletion:${SESSION_ID}` tag, via a new `harness approve
+    risk --scope deletion` option (`src/cli/approve/risk.ts`); the bare
+    `harness approve risk` keeps writing only the production tag,
+    unchanged.
+  - **Wrapper-head coverage (MEDIUM):** `sudo`/`doas`/`command`/`env`/
+    `time`/`timeout`/`nice`/`xargs` in front of the deletion verb, and
+    `git -C <path> clean -f*`, all now recognize the wrapped verb — a
+    bare `xargs rm -rf` (no explicit operand — the target comes from
+    stdin) is UNRESOLVABLE, not "not a deletion" the way an ordinary
+    operand-less `rm -rf` is.
+  - **Root-itself / bare-glob targets (MEDIUM):** `rm -rf /tmp`, `rm -rf
+    /tmp/`, and `rm -rf /tmp/*` used to resolve as safe — a target must
+    now be STRICTLY deeper than a declared root, and a bare `*`/`**` final
+    path segment is never resolvable regardless of the root it sits under.
+  - **Obfuscated flags (LOW):** every token is decoded with
+    `decodeShellWord` (`src/runtime/shell-word.ts`) before any verb/flag/
+    `-delete` comparison, so `find /x $'\x2ddelete'` / `git clean
+    $'\x2df'` are recognized.
+  - **`safe_deletion_roots` hygiene (LOW):** a bare `/` (or `//`, ...)
+    entry is now a schema parse error (it would match every absolute
+    path, silently defeating the allowlist); a non-absolute entry or one
+    containing `$`/`~` is a new `harness validate` warning
+    (`checkSafeDeletionRootsSyntax`, `src/cli/validate/checks.ts`).
+  - Deduplicated the tokenizer against `kubectl-target-parse.ts` instead
+    of tolerating the round-1 clone pair: `firstSegment` is now exported
+    there (pure visibility change) and imported; `check:duplication`'s
+    pinned baseline is back at 109 (was raised to 110 in round 1).
+
+  **Review round 3** (same task): round 2's own hand-rolled recognition —
+  a second, independently-drifting copy of the wrapper-peeling and
+  segmentation `src/runtime/command-normalize.ts` already ships,
+  flag-aware and pinned for the `bash_match` gate — still failed OPEN on
+  a new class every round (round 1: first-segment-only; round 2:
+  flag-blind wrapper peeling plus bare-`&`/brace/`exec`/`nohup`). Rebuilt
+  on top of `command-normalize.ts`'s own machinery instead of a third
+  hand-rolled enumeration:
+  - **Shared wrapper peeling (structural fix):** the resolver now reuses
+    `command-normalize.ts`'s exported `peelWrapperPrefixes` (the same
+    loop `canonicalizeSegment` uses for `git`/`gh`/`npm`/`harness`
+    trigger recognition) instead of its own narrower copy — closing every
+    flag the round-2 peeler missed: `sudo -u <user>`, `sudo -E`, `sudo
+    --preserve-env`, `nice -n <n>`, `nice -<n>`, `env -i`, `env -u <VAR>`,
+    `timeout -k <n> <duration>`, `timeout --signal=<sig> <duration>`.
+    `exec` and `nohup` are now peeled too — added to
+    `peelWrapperPrefixes` itself so both this gate and the `bash_match`
+    trigger gate benefit. `xargs` (never peeled by `command-normalize
+    .ts` — its own argv is not simply "the command to run") stays a
+    local concern, but its own flags (`-0`, `-n1`, ...) are now peeled
+    too, via the newly-exported `peelGenericFlags`.
+  - **Dual-arm segmentation (structural fix):** segments now come from
+    BOTH of `command-normalize.ts`'s arms — `segmentViewOf` (primary) AND
+    the new `segmentViewOfAmpAware` (the bare-`&` alphabet
+    `normalizeCommandAmpAware` already uses for trigger matching) —
+    combined additively and de-duplicated by text, closing `echo hi & rm
+    -rf /home/x` (a background job the primary alphabet does not split
+    on).
+  - **`find -exec`/`-execdir` recognition (MEDIUM):** `find /home -exec
+    rm -rf {} +` / `find /home -execdir rm {} \;` are now recognized,
+    targeting `find`'s own search-path operand (never the `{}`
+    placeholder).
+  - **Redirection operands (MEDIUM):** a `>`/`>>`/`<`/`<<`/`<<<` token
+    (glued or bare, optional leading fd number) is no longer collected as
+    a target — `rm -rf /tmp/x >/dev/null 2>&1` no longer reports
+    `/dev/null` as an unresolved target.
+  - **`find` search-root equality (MEDIUM, premise corrected round 4 —
+    see below):** `find`'s own search-root operand EQUALLING a declared
+    root now resolves; `rm` keeps the strict-deeper-only rule.
+  - **Brace groups and subshells:** `{ rm -rf /home/x; }` (leading `{` /
+    trailing `}`/`;` token stripped before the head test) and `(rm -rf
+    /home/x)` (trailing `)` stripped from the segment's last token) are
+    now recognized.
+  - **`safe_deletion_roots` hygiene, widened (LOW):** an entry that
+    lexically NORMALIZES to the filesystem root (`/.`, `/./`,
+    `/tmp/..` — not only the bare-`/` spelling round 2 caught) is now
+    also a schema parse error; `checkSafeDeletionRootsSyntax`
+    (`src/cli/validate/checks.ts`) now falls back to
+    `DEFAULT_SAFE_DELETION_ROOTS` for a hand-built `Manifest` missing
+    `risk`/`risk.safe_deletion_roots` instead of throwing.
+  - `gate-dev-unsafe-deletion`'s position in `FULL_TEMPLATE` (after both
+    `gate-prod-destructive` and `gate-prod-destructive-approval`) is now
+    pinned by a test — `src/runtime/intercept.ts` evaluates policies in
+    array order.
+  - NOT COVERED, named rather than left implicit (pinned as
+    `toBeNull()`): `bash -c '...'`/`sh -c '...'`, `eval "..."`, a script
+    FILE the agent writes and executes, `shred`/`rmdir`/`unlink` (real
+    deletion verbs outside this task's closed head-token set), and
+    `npm run clean` (a script NAME, not a literal deletion verb).
+
+  **Review round 4** (same task): four more measured gaps against the
+  round-3 recognition surface, plus reviewer-flagged output-quality
+  issues. Fixed:
+  - **`xargs` separated-value flags (HIGH):** round 3's `xargs` flag
+    peeling (`peelGenericFlags`, boolean-only) stranded a SEPARATED flag
+    value where the verb was expected, so `xargs -I {} rm -rf {}`,
+    `xargs -n 1 rm -rf`, `xargs -P 4 rm -rf`, `xargs -a list rm -rf`, and
+    `xargs -d '\n' rm -rf` all ran UNGATED (only the glued spellings —
+    `-I{}`, `-0`, `-n1` — happened to gate). Replaced with a forward
+    scan (bounded by the token count) for the first token that is itself
+    a recognized deletion-verb head, skipping `xargs`'s entire flag
+    vocabulary uniformly instead of enumerating it.
+  - **`find <root> -delete` root-itself premise was FALSE (MEDIUM):**
+    round 3 claimed `find <root> -delete` "only ever deletes entries
+    strictly inside `<root>`" — measured wrong: a BARE `find /tmp
+    -delete` (no test predicate) removes `/tmp` itself too, on both GNU
+    findutils and BSD find. Root-equality now resolves ONLY when the
+    expression carries at least one non-action test predicate (`-name`,
+    `-iname`, `-path`, `-ipath`, `-regex`, `-type`, `-mtime`, `-mmin`,
+    `-newer`, `-size`, `-empty`, `-user`, `-perm`, or `-maxdepth`/
+    `-mindepth` with a value `>= 1`), so `find /tmp -name '*.log'
+    -delete` still resolves but a bare `find /tmp -delete` now gates.
+    Corrected the same premise in `src/schema/risk.ts`, `docs/risk-
+    gate.md`, and this file.
+  - **`&>`/`>&` redirection forms (MEDIUM):** round 3's redirection
+    regexes matched only tokens starting with an optional fd number
+    followed by `<`/`>`, missing bash's combined stdout+stderr forms
+    `&>`/`&>>` (glued) and `>&`/`<&` (bare) — `rm -rf /tmp/x
+    &>/dev/null` and `rm -rf /tmp/x >& out` were GATED with the
+    redirect target misread as a second, unresolvable target. Both
+    regexes now cover the full set.
+  - **`stripRedirections` was unpinned in `resolveFind`/
+    `resolveGitClean` (MEDIUM, test gap):** added `find /tmp >out -name
+    '*.log' -delete` and `git clean -fd /tmp/x >/dev/null` fixtures;
+    removing the strip from either resolver now turns both red.
+  - **Duplicate/spurious targets (LOW):** `combineVerdicts` now
+    de-duplicates verdicts by exact `(verb, targets)` before combining,
+    replacing round 3's "accepted cosmetic quirk" — `nohup rm -rf
+    /home/x &` and `rm -rf /home/x 2>&1 | tee log` now name their
+    target once, not twice. This also fixed a real correctness bug the
+    round-3 note did not anticipate: for `rm -rf /home/x & rm -rf
+    /home/y`, the primary segmentation arm (which does not split on a
+    bare `&`) used to keep parsing past a dropped `&` into the SECOND
+    invocation's own tokens, collecting its verb `rm` as a spurious
+    literal target; `stripRedirections` now stops (rather than merely
+    skipping) at the first bare `&`, so that command no longer lists
+    `rm` as a target.
+  - **Backtick command substitution added to NOT COVERED (LOW):** `` `rm
+    -rf /home/x` `` is pinned alongside the other unparsed-substring
+    shapes (`bash -c '...'`, `eval "..."`).
+  - **`exec`/`nohup` wrapper enumerations updated (LOW):** `docs/okf/
+    policy-engine-producer-wiring.md` and `src/cli/init/templates.ts`'s
+    `deny-kill-switch-bypass` comment now list `exec`/`nohup` alongside
+    the other peeled wrappers (both were already peeled by
+    `peelWrapperPrefixes` since round 3; only the doc/comment
+    enumerations were stale). `docs/okf/pause-vs-gate-kill-switch.md`
+    gained a corresponding update note and timestamp re-stamp.
+  - **`docs/okf/policy-engine-producer-wiring.md` frontmatter
+    `description:` quoted (LOW):** the unquoted value's embedded
+    `risk.degraded_fail_posture: fail_open` colon-space made the
+    frontmatter block unparseable YAML (`npx okf-kit check docs/okf`
+    reported `frontmatter-required`); quoting fixes it.
+  - **`MAX_NORMALIZE_LENGTH` fallback added to NOT COVERED (LOW):** a
+    command past 100,000 characters falls back to the pre-round-2
+    single-first-segment contract — a recognized deletion verb in a
+    LATER segment of such an oversized command goes unrecognized. Named
+    explicitly rather than left implicit.
+  - `docs/risk-gate.md`'s "Dev-context deletion gate" section trimmed:
+    the round-by-round narrative and the measured BLOCKED->ALLOWED
+    incident now live only here (this file) and in the run's own
+    review-round notes; the reusable doc states the rule plus a pointer
+    to this entry.
+
+  **Review round 5** (same task): the round-4 root-equality exception for
+  `find` (a search-root operand EQUALLING a declared root resolved when
+  the expression carried a test predicate) is REMOVED. It had already
+  been corrected once, in round 4 — the halt rule fired on a second
+  consecutive round finding the same premise wrong, so the exception
+  itself was cut rather than patched a third time: every recognized verb
+  (`rm`, `find`, `git-clean`) now requires a target STRICTLY deeper than
+  a declared root, no exceptions. `find /tmp -name '*.log' -delete` and
+  `find /tmp -mindepth 1 -delete` now gate, same as `rm -rf /tmp`; a
+  scratch cleanup strictly inside a session directory (e.g. `find
+  /private/tmp/claude-<uid>/<session>/x -delete`) is unaffected. Three
+  more measured gaps, fixed alongside:
+  - **`xargs` replace-string aliasing (MEDIUM, security):** `xargs -I{}
+    rm -rf /tmp/{}` and `cat list | xargs -I% rm -rf /tmp/%` used to
+    resolve ALLOWED — the placeholder token textually starts with a safe
+    root, but its real value is substituted from stdin at runtime, never
+    statically known. `findXargsVerbHead`'s forward scan now also
+    captures the invocation's own replace-string (the value of `-I`/
+    `-i`, glued or separated, default `{}`), and every resolver treats a
+    target token containing it as unresolvable, the same as an
+    unexpanded `$` token.
+  - **`find`'s path-operand collection did not stop at `!`/`(`/`)`
+    (LOW):** `findPathOperands` now also stops at `!`, `(`, and `)` (a
+    `-`-prefixed token, `-not` included, already stopped it) so a
+    negation or grouping operator is never mistaken for — or emitted as
+    — a search-root operand.
+  - **Glued trailing `&` double-counted a target (LOW):** `rm -rf
+    /home/x&` used to yield `targets == ["/home/x&", "/home/x"]` — the
+    primary segmentation arm's segment keeps the bare `&` glued to its
+    last raw token (it is not one of that arm's boundary characters),
+    while the amp-aware arm's matching segment has none, so the two
+    arms' verdicts textually differed and `combineVerdicts`'s dedup
+    (keyed on exact target text) did not collapse them. A new
+    `stripTrailingAmp` (the same treatment `stripTrailingParen` gives a
+    subshell's trailing `)`) strips a single trailing bare `&` from a
+    segment's last raw token before target collection, so the command
+    now yields `["/home/x"]` once.
+
+  **Review round 6** (same task; escalated after five rounds each found
+  a new fail-open on the permissive side of the recognition layer).
+  Decision D-023: ANY `xargs`-wrapped deletion is unresolvable, without
+  parsing `xargs` at all — `xargs` appends or substitutes stdin-supplied
+  operands at runtime, so `echo /home/x | xargs rm -rf /tmp/known`
+  deletes `/home/x` while the round-5 module resolved it ALLOWED. The
+  round-5 replace-string plumbing (`-I`/`-i` capture, default `{}`) is
+  deleted; the bounded forward scan to the first deletion-verb head
+  stays, and every resolver returns unresolvable when `xargsWrapped`,
+  listing a synthetic `(xargs-supplied target, not statically known)`
+  entry plus any explicit operand, none resolved. The round-2 pin
+  "`xargs rm -rf /tmp/known` resolves" is flipped to GATED; `xargs ls`/
+  `xargs echo`/`xargs -I{} mv {} /trash` stay unrecognized; `xargs echo
+  rm -rf /home/x` (which only prints) is gated — an accepted, documented
+  over-gate of the forward scan. A path-qualified `/usr/bin/xargs` is
+  now recognized too (round 5 matched the bare word only). An
+  adversarial audit of 232 shapes against the built module (permissive
+  side: quoting, escapes, globs, traversal, substitution, symlink
+  spellings, keywords, wrappers; fail-safe side: every legitimate
+  inside-root shape) found and closed these CLASSES, each pinned:
+  - **Symlink-following spellings (HIGH):** a trailing `/` or `/.` on a
+    target follows a symlinked directory into its target (measured on
+    macOS: `rm -rf <link>/` removed the link's TARGET directory), and a
+    `..` component is resolved PHYSICALLY through a symlinked component
+    (`/tmp/<link>/../y` lands under the link's target), so both are now
+    unresolvable — the round-1 pin "`rm -rf /tmp/a/../b` resolves" is
+    flipped. `find -H`/`-L`/`-follow` make the whole `find` verdict
+    unresolvable. Still not visible lexically, named as a ceiling: a
+    symlink named without a trailing slash (`rm -rf /tmp/link/y`).
+  - **Globs that expand to `..` (HIGH):** `rm -rf /tmp/.*`, `/tmp/..*`,
+    `/tmp/.?/x`, `/tmp/.*/foo`, `/tmp/.[.]` resolved ALLOWED; `find
+    /tmp/.* -delete` traverses `/tmp/..` = `/`. A path component starting
+    with an explicit `.` whose remainder can glob-match `.` is now
+    unresolvable (`globComponentCanMatchDotDot`, a minimal fnmatch over
+    `*`/`?`/`[...]`); measured on bash 3.2 with and without `dotglob`
+    that `*`, `[.][.]`, `.[!.]*`, and `.??*` cannot match `..`, so those
+    (and `rm -rf /tmp/x/*.log`) stay resolvable.
+  - **Brace expansion, backtick and extglob (MEDIUM):** `rm -rf
+    /tmp/{..,x}` expands to `/tmp/..`; `` rm -rf /tmp/`cat<f` `` is a
+    single token with a command substitution; `rm -rf /tmp/@(..)/x` is
+    cut at the `(` boundary leaving `/tmp/@` as the target. A token
+    containing `{` or a backtick is unresolvable (this also subsumes
+    the `xargs`/`find` `{}` placeholder), and when the command contains
+    an extglob opener a target ending in `?`/`*`/`+`/`@`/`!` is
+    unresolvable.
+  - **`find -exec` payload operands (HIGH):** `find /tmp/x -exec rm -rf
+    /home/y \;` resolved ALLOWED — only the search root was a target.
+    The payload's explicit operands (every non-flag token other than the
+    exact `{}`, up to `+` or the end of the segment) are now targets;
+    `-ok`/`-okdir` are recognized alongside `-exec`/`-execdir`.
+  - **`find` continuation after `\;` (HIGH):** `;` is a segment
+    boundary, so `find /home/x -exec echo {} \; -exec rm -rf {} \;`
+    put the deleting `-exec` in a segment headed by `-exec`, which was
+    unrecognized. A `find`-headed segment's search roots are now carried
+    (per segmentation arm, in command order) into a directly following
+    segment headed by a `find` primitive. This also covers the escaped
+    grouped expression `find /home \( -name a -o -name b \) -delete`
+    that round 5 reported as unrecognized; the QUOTED `'('` spelling
+    stays a pinned residual (the cut lands inside the quoted run). The
+    orphaned `\`/`'`/`"` token the cut leaves behind is dropped from
+    both the roots and the payload operands.
+  - **`git clean` (HIGH):** `git -c clean.requireForce=false clean -d`
+    deletes without `-f`, but `command-normalize.ts` canonicalizes it
+    to `git clean -d` before the resolver sees it — a `clean
+    .requireForce` mention anywhere in the raw command text now counts
+    as a force flag (case-insensitive; also covers
+    `GIT_CONFIG_PARAMETERS` and a same-command `git config`). `git
+    --no-optional-locks clean -fdx /home/y` was unrecognized (an
+    un-canonicalized global option sat where `clean` was expected) —
+    `git`'s global options are now skipped locally, `-c`/`--config-env`
+    with their value. `git clean -f -e /tmp/x` resolved ALLOWED with
+    `/tmp/x` mistaken for a pathspec while git cleaned cwd —
+    `-e`/`--exclude` now consume their value.
+  - **Shell keywords and locally-peeled wrappers (MEDIUM):** `if true;
+    then rm -rf /home/x; fi`, `for f in a; do rm -rf /home/x; done`, `!
+    rm -rf /home/x`, `f() { rm -rf /home/x; }`, `exec -a name rm -rf
+    /home/x` (the shared peeler treats `-a` as boolean, leaving `name`
+    as the head), and `busybox`/`toybox rm -rf /home/x` were all
+    unrecognized. Leading `if`/`then`/`else`/`elif`/`while`/`until`/
+    `do`/`!`/`{`/`)`/`){` tokens are stripped; `exec -a <name>` and the
+    two multi-call binaries are peeled locally.
+  - **Inert tests and false positives from round 5 (LOW):** the
+    oversized-command pin gains a positive assertion (a deletion in the
+    FIRST segment past `MAX_NORMALIZE_LENGTH` still gates, the `/tmp`
+    variant allows); `( rm -rf /home/x )` reported the lone `)` as a
+    second target and `( rm -rf /tmp/x )` was GATED by it — a bare
+    `(`/`)` token is dropped during `rm`/`git clean` target collection
+    and `findPathOperands`'s unreachable `(`/`)` stop is removed (`!`
+    kept); `rm -rf /tmp/x # cleanup` was GATED on `#` and `cleanup` —
+    a `#` word now ends the segment, as it does for bash; `rm -rf
+    /tmp/x\ y` was GATED as two operands — the tokenizer now honours a
+    backslash escape; `find -P /tmp/x -delete` was GATED with `.` as the
+    root — `find`'s leading options are skipped. The quote-unaware amp
+    arm's duplicate reporting for a quoted literal `&` is noted next to
+    the dedup comment as a reporting-only, fail-closed ceiling.
+  - NOT COVERED additions, pinned: `env -S '...'`, `find ... -exec sh
+    -c '...'`, the quoted-paren grouped `find`, a `case` arm, runners
+    outside the wrapper set (`parallel`, `ionice`, `chrt`, `taskset`,
+    `caffeinate`, `flock`, `strace`, `ssh`, `docker exec`, `chroot`, `su
+    -c`, `watch`), a symlink named without a trailing slash, and a
+    `clean.requireForce` override set outside the command text.
+
+### Fixed
+
+- **Risk Gate: a narrow, secrets-excluding kubectl read-only verb floor
+  fixes the AC5 false positive waived at task `a7eb1a71`** (task
+  `da823721`). Once an explicit `--context`/`--namespace` resolves
+  `environment: production` (`a7eb1a71`), the pre-existing "unknown is
+  not safe" rule made a harmless `kubectl get pods --context prod-eu-1`
+  require approval exactly like `kubectl delete namespace payments
+  --context prod-eu-1` does. `isReadOnlyKubectlCommand`
+  (`src/runtime/read-only-bash.ts`) floors a curated set of read verbs
+  (`get`, `describe`, `logs`, `top`, `api-resources`, `api-versions`,
+  `version`, `cluster-info`, `explain`, `auth can-i`) to `low` severity
+  in `classifyRisk`'s built-in floor (`src/runtime/risk-classifier.ts`),
+  UNLESS the command reads `--raw` or the resource argument mentions
+  "secret" in any form (`get secret`, `get secrets`, `get
+  secret/<name>`, `describe secret`, `-o yaml`/`-o json` on a secret) —
+  a prod Secret read stays approval-gated. Any other kubectl subcommand
+  stays fail-closed, unchanged. The floor is wired ONLY into the Risk
+  Classifier: it is a separate function, not folded into the shared
+  `isReadOnlyBashCommand` / `isReadOnlyBashPipeline` the
+  understanding-gate PreToolUse blocker and the solution-acceptance
+  write-guard also consume, so every kubectl command still requires an
+  approved Understanding Report there, unchanged — proven by a real
+  end-to-end test (`tests/cli/pack-hook-pre-tool-use.test.ts`), not just
+  the classifier unit. See docs/risk-gate.md's "Kubectl read-only verb
+  floor (decision record, task `da823721`)" for the full decision, the
+  `get all` / `explain secret` sub-decisions, and the blast-radius
+  reasoning.
+  Round 2 (review): three bypasses of the secrets exclusion were
+  measured end-to-end ALLOW and fixed. `-f`/`--filename`/`-k`/`--kustomize`
+  on `get`/`describe` now disables the floor (a manifest file or
+  kustomization directory can select a Secret/ConfigMap this module
+  cannot read). Any token after `kubectl` containing `$` now disables
+  the floor (`$VAR`/`${VAR}`/`"$VAR"` leave the resource-type argument
+  unresolved in the raw command text). `configmap`/`configmaps`/the
+  bare `cm` abbreviation now get the same exclusion as `secret` (a
+  common credential store in practice). Also: the `--raw` reject now
+  applies to every floored verb, not just `get`; the timing test now
+  measures a floored 30-flag run instead of the fail-closed short-circuit
+  path; and docs/risk-gate.md's `get all` claim is narrowed to kubectl's
+  built-in resources (a CRD can opt into the `all` category via its own
+  `spec.names.categories`), citing the runnable `kubectl
+  api-resources --categories=all` check rather than an upstream file
+  path this task did not run against a live cluster.
+  Round 3 (review): brace expansion (`kubectl get s{e..e}cret ...`),
+  glob patterns (`get s*`, `get sec[r]et`), and endpoint/identity
+  redirection (`--server`/`-s`/`--kubeconfig`/`--token`/`--as`, pre- or
+  post-verb) were measured end-to-end ALLOW, the same class of bug as
+  round 2's findings recurring a third time on top of a metacharacter-
+  by-metacharacter exclusion list. `isReadOnlyKubectlCommand` is
+  redesigned around two ALLOWLISTS instead: every token after `kubectl`
+  must match a plain-word shape (closing brace expansion, globs,
+  quoting, and escaping, and superseding the round-2 `$`-token and
+  `decodeShellWord`-decoding checks, both now redundant), and every flag
+  token must be drawn from an explicit per-verb read-flag allowlist (or
+  a small global-flag allowlist) — `--raw`, `--filename`/
+  `-k`/`--kustomize`, and every endpoint/identity flag
+  (`--server`/`-s`/`--kubeconfig`/`--token`/`--as`/`--as-group`/
+  `--user`/`--cluster`/`--tls-server-name`/`--insecure-skip-tls-verify`)
+  are simply absent from every verb's allowlist, closing all three as
+  one mechanism instead of three separate checks. `--as`/`--as-group`
+  impersonation, floored in rounds 1-2, is now refused (behavior
+  change, folded into the endpoint/identity set). See docs/risk-gate.md's
+  "Round 3: from metacharacter exclusions to allowlists" for the halt
+  rationale and the new residual-risk bullet on the secret/configmap
+  exclusion being a two-kind resource-TYPE denylist (not a
+  credential-content scan: Pod env literals and Flux
+  `HelmRelease`/Argo CD `Application` `values:` blocks stay floored;
+  mitigation is an operator-defined classifier pattern).
+
 ## [0.49.0] - 2026-08-26
 
 ### Fixed