Capabilities

This is the honesty page. It exists so that every other page on this site can be trusted.

loopexec documents the discipline of loop engineering in full. The binary today implements the first slices of the engine and continues to grow toward the full contract. Those two facts are not in tension - they are the whole point of this page. We describe the mechanics completely, and we mark exactly what the binary does today against what the contract specifies. The matrix below is the boundary between the two.

The single rule we hold ourselves to:

The capability-honesty rule

A capability is Shipped only when it lives in cmd/loopexec with tests. In progress means it is on a feature branch and partially landed. Planned means it is specified and contracted in the SPEC, but not yet built. We never present Planned or In progress capability as if it ships today. When a mechanism is Planned, this site frames it as the contract (“loopexec is specified to…”, “the contract requires…”), never as current behavior.

How to read this

Three status tokens, defined once, used everywhere:

• Shipped - in the binary, with tests. You can run it now.
• In progress - on a feature branch, partially landed. Do not depend on it.
• Planned - written into the SPEC as a normative requirement, not yet implemented. The contract exists; the code does not.

Read Planned as a promise made in writing, not a feature you can invoke. The mechanism is fully specified - its halt reasons, its gates, its receipt fields are all defined - so you can design against the contract today. But the binary will refuse, stub, or simply not expose it until it ships.

The matrix

This table renders SPEC section 11 verbatim in meaning. The SPEC is the normative source; this page is its mirror. When a capability changes status, it changes in the SPEC first, then here.

Capability	Status	Deep dive
CLI contract: --json, stable exit codes, deterministic output	Shipped	/cli-reference/
init / status / check / step commands	Shipped	/cli-reference/
run as a real iterating loop (section 4)	Shipped	/loop-engineering/
Computed halt reasons (section 5) replacing --halt-reason	Shipped	/halt-reasons/
Typed JSONL receipt + durable state (section 8)	Shipped	/state-on-disk/
probe-check determinism confidence bound (O2)	Shipped (core) - perturbation + sequential monitor Planned	/determinism/
doctor precondition gate (O3-O5, section 7)	Shipped (core) - hermeticity + adequacy coverage-delta tier Planned (mutation canary ships via --mutate-cmd)	/cli-reference/
Set-based progress + no-regression ratchet: oscillation / no-progress / regression halts (section 3.2)	Shipped (core) - git revert-to-best Planned	/the-four-deaths/
explain-halt: raise-the-limit vs do-not-retry	Shipped	/cli-reference/
Receipt pinning: model tuple + sampling + context manifest + cost + check fingerprint (section 8)	Shipped (core) - live cost metering Planned	/state-on-disk/
replay: verify a receipt offline - re-run the check, match the fingerprint (section 8)	Shipped	/state-on-disk/
attest: HMAC-sign and verify a receipt (section 8)	Shipped	/state-on-disk/
reexecute: live re-run distribution (section 8)	Shipped	/cli-reference/
escalate / watch / ack + comprehension gate (section 9)	Shipped (core) - github/slack channels + kill-PID actuator Planned	/cli-reference/
build-context: budgeted relevant-file slice (workdir-confined, symlink-safe)	Shipped (core) - import_closure / dep_graph tiers Planned	/cli-reference/
Metric-integrity gate: guards dominate success (section 6)	Shipped (core) - assertion-count / manifest-hash / coverage-floor Planned	/reward-hacking/
doctor isolation preflight: credential-mount + exec-network fail-closed (section 7)	Shipped	/isolation/
isolate: two-zone orchestration - detached-clone sandbox + per-run minted/revoked key + rendered/launched zones (section 7)	Shipped (core) - container engine / egress proxy / key API are operator hooks	/isolation/

Counted plainly: eighteen Shipped, zero fully Planned. Eight rows are marked Shipped (core): the core ships and is tested today, with named sub-parts still Planned and spelled out in the row and enumerated below. The matrix carries those qualifiers so the table is as honest as SPEC section 11 - we do not round them up to a bare “Shipped”.

What “Shipped” buys you today

