ANVIL

TDD: tests before implementation

"ANVIL is a composable software factory: spec first, tests first, and no station approves its own work."

Full name: ANVIL, Agentic Network for Verified Implementation Lifecycle.

See it working

Landing page: anvil-landing-7x1.pages.dev explains what ANVIL is: the problem it solves, how the line works, and the proof built on it. The page itself was built by ANVIL under work order wo-gh-35 and went through the same review line as everything else here.

Real run trail: wo-gh-9 shows the complete cycle from work order through five independent reviews to merge. Every station's packet, every review file, and the final report are preserved in the runs/ directory. No mockups - this is what the factory actually produced.

Live example: The Taskline repository is a working task board API built entirely on the ANVIL line from a blank slate, with spec-first, red-green TDD evidence, and all station artifacts committed to its tree.

Built by ANVIL

Three projects running in production, built on this factory:

• Sentia - Full-stack web app with database persistence, built from spec through deployment verification on the greenfield pipeline
• Platform25 - Playable game built through the content pipeline with media production and brand review stations
• Status Board - Live factory run status, generated from run reports and published automatically

Each proves the same line can ship software, content, and infrastructure.

Quickstart

Clone the Taskline example and see the factory output in under a minute:

git clone https://github.com/arananet/anvil-example-taskline.git
cd anvil-example-taskline
python3 -m unittest discover -s tests -v

You will see 6 passing tests mapped to spec scenarios, a complete run report in runs/, and review files from five independent reviewers. The example completes in ~0.3 seconds.

If ANVIL is useful to you, a star helps other builders find it.

Why you can trust the output

1. No station approves its own work

Every agent station writes to its assigned artifact file (builder writes code, reviewers write review JSON). The approver station reads only the review files - it cannot see station output or logs - and aggregates verdicts using deterministic parsing that fails closed. If a review file is malformed or a verdict is missing, the run is rejected, never assumed pass.

Independent review evidence: runs/wo-gh-9/reviewer-spec.review.json, reviewer-security.review.json, reviewer-tests.review.json, reviewer-architecture.review.json, reviewer-design.review.json - five independent reviewers, none of which built the code.

2. Memory with provenance

The factory brain learns from run outcomes, but agent-written learnings never reach verified storage directly. New learnings wait in brain/inbox/ (quarantined) until deterministic code verifies their provenance field against an actual run report that produced the claimed outcome. Only verified learnings promote to brain/learnings.md. This is the project's answer to benign memory contamination (CONTAM-Bench): the brain cannot learn from hallucinated runs.

Provenance gate implementation: docs/MEMORY-GATE.md

3. Human gate before publishing or production deploys

Any work order with a publishing or production deploy risk hint stops at the triage-human station for explicit human approval before the deployer or publisher stations run. The factory prepares and checks, but a human decides what goes out. Runs that reach the deployer without approval are rejected at that gate.

Evidence: runs/wo-gh-9/report.json line 147, triage-human station status: "executed", blocking risky work.

What it is

ANVIL is a framework for running software work down a line of 27 stations. Each station has a manifest and a clear contract. Some stations are deterministic code: intake, gates, the approver and human triage. Agent stations are explicit contracts, a manifest plus a prompt packet. The runner never pretends a model ran: for an agent station it writes a packet file and marks the step packet_ready.

A project keeps everything in its repo: specs, tests, reviews, run reports, envelopes and a brain folder with context and decisions.

The factory ships 8 pipelines and over 500 tests covering the full SDLC, content production, and greenfield builds.

One core, two domains: software and content

The factory core (work orders, pipelines, gates, envelopes, approver, human triage, brain) does not care what the line produces. Domains are station sets that plug into the same core:

• Software is the default domain in this repo: spec-writer, test-writer and builder produce code, and five software reviewers check it. The spec is the contract and tests are the evidence.
• Content ships in the same catalog: brief-writer, researcher, writer and media-producer produce a piece, and five different reviewers check it in parallel (facts against sources, voice, platform fit, brand risk, UX). The brief replaces the spec, the source pack replaces the test base, and two deterministic gates check the brief and the AI generated disclosure on the draft.

여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