Handoff

Start here: three doors and the entry they hang off

Everything below is reachable from these four addresses, and the same four are written in README.md in the same pass, because a README is the page a person opens on GitHub and sending them one click further for the address of the product would be the route into nowhere this stage exists to fix.

Eight markdown files have had no visible place at one point or another, and this section is what closed them. Four were closed in August: AGENTS.md and DESIGN-artifacts.md, the draft the design document grew out of, and research/docs/product-model.md and research/docs/quality-check.md, the last of which was named by nothing at all, not even by another document. The five documents of this stage joined them the day each was written. It is worth saying out loud rather than quietly enjoying: handoff13.cjs counts "md files named by at least one html", this is an html, and the naming is the sentence you are reading. An artefact with no visible place does not exist for the person who decides, and three of these four fell out of the count again the moment this page was rewritten, which is the whole argument for running the census rather than remembering it.

The package boundary: what this is, and what it is not

This is a clickable product, not an application. There is no data layer, no API, no router, no persistence and no session. Nothing here talks to a bank, charges a card or remembers anything between two page loads. A reviewer can walk every flow end to end and a developer can read every rule, and neither of those is running software.

Every STATE is its own file. 17 screens carry 39 states between them and that is 58 html files: home.html, home-loading.html, home-empty.html, home-error.html, home-few.html, home-one.html are one screen. A real build collapses those 57 files back into 17 screens with states, and nothing in this repository says who owns that translation - it is the first decision a receiver makes and it is named here because it was written down nowhere.

Two scripts exist and they are not the same kind of thing. design/system/behaviour.js belongs to the system, is the only javascript it owns, travels with it, and draws the trend chart's cursor: 7 of the 57 screens load it. design/story.js belonged to the landing and drove its scroll choreography: 1 screen loaded it. Everything else on every screen is html and css. Updated 2026-09-30: the landing is now Light 2 and its motion is the product's own, bundled into design/landing.js (three.js and Lenis, generated, with its rebuild command in its banner), plus design/auth.js for the sign-in dialog; story.js is gone. See the live product, since v1.0.

Which theme is the main one

Light is the main one, dark is complete, and since 2026-08-23 a person can choose. The light palette is the one written on :root; the dark palette is written on [data-theme="dark"] and overrides it role by role. Every semantic role in the system exists in both or it does not exist, which is a rule of stage 08 and is checked rather than promised.

The switch you see on a screen is not the one this is about. That one belongs to design/_screen.css, the reviewer's chrome, together with the panel that names the screen and its IA node. Chrome is not shipped, and the map of the product deliberately does not include it. The PRODUCT's control is a switch in a group of its own on Settings, How Tendd looks, above the rows that leave the screen.

And the product still does not follow the machine. prefers-color-scheme stays at zero occurrences in base.css, in tokens.css and in both chrome stylesheets, deliberately: a person who has chosen a theme has said what they want, and a money app that changes appearance because the sun went down is doing something its user did not ask for.

What a real build still owes is one line in a data model, and it is written in behaviour.md rather than guessed here: where the choice lives. On the account, so it follows a person to a second device, or in the browser, so it is per-device. The switch in this package draws the state and does not keep it, exactly like the four alert switches above it, because this is a clickable product with no runtime and no persistence.

The route through the repository

Thirteen stages, one folder each, and every one of them opens on a page rather than on a folder listing. The order below is the order the work happened in, which is also the order that makes it readable: each stage's material is the previous stage's answer.

The route is checked and not asserted. design/kit/screens/route13.cjs resolves every href and src in all 245 pages against the file that writes it, every markdown link in all 72 documents, and then walks the project in a real browser from the entry page: 3522 links, 0 dead; 55 markdown links, 0 dead; 0 pages carrying a markdown link pasted into html. A browser is not optional there, because the roadmap on every page is drawn by _nav.js at runtime and a static read of the entry page sees none of it.

How it behaves

A screen shows a state. What it does not show is what leads to that state, what happens at the edges, and what a field will refuse. That is handoff/docs/behaviour.md, and the thing that makes it a specification rather than a plausible description is the source column: every row names the file it was read from, and a row with no source is not written into the spec at all. It goes to a list addressed to a person.

The roll-call closes at five. Flows in ia/docs/flows.md = described 5 + deliberately not 0. The five sources are the screen file, the flow, the IA node, the figures document - approved as a source on 2026-08-23, having been used and marked until then - and the grey wireframe - and the last of them is used zero times in all five flows, which is the honest version of "the grey is not a source of truth": it was available and it was never needed.

Nine states cannot be reached by clicking, and every one of them is right. The click graph reports them, and the spec answers each with the real trigger a build will fire: a bank connection that goes stale, a merchant with no cancellation guide, a person who has never had an account, a renewal that fails on a card that was working. The largest single reason is that the canonical person in this package is on Free, so the two screens that only a paying account ever sees have nothing to link them.

What each screen is made of

handoff/docs/map.md is read off the code by design/kit/screens/map13.cjs, which serves the repository to a browser, walks all 57 screens, and writes its raw output beside itself. It is in three parts and the third is the working one.

