docs: constrained-autonomy design approved + fix stale tier-2 guard

- constrained_autonomy_design_decisions.md: D1-D8 locked (hybrid hook
  classifier + Agent-Sudo daemon executor, structural classification with
  unknown->sandbox, fail-closed, Hermes recovery ladder) + EXECUTION ORDER
  with CA-P1a inserted as zero-dependency item 0
- agent_prompts.md shared block: replace "TIER-2 IS BROKEN" with the
  corrected root cause (old primary bridge's NTFY endpoint was unreachable;
  tier-2 works when the bridge reaches ntfy + user is attended)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Backtalk6858
2026-07-14 17:02:08 -05:00
parent 32131ade7e
commit c101167eb5
2 changed files with 79 additions and 1 deletions
+5 -1
View File
@@ -898,7 +898,11 @@ If you issue the same tool call or command twice with identical arguments, STOP
Agent-Sudo does not exist yet, so build agents that need root on server-01 use the **existing** `sudo-bridge-server01` (`http://192.168.1.90:8082`, Bearer `secret/data/sudo-bridge-server01#api_key`). Rules:
- `GET /allowlist` before any `POST /allowlist` (409 = already exists). New rules via `POST /allowlist` only (allowlist.json is root:root — cannot be edited directly).
- `sudo-bridge` uses `subprocess.run(shlex.split())`**NO shell**: no `&&`, `|`, `$()`, `>`. Each command is a separate `POST /exec`. File writes = `python3 -c "..."` with base64 (single argv).
- **⚠️ TIER-2 NTFY APPROVAL IS BROKEN** (behavior_changes id=3 — notifications never arrive, command times out at 900s). **Do NOT design a build step that blocks on a tier-2 approval.** If a required privileged command would be tier-2, STOP and record it under `actions_failed` as "needs manual authorization: <command>" so the reviewer can pre-add it as tier-1 or run it interactively. Prefer tier-1-eligible commands; batch anything needing genuine escalation into an explicit list for the user.
- **⚠️ TIER-2 NTFY APPROVAL — ROOT CAUSE CORRECTED 2026-07-14** (behavior_changes id=3, updated). Tier-2 is **NOT universally broken.** The NTFY server (`ntfy-k0oooo8cckwsok80gg8kck88`) is healthy, and **server-01's bridge reaches it fine — its tier-2 approvals DO arrive on the user's phone and were approved live during P4.** The real failure was the **OLD PRIMARY bridge configured with an unreachable NTFY endpoint** (Connection refused, topic `sudo-bridge-approvals`) — a dead send-path, not a dead NTFY. Rules now:
- **Tier-2 IS usable when (a) the target bridge can reach ntfy AND (b) the user is attended (interactive session / watching phone).** In that case, submit the tier-2 and WAIT for approval — do NOT pre-emptively batch to manual.
- **Batch to manual-auth ONLY when** the run is unattended/async, OR the target bridge's NTFY send-path is known-unreachable (currently: the old PRIMARY bridge). Then record under `actions_failed` as "needs manual authorization: <command>".
- If a tier-2 submit returns an NTFY send failure or parks/expires, that is the misconfigured-send-path case → stop waiting, record it under `actions_failed`, and continue. Never stall the whole run on it.
- Moot on primary once its Agent-Sudo daemon is live + the old bridge is decommissioned (P5).
### Mandatory wrap-up (every agent, on success OR failure, as the final message)
```