disinto-admin/disinto-ops

Fork 0

architect: vault blast-radius tiers #9

Merged

disinto-admin merged 2 commits from architect/vault-blast-radius-tiers into main

2026-04-08 19:08:05 +00:00

architect-bot commented

2026-04-08 10:28:35 +00:00

Collaborator

{"title": "architect: vault blast-radius tiers", "body": "## What this enables\n\nAfter this sprint, vault operations are classified by blast radius:\n- Auto-approve (low): docs, feature-branch file edits \u2014 no human gate\n- Async review (medium): CI config, Dockerfile changes \u2014 human reviews but agent continues\n- Hard block (high): production deploys, secrets rotation, agent self-modification \u2014 same as today\n\nThe dev loop stops stalling on routine vault requests. Agents move autonomously through 80%+ of vault requests while preserving the safety contract on irreversible operations.\n\n## Complexity and risks\n\n~14 files (7 new, 7 modified). ~60% gluecode wiring existing vault infrastructure, ~40% greenfield (classification engine, policy file format). Estimated 4-5 sub-issues.\n\nPrimary risk: the branch-protection/admin-token interaction. Auto-approve means the dispatcher merges without human approval, but branch protection currently requires 1 approval. The dispatcher needs admin access or branch protection must become tier-aware.\n\nSee sprints/vault-blast-radius-tiers.md for full pitch.\n\n## Recommendation\n\nWorth it. Vault redesign (#73-#77) is done and stale in prerequisites.md. Blast-radius tiers are the natural next step \u2014 the main reason agents cannot operate continuously is that every vault action blocks on human availability.\n\n---\nReply ACCEPT to proceed with design questions, or REJECT: <reason> to decline.", "head": "architect/vault-blast-radius-tiers", "base": "main"}

{"title": "architect: vault blast-radius tiers", "body": "## What this enables\n\nAfter this sprint, vault operations are classified by blast radius:\n- **Auto-approve (low)**: docs, feature-branch file edits \u2014 no human gate\n- **Async review (medium)**: CI config, Dockerfile changes \u2014 human reviews but agent continues\n- **Hard block (high)**: production deploys, secrets rotation, agent self-modification \u2014 same as today\n\nThe dev loop stops stalling on routine vault requests. Agents move autonomously through 80%+ of vault requests while preserving the safety contract on irreversible operations.\n\n## Complexity and risks\n\n~14 files (7 new, 7 modified). ~60% gluecode wiring existing vault infrastructure, ~40% greenfield (classification engine, policy file format). Estimated 4-5 sub-issues.\n\nPrimary risk: the branch-protection/admin-token interaction. Auto-approve means the dispatcher merges without human approval, but branch protection currently requires 1 approval. The dispatcher needs admin access or branch protection must become tier-aware.\n\nSee [sprints/vault-blast-radius-tiers.md](sprints/vault-blast-radius-tiers.md) for full pitch.\n\n## Recommendation\n\n**Worth it.** Vault redesign (#73-#77) is done and stale in prerequisites.md. Blast-radius tiers are the natural next step \u2014 the main reason agents cannot operate continuously is that every vault action blocks on human availability.\n\n---\nReply `ACCEPT` to proceed with design questions, or `REJECT: <reason>` to decline.", "head": "architect/vault-blast-radius-tiers", "base": "main"}

architect-bot added 1 commit 2026-04-08 10:28:35 +00:00

sprint: add vault-blast-radius-tiers.md 7afe8bf145

disinto-admin approved these changes 2026-04-08 11:26:20 +00:00

Dismissed

disinto-admin left a comment

Owner

i don't like the requirement that the vault runner needs an forgejo admin token. on the other side the dispatcher has access to all encrypted secrets anyway. we need to find a way to have a secure setup, where things can not be broken easily, but that is for later. good design otherwise.

dev-bot commented

2026-04-08 18:43:49 +00:00

Collaborator

architect-bot added 1 commit 2026-04-08 18:48:24 +00:00

sprint: add design forks and proposed sub-issues 708901e4e2

architect-bot dismissed disinto-admin's review 2026-04-08 18:48:24 +00:00

Reason:

New commits pushed, approval review dismissed automatically according to repository settings

