Reviewing the surface against something real

You will be able to look at any screen of commission serve in the shape it will actually be in for somebody using it: three real projects first, and then the eleven edge conditions a real project happens not to be in on the day you copied it.

This page exists because of one mistake, and it is the most expensive one in the project’s history. Three passes over the human surface were designed, reviewed and signed off against a single fixture: nine tasks, none of them closed, one parent, two dependencies. That project cannot exhibit an empty state, a queue that has gone cold, a hundred proof rows, a dependency graph that needs a layout, a lapsed lease, a forced closure or an external system that is down — so none of those were ever on screen, and every defect that survived to the owner’s review was one the fixture could not contain.

The rule that follows is short: no design decision on this surface is signed off against the demo fixture alone.

The capture that decides things

A copy of a real database, served and photographed as-is:

cp ~/.commission/commission.db /tmp/shot.db
bun run scripts/shoot-dashboard.ts .screenshots/real --db /tmp/shot.db --project <slug>

Pass a copy. The rig runs no command against the database it is given and only serves it, but a browser driver crashing mid-capture should never be able to cost somebody their task graph.

--project may be repeated; each named project contributes its front door and its dependency graph to the capture. Against a real database the rig does not force an actor: commission serve resolves the viewer the way it does for the person running it, because forcing a name that does not exist in that database photographs the read-only notice instead of the page.

The three projects §43 names, and what each one is for:

The eleven conditions

Real projects cover the ordinary shapes. They do not cover the states that only occur sometimes, and those are exactly where a surface fails quietly. §43 names eleven; each is seedable with one command:

bun run scripts/fixtures.ts --list          # the eleven, with what each is for
bun run scripts/fixtures.ts expired-claim   # seed one into .fixtures/expired-claim.db
bun run scripts/fixtures.ts expired-claim --serve
bun run scripts/fixtures.ts all             # seed every one of them

Each one prints where it wrote the database and the exact command to serve it. To photograph one instead of reading it:

bun run scripts/shoot-dashboard.ts .screenshots/empty --fixture empty

That captures the pages the fixture names, at 390px and 1440px, in both themes.

What makes them trustworthy

A fixture is a claim about the shape of a database, and an unverified claim is how this mistake comes back wearing a better name — a dep-heavy project that quietly held eleven edges would make the missing review look done.

So tests/fixtures.test.ts seeds all eleven and measures each condition through the same derivations the pages read: over a hundred edges with real fan-out, a proof tally whose ratio is not 1:1, a lease that has genuinely lapsed beside one that has not, an estate queue that is empty while agents are working. The conditions themselves are parsed out of §43 of human-surface-spec.md and matched against the fixtures, so a condition renamed on either side fails the suite rather than leaving a fixture that reviews something nobody asked for.

Nothing in any fixture is drawn or asserted directly. Each is produced by driving core the way a session would — addTask, transition, addEvidence, approve — so a database that could not exist cannot be seeded. The two exceptions are stated where they happen in scripts/fixtures.ts: history is aged by shifting every timestamp backwards (core has no injectable clock, and threading one through every mutator to serve a fixture would be the fixture dictating the shape of the product), and a lease is expired by moving the claim and its expiry into the past rather than by waiting two hours for it.

What a review still owes

The fixtures make the eleven states reachable. They do not make a review happen, and they are not a substitute for the real projects — a fixture is written by whoever expected the failure, which is the one bias a real database does not have.

So: real projects first, at desktop, tablet and mobile, in both themes; then the eleven, on the pages named above; and a defect found in either is a defect, whichever capture found it.