The inversion is two knees deep and that is the whole of why it works. A component reads colour only through a semantic role, so a flat inversion would name no primitive at all and the entire primitive level would report as unused. The chain followed is component to semantic role to primitive, in both themes, since a dark role points at a dark primitive.

The roll-call closes and the idle control is a number rather than an impression. Screens named by the registry 57 = mapped 57, with nothing on disk that the registry does not name and nothing named that is not on disk. Zero components stand on no screen, asked here for the third time and against the whole product rather than a sample. Three tokens are reached by no chain, and all three are accounted for: two are the width points, which a container query cannot read through a var(), so the token holds the decision and the literal in the query is its application; the third was declared idle and kept, with the date, in the file that declares it.

Accessibility

handoff/docs/a11y.md introduces nothing. Accessibility was built at stages 08 to 11; what was missing was not the work but the PROOF. So every row carries four things and the third is the one that matters: item, where it is in the code, how to check it, and a status of exactly two words. "Confirmed" means a run on 2026-08-23 with the instrument named in the row, never a memory of stage 08 doing it, and a row for which no instrument can be named never gets the word.

Two rows were real failures when this stage measured them, and both closed the same day. Nine screens scrolled sideways at twice the default text size, all on a phone and none at desktop width; and the trend chart, made focusable at runtime and not a native control, wore the browser's own focus ring. They went to the backlog as debts, because the product was accepted at stage 12 and an edit would have voided every pixel comparison it stands on - and then the founder lifted the freeze. Nine became 0 of 114 and the ring is the system's, with zero boxes moved at 360 or at 1440.

And the instrument had to be made deterministic before any of its numbers could be believed. Its first two full runs reported catastrophic contrast failures, sixteen in one and twenty-eight in the next, on different screens each time, and none of them reproduced in isolation. The cause is in the system: every interactive element transitions its colours over the state duration, so asserting a theme starts a cross-fade across the whole page and a sample taken inside it compares one theme's ink against a surface halfway to the other. The contrast and focus passes now run with reduced motion emulated, which makes the product's own reduce block zero every duration; the motion pass needs a context of its own, since measuring the baseline inside a reduced one would report the reduce block as the product's motion, which is a check that always passes and proves nothing. Two consecutive runs now return byte-identical output, and that determinism is part of what "confirmed" means.

How to add a feature

There is a ready prompt for it: handoff/docs/one-shot.md. Copy it, put your feature in the one blank it leaves, and hand it to whoever is building - a person, or a model in a fresh session. It leads to all three documents above, carries the growth rules word for word from the files that own them, and repeats no value from any of them.

It was written to be tested, and it was tested twice on 2026-08-23 by two readers with no memory of this project, on two different features. Each was given the prompt and nothing else, and each was sized before the run rather than after it - four states and three - because a reader who does not stumble on a feature of two states has proved nothing. Both built something the instruments accepted: zero style violations, zero contrast or focus failures across the grown corpus in both themes, zero prose past the reading measure at fifty-eight widths. Neither screen is in the product, and the reason is in "deliberately not done" below.

The second list is not shorter, and saying so is the point of running the exam twice. Thirteen readings became twelve, which is no improvement worth claiming. What did change is WHICH readings: the second reader named five paragraphs of the prompt that did real work and said what each one saved it, and only one item on its list repeated a difficulty from the first. That one is the paragraph the first run's own fix created - the test for whether a feature is a new screen or a state of an existing one - and the second reader had to break the tie itself because the rule and the cautionary tale beside it pointed at two different tables. It is a three-row table now instead of a sentence. A prompt that is measurably better and still produces a list that long is a prompt that is working and is not finished, and the honest form of that is a number rather than a paragraph of comfort.

What the exams found about the product, rather than about the writing, is two rows and both are in the backlog: a rewrite that the line inventory's own log records as done and that was applied by halves, still carrying the word two documents agreed to drop; and a shipped button label that breaks the voice's own rule about how a button addresses a person, in three places at once. Neither had been seen before, because no instrument compares a line in the inventory against the rules of the voice, and nobody had read the two side by side.

The census: what is on disk

Counted by group rather than by folder, because a receiver's first question is not "how many files" but "how much of this is the product, how much is the argument for it, and how much is scaffolding I can ignore". Every figure comes from design/kit/screens/handoff13.cjs, whose corpus is git ls-files - what a receiver actually gets - with a walk of the tree kept as the fallback for a copy that is not a checkout. Neither is a list somebody typed.

Two numbers are worth reading together. The product is 8225 lines of html and the argument for it is 26172 lines of markdown, more than three times as much. That ratio is the pipeline's shape rather than an accident: every value in the system carries the decision that put it there, and a decision with no ground is the thing this repository spends its words refusing.

These figures were each one line per file too high until the critique of this stage. The census counted lines with a split on the newline, which returns an extra element for the empty string after a file's final newline, so every group total was inflated by the number of files in it. The read-only pass found it from the outside, by flagging a line count on this page against the census's own and calling the page wrong; the page was right. A census that is off by one on every file is worse than no census, because the error is invisible at any single row.

