ceo-orchestration 1.0.0

package/.claude/plans/PLAN-143/architect/round-1/consensus.md

@@ -0,0 +1,108 @@
+---
+plan: PLAN-143
+round: 1
+round_verdict: PROCEED
+created_at: 2026-06-20
+critics: 3
+verdicts: [ADJUST, ADJUST, ADJUST]
+vetoes: 0
+consensus_adjustments: 7
+---
+
+# PLAN-143 — Round-1 consensus
+
+Three critics, **all ADJUST, zero VETO/REJECT**. The design is coherent; every
+finding is a framing/sequencing improvement, not a mutually-exclusive design
+conflict. Folded into the plan in this round → **PROCEED** (design-coherent).
+Synthesis consumed the anonymized critique text only (Critic-A/B/C); mapping in
+`anonymization-map.md`.
+
+## Consensus findings (2+ critics)
+
+- **CF-1 — Item-1 framing is factually wrong; reframe to inventory-accuracy
+  reconciliation (A+B+C).** The five named "governance kill-switches"
+  (`CEO_TRUST_BYPASS`, `CEO_CANONICAL_GUARD_DISABLE`, `CEO_ALLOW_NO_VERIFY`,
+  `CEO_HOOKS_DISABLE`, `CEO_SKIP_HOOKS`) have **zero live `getenv`/`environ`
+  consumers** — they appear in the inventory only as forbidden-family tokens
+  inside `_lib/env_persist_allowlist.py` (the deny-list whose job is to exclude
+  them), and the bypass class is already governed by **ADR-143**. So item 1 is
+  *reconcile inventory drift* (cross-check each of the 25 against the existing
+  governed allowlists, classify, regen), NOT "review 25 unreviewed surfaces"
+  and NOT a new ADR. The `env-inventory-check.py` `TOKEN_RE` is a documented
+  *superset* scanner doing exactly its job.
+
+- **CF-2 — Item-3 release-coupling needs explicit sequencing against verdict
+  regeneration (A+B+C).** `audit_emit.py` is manifest line 22; editing it mutates
+  the recomputed `inputs_hash`, invalidating every existing verdict — masked
+  today only by `CEO_PAIR_RAIL_VERDICT_OPTIONAL=1`. Shipping item 3 as a bare
+  allowlist edit *hides a fresh increment* of the coupling behind the flag
+  PLAN-142 set to drain the OLD coupling; when the flag flips to `0`, the first
+  release hard-fails. Item 3 MUST ship **paired with** verdict regeneration
+  (recompute inputs_hash, GPG-sign, within the 24h TTL of the next tag) OR
+  **wait** — split it out (D1) so the other 3 items are not held hostage.
+
+- **CF-3 — Test ACs are vacuous; require positive survival-assertions (B+C).**
+  "a test asserts … / no exception" passes even with the bug present (item 2's
+  probe is inside a fail-open `try/except`). The tests must assert the *positive*
+  contract: item 2 → the shim path takes the intended branch AND emits no
+  AttributeError breadcrumb; item 3 → the event RETAINS `exit_code` AND no OTHER
+  field newly survives (allowlist did not widen) AND the scrub drop-counter stops
+  logging the forbidden-field warning.
+
+- **CF-4 — Peel item 4 off + keep it a FLOOR (A+C).** Item 4 (INSTALL.md
+  tests-floor) is non-guarded + not CI-gated (`verify-counts.sh --no-tests`) →
+  ship it standalone NOW, not behind the canonical ceremony. And set a robust
+  **floor** (`11000+`, live 11752 ≥ 11000) — do NOT pin the exact ~11.7k (that
+  defeats the floor rule and re-breaks on normal suite churn).
+
+## Single-critic insights — KEPT
+
+- **SK-1 (B) — Inventory regen must preserve the deny-list disjointness
+  invariant.** The regen must not enroll any override/escape-hatch name into a
+  *persist allowlist* (only into the descriptive inventory census);
+  `test_env_persist_allowlist.py` must still pass post-regen.
+- **SK-2 (B) — Clamp/coerce `exit_code`** (bounded int, e.g. 0..255) when adding
+  it to the allowlist; inline provenance comment at the edit site.
+- **SK-3 (C) — Two-channel emit divergence.** The typed `emit_codex_invoke_dispatched()`
+  does not accept `exit_code` while the generic `emit_generic(...)` callsite does.
+  Reconcile (route through the typed emitter OR document the asymmetry).
+- **SK-4 (C) — npm/ mirror scope.** Every coupled file has an `npm/.claude/`
+  twin. The plan must state whether the npm mirror is in scope (apply edits to
+  both, or a sync step regenerates it).
+- **SK-5 (C) — verdict 24h TTL.** Verdict regen + release tag must fall in the
+  same 24h window (ADR-103), else item 3's hash fix still can't ship.
+- **SK-6 (A) — item-2 default locus = hasattr/getattr-guard** (smallest blast
+  radius; keeps `_EmitCapture` a pure test double).
+- **SK-7 (A/C) — durability/recurrence gap.** Item-1 + item-4 drift recur because
+  neither is CI-gated. Name the structural gap (a periodic `--check` assertion);
+  deferring the gate itself is acceptable.
+
+## Single-critic insights — REJECTED / DEFERRED
+
+- **D3 "kill-switch ADR" (REJECTED).** Critic-B: an ADR here would be actively
+  harmful (it would imply the bypasses exist + are governed when they are not,
+  and could be cited to launder override-family names). The existing inline
+  governance + ADR-143 + the classification note suffice.
+- **Pin INSTALL.md to exact ~11.7k (REJECTED).** Defeats the floor rule.
+- **OPTIONAL→0 closure in this plan (DEFERRED, but named).** Critic-C U4: the
+  plan should explicitly decide scope; folded as a §4 note that closing the
+  transition is OUT of scope but item 3's verdict-regen is its prerequisite.
+
+## Plan adjustments (applied to PLAN-143 this round) — 7
+
+1. §1 item-1 reframed to inventory-accuracy reconciliation (CF-1).
+2. §2 D2 framing corrected: BOTH loci re-touch the manifest (Critic-C R2/NH4).
+3. §3 AC-1 rewritten: classify {consumed | forbidden-family-mention | descriptor};
+   preserve deny-list disjointness; per-name review BEFORE regen (CF-1/SK-1/MF5).
+4. §3 AC-2/AC-3 hardened with positive survival-assertions + clamp + nothing-else-leaked (CF-3/SK-2).
+5. §3 AC-3 gains a hard sequencing clause: pair with verdict regen OR wait (CF-2/SK-5).
+6. §3 AC-4 set to floor `11000+`, documented as floor-by-design (CF-4).
+7. §4 D1/D2/D3 ratified + new D4 (item-3 sequencing) + D5 (durability gap) + npm-scope + OPTIONAL→0 scope note.
+
+## Round verdict
+
+**PROCEED — design-coherent.** No further round needed (no REJECT, no design
+deadlock; all folds are additive). Reminder (DEBATE-SCHEMA §13): this certifies
+internal design coherence ONLY — it does NOT authorize shipping. PLAN-143
+execution still requires V1 (deterministic tests/gates) → V2 (Codex pair-rail,
+now restored) → V3 (Owner GPG). Plan moves to `status: reviewed`.

