Leerie

Leerie is an autonomous task driver for Claude Code. One prompt. Finished, committed, validated code. No steering mid-run, no polishing when it's done.

Most tools that call themselves autonomous still require you: to confirm a direction, catch a hallucination, or clean up the result before it's usable. Leerie doesn't. It classifies the task, decomposes it, implements each piece in parallel isolated worktrees, validates the integrated result, and merges — beginning to end, unattended.

It runs entirely on the Claude Code CLI and your existing subscription — no Anthropic API key, no per-call billing. If you have Claude Code installed and logged in, you have everything it needs.

Why it actually finishes without you:

Most AI "orchestrators" let the model pilot: the model decides what to do next, declares when it's done, and judges whether it succeeded. That's where drift, hallucinated completion, and silent failures come from — and why you end up steering.

Leerie inverts the relationship. The model writes code. The program runs everything else. Phases, wave scheduling, retries, caps, merge logic, and success-criteria enforcement are ordinary Python — real loops and conditionals that cannot drift.

• No silent failures. Every worker output is JSON-schema-validated before the orchestrator acts on it. A worker cannot, by malformed output or confident hallucination, cause the system to do something undefined.
• An independent verifier is the hard gate, not self-report. The implementer self-scores evidence-anchored confidence in root_cause and solution (target ≥9 on both, see DESIGN.md §8) — falsifiers tested, contradictions reconciled, gaps named with concrete artifacts — and a worker that cannot justify the score exits blocked with the gap analysis. But that self-score is advisory: a self-report has a structural ceiling (you cannot disprove a failure mode you cannot conceive), so the load-bearing check is an independent adversarial verifier — the conformer's solution_defects completeness axis — that did not produce the diff and can see gaps the implementer's own grading could not (DESIGN.md §8/§9). Everything else — tests passing, lint clean, build green, per-criterion satisfaction — is best-effort: surfaced as advisory warnings on the subtask result, never escalated to failed or blocked by the orchestrator. The criteria file is the implementer's working note, not a gate.
• Workers must justify confidence with evidence, not feelings. Before writing code, an implementer clears domain-specific evidence gates — file-and-line citations, reproductions, falsification attempts. A self-reported score without hard artifacts doesn't clear the bar, even though the score itself is advisory.
• Parallel work that's actually safe. Each implementer gets an isolated git worktree. Parallel writes never collide. Conflicts surface one wave at a time, close to the work that caused them.
• Resumable by design. A reboot, network blip, budget cap, the Claude Code subscription rate-limit, Ctrl-C, or an external kill (SIGTERM from CI / systemd / a closed terminal) all lose nothing — the run branch is the durable record, worktrees are torn down, and resume picks up from the last completed wave. When the subscription rate-limit hits and the reset time is unambiguously parseable, leerie even auto-resumes after the reset window without manual intervention. The explicit "throw this away" gesture is scripts/cleanup.sh --run-id <id> --branches, not Ctrl-C.
• Parallel-safe across runs. Multiple ./leerie invocations in the same repository each get a unique run_id (a derived branch + state directory). Their branches, worktrees, and per-run state directories never collide. Launch a fix and a feature in parallel without coordination.

The orchestrator is a Python program — not an in-session agent. It shells out to claude -p (headless mode) for each unit of LLM work. Each call is a separate process, so there is no subagent nesting anywhere. Control flow lives in real Python: for loops, if statements, counters. It cannot drift.

leerie "<task>"
   ├─ Phase 1  Classify into 1..9 categories                    → 1 claude -p
   │             ↓ derive run_id (category + slug + start-hex)
   │           • Clarify — intent-only questions (optional; skipped for fully-specified tasks)
   ├─ Phase 2  Plan — one planner per category (parallel)        → N×3 claude -p (multi-sampled)
   │           • Decompose — repo-map-grounded recursive split into
   │             right-sized leaf subtasks (P6 + P1)             → fit_judge / splitter
   │           • Reconcile — cross-domain capability-tag bridging (0 or 1 claude -p, when needed)
   │           • Overlap-judge — cross-planner surface collisions (multi-planner runs only)
   ├─ Phase 3  Schedule — global dependency graph → topo waves   (topo-sort pure Python;
   │             a satisfied-probe drops already-done criterion-bearing subtasks → 1 claude -p each)
   ├─ Phase 4  Create leerie/runs/<run-id> branch + worktree (per-run unique)
   ├─ Phase 5  Per wave:
   │   ├─ Implement each subtask (parallel, isolated worktrees)  → claude -p each
   │   │     • self-scores evidence-anchored confidence (advisory)
   │   │     • Conform — post-work doc/test/lint/build pass (advisory) plus an
   │   │       independent completeness verifier (gating) → 1 conformer claude -p
   │   ├─ Integrate the wave into the run branch; on conflict    → 1 integrator claude -p
   │   └─ Validate the integrated run branch (conflict-marker scan)
   │         (after the final wave: one more conformer pass on the whole tree)
   └─ Phase 6  Push run branch; open PR against working branch; cleanup
               (working branch not modified locally)

