specgate/docs v0.20.0

Proven on real products#

Note

A real client brief, built by an agent with Specgate. The brief came from a real client; the product was built end to end by a coding agent (Claude) driving Specgate, with business decisions delegated to it and written down as assumptions. It is not a customer deployment, and the code repository is private.

These six pilots are agent-driven adoption, not a customer story. Each one started from a brief a real client wrote — vague, detailed, heavy on architecture, or regulated — and ended as a working product with its specification, tests and CI. The numbers come from each product's generated traceability matrix and its test suite. What these pilots are not: a team choosing Specgate and using it on their own. That reading is still to come.

Every page lists what Specgate got wrong during the pilot and the release that fixed it. Most of the tool's rules exist because a pilot needed them.

Side by side#

ProjectBriefStackRequirementsTestsWaitingSpecgate defects found
Rebar CrewDetailed, hand-written as domain packsExpo + Next.js, hexagonal TS core47 of 47599032 (one open: #21)
BookingsDetailed, with screenshotsNext.js + hexagonal TS core38 of 38212022, plus #60
Credit shopVagueNext.js + hexagonal TS core24 of 2427202, plus #60
FinCoreArchitecture-heavySpring Boot 3.3 · Java 21 · PostgreSQL59 of 601121 (REQ-055)7, plus #79
EventTechArchitecture-heavyQuarkus 3.40 · Java 21 · PostgreSQL38 of 387102
HealthTechRegulatedQuarkus 3.40 · Java 21 · PostgreSQL23 of 24351 (REQ-020)1

Requirements include REQ-001, the adoption baseline. Java test counts are the suite's run totals; Bookings and Credit shop are test cases counted in the source; Rebar Crew is its suite's total at the end of the pilot. #60 — init proposing requirements on a fresh skeleton — was hit by three pilots.

What all six found#

The gate verifies what the specification says. Running the product finds what it does not say. In every pilot, using the running product turned up something the green gate could not see: a product with no screens, an API with no button, an action on an id nobody could list, a build that failed in production, an application that did not start. Each one became a short follow-up change — and several became rules in specgate draft --check. The path from a brief to a specification is in From a client brief to a spec.