How we work
One request, from the sentence that asked for it to the code that satisfies it — through every system the studio runs, each hop handing the next something it can check.
A conversation, a forwarded thread, and someone's whole problem
- 01 Frameevergo-productINTENT BEHAVIOUR REFTAG
What the product is for, and which behaviour answers which need.
- 02 Specifyevergo-specREQUIREMENT DESIGN TASK
A decision with its reasoning still attached, and nothing beneath it that descends from nowhere.
- 03 PlanspecforgeSPEC WAVE TASK
An order derived from the dependencies rather than chosen, so disagreeing with it is a small argument.
- 04 Buildpr-reviewerDIFF FINDING COMMENT
Every change read against the specification that asked for it, before a human looks at the diff.
- 05 Verifyevergo-specCHANGE GATE BLOCK
Weight, contrast, accessibility and spec-to-code drift as a red build rather than a dashboard.
- 06 Coordinatehub workspaceASK STATE ISSUE
Where it actually is, across every project — checked against a record rather than recalled on a call.
Shipped — and traceable back to the sentence that asked for it
Counted from this repository's specs/ directory when the site was built, not written
here by hand — so the figures cannot drift from the thing they describe.
What it is for
Nothing here is unusual on its own. Wired together and enforced is the part that is hard.
The wrong thing does not get built
Six months in, the thing being built solves a problem you have stopped having — and nobody can reconstruct why it was scoped that way, so nobody can tell whether it is salvageable.
It can be handed to someone else
The work turns out to be executable only by the people who wrote it. That is fine until the day it is not, and by then the cost of finding out is the whole engagement.
Nothing ships unwatched
Something breaks quietly — a page doubles in weight, a rule stops being enforced, an agreement is remembered differently by each side — and you find out from a customer.
Hop 02, unrolled
One requirement from this site's own spec, with the design and task descending from it — the REQUIREMENT → DESIGN → TASK chain above, at full size.
The visible grid is the structural identity
A drafting grid made literal: hairline rules dividing the page into cells, with + marks at every intersection. Sections occupy cells and their boundaries are the page's structure. This is the single most distinctive device in the direction and the one most easily got wrong — heavy rules produce a spreadsheet, absent plus marks produce a generic bordered layout.
Why it existsFramed whitespace reads as composition; the same whitespace unframed reads as emptiness. web3's first draft demonstrated the failure mode directly — a centred column left half a viewport of dead space and the page looked unfinished rather than airy.
Satisfied when- Must divide the page with hairline rules into visible cells
- Must mark grid intersections with a plus glyph
- Ensure the grid extends to the viewport edges rather than stopping at a content measure
- Verify the grid is decorative and hidden from assistive technology
- Should keep rule weight and colour subordinate to content.
The grid system
A Grid layer painting hairlines and + intersection marks, and a Cell primitive for content that sits inside it. The plus marks are the part that must not be dropped. Hairlines alone produce a generic bordered layout that reads as any admin template; the intersection marks are what make it read as a drafting surface. The layer is purely decorative and hidden from assistive technology — a screen reader announcing a hundred plus signs would be actively hostile.
Build the grid system
The Grid layer and Cell primitive: hairline rules, intersection plus marks, edge-to-edge extent, aria-hidden decorative layer, consistent column measure across pages.
From web4-phase-1-landingAsk us to show the specification
For any engagement, the plan is a document you keep — readable by whoever comes after us, including the parts where we were wrong and said so.