Patterns

The level above the component

A pattern is a composition that already stands on three or more screens. It owns no colour and writes no rule of its own: it is the arrangement of components that were already there, taken out of the files where it was hiding and given a name. Four of them, and each one was found by counting rather than by recognising.

The counter runs on wireframes/, where the whole product stands in grey. Colour holds 52 pages of 62 until stage 12, so three occurrences there would be a statement about the sample wearing the name of a rule. Every card below carries two numbers for that reason, and the second one grows.

When to take a pattern, and when to take the components

Take the pattern

You are filling the same zone with the same job. A new queue state, a new case state, a fourth handover screen: the composition is not a choice you are making, it is the one this zone already has.

Concretely: node 3.4 queue with nothing waiting is queue-list with an empty where the rows go. It is not a new column. Everything about the scope bar, the readout and the keyboard strip is already decided, and deciding it again would produce a fifth answer to a question with four.

Take the components

The composition is not repeating, or it repeats in a different order. The entry screen puts a frame in the list column and the system states put an outage there; each is one wrapper with one job, and a wrapper with one job is a component, not a pattern.

The test is mechanical. Can you name three screens where this exact set of zones already stands, in this order? Two is not enough: two occurrences prove the composition is possible, three prove it is settled. A composition on two screens stays markup and waits, and it is on the list at the bottom of this page rather than forgotten.

A new stylesheet is never the answer. If the composition you need wants a declaration none of the parts has, that is not a pattern asking to be born, it is a component or a variant missing: build the component first, by the five things on Architecture, and then compose it.

What made these four, and only these four

Every composition in this product that cleared three screens turned out to be the same shape, and naming the shape is what stopped this folder from filling with files nobody would open.

A pattern here is a filling. One container component, filled with a set of zones, where the container's other filling drops zones and grows different ones. Stage 08 ruled that a zone which disappears means a different thing rather than a variant of the same thing; applied one level up, that rule produces exactly four compositions in this product. The split has two zones, each zone has two fillings, and that is the whole level.

The two hosts have three other fillings between them and none is a pattern: frame on the five entry screens, outage on the three system states, and door on the five sign in states, which fills the shell rather than either half of the split. A filling with one wrapper is a component, and the wrapper is its name.

The four

Queue list

The main dashboard of the product. Scope at the top, a counted claim under it, an optional banner, the rows, and the keyboard taught at the foot. CLAUDE.md settles that the dashboard is the queue with the fleet in the pane and not the other way round, and this is that sentence as a composition.

z4 › scopebar · readout · banner · rows · qfoot

38grey screens
29of them in colour
2variants: the log, and one client

Case pane

Where the analyst rules. The pane's head names the case, the body carries what Clerk filed and what it stands on, and the foot holds the four verdicts. It is the surface the whole product exists for, and it is a pattern rather than a variant because the pane's other filling shares nothing with it past the head.

z5 › pane-head · pane-body · pane-foot

38grey screens
29of them in colour
2routes, paired and standalone

Fleet

The resting state of the pane, and the only surviving differentiator. Every client's current latitude and accuracy trend, legible at one glance where the analyst works rather than on a configuration page. It has no menu item and no route on purpose: checking it should not be a trip.

z5 › pane-head · frow · fleet-more

10grey screens
10of them in colour
1rule in its file, and that is the finding

Shift brief

Picking up and handing off a shift, the second of the three jobs in the MVP core. The same column as the queue, filled with the handover instead of the waiting: a counted claim about the shift, then what waits, what moved and who is on. It keeps the keyboard strip, because the analyst reads it the way she reads the queue.

z4 › readout · banner · brief · qfoot

7grey screens
7of them in colour
0reference for its page type anywhere

None of the four is waiting on stage 12. Every one of them already stands on coloured screens, so every one was proved by measurement rather than by argument: 102 renderings of 51 screens at 1440 and 360, before the extraction and after it, with zero elements moved. A pattern with three grey occurrences and no coloured one would be legitimate and would be named here as such; there is none.

What a pattern may not do

Three prohibitions, and they are the difference between a level and a second folder of components.

A pattern page is not a component page, and it is one block short

A component page carries five blocks: anatomy, variants and sizes, when to use it, rule and anti-rule, and states. A pattern page carries five too and the fifth is different: where it stands, three or more screens by name, which is the proof that the pattern exists at all.

There is no states block on any of the four, and there should not be. A pattern arranges components and every component in it carries its own states, in both themes, on its own page. A states block here would either repeat them, which is a second copy, or invent a state for the composition, which is the same thing as a pattern with its own paint. Said out loud rather than left as a page that looks like it is missing something, and the same sentence is in the contribution rules on Architecture.

Candidates, waiting for a third screen

Compositions the counter found on two screens. None of them is a pattern today. They are here so the next round finds a list rather than starting the count again.

CompositionGrey screensWhat it would need
doc › block · prov · block · prov · block · anote2A third framed record. The entry screens carry five renderings of frame and only two of them fill the document this way
block › claim · expand · claim · anote2A third evidence block that closes on an argument note rather than on a ground note. Nineteen close on a ground note, which is the settled form
pane-body › block · prov · stamp2Nothing, probably. It is the evidence stack with one block instead of two, which makes it a count rather than a composition
z45 › z4 · z5 · z62A third screen that draws the notice layer. There are two, and the cap the layer was measured against is one notice at 360
act › btn · why2A third action that carries its reason underneath it. sa-offer does the same thing on three more screens under a different host, and whether those are one composition is the question this row is waiting on
body › banner · block2A third screen where the banner sits above the blocks with no column around either. brief does it on five, inside a column

The counter that produced this table is design/kit/checks/compose.mjs. It reads the DOM rather than the markup, which is why it sees the compositions written by a script: the whole global navigation and both shell zones live in no html file at all. 104 distinct compositions across the 62 grey pages. 68 of them stand on two screens or more and 54 on three or more, three of the 54 being the wireframe stand's own panel rather than the product. Almost all of the rest are a component's own anatomy: claim is a text and a source on 24 screens, and that is what claim IS. What the four patterns are is the residue, the compositions with no single owning class, and the six above are the two screen candidates a person would recognise.