For the full rationale — why the orchestrator is a script rather than a plugin command, all architectural decisions, and the complete enforcement surface — read docs/DESIGN.md.

• claude CLI on PATH, logged in interactively
• For long or unattended runs, a long-lived claude setup-token OAuth token is recommended: export it as CLAUDE_CODE_OAUTH_TOKEN before launching. A container can't refresh a copied subscription token, so an interactive login alone can expire mid-run; the setup-token still bills against your subscription, not the API. See docs/DESIGN.md §6 Credential strategy for why.
• git
• A git repository with user.email and user.name configured
• A reasonably clean working tree
• A container runtime (one-time setup — see Install below)
• gh CLI logged in (gh auth status succeeds), or pass --no-push to skip the finalize PR step

Leerie runs inside a container to give cleanup a hard kernel guarantee: when you Ctrl-C, the Linux PID namespace is torn down and every worker / build / test runner is reaped, even ones that detached into their own POSIX sessions. See docs/DESIGN.md §6 and docs/IMPLEMENTATION.md §0.5 for the reasoning and mechanics. Python is provisioned inside the container by the image; you don't need it on the host.

curl -fsSL https://raw.githubusercontent.com/enricai/leerie/main/scripts/install.sh | bash

The installer auto-installs and starts the container runtime per OS (Colima on macOS via brew; containerd + pinned nerdctl on Debian/Ubuntu, Fedora/RHEL, and Arch via the distro package manager) and then clones leerie into ~/.leerie + symlinks leerie into ~/.local/bin. Sudo prompts apply on Linux. Full per-OS details and the rootless / unsupported-distro paths live in docs/INSTALL.md.

/plugin marketplace add enricai/leerie
/plugin install leerie@enricai-leerie

Then in any Claude Code session:

/leerie Fix the login timeout bug and add a regression test

curl -fsSL https://raw.githubusercontent.com/enricai/leerie/main/scripts/install.sh -o install.sh
bash install.sh --dry-run            # print actions without executing
bash install.sh                       # then run for real

Customize with --prefix DIR (default ~/.leerie), --bin-dir DIR (default ~/.local/bin), or --ref REF (default main).

If you'd rather install the runtime yourself (CI, dotfiles managers, or you want to pin a different nerdctl version), do the runtime steps manually then pass --no-runtime-install (or set LEERIE_NO_RUNTIME_INSTALL=1):

macOS (Colima manages a Linux VM):

brew install colima
# Size the VM at ~half your host's CPU/RAM (Colima's 2-CPU / 2-GB
# default OOMs under parallel leerie workloads — see docs/INSTALL.md
# for the auto-sizing the installer applies). On an 8/16 host:
colima start --runtime containerd --mount-type virtiofs --cpu 4 --memory 8
# Also add 4 GB of swap (paste the YAML block from docs/INSTALL.md
# "Memory pressure: swap configuration" into ~/.colima/default/colima.yaml,
# then colima stop && colima start). This step is optional but strongly
# recommended — without swap the VM OOMs under heavy parallel load.
curl -fsSL https://raw.githubusercontent.com/enricai/leerie/main/scripts/install.sh | bash -s -- --no-runtime-install

(Do not brew install nerdctl — the formula requires Linux. Leerie auto-installs the host-side nerdctl shim from Colima on first run.)

Linux (Debian/Ubuntu — see docs/INSTALL.md for Fedora, Arch, and rootless setups):

sudo apt-get install -y containerd
NERDCTL_VERSION=2.3.1
ARCH="$(dpkg --print-architecture 2>/dev/null || uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/')"
curl -L "https://github.com/containerd/nerdctl/releases/download/v${NERDCTL_VERSION}/nerdctl-${NERDCTL_VERSION}-linux-${ARCH}.tar.gz" \
  | sudo tar -C /usr/local/bin -xz nerdctl
sudo systemctl enable --now containerd
curl -fsSL https://raw.githubusercontent.com/enricai/leerie/main/scripts/install.sh | bash -s -- --no-runtime-install

