AI-built Human-directed Auditable

A real application, built to a regulated standard — almost entirely by AI.

foragerr is a self-hosted manager for a comic library you own. Its code, tests, and documentation are written almost entirely by Claude, under a spec-driven, requirement-traced process — directed, reviewed, and approved by a single human operator. This site is the record of how it's built.

FRG-SER-019 Traced
Trades never suppress single-issue wanted
One requirement, followed end to end — from the live traceability matrix.
Specopenspec/specs/ser/spec.md
Testsbackend/tests/library/test_booktype.py +4 more
Commitsfdccb70, 37518cb, b927f19
Statusimplemented · M3
375
requirements in the registry
305 of 305
implemented requirements have tagged tests
57
tagged releases
52
risks tracked in the register
The regulated-software story

Discipline is the product, as much as the software is.

Four practices, borrowed from regulated engineering, applied to an AI-authored codebase.

01A requirement registry

Every behavior foragerr is meant to have is written down first, with a stable ID. IDs are allocated in the registry when a change is proposed, and a commit hook rejects any commit citing an ID that is not registered.

IDs allocated before codeNever reused or renumberedEnforced by the commit hook
02End-to-end traceability

Each requirement links to the spec that defines it, the tagged tests that prove it, and the commits that built it. The matrix is regenerated from repository state — spec headings, test tags, commit trailers — and inconsistencies fail the run.

Requirement → spec → test → commitGenerated, not assertedGaps are visible, not hidden
03Per-change review gates

The owner approves every proposal before implementation begins, and no change merges until its gate passes: the full test suite green, traceability and dependency checks at zero, and a multi-angle review of the diff.

Owner approval before codeFull suite + consistency checksMulti-angle diff review
04Release records

Every tagged release carries the same four artifacts: a CHANGELOG entry citing the requirements it moved, an annotated tag, the pushed history, and a GitHub Release. Tags are immutable — a mistake gets a new patch release, never a moved tag.

CHANGELOG + tag + GitHub ReleaseRequirement refs in every entryTags are immutable
Trust center

The evidence is public.

The requirement registry, the traceability matrix, the risk register, and the threat model all live in the repository. This is the index into them — no PDFs behind a form, no marketing gloss.

Open the trust center
Product timeline

Watch it get built.

57 tagged releases mined from the changelog — every one recording what changed and which requirements moved.

See the timeline