A development method

Spec-driven, ratcheting vertical slices, verified three ways.

How a set of planning documents became a working, dockerized, versioned product: we shipped thin, end-to-end slices — each traced to a requirement, each proven three ways, each “clicked in” to version control before the next one began. Forward-only, like a ratchet.

15+
independently shipped & tagged slices
verification on every slice — static · behavioral · data
2
milestone releases — v1.0.0 plan-complete, v1.1.0 experience-complete
01

Five principles that governed every decision

i

Spec is the source of truth

Every feature traced to a numbered requirement. Nothing built “because it’d be cool.”

ii

Ratcheting

Atomic gains, locked in and never backtracked. If it isn’t committed & documented, it didn’t happen.

iii

Vertical slices

Each slice ran full-stack and shipped on its own — never “all the models, then all the screens.”

iv

Compliance is the core

Consent, audit, access control and retention were the spine; features attached to them.

v

Human steers, process runs

The person chose direction at every fork; the loop executed and verified the rest.

02

The engine — the same loop, every slice

One numbered sequence, repeated. This is the part that made progress predictable.

01

Scope

Pin the slice to one spec section.

02

Schema & migration

Model it, migrate, regenerate the client.

03

Access & queries

Role rules, labels, the data reads.

04

Server actions

Every mutation: auth · role check · audit.

05

Build the UI

A client-record section or a new route.

06

Surface it

Add the work to the daily exception view.

07

Seed

Fictional demo data only — never real PII.

08

Static verify

typechecklint → production build.

09

Behavioral verify

A script drives the real UI end-to-end.

10

Rebuild containers

The running system now matches the commit.

11

Click it in

Update the coverage map & handoff note → commit → fast-forward main → annotated tag. The click of the ratchet.

↻ repeat for the next slice — forward only
03

“Done” meant passing three gates, not one

Static proves it compiles. Behavioral proves it works. Data proves it persisted.

Staticcompiles
  • Type-checks clean
  • Lints clean
  • Production build succeeds
Behavioralworks
  • A browser script logs in
  • Clicks the feature end-to-end
  • Screenshots confirm the look
Datapersists
  • Direct database queries
  • Confirm the action truly saved
  • Never trust the screen alone
Why it earns its keep This caught bugs that tests-in-isolation miss — a dashboard silently serving stale data (404s), a checkbox submitting "on" instead of its real value, and container port races. The gate is the difference between “it ran” and “it’s right.”
04

Traceability, kept as living artifacts

The paper trail wasn’t overhead — it was how progress stayed honest and visible.

Decision records (ADRs)

before building

The significant, hard-to-reverse choices — the stack, the authentication model — were written down and justified before a line was built.

Living coverage map

2 → 15 ✓

A colour-coded map of all 15 workflow steps, updated every slice — so the answer to “how far along?” was always current and honest.

Handoff log

every click

Each ratchet click recorded what changed and exactly how it was verified — a running record any teammate or future session could pick up cold.

GitFlow ratchet

develop → main → tag

Active work on develop, fast-forwarded to main, then an annotated version tag. Every stable state is a named, recoverable point.

05

The ratchet, over time

Each tag is a notch — a shippable state you can never fall behind.

Tagged releases · forward only
mvp
spine + journey
providers
directory
privacy
client rights
v1.0.0
plan complete
whiteglove‑t1
relationship
whiteglove‑t2
logistics
v1.1.0
experience complete
06

What it produced — and what it cost

The outcome

  • 01A planning document became a dockerized, tested, v1.1.0 product — the operational plan and the white-glove experience layer.
  • 02~15+ slices, each independently shipped, tagged, and verified.
  • 03Every mutation audited · access role-scoped · fictional data only, until the launch gate — the compliance the domain demands, by construction.

Worked because

Small, reversible steps plus constant verification = low risk, always shippable, progress always visible — and the human stayed in control at every fork without babysitting execution.

The honest trade-off

The per-slice ceremony — migrate, verify, rebuild, tag — is heavier than “just code it.” Deliberately. In a regulated, audit-heavy domain, that overhead is the product.

07

Pubert agent — the manager layer around the work

The coding loop sits inside a wider system: delegated execution, persistent context, and prepared infrastructure.

PPubertPrimary agent, manager layer, continuity keeper.
S1SimonGateway node, web edge, public routing surface.
S2Simon2Subconscious node, storage, graph memory, heavy processing.
Human in the loopvision + audit
humanArchitect / AuditorSets direction, approves trade-offs, verifies outcomes through logs and visible behavior.
primary agentPubertMaintains continuity, locks in plans, delegates surgical work to specialized agents.
Coding Sub-agentsOperate inside the prepared environment instead of redesigning infra on the fly.
Infrastructure layergateway + engine room
gatewaySimonPublic face: SSL, Nginx routing, application entry points, and served experiences.
subconsciousSimon2Heavy storage, graph memory, ingestion, video hosting, and high-volume processing.
Public WebThe routed surface exposed through the gateway once the system is prepared.
Continuity layermemory + ratchet
Kuzu graph memoryEntities, tasks, and relationships survive across sessions without replaying every log.
Log ingestionOperational history is shipped and structured so the system documents itself.
ADRs / manager notesConstraints and road-paving get fixed in writing before app-level changes begin.
Pubert = orchestration Simon = gateway Simon2 = storage and processing
1. Prepare the ground

Pubert configures the environment first: routing, storage, permissions, memory shape, and the written decision trail.

architect → pubert → ADRs / infra
2. Delegate narrowly

Once the environment is ratcheted into place, specialized coding agents step in for targeted repo work instead of broad system design.

ADRs / notes → coding agents → app changes
3. Preserve continuity

Graph memory and logs keep the state alive between sessions, so work can resume from entities and decisions rather than from scratch.

logs + graph → continuity of context
4. Keep the human accountable loop

The person remains the architect and auditor. Pubert is the system administrator and project manager layer, not the final authority.