docs: expand P0 prompt → P0+pre-flight+groundwork agent (absorbs P1)

- P0 build prompt now does Part A (command_audit schema) + Part B
  (read-only audit of all P1-P5 assumptions) + Part C (remediate safe
  findings = all of P1: Incus install, host inventories, build-sandbox.sh,
  both sandbox mirrors)
- Golden Rule: only remediate read-only or server-01-sandbox findings;
  tier-2/manual-auth or prod-touching → batched, never blocked
- Ends with a BUILD READINESS wrap-up so the focused build starts at P2
- P1 section retained as canonical contract reference, marked folded-in

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Backtalk6858
2026-07-09 20:19:00 -05:00
parent c50e72e17b
commit d44c9b55e6
+37 -16
View File
@@ -914,19 +914,23 @@ If you issue the same tool call/command twice with identical arguments, STOP and
---
## P0 — DB foundation (`command_audit` + training-signal schema)
**Blast radius: ZERO** (additive DDL only, no server touched). Safe to run first, independent of P1P5. `--max-turns 10`.
## P0 — DB foundation + PRE-FLIGHT AUDIT + GROUNDWORK (absorbs P1)
**Blast radius: DDL = ZERO; audit = ZERO (read-only); groundwork = server-01 sandbox-side only** (no production, no live data). This is the "run-while-user-does-business-research" agent: it lays every prerequisite so the focused interactive build can start at **P2**. It does P0's schema, a full read-only audit of all P1P5 assumptions, and then remediates the safe/unblocking findings (= all of P1). Anything needing tier-2/manual-auth or with production blast radius is NOT done — it is batched into an explicit manual-auth list. `--max-turns 40`.
```
You are a database schema agent on the primary server (192.168.1.88). Create the audit + training-data foundation for Agent-Sudo (projects id=176).
You are the Agent-Sudo GROUNDWORK agent, running on the primary server (192.168.1.88) with server-01 reachable at 192.168.1.90. You run while the user is doing other work. Your job: create P0's schema, audit every assumption the later build phases (P1P5) depend on, and remediate the SAFE, unblocking findings so that when the user returns, the focused interactive build can start directly at P2 (service logic) with zero groundwork left. You do NOT build the service (P2), the security layer (P3), deploy (P4), or decommission (P5).
## DESIGN IS LOCKED — DO NOT REDESIGN
The Agent-Sudo design is fixed in agent_sudo_design_decisions.md. Your job is only to create the schema below. Do not add, rename, or "improve" tiers, columns beyond the contract, or tables. If the contract seems wrong, record it in notes and proceed with the contract as written.
The Agent-Sudo design is fixed in agent_sudo_design_decisions.md. Create the schema and mirrors below exactly. Do not add, rename, or "improve" tiers, columns, tables, or architecture. If any contract seems wrong, record it in notes and proceed with the contract as written.
## Use the shared block (verified facts, postgres access, wrap-up, loop guard).
## Use the shared block (verified facts, postgres access, sudo-bridge-server01 path, tier-2-broken guard, wrap-up, loop guard).
## Contract — what must be true when you finish
1. In the `projects` DB, a table `command_audit` exists with AT LEAST these columns (types are guidance; match intent):
## THE GOLDEN RULE FOR "TAKE CARE OF FINDINGS"
Remediate a finding ONLY if it is (a) read-only, or (b) server-01 sandbox-side with a clean rollback. If a fix needs a tier-2/manual-auth privileged command you cannot get as tier-1, OR would touch primary production, OR touches a live prod container — DO NOT do it. Record it verbatim under `actions_failed` as "needs manual authorization: <exact command>" and keep going. Never block on a tier-2 approval (it is broken — see shared block). A stalled agent is worse than a batched manual-auth list.
## PART A — P0 schema (do this first; zero blast radius)
Contract:
1. In the `projects` DB, table `command_audit` exists with AT LEAST these columns (types are guidance; match intent):
- id BIGSERIAL PK
- ts TIMESTAMPTZ DEFAULT now()
- server_id TEXT NOT NULL -- 'primary' | 'server-01'
@@ -944,25 +948,42 @@ The Agent-Sudo design is fixed in agent_sudo_design_decisions.md. Your job is on
- training_signal BOOLEAN DEFAULT true -- include this row in the local-model training export
- Helpful indexes: (server_id, ts), (decision_type), (assigned_tier).
2. Confirm `agent_test_results` already exists in `api_business` (it does — just verify + print its columns; do NOT recreate).
3. Nothing else is modified. Existing tables untouched.
3. Nothing else modified. Existing tables untouched.
Approach: write DDL as `CREATE TABLE IF NOT EXISTS ...` + `ALTER TABLE ... ADD COLUMN IF NOT EXISTS` (idempotent), `docker cp` a .sql file into the postgres container, run via `docker exec <pg> psql -U postgres -d projects -f <file>` (NOT a heredoc). Pre-flight: `SELECT to_regclass('public.command_audit')` — if present, verify columns and only ADD missing ones; never drop/recreate.
## Reference approach
Write the DDL as `CREATE TABLE IF NOT EXISTS ...` (idempotent) and run it via `docker exec <pg> psql -U postgres -d projects -f <file>` (use `docker cp` of a .sql file, not a heredoc — heredocs over docker exec are unreliable). Use IF NOT EXISTS everywhere so a re-run is a no-op.
## PART B — read-only PRE-FLIGHT AUDIT of every P1P5 assumption (zero blast radius)
Produce a findings report (also save it to `/opt/appdata/docker/agent-sudo/preflight-audit.json` on server-01). Check and record PASS/FAIL/finding for each:
- **P1 substrate (server-01):** is `incus` installed (`which incus`)? Is root fs btrfs (`stat -f -c %T /`) → which pool backend? Do `incusbr0` / a storage pool already exist? Does `/opt/appdata/docker/agent-sudo/` exist?
- **P2 service:** is the existing sudo-bridge repo/source readable (needed as the refactor skeleton)? Read app.py + daemon + allowlist.json and note the rule count for the 04 remap. Is port **8084 free on BOTH hosts** (`ss -ltn` / audit; design-doc D8's 8083 is WRONG — bitwarden-bridge owns it)?
- **P3 security:** does an `agent-sudo` Vault policy/role already exist (skip-create later)? Is the Vault transit engine enabled? Is Timeshift present on server-01 (it is — confirm) and what is primary's snapshot config (record only; NEVER enable auto-restore)?
- **P4 deploy net:** is the OLD bridge on **8082 healthy on BOTH hosts** (the safety net)? Does the existing Jenkins/Gitea deploy path (Jenkinsfile.server01) exist?
- **P5:** n/a for groundwork (retention-window gated) — just note it's out of scope.
## Pre-flight (idempotent — safe on re-run)
- Resolve the postgres container. Confirm `projects` and `api_business` DBs are reachable.
- `SELECT to_regclass('public.command_audit')` — if it already exists, verify its columns match the contract and only ADD missing columns (ALTER TABLE ... ADD COLUMN IF NOT EXISTS); do not drop/recreate.
## PART C — REMEDIATE the safe/unblocking findings (= all of P1; server-01 sandbox-side only)
Fold in and execute the **P1 contract below in the "P1 — Incus + command-surface mirrors" section** in full (it is the canonical spec — follow its Contract, Reference approach, Pre-flight, and Abort/rollback exactly):
1. Capture the read-only host inventory for BOTH hosts → `/opt/appdata/docker/agent-sudo/inventory/{primary,server-01}.json` (packages, users/uids/groups, sudoers STRUCTURE only — never secret values, never file contents).
2. Install + init Incus on server-01 (btrfs pool or `dir` fallback, `incusbr0` NAT bridge) — **via sudo-bridge-server01 tier-1 if possible; if the apt install needs tier-2, defer it to the manual-auth batch and still produce everything that doesn't need it.**
3. Write `build-sandbox.sh <primary|server-01>` to `/opt/appdata/docker/agent-sudo/build-sandbox.sh`.
4. Build BOTH sandbox mirrors (`sandbox-server01`, `sandbox-primary`, both ON server-01) with the 2vCPU/2GB/10GB limits and ZERO LAN exposure (incusbr0 only). Confirm isolation.
Do NOT do anything from P2/P3/P4/P5 beyond the read-only audit in Part B.
## Abort / rollback
- Abort if either DB is unreachable (emit failed wrap-up; touch nothing).
- Rollback if needed = `DROP TABLE command_audit` (this table is brand-new and empty; safe). Never drop agent_test_results.
- Part A: abort if a DB is unreachable (touch nothing). Rollback = `DROP TABLE command_audit` (brand-new, empty). Never drop agent_test_results.
- Part C: rollback = `incus delete --force sandbox-primary sandbox-server01` + remove the btrfs pool (nothing production affected). Abort Part C (record + continue to wrap-up) if btrfs AND dir backends both fail, or if Incus install needs tier-2 you cannot get (defer via manual-auth batch — Parts A + B still stand).
## Wrap-up notes must confirm: command_audit columns created/verified; agent_test_results columns; row counts (should be 0 for command_audit).
## Wrap-up notes MUST include a "BUILD READINESS" section:
- command_audit columns created/verified; agent_test_results columns; row counts (0 for command_audit).
- The full pre-flight findings (path to preflight-audit.json).
- Incus version; pool backend; both containers' isolation proof (no LAN port, on incusbr0); build-sandbox.sh path.
- **A single "MANUAL-AUTH BATCH" list** = every command the user must authorize/run on return before P2 can proceed (verbatim commands), or "none — build can start at P2 immediately."
- One line: "Focused build starts at: P2" (or, if a blocker was hit, which phase and what unblocks it).
```
---
## P1 — Incus + command-surface mirrors on server-01
> **NOTE (2026-07-09):** P1 is now **folded into the P0+GROUNDWORK agent above** (Part C) so it runs while the user does business research. This section remains as the **canonical contract reference** that the groundwork agent follows — do NOT launch it as a separate agent unless the groundwork agent deferred it (manual-auth batch) and it needs a standalone re-run.
**Blast radius: server-01 sandbox-side only** (no production, no live data). `--max-turns 30` (many discrete privileged steps).
```