Edit catalog product

The question this file exists to answer

The missing-items view had no home. It lived as a harness state inside catalog-product-create.html with no route to it from the product, and it was carrying two jobs that do not resemble each other. One surface is built here and moved between three placements — a tab, its own screen, a drawer — from the harness bar. It is moved, never copied, so no placement can look better for having been rebuilt and none of them can drift.

The split: a shopping list and two machines

The old panel was seven rows that looked alike and behaved in two ways. Waiting on someone are facts we must be given — an image, a weight, a barcode. Each is simply there or not; nothing is running. System records are two automatic jobs that check before they create, stop only when there is a real decision, and leave proof. Those have a lifecycle — checked · you decided · created · proved — that a table cell cannot hold, and the second is downstream of the first, which a flat row list cannot say either. So they are cards with the four beats drawn on them, and the beats are what makes the difference visible: QuickBooks reads created — not needed, adopted, ShipStation reads creating — failed 09:14.

ShipStation appears here for the first time. It was on neither screen before, yet QUICKBOOKS-FP-SETUP.md §6a names the exact state this fixture is in — QuickBooks linked, ShipStation pending — as real and retryable. One shared row could never have shown it.

The optional band is a band, not a colour. UPC, unit cost, benefit tags and gift eligibility block nothing, so they sit under a rule that says so and stop competing for alarm with the one row that does block.

✓ and ✗ on Identity

QB FP SKU and the new ShipStation SKU sit side by side, each carrying its own mark, and both are read-only — neither is a value anyone types. The ✗ is a link straight to this surface, which is one of four ways in; the header chip, the rail chip and the empty listings block are the other three, and all four are the same act.

What “attention” is allowed to mean here

On the catalog product record, “attention” means setup and nothing else (Paul, 2026-09-02). CP-0102 used to read “3 attention” here and “Ready to list” on the create screen, because the 3 were listing-level — L-202 awaiting content approval and two more — while readiness was clear. Two counters, two meanings, one word.

The first fix was to label both and show them side by side. That was wrong. A marketplace problem is not a fact about the catalog record, and once both live here the number on this screen can never be trusted to mean one thing. So the listing-level signals are gone from this page entirely — the rail chip and the header bell both. One counter remains, 2 things missing, and it counts setup.

Listing problems get a column, not a counter (Paul, same day). The Channel listings module at the bottom gains a Needs a person column, so a listing’s outstanding work is named on the listing’s own row — L-202 is waiting on copy approval, the other three are waiting on nothing. In context, next to the account, the SKU and the state, where it can actually be acted on.

That is strictly better than the bell it replaces. A counter in the header says three and makes you go hunting; a column says which one, and what for. It also cannot be confused with readiness, because it is inside the listings module rather than beside the product’s name.

The gate bites on making new listings, not on the ones that exist

The first draft emptied this module entirely, on the reasoning that an unready product cannot have listings. That was too strong. Setup can lapse after listings are live — a ShipStation record is lost, a front image is deleted — and nothing about that retires four listings that are already on eBay. So the existing listings stand and are readable, Create listings… is disabled with the reason, and the module says which rule is doing what.

Two fixture corrections

Two, not three. The count is honest rather than made to match the old chip: a missing front image and a ShipStation record that has not been created. catalog-product-edit-v6.html’s own design notes already flagged the missing front — memopryl-.webp is a byte-identical duplicate of the ingredients side.

Placement A is given its best shot

The product module is half the container by design, with supplement facts beside it, and a readiness table does not fit in half. So while Setup is the active tab the module spans both work columns and supplement facts stands down. A strawman would decide the comparison rather than inform it.

The settled state, and what it decides

Two fixtures now, on the harness bar. Both are in the DOM and one CSS rule picks between them, with only the pieces that genuinely differ doubled — so the mid-flight and settled cases can never describe two different screens.

The checklist stays visible when it is clear. Following the precedent MR-056 already set on the create screen: it is the evidence that each thing was checked, not a badge that checking finished. A screen that empties itself on success throws away the answer to “was the weight ever verified?”.

The two system records collapse to one line each, opening on the proof. Not a judgement call — QUICKBOOKS-FP-SETUP.md §5.2 asks for exactly it: “once linked, the section collapses to a quiet line naming the item and when it was confirmed.” Built on <details>, so evidence-on-demand costs no script at all.

The four beats are the same four in both states, which is what makes them worth drawing. Settled reads created — retry 4, 09:31 and proved — read back, weight matched; the failure state reads creating — failed 09:14 under the same headings. The difference is legible before you read a word of prose.

Ready to list and a listing needing a person are independent, and the fixture proves it. In the settled state the product is listable, Create listings… is live, and L-202 is still waiting on copy approval in the module below. Two facts, two places, neither contaminating the other — which is the point of moving listing attention out of the header.

Bug the browser found and reading would not have

The fixture switch writes data-fix to <body>, so the delegated handler’s closest('[data-fix]') matched body on every click in the document and swallowed every handler after it — the placement toggle, all four ways in. Silent: no console error, the page simply stopped responding to one class of click. Now closest('button[data-fix]').

Open — needs Paul

The scope model

Version-scoping is per field, not per tab. Two marks carry it:

• shared product-level — one value for every version.
• v1 plus a heavy left rule — belongs to the version selected in the brand strip.

Colour is now spent on version identity, and this is a deliberate reversal. The rule used to be “no colour for scope, keeping colour for status only”. But a sticker that reads v1 in one hue and v2 in another can be traced back to the toggle at a glance, which a uniform black chip could not. The hues are drawn from outside the semantic set — never green, amber or red — so they cannot be mistaken for status, and the status chip stays where it was, inside the toggle button. Each version’s hue is the same on its sticker and on its button, so the pressed button and the stickers it governs read as one object.

A tab now carries two axes, not one. The old rule was “a tab is never mixed”, meaning one scope per tab. That still holds for scope — everything on Specs is version-scoped. What is new is ownership: Physical & packaging and Source formula are shown here but owned by the source formula, so they render read-only with an SF-0007 ▸ mark and are edited in the formula’s own drawer. Filling a blank from here is not allowed either — one owner, one place. Switching version flashes the Specs tab’s groups.

Benefits and gift eligibility sit on Identity because both are product-level. Benefits come from a managed list rather than free text, so the listing builder’s angle picker does not fill with near-duplicates; gift eligibility exists only because a freebie is named in marketing copy and imagery — otherwise it is just another product riding in a combo.

Layout

• Top section is the brand and the version toggle, right-aligned — a second deliberate reversal of “the brand and nothing else”. The toggle governs the whole module (both Specs and Base images are version-scoped), so the module’s own header is where it belongs, and the strip now reads as one statement of context: Memopryl · editing v1. The tab row was the alternative and lost: it already carries three tabs and their scope chips, it wraps, and a toggle dropping to its own line reads as broken.
• Supplement facts is always visible and sits beside the tab module, each taking half the container, so both stack to roughly equal height and channel listings ride higher.
• The sticky page header keeps only what acts on the whole product — save, create listings, attention.
• Field grids fill the container width; an individual field stays around 230–300px, so nothing stretches.
• Notes sits full-width directly under supplement facts, above channel listings.
• Channel listings sit full-width at the bottom, one tab per sales channel.

Notes

The same shared block that source-formula.html carries, lifted markup-and-CSS intact rather than re-drawn: a container with data-notes and an optional data-author holding [data-newnote], [data-addnote], [data-notelist] and an optional [data-ncount]. Every lookup is scoped to that container, so the two screens cannot collide and neither needs initialising.

It is marked product-level on purpose. A note is about these goods — a supplier conversation, a packaging change — and reading it should not depend on which version the toggle happens to be showing. The formula's log answers the same question one level up; this one does not repeat it.

The nav collapses to its icons

A toggle in the brand row drops the rail from 284px to 58px. Labels are hidden rather than removed, so the section order, the current-page rule and the not mocked yet stubs are all still there when it opens again — and the work column gains the width, which is what the collapse is for: the identity grid goes from two fields across to three.

While collapsed each link carries its label as a native title, set by the toggle and removed on expand. A CSS tooltip was the first attempt and it does not survive: .sb has overflow:hidden and its scroller has overflow-y:auto, which clips anything reaching past the 58px rail, and there is no honest way to have overflow visible on one axis only.

Open: the collapsed state is not remembered — no reload survives it, because this screen has no URL state to hang it on. Worth settling before this is copied to the other promoted mockups.

Supplement facts editor

Table and Markdown are two views of the same data. The markdown dialect reads Serving Size:, Servings Per Container: and Other Ingredients: as their own lines; a row prefixed with - nests under the blend above it, which is what the real MemoPryl label needs. Paste a whole panel, hit Save facts, and the table repopulates.

Open — needs Paul