claude-projects/agent-builder/agent_sudo_design_decisions.md

# Agent-Sudo (projects DB id=176) — Design Grill-Me: Locked Decisions & Open Gaps

**Status:** ✅ GRILL-ME COMPLETE (2026-07-08, Opus 4.8/high). All decisions D1–D10 + gap-#5 cross-cutting LOCKED. Phased build prompts P0–P5 written to `agent_prompts.md`. NEXT = user review of prompts, then dispatch (not yet launched).
**Started:** 2026-07-08 (Opus 4.8 / high). Design doc for the pre-existing id=176 design; this file records the sub-design decisions the DB row left unspecified.

## Verified current state (checked live 2026-07-08)
- ❌ No Incus/LXC/LXD installed on server-01 (192.168.1.90) — P1 installs it
- ❌ No `command_audit` table in `projects` DB (table `infrastructure_projects` holds id=176) — P0 creates it
- ✅ `agent_test_results` table EXISTS in `api_business` DB (verified 2026-07-08); `automation_ideas` + `behavior_changes` also in `api_business` (NOT the empty `automation_ideas` DB)
- ✅ timeshift installed on server-01 (`/usr/bin/timeshift`)
- ✅ **Coolify RETIRED** (control plane stopped 2026-06-25) — deploy Agent-Sudo via plain docker-compose + Jenkins/Gitea, never Coolify; old bridge decommission (P5) = plain stop+rm, nothing to deregister. `coolify-proxy` = standalone Traefik (name kept for cloudflared). See [[project-coolify-traefik-retirement]].
- ✅ **N8N is NOT a caller of the bridge** — all 12 production workflows checked 2026-07-08, zero reference sudo-bridge (they use the now-dead Coolify API + Vault + bitwarden-bridge). So the D8 cutover shadow-diff has ZERO N8N surface; real callers = claude-code / background-agents / (future) Hermes via PROXY_CALLERS.
- ⚠️ **PORT CORRECTION to D8:** Agent-Sudo parallel port = **8084**, NOT 8083 (8083 is bitwarden-bridge). 8084/8085/8086/8087 free on primary as of 2026-07-08.
- Existing sudo-bridge: primary `sudo-bridge-drbjegv07256ki2lpfyr00n8` (port 8082 @192.168.1.88); server-01 bridge (Coolify UUID o2kz1puml1mmneyiqd96mouj, port 8082 @192.168.1.90); shared image `gitea.local/backtalk6858/sudo-bridge:latest`; API keys in Vault `secret/data/sudo-bridge` and `secret/data/sudo-bridge-server01`.

## LOCKED DECISIONS

### D1 — LXC mirror fidelity = COMMAND-SURFACE mirror
Same OS + package versions, same directory structure/paths, same users/sudoers/groups.
**No** live data, **no** running containers. Static, script-rebuildable, zero production-data exposure in sandbox.
(Rejected: state-replica mirror — constant drift, high upkeep, leaks prod data.)