architect-bot commented

2026-04-08 18:48:36 +00:00

Author

Collaborator

Thanks for the ACCEPT. I dug through the codebase — dispatcher.sh (1005 lines), lib/vault.sh, lib/branch-protection.sh, vault/vault-env.sh — and identified three design forks before implementation can begin. The sprint spec has been updated with full options and proposed sub-issues per path.

Three questions to resolve:

Q1: Auto-approve merge mechanism (critical)

Branch protection on ops repo: required_approvals: 1, admin_enforced: true. For low-tier vault PRs the dispatcher must merge without a human approval. How?

A. Skip PR entirely for low-tier — vault-bot commits directly to vault/actions/ on main using FORGE_ADMIN_TOKEN (already in vault env). No PR, no audit trail per execution.

B. Dispatcher self-approves — vault-bot creates PR as today, then posts APPROVED review + merges using its own token. Requires granting vault-bot Forgejo admin role. Full PR audit trail.

C. Tier-aware branch protection — create a Forgejo protection rule for vault/* branches with required_approvals: 0. Main protection unchanged. vault-bot merges its own low-tier PRs. (Needs verification that Forgejo supports vault/* glob patterns.)

D. Dedicated auto-approve bot — separate vault-auto-bot account with admin role that auto-approves low-tier PRs. Cleanest trust separation; most setup overhead.

Q2: Policy storage format

Where does the formula → tier mapping live?

A. vault/policy.toml in disinto repo. classify.sh reads at runtime. Policy changes require a disinto PR.

B. blast_radius field in each formulas/*.toml. Co-located with formula — impossible to add a formula without declaring its risk tier. classify.sh reads formula TOML.

C. vault/policy.toml in ops repo. Operators update without a disinto PR; useful for per-deployment overrides.

D. Hybrid: formula TOML carries default tier, ops vault/policy.toml overrides per-deployment. Most flexible; classify.sh merges two sources.

Q3: Medium-tier dev-loop behavior

When dev-agent creates a vault PR for a medium-tier action, what does it do while waiting for human approval?

A. Non-blocking — fire vault PR and continue to next issue immediately. Most autonomous; sequencing becomes unpredictable.

B. Soft-block with 2-hour timeout — poll for PR merge every 15 min for up to 2 hours, then continue. Balances oversight with velocity.

C. Status-quo block (medium = high) — medium-tier blocks agent loop like today. Only low-tier gets unblocked. No change to dev-agent flow needed.

D. Label-based approval — agent polls for vault-approved label on vault PR. Human applies label to signal "proceed" without requiring immediate PR merge.

Reply with your answers in the format:

Q1: A
Q2: B
Q3: C

Thanks for the ACCEPT. I dug through the codebase — `dispatcher.sh` (1005 lines), `lib/vault.sh`, `lib/branch-protection.sh`, `vault/vault-env.sh` — and identified three design forks before implementation can begin. The sprint spec has been updated with full options and proposed sub-issues per path. Three questions to resolve: --- ### Q1: Auto-approve merge mechanism (critical) Branch protection on ops repo: `required_approvals: 1`, `admin_enforced: true`. For low-tier vault PRs the dispatcher must merge without a human approval. How? **A.** Skip PR entirely for low-tier — vault-bot commits directly to `vault/actions/` on main using `FORGE_ADMIN_TOKEN` (already in vault env). No PR, no audit trail per execution. **B.** Dispatcher self-approves — vault-bot creates PR as today, then posts APPROVED review + merges using its own token. Requires granting vault-bot Forgejo admin role. Full PR audit trail. **C.** Tier-aware branch protection — create a Forgejo protection rule for `vault/*` branches with `required_approvals: 0`. Main protection unchanged. vault-bot merges its own low-tier PRs. (Needs verification that Forgejo supports `vault/*` glob patterns.) **D.** Dedicated auto-approve bot — separate `vault-auto-bot` account with admin role that auto-approves low-tier PRs. Cleanest trust separation; most setup overhead. --- ### Q2: Policy storage format Where does the formula → tier mapping live? **A.** `vault/policy.toml` in disinto repo. classify.sh reads at runtime. Policy changes require a disinto PR. **B.** `blast_radius` field in each `formulas/*.toml`. Co-located with formula — impossible to add a formula without declaring its risk tier. classify.sh reads formula TOML. **C.** `vault/policy.toml` in ops repo. Operators update without a disinto PR; useful for per-deployment overrides. **D.** Hybrid: formula TOML carries default tier, ops `vault/policy.toml` overrides per-deployment. Most flexible; classify.sh merges two sources. --- ### Q3: Medium-tier dev-loop behavior When dev-agent creates a vault PR for a medium-tier action, what does it do while waiting for human approval? **A.** Non-blocking — fire vault PR and continue to next issue immediately. Most autonomous; sequencing becomes unpredictable. **B.** Soft-block with 2-hour timeout — poll for PR merge every 15 min for up to 2 hours, then continue. Balances oversight with velocity. **C.** Status-quo block (medium = high) — medium-tier blocks agent loop like today. Only low-tier gets unblocked. No change to dev-agent flow needed. **D.** Label-based approval — agent polls for `vault-approved` label on vault PR. Human applies label to signal "proceed" without requiring immediate PR merge. --- Reply with your answers in the format: ``` Q1: A Q2: B Q3: C ```

disinto-admin commented

2026-04-08 19:00:45 +00:00

Owner

Q1: A
Q2: C, is copied from the disinto repo during "disinto init"
Q3: C, i don't see a situation where the dev agent would need to get an approval, this is for predictor, planner, architect, deployments, releases, shipping. everything that the dev agent does is revertable in git, so doesn't need blocking

Q1: A Q2: C, is copied from the disinto repo during "disinto init" Q3: C, i don't see a situation where the dev agent would need to get an approval, this is for predictor, planner, architect, deployments, releases, shipping. everything that the dev agent does is revertable in git, so doesn't need blocking

architect-bot commented

2026-04-08 19:07:14 +00:00

Author

Collaborator

Sprint filed: #437, #438, #439, #440

Answers applied:

Q1: A — Low-tier actions bypass PR creation entirely; vault-bot commits directly to ops main using FORGE_ADMIN_TOKEN
Q2: C — vault/policy.toml lives in ops repo (seeded from disinto repo template during disinto init); classify.sh reads ops copy at runtime for per-deployment overrides
Q3: C — Medium-tier blocks like high-tier (status quo); vault-blocking applies to predictor, planner, architect, deployments, releases, shipping — not dev-agent (whose work is git-revertable)

Sub-issues:

#437 vault/classify.sh + vault/policy.toml: classification engine + policy template
#438 lib/vault.sh: low-tier direct commit bypass (FORGE_ADMIN_TOKEN, no PR)
#439 dispatcher.sh: skip verify_admin_merged() for direct-commit low-tier TOMLs
#440 docs/BLAST-RADIUS.md + vault/SCHEMA.md: tier documentation

Dependencies: #437 → #438 → #439; #437 → #440 (parallel with #438/#439).

Sprint filed: #437, #438, #439, #440 **Answers applied:** - Q1: A — Low-tier actions bypass PR creation entirely; vault-bot commits directly to ops main using `FORGE_ADMIN_TOKEN` - Q2: C — `vault/policy.toml` lives in ops repo (seeded from disinto repo template during `disinto init`); classify.sh reads ops copy at runtime for per-deployment overrides - Q3: C — Medium-tier blocks like high-tier (status quo); vault-blocking applies to predictor, planner, architect, deployments, releases, shipping — not dev-agent (whose work is git-revertable) **Sub-issues:** - #437 `vault/classify.sh` + `vault/policy.toml`: classification engine + policy template - #438 `lib/vault.sh`: low-tier direct commit bypass (`FORGE_ADMIN_TOKEN`, no PR) - #439 `dispatcher.sh`: skip `verify_admin_merged()` for direct-commit low-tier TOMLs - #440 `docs/BLAST-RADIUS.md` + `vault/SCHEMA.md`: tier documentation Dependencies: #437 → #438 → #439; #437 → #440 (parallel with #438/#439).

disinto-admin approved these changes 2026-04-08 19:07:57 +00:00

disinto-admin left a comment

Owner

Sprint sub-issues filed (#437-#440). Approving for merge.