v1.11.0

Added: the work graph, parallel lanes guided by the code

• maverick loop graph <task> runs a task's ready subtasks in parallel lanes, each a loop in a worktree of its own from the same integration commit. For every pair of ready subtasks it predicts a collision from the files both declare, the files one changes that the other's files import within two hops, and the files history says change together; subtasks that may collide share a lane and run in series. --plan shows the predicted collisions and lanes without running anything; --max-lanes caps them (default 4).
• The lanes meet at a fan-in: an integration worktree merges their branches and runs the whole oracle. A merge conflict, or a gate the merged lanes break, is a real collision, recorded next to the prediction; its subtasks go back to pending and run again in the next wave on the merged code. When every subtask is done, the merged work must pass every blocking gate and, for a sealed task, the holdout. The result stays on maverick/graph/<task>-<id>; .maverick/tasks/<task>/graphs/<id>.json keeps every wave, the predicted and real collisions and wall-clock time against the lanes' total.
• maverick loop run <task> --lane <id> --only 01,02 [--start-point <ref>] runs one lane by hand. A lane has its own checkpoint refs (refs/maverick/loops/<task>/lanes/<lane>/), branch (maverick/lane/<task>/<lane>), lock and LOOP-<lane>.md; it is done when its subtasks are, and never runs the holdout or the judge of the whole change. The task's own loop and its lanes never run at the same time.
• Lens: Loops → Work graphs shows each wave's lanes, the collisions predicted and the ones the fan-in found.

Added: the arena

• maverick arena run <task> --subtask <id> --providers a,b[,c] builds one subtask with several providers at once, each by a bounded loop in a worktree of its own, from one snapshot of the working copy and a private copy of the task. The winner comes from evidence, each step breaking only the ties of the one before: finished, the oracle, the sealed holdout, integrity, a judge from a model family none of the competitors belongs to, vacuous tests, the architecture delta, the smaller diff. A tie is a tie.
• arena confirm <task> <id> (a human, --by) applies the winner's change to the working copy, which must still be the arena's base, and finishes its subtask; choosing against the evidence needs --reason. The others are recorded as rejected in their loops' ledgers. Every competitor's loop joins the task's loops, so the scorecard counts it, and decided arenas add a win rate per provider. arena stats says how often the winner by evidence was the human's choice; arena status|list|verify read and check the record. Lens shows arenas on the Loops page.

Added: the flight recorder

