Take it from here

What this is

One sentence, and the rest of the page assumes it

The person it is built for is Rasha Idrissi, a Tier 2 analyst four years into operations, who arrives distrusting AI tooling. Every trust mechanism in the product argues with that rather than assuming it away. She is described in personas, and where two decisions conflict, hers wins.

Three links

The repository, the product, the system

The edge of the package

Three things to know before you open anything, because the opposite is the natural assumption

The route through the repository

Which folder, what is in it, who reads it

Two rename maps, and they are in one file under two headings, which is worth knowing before you go looking: design/kit/docs/inventory.md section 10 carries the stage 08 map, and the later renames, nf to miss among them, are in section 8.

Which theme is the real one

Dark by default, and the light one is now a control rather than a proof

The console ground is dark and that is what ships. :root carries it, and with nothing stored that is what a person gets. The light theme exists as [data-theme="light"], it is complete, every role is paired into it, and since 2026-08-27 the analyst can reach it: the second control in the top bar, beside the name, and the choice is remembered.

The default is a decision and not an accident, so do not make it follow the machine. prefers-color-scheme is deliberately never read. The dark ground was argued against the reading research and settled on the rota that 79 per cent of these teams run; an operating system that happens to be light is not evidence about that rota. If you are asked to make the console follow the system, that is a product decision with an owner, not a default anyone should quietly flip.

Two consequences for you, and the second is the one that bites. A colour role is written twice, in the same edit, and the two values are not the same primitive: contrast is computed against the opposite ground, so the light side takes a different step of the ramp. A role written once loses its focus ring in the other theme, and nothing but reading the two lines side by side finds it. And a new screen must link design/system/theme.js from its head, above the stylesheet. Omit it and nothing looks broken: the screen renders dark and the bar quietly comes back with one control instead of two.

The consequence for you is one line: a colour role is written twice, in the same edit, and the two values are not the same primitive. Contrast is computed against the opposite ground, so the light side takes a different step of the ramp. A role written once loses its focus ring in the other theme, and nothing but reading the two lines side by side finds it.

How it behaves

The part you cannot see by looking

The screens show you what things look like. They cannot show you when the error appears, what counts as valid, what stands in the pane when nothing is selected, or where success goes. That is handoff/docs/behaviour.md, and it covers all four flows: rule on the case, pick up and hand off a shift, answer for a decision months later, and get in and arrive where the link pointed.

Every row in it names its source, and the source is one of three: the file of the screen, the flow diagram, or the specification of the IA node. A behaviour with no source is not written there at all. It goes into a list called NOT SETTLED and waits for a person, because behaviour is exactly where a plausible invention is indistinguishable from a decision.

Two rows are in that list today and neither blocks anything built. They are named on the page rather than resolved by guess.

What every screen is assembled from

And what moves if you touch a token

handoff/docs/map.md goes both ways. Downward: screen, zone, component, the tokens that component reads, where its text is addressed. Upward, and this is the half you will actually open: for every token, every screen it stands on.

The upward list is an inversion of the downward table rather than a second pass over the code, because two editions of the same data drift apart and the one that drifts first is the one nobody opens. It resolves in two knees, component to semantic role to primitive, because a component reads colour only through a role and a direct search would put the entire primitive level in the dead list.

It was taken by opening all 62 screens in a browser and walking the rendered DOM, not by matching patterns in the files. Two of the components on every screen are rendered by javascript and appear in no markup at all, and the zone of a component is its ancestry rather than its spelling.

Accessibility

Already built, and here is how to check it yourself

handoff/docs/a11y.md lists every point, where it lives in the code, a command or an action that verifies it in under a minute, and a status with exactly two values. A point with no way to test it is not on the list: it would look like finished work and would not be.

Confirmed means run at this stage, not remembered from an earlier one. Contrast, a real keyboard walk in both themes, browser zoom at 200% and the reader's own font size at 200%, and computed style under reduced motion, all across the whole product.

It ends with one real failure, found by an instrument written for this checklist on its first full run: the focus ring on the record rail measures below the non text threshold in the shipped dark theme. It is not fixed here. The handoff documents the product, and changing a state token after the product was accepted would void every measurement that acceptance stood on. It is a row in the backlog with a named owner.

How to add a feature

The prompt, ready to paste

handoff/docs/one-shot.md is not advice about prompts, it is the prompt. Copy it, put your feature where it says, paste it. It was written for the exam this stage ran and it has been through that exam twice, on two different features, with two agents that had never seen this repository: node 7.1 Tenant detail, which is in the product, and node 6.1 Client summary draft, which was a probe and was deleted.

This page carries its opening rather than all of it, and the reason is a rule of the package. Documentation here references code and never restates it, so a second copy of a 180 line prompt on this page would be the one that goes stale. What is worth having in front of you is the shape: the prompt is a ROUTE before it is an instruction, and the first thing it does is send the reader to the three files this stage produced.

The part nobody thinks to ask for is the last block, and without it the screen exists only on disk. A screen goes flat in design/ with no subfolder, one file per state named <screen>-<state>.html, it links exactly two stylesheets, it carries the design only panel the other screens carry, and it is registered in design/_nav.js. Without that last line the coverage map does not know it exists and the hub will not render it. Its strings go into voice/docs/microcopy.md section 8 with a page and a zone.

And it forbids inventing in the file of a screen without forbidding growth, which are two different things and the difference is the whole of it. No @media, no transition, no animation, no @keyframes, no <style> and no style= in a screen: those words are copied out of design/system/CLAUDE.md rather than paraphrased. What is missing appears in the SYSTEM first, as a complete component with its five parts, and only then stands on the screen.

Who decides

Because two open lists in this package are addressed to a person

Both open lists in this package, the NOT SETTLED rows in the behaviour specification and the debts in the accessibility checklist, are addressed to the owner of the product, which in this repository is its author. A row on either list is a question, not a defect, and answering it by reasonable inference is exactly the failure both lists exist to prevent.

If there is no owner to ask, the rule is the one this whole project runs on: write the question down where the work is, ship the rest, and say out loud what you assumed. An assumption that is stated can be corrected. An assumption that is implemented cannot be found.

What is deliberately not done

So that a decision does not read as a hole

design/kit/docs/backlog.md holds every one, with what is missing, where it is visible, why it was deferred and who closes it. An entry with no owner is a wish rather than a backlog item, so there are none.

What is in it: neither webfont is loaded, which is the one item that costs money and a request; a field has no error state, which is a voice decision before it is a visual one; twenty three collapsible blocks that need twenty three summary sentences nobody has written; and the two debts this stage added.

And six nodes have no screen at all, deliberately: clusters 6 and 7, which are the client summary and the autonomy grants, plus permission denied. They carry a record in the registry with a count of zero, so the coverage map renders them as work not done rather than hiding them. Only one of the six has a written specification, and that is what made it the exam of this stage.

Was unclear, became

What readers with no context could not find, and where the answer is now

Every question on this page came from somebody who had never seen this product. The full log, with each question, where the reader looked for it, the verdict on whether the answer really was missing, and what closed it, is handoff/docs/onboarding-gaps.md.

It has two halves and they are counted separately on purpose. Twenty agents built the last ten screens of the product from a written contract, each reading the design documentation for the first time, and what they had to ask is the first half. One reader was given the repository and this stage's own question, which is different: not one screen from a briefing but the whole product from the README down.

The numbers, and the two halves stay apart. The reader of this stage returned 13 questions of its own: 10 it could not answer and 3 it answered wrongly, which is the more expensive list. Of the 10, three were really absent, four were decided long ago and written down nowhere, and two were present and not where it looked, which is a defect of the route rather than of the documentation. The rollout's twenty readers contributed 15 more, 12 of them really absent. The exam then ran twice, on two features, with two agents that had never seen this repository: 7 gaps on node 7.1 and 10 on node 6.1.

The second list is longer than the first and that is said out loud rather than smoothed. None of the first run's gaps recurred, and the agent cites the paragraph that closed each one. What grew is not the package: of the second run's nine, about three are this handoff and five are the IA and the voice layer being genuinely empty for a cluster the track deferred. A feature with no node specification costs the reader more than a feature with one, and that is a fact about the map rather than about the guide.

And the critique of this stage, by class. Four instruments: an independent read only pass, this session's own pass over the code and in the browser, the two reader sets above, and one that returned nothing because it could not run.