If you'd rather not run any installer at all:

git clone https://github.com/enricai/leerie.git
./leerie/leerie "your task"   # or symlink onto PATH

The first invocation builds the container image (~60–120s); subsequent runs reuse it. The container runtime must already be set up — see docs/INSTALL.md for per-OS instructions.

# From the root of the target git repository:
leerie "Fix the login timeout bug and add a regression test"
# (substitute leerie if you used the manual install)

# Or pass a path to a .txt / .md file whose contents are the task —
# useful for multi-paragraph briefs that are awkward to quote on the shell:
leerie path/to/task.md

# Resume an interrupted or budget-capped run. Auto-picks if exactly one
# in-flight run exists; otherwise pass the run-id (see `list`).
leerie resume
leerie resume fix-login-timeout-bug-b81e90

# List in-flight and completed runs in this repository:
leerie list

# Skip the default push + PR at finalize (run completes with the run
# branch local-only; your working branch is unchanged):
leerie "task" --no-push

# Skip pre-push hooks at finalize (the user's explicit override; defaults
# off). Affects only the final `git push`; worker commits still run hooks.
leerie "task" --no-verify

# Opt into intent questions (default: no questions are surfaced).
leerie "task" --clarify

# Pre-supply clarification answers (JSON object):
# Keys are question ids from the classifier, plus "source_of_truth"
# set to "codebase", "research", or "both".
leerie "task" --answers answers.json

# Override caps (defaults: 2000 total workers, 5 in parallel per wave).
# --max-workers also reads LEERIE_MAX_WORKERS or max_workers in
# leerie.toml; --max-parallel also reads LEERIE_MAX_PARALLEL or
# max_parallel in leerie.toml.
leerie "task" --max-workers 80 --max-parallel 4
export LEERIE_MAX_WORKERS=80

# Dial how persistent the planner and implementer are at building
# confidence before they exit blocked (default 8 evidence-gate rounds
# inside each worker; see DESIGN §8):
leerie "task" --confidence-rounds 12
export LEERIE_CONFIDENCE_ROUNDS=12

# Override the default source-of-truth preference (`both`) — pass
# --source-of-truth on the command line for a one-off, set
# LEERIE_SOURCE_OF_TRUTH for the session, or commit a leerie.toml
# at the repo root with the line `source_of_truth = codebase` (or
# research / both).
# Precedence (highest first): --source-of-truth > env > leerie.toml.
export LEERIE_SOURCE_OF_TRUTH=codebase    # or: research, both
leerie "task" --source-of-truth codebase

# Choose the model. Without overrides, every worker — judgment (classifier /
# planner / reconciler / plan_overlap_judge / provision / integrator) and
# acting (implementer, conformer) alike — defaults to sonnet — see
# docs/IMPLEMENTATION.md §2 "Model selection" for the full env-var /
# CLI-flag / TOML-key table.
export LEERIE_MODEL=sonnet                # or: opus, haiku
leerie "task" --model opus
leerie "task" --model-implementer opus --model-classifier haiku

# Optional but recommended — lower the auto-compaction threshold
# for worker processes (default is 95%):
export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=70

# Chain orchestration: submit and track multi-run chains. A chain is
# N parallel `leerie --runtime fly` invocations per wave, with
# synth-merge between waves to build the next wave's base branch.
# The laptop is the sequencer; no Fly coordinator machine. No chain-
# specific env vars required — each per-job `--runtime fly`
# invocation has its own env requirements unchanged.

# Submit a new chain. Each --wave defines one wave (comma-separated
# prompt files). Waves execute in order; runs within a wave execute
# in parallel as separate Fly machines. N waves supported. The chain
# operates against $USER_REPO directly.
leerie chain \
  --wave prompts/fetch.md,prompts/lint.md \
  --wave prompts/publish.md

# ID-dispatched verbs: UUID positional → chain scope (iterates
# run.json filtered by chain_id); Fly machine id → existing
# single-run scope.
leerie status   <chain-id>   # render per-run states from run.json
leerie attach   <chain-id>   # poll run.json files every 5s
leerie stop     <chain-id>   # pause every running chain run
leerie kill     <chain-id>   # destroy every chain run's machine
leerie resume   <chain-id>   # resume every paused chain run
leerie finalize <chain-id>   # push + open PR for every unpushed run
leerie list chains         # group runs by chain_id

