/ admin / next

/next/ is the v3 design direction 01 / ABP first, built here. It runs beside the store that sells today rather than replacing it: the current store keeps working while this one is finished, and they swap over when the buying flow is wired end to end.

One section of the design is not built

The v3 pages carry a mission line under the heading why RiskMandate exists that uses a word this site bars absolutely, on every page, with no allowlist and no carve-out for a quotation. The rule argues its own absoluteness: a positioning phrase is a claim, but a priced checkout is an OFFER, and every page here carries a price.

Their own notes page records that the project lead asked for that line. So this is a real collision between two things somebody is right about, and it is not the builder’s to settle. The section is left out of /next/, the mirror keeps their file intact because it is their page, and the ruling is on the board. Shipping it would fail the release; dropping it without saying so would be worse than either.

The reasoning behind the rule, without printing the word, is at what we do not say, and why.

The names, ruled on 16 September

Pack, Vault, Tailored, Reviewed — a short name at heading size with the precise line underneath, which is the shape the design brief proposed and the project lead ruled on. They live in data/offers.yml beside the price and are frozen by the same check.

How it is built

Every price, name, delivery estimate, claim and audience on these pages is read out of the files the current store is already built from. There is no second copy of a number to drift, and the checks that freeze the live store’s prices freeze these. The pages are generated by next_pages() in build.py.

They load /assets/next.css and /assets/next.js and nothing else — not site.css, not shop.js. The v3 source layers its palette on top of this site’s own stylesheet, which is right for a mockup and wrong to ship: it carries 26KB of a design we are leaving, and every new rule then fights an old one it did not know about. The cost is that a few components exist twice for now, in two visual languages; they converge when /next/ takes over.

One deliberate change from the source: the v3 files declare Arial, Helvetica, sans-serif outright, which renders as drawn on two platforms and as a substitute everywhere else. /next/ uses a stack that resolves to the same faces on macOS and Windows and degrades to a real grotesque elsewhere, so the design is unchanged where it was judged and better where it was not.

What it was built from

Taken from abp-marketplace-v3.diniscruz.chatgpt.site on 2026-09-16, and hashed so the question did we build it faithfully has an answer nobody has to remember. python3 tools/promote_v3.py --check re-fetches and reports drift.

The two unchosen directions (vault-first, use-first) and the model's own lab and notes pages. The choice is made; mirroring the alternatives would imply it is not.

The artwork

Four product renders arrived as 1.9–2.1MB PNGs — 7.9MB for the set. They are photographic product art with soft gradients, which is the worst case for a lossless encoding and the best case for JPEG. tools/shoot_v3.mjs re-encodes them at the size a card actually uses.

The journey, wired end to end

The v4 handback supplied the picker, the cart, the checkout and the post-purchase screens. All four are built here, from the store’s own data: which agent you run, your order, checkout, and what lands afterwards.

What it does not share is the rendering. assets/shop.js draws the current design’s markup, so the order engine in assets/next.js is a second renderer over one record rather than a second record.

Still no typing surface. Quantities are buttons, the behaviour filter is a <details>, and the picker’s search holds no field at all: the query lives on the body element and characters are read off the keyboard, so there is no input to submit and nothing to submit it to. The cost is that a phone with no hardware keyboard cannot type there, and the dialog says so and points at the chips. The handback drew an on-screen keyboard out of buttons to solve the same problem; twenty-six buttons to filter fifteen things is worse than the fifteen things.

The filter that cannot run, and the five grants that do not add up

The picker offers a filter by behaviour and it narrows nothing. The capability vocabulary is promoted here — 23 named behaviours in the form verb.object.reach — and every shape publishes how many of them its grant contains. Which behaviours those are is not published for any shape. So the menu lists all 23, choosing one says the join is missing, and the list is left unchanged rather than narrowed on a guess. The design team reached the same answer independently on the same gap.

The panel’s capability strip is one uncoloured cell per capability, and that is the second half of the same finding. The first version painted the first wanted cells green and the last unbounded ones amber, which reads as a decomposition of the grant. For five of the fifteen shapes it is not one: wanted plus not-asked overshoots the grant by exactly one, every time. Ten are exact. Off by one on five and exact on ten is a convention somewhere upstream rather than noise. The panel says so on those five, says nothing on the ten, and a check refuses it either way round.

Both are on the board as TK-14 and TK-13, for the team that publishes the catalogue.

Why the evidence state is typed out rather than derived

The picker filters on what stands behind a shape’s numbers: measured on the thing itself, or read from published sources. The obvious way to get that is to look for the word measured in each upstream summary. That marks four shapes, and one of the four is chatgpt-web, whose summary calls it “the baseline every other shape is measured against” — the shape others were measured against, not one that was measured. A regex cannot read a preposition. The join is fifteen typed lines in data/products.yml, and a check refuses a catalogue shape with no line, a line naming no catalogue shape, and a state this site has no badge for.

The four supporting pages

The v4 pack supplied five more screens and four of them are built: what arrives at every level, who this is for, the claim ledger and who does the work. Each renders from the file the current store already renders from, and a check counts what reaches the page against what is in the file: a comparison missing a row, a ledger missing a claim and an audience view that hides a level all still look right.

The ledger is here so a claim chip stops throwing the reader out of the round. Every chip on every /next/ page now lands on a row in this design rather than on the design being replaced. It is the same 52 claims from the same file — there is no second copy — and it prints which pages say each one.

The generic template is not a page, deliberately

The fifth screen in the pack is the generic template: a reading column with a claim chip beside each heading, drawn as what is inside one. That template is exercised here by the ledger and the reviewer page, which are reading columns that sell nothing. Re-rendering an existing content page at a second URL to demonstrate it would put the same paragraphs in two places on one site for the sake of a mockup, and the markdown twin, the search index and every reader who landed on the wrong one would carry that for as long as both existed. The nav’s third link therefore leaves the round, and the strip at the top of every page says the round is a round.

What is not there yet

The two add-ons attach to a level and have no page in this design. The admin console is untouched by the round: it is a different job for a different reader and its design is not this one’s to spend on.

Open the next store → · the picker · the product page · the comparison · the ledger · how the direction was chosen · the brief that produced it