### D2 — Tier-2 semantics = RE-TIER BY REPRODUCIBILITY
The current 4-level testing methodology tests *built automations*; sandbox-testing *arbitrary sudo commands* universally is impractical (would need the rejected faithful replica). So:
- **Reproducible ops** (file edits, package installs, permission/config changes) → run the **sandbox-execute** path in the command-surface mirror, using **static/dry-run validation** (parse, path resolution, forbidden-path check, `--dry-run`/`shellcheck`). Does not claim to prove live runtime behavior.
- **Live-service ops** (`docker`/`systemctl` restarts, network changes, live DB) → **skip the sandbox** (it structurally can't test them) → **Tier 3**: Timeshift snapshot → execute on target → full audit trail. If it fails, restore from snapshot and post-mortem from the audit record.
- Net: the LXC mirror earns its keep only for reproducible ops; live-service safety = snapshot + audit, not a theatrical sandbox run.

### D3 — LOCKED (confirmed 2026-07-08): rollback is scoped, not Timeshift; primary is stricter
Emerged from the "primary has no failover" question. Confirmed by user.
**Tier-4-on-primary = HARD REFUSE, interactive-session-only (option a).** No remote/NTFY approval path for primary Tier-4 — a command dangerous enough to be Tier-4 on the most critical host requires a human at a real terminal. (server-01 may still allow refuse-and-notify at its own lower tiers.)
**Long-term (Horizon B / redundancy vision):** once a redundant failover setup exists (Proxmox mirror + server redundancy/k3s — see [[project_server_redundancy_vision]], [[project_proxmox_test_server]]), revisit allowing full Timeshift restore — with failover, actual downtime → ~0%, so the "full restore = total downtime" objection dissolves and the primary posture can relax. Until then: conservative-by-default.
- **Default Tier-3 rollback = scoped command-specific undo**, captured BEFORE execution (file backup+restore of only touched files; package record+remove; container recovery via **Jenkins redeploy**, not system restore). Blast radius = only what the command touched.
- **Timeshift full-restore = emergency last resort ONLY** (OS-level corruption: dpkg/systemd/libs). User-in-the-loop, NTFY-urgent, accept full downtime. Agent-Sudo may TAKE the snapshot but must NEVER auto-restore primary. Rationale: full restore = total downtime for ALL services (incl. Vault/Authelia/secrets-proxy/media) + reboot, AND reverting /var/lib/docker risks stateful DATA LOSS (Postgres).
- **Host-aware tiering:** primary classifier stricter than server-01. Same command may be Tier-3 on server-01 but **Tier-4 (refuse → require interactive session)** on primary — especially anything touching critical security infra or stateful DB volumes.
- Long-term real fix = Proxmox test-mirror + server redundancy/k3s failover (already in vision). Until then primary posture = conservative-by-default.
- Feeds SUDO.md design (gap #1): the classifier must be **host-aware** (per-host tier overrides).

### D4 — LOCKED (2026-07-08): tier model has NO human-approval gate
The current sudo-bridge tier-2 "NTFY approve/deny then execute" gate is being **eliminated**, not preserved. Rationale (why — this is the whole point of Agent-Sudo):
- It didn't work: user misses NTFY notifications → command times out (900s APPROVAL_TIMEOUT), compounded by up to 5 parallel background agents competing for attention.
- It was theatrical: user was asked to approve commands they couldn't evaluate for safety → rubber-stamping, not a real gate.
- Real safety = testing/verifying the command (sandbox for reproducible ops; snapshot+audit+auto-verify for live ops), NOT a human who lacks context.
- Only human touchpoint remaining = Tier-4 hard-refuse → interactive session. Classifier must be tuned so Tier-4 is a near-zero-frequency event.

**Canonical tier model (safe→dangerous ascending; inverts the live bridge's 0=refuse):**
| Tier | Name | Behavior |
|---|---|---|
| 0 | auto-safe (read-only) | auto-execute, no snapshot |
| 1 | auto-reversible | auto-execute + capture scoped-undo |
| 2 | sandbox-first (reproducible ops) | dry-run/validate in LXC mirror → execute → audit |
| 3 | snapshot+execute (live-service ops) | scoped-undo (+Timeshift snapshot) → execute → full audit → auto-verify |
| 4 | hard-refuse | refuse → require interactive session (host-aware: stricter on primary) |

Migration note (P0/P4): existing allowlist.json uses live-bridge numbering (0=refuse,1=auto,2=NTFY-approve). Remap on cutover: live tier-1 → new tier-0/1 (by read vs write); live tier-2 → new tier-2 or 3 (by reproducible vs live-service); danger vetoes → new tier-4.

### D5 — LOCKED (2026-07-08): matching engine + seed corpus + audit-driven self-completing loop
**Engine = option (a):** evolve the existing model — ordered rule list, most-specific-first (first-match-wins), `fnmatch` globs (existing allowlist.json migrates ~1:1), regex danger-veto = auto-Tier-4. Each rule gains optional per-host tier override + verb class. Verb-heuristic is a *fallback default only*, not the primary engine.
**Miss behavior (host-aware, per D3):** allowlist miss on **primary → hard-refuse (Tier-4)** (primary never guesses); on **server-01 → verb-heuristic default** allowed (sandbox-side may guess). Ambiguous even under heuristic → Tier-4.
**Seed corpus:** pre-populate SUDO.md via internet research on the common command set we actually run + what each does → assign each a tier up front. Reduces cold-start Tier-4 misses.
**Audit-driven classification loop (the self-completing part — this is the training-data mechanism):**
1. Unknown command arrives. Reproducible-verb unknowns route to the **sandbox** (Tier-2 treatment) — NOT the live target. Live-service unknowns on primary → Tier-4 until classified (no blind execution on primary).
2. Run in sandbox → analyze the audit trail (exit code, output, stderr).
3. If it executes cleanly → evidence supports a tier; propose the classification.
4. If it fails because the sandbox is missing something (path/package/config/user) → analyze the audit trail to identify the gap → add it to the command-surface mirror **rebuild script** → rebuild → re-run. This makes the LXC mirror (D1) self-completing over time.
5. The AI evaluator (P3) produces a **proposed** tier + audit evidence and writes the rule into SUDO.md in a **`proposed` (inactive) state on BOTH hosts** — a proposed rule cannot be used to execute until reviewed. It fires a **low-priority NTFY** ("new proposed Agent-Sudo rule — load conversation <X> in an interactive session to review"). Rule becomes `active` only after the review discussion. Logged as training data throughout.
   - **Why this does NOT contradict D4:** D4 killed the blocking *execution*-approval gate (timed out, on live commands the user couldn't evaluate). This is a **non-blocking async review of a config/rule change** — nothing is stalled waiting on it (no timeout failure mode), it's low-frequency (meta-level), and it happens in a session where the user CAN evaluate it with Claude's help. Different mechanism, different risk profile.
   - Implementation detail (defer): NTFY must carry a stable conversation pointer for the review session (candidate: a dedicated `agent-sudo-rules` conversation, or the agent-builder conversation).

### D6 — LOCKED (2026-07-08): operating principle = minimize human involvement, not eliminate it
Until human-level AGI exists, reducing the user's involvement to exactly zero is not achievable. Design target for every autonomous system = **minimize** required human touchpoints, not **eliminate** them. Legitimate residual touchpoints (Tier-4 interactive execution; proposed-rule review) are kept deliberately, made non-blocking and low-frequency, and each is justified. (Candidate universal feedback memory — applies beyond Agent-Sudo.)

## OPEN GAPS (resume grill-me here)

### D7 — LOCKED (2026-07-08): LXC architecture on server-01
Verified live: both hosts = LMDE 7 "gigi" (Debian 13 trixie base), kernel 6.12.90; server-01 = 31GB RAM/27GB free, 173GB free disk, btrfs tooling present (no zfs), no LXC/LXD/Incus yet. Primary confirmed CLEAN of all testing infra (no LXC/sandbox/test containers; only prod postgres + vault; timeshift present = intended D3 snapshot tool).
- **Container tech = Incus** (Debian-trixie-native; profiles/limits/instant snapshots for cheap reset-to-baseline).
- **Base image = `images:debian/13` (trixie).** LMDE≈Debian under the hood; LMDE's deltas are desktop/theming, irrelevant to sudo command behavior. Confirmed acceptable by user.
- **Storage = btrfs pool** (loop-file or subvolume) for near-instant snapshot/rollback; fallback `dir` backend if root isn't btrfs.
- **Network = NAT via default `incusbr0`** — outbound works (nala/apt during classification tests), ZERO inbound LAN exposure (sandbox must not be reachable on 192.168.1.x).
- **Limits = 2 vCPU / 2GB RAM / 10GB disk each** (ephemeral scaffolds, no services).
- **Rebuild = one parameterized `build-sandbox.sh <primary|server-01>`** (D1 script-rebuildable; D5 loop appends missing deps). Differs per host only in package set + paths + users/sudoers.
- **P1 prerequisite = read-only host inventory** (the mirror spec): `dpkg --get-selections`, users/uids+groups+sudoers STRUCTURE (never secrets), relevant dir tree (`/opt/appdata`, `/data/coolify`, `/etc/...`). Both mirrors (`sandbox-primary`, `sandbox-server01`) run ON server-01; `sandbox-primary` mirrors production's command surface but never runs on production.

### D9 — LOCKED (2026-07-08): privilege + security model = FULLY AUTONOMOUS, no human arming
Hard constraint (user): must be fully autonomous — if the user is unavailable, automation must not stall. So NO human-arming gate on the execution path. Once full autonomy is required, "can the machine escalate on its own?" = yes (settled); security moves OFF access-gating (theater) ONTO the constraint layer.
**The reframe (the crux):** separate two powers —
- **EXECUTE an already-vetted command** → fully autonomous, no human ever, always available (Tiers 0–3).
- **EXPAND what's allowed** (new command / raise tier / widen allowlist) → the ONLY human touchpoint; rare, async, non-blocking (D5 proposed-rule review). The autonomous system CANNOT widen its own allowlist.
Attacker win = "run arbitrary dangerous command" ⇒ requires widening the allowlist ⇒ impossible autonomously; executor enforces danger-veto regardless. Full compromise of the smart brain ⇒ only inherits "run already-safe/reversible/audited commands" = bounded blast radius.
**Unavailability is NOT a single point of failure:** all Tier 0–3 automation runs with user asleep/away; only (a) activating a brand-new capability and (b) catastrophic Tier-4 wait for a human — both SHOULD wait.
**Privilege mechanism:** dumb root daemon everywhere (auth-agnostic — survives user's fingerprint→privacyIDEA MFA→YubiKey roadmap; never calls sudo/PAM). Both hosts = always-on SCOPED short-TTL AppRole (reuse existing rotate-and-revoke machinery; policy reads ONLY the one Agent-Sudo secret path). Bitwarden + OS-sudo-password both DROPPED from design (Bitwarden was only for the abandoned OS-password pull).
**Autonomous-security stack (all human-free):** least-privilege allowlist · dumb minimal root executor · independent re-validation (already in code) · signed/read-only SUDO.md (Vault transit — allowlist can't be silently widened) · scoped short-TTL AppRole · executor sandboxing (AppArmor/seccomp/systemd) · egress lockdown (executor has no outbound net) · append-only audit shipped off-box · **anomaly circuit-breaker that self-disarms** (watches own command rate/mix/failure spike → auto-stops Tier-3 + alerts — replaces the human panic button) · **dual-service concurrence on Tier-3** (independent second classifier must agree). Primary stays stricter (D3): larger Tier-4 set, catastrophic → refuse-to-human.
**New tool? NO.** All pieces already exist (allowlist+executor, Vault AppRole + transit signing, AppArmor/seccomp/egress free on host). Falco (runtime anomaly detection) / OPA (policy-as-code) = documented FUTURE-ENHANCEMENT candidates only — new tools add attack surface + maintenance for a solo operator.

### D10 — LOCKED (2026-07-08): Hermes as the always-on independent monitor (future layer)
Hermes (id=138, monitoring brain, local model on server-01, no Claude-API cost) is the natural home for the monitoring layers of D9 — layered on AFTER Agent-Sudo v1 ships.
**Security gains:** (1) Hermes IS the intelligent anomaly circuit-breaker/watchdog — reads the append-only audit stream, trips the breaker on anomaly, NTFYs user; being a SEPARATE process from Agent-Sudo = separation of duties (compromising Agent-Sudo ≠ compromising the watchdog). (2) The independent second opinion for dual-service Tier-3 concurrence. (3) Audit drift-detection + integrity monitoring (SUDO.md signature valid? AppArmor loaded? egress rules present? → tamper alert). 
**Usability gains:** (1) triages/batches the two human touchpoints (proposed-rule activation, Tier-4) into digestible evidence-backed decisions. (2) Drives the D5 sandbox-test-and-analyze loop autonomously so unknown-command classification is one-click-confirm by review time. (3) Self-healing: detects failed side effects → triggers scoped-undo or Jenkins redeploy (per project_jenkins_hermes_boundary).
**HARD BOUNDARY:** Hermes is on the MONITORING side only — observe/analyze/alert/trip-breaker/trigger-pre-vetted-recovery. Hermes NEVER gets execution privilege, NEVER widens the allowlist, NEVER runs arbitrary Tier-3+. If Hermes could command the executor freely it becomes the soft underbelly (compromise Hermes = escalate). Keeps automated dual-control intact: Agent-Sudo (has root, dumb about judgment) + Hermes (no root, smart about judgment) check each other.
**Build order:** Agent-Sudo v1 ships with a simple self-contained rule-based circuit-breaker; Hermes later augments/replaces it as the intelligent watchdog. Ties to project_hermes_exploration_day (capability-map after id=138).

## OPEN GAPS (resume grill-me here)
1. ✅ RESOLVED — SUDO.md classifier (see D4 tiers, D5 engine/seed/loop, D6 principle).
2. ✅ RESOLVED — LXC/Incus specifics (see D7).
3. ✅ RESOLVED — Cutover & rollback (D8).
4. ✅ DROPPED — Bitwarden ephemeral pull no longer in design (D9: Vault AppRole replaces it; no OS-password, no Bitwarden).
   [Security model fully resolved: D9 + D10.]

### D8 — LOCKED (2026-07-08): cutover sequence & rollback
Drop-in replacement: response contract stays identical (`POST /exec` Bearer → `{exit_code, output, ...}`; T4 refuse = 403 like today's allowlist-miss). Callers need zero changes; T2/T3 just add latency (sandbox/snapshot) transparently. D4 removes the tier-2 NTFY-approval block entirely.
- **Deploy order = server-01 FIRST, primary LAST** (user confirmed). server-01 = testing host, low blast radius, and hosts the sandbox LXCs (T2 local). Primary only after a clean 4-level pass on server-01.
- **Parallel run via ports:** Agent-Sudo stands up on **new port 8084** (⚠️ corrected 2026-07-08 from 8083 — 8083 is bitwarden-bridge) while old bridge keeps serving **8082** untouched. Shadow-validate (4-level gate on 8083 + replay known-safe commands through both, diff results). Callers stay on 8082 during validation → zero disruption.
- **Atomic swap when green:** flip Agent-Sudo to 8082, demote old bridge to 8083 hot-standby (kept running, not deleted).
- **Rollback = swap ports back** (old bridge one flip from resuming 8082). Retain old bridge container + image **14 days** before decommission (P5).
- **Primary cutover = MANUAL port-swap by user** in an interactive session (user confirmed). Agent-Sudo is built + validated autonomously everywhere; the final "make it live on production" flip on primary is user's hands on keyboard (per D3/D6). server-01 cutover = autonomous.
4. **Bitwarden ephemeral sudo password pull** — confirm path via bitwarden-bridge; never stored at rest.
5. ✅ RESOLVED (2026-07-08) — **Cross-cutting:**
   - **Per-phase rollback/abort** — matrix baked into the P0–P5 prompts (P0 drop-table / P1 incus-delete / P2 delete-repo / P3 revoke-policy / P4 port-flip-back / P5 re-pull-image). No phase is destructive to the OLD bridge until P5.
   - **Vault/N8N/Coolify dry-run paths** — Vault = additive `agent-sudo` policy + revoke-self smoke test (least-priv proof); N8N = ZERO surface (not a caller); Coolify = retired, Agent-Sudo deploys OUTSIDE it via Jenkins, P5 = plain stop+rm.
   - **Training-data logging** — 6 decision points → `command_audit` rows; GOLD label = AI-eval-proposal → human review verdict (`human_verdict`). P0 schema carries the fields.
   - **Blast radius per tier** — 0 minimal→3 medium/large→4 zero; capped on primary by shifting the dangerous middle up to refuse; **Tier-3-on-primary = highest-attention path** (most tests + dual-concurrence + tightest breaker). Full-compromise ⇒ inherits only already-vetted T0–3, cannot widen allowlist or reach T4.
   - **Blocks/unblocks** — id=176 has NO blocker (buildable now); no DB row lists it as a blocker (link is architectural, not recorded). Unblocks: Hermes self-healing (id=138), the sandbox-testing program (it's the first test of the harness), and any Horizon-B autonomous automation needing unattended privileged exec. Does NOT unblock the 12 broken N8N workflows (those need the Jenkins/Coolify-API migration).

## AFTER GRILL-ME COMPLETES
Write the **phased** background-agent prompt SET (NOT one monolith — see reasoning in session):
- P0: DB foundation (`command_audit` in projects + ensure `agent_test_results` in api_business) — design-complete, no server risk.
- P1: LXC/Incus setup + command-surface mirror build on server-01.
- P2: Python service = drop-in sudo-bridge replacement (same API), classifier reads SUDO.md, audit → command_audit.
- P3: Bitwarden ephemeral pull + Timeshift automation + AI evaluator (tier-2/3 flow).
- P4: deploy both servers behind old bridge, run 4-level gate.
- P5: decommission old sudo-bridge.

Opus+high prompt-craft upgrades over the Sonnet-era prompts (agent_prompts.md): bake in the 4-level test gate + agent_test_results logging (Sonnet's omitted it); split locked-contract from reference-implementation instead of embedding brittle literal scripts; right-size per-phase turn budgets; explicit "design is locked — do not redesign" block; per-phase rollback/abort criteria + idempotent pre-flight checks.

---

## CIRCUIT-BREAKER — REMAINING DECISIONS LOCKED (2026-07-15, grill-me Q3/Q4/Q5)

These close the last three open questions on task #149. D-CB1..D-CB4 (2026-07-14) fixed the
breaker's *concept*; these fix its *numbers, storage, and self-protection*. **#149 is now
design-complete — an implementing agent must NOT redesign any of this.**

### D-CB5 — LOCKED: benign-trip threshold = 3 tier-3 failures / 15-min SLIDING window / PER-HOST
- **Sliding, not fixed.** A fixed window lets failures straddle the boundary (2 at the end of
  window 1 + 2 at the start of window 2 = 4 failures, no trip). Sliding closes that.
- **Per-host, not global.** The hosts have different roles (primary = production, server-01 =
  sandbox); a sandbox failure burst must not disarm production tier-3. Decisive reason: a global
  counter needs cross-host state, which recreates the **#173 failure class** (server-01's safety
  depending on primary ⇒ drop primary to disarm server-01). Per-host adds no new cross-host edge.
- **Known, accepted cost:** an attacker probing BOTH hosts gets 2× budget before a benign trip.
  Accepted because probing is a **tier-4 signal**, which latches hard via D-CB1 regardless of this
  counter. The benign counter only ever governs broken scripts — and broken scripts are per-host.
- Threshold governs the BENIGN path only. Blast radius + re-arm still per D-CB1/D-CB2:
  benign ⇒ stop **tier-3 only**, auto re-arm after cooldown w/ exponential backoff on repeat;
  attack (any tier-4 attempt, or repeated trips inside one window) ⇒ **full read-only, human-only
  reset, NTFY urgent.**

### D-CB6 — LOCKED: breaker state = LOCAL APPEND-ONLY EVENT LOG, state DERIVED by replay
`/var/lib/agent-sudo/breaker.log` (0600 root, append-only), one JSON event per line:
`{ts, host, event: tier3_fail|TRIP|REARM|RESET, cause: benign|attack, scope: tier3|readonly, cmd_id}`

- **State is never stored — always `replay(log)`.** Consequence that matters: a daemon restart
  replays the log and the breaker is STILL TRIPPED. In-memory state would make
  **restart = free reset = bypass** (the trap Q4 existed to catch).
- **Local only. No Vault, no Postgres.** Both live on primary ⇒ server-01 would depend on a remote
  host for its own local safety state, and Vault-sealed/pg-down would mean *no breaker at all*.
  Same #173 class as D-CB5's global-counter rejection. State must survive restart AND not add a
  cross-host edge; local storage is the only option meeting both.
- **Append-only over a mutable `breaker.json` — because the daemon is root.** Root can rewrite any
  local file, so "tamper-proof" is theater ([[feedback-autonomous-security-constrain-not-gate]]).
  A mutable state file can be silently set back to `armed` leaving no trace. An append-only log
  cannot be *edited* into a lie, only **truncated** — and truncation is **evident** (log shrinks,
  audit trail has a hole). This converts *impossible-to-tamper* (false) into *tampering-is-visible*
  (true and enforceable). Constrain, don't gate.
- Free wins: trip/reset events are labelled **training data**; and the replay boundary is the **D10
  seam** letting Hermes assume trip-classification/reset later without a rewrite.

### D-CB7 — LOCKED: self-cannibalization ⇒ host_override TIER-4 in CODE, BOTH hosts, whole Set B surface
Found live during #145: `systemctl restart agent-sudo-daemon` routed THROUGH Agent-Sudo has the root
daemon kill its own executor mid-request — post-exec verify/audit can never complete. **The command
destroys its own witness.** Structural; `SNAPSHOT_ENABLED` does not touch it.

Refuse in code (a `host_override`, NOT merely a SUDO.md rule) on **both** hosts:
- `systemctl restart|stop|disable|mask agent-sudo-daemon`
- edits to `/etc/systemd/system/agent-sudo-daemon.service`
- writes to `agent-sudo/bridge/SUDO.md`
- writes to `/var/lib/agent-sudo/breaker.log`  ← **new Set B member created by D-CB6**

- **Why the whole surface, not just `restart`:** the reason restart is forbidden is D-CB4 **Set B** —
  the unit env is where `SUDO_MD_VERIFY_ENFORCE` lives, so self-restart *is* the gate-disarm
  primitive. But `stop`/`disable`/`mask`/unit-file-edit all reach the same place, and D-CB6's log
  makes "reset the breaker" a one-line write. Blocking only `restart` blocks one door in an open frame.
- **Why code-level, not a SUDO.md rule:** *a rule that lives in the file it protects is not a
  constraint, it is a suggestion.* (SUDO.md is signed, but host_override must not depend on the
  gate it exists to protect.)
- **Why both hosts (rejecting tier-4-primary/tier-3-server-01):** server-01 is where Agent-Sudo
  changes get PROVEN. A gate behaving differently in test than in prod means the sandbox stops
  predicting production — the one host that proves the gate would be the one host not running it.
- **Known, accepted cost:** nobody can restart the daemon through Agent-Sudo, including for
  legitimate deploys — a human needs a shell. That is **Set B working as designed**: human-only
  *even though fully recoverable*, because automating it removes the ceiling. Per D6 (minimize, not
  eliminate) this is a *near-zero-frequency* touchpoint, not a stall.

**XREF:** #149 (impl), #146 (primary cutover), #173 (same cross-host class — still OPEN, and
D-CB5/D-CB6 both deliberately avoid adding to it), D-CB1/D-CB2 (benign-vs-attack drives both blast
radius and re-arm), D-CB4 Set B, D9, D10, CA-D7.

### D-CB8 — LOCKED (2026-07-15): WHICH tier-4 sources are attack signals (closes D-CB1's open sub-decision)
D-CB1 says "any tier-4 attempt => attack latch" and explicitly left open: *"each trip signal must be
classified benign-noise vs attack at design time."* THIS IS THAT DECISION. It is load-bearing:
`app.py` reaches tier-4 from THREE different sources and **one of them is routine operation.**

| tier-4 source (`d.source`) | breaker signal | why |
|---|---|---|
| `danger_veto` | **ATTACK LATCH** (read-only) | matched a DANGER_PATTERN — attack-shaped |
| host_override (D-CB4 **Set B**) | **ATTACK LATCH** (read-only) | an attempt to disarm the gate itself |
| `miss_primary_refuse` | **NONE** (audit only) | **just an unlisted command** |

**Why `miss_primary_refuse` must NOT latch:** on primary it is the *default outcome for anything not
on the allowlist* — it is the system working, not an attack. Taken literally, D-CB1 would make every
typo and every new tool take the host to FULL READ-ONLY pending a human reset. **Verified against
reality:** during the 2026-07-15 session Agent-Sudo correctly refused every privileged command with
`source=miss_primary_refuse`; under the literal rule the breaker would have attack-latched on the
FIRST one and stayed latched all day. That is a false-positive machine and directly contradicts D9
("if the user is unavailable, automation must not stall").

**Rejected — "repeated misses trip BENIGN" (3-in-15min via the D-CB5 counter):** attractive because
rapid-fire misses resemble enumeration, but normal exploratory work produces exactly that shape, so
it re-imports the false-positive problem one layer down. A miss is not evidence of intent.
**Rejected — "only host_override latches, danger_veto trips benign":** a real destructive attempt
would then keep write access. Danger patterns catching fat-fingering as often as malice is fine —
the response (stop writing) is correct for BOTH.

**IMPLEMENTATION NOTE — the seam holds, no breaker change needed.** `circuit_breaker.record_tier4_
attempt()` stays correct as a primitive that ALWAYS attack-latches. D-CB8 governs only its CALLERS
in `app.py`: call it for `danger_veto` and host_override; for `miss_primary_refuse` emit the
existing `tier4_refuse` audit row and NO breaker event. Classification lives behind
`classify_trip()` (the D10 seam) so Hermes can refine this later without a rewrite.

**[[feedback-instrument-the-gate]] applies:** log every breaker decision WITH its reason and read the
log on a schedule. If `miss_primary_refuse` bursts turn out to correlate with real probing, D-CB8 can
be revisited **on logged evidence** — not on imagination. Widen/tighten on evidence.

### D-CB9 — LOCKED (2026-07-15): escalation = 4+ benign trips / 6h sliding (fixes an incoherent constant pair)
**The bug this fixes was in the SPEC, not the code**, and it was caught by the implementing agent
rather than by me. As first specified: `BASE_COOLDOWN_SECONDS`=10min but
`TRIP_ESCALATION_WINDOW_SECONDS`=1h with an implicit 2-trip threshold. Since re-arm happens at 10min,
**any repeat benign trip is NECESSARILY inside the 1h window** ⇒ every repeat escalates to an attack
latch ⇒ **the exponential backoff (20/40/80min) is unreachable dead code.** Two explicitly-required
behaviours (backoff; escalate-on-repeat) were mutually unsatisfiable at those constants.

**LOCKED VALUES:**
- `BASE_COOLDOWN_SECONDS = 10 * 60`
- `MAX_COOLDOWN_SECONDS = 4 * 60 * 60`
- `TRIP_ESCALATION_WINDOW_SECONDS = 6 * 60 * 60`  (was 1h)
- `TRIP_ESCALATION_THRESHOLD = 4`  (was implicitly 2)

Benign trips 1→2→3 stay benign with doubling cooldown (10 → 20 → 40 min); the **4th within a 6h
sliding window** attack-latches. Two counters, deliberately different: **escalation** counts benign
trips inside the 6h window; **backoff** counts benign trips since the last `RESET`.

**WHY 4/6h rather than latching on trip #2 — the key insight:** *exponential backoff IS the
anti-"attacker waits out the cooldown" mechanism.* 10→20→40→80min rate-limits a patient attacker
automatically, with no latch required. Meanwhile a broken cron job emits an IDENTICAL signal to a
patient attacker, and the breaker cannot tell them apart (same ambiguity as D-CB2). So latching on
the 2nd trip mostly punishes broken scripts and re-imports the false-positive problem D-CB8 just
removed. **A latch should mean "this is not resolving", not "you failed twice."**
- Rejected — *raise BASE_COOLDOWN above the 1h window*: makes backoff reachable, but one broken
  script then kills tier-3 for 90+ min. Slow recovery fights D9 (automation must not stall).
- Rejected — *drop escalation, backoff only*: simplest and most autonomous, but a permanently broken
  system would quietly self-throttle to the 4h cap forever and never ask for a human. A latch is how
  the system says "I cannot fix this myself."

**PROCESS NOTE — worth keeping:** the constants were set casually mid-session to avoid stalling on a
question, and were not checked against each other. The implementing agent flagged the contradiction
instead of silently picking a reading that made its tests pass. That is the behaviour we want from
build agents, and it is why the "if you think a decision is wrong, implement it anyway but say so"
instruction is load-bearing — a compliant-but-silent agent would have shipped unreachable backoff and
nobody would have known until an incident. XREF [[feedback-instrument-the-gate]].