# Run-groups: launch N single-repo leerie runs together as a coordinated
# unit. Each member runs in its own state dir (basename-keyed), its own
# branch, and opens its own PR. Members share a group_id and read-only
# cross-repo visibility via --inspect-dir; the optional --brief file is
# prepended to every member's prompt.
leerie group \
  --repo ../api     "add /volumes endpoint" \
  --repo ../frontend "add-disk dialog" \
  --brief group-brief.md          # optional shared brief

# Resubmit with an existing group_id (keeps the same group):
leerie group --group-id <prior-group-id> \
  --repo ../api     "add /volumes endpoint" \
  --repo ../frontend "add-disk dialog"

# Group-scoped verbs (UUID → group scope across member state dirs):
leerie status   <group-id>   # render per-member run states
leerie stop     <group-id>   # pause every running member (Fly runtime only)
leerie resume   <group-id>   # resume every paused member run
leerie kill     <group-id>   # destroy every member run
leerie finalize <group-id>   # push + open PR for every unpushed member
leerie list --groups         # list all groups across state dirs

Inside Claude Code (after /plugin install leerie@enricai-leerie):

/leerie Fix the login timeout bug and add a regression test

Complete reference for every CLI flag, environment variable, and leerie.toml key the orchestrator reads.

These bare subcommands are handled by the bash launcher before the container starts. A summary appears in the leerie --help epilog; see below for full details and modifier flags.

Per-repo configuration (no container required):

leerie config is a host-only fast path — it exits before nerdctl run and never starts a container.

Lifecycle (remote mode):

resume and list are documented in the "CLI flags" table above (they interact with the task positional and --run-id/--phase); the rest of the bare verbs are listed here.

Resume modifiers (used with resume):

Build and runtime:

• Source-of-truth (highest first): --source-of-truth → LEERIE_SOURCE_OF_TRUTH → leerie.toml → default both.
• Model (per worker, highest first): --model-<worker> → --model → LEERIE_MODEL_<WORKER> → LEERIE_MODEL → model_<worker> in leerie.toml → model in leerie.toml → per-worker default → global default (every worker resolves to sonnet today). To opt a specific worker into Opus-grade reasoning, set LEERIE_MODEL_<WORKER>=opus or pass --model-<worker> opus.
• Confidence rounds (highest first): --confidence-rounds → LEERIE_CONFIDENCE_ROUNDS → confidence_rounds in leerie.toml → default 8.
• Verbosity (highest first): --verbosity → -v/-vv/-q/-qq shortcuts (anchored to normal, not to the resolved default) → LEERIE_VERBOSITY → verbosity in leerie.toml → default stream.

See docs/IMPLEMENTATION.md §2 for the rationale behind these orders and the full validation contract.

Leerie spawns sixteen kinds of claude -p worker. Each is a separate subprocess; there is no in-session agent nesting.

Additionally, two post-run workers run outside the main orchestrate loop and are not in WORKER_TYPES:

• pr_writer (prompts/pr_writer.md, default sonnet) runs at finalize when the run will push — it produces the PR title and body. Overridable via --pr-writer-model / LEERIE_MODEL_PR_WRITER.
• dep_capture (prompts/dep_capture.md, default sonnet) runs at finalize (and on --recapture / next-run backstop) — it reads worker logs, decides what the repo needs across all languages, and writes setup_packages / language_installs to .leerie/config.toml. Overridable via LEERIE_MODEL_DEP_CAPTURE. See DESIGN §6½.

Per-worker model defaults: every worker — judgment (classifier, classification_judge, artifact_registry, planner, reconciler, plan_overlap_judge, provision, provision_judge, wiring_judge, integrator, fit_judge, splitter, adherence_judge) and acting (implementer, conformer, satisfied_probe) alike — defaults to Sonnet. This was previously split (judgment workers defaulted to Opus), but Sonnet 5's judgment quality has been externally verified to match the prior Opus 4.8 baseline on these same decision-shaped tasks, closing the gap that motivated the split — see docs/DESIGN.md §"Opus-judgment, sonnet-workhorse (historical)". To opt a specific worker into Opus, set LEERIE_MODEL_<WORKER>=opus or pass --model-<worker> opus. See docs/IMPLEMENTATION.md §2 Model selection for the full precedence table.

See docs/DESIGN.md §7 for the worker contract and docs/IMPLEMENTATION.md §3 for the invocation surface (flags, timeouts, schema enforcement).

For worked end-to-end examples — from invocation through clarification, wave execution, run-branch review, and merge; and for chain orchestration (submitting, monitoring, and cancelling a multi-run chain) — see docs/USAGE.md.

