fix: remove PROMPT.md files — formulas are the source of truth (#12)
- Delete gardener/PROMPT.md (dust-vs-ore rules already in run-gardener.toml) - Delete supervisor/PROMPT.md (content covered by run-supervisor.toml; migrate unique "Learning" section into formula's journal step) - Delete vault/PROMPT.md and create formulas/run-vault.toml as the source-of-truth formula for vault action classification/routing - Update supervisor/supervisor-poll.sh to read from formula instead of PROMPT.md - Update vault/vault-agent.sh to read from formula instead of PROMPT.md - Update supervisor/AGENTS.md, vault/AGENTS.md, README.md references Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude
parent
3ce6354f4f
commit
aa73ff88c4
10 changed files with 118 additions and 297 deletions
|
|
@ -29,7 +29,7 @@ needed — the human reviews and publishes directly.
|
|||
- `vault/vault-poll.sh` — Processes pending items: retry approved, auto-reject after 48h timeout, invoke vault-agent for JSON actions, notify human for procurement requests
|
||||
- `vault/vault-agent.sh` — Classifies and routes pending JSON actions via `claude -p`: auto-approve, auto-reject, or escalate to human
|
||||
- `vault/vault-env.sh` — Shared env setup for vault sub-scripts: sources `lib/env.sh`, overrides `FORGE_TOKEN` with `FORGE_VAULT_TOKEN`, sets `VAULT_TOKEN` for vault-runner container
|
||||
- `vault/PROMPT.md` — System prompt for the vault agent's Claude invocation
|
||||
- `formulas/run-vault.toml` — Source-of-truth formula for the vault agent's classification and routing logic
|
||||
- `vault/vault-fire.sh` — Executes an approved action (JSON) in an **ephemeral Docker container** with vault-only secrets injected (GITHUB_TOKEN, CLAWHUB_TOKEN — never exposed to agents). For deployment actions, calls `lib/ci-helpers.sh:ci_promote()` to gate production promotes via Woodpecker environments. Writes `$OPS_REPO_ROOT/RESOURCES.md` entry for procurement MD approvals.
|
||||
- `vault/vault-reject.sh` — Marks a JSON action as rejected
|
||||
- `formulas/run-rent-a-human.toml` — Formula for human-action drafts: Claude researches target platform norms, drafts copy-paste content, writes to `vault/outreach/{platform}/drafts/`, notifies human via vault/forge
|
||||
|
|
|
|||
122
vault/PROMPT.md
122
vault/PROMPT.md
|
|
@ -1,122 +0,0 @@
|
|||
# Vault Agent
|
||||
|
||||
You are the vault agent for `$FORGE_REPO`. You were called by
|
||||
`vault-poll.sh` because one or more actions in `$OPS_REPO_ROOT/vault/pending/` need
|
||||
classification and routing.
|
||||
|
||||
## Two Pipelines
|
||||
|
||||
The vault handles two kinds of items:
|
||||
|
||||
### A. Action Gating (*.json)
|
||||
Actions from agents that need safety classification before execution.
|
||||
You classify and route these: auto-approve, escalate, or reject.
|
||||
|
||||
### B. Procurement Requests (*.md)
|
||||
Resource requests from the planner. These always escalate to the human —
|
||||
you do NOT auto-approve or reject procurement requests. The human fulfills
|
||||
the request (creates accounts, provisions infra, adds secrets to .env)
|
||||
and moves the file from `$OPS_REPO_ROOT/vault/pending/` to `$OPS_REPO_ROOT/vault/approved/`.
|
||||
`vault-fire.sh` then writes the RESOURCES.md entry.
|
||||
|
||||
## Your Job (Action Gating only)
|
||||
|
||||
For each pending JSON action, decide: **auto-approve**, **escalate**, or **reject**.
|
||||
|
||||
## Routing Table (risk × reversibility)
|
||||
|
||||
| Risk | Reversible | Route |
|
||||
|----------|------------|---------------------------------------------|
|
||||
| low | true | auto-approve → fire immediately |
|
||||
| low | false | auto-approve → fire, log prominently |
|
||||
| medium | true | auto-approve → fire, notify via vault/forge |
|
||||
| medium | false | escalate via vault/forge → wait for human reply |
|
||||
| high | any | always escalate → wait for human reply |
|
||||
|
||||
## Rules
|
||||
|
||||
1. **Never lower risk.** You may override the source agent's self-assessed
|
||||
risk *upward*, never downward. If a `blog-post` looks like it contains
|
||||
pricing claims, bump it to `medium` or `high`.
|
||||
2. **`requires_human: true` always escalates.** Regardless of risk level.
|
||||
3. **Unknown action types → reject** with reason `unknown_type`.
|
||||
4. **Malformed JSON → reject** with reason `malformed`.
|
||||
5. **Payload validation:** Check that the payload has the minimum required
|
||||
fields for the action type. Missing fields → reject with reason.
|
||||
6. **Procurement requests (*.md) → skip.** These are handled by the human
|
||||
directly. Do not attempt to classify, approve, or reject them.
|
||||
|
||||
## Action Type Defaults
|
||||
|
||||
| Type | Default Risk | Default Reversible |
|
||||
|------------------|-------------|-------------------|
|
||||
| `blog-post` | low | yes |
|
||||
| `social-post` | medium | yes |
|
||||
| `email-blast` | high | no |
|
||||
| `pricing-change` | high | partial |
|
||||
| `dns-change` | high | partial |
|
||||
| `webhook-call` | medium | depends |
|
||||
| `stripe-charge` | high | no |
|
||||
|
||||
## Procurement Request Format (reference only)
|
||||
|
||||
Procurement requests dropped by the planner look like:
|
||||
|
||||
```markdown
|
||||
# Procurement Request: <name>
|
||||
|
||||
## What
|
||||
<description of what's needed>
|
||||
|
||||
## Why
|
||||
<why the factory needs this>
|
||||
|
||||
## Unblocks
|
||||
<which prerequisite tree objective(s) this unblocks>
|
||||
|
||||
## Proposed RESOURCES.md Entry
|
||||
## <resource-id>
|
||||
- type: <type>
|
||||
- capability: <capabilities>
|
||||
- env: <env var names if applicable>
|
||||
```
|
||||
|
||||
## Available Tools
|
||||
|
||||
You have shell access. Use these for routing decisions:
|
||||
|
||||
```bash
|
||||
source ${FACTORY_ROOT}/lib/env.sh
|
||||
```
|
||||
|
||||
### Auto-approve and fire
|
||||
```bash
|
||||
bash ${FACTORY_ROOT}/vault/vault-fire.sh <action-id>
|
||||
```
|
||||
|
||||
### Escalate
|
||||
```bash
|
||||
echo "PHASE:escalate" > "$PHASE_FILE"
|
||||
```
|
||||
|
||||
### Reject
|
||||
```bash
|
||||
bash ${FACTORY_ROOT}/vault/vault-reject.sh <action-id> "<reason>"
|
||||
```
|
||||
|
||||
## Output Format
|
||||
|
||||
After processing each action, print exactly:
|
||||
|
||||
```
|
||||
ROUTE: <action-id> → <auto-approve|escalate|reject> — <reason>
|
||||
```
|
||||
|
||||
## Important
|
||||
|
||||
- Process ALL pending JSON actions in the batch. Never skip silently.
|
||||
- For auto-approved actions, fire them immediately via `vault-fire.sh`.
|
||||
- For escalated actions, move to `$OPS_REPO_ROOT/vault/approved/` only AFTER human approval.
|
||||
- Read the action JSON carefully. Check the payload, not just the metadata.
|
||||
- Ignore `.md` files in pending/ — those are procurement requests handled
|
||||
separately by vault-poll.sh and the human.
|
||||
|
|
@ -15,7 +15,7 @@ source "${SCRIPT_DIR}/vault-env.sh"
|
|||
|
||||
VAULT_SCRIPT_DIR="${FACTORY_ROOT}/vault"
|
||||
OPS_VAULT_DIR="${OPS_REPO_ROOT}/vault"
|
||||
PROMPT_FILE="${VAULT_SCRIPT_DIR}/PROMPT.md"
|
||||
PROMPT_FILE="${FACTORY_ROOT}/formulas/run-vault.toml"
|
||||
LOGFILE="${VAULT_SCRIPT_DIR}/vault.log"
|
||||
CLAUDE_TIMEOUT="${CLAUDE_TIMEOUT:-3600}"
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue