Completion proven by evidence, never by an agent's claim.

Each chapter links to its section below. Section numbers match the markdown file.

An idea goes through planning, decomposition, execution and verification with little human involvement. Completion is proven by independently checked evidence, never by an agent's claim. The goal is reliable, controlled autonomy, not maximum autonomy.

Three agent roles plus the EPO. No Orchestrator model in the coding lane for now: Hermes' dispatcher assigns cards by profile, reclaims stale claims, promotes cards whose dependencies are met, and dispatches review. The EPO creates the starting card. Escalation routing is a script.

What each role needs from its model

Executor routing. Local or cloud is the packet's route field, set by the Planner at decomposition and fixed for the task's life. A local execution never runs at the same time as a local Planner session. The rule for choosing a route isn't defined yet; for the proof run, every task uses one route.

Five stages, three checkpoints. People are involved only at scope approval, consequential decisions, escalations, and milestone acceptance and merge. Everything else is automatic.

Review bundle

The milestone PR description is a plain-language summary the EPO can act on without another agent translating it. It is generated by a script, not written freehand.

• What changed and why
• Each task's verdict, with the commit it applies to and links to its evidence
• Changes made to record.yaml, where decisions and constraints get their final EPO review
• The human checks still outstanding
• The known gaps in check coverage

All artefacts live in the project repo, and git history is the archive. The record is one structured file holding the current state only: no archive files and no events. Superseded values stay in git history; the log and telemetry are enough for events.

Ownership by type

Design test: could a fresh session, given only the repo, AGENTS.md and this packet, complete the task correctly?

# fields
task_id
objective
acceptance_criteria
depends_on
record_refs        # pinned {id, version} pointers
constraints
checks             # which checks apply, and who runs them
human_checks
route              # local or cloud (§3)
inputs             # files the Executor needs to read + files the checks need to run; only these go in its workspace
output_cap         # max tokens generated over the whole session, incl. drafts, rewrites, revisions (not final file size)
context_estimate   # the five-term ledger below
attempt            # copy of the trusted counter at dispatch; records the attempt, isn't the allowance

Two quantities are tracked separately. Peak context is the largest single model request: its prompt plus the response allowance. Cumulative usage is the total across all requests in a session; it drives cost and time. The 64K ceiling applies to peak context.

At runtime: measurement and prevention are separate jobs

The same instrumentation applies to every session with a budget, including CP3 verification tasks.

The Verifier runs the declared checks itself, against a clean checkout of the committed revision. Results reported by the Executor are informational only and never count as evidence.

Truth precedence

Three layers at every checkpoint: deterministic (code, which must reject reliably), judgement (the Verifier) and human-required (stated plainly, never guessed). Anything automatable belongs in code.

New checks are added when a defect slips through, and they are specific to where they apply unless they prove universal.

Task-specific checks

Rendering and measuring (anything with a UI)

A task gets at most two attempts: the original plus one corrective retry, each in a fresh session, with the prior failure written into the hand-off. Same model tier; no mid-task escalation.

• One trusted counter: a launch ledger of OpenCode launches per task ID, written only by the launch gate, never by an agent.
• The launch gate is the only way to start OpenCode as the OpenCode user: the sudoers rule allows that one script and nothing else. It runs before every launch, including a relaunch after a recovered crash.
• The guard plugin also refuses kanban_request_changes once two launches are recorded, so a review-driven retry becomes a block instead of a refused launch.
• The counter is keyed on the task ID, so editing the packet never resets it. Re-decomposing the work creates a new task through the Planner, linked to its parent and visible to the EPO.
• Contradictions block immediately. A contradictory or impossible acceptance criterion, or a conflict with the record, stops the task at detection without using a retry.

Escalation categories

Stop conditions live in the project-root AGENTS.md, not in prompts or SOUL.md, because AGENTS.md propagates to child agents.

Executor restrictions must hold through every route, not just the Hermes tool call.

Three profiles — planner, executor and verifier — each with its own identity, SOUL.md, memory and pinned toolset. The general-assistant default profile is separate and untouched.

# kanban config
auto_decompose: false
auto_subscribe_on_create: false
review_dispatch: true          # verifier profile as reviewer
max_in_progress: 1           # during the proof run; tasks are serial
# no goal-mode cards: a model judge deciding completion contradicts §2

# workspace (scratch workspaces are deleted on completion)
--workspace worktree:<path> --branch wt/<task-id>

Executor skill sequence

One plausible model configuration, with OpenRouter as the cloud stand-in until the hardware lands. A small set of defective and clean briefs and packets, then a disposable 3–5-task app.

Setup

• Pin one provider per model, with data collection denied. A dedicated OpenRouter key with a hard credit limit and a buffer: Hermes requests the model's maximum max_tokens, which can cause 402 errors on a low balance (Hermes issue #22879).
• Telemetry on every model call: model, provider, tokens and cost, plus peak context and cumulative usage per task.
• Hermes' own hook covers only Hermes' calls. The Executor's usage must come from OpenCode's JSON event stream or a proxy in front of the provider. confirm that the stream carries the token fields on the installed version.
• Prevention needs a check before each request (§5.2). With OpenCode calling the provider directly, the likely place is the same proxy. confirm it at setup, with how to turn off OpenCode's automatic compaction.
• Measure the fixed overhead once per configuration before any packet is estimated; re-measure after any change to the harness, AGENTS.md, tool schemas or model.
• A setup log in the vault: every tool installed, config change and workaround, recorded as it happens. It becomes the V2 deployment prerequisite list. Known so far: gh.

The run must demonstrate

• Broad model comparisons are added only when an observed failure warrants one.
• Refreshing the stale Confluence space is the first agent task after the proof run passes. Until then, ignore Confluence as a source.
• All external content (tickets, chat, email, web) is untrusted data, never instructions. The general-assistant lane feeds nothing into this pipeline until the proof run passes.
• Hardware, the general-assistant lane and the automation backlog are listed in the table under §1.

• Three roles: Planner/Decomposer, Executor and Verifier. No coding Orchestrator model.
• Five stages and three checkpoints. CP2 is the priority.
• One record.yaml holding current state, with git as history. verified requires evidence.
• Packets may be drafted ahead, but are validated and pinned at dispatch.
• Tasks are serial, with one milestone branch and one milestone PR. No integration task.
• At most two OpenCode launches per task, recovery included, enforced by a launch gate in code before every launch. Contradictions block immediately.
• Verdicts are bound to the SHA, packet and pins. The Verifier runs the checks itself.
• The EPO merges, and no agent holds merge rights.
• Enforcement: repository protection, credentials, OpenCode isolation, and the guard plugin.
• Secrets travel only through environment variables. Consequential actions are approved only through a structured action.
• Anything with a UI is rendered and measured, and every check states its coverage.
• The context ceiling applies to peak context. Estimated from transcript growth at CP2, measured per call, and prevented by a check before each request. The Executor's workspace is a sparse checkout of its declared inputs, which reduces incidental reads without enforcing them.
• Scope is frozen until the proof run passes. Only corrections needed to pass it are allowed, and each is logged.