The contract surface is real. --json emits exactly one JSON object to stdout; human logs and errors go to stderr. Exit codes are stable - 0/10/11/12/... through 20/30/40/50 - and CI can branch on them without parsing JSON. Classes 13, 14, 15, 16, 17, 18, and 19 emit today (their core reasons; class 18, budget_exceeded / cost_anomaly, via inspect-cost; class 15, check_inadequate, via the doctor --mutate-cmd adequacy canary); only class 11’s task-list reasons stay reserved.

The loop is real too. run iterates the work command (--exec) then the external check (--check) until the check passes (success_condition_met), a bound trips (max_iterations_reached), or the work command fails (execution_failure). With no --check it refuses to start (workspace_invalid): no check, no loop. Every halt reason is computed from observed state, not forced by a flag, and every run appends a typed JSONL receipt and an atomic, resumable state file.

Determinism is enforced, not assumed. probe-check runs the check repeatedly and reports the achieved 95% upper bound on its flake rate - a confidence bound derived from a target via the rule of three, not a one-time pass of ten runs. doctor gates on that probe and refuses a flaky check.

What still ships only in part

Two Shipped rows have Planned sub-parts. Naming them is the honest thing to do:

• probe-check (core). Repeat-run verdict stability and the confidence bound ship today. Planned: adversarial perturbation (shuffling test order, varying seed, inducing load) and the in-loop sequential monitor that re-probes as the codebase mutates.
• doctor (determinism + isolation preflight + adequacy canary). Determinism, the isolation preflight (credential-mount + exec-network, fail-closed), and the mutation-canary adequacy gate (doctor --mutate-cmd runs an operator-provided mutation in an isolated copy of the workdir and halts check_inadequate when the --check stays green with the planted bug) are enforced today. Planned: hermeticity and the coverage-delta tier of adequacy - reported by doctor as planned rather than silently claimed.

What “Planned” means - specified, contracted, not shipped

Each Planned capability is written into the SPEC as a normative MUST. None of it is in the binary yet.

• The metric-integrity gate’s remaining layers - assertion-count, protected-manifest hash, and coverage-floor - are Planned. Its core already ships: the test-determining surface is captured at an immutable t0 (--integrity-cmd) and re-checked before any green declaration, so a suite that went green by testing less halts (metric_integrity_violation) instead of succeeding.
• Two-zone isolation now ships via isolate: a hardened detached-clone sandbox (a worktree is not a boundary), a per-run minted credential injected through a 0600 env-file (never on the argv or in the receipt) and always revoked, and rendered/launched exec-zone (network:none) + agent-zone (egress-allowlist) commands. loopexec orchestrates; the container engine, the auditing egress proxy, and the provider key API are operator-provided hooks (--runtime / --egress-proxy / --mint-cmd + --revoke-cmd).
• replay versus reexecute are two verbs that must never blur, and both ship: replay verifies a recorded verdict agent-free and budget-free by re-running the check and matching the fingerprint; reexecute is the live re-run that reports a statistical match across --samples. This is why the contract says replayable verdicts, not replayable runs - a live-LLM trajectory is not reproducible; only the verdict is.
• Nothing remains fully Planned. Every capability now ships a core. The remaining gaps are named, inline sub-parts: the operator-provided container engine / egress proxy / provider key API that isolate composes with, github/slack escalation channels, the kill-the-PID watchdog actuator, live/auto cost metering + in-loop budget enforcement (the cost analysis itself ships as inspect-cost: run-total cap + cost_anomaly), the deeper metric-integrity layers (assertion-count / manifest-hash / coverage-floor), the import_closure / dep_graph context tiers, and git revert-to-best for the ratchet.

When you read those pages, read them as the contract loopexec is specified to honor. They describe what the engine will do when the capability ships, governed by the SPEC, not what the binary does today.

The normative source

This page can drift; the SPEC cannot. SPEC.md in the repository is the single normative source of truth for the contract. Section 11 is the capability matrix this page mirrors. Where this site and the SPEC ever disagree, the SPEC wins - and that is a bug on this site to be fixed, not a reinterpretation of the contract.

Note

The matrix is the contract between the binary and this site. The binary’s tests and the docs matrix both reference SPEC section 11. That shared reference is what keeps the marketing honest: a capability cannot be claimed here until it is claimed there, and it cannot be claimed there until it is built and tested.