Modes & validation

Validation intent versus kernel truth¶

The model expresses what must hold and how to check it: validate takes a semantic requirement name plus a command. The kernel runs the command, records the result, links evidence provenance internally, and derives completion. The model never needs event UUIDs, call ids, or ledger ids, and cannot write validation truth: record_evidence accepts only pending and unavailable observations, and task_update declares requirements — not pass states.

Current evidence, honest completion¶

Evidence is a current-state ledger, not a history trap. The newest observation per claim is current; the raw event log keeps every attempt. A test that failed and now passes supersedes the failure, so a fixed task moves InProgress → ImplementedNotVerified → Verified even with earlier failures behind it. A required validation that cannot run yields Blocked rather than a pretense of verification. complete only records the implementation claim; the kernel computes the result and announces changes durably.

Verified completion is also what ends a run. An implementation claim is not a substitute for evidence, so ImplementedNotVerified no longer terminates the loop by itself: when the run actually changed the workspace and no required validation has passed, the kernel spends one corrective turn asking the model to validate the change or state why verification is unavailable. The state stays honest either way, and the correction is one-shot — it can never loop, and it can never promote an unverified run to Verified. Read-only work is untouched: nothing was mutated, so there is nothing to verify.

Failure supervision¶

Failure signatures are normalized deterministically and tracked per validation lineage. Unrelated successful tools (reading a file, searching, git status) do not reset a failing validation's streak. The streak resolves when the failing validation itself passes or the failure signature materially changes — evidence the strategy moved. At the retry budget the kernel requests re-ground: inspect reality, name disproven assumptions, change strategy. Supervision state replays from raw events so resume keeps a stalled loop visible.

Known limits of failure supervision¶

The mechanism is reliable about what it can see and weaker than its summary reads on what it cannot. These limits are recorded because the claims above are narrower than they first appear:

• A lineage is the whole normalized command, not the failing behavior. For shell the lineage subject is the whitespace-normalized command text, so changing any argument (a path, an -m5, a head count) starts a fresh lineage at count 1. Perturbing the command spelling while the same behavior keeps failing never reaches the re-ground budget, and the earlier streak is not surfaced as related evidence. For other tools the subject is the bare tool name, so every search failure shares one lineage regardless of query.
• The signature is coarse. It is the subject's first whitespace token plus at most eight output lines with ASCII digits masked and (elapsed …) lines dropped, so two genuinely different failures of one command that differ only in numbers collapse into one signature. A materially different failure body under an unchanged subject is the only change that restarts the count.
• Every errored tool call becomes a failure, including probes whose exit code is the answer. grep with no match, a failing test, git diff --quiet, a find | head under pipefail, or a search that legitimately found nothing is presented as an active failure lineage, and only a later successful shell call with the same normalized command resolves it — a passing validate clears only its own requirement lineage, and successful inspection tools never reset a streak. False lineages therefore consume the re-ground budget and can re-ground the model over a probe that already answered the question.

Progress and stagnation¶

Successful inspections are supervised too. The kernel keys every read, search, artifact read, git status/diff, and conservative read-only shell observation by canonical subject (including range arguments) and result digest inside a progress epoch. Real change advances the epoch: workspace mutations, detected external edits, validation and evidence, meaningful task-state updates, mode switches, and new user turns. Repeating an unchanged observation once is allowed; consecutive redundant turns cross the stagnation budget and the kernel re-grounds the model with the explicit list of already-known observations, then suppresses further repeats deterministically. Epoch and streak state replay from raw events, so resume keeps an active inspection loop visible. There is no turn ceiling: failure.max_model_turns is an optional, off-by-default circuit breaker, and progress is bounded by real behavior, not task length.

Mode, Safety, and Permissions¶

Mode, Safety, and Permissions are deliberately separate, because conflating them makes the wrong thing adjustable. Mode is the shape of the work: ASK and PLAN may inspect but never mutate; WORK may change the workspace according to Safety. Safety is the risk posture: Strict asks before workspace writes, Standard treats ordinary source edits as work, Autonomous removes that friction while still classifying network and external effects. Permissions is how uncertainty is resolved: a human decision, a recorded automatic approval, or a separate stateless model review of the exact command. The kernel applies them in order; none can widen what a previous stage refused.

The invariant that keeps provenance honest is that external effects are never silently allowed. Writing outside the workspace, mutating .git, using the network, or touching a remote system always becomes a kernel Ask first — even when Safety is Autonomous and Permissions is All approved. Auto-approval is a resolver, not a bypass: it records the same durable request/resolution pair and issues a single-use capability grant for exactly that call. Hard deny (privileged or system-destructive operations) sits outside all three controls and can never be approved.

Enforcement is the OS sandbox, not bash-string parsing. bwrap is mandatory: the host root is read-only, the workspace is mounted explicitly, .git is protected unless Git metadata mutation was granted, home credentials and host sockets are masked, and PID/IPC/UTS/network namespaces isolate the process. Approval never means "rerun outside the sandbox"; it adds the narrowest capability to a new sandbox for that call. The threat model is honest: this strongly contains ordinary mistakes, prompt injection, accidental host access, and unauthorized network use; it does not claim protection against kernel exploits, resource exhaustion, or damage inside roots the user explicitly granted.

Context, reads, and approvals¶

Context is budgeted in tokens with a conservative estimator; every pre-request number is visibly approximate and provider usage is authoritative afterward. Tools are bounded by design rather than by small product ceilings: file reads and artifact reads return continuation windows, searches return paged matches, and long-running commands become managed processes with exec_start / exec_poll / exec_terminate. Ask policy decisions pause for a real human decision through the TUI; approval is single-use and keyed by kernel call ids the model never sees, so consent cannot be fabricated. Outside-workspace writes execute only after approval; dangerous shell commands remain denied.