package/.claude/plans/PLAN-143/architect/round-1/devops-engineer.md

@@ -0,0 +1,228 @@
+# PLAN-143 — Round 1 critique — DevOps & Platform Engineer
+
+> Lens: CI/CD impact, release coupling, verification mechanics, operational
+> testability. One of 3 independent critics; I have not seen the others.
+
+## 1. Verdict
+
+**ADJUST**
+
+## 2. Summary
+
+The four items are real, correctly triaged by nightly dimension, and three of
+four are CI-neutral (env-inventory regen is not release-gated; the rotation
+probe is already fail-open; the tests-floor doc is explicitly `--no-tests` in
+CI Governance). The one item with genuine release-coupling blast radius is
+**item 3**, and the plan's preferred locus (D2 — extend the `audit_emit.py`
+allowlist) materially compounds the pair-rail release-coupling debt that
+PLAN-142 deliberately parked behind `CEO_PAIR_RAIL_VERDICT_OPTIONAL=1`. The plan
+acknowledges this in prose ("fold into the existing transition window") but does
+not give it the sequencing rigor it needs, and several ACs are written as
+"a test asserts" without naming the test rail or the assertion mechanics. Adjust
+to (a) sequence item 3 explicitly against verdict regeneration, and (b) harden
+the verification language on items 1–3.
+
+## 3. Risks
+
+- **R1 (release-coupling, item 3 — the load-bearing risk).** `audit_emit.py` is
+  line 22 of `pair-rail-inputs-hash-manifest.txt`. The verdict validator
+  (`validate-pair-rail-verdict.py:106 compute_inputs_hash`) computes
+  `inputs_hash` as `sha256(canonical_json({ path: git hash-object(path) }))`
+  over every manifest entry. Editing `audit_emit.py` (current
+  `git hash-object` = `6fc81824…`) changes that file's object hash → changes the
+  recomputed `inputs_hash` → **invalidates the declared `inputs_hash` of every
+  pre-existing verdict artifact** (`pair-rail-verdict-v1.16.0.md`,
+  `…-rc.1.md`). Today this is masked because `CEO_PAIR_RAIL_VERDICT_OPTIONAL=1`
+  is set as a GHA variable, so step 15 is `continue-on-error: true` and a
+  mismatch is a soft-fail. The risk is **latent**: the day someone flips the
+  variable back to `0` (the documented end-of-transition action), the FIRST
+  release after this edit hard-fails step 15 unless a fresh verdict bound to the
+  post-edit tree was regenerated. This is exactly the coupling PLAN-142 put into
+  transition mode; item 3 as written deepens it rather than draining it.
+- **R2 (double-touch of the manifest, item 3 alt-locus).** The kernel
+  alternative (`check_pair_rail.py`, manifest line 27) is ALSO in the manifest.
+  There is no "manifest-free" fix locus for item 3 — both candidate files are
+  coupled. So D2's framing ("canonical preferred to avoid a second KERNEL-HARD-
+  DENY ceremony; the cost is re-touching the manifest") is half-stated: BOTH
+  loci re-touch the manifest. The real trade is canonical-GPG ceremony vs
+  kernel-hard-deny ceremony — the inputs_hash invalidation is identical either
+  way. The plan should not imply the kernel path avoids the release-coupling.
+- **R3 (two-channel emit divergence — unseen by the plan).** There are two emit
+  paths. The breadcrumb at `check_pair_rail.py:571` uses
+  `emit_generic("codex_invoke_dispatched", exit_code=…)`. The structured helper
+  `emit_codex_invoke_dispatched()` (`audit_emit.py:9564`) does not even accept an
+  `exit_code` kwarg. Extending only `_CODEX_INVOKE_DISPATCHED_ALLOWLIST`
+  (line 9555) fixes the generic path but leaves the structured helper
+  asymmetric. A fix that adds the field to the allowlist without reconciling the
+  two producers is incomplete and will read as inconsistent to the next auditor.
+- **R4 (verify-counts floor brittleness, item 4).** The `tests` rule is a
+  *floor* (`grep '(\d+)\+ tests'`). The live count moves every time a test file
+  is added/removed. Pinning INSTALL.md to the exact `~11.7k` (one of D-options)
+  will re-break `verify-counts.sh` (full) the next time the suite grows or
+  shrinks — re-creating this exact nightly RED. The whole point of the floor
+  rule (per the script header: "so adding a test never churns the docs — AC6")
+  is defeated by an exact number. This is a verification-mechanics trap.
+- **R5 (env-inventory regen captures unintended surface — item 1).** `--generate`
+  is a blind snapshot: it writes whatever the token scan currently finds, with
+  zero gate on whether a name is *intended*. If even one of the 25 NEW names is
+  an accidental/typo/dead reference, `--generate` launders it into the
+  "reviewed" inventory and the drift signal goes green while the footgun
+  persists. The S218 footgun class this instrument exists to catch is precisely
+  "an env surface nobody reviewed" — a mechanical regen without the per-name
+  review defeats the instrument's purpose.
+
+## 4. Must-fix (blocking)
+
+- **MF1 — Sequence item 3 against verdict regeneration (directly answers OQ3).**
+  Add an explicit ordering AC: item 3's canonical edit to `audit_emit.py` MUST
+  be followed, in the same plan, by regenerating the pair-rail verdict bound to
+  the post-edit tree (new `inputs_hash` over the updated manifest file set)
+  BEFORE the next release tag is cut. Do NOT ship item 3 and leave a stale
+  verdict relying on `CEO_PAIR_RAIL_VERDICT_OPTIONAL=1` to paper over the
+  resulting `inputs_hash` mismatch — that converts a transition-mode bridge into
+  a permanent crutch. If verdict regeneration cannot happen this plan,
+  **item 3 must wait** until it can (see OQ3 answer below). The plan currently
+  says "fold into the existing transition window" — that is necessary but not
+  sufficient; the window is for *parent_sha* legacy bridging, not for shipping
+  fresh inputs_hash drift under cover.
+- **MF2 — Name the verification rail + assertion for each test AC.** AC
+  `[P1][audit-errors-02]` and `[P2][audit-errors-04]` say "a regression test
+  covers…" / "a test asserts…" without specifying WHERE. Per repo convention
+  (memory: `_lib/tests/` is canonical-guarded; `hooks/tests/` is not), state the
+  target test file and that new tests subclass `TestEnvContext` + use
+  `mock.patch.dict` (never `os.environ[...]=`), or the env-hygiene gate rejects
+  them. For item 3 specifically, the assertion must verify the emitted event
+  RETAINS `exit_code` AND that the `_scrub_ceo_boot_event` drop-counter
+  (`audit_emit.py:5854`) no longer logs the forbidden-field warning — assert on
+  the survival, not just on "no exception".
+- **MF3 — Make the item-2 regression test exercise the real defect, not a
+  no-op.** The probe at `spool_writer.py:1729` is ALREADY inside a
+  `try/except Exception` fail-open block (lines 1726–1746). That is why the
+  AttributeError surfaces as a benign breadcrumb, not a crash. A regression test
+  that merely asserts "no exception escapes" will pass even with the bug present
+  (the outer try swallows it). The test MUST assert the *positive* contract:
+  given a shim object lacking `_rotate_if_needed_safe`, the probe takes the
+  intended branch (rotation correctly skipped/handled) AND does NOT emit the
+  AttributeError breadcrumb to `audit-log.errors`. Otherwise the AC is
+  vacuously satisfiable.
+- **MF4 — Item 4: keep the floor a floor.** Reject the "pin to exact ~11.7k"
+  option. Set INSTALL.md to a robust floor (e.g. `11000+`) that is currently
+  satisfied (live 11752 ≥ 11000) and gives headroom so normal suite churn does
+  not re-trigger the nightly RED. Document in the AC that the value is a FLOOR by
+  design (cross-reference the verify-counts.sh header rule), so a future editor
+  does not "tighten" it back to exact and reintroduce the drift.
+- **MF5 — Item 1: gate the regen behind explicit per-name review.** The AC must
+  require that each of the 25 NEW names is individually classified
+  (intended-surface | dead-ref-to-remove) and that the kill-switch subset
+  (`CEO_TRUST_BYPASS`, `CEO_CANONICAL_GUARD_DISABLE`, `CEO_HOOKS_DISABLE`,
+  `CEO_SKIP_HOOKS`, `CEO_ALLOW_NO_VERIFY`) is documented at its consumer site
+  BEFORE `--generate` runs. The regen is the last step, not the work. As written
+  (`status=current` after regen) the AC is satisfiable by a blind snapshot,
+  which is the failure mode the instrument exists to prevent.
+
+## 5. Nice-to-have
+
+- **NH1.** Add a post-merge verification step to the regression AC `[P2]`: run
+  `env-inventory-check.py --check`, `verify-counts.sh` (full, no `--no-tests`),
+  and a targeted re-emit of `codex_invoke_dispatched` locally, then re-run
+  `nightly-hygiene` and capture the GREEN. The plan already gestures at this
+  ("a follow-up nightly run returns GREEN") — make the three individual
+  reproducible commands explicit so the verification is mechanical, not
+  narrative.
+- **NH2.** For item 3, reconcile the two-channel emit (R3): either route the
+  breadcrumb through `emit_codex_invoke_dispatched()` with a new `exit_code`
+  param, or leave one producer and document the other as intentionally
+  field-narrow. Pick one explicitly so the next auditor does not re-flag the
+  asymmetry as a new finding.
+- **NH3.** Consider peeling item 4 off (D1) and shipping it as a trivial
+  doc-only commit NOW. It is not canonical-guarded, not CI-gated, and has zero
+  coupling to items 1–3. Bundling a 1-line doc fix into a canonical-GPG +
+  verdict-regen ceremony needlessly widens that commit's blast radius and slows
+  the doc fix.
+- **NH4.** Record (ADR or plan note) that BOTH item-3 loci re-touch the manifest
+  (R2), so the next person choosing a fix locus is not misled by D2's framing
+  into thinking the kernel path avoids the inputs_hash coupling.
+
+## 6. Unseen (gaps the plan does not address)
+
+- **U1 — npm/ mirror divergence.** Every coupled file exists twice:
+  `.claude/…` AND `npm/.claude/…` (audit_emit.py, check_pair_rail.py,
+  env-inventory-check.py, verify-counts.sh, the manifest, env-inventory.json all
+  have an `npm/` twin). The plan names only the `.claude/` paths. If the npm
+  mirror is shipped/validated independently, fixes applied to one tree and not
+  the other create a fresh drift the next sweep (or a packaging step) will flag.
+  The plan must state whether the npm mirror is in scope and, if so, that each
+  edit is applied to both trees (or that a sync step regenerates the mirror).
+- **U2 — verdict TTL interaction.** Step 15 enforces `--max-age-hours 24` on the
+  verdict (`generated_at` within 24h, ADR-103). Even if item 3 regenerates the
+  verdict (MF1), a verdict authored more than 24h before the eventual GA tag
+  will fail the TTL independently of the inputs_hash fix. The plan should note
+  that verdict regeneration and the release tag must fall inside the same 24h
+  window — otherwise item 3 "fixed" the hash but the tag still can't ship once
+  `OPTIONAL` is flipped off.
+- **U3 — no rollback/abort path for the canonical ceremony.** Items 2+3 require
+  GPG-signed canonical edits to `_lib/spool_writer.py` and `_lib/audit_emit.py`.
+  The plan has no stated abort path if the canonical-edit sentinel ceremony
+  fails mid-flight (e.g. signer not in both rails per the GPG-cascade memory).
+  Note the bail-out: revert the working tree, no partial sentinel left behind.
+- **U4 — does flipping OPTIONAL→0 belong to THIS plan?** The plan treats
+  `CEO_PAIR_RAIL_VERDICT_OPTIONAL=1` as a fixed backdrop. But item 3 is the kind
+  of change that should ideally end the transition. The plan does not decide
+  whether closing the transition (var→0) is in scope or explicitly deferred. It
+  should say one or the other, so the transition-mode debt has an owner and an
+  exit, rather than drifting indefinitely.
+
+## 7. What I would NOT change
+
+- The triage-by-nightly-dimension structure and the honest provenance framing
+  (items 1-2-4 pre-date PLAN-142; item 3 is a PLAN-142 follow-up made observable
+  by the restored rail). This is accurate and well-sourced against the live
+  tree.
+- The correct identification that item 4 is NOT CI-gated (Governance runs
+  `verify-counts.sh --no-tests`) — verified: the `tests` rule is skipped under
+  `--no-tests` (`if metric == "tests" and no_tests: continue`). The plan's claim
+  is exactly right; do not "harden" this into a CI gate (it would make every
+  test add/remove a release blocker — wrong trade).
+- The fail-open posture of the item-2 probe. Do NOT convert the rotation probe
+  into a hard-failing path "for visibility"; the surrounding fail-open
+  `try/except` is correct framework doctrine (CLAUDE.md §4 fail-open on
+  infrastructure). The fix is to stop the AttributeError at the source, keeping
+  the fail-open envelope intact.
+- D2's preference for the canonical locus OVER the kernel locus for item 3 — on
+  ceremony-cost grounds that is the lighter path (canonical-GPG < kernel-hard-
+  deny). My objection (R2/NH4) is only to the *framing* that it avoids the
+  manifest coupling; the locus choice itself is reasonable.
+
+---
+
+### OQ3 — does item 3 compound the release-coupling debt, and should it wait?
+
+**Yes, it compounds it, and it should not ship as a bare allowlist edit while
+the transition window is open — it must ship *paired with* verdict
+regeneration, or wait.**
+
+Mechanically: `audit_emit.py` is a manifest input (line 22). The verdict's
+`inputs_hash` is `sha256` over `git hash-object` of every manifest file. Editing
+`audit_emit.py` mutates its object hash → mutates the recomputed `inputs_hash` →
+makes every existing verdict's declared `inputs_hash` stale. Right now
+`CEO_PAIR_RAIL_VERDICT_OPTIONAL=1` makes step 15 `continue-on-error`, so the
+mismatch is invisible. That is the trap: shipping item 3 under the transition
+flag does not *resolve* the coupling, it *hides a fresh increment of it* behind
+the same flag PLAN-142 set to drain the OLD coupling. When the Owner flips the
+flag back to `0` (the transition's whole purpose), the first release after this
+edit hard-fails step 15.
+
+So the disposition is conditional, not a flat "wait":
+- **If this plan can regenerate the verdict** (recompute `inputs_hash` over the
+  post-edit tree, GPG-sign, land it within the 24h TTL of the next tag) → item 3
+  may proceed, with MF1 as a hard sequencing AC.
+- **If verdict regeneration is out of scope** for this plan → item 3 should
+  **wait** until the regeneration (or the OPTIONAL→0 closure) is scheduled,
+  because a bare allowlist edit silently grows the very debt the transition flag
+  exists to retire. The other three items have no such coupling and should not
+  be held hostage to item 3 — split it out (D1) if it must wait.
+
+This is the single most consequential sequencing decision in the plan, and it is
+why my overall verdict is ADJUST rather than ACCEPT.
+
+VERDICT: ADJUST

package/.claude/plans/PLAN-143/architect/round-1/proposal.md

@@ -0,0 +1,48 @@
+---
+plan: PLAN-143
+round: 1
+created_at: 2026-06-20
+note: "Written post-hoc — the anti-CEO-overhead hook blocked the original pre-spawn write; the round-1 critics read the full PLAN-143-repo-hygiene-debt.md draft directly. This captures the PRE-FOLD thesis they critiqued (the plan has since been adjusted per consensus.md)."
+---
+
+# PLAN-143 proposal — repo-hygiene debt (2026-06-20 nightly sweep)
+
+Full plan: `.claude/plans/PLAN-143-repo-hygiene-debt.md`. Distillation of the
+PRE-FOLD draft the round-1 critics evaluated.
+
+## Thesis
+
+The post-PLAN-142 `nightly-hygiene` sweep (over merge `8a1fc68`) returned RED.
+PLAN-142 itself is clean. The RED is **repo debt the general sweep exposed** —
+3 of 4 items pre-date PLAN-142. This plan collects those 4 items so they are
+*governed* (reviewed + sequenced) rather than fixed ad-hoc. It executes nothing;
+it is a draft seeking a design-coherence verdict.
+
+## Scope — the 4 items (as critiqued, pre-fold)
+
+1. **env-var inventory drift (P1)** — 25 NEW consumed env names absent from the
+   2026-06-13 inventory, framed as spanning model-routing + "governance
+   kill-switches" + lifecycle vars; proposed remediation = review + regen.
+2. **spool_writer rotation-probe AttributeError (P1)** on the `_EmitCapture`
+   shim → rotation silently skipped; canonical-guarded file.
+3. **codex_invoke_dispatched drops exit_code (P2)** — not in the audit_emit
+   allowlist (ADR-153 class); PLAN-142's restored rail made it observable.
+4. **INSTALL.md tests-floor stale (P2)** — `12000+` vs live ~11.7k; not CI-gated.
+
+## Decisions proposed (pre-fold)
+
+- D1: batch items 2+3 under one canonical ceremony; 1+4 independent.
+- D2: prefer canonical `audit_emit.py` over kernel `check_pair_rail.py` for item 3.
+- D3: whether the kill-switches warrant an ADR.
+
+## Open questions put to critics
+
+- OQ1: batching 2+3 correct, or split by kernel/canonical locus?
+- OQ2: do the kill-switches need an ADR?
+- OQ3: is re-touching the pair-rail inputs-hash manifest acceptable while
+  `CEO_PAIR_RAIL_VERDICT_OPTIONAL=1` is in transition?
+- OQ4: scope creep, or a missing debt dimension?
+
+(Outcome: all 3 critics ADJUST, 0 VETO → PROCEED; 7 adjustments folded. The
+biggest correction: OQ2/D3's "kill-switch" premise was factually wrong — see
+`consensus.md` CF-1.)

package/.claude/plans/PLAN-143/architect/round-1/security-engineer.md

@@ -0,0 +1,224 @@
+# PLAN-143 — Round 1 critique — Staff Security Engineer
+
+> Critic lens: security blast radius of each debt item, with VETO authority
+> over auth/governance-surface changes. Focus: the governance kill-switches
+> (item 1) and the audit_emit allowlist (item 3, ADR-153-class scrub control).
+> One of 3 independent critics; I have not seen the others.
+
+## 1. Verdict
+
+**ADJUST.**
+
+The plan is directionally sound and correctly treats the audit allowlist and
+the canonical-guarded files as security-relevant surfaces. But the item-1
+framing ("25 NEW consumed env vars … including governance kill-switches") is
+**factually wrong in a way that drives the security decision** (D3/OQ2), and
+the AC for item 1 must not be allowed to "document a kill-switch surface" that
+does not exist as a consumed surface. No VETO-magnitude defect blocks the plan,
+but two must-fix corrections are required before execution and one AC must be
+re-worded so it cannot regress a security control.
+
+## 2. Summary
+
+Items 2, 3, 4 are correctly diagnosed and the preferred fixes are the right
+security calls: hasattr-guard the rotation probe (item 2), extend the
+closed-enum allowlist on the canonical path rather than mutate the kernel
+(item 3), doc-only floor fix (item 4). Item 1's "kill-switch" framing is the
+one real problem: the five named switches (`CEO_TRUST_BYPASS`,
+`CEO_CANONICAL_GUARD_DISABLE`, `CEO_ALLOW_NO_VERIFY`, `CEO_HOOKS_DISABLE`,
+`CEO_SKIP_HOOKS`) have **zero live `getenv`/`environ` consumers** — they enter
+the inventory only as documentation tokens inside `env_persist_allowlist.py`,
+the very security control whose job is to *exclude* them. The plan must not
+"document a surface" that is actually a non-surface, and must not let the
+inventory regen quietly enroll override-family names as if they were features.
+
+## 3. Risks
+
+- **R1 (security-control misread → wrong remediation).** The env-inventory
+  checker (`env-inventory-check.py:58`, `TOKEN_RE`) is an explicit
+  *token-level superset* — its own docstring (lines 11-14) says it captures any
+  `CEO_*`/`CLAUDE_*`/`ANTHROPIC_*` token, "a superset of strictly-consumed
+  vars." The five kill-switches match because they are *named as forbidden
+  strings* in `env_persist_allowlist.py` (lines 32-45) and `_FORBIDDEN_KEY_SUBSTRINGS`
+  (lines 97-110). They are not consumed. Treating them as "unreviewed env
+  surfaces that must be documented where consumed" (plan §3 AC-1, §2 item-1)
+  inverts reality: they are the *output* of a deny-list, not an input surface.
+  If the remediation "documents the kill-switch surface" it manufactures the
+  appearance of a bypass that the codebase deliberately does not implement.
+
+- **R2 (inventory regen as a silent allowlist-of-bypasses).** Item-1's fix is
+  "regenerate `env-inventory.json` in WRITE mode after confirming each of 25
+  names." `env-inventory.json` is a generated data file, but regenerating it
+  *normalizes* every override/escape-hatch token into an "inventoried,
+  intended" set. There is a real test coupling here:
+  `test_env_persist_allowlist.py` grep-proves the persist-allowlist is disjoint
+  from the override/bypass families. The inventory regen must not become a
+  second, weaker registry that launders bypass-family names into "blessed."
+
+- **R3 (allowlist extension is a real security-control edit, correctly
+  flagged).** Item 3 extends `_CODEX_INVOKE_DISPATCHED_ALLOWLIST`
+  (`audit_emit.py:9555`). This is a deny-by-default scrub allowlist
+  (ADR-153-class: closed-enum + per-action allowlist, NEVER
+  `_EMIT_GENERIC_PASSTHROUGH`). The plan correctly treats extending it as a
+  justified-only change. The security cost of adding `exit_code` is low (a
+  bounded small int, no PII, no free-text), but the *precedent* — "we extended
+  an audit scrub allowlist to make a dropped field survive" — must be recorded
+  so the next extension is not waved through on this one's authority.
+
+- **R4 (manifest re-touch during a verdict-gate transition).** Item 3 (canonical
+  locus) re-touches `pair-rail-inputs-hash-manifest.txt` while the
+  `CEO_PAIR_RAIL_VERDICT_OPTIONAL=1` window is open (PLAN-142). A manifest
+  re-hash during a transition window is a window where the pair-rail's own
+  integrity reference is in motion — low blast radius (it is a hash manifest,
+  not an auth path) but it must be folded into the existing window, not opened
+  as a second uncoordinated edit.
+
+## 4. Must-fix (blocking)
+
+- **MF1 — Re-frame item 1; the five "kill-switches" are NOT a consumed
+  surface.** Before any inventory regen, the plan must state the verified fact:
+  these five names have zero `getenv`/`environ.get` consumers in the live tree
+  (I grepped all access patterns; the only hits are the `env_persist_allowlist.py`
+  docstring + `_FORBIDDEN_KEY_SUBSTRINGS` and the inventory JSON itself). The
+  `TOKEN_RE` superset is doing exactly what it documents. Item-1 work is an
+  **inventory-accuracy reconciliation**, NOT a "document the bypass surface"
+  task. Rewrite §2-item-1 and §3 AC-1 accordingly.
+
+- **MF2 — AC-1 must NOT require "kill-switch surfaces documented where
+  consumed."** As written, AC-1's clause "Kill-switch surfaces documented where
+  consumed" is unsatisfiable for the five names (there is no consumption site)
+  and, if forced, would push someone to *implement* a consumption site or write
+  documentation implying one exists. Replace with: "each NEW token is classified
+  as {consumed | forbidden-family-mention | descriptor}; forbidden-family
+  mentions are recorded as such and explicitly NOT enrolled as intended
+  surfaces." Any token that IS genuinely newly consumed (the `ANTHROPIC_MODEL`
+  routing trio is the plausible real-consumer subset) gets the actual review.
+
+- **MF3 — Inventory regen must preserve the deny-list disjointness invariant.**
+  The regen step must assert (or the plan must require a check) that no
+  override/escape-hatch/kill-switch-family name lands in any *allowlist*
+  (`ENV_PERSIST_ALLOWLIST`) as a side effect, and that
+  `test_env_persist_allowlist.py` still passes post-regen. Enrolling a name in
+  the *inventory* (a descriptive census) is fine; enrolling it in a *persist
+  allowlist* is a security regression. Make the plan name this boundary so the
+  two "allowlists" are not conflated during execution.
+
+- **MF4 — Item 3: keep the canonical (allowlist) locus; do NOT drop the kwarg
+  in the kernel.** From a security standpoint the correct fix is to make the
+  closed-enum allowlist *honestly reflect* the field the producer emits, not to
+  silently delete the producer's kwarg. Note that the live callsite
+  (`check_pair_rail.py:571`) uses the **generic** path
+  `emit_generic("codex_invoke_dispatched", exit_code=...)`, while the typed
+  emitter `emit_codex_invoke_dispatched()` (`audit_emit.py:9564`) does not even
+  accept `exit_code`. The fix must (a) add `exit_code` to
+  `_CODEX_INVOKE_DISPATCHED_ALLOWLIST`, (b) clamp/coerce it (`int`, bounded —
+  it is a process return code, range it to e.g. 0..255 or store the raw int but
+  type-guard it), and (c) the regression test must assert the field survives
+  AND that no *other* field newly survives (allowlist did not widen beyond the
+  one intended key). A scrub-allowlist edit without a "nothing else leaked"
+  assertion is how side-channel fields creep in.
+
+## 5. Nice-to-have
+
+- **NH1 — One-line provenance comment on the allowlist entry.** When `exit_code`
+  is added to `_CODEX_INVOKE_DISPATCHED_ALLOWLIST`, annotate it inline
+  (`# PLAN-143: process return code, bounded int, no PII`) so the next reviewer
+  sees the justification at the edit site, matching the existing per-entry
+  comment style in that file.
+
+- **NH2 — Record the allowlist-extension precedent in the plan's design notes.**
+  A two-line note: "extending a deny-by-default scrub allowlist requires (i) the
+  field is a closed type with no free-text/PII, (ii) a 'nothing else leaked'
+  test, (iii) named in the plan." This is cheap and stops the precedent from
+  being cited loosely later.
+
+- **NH3 — Item 2 regression test should assert the audit log still ROTATES on a
+  real writer.** The hasattr-guard fixes the AttributeError on the shim, but the
+  security-relevant property is that the audit log *does* rotate on the real
+  `audit_emit` object (an unrotated, unbounded audit log is its own integrity/
+  availability risk). Cover both the shim path (no raise) and the real path
+  (rotation still invoked).
+
+## 6. Unseen (what the plan does not address)
+
+- **U1 — Why did the rotation probe silently skip for ~2 days (since 2026-06-18)
+  with no alarm?** Item 2 is "rotation silently skipped." The security question
+  is not just "fix the AttributeError" but "what is the detection latency on a
+  governance component (audit-log rotation) failing?" The nightly sweep caught
+  it on 06-20; that is the *only* reason it surfaced. The plan should note
+  whether audit-rotation health has any signal other than the once-a-night
+  hygiene grep — and accept that residual gap explicitly if not.
+
+- **U2 — The 20 *non*-kill-switch NEW names are unexamined here.** I verified the
+  five named switches are non-consumed mentions; I did NOT verify the other 20
+  (model-routing trio, `CEO_COMPACTION_CONTINUITY`, `CEO_SUBAGENT_LIFECYCLE*`,
+  `CLAUDE_ENV_FILE`, etc.). Several of THOSE may be genuinely consumed and some
+  (`CLAUDE_ENV_FILE` — an env-file path; `CEO_COMPACTION_CONTINUITY` — a
+  kill-switch for the ADR-153 compaction hooks) are themselves security-adjacent.
+  The plan's "confirm each of the 25" must apply the MF2 classification to all
+  25, and the genuinely-consumed security-adjacent ones (`CLAUDE_ENV_FILE`
+  especially — a file-path env surface) deserve the real review the plan
+  reserves for "kill-switches."
+
+- **U3 — `emit_generic` vs typed-emitter divergence is a latent class.** The
+  fact that `check_pair_rail.py` reaches the audit wire via `emit_generic(...)`
+  with a kwarg the typed emitter never declared means OTHER `emit_generic`
+  callsites may be silently dropping fields against allowlists they don't know
+  exist. Item 3 fixes one instance; the plan does not ask whether this is a
+  pattern. A one-line follow-up note ("audit other `emit_generic` callsites for
+  silently-scrubbed kwargs") would be honest.
+
+## 7. What I would NOT change
+
+- **Keep the canonical locus for item 3 (D2).** Routing the field through the
+  `audit_emit` allowlist rather than the kernel (`check_pair_rail.py`
+  KERNEL-HARD-DENY) is the correct security call: it keeps the closed-enum scrub
+  contract intact and avoids a second kernel ceremony. The allowlist *is* the
+  right place for "which fields may travel" to be decided.
+
+- **Keep the deny-by-default scrub architecture.** Nothing here argues for
+  relaxing ADR-153's "dedicated `_scrub_` branch + per-action allowlist, NEVER
+  `_EMIT_GENERIC_PASSTHROUGH`." The bug is a *missing* allowlist entry, not an
+  over-strict control. Do not "fix" it by widening the passthrough path.
+
+- **Keep the env-inventory `TOKEN_RE` as a superset scanner.** It is doing
+  exactly what it claims. The fix is the *interpretation* of its output (MF1/MF2),
+  not the scanner. A superset census that over-reports is the safe failure
+  direction for a drift detector — do not narrow it to "only `getenv` calls"
+  and risk missing a real dynamically-constructed consumer.
+
+## OQ answers
+
+- **OQ2 (do the kill-switches need an ADR?):** **No** — and an ADR here would be
+  actively harmful. The five named switches are not implemented bypass surfaces;
+  they are forbidden-family *mentions* inside the persist deny-list. Writing an
+  ADR "documenting the kill-switch surface" would (a) imply these bypasses exist
+  and are governed when they do not, and (b) create a canonical record that the
+  next inventory regen could cite to justify enrolling override-family names.
+  The correct artifact is the existing inline documentation in
+  `env_persist_allowlist.py` plus the MF2 classification note in the inventory.
+  IF, during the "confirm each of 25" review, any name turns out to be a
+  *genuinely consumed* bypass with no current governing record, THAT specific
+  one earns an ADR — but none of the five flagged switches is that case on the
+  evidence I have.
+
+- **OQ3 (re-touching the pair-rail manifest while the verdict gate is in
+  transition):** Acceptable ONLY if folded into the existing
+  `CEO_PAIR_RAIL_VERDICT_OPTIONAL=1` window (plan §2 item-3 already says this).
+  Do not open a second, independent manifest re-hash. The manifest is a hash
+  reference, not an auth path, so blast radius is low — but coordinating it with
+  the open window keeps a single coherent integrity-reference transition rather
+  than two overlapping ones. Confirm the re-hash is re-signed under the same
+  ceremony that the window already requires.
+
+- **Security framing of extending the audit allowlist (item 3):** Justified.
+  `exit_code` is a bounded process return code with no PII, no free-text, no
+  endpoint/credential content — exactly the closed-enum shape the scrub control
+  is designed to permit. The extension makes the audit record *more* faithful
+  (the dispatch outcome is forensically relevant for the AML.T0050 dual-rail
+  technique this event maps to). The two guardrails are non-negotiable: the
+  field must be type-coerced/clamped (MF4), and the regression test must prove
+  the allowlist did not widen beyond this one key (MF4). With those, extending
+  the allowlist is the right, security-positive change.
+
+VERDICT: ADJUST