Every Leerie document is reachable from this README. Architecture and code surface:

• docs/DESIGN.md — architecture, constraints, phase flow, the evidence-gated loop, deterministic enforcement
• docs/IMPLEMENTATION.md — code-surface reference (functions, caps, schemas, model / effort selection)
• docs/USAGE.md — worked end-to-end example
• docs/INSTALL.md — per-OS container runtime setup (Colima on macOS, containerd + nerdctl on Linux), Fly.io prerequisites

Policy and process:

• CONTRIBUTING.md — development setup, task-completion checklist, PR conventions (and pointer to CLAUDE.md, the repo-local guidance for Claude Code)
• SECURITY.md — threat model and vulnerability reporting
• CODE_OF_CONDUCT.md — Contributor Covenant

Post-run analysis skills (invoked via Claude Code, not the orchestrator itself):

• skills/judge-llm-batch/SKILL.md — score captured claude -p calls against a 3-dimensional accuracy rubric
• skills/llm-self-heal/SKILL.md — autonomous prompt-patch loop for failing call types

Tests:

pip install -r requirements.txt   # runtime deps — the suite imports them
pip install pytest jsonschema     # pytest is the only dev dependency
pytest tests/                     # from the repo root

The suite runs on the host Python and imports the orchestrator directly, so the pinned runtime deps must be installed too — without them, tests that exercise the auth/quota backoff fail with ModuleNotFoundError: No module named 'tenacity'. This mirrors what CI installs (.github/workflows/test.yml).

The suite covers the deterministic enforcement functions, including a coupling test that the retry-policy markers match the live check-function strings. See docs/IMPLEMENTATION.md §10 for the test layout. The worker invocation path is not unit-tested (a stub or live claude binary would be needed; out of scope for the current suite).

Acting workers use --dangerously-skip-permissions. That is a real risk surface — it is what makes the run unattended. It is bounded by two isolation layers: (1) worktree isolation — each worker operates in its own isolated git checkout, not your main working tree; (2) the container the orchestrator runs in — PID-namespace + cgroups bound every worker subprocess inside the per-run container (see docs/DESIGN.md §6 and SECURITY.md). These bound the blast radius; they do not eliminate it. Run on repositories you trust and review the run branch (leerie/runs/<run-id>) before relying on the result. Push + PR at finalize is the natural review surface; you can also pass --no-push to keep finalize fully local.

The run writes only to <state-root>/runs/<run-id>/ (where <state-root> is the resolved state directory — default $HOME/.leerie/<basename>/, overridable via LEERIE_STATE_DIR / --state-dir / leerie.toml state_dir; never inside the repo itself) and to leerie/runs/<run-id> plus leerie/subtasks/<run-id>/<subtask-id> branches. Phase 6 (unless --no-push) pushes the run branch to origin and opens a PR against your working branch — your working branch itself is never modified locally. After a run, the run branch (leerie/runs/<run-id>) is kept as an audit trail; per-subtask branches are auto-deleted at finalize, but each worker's commits remain reachable from the run branch's --no-ff merge graph (git log leerie/runs/<run-id> --graph). Remove the run branch (and any leftover subtask branches) with scripts/cleanup.sh --run-id <id> --branches (or --all-runs --branches for an audit cleanup across every past run).

• claude: command not found — Leerie shells out to the Claude Code CLI; install it from https://claude.ai/code and confirm with claude --version. There is no fallback path.

• Exits with code 10 — not an error. Leerie needs clarification answers and you are running non-interactively. Read <state-root>/pending-questions.json, write the answers to <state-root>/answers.json, then ./leerie resume --answers <state-root>/answers.json (where <state-root> is the resolved state directory — default $HOME/.leerie/<basename>/). The plugin skill at commands/leerie.md handles this relay automatically when invoked as /leerie.

• Run interrupted (Ctrl-C, SIGTERM, SIGHUP, CI cancel, terminal close, reboot) — worktrees are torn down but state.json + branches are preserved. Resume with ./leerie resume (auto-picks the most recent resumable run) or ./leerie resume <id>. Run leerie list to see what's in flight. The explicit "throw this away" command is scripts/cleanup.sh --run-id <id> --branches — Ctrl-C alone is always safely resumable.