• maverick loop replay <task> --set stall.window=3 [--set escalation=human] replays a recorded loop through the pure policy functions (budgets and forecast, ratchet, stall diagnosis, escalation ladder) under other settings and says what would have happened: stopped earlier and what it would have saved, decided the same, or diverged at the first iteration where the recording can no longer say what the agent would have done. Nothing runs. Lens: a Flight recorder card on each loop with its checkpoints and a what-if form (GET /api/loop/replay).
• maverick loop fork <task> --from <iteration> --provider <id> starts a new loop from a recorded checkpoint, in a worktree of its own, on a copy of the task with the subtasks as they were then; the original loop, its task and the checkout are untouched, and the result stays on refs/maverick/forks/<task>/<id>. Commands that default to the newest loop (status, log, verify, replay, the review budget, the PR's holdout section) ignore forks and arena competitors.

Added: proof receipts

• maverick proof sign <task> writes PROOF.json: an in-toto Statement (predicate https://maverick.dev/proof/v1) in a DSSE envelope signed with ed25519 from node:crypto, no new dependency. Its subject is the git tree without .maverick/; it records the PRD, SPEC and TECHSPEC digests, every loop ledger's head and outcome, the gates, the holdout and its overfitting index (once a reviewer decided on the seal), integrity findings, the judges' verdicts, the approvals and the models. A committed change also gets the receipt as a note in refs/notes/maverick.
• maverick proof verify [<task>] [--commit <ref> | --file <path>] checks the signature against .maverick/proof-keys/, that the code is the tree it names, that the PRD and SPEC are unchanged and that every local ledger still has the recorded head. proof keygen creates the key ($MAVERICK_HOME/keys/proof-ed25519.pem, proof.keyFile, or MAVERICK_PROOF_KEY for CI, never passed to an agent or a check) and commits its public half. proof.onPullRequest makes the pr flow sign the commit it pushes and push the note; the generated GitHub Actions workflow verifies the pull request's head.
• maverick proof export <task> --format agent-trace writes Agent Trace 0.1 with the exact line ranges each loop iteration wrote (blamed against the loops' checkpoint chains, hand edits left out); --format aibom writes a CycloneDX 1.6 AI bill of materials.

Added: explain-back (experimental)

• With review.explainBack, maverick explain <task> (and the new explain-back gate of the ship flow, which never blocks) has a read-only agent ask the reviewer three questions about what the change does, from the SPEC and the diff, in an export of the change. Answers, in Lens or with --answer Q1 --text "...", go into REVIEW.md under ## Explain-back and EXPLAIN-BACK.md.

Added: flows v2, typed DAGs

• apiVersion: maverick.flow/v2 flows have gate, agent (with a context policy and read-only or guarded edit permission), decision (a typed rubric), human, fan-out, join and explicit end nodes, and edges whose when is a typed contract on the source's outputs. Cycles, impossible routes, a missing end and a decision that leads straight to done are refused when the flow loads. One run is one pass; the contract's iteration cap and no-progress window still apply. Gate and human nodes are the flow's gates, so loops and flow approve work with them. Lens draws the DAG with each node's last output.

Added: smaller pieces

• A judge gate splits a diff larger than maxDiffBytes into up to maxParts parts (default 4) instead of leaving files out; the verdicts merge criterion by criterion.
• maverick grounding [<task>] measures grounding precision and recall: the files maverick new suggested (kept in TASK.json) against the files the task's loops kept.
• The task's overview in Lens shows the proof tree per criterion (from review-budget.json, written by maverick attention) and the explain-back questions.
• The architecture gate reuses the base tree's cached import graph when a change touches no source file and no file that changes import resolution.

Changed: concurrency

• Captured command output belongs to its invocation (AsyncLocalStorage), so loops in one process never mix their gates' output. Changes to a task's subtask graph take a lock, and the harness journals its own writes to subtask files so one lane's guard never undoes another's. One Ctrl-C handler stops every loop in the process; a second Ctrl-C exits. Worktree loops collect reports atomically.
• A flag given twice keeps both values (--set a=1 --set b=2).

Removed

• The v1 .maverick/ task and maverick.config.json at the repository root (a root maverick.config.json in your project is still read as a fallback). loop log no longer describes a rollback entry type the ledger never had; rollbacks are part of iteration-end.

Full Changelog: v1.10.0...v1.11.0

v1.10.0

• New Decide commands and sealed-suite review actions follow the Maverick CLI wordmark, status badges, spacing and next-step hints. Human reports preserve uncertainty and unknown costs; --json remains machine-readable. The help and launcher keep Get started first.

Added: Decide

• Repository scorecards from verified evidence, confidence intervals, integrity/OI penalties, repeated-run passK, and reviewed routing and autonomy patch proposals.
• Opt-in yield governor, repository-based budget forecasts, typed integrity/dispute suggestions and version-specific human calibration with a 30-label minimum.
• Isolated integrity canaries, capability security lint, declared session trifecta reports, and Lens scorecard/calibration and holdout panels.
• Independent sealed-suite review, surface import lint, dispute-linked amendments and test suspension/restoration, builder transcript vault-access checks, and an opt-in sealed ratchet that stops for human review without rolling work back.
• Applied autonomy policies constrain permissions, loop file budgets and flow auto-approval, with independent judge evidence and explicit human settlement.
• The Northstar Lens example now covers scorecards, canaries, calibration, yield escalation, disputed and failed holdouts, reviewed policy proposals, living memory and capability drift, using a disposable private home and local provider stubs. Loop details show recorded typed decisions and yield measurements.

Full Changelog: v1.9.0...v1.10.0

v1.9.0

Added: maverick why, the reason behind every line

• maverick why <file:line> walks from a line to its commit, its Maverick task (the Maverick task: trailer), the loop iteration that wrote it (by blaming the current content against each loop's checkpoint chain, so the match is exact), that iteration's agent, model, effort, gates and integrity audit, the subtask and the AC/SC criteria it serves, the judges, the sealed suite, the flows' approvals, the human review, the pull request, and the contracts and protected paths that guard the line now. What is missing (no Maverick history, cleaned checkpoints) is listed, never invented. why <task> --ac AC-02 is the reverse walk. Both take --json.
• A new MCP tool, why, gives agents the same chain without author names and without what the loop's feedback policy withholds from a builder.

Added: living contracts

• maverick done turns a task's SPEC invariants and the criteria its committed sealed tests prove into contracts in .maverick/contracts/C-NN.md, anchored to the files that implement them, with an owner and a review date (--no-contracts skips it; maverick contract harvest <task> does it on demand). unseal --commit now records which criteria each committed test proves.
• An agent whose subtask touches an anchored file gets the contract in its prompt. The new contracts gate of the ship flow (maverick contract check <task>) runs the tests of every contract the change touches: they must pass, or the task's PRD must revoke the contract (Revokes C-07: <why>); a deleted contract test always fails. Without a task (contract check --against <ref>, for CI), a touched anchor is reported as drift, and --strict fails on untested drift.
• contract list|show|revoke|review manage them; overdue reviews are listed by every check. A revocation in a task's PRD takes effect when maverick done finishes the task.

Added: the error ratchet

• At the end of every loop run, rollbacks, judge rejections, escalations and disputes become proposals in .maverick/proposals/, one per failure class, with the evidence (ledger entry, rejected diff) and the kind of fix each calls for: an AGENTS.md line, a lint rule, a skill, an integrity rule or a PRD question.
• maverick proposals accept <id> [--text] [--paths] [--agents-md] promotes one; reject <id> --reason declines it. Accepted rules reach an agent's prompt only when its subtask touches their paths, and --agents-md keeps a managed block in AGENTS.md. maverick proposals stats compares each rule's failure class per loop before and after it was accepted, and flags rules that have not reduced it for pruning.

Added: the review budget

• maverick attention <task> (the review-budget gate of the ship flow, a warning) ranks every hunk of the diff by risk: blast radius, hotspot, integrity warnings, judge uncertainty or rejection of the criterion it serves, the sealed escape set (only after the seal was opened), and whether a nearby test changed. It compares with the commit the task's newest loop started from, else the merge-base with the base branch. It writes REVIEW-BUDGET.md with the hunks to read first, a review time range and a proof tree per criterion; unless loop.feedback is detailed, the task's copy leaves out detection kinds and the judges' evidence, and the full one is in $MAVERICK_HOME/reports/. PR-DRAFT.md gets a Where to look section.
• PR-DRAFT.md's Holdout section shows the last loop's sealed counts only once a reviewer has decided on the seal.

Changed: grounding remembers

• Grounding ranks files that earlier, similar tasks planned higher, lists files that usually change together with the chosen ones, and names who knows them best (shown to you, never sent to an agent or through MCP). Spanish stopwords join English and Portuguese.
• Every graph, coupling and audit run records a snapshot of the graph in .maverick/cache/graph/; maverick graph --trend shows architecture health over time.

Added: sealed tests, acceptance tests the builder never sees

• maverick seal <task> has an agent from a model family no builder of the task belongs to (the build agent, loop.providers, routes, the fix agent) write acceptance tests from the PRD's AC-NN and the SPEC's SC-NN, read-only, in an export of the code as it is, through the surface you choose (--surface spec|techspec|boundary). --from-file <dir|bundle.json> seals a suite you wrote. Every test must fail on the code as it is; one that already passes leaves the holdout.
• The suite is encrypted (AES-256-GCM, node:crypto) in $MAVERICK_HOME/vault/<project>/<task>/<seal>/ with its results and the sealer's transcript, under a hash-chained ledger of its own. The task keeps SEALED.json: digests, counts per criterion and the approval, never a path, a test name or a line of test code. Keys come from a file (default, 0600), MAVERICK_SEAL_KEY (never passed to agents) or a command.
• The suite is checked against the code before the change: --base <ref>, else the tree the task's newest loop started from, else the working tree. A suite in which no test fails there is refused.
• maverick seal approve, maverick seal status [--reveal] (the tests, their results and the escape set, only at an interactive terminal) and maverick unseal --commit [--protect] | --discard (at review; --protect adds the tests to loop.protectedPaths). REVIEW.md gets a Sealed acceptance tests section, merge readiness waits for the decision, and PR-DRAFT.md gets a Holdout section.
• Loops query the suite at the baseline, when a subtask is done (sealed.when, up to sealed.maxQueries) and at done, in exports outside the repository. Below sealed.threshold a loop stops as the new outcome holdout-gap with the overfitting index (OI = criteria the visible evidence claims − criteria the sealed tests confirm, in points), never rolling work back. The builder learns nothing from the holdout unless sealed.feedback is count or ac. A loop whose builder shares the sealer's family refuses to start, and the escalation ladder skips that family. loop.sealed (auto, required, off, or --sealed) says whether the seal decides the loop.
• A new sealed flow gate runs the suite against the working tree; below its threshold with feedback: none it is pending for a human, never revise, and flow approve binds the decision to the suite and the exact tree. Sealed results never enter EVIDENCE.md, the ratchet or a judge's evidence.
• Maverick's own tests hold it to the invariant: after a full loop, a random marker in a sealed test is in no project file, no git object, no prompt and no leftover temporary file.
• Lens: a loop's page has a Holdout card (the seal, its queries and, once the loop stopped, the counts and the overfitting index; never a test), tokens in the budget, and the integrity warnings it kept with its quarantined notes. holdout-gap loops wait in the Inbox.

Added: checks of the checks

• maverick ablation <task> (the ablation gate) runs each new or changed test file with the change, where it must pass, and on the code before it with only the new tests on top, where it must fail. A test that passes both ways is the new integrity kind vacuous-test (warn, block at strict); a regression guard named in the TECHSPEC Test Plan is expected to pass. Writes ABLATION.md.
• maverick structure <task> (the architecture gate) compares the import graphs before and after a change: a new import cycle, a new import that architecture.rules forbids, or a health drop beyond architecture.maxHealthDrop (default 5) fails it, unless TECHSPEC declares the edge under ## Architecture. Graphs are cached by tree in $MAVERICK_HOME/cache/. Writes ARCHITECTURE-CHECK.md.
• verification.runners says how to run chosen test files ({files}, {file}, {dir}, {name}, {report} for JUnit XML); runners are otherwise inferred for node:test, Vitest, Jest, Mocha, AVA, pytest, unittest, Go, Cargo, RSpec, Minitest, PHPUnit, ExUnit and Dart.
• The built-in ship flow runs ablation and architecture as warnings; the built-in loop flow blocks on architecture, so no iteration can add a cycle.

Changed: loop feedback names criteria, not detections

• New loop.feedback (--feedback): with criteria, the default, the next agent reads regressed visible checks in full, but integrity findings become one generic line (no rule, file or pattern) and a judge's verdict becomes its unmet criteria, never its reasoning. generic says only that the attempt was rejected; detailed keeps the 1.8 behavior. Humans always get the detail: LOOP.md and LOOP-ESCALATION.md in the task follow the policy, and their full copies, the judges' reports and transcripts live in $MAVERICK_HOME/reports/. LOOP-ESCALATION.md leaves the task once you resume. The MCP loop_status tool, which agents call, follows the same policy, and so do flow run --agent fixes.
• Notes from an iteration kept despite integrity warnings are quarantined outside the work tree instead of reaching LOOP-NOTES.md, and its checkpoint (and every one derived from it) is marked tainted. maverick loop release <task> releases the notes and acknowledges the taint, on the record.
• A resumed loop records drift in its ledger: changed loop, runtime, verification, architecture or sealed configuration, a changed flow, a new or dropped seal, and oracle files you edited while it was stopped. loop.judge.isolation: "live", which never had an effect, is now warned about.

Added: tokens and costs for every provider

• Claude Code, Codex, Gemini CLI and OpenCode report token usage (and Cursor, Copilot, Kiro and Antigravity when their stream carries it), normalised to input, cached input, output and reasoning tokens. runtime.prices estimates the cost of runs whose provider reports tokens but no cost; estimates are marked as such.
• `...

v1.8.1

Fixed: the changelog has a section for every version

• CHANGELOG.md listed every change since 1.0.0 under [Unreleased]. Each release now has its own section, 1.1.0 to 1.8.0 rebuilt from the release tags.
• The release pipeline moves the [Unreleased] entries under the version it publishes and uses them as the GitHub release notes; when nobody wrote an entry, it lists the feat:, fix:, perf:, refactor: and docs: commit subjects since the last tag (scripts/release-changelog.mjs).

Full Changelog: v1.8.0...v1.8.1

v1.8.0

Full Changelog: v1.7.1...v1.8.0

v1.7.1

Full Changelog: v1.7.0...v1.7.1

v1.7.0

Full Changelog: v1.6.0...v1.7.0