The lift test

The design system's central claim is that design/system/ is liftable whole. It had been asserted in three places and measured in none, so on 2026-08-18 it was measured: the folder was copied into an empty directory and one screen the system had never seen was assembled there out of its classes alone - the shell, the app bar, the brand lockup, the big total, the interactive trend chart, the segmented range, a prose card, a divided list, the trust block and the tab bar.

Every url() inside the folder resolves inside it, assets/ included - which is why those four washes are part of the lift rather than decoration. The chart's cursor was built by behaviour.js, the only javascript the system owns, and it works in the empty folder exactly as it works in the product.

And one dependency it cannot provide

base.css asks for Inter by name and nothing in the folder provides it: no @font-face, no file, no import. The lift test passed without noticing, because the machine it ran on has Inter installed, which is exactly the shape of failure a handoff exists to prevent. It is written down now in the two places a person looks - design/system/CLAUDE.md under "What this folder does NOT carry", and at the declaration in base.css, which is the line somebody greps for.

The run surface

The census asked what a receiver needs before they can open anything, and in its first run the answer was almost nothing existed: no package.json, one file in the whole repository telling a person how to run something, and every instrument resolving playwright from a global npm root - one of them from an absolute path inside one machine's npx cache, which was the least liftable line here.

Every instrument resolves playwright local first and global after, so it runs for a receiver who typed npm install and still runs on a machine that never had one. node_modules/ is ignored; nothing in this repository is built from it and nothing is published.

The remaining six are the ledgers and pixel proofs of stages 08 to 12 and are kept for the same reason their stage pages are: a claim with no instrument behind it is a claim, and the instrument is how the next person disagrees with it.

What is open, counted rather than remembered

Read off design/kit/docs/backlog.md by a script that classifies each row by what it says about itself, so the number cannot drift from the file.

The one row addressed to this stage is the largest structural debt in the repository: a per-component coloured footprint is written by hand in forty places and nothing recomputes it, which is why twenty-one component pages went stale the day the corpus grew. It has an instrument, counts.cjs, and what it does not have is the discipline of being run - which is the honest state of it and is why it is still open.

The count of the founder's own rows moved from twenty to five between two runs, and the reason is not drift. The founder took twenty-one decisions on 2026-08-20 and the rows that record them still carry the word in their prose. The census now prints two readings rather than one - rows where the founder is the OWNER, and rows that mention the founder anywhere - because a single number would have made a closed decision look like an open one.

Who decides after the handover

Two lists in this package are addressed to a person and not to a builder, and without an addressee the first row of either stops the work. They are not defects. Each one is a place where the code is consistent, the documentation is silent, and somebody has to say which way it goes.

Four things that were so on purpose and written down nowhere, and the day they stopped being

From the onboarding log, where a clean-context reader was sent through the repository twice and every finding was verified line by line against the files before it was believed. All four were put to the founder on 2026-08-23 and all four were answered the same day, which is why this table has a third column that says what happened rather than what is owed.

Seven behaviours no file stated, and the day they were stated

From the behaviour spec, which refuses to write a row it cannot source. All seven were put to the founder on 2026-08-23 and all seven were answered, and the list is kept exactly as it was written rather than deleted: a spec that quietly removes its own open list is one that cannot be trusted with the next.

What is deliberately not done

So that a decision is not read as a hole. Everything here was available and was refused, and each refusal has a reason that survives being written down.

The critique, on two instruments

Run 2026-08-18 the way CLAUDE.md requires it: Codex read-only on the source and Claude in a browser on the render, taken independently and merged afterwards, with a column saying who found what. 22 findings, 22 closed, none dropped at verification - and the two most valuable ones were each produced by checking the other instrument's work rather than by either instrument alone. The closing round of this stage adds its own and lands in this section.

Nothing was dropped at verification, which is unusual and is worth one sentence rather than a celebration: the read-only pass was given a scope of files changed on one day, and a narrow scope is what makes a critic precise. The one finding that could have been dropped turned out to be the most valuable in the run, because the instrument was the wrong one.

Round 2, 2026-08-23: the closing pass over this stage's own material

The same two instruments, the scope narrowed to what stage 13 produced. Eleven findings, ten closed, one filed, and four dropped at verification inside a single row - every one re-read in the file it names before it was believed. Seven came from the read-only pass, three from the browser and the design detector, and the split is exactly what the two instruments are for: the sharpest source finding is a rule this package could not obey, and the sharpest render finding is a contrast failure no source read could ever have produced.

Was unclear, became

This stage produced no screen and no component. What it produced is a package that answers questions it could not answer before, and the honest way to show that is the pair: what a stranger actually asked, and where the answer lives now. Every row on the left was said out loud by a reader with no memory of this project, in one of the three clean-context runs, and none of them was imagined by the person who built it.

The contract of this stage, checked

The list a handoff has to satisfy, as a table rather than as a paragraph, so that a disagreement lands on a row. Every "yes" here is a run or a file, and where the answer is partly no it says so.