• Run hit the Claude Code subscription rate-limit — leerie detects the session-limit message from claude -p and exits cleanly. Worktrees are torn down; state and branches are preserved. A rate-limit resets on a clock, so leerie auto-resumes: when the reset time can be parsed unambiguously it sleeps until the reset window; when it cannot (malformed time, unfamiliar timezone, or a future format change) it sleeps a fixed backoff (5 min) and re-resumes, polling until the limit clears. Ctrl-C during the wait drops to a manual resume. Auto-resume passes only resume <id>; CLI-only overrides (--model, --max-workers, etc.) on the original launch are not preserved across an auto-resume. Set those via env (LEERIE_*) or leerie.toml if you want them to survive — both channels are re-resolved on every resume.

• Run hit an expired OAuth session ("OAuth session expired") — the host's interactive login token expired mid-run and a container can't refresh a copied one. Leerie detects this as terminal (distinct from the rolling rate-limit above) and pauses resumably at exit code 75 rather than dying: worktrees are torn down, state and branches are preserved. Fix it immediately with claude /login, then ./leerie resume <id>. To avoid this class of failure entirely on long or unattended runs, mint a durable token with claude setup-token and export it as CLAUDE_CODE_OAUTH_TOKEN before launching — see Requirements above.

• Run ran out of credits — distinct from a rate-limit: credits don't reset on a clock (they return on a top-up or billing cycle), so leerie does not auto-resume. It tears down worktrees, preserves state and branches, prints an out of credits — leerie resume <id> hint, and exits with code 75. Add credits, then re-run that resume command. (An org with "extra usage" disabled at the org level is not out of credits — that's a benign standing state and never triggers this pause.)

• A subtask reports blocked — the implementer hit something it cannot resolve and bailed before integration. Read the blocker reason in <state-root>/runs/<run-id>/state.json under blocked[<subtask-id>], address the upstream cause, then resume. See docs/DESIGN.md §8 for the evidence-gated loop.

• Worktree or branch conflicts on a re-run — scripts/cleanup.sh --run-id <id> --branches removes that run's worktrees and deletes its branches so a fresh run with the same task starts clean. For a global sweep across every past run, use --all-runs --branches. Then re-invoke as normal.

• Push or PR failed at finalize — the run completed locally. Check leerie list for the run's status (push-failed / pr-failed) and read $LEERIE_STATE_HOST_DIR/runs/<run-id>/run.json for the captured stderr. The error message at finalize names the exact retry command. Local commits are intact on the run branch.

Do I need an Anthropic API key? No. Leerie runs entirely on the Claude Code CLI and your existing subscription. The orchestrator shells out to claude -p workers; no API key is read or sent.

Can I run multiple Leerie instances in the same repository? Yes. Each invocation derives a unique run_id and namespaces all of its state under $LEERIE_STATE_HOST_DIR/runs/<run-id>/ and its branches under leerie/runs/<run-id> (run branch) and leerie/subtasks/<run-id>/<sid> (subtask branches) — so parallel runs in the same clone never collide. Use list to see what's in flight and resume <id> to resume a specific one.

Does Leerie work outside a git repository? No. Per-subtask isolation is provided by git worktree; the worktree mechanism is load-bearing, not optional.

What if my project has no test runner? That's fine — running tests is advisory only (DESIGN §9 Post-work conformance). When _infer_build_lint_test() finds no test command, the conformance phase reports the test axis as not-applicable and surfaces no warning. The subtask's terminal status is determined by the implementer's confidence gate (DESIGN §8), not by whether tests ran. See docs/IMPLEMENTATION.md §5 for the conformance phase's advisory contract.

Can I see what each worker did? Yes. Every worker commits to its own leerie/subtasks/<run-id>/<subtask-id> branch during the run; at finalize, those branches are auto-deleted, but the integrator merges each one into the run branch with --no-ff, so every worker's commits remain reachable from leerie/runs/<run-id> as a named merge bubble. git log leerie/runs/<run-id> --graph is your per-worker audit trail. When you no longer need the run branch either, scripts/cleanup.sh --run-id <id> --branches removes it (and any leftover subtask branches); --all-runs --branches removes all of them.

Why not use the Claude Code SDK or the in-session Agent tool? Two platform constraints make subprocess workers the right shape. See docs/DESIGN.md §2.

Contributions welcome. See CONTRIBUTING.md for development setup, the task-completion checklist, and PR conventions. Security issues: see SECURITY.md.

MIT — see LICENSE.

See GitHub Releases for the current release. The orchestrator's phase flow, wave scheduling, cross-domain dependency resolution, and git worktree mechanics are all tested. First contact with a live claude -p session is the remaining verification step. Limitations and planned work are in docs/DESIGN.md.