Codex

The law before the page-class laws. Every one of those owns a page SHAPE and pins the kit that enforces it; this one owns the step that comes first — how a business function becomes a page class, or no page at all. It has no kit, because the thing it governs is a decision rather than a component: its enforcement is the Page-type laws table in ../AGENTS.md, which only accepts a class this derivation produces. The living example is the tasks app (/labs/apps/tasks), where one domain object wears ten expressions and every one of them is a view of the same screen.

Page form is derived, never chosen. A page is the last output of a chain that starts with the domain — what objects, relationships, events and rules actually exist — passes through the ONE task the reader came to do, names the information structure that task needs, and only then picks the expression that answers the task's question with the fewest mental conversions. Skipping to the end is how a repo ends up with a table because an API returned an array, and a detail page because the route carried an id.

The corollary is that the same object has no single page. An issue is a collection while it is being queried, a status flow while it is being processed, a thread while it is being discussed, and an event sequence while it is being audited. Those are four expressions of one object, and the question "which page is the issue page" has no answer — only "which task".

Five steps, each with one question and one output. The output of each is the only input the next one may use.

A page whose class cannot be named by walking these steps is not "special". It is either a class that already exists wearing an unfamiliar body, or a class this repo has not legislated — and the second case is handled by the growth law at the end of this document, never by building first.

A page is expensive: it takes a route, a nav entry, a heading, a place in the composition pyramid, and it promises to be there when the URL is opened tomorrow. It earns that cost on three grounds, and only these three:

• An independent address. The thing is shared, bookmarked, or returned to after an interruption — a record, a report, a board someone links to.
• Independent permission. Who may see it differs from who may see the page it would otherwise sit inside.
• An ongoing task that needs the room. A workbench canvas, a board with eight columns, a table whose columns cannot reflow — content with intrinsic width past the reading measure (<PageContainer fluid> exists for exactly this).

Everything else folds into a surface that already exists: a tab on a family page, a view of an app screen, a DetailPeek beside the list, a feature card on a dashboard, a dialog. The tasks app's ten views share ONE nav entry for this reason — none of them is a page in its own right, each is an expression of the screen.

The reader's intent is a verb, and each verb pulls a small set of information models. Naming the verb first is what stops a page from serving two of them at once — a table that is also trying to be a status board is the most common result of skipping this step.

A page has ONE primary intent. Secondary intents are served by supporting models that step 4 places — the deal page's activity timeline is a Trace model supporting an Understand page, and it lives in a feature card, not in a second heading.

