PURE interface standards — the full suite

Tabs — the folder standard

Mike's rule, 8/21: an unselected tab must still look like a tab. A folder shape sitting on the baseline — cream fill, hairline border, rounded top corners — never a bare text label you have to hover to discover. The selected tab joins its panel: white fill, navy border, a 3px gold rule inside its top edge, and the baseline opens under it.

Top bar

The 60px navy bar with the gold hairline is chrome — the shell renders it, never the page. Active section = gold-washed pill. Search sits in the bar, right side, pill-shaped.

Tables

Semantic <table> always — a grid of divs is invisible to assistive tech and to pure-table.js. Filter row above; sorted column carries the gold inset rule.

KPI & BI reports

KPI tiles carry the 3px gold top bar and the Down-Right shadow. Deltas are colored text, not arrows-in-circles. Bar lists beat pie charts at every size; navy is the series color, gold is the comparison.

Controls

The console pattern — how spines and hubs are driven

A console edits rows other surfaces read. One family row carries label, tier, cockpit, hats, org and owner lane; the hub computes its index from the registries; the guard writes staleness back onto the row. Nothing stores what it can compute, so an edit here IS the edit everywhere.

Live consoles: Site Control (scores · consolidation · switchboard · crons · instruments · lessons) · Navigation Management · Palette & Tokens · Users & Hats.

States — loading, empty, broken

The rule this week kept proving: an empty surface and a broken read must never look alike. Loading is the brand wait state; empty says empty in words; broken announces itself with role="alert" and says what to do.

Menus, dropdowns, tooltips & the hamburger

Everything that opens must announce how it closes. Openers show state (aria-expanded), close on Escape and on any click outside, and never trap focus.

Search results, property cards & maps

The two shells — and the gate between them

PURE is two shells reading one set of rows. The pure shell serves people doing the work; the admin shell governs the rows those surfaces read. A page belongs to exactly one shell (mcp_page_shell decides from the registry), and the SAME family row drives both sides.

Identity — hats, users, organizations

Who you are is worn, not assumed. The top bar carries exactly two identity controls — the hat switcher and the account capsule — and Mike's screenshot of them is the standard rendered below. Wearing a hat re-renders the rail from the nav registry; it never grants anything.

Mobile, touch & haptics

Sign-in — desktop, mobile & the turnstile

The live gate is /sign-in — it IS the specimen. Desktop: two full-height columns, brand pane left (navy gradient, gold rule, trust rows), credential pane right; fills the viewport edge to edge with NO page scroll — content compresses by viewport height and sheds brand copy first, the credential form never. Mobile: one column, brand pane collapses to a compact band.

Sign-in, the turnstile & the gate

One door, three widths, four proofs. The live page is the specimen: /sign-in — fills the viewport with NO page scroll (content compresses, sheds by height: trust copy → trust rows → MFA panel → headline; the credential form is never shed), collapses to one column under 880px with the brand pane as a compact band.

Email & comms

Email is Arial, table-layout, 600px column — the one place Open Sans does not go. Sender: PURE <noreply@acquisto.biz>; marketing honors suppression + {{unsubscribe}}. Templates are pre-generated and versioned rows — a send references a template id, never inline-invented HTML.

The site dictionary — one meaning, everywhere

A dictionary DEFINES a word. A constraint ENFORCES a value. A term is not governed until it has both. This is the rule whose absence produced every vocabulary problem on this site, and the proof sits inside our own schema: pure_pages.protection, .shell, .status and .strictness carry CHECK constraints and hold four or five clean values each, because the database refuses anything else. pure_spine_pages.role carried none and grew to 55. Same project, same week. One column was defended and the other was not.

So: any column whose values are a vocabulary is constrained, and the constraint is generated FROM the dictionary — never hand-typed beside it. Add a term and the constraint widens; retire one and the gate names every row still using it. One source of truth, and no way to write around it. A glossary can tell a person what atlas means; only a constraint can stop four people typing atlas, reference, registry and docs into one column over four months.

The real-estate terms come first — RESO and MLS field names, deal stage, closing, mortgage, tax. A wrong word there does not just read badly; it reaches a contract or a feed.

The five governed columns, and the gate that proves it

The rule above is only true if something checks it, so something does. A dictionary DEFINES a word. A constraint ENFORCES a value. A term is not governed until it has both. tools/governed-vocab-gate.mjs reads the LIVE constraint through pg_get_constraintdef — never a copy, because a gate reading a copy of the rule cannot detect the rule changing — and fails in both directions: a value the constraint allows that nobody defined, and a definition pointing at a value the constraint no longer allows.

All five were constrained on 8/22, and the gate immediately found that protection_category had five allowed values and zero definitions — a rule with no meaning behind it, which is the exact half-governance the sentence above warns about. Defined the same hour. That is what the gate is for: the failure it caught first was ours.

Terms live in pure_dictionary rows (term, plain definition, field bindings, hat visibility). Everything else READS them:

Onboarding — person → hat → workspace

PII & per-field control

PII is gated at the FIELD, not the page. A field row carries its sensitivity class and the hats that may read or write it; functions enforce it; the UI renders what survives.

The management console — everything established, one roof

The admin shell is the management console. Everything standardized this month is already a row-driven surface inside it — adopting this suite adopts THEM:

The back office — one management console, integrated

Everything established this month is already console-driven; the conversion carries it over INTACT rather than rebuilding it. One rule: every governed thing has exactly one console, and every console is reachable from /pure-home under its owner's hat.

The back end — one management console set

Everything above is DRIVEN from the admin shell — each standard has exactly one console, and every console edits rows the surfaces read:

Wayfinding — hamburger, pins, tooltips, mobile

Everything that opens, closes, points or explains. Try them — the specimens work.

Search, maps & property pages

Field CMS — add and edit database fields from the admin shell

The full content-management loop: a staff admin can ADD a field, EDIT its rules, WIRE it to surfaces and RETIRE it — without a deploy, because every step is a row.

Devices, permissions & profiles

Brand assets — editable from the admin shell

Ingest & vision — every upload read, versioned, filed

Comms suite — tickets, projects, notes, messages, one spine

Comms is ONE family (Mike''s 8/19 ruling): messages, tickets, projects, notes and email are views over the same spine, so a thing never has to be retyped to change kind.

Calendars — subscribe to many, see one

Crons, self-heal & site health

Navigation, spines, act-as & the org hierarchy

Wireframe — everything above, composed

One governed page assembled ONLY from the standards on this page — the proof the suite is complete enough to build from.

The spine standard — every page lives in one

A spine is a family: its tables, its functions, the ONE cockpit that governs it, the hats that may reach it, and the standards it is held to. Everything below is the rule; the live reading of the rule is at the bottom of this section, so the standard and its score never drift apart.

1. Every page is in exactly one spine

Not most pages. Every page. A page with no spine row is not "out" — it is invisible, and an absent row cannot be queued, assigned or counted. Two spines exist so that no page can fall outside:

Both spines exist as of 8/22, and the sweep is done. Of 841 registry pages: 194 sit in a real family, 434 wait in unclassified, and the rest are parked. Zero belong to nothing — and tools/spine-homeless-gate.mjs was baselined at that zero the same hour, because the one moment a ratchet is cheap to set is the moment the count reaches nothing.

The waiting room was not one queue but three, which the sweep recorded per page: 345 never examined by any spine, 73 examined and recorded out of every family that looked (out of a family means “not part of that family” — it never meant “belongs nowhere”), and 16 disabled with no park record at all, which is two open questions rather than one: where does it belong, and why is it off?

2. Seven role names, and no eighth

A role says what a page DOES inside its family. The list is closed. It is closed because it was not: 176 governed pages once carried 55 different role names, 23 of them used exactly once, with tool beside tools and signature beside signing. Nobody was careless — the column was free text, so it grew.

hub is not a role. A dozen pages are named -hub, which is exactly the confusion a closed list prevents.

3. The gate is declared, and so is the shell

Every spine row carries gate + gate_why and shell + shell_why — declared with a reason, never derived from a name. A role name cannot tell you what a surface is: the STORE cockpit writes the catalogue and is admin-only; the DEAL cockpit is where an agent works all day. Both are role=cockpit.

The shell test. A page belongs to the ADMIN shell if and only if a non-staff user seeing it would be a security incident. Everything else is the pure shell. No third category, and no page in both — a page that is genuinely both is two pages.

4. Placement belongs to nav; the registry belongs to pages

Shell and menu are one subject at two zoom levels: the shell decides which menus a page can appear in at all, the menu row decides where inside. So Navigation Management owns placement — moving a page between shells and between menus — and Site Control owns the registry, which is what a page IS. Both call the same functions; a second door is never a second implementation.

5. The creation door — new things are born here, by a person

This is the rule that stops the others from being needed again. A new page, function, spine or vocabulary term is created from the admin shell, by a human, through the cockpit that governs it. Everything after that — filling it in, wiring it, styling it — is ordinary work anyone may do.

It is the cockpit-writer law applied to the one act it never covered. A cockpit must perform or launch every governing act, and creating is the most consequential governing act there is, because every later problem inherits from it. Six listing writers exist because six people each created one. The cheapest moment to stop a duplicate is before it exists.

Built 8/22 — mcp_page_create(), at Navigation Management › Create a page. One call takes the registry row, the spine row, the role, the gate and its reason, and the shell and its reason, and hands back a stub whose head is already correct. It refuses a path that already exists, a path that is not URL-safe, a placeholder title, a family that does not exist, a role outside the seven, a second cockpit for a spine, a gate or shell with no reason — and shell=auto, because auto is a derivation and this is the moment the decision is made.

What it honestly cannot do: PURE is a static site deployed from git, so no database function can write a file into the repo. The door owns identity and governance — the half that actually rots — and makes the file trivial. Saying it “creates the page” would be the kind of half-true this suite exists to catch.

Its companion finding, from the spine index built beside it: of 631 spine members, seven declare shell=pure. 55 declare admin, four none, and 560 declare nothing. Twelve of the fifteen real families have no declared pure-shell surface. They are not unreachable — auto derives a shell from which menu a page is in and falls back to pure — so the separation is real in behaviour and almost entirely undeclared in the registry. Every page born through the door declares its shell at birth, which is how that number starts moving.

The door must be faster than the workaround, or it will be walked around. Creating a page from the cockpit has to do more for you than writing a file does — pre-fill the spine, the role, the shell, the protection, the boot scripts and the registry row in one action. A rule that costs more than the behaviour it replaces is a rule people route around, and then the drift returns wearing a compliant name.

Worth stating plainly: this constrains Claude more than anyone, as the highest-volume creator on the system. That is the point. The fastest-moving actor is where a naming mistake compounds quickest, and a stub whose identity a person already settled is a better brief than a blank page.

6. Every guard names what it guards

A healer with no declared subject is not a guard — it is a job that runs. The chain is spine → standard → gate → cron → ticket, and each link names the next, so a failure can say which family is unguarded rather than only which job failed. An instrument that cannot state its own population must report UNKNOWN, never a clean run.

Wired 8/22. When this rule was written, 417 active crons ran and not one of them named a spine or a standard — so a cron failing told you a job had failed and nothing else, never which family had just lost its cover. pure_cron_meta now carries the subject, on the table that already had a row per job rather than a new one.

Two ratchets, moving opposite ways on purpose. The 280 unknowns may only shrink. But a spine with no active healer must stay at zero — that is not a slow backlog, it is cover disappearing, and it is silent by construction. Exactly one spine had none: unclassified, the only spine whose health is measured by shrinking, which could have refilled in silence. It has one now, and it alerts on growth rather than depth — 434 waiting is the known starting position, and a guard that mails every morning trains everyone to skip its mail, and then reports the one real break to nobody.

Spine progress — live from the consolidation registry

This is not a specimen: it reads mcp_spine_progress() — the same pure_spine_pages registry the family passes write — every time you open it. Numbers here are never typed into markup (the eight-for-eight regex lesson). IN counts pages folded into a family surface; OUT counts pages retired or parked through the Boneyard flow; a family''s cockpit is the surface that must perform or launch every governing act (design.cockpit_writer_ruling).

Conversion findings — the defect log Code fixes from

Every off-standard page found during the offender sweeps is logged as a ROW in pure_conversion_findings (finding + prescribed fix + class), not as chat. This list is that registry, live via mcp_conversion_findings() — when Code fixes one during the conversion, the row flips to fixed with the commit as receipt, and this page shows it with no edit. Classes matter: a transient, client-token or public page failing a shell check is a SCORER gap, not a page defect.

The spine atlas — every spine, every page, editable

The tab before this one states the rule and scores it. This one is the register: all 15 spines, every page inside each, the role it holds, the gate and shell declared for it, and every page that is declared in two spines at once. It reads mcp_spine_atlas() live, so it is the rows themselves — not a copy of them.

It edits, too. Every row has an editor, because a register nobody can correct becomes wrong and stays wrong. Saving calls mcp_spine_page_set(), which is staff-gated, refuses a role outside the seven, refuses a second cockpit in a spine, and refuses a family that does not exist. There is no delete. Removing a page from a spine means setting its verdict to out with a reason — the row, the role it used to hold and the reason all survive. A spine that forgets it once examined a page will examine it again and reach a different answer.

Debug overlay — URL-flag diagnostics from the user’s own session

Adopted 8/23/26 from the dead-account-pill case. When a user reports “X doesn’t work” in their signed-in browser, outside probes can’t see their session — test frames get redirected to sign-in, screenshots show symptoms, and guessing burns deploy cycles. The fix: instrument the live page itself, gated behind a URL flag, and let the user’s browser report the facts. Full spec: DEBUG-OVERLAY-STANDARD.md (repo root).

Conversion findings — the defect log Code fixes during the conversion

Live from mcp_conversion_findings() over pure_conversion_findings — every page triaged against this suite files what is actually wrong (and what turned out to be a scorer gap instead), so fixes happen systematically inside the spine conversion rather than as one-off sweeps. OPEN rows are Code’s conversion queue; FIXED rows keep their commit ref as the receipt. Anything found off-brand goes in this table, not in a chat message.