/ admin / next
The design, and the swap
The design this store now uses, and how it got here. Four rounds, what was taken from each, and what the swap moved.
The design direction 01 / ABP first, built here across three rounds at /next/ and, from v0.3.16, the store. The design it replaced is kept at the previous design — nine pages, noindex, each saying above the fold that it is not the live one.
At least one level carries a payment link, so the checkout renders one button per line of the order and each hands the buyer to the provider carrying the order reference. Nothing comes back: there is no server here to receive a webhook, so this site can say a line was sent and never that it was paid.
What moved, and what did not
Nine pages existed in both designs, so the new one took the address and the old one was archived one directory down: the front page, the picker, the comparison, the audiences, the ledger, the order, the checkout, the page after paying and the reviewer register. Their links to each other are rewritten to stay inside the archive; their links to pages that never moved go where they always went, because those pages still exist and are still right.
Every other page kept its address and was re-drawn in this chrome. There was no second version of them to choose between. They load site.css and then next.css: the chrome and the base type come from the new file, and the block components — the tables, the tiles, the specification rows — keep the rules that already draw them. Fourteen rules in the old stylesheet were scoped to the old chrome’s own element and are replaced by the reading column in the new one; the other four hundred and sixty-seven are not scoped to anything and were untouched.
That layering is a transitional state and is on the board. The argument against it still holds where it applied — a new page with no old blocks in it should not carry 26KB of a design it is replacing, and those pages still do not. These pages are made almost entirely of those blocks, and porting them is real work with no reader-visible result on the day it lands.
The console and the release archive were not part of the round. /admin/ has its own interface for a different reader and /versions/ is a record rather than a shop.
Every address the round used still resolves. The ten /next/ pages are still there, each one saying where its page went, carrying the canonical link to it and refreshing there.
The printed cards still work
A code is never typed — there is no field on this domain — so it arrives in the address off a printed card or a QR, and the cards in circulation point at the front page. That page is the new design now and the old engine is not on it, so the capture, the expiry and the per-level arithmetic were ported into assets/next.js, which shares the storage key and the record shape with assets/shop.js. Both hash a code with the same sha256 and a build check holds the two copies identical: a card that works on half a site is worse than one that works on none of it. A code landing on a page drawn by the old engine is handed to the order page rather than dropped, and every page carries somewhere to say a code was applied or refused — a code that changes nothing and says nothing reads exactly like a code that worked.
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.
| Code | Name | Price | Arrives | State | Till |
|---|---|---|---|---|---|
ABP-T1 | ABP Pack The material, downloaded. | £10 | Immediately from your payment | exists and runs | a link is issued |
ABP-T2 | ABP Vault The material, in a working vault. | £50 | 1 to 2 days from your payment | exists and runs | no link yet |
ABP-T3 | ABP Tailored Your deployment, reflected in the mandate. | £500 | 1 to 3 days from your reply | delivered by a person | no link yet |
ABP-T4 | ABP Reviewed Two sessions and a custom vault. | £1,500 | 1 to 5 days from your reply | delivered by a person | no link yet |
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.
| File | Bytes | sha256 |
|---|---|---|
index.htmlthe chosen direction: 01 / ABP first | 13,345 | 4bd678b4ef62606f |
style.cssthe base stylesheet | 26,364 | 191df5956c53ab5a |
marketplace.cssthe marketplace layer | 6,113 | 98f9a10227445d72 |
data.jsthe four levels and the vault file list, as data | 4,432 | 2ef5c502ffc12589 |
app.jslevel selection, edition switching, file explorer | 6,097 | 3918ffd17d8b2582 |
products.htmlthe product page, with the level switcher | 10,211 | 36b835144cb8e2bb |
assets/marketplace.pngABP Pack artwork | 2,072,654 | c25c561c43abd098 |
assets/vault-marketplace.pngABP Vault artwork | 2,027,739 | 677509ba1f9ec793 |
assets/toolkit-marketplace.pngABP Tailored artwork | 1,869,647 | 6a5438806a34c308 |
assets/reviewed-marketplace.pngABP Reviewed artwork | 1,892,015 | 4a91f746d9bd03d3 |
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.
| File | Size | Weight | From |
|---|---|---|---|
pack.jpgABP Pack | 1536×1024 → 720×480 | 2,024KB → 39KB | c25c561c43ab |
vault.jpgABP Vault | 1536×1024 → 720×480 | 1,980KB → 28KB | 677509ba1f9e |
tailored.jpgABP Tailored | 1536×1024 → 720×480 | 1,825KB → 33KB | 6a5438806a34 |
reviewed.jpgABP Reviewed | 1536×1024 → 720×480 | 1,847KB → 25KB | 4a91f746d9bd |
audiences.jpgThe five audiences, illustrated | 2172×724 → 1400×467 | 1,280KB → 42KB | ca5e641c86a1 |
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.
The store that sells today keeps an order in the browser under one key. /next/ reads and writes that record — same key, same schema, same line shape, same reference alphabet, same SKUs — so an order started in this design round is still there on the current store, and back. Two carts under two keys would be a bug that only appears for the one person who uses both, which is the worst kind. A check compares the two models field by field on every build.
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.
The parity pass against v4
On 16 September the project lead put the live store beside the v4 site and found bits missing, the buy references first. The site is byte-for-byte the pack mirrored here, so the gap was not a newer version: it was what the first implementation left out of the pack. Every v4 screen was then diffed against its page here.
Taken. Buy this level on every offer card, everywhere, as v4 has it: a link to the product page carrying a level and a policy, where Add to your order adds the line. The product page sells a policy at a level, names the default shape as a default beside a link to change it, and carries the level switcher in its own aside. The comparison leads with the four cards and a print action. The five doors are drawn in this design at /are/, with the reader’s question as the headline and the cards under it, and the lens on who this is for shows them too. Describe your agent exists in the store rather than only in the lab, on the lab’s own engine. The ledger explains its ten states. The page after paying prints. The picker panel names the two files you hand the agent and opens the example vault on the shape’s own page.
Deliberately not taken. The preview controls on v4’s cart and checkout (load example order, show 100% code applied) are design states, not store controls. v4’s checkout button reads as live and says preview in a callout underneath; this one is a disabled control that carries its reason on any level that has no link yet, because a button that looks live and does nothing is the one thing a store must never ship. The panel’s scenario selector and side-effect ladder are placeholders in the pack itself and stay out until the data exists. The post-purchase vault frame with a file list is a drawing of a vault; the page after paying links to the real one embedded on each level’s landing page instead. The design-handoff explorer on v4’s front page is for reviewing a handback, not for buying. And the product names are the ones ruled on 16 September, not v4’s.
Found on the way. Five “the same X on the store that sells today” links were pointing at themselves since the swap; they point at the archive now.
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 store → · the picker · the product page · the comparison · the ledger · how the direction was chosen · the brief that produced it