The information model and the question it must answer pick the expression, and each expression maps onto a page class this repo has legislated — or onto a recorded gap. The index below is the vocabulary a request arrives in (the industry's skeleton names) translated into this repo's classes. Several skeletons collapse into one class with a different BODY: table, catalog and card grid are all the data view with a different DataViewBody. That is the kit-over-convention design paying off, and it is why the class count stays small while the skeleton count does not.

Two readings of the index are wrong. It is not a list of what this repo does and what it does not: every "not legislated" row is a shape that has not yet appeared twice, and the growth law below says what happens when it does. And it is not a menu — a request arrives with a skeleton name because that is the vocabulary people have, but the row is only confirmed once steps 0–2 land on it.

Every page has content that is not its primary model — the record beside the list, the raw log under the summary, the confirmation before the delete. The surface it lives on is decided by how the reader moves between it and the primary content, and the ladder has four rungs. The rule from detail.md generalises: the cut between rungs is width and frequency, never importance.

The failure this step exists to prevent has one shape: a Drawer over the queue the reader is triaging. It hides the very list the judgement depends on, and every close is a re-orientation. The detail law's two-surface split was legislated out of that exact rework.

The tasks app is this law's living example because it refuses the question "what does the task page look like". A task is a collection in list and table, a status flow in board, a plan in timeline and calendar, a priority field in matrix, an event sequence in activity, a set of figures in overview and workload, and a queue in my-work — ten views, one object, one nav entry, one [key] detail page they all open into.

The Support app (/labs/apps/support) proves the same rule for a conversation-led object: Inbox reads the thread, Queue assigns ownership, SLA orders obligations, Customers groups relationship history, and Analytics aggregates the same events. Replying, adding a note, assigning and resolving each append to one log; every view opens the same [key] detail. It composes the data-view, detail, timeline and dashboard kits, with StatTile, ChartContainer, ShareBar and RankBar as its analytical parts.

The Content app (/labs/apps/content) follows a revision through Library (data view), Workflow (kanban), Calendar (date-picked weekly agenda), Channels (live edition catalog) and Analytics (dashboard). All five open one [key] editor, composed from the form and detail kits. The calendar is an agenda body in DataView, selected by the existing date-input Calendar; it introduces no second calendar canvas. Approval and scheduling bind to a saved revision, while the live edition remains immutable until the next release. Its Revisions body now compares two saved snapshots; it does not introduce a second editor or a separate comparison page class.

The Observability app (/labs/apps/observability) separates measured facts from response work: Overview aggregates hourly observations, Services compares current health and ownership, Events traces alerts and deployments, Incidents advances a response, and SLOs accounts for request-based error budgets. Service expressions share services/[key]; incident expressions share incidents/[key]. It composes DataView, DetailPeek, DetailBody, FactCard, FormShell, Timeline and DashboardBoard, with StatTile, ChartContainer, RankBar and Meter. Shared environment/team scope applies everywhere; the observation window filters telemetry but never hides an active incident. Acknowledgement and resolution do not rewrite measurements. Topology reuses ServiceMapCard with that same service scope and latest health; its node opens the shared service peek and detail. Edges denote dependencies, not measured traffic or proven root cause.

Commerce (/labs/apps/commerce) separates orders, payment, fulfillment and returns while sharing CRM customers and the Inventory movement ledger. Billing (/labs/apps/billing) separates subscriptions, usage, issued invoices and collection attempts. Both compose the existing Dashboard/DataView/Detail/Form kits; Billing's customer portal is a view over the same account detail. Their route manifests name every expression; SaaS apps records each model's boundaries and the composed parts.

Three rulings follow:

• A new expression of an existing object is a view, never a new app. It joins the screen's view row and reads the same data module.
• Screens list their expressions. The composition pyramid already asks a screen to list the cards it composes; the same manifest names the expressions each of its objects wears, so the next request ("add a board to CRM") is checked against it before anything is built.
• The detail page is shared. Every expression that opens a record opens the same [key] page; an expression that grows its own detail has forked the object.

• Table because the API returns an array. A collection is a model, not an expression; catalog, grid and table are three answers to three different questions about the same array.
• Detail page because the route has an id. An id names an object; the page is chosen by what the reader does with it. A record that is only ever triaged wants a peek, not a page.
• Page because it is important. Step 0 admits pages on address, permission, and room — never on how much the stakeholder cares.
• Two primary intents on one page. A table that is also a status board, a form that is also a report. Serve one; place the other with step 4.
• The skeleton name as the decision. "Build a kanban" is a request in a vocabulary, not a classification. Walk the steps; it is usually a kanban.
• A private detail per expression. The board's card opens one thing, the list's row another — the object has been forked and the two will drift.
• Legislating a class from the index. A "not legislated" row is not a to-do list. A law written before its second instance is a guess about a failure that has not happened.

This document adds no page classes, and it is not where new ones are added. A skeleton in the index with no class is a shape that has appeared at most once; when it appears a second time, THAT is the moment to legislate — write docs/<class>.md in the house shape (the failure, the thesis, the anatomy, the anti-patterns), extract what the two instances agree on into a kit, add the AGENTS.md row and the codex entry in the same commit, and move the index row from "not legislated" to its class. The new-page skill walks the same procedure, and its first step is this document.