This page and its sections render JSON that CI writes at every deploy — no dashboard service, no backend, just a static site telling the truth about itself. If you have vibe-coded a working service and are wondering what growing it up looks like, this is a live worked example.
Each one follows the same shape: the principle (why this matters), the live view (real numbers from this deploy), and the receipts (links to the actual files).
Push → tests → auto-tag → publish → live QA. Two workflows, two estates, and why the version file is CI-owned.
The CI/CD story →Three layers — unit, integration, live QA — and the real bugs each one caught. No release without a green gate.
The test pyramid →A reality doc that cannot lie, a changelog with one entry per tag, and the brief → build → debrief loop that produces them.
The documentation system →No backend, your key stays in your browser, and a public line between what may be published and what must never be.
The security posture →Eleven agent roles, one human, and an issue queue worked in public — rendered live below.
The agentic team →The vocabulary behind the interface: meaning stored in a definition, one label per culture, and the English review that found three words naming the wrong thing.
The concept scheme →Every CI tag with its date, headline and diff — the per-version ledger this hub's pattern is borrowed from.
The release ledger →Work is tracked as markdown files in the repo (issues/) — created,
worked, and closed in the same commits as the code. CI renders the queue here at deploy time.
loading…
| # | Title | State | Priority | Created |
|---|---|---|---|---|
| loading issues.json… | ||||
Deciding how this product should look and read is being done in the open too. /design/ carries seven runnable candidates, each the same tool with a different answer to a different question:
Studio (editorial, a crumb line and a plain-English "next:" under every action), Console (a pipeline rail marking every step, with a live spend meter) and Card (a phone-app stepper and one sticky next button). Same flow, three theories of how much a person wants to be told while a machine works for them. None uses today's navy and green, so the test measures the design rather than familiarity.
open the candidates →English (UK & US) and Portuguese (Portugal & Brazil): two languages, four cultures. Each changes accent colour, typography, shape, register and vocabulary (ficheiro vs arquivo, ecrã vs tela), plus money, date and number formats. Every difference is annotated with the reason for it, and a matrix compares all four side by side.
compare all four →They run the real flow without a key — a scripted sample at realistic speed — and the identical code path once you save one, so a candidate can be judged by using it rather than by looking at a picture. They are prototypes under evaluation, not the shipping product: the live app is unaffected, and the pages are excluded from search indexing. The briefs behind them, and the review that accepted them, are in the Library.
The product's privacy story is its architecture (no backend — nothing to store your audio on). The engineering story works the same way: instead of telling you the service is looked after, this hub shows you the gate every release passes, the queue being worked, and the docs that record it — with links to the source of every claim. Nothing aspirational appears here without a PROPOSED label.