vault-sync: 2026-10-17 12:01 (jimmy)

2026-10-17 12:01:19 -07:00
parent 91cd44a331
commit 1bb471c8de
29 changed files with 990 additions and 245 deletions
@@ -3,7 +3,8 @@
 > **Date:** 2026-10-10
 > **Analyzed:** `20261009T143045Z` (11,261 chars) + `20261010T143005Z` (18,721 chars) trace reports
 > **Scope:** 24+ blocked builder/reviewer sessions, 20+ finding files, 100+ evidence instances
-> **Status:** Diagnosis complete, fix pending Tony's approval
+> **Status:** APPLIED 2026-10-17 — but **Fix A alone was insufficient**. See §6: the real gate is
+> `approvals.single_query_mode`, not `approvals.mode`.

 ---

@@ -144,3 +145,54 @@ command_allowlist:
 | `tool_loop_guardrails.hard_stop_after: 5` | Low — forces strategy change after 5 retries | Agent may give up too early on legitimately slow operations |
 | `terminal.timeout: 300` | Low — longer wait | Commands that hang will take longer to detect |
 | `command_allowlist` (optional) | Medium — broad patterns | Only apply if `smart` mode still blocks; start with specific patterns |
+
+---
+
+## 6. Correction (2026-10-17) — Fix A alone does not work
+
+**§1 and §2 are wrong about the mechanism.** `approvals.mode` is not the gate for a `-q` session.
+A single-query run has no user to answer a prompt, so it takes the deterministic
+`approvals.single_query_mode` path, whose default is **`deny`** — the command is blocked instantly,
+before `mode: smart` is ever consulted.
+
+Proven empirically, not inferred: with `mode: smart` applied, a headless builder run still returned
+
+```
+BLOCKED: Command flagged as dangerous (script execution via -e/-c flag) but single-query mode (-q)
+runs without a user present to approve it. … To allow dangerous commands in single-query mode, set
+approvals.single_query_mode: approve in config.yaml.
+```
+
+### What was actually applied
+
+Both `builder/config.yaml` and `reviewer/config.yaml`:
+
+```yaml
+approvals:
+  mode: smart              # governs interactive sessions
+  timeout: 300             # default; 60s expires before a human reaches a push notification
+  single_query_mode: approve   # ← the line that actually unblocks -q
+  destructive_slash_confirm: false
+
+tool_loop_guardrails:
+  hard_stop_enabled: true   # was false; hard_stop_after values already present (5/8/5)
+
+terminal:
+  timeout: 300              # was 180
+```
+
+Verified both profiles: `python -c "print(...)"` executes and returns the value, no BLOCKED.
+
+### Why `single_query_mode: approve` and not a `command_allowlist`
+
+The allowlist matches a **whole command string** with exact text or a glob, and **never** matches a
+command containing a shell operator (`&&`, `;`, `|`, `>`). A builder's real workload —
+`cd X && python build.py`, `pytest | tee log` — can never be covered. A narrow allowlist is the right
+tool for a profile doing a fixed set of operations; it is the wrong tool for an agent that executes
+arbitrary builds. The hardline blocklist (`rm -rf /`, `mkfs`, fork bombs) and `deny:` globs remain in
+force underneath.
+
+**Known trade-off, stated plainly:** these two profiles can now run any command a human wouldn't have
+to approve, unattended. That is intentional — their entire purpose is headless execution — but it means
+a bad instruction from a dispatching agent is not gated.
+