What works

"The central design bet pays off, and I verified it against the real pixels rather than the description. I reconstructed the desktop look-strip at true size (70x56 thumbs, cover-cropped to the middle 70% of each 820x458 render, since object-position:50% 0% only affects the axis that is actually cropped): the seven looks are plainly different at that size — yellow comic, navy wireframe, thermal spectrum, white hub-and-spoke, ink-wash on paper, brass steampunk, green PCB. \"Several looks inside\" is legible without a count, and no count is stated anywhere. The four picture states really are distinguishable across the room and use four different CSS mechanisms, not four captions: a plain filled render (R1), a render plus a strip/dots (R3), a dashed hatched hole on a repeating-linear-gradient (R2), and a filled accent-gradient panel with a tag and two lines of prose (R4). System compliance is the cleanest part: I split every selector in the style block on commas and zero fail the `.s-discover` prefix; no :root, no bare element selector, no body, no @import, no external resource, no restyling of the four host classes; every colour that must flip comes from a token, with hard #fff used only on top of --accent; exactly eight image tokens, all in recipes.md, with the two decoys in assets.json (IMG_PIE, IMG_WINTER) correctly untouched. All four titles and all four requirement lines are verbatim. The browsing surface is disciplined — no author, id, date, platform name, style name, technique, or count survives anywhere a user can see, and the seven looks are identified by picture and alt text alone, exactly as the brief demanded. Every control works and the filters compose correctly; \"Only with an example\" survives an outcome-chip change, and the picked look survives search, filtering, and Clear. The Save label swap works too — the button's lastChild is genuinely a text node (\"Save\\n...\") after the inline SVG, so the nodeType===3 guard holds."

Phone

"A real adaptation, not a squeezed desktop — and the CSS proves it rather than merely reflowing. Four structural changes, not just sizes: the search field moves out of a tools row and into the header (`.d-phone .d-searchwrap{flex:1 1 auto}`); the desktop's wrapping chip row becomes a bottom bar (`.d-desk .d-facetrow{flex-wrap:wrap}` vs `.d-phone .d-facetrow{flex-wrap:nowrap;overflow-x:auto}`); the seven-thumb `.d-strip` is replaced by a different component, `.d-dots`, with aria-labels instead of images; and the action row is re-laid-out as `display:grid;grid-template-columns:1fr auto` with `.d-use{width:100%;padding:15px 18px}` so the primary action is full-width and 51px tall. Density is genuinely retuned (h1 38px to 25px, body padding 16/18 to 15/16, gap panels swapped from aspect-ratio to min-height:172px) and the hero and R2 gap copy are shortened for the frame rather than reused. No sideways scroll at frame level: the single overflow-x:auto is the chip row in its own container, which is what hard requirement 6 asks for, and I checked the widest fixed row — seven dots at 28px plus six 6px gaps is 232px inside 390. Three real defects, all listed above: the \"Only with an example\" toggle sits roughly 370px past the right edge of a scrollbar-less strip; both sticky bars are inert because the harness viewport is overflow:hidden with auto height, so the bottom bar is about 1,800px down a non-scrolling column rather than under a thumb; and the phone loses the current-page indicator, leaving a 13px top-right text link as its only navigation."

Problems

• blockingThe alt text contradicts the asset it describes. I base64-decoded {{IMG_BOAT}} from assets.json: the anchor's sign reads "UNPLANNED CHANGES" and the hull reads "PROJECT". The alt asserts "a large anchor labelled 'new features'". The phrase comes from the prompt (recipes.md line 19), not from the picture. Fix by describing what is actually in the frame. — screen_discover.html lines 320 and 443 — R1 alt attribute, both frames
• blocking"The recipe works." is an invented test result on the one card whose entire purpose is to admit we have nothing to show. recipes.md says only that no render has been produced. Deleting three words fixes it, and the rest of the panel ("We have not produced a picture for it, so there is nothing honest to show here yet.") is exactly right without them. — lines 337 (desktop) and 466 (phone) — R2 no-example panel
• blocking"...that other people published and we tested" claims testing the pack does not support and partly contradicts: R1's render is "cropped from a table screenshot in the post", R3's seven carry a NotebookLM watermark, R2 has none and R4 can have none. The phone hero (line 400) drops the clause entirely — so the honest version already exists in the file. — line 250 — desktop hero subtitle
• majorThe crop destroys the only single-example card. {{IMG_BOAT}} is 640x633 (AR 1.011) going into a 1.6 box with cover and top anchoring, so the visible vertical fraction is 1.011/1.6 = 0.632 — the bottom 234 of 633 pixels are cut. I rendered the crop: the anchor and its sign are entirely gone; what remains is a boat on a pretty river with a bit of chain at the edge. The metaphor, which is the whole outcome, is not on the card. The 820x458 style renders (AR 1.79) survive this fine, losing 10.6% off the bottom. Give R1 a taller stage or object-fit:contain. — .s-discover .d-stage{aspect-ratio:16/10} + .d-shot{object-fit:cover;object-position:50% 0%}, line 82-83, applied to R1 in both frames
• invented"The recipe works." — on the R2 card in BOTH frames (line 337 desktop, line 466 phone). recipes.md says only "Example image: NONE. We have not produced one yet." Nothing in the pack says R2 was ever run or that it works. This is an invented test result, banned by hard requirement 3 ("Invent no ... test results").
• invented"Real prompts that other people published and we tested." — desktop hero (line 250). "other people published" is supported (four source URLs). "we tested" is not, and is contradicted for R1: recipes.md line 13 says {{IMG_BOAT}} is "cropped from a table screenshot in the post" — the poster's render, not ours. R3's seven renders carry a visible NotebookLM watermark in the source JPEGs, i.e. also a third party's. R2 has no render at all and R4 can never have one. A blanket "we tested" over a four-card catalog where zero renders are demonstrably ours is a fabricated provenance claim.

What works

"Honesty is clean, and I checked it rather than trusting the summary. Every one of the roughly 95 visible strings cross-checks against recipes.md or system.md. All four titles and all four requirement lines are verbatim. Provenance is exact on both pages: \"From r/notebooklm on Reddit, January 10, 2026\" against `reddit · r/notebooklm · 2026-01-10`, \"From MrMekzy_ on X, February 6, 2026\" against `x · MrMekzy_ · 2026-02-06`, both with the correct URLs. \"7 styles\" and the 75- and 1,043-character counts are computed from the DOM at runtime and match the source. There is no invented author, date, engagement figure, test result, or social proof anywhere — no \"12 people made this\" of any kind.\n\nThe two no-image kinds are correctly distinguished, which is the subtlest thing system.md asks for and the thing most likely to be got wrong. R2's `.rc-gap` (line 291-298) is a dashed placeholder saying \"No example yet / We haven't made one for this recipe.\" — it looks like a gap because it is one. R4's `.rc-noex` (line 301-323, markup 593-607) is a solid bordered card with bespoke SVG art, a lead (\"No example can exist here.\"), a reason, a \"shape of the answer\" section, and a warn-toned \"Illustrative, not a result\" chip. Nothing on either page presents a catalog render as the user's own result: all seven style images carry alt text of the form \"The document rendered as an infographic in the <style> style\", and both the R3 caption and the R1 strip label the render \"Original result\" using the exact system word.\n\nRule 3 is handled better than the brief required, and the reasoning behind it is right. There is no persistent hero, so there is no way for a stale picture to sit beside a changed prompt. Each of the seven tokens appears exactly once; selecting a tile widens it, sets `aria-checked`, replaces the whole prompt, re-derives the swatches and all eight Fine-detail fields from that same string, and re-runs the integrity strip. The \"Original result\" chip renames itself to the selected style on every switch (line 822-823), so the label stays truthful.\n\nRule 2 is not just satisfied but stated: the requirement sits above the actions and the copy is never gated, and line 439 adds \"You can copy the prompt now and bring the document later.\" There is no checklist anywhere.\n\nRule 4 survives an actual read of the handler, not an assumption. The style-switch listener (line 867-877) touches only the tile classes, `aria-checked`, `renderStyle`, and `note.hidden`; it does not reset `aria-pressed`, the star glyph, or the Save label, so a Save made before exploring survives switching all seven styles. There is no editable field on this screen to lose. The only thing a switch discards is the transient Save confirmation message, which is acceptable.\n\nRule 5 is met on both simple recipes: R1's strip and R4's phone page each carry Make my version, R4 with \"Reword it before you run it. The original stays here.\"\n\nHard requirements audit, done by parsing the stylesheet rather than eyeballing: every one of the selectors starts with `.s-recipe`; there is no `:root`, no bare element selector, no `body`, no `@import`, no `url()`, no http reference, and — notably — not one `.dv-frames`, `.dv-fr`, `figcaption` or `.dv-vp` rule, so the host frames are left alone. All eight image tokens are `src=\"{{TOKEN}}\"`, all eight exist in recipes.md, each is used exactly once, and every `<img>` has real alt text. No external script or stylesheet. Every `querySelector` goes through the try-wrapped `q`/`qa` helpers at lines 709-710 and every result is null-guarded; `btn.closest` is feature-tested. There are no `id` attributes at all, so nothing can collide with the three sibling screens on the same host page. Banned vocabulary is clean: \"schema\" appears only inside the style names \"…Schematic\", and \"artifact\" only inside the verbatim Engineering Blueprint prompt, where the cardinal rule forbids changing it.\n\nThe requested order is exactly right on both frames: title, example (or its designed absence), requirement, Use recipe + Save, prompt with persistent Copy prompt, then — well below, after `.rc-below` (line 225, 46px and a rule away) — the closed-by-default Fine detail, provenance, and the small mono technical line.\n\nWhat stops this being a 9 is not honesty and not the copy. It is the phone's primary action, whose stated behavior is the inverse of what the CSS does; a persistent button that can lose its own name; an integrity guard that cannot fail on the page it was written for; and a handful of copy and hierarchy nits including reviewer meta-text sitting in the shipped UI. All are small and local. Fix the action bar and the label timer and this is ready to build from."

Phone

"A real adaptation in structure, undermined by one wrong CSS property in its most important element.\n\nEvidence it is a genuine adaptation, not a 390px squeeze: it has its own navigation — `.rc-ptop` (line 327-334) is a compact app bar with a back chevron, an uppercase \"Recipe\" label and a single \"Mine\" link, replacing the desktop's `.rc-topbar` with its back link plus two-item `.rc-topnav` (line 68-81). It has its own density: title 27px vs 38px with `max-width: none` overriding the desktop's `20ch` (line 336), `.rc-pre` at 13.5px/15px 14px padding vs 13px/18px 20px (line 340), `.rc-below` margin 34px vs 46px (line 342), and the Fine-detail `<dl>` collapses from `168px 1fr` to `1fr` with per-item bottom margins (line 343-344). The primary action is restated as a full-bleed two-button bar with a flex:1 \"Use recipe\" (line 348-354), and Make my version becomes a full-width `.rc-pmine` block button with its own supporting line (line 355-362), rather than the desktop's right-aligned ghost button. The desktop-only material — the seven-tile rail, the swatch row, the R1/R2 strips — is simply absent rather than reflowed. That is the right kind of difference.\n\nNothing scrolls sideways. `.rc-pre` carries `white-space: pre-wrap; overflow-wrap: anywhere` (line 210); the only fixed-width grids (`.rc-fields` 168px, `.rc-strip` 208px) are overridden or unused on phone; the SVG is `width: 100%` on a 320-unit viewBox in a ~322px content box; the `.rc-pbar` negative margins (`margin: 14px -16px 0`) exactly cancel `.rc-pwrap`'s 16px padding, so the bar reaches 390px and no further. The one horizontally scrolling element, `.rc-rail`, has `overflow-x: auto` and exists only in the desktop frame.\n\nThe failure is the thumb-reach claim. `position: sticky; bottom: 0` releases as soon as you scroll down to the element, so the bar is present while you are above it and gone for the entire lower half of the page — and at a 390x844 frame the content above it measures roughly 646px, meaning its natural bottom sits inside the viewport on load and it likely never pins at all. See the major entry in problems. Everything else about the phone frame is well judged; this one property needs replacing.\n\nOne structural note, not a fault: because the brief mandates R4 on phone, the phone never has to answer the hardest small-screen question in this system — how a seven-image style rail and a three-swatch row behave at 390px. A reviewer should not read this frame as evidence that the R3 template survives the phone."

Problems

• major`position: sticky; bottom: 0` does the opposite of what the comment above it claims. The comment says the bar "starts in its correct place in the order, then stays within thumb reach as you read on". Sticky-bottom pins an element only while its natural flow position is BELOW the scrollport bottom; the shift is upward-only, and it releases to zero the moment you scroll down to it. So the bar is reachable while you are ABOVE it and disappears permanently for the rest of the page — exactly the stretch (the prompt, Copy prompt, Make my version, Fine detail, provenance) where you would want it. Worse, on a normal 390x844 frame it probably never pins at all: the content above it measures roughly 646px (app bar ~46 + title ~82 + the .rc-noex card ~454 + requirement ~64), putting its natural bottom near y=726, already inside the viewport. The designer's stated worry — whether `.dv-ph .dv-vp` is a real scroll container — is the wrong diagnosis; the geometry fails either way. Meanwhile the full-bleed styling (`margin: 14px -16px 0`, `border-top`, opaque `background: var(--rc-surface)`, `z-index: 3`) makes it LOOK like a persistent bar in a screenshot, which will mislead a reviewer. Fix: make `.rc-phone` a flex column whose scrolling middle holds the content and whose last child is the bar, or use `position: fixed` inside a `position: relative` phone shell — and add matching bottom padding so the bar does not cover the provenance line. — CSS line 348-352, .s-recipe .rc-pbar (phone R4 action bar)
• minorA double click permanently destroys the label of the button system.md requires to be persistent. `var label = btn.textContent;` is captured at click time, but the previous click's 2600ms timeout has not fired yet, so the second click captures "Copied · 1,043 characters" as the label to restore. Sequence: click at t=0 sets "Copied · 1,043 characters", click at t=1000 captures that as `label`; the t=2600 timeout writes "Copy prompt"; the t=3600 timeout writes "Copied · 1,043 characters" — and the button reads "Copied · 1,043 characters" forever. Fix: store the original label once on the element (e.g. a `data-label` attribute set at wire-up) and clear any pending timer before setting a new one. — script line 900-903, the Copy prompt button
• minorThe integrity check cannot fail for R3, so the summary's claim that it "turns red if the rendered text ever stops matching the recorded prompt" overstates what ships. `renderStyle` writes `pre.textContent = style.text` at line 820 and then calls `verify(panel, style.text)` at line 860, so `full === source` compares the string to itself. The guard is real only for R4, where line 967 `verify(r4, R4_PROMPT)` compares the hand-written markup against an independent JS constant — a check that would genuinely catch markup drift, and which I confirmed passes. The visible strip text is still accurate (it is computed from the same node the clipboard reads), so this is not a dishonest string; it is a guard that will never protect anyone on the page it was built for. Fix: hold the seven recorded strings in a frozen table and pass the table entry, not the value just written — or state plainly that the safety comes from the one-node architecture, which is the real and sufficient guarantee here. — script line 796, `verify()`, on the R3 path
• minorThe fallback message is wrong advice: `btn.textContent = ok ? (...) : 'Press Ctrl+C to copy';`. When both `navigator.clipboard.writeText` and `execCommand` fail, nothing is selected, so Ctrl+C copies whatever the user last had selected — not the prompt. The Use recipe handler gets this right two blocks later (line 934: "Select the prompt below and copy it, then paste it into ..."). Make the copy button say the same thing. — script line 902, copy failure branch
• invented"One image comes back: a caricature of you and your job — a single figure, exaggerated, built only from your own chat history. What it picks out is different for everyone who runs it." (line 604, R4 phone). system.md sanctions the KIND of copy ("a short description of the shape of the answer, clearly marked as illustrative") and it IS marked ("Illustrative, not a result", line 606) — but the certainty is not sourced. Nothing in recipes.md establishes that the output is exactly one image, or one figure. Worse, "built only from your own chat history" is narrower than the verbatim prompt, which says "based on everything you know about me" — on ChatGPT that includes saved memory and custom instructions, not only chat history. Fix: hedge the count ("You get back a picture, not text") and drop "only". This is the ONLY visible string in the file I could not ground; there are no invented counts, authors, dates, engagement figures, social proof, or test results anywhere.

What works

Payload integrity is proven, not claimed. I extracted the real `STYLES` / `assemble` / `tailFor` / `parse` code and ran it: all seven assembled prompts are byte-identical to recipes.md, each carries its own `Instruction: … visual DNA of "<name>".` line and each ends with `Reference extracted metadata for exact aesthetic and structural adherence.` The Neumorphic `Categories: … Clean Minimalist,\n\nSymmetrical` blank line survives intact, and the parser round-trips all seven styles with zero field drift and zero tail drift — the designer's own test claim holds. R1's `ORIGINAL` equals the verbatim boat prompt exactly at 254 characters, and the three choices are built so the defaults reproduce the source text character-for-character. Zero invented content: every numeral in the static markup is either a frame label ("Desktop · 1200", "Phone · 390") or a verified date ("From r/notebooklm on Reddit, 10 January 2026", "From GBFORCE7834 on Reddit, 6 September 2025"), both matching recipes.md including the URLs. No counts, no engagement figures, no fabricated saved versions — `st.versions` starts empty and reads "None yet." All 21 hex values match their styles. The seven R1 alternate chips are honestly demarcated by `.cz-chip.is-src::before{ content: "• "; }` plus the legend "• marks the wording from the original post." CSS is exemplary: I parsed all 154 selector groups and every one starts with `.s-customize`; no `:root`, no bare element selector, no `body`, no `@import`, no `@media`, no `url(`, no `http`, one `<style>`, one `<section>`, one inline `<script>`, no restyling of `.dv-frames` / `.dv-fr` / `.dv-vp`. All eight image tokens come from the recipe pack, none invented, every `<img>` has substantive alt text derived from the style's own declared palette. Rule 3 is executed better than the brief demanded: the label stays "Original result" and the tag flips to "Does not match your prompt", the ribbon rewrites to "Your 3 edits are not in this picture. This is still the catalog's render of …", the figure gains a diagonal hatch and a dashed inset outline, the "In this picture" / "In your prompt now" swatch rows diverge the moment Colors changes with the note flipping to "Different from the picture", and three separate lines of body copy say editing makes no picture. The three-way switch dialog with per-style edit storage plus "Edits kept in <style>" chips is a genuine, working answer to rule 4 in the common case, and the hand-typed lock correctly refuses to merge unparseable wording rather than dropping it. Both required actions are present everywhere with distinguishing sub-labels ("Back to the catalog's wording" vs "Keeps your edits as My version"). Every system word is used exactly, no banned word appears in authored copy — the single "artifact" hit is inside the Engineering Blueprint composition value, which is verbatim source text.

Phone

A real adaptation, not a squeezed desktop — the clearest strength of the file after the copy payload. Evidence of independent structure, not just narrower boxes: the two-column desktop grid is dissolved (`.s-customize .cz-p .cz-cols{ display: block; }`) and the ORDER is re-authored, not reflowed — desktop runs choices-left / result-right, phone runs Original result → Pick a style → Your prompt → Fine detail → My versions, so the honesty artefact leads and the disclosure sinks. The style picker changes component: a `repeat(4, minmax(0, 1fr))` grid on desktop becomes `.cz-strip-h{ display: flex; gap: 10px; overflow-x: auto; scroll-snap-type: x mandatory; }` with `flex: 0 0 118px` tiles and its own instruction ("Swipe. Seven styles, one document." vs "Seven styles, one source document. Each brings its own colours."). Navigation differs: "← Recipe" becomes "←". A thumb bar exists only on phone — `.cz-bar{ position: sticky; bottom: 0; …}` carrying Copy prompt (primary) + Save as new version, with `.cz-bar .cz-btn small{ display: none; }` stripping the desktop sub-labels, and "Save as new version" is deliberately moved OUT of the edits strip into it. Density is retuned throughout (h1 27→21px, textarea min-height 300→210px, hero max-height 330→220px, wrap padding 24→14px, palette label 128→96px, prompt font 12→11.5px), and the lede is rewritten rather than truncated ("You are editing your own copy. The recipe in the catalog stays as it is. Nothing on this screen makes a picture…" → "Editing writes your prompt. It never makes a picture."). SIDEWAYS SCROLL: none found. The only wide content is `.cz-strip-h`, which carries its own `overflow-x: auto`. Everything else is wrap-safe — `.cz-striptop`, `.cz-row`, `.cz-kept`, `.cz-chips`, `.cz-switchbtns` all set `flex-wrap: wrap`; `.cz-input` is `flex: 1 1 220px; min-width: 0`; `.cz-p .cz-stripbtns{ width: 100% }` sits inside a wrapping flex row; textareas are `width: 100%` with `resize: vertical` only. At 390 − 28 (wrap) − 32 (card) = 330px inner, `.cz-switchbtns .cz-btn{ flex: 1 1 180px }` wraps to one per row rather than overflowing. Two caveats. (1) The frame stacks two complete screens with a labelled divider band ("Second example — the same screen, a three-sentence recipe") — honest and clearly marked, but it means two `position: sticky; top: 0` headers and two sticky bottom bars share one scroll container, so mid-scroll you can briefly see the R3 bar pinned below while the R1 header pins above, reading as one hybrid screen. (2) The thumb bar's own primary path is broken: tapping "Save as new version" there focuses an input far above the viewport (see the major finding). Verdict: real adaptation, with one phone-specific interaction defect inside it.

Problems

• blockingText typed above the first `Overall Tone:` line is silently deleted AND the screen lies about it. Verified by running the extracted parser: `'Use British English.\n\n' + assemble('retro')` parses successfully, produces an empty edit set, so `dirty()` is false — the tag reads "Matches your prompt", the ribbon reads "…unedited.", the strip reads "No edits yet", and the next render with the textarea unfocused (click a tile, or type in any Fine detail field) rewrites `prompt.value = text(id)` and the typed line is gone. No lock, no warning, no Undo. Fix: have `parse()` also capture the head slice `s.slice(0, stops[0])` and either return null when it is non-empty (drop into the hand-typed lock, which already works correctly for a deleted `Lighting:` label) or store it as a leading edit. — screen_customize.html:993 parse() + :1155 render() write-back
• major"Bring my edits with me" overwrites the destination style's existing edits with no warning. `Object.keys(from).forEach(function (k) { if (k !== "__tail") to[k] = from[k]; });` has no collision check, and `st.undo = null` two lines later removes the escape hatch. The "Edits kept in <style>" chips make the round trip that triggers it a first-class navigation path. Fix: when `to` already holds a key, name the conflicting lines in the panel and offer a third option, or refuse to clobber. — screen_customize.html:1201-1206 applyStyle(id, true)
• major`t.indexOf(cur[key])` rewrites the first occurrence, which is not necessarily the right slot. Reproduced: obstacle typed as "the project", then the "scope creep" chip renames the BOAT and leaves the anchor labelled 'the project'. Any short or repeated custom value does this — a custom project of "a" would splice into "Cre|a|te". The warn panel only fires on `i < 0`, so the wrong-occurrence case is completely silent. Fix: track slot offsets, or anchor each replacement to its surrounding literal (`boat (`…`)`, `labeled '`…`'`, `Keep the style `…`.`). — screen_customize.html:1451-1461 R1 apply()
• majorThe Undo button stays on screen after `st.undo = null`, and clicking it does nothing at all — no state change, no message, and the stale note ("Restored the catalog's wording for Retro-Comic Action Blueprint.") still asserts an action you can no longer reverse. Two keystrokes to reach. Hard requirement 7. Fix: call `closeRows()` wherever `st.undo` is cleared, or hide `undoBtn` from `render()` off `!!st.undo`. — screen_customize.html:1085/1090/1208/1263/1305/1463/1480/1511 vs note()

What works

"The two collections do not blur: separate sections with separate subtitles (\"Copies you edited and named. Each one keeps a link back to the recipe it came from\" vs \"Catalog recipes you bookmarked. Nothing here is edited — the moment you change one, it becomes a my version and moves up there\"), separate card treatments (`.m-card.is-mine` gets an accent left border and a `My version` chip; saved cards carry exactly the system's card shape — image, title, requirement line, Use recipe + Save, nothing else), and every my version shows \"Made from <recipe>\" as a working link.\n\nThe return card is the right idea, executed almost entirely: the version's live state, a numbered two-step path (pick document → copy), the three-row original-versus-mine comparison, the full prompt with the two changed lines bar-marked and tagged \"My edit\", a persistent Copy prompt, provenance demoted to the footer, and the seven-style row present but below the prompt. \"You built this once. Coming back is two steps\" is honest about what the screen actually costs.\n\nCopy is complete everywhere — the one bug that shipped last time is fixed, and I proved it by diffing all 16 rendered payloads and all seven JS style datasets against recipes.md character-for-character (including the Neumorphic double line break).\n\nThe two no-image treatments are correctly distinguished in all four places they appear. R2 card: dashed gap chrome, \"No example yet / We haven't made a render for this one.\" R4 card: a designed accent-soft panel headed \"What you get — illustrative, not a result\" with \"One drawing of you at work, exaggerated the way a street artist would\" and \"It is different for every person who runs it, so there is no example to show.\" The list rows carry the same distinction at 34px (`m-th-gap` dashed \"No example yet\" vs `m-th-shape` accent \"No example possible\"), which is more care than the requirement asked for.\n\nThe dense list is what the direction asked for: single-line rows, expandable detail, prompts behind an explicit \"Show prompt\" toggle, and no nested scrollbar in any row.\n\nDead-control discipline is otherwise good — every one of the 20 data-act values has a handler, `nav` honestly reports \"Opens the recipe: X. This prototype is one screen.\" instead of pretending, unsave/resave keeps the card and the row in sync by data-item and recomputes the header counts, and the state machine is driven by data attributes rather than inline styles. The single exception is restore-no, and that exception is what costs the score."

Phone

"A real adaptation, and the best-argued part of the submission after the copy payload. Concrete evidence of independent structure rather than a squeezed desktop: a sticky app bar (`.m-p .m-ptop{position:sticky;top:0}`) that the desktop does not have; a two-up tab navigation (`<nav class=\"m-tabs\">` with `data-act=\"tab\"` and `.m-p[data-tab=\"versions\"] .m-coll[data-coll=\"saved\"]{display:none}`) replacing the desktop's stacked sections plus Cards/List toggle; `data-view=\"list\"` hard-set so the phone never renders the grid at all; a one-column return card (`.m-p .m-rgrid{grid-template-columns:1fr}`) with the document pills stacked full-width (`.m-p .m-pill{width:100%;padding:11px 13px}`); row actions hidden until the row is opened (`.m-p .m-rowacts{display:none}` → shown on `.is-open`), which is a genuinely different density decision; the palette swatches demoted from the media column into the footer's Fine detail; the diff's two-column was/now collapsed to one (`.m-p .m-was{grid-template-columns:1fr}`); shortened copy (\"3 weeks ago\" vs \"Last opened 3 weeks ago\"); and a thumb-reachable sticky bottom `Copy prompt` bar that the desktop replaces with an inline step-2 button. The return card is the first thing under the header on both frames, so the return journey is the primary path as asked.\n\nSideways scrolling: I could not render, but I checked every candidate and found no overflow. `.m-p .m-rowmeta{white-space:normal}` explicitly undoes the desktop's nowrap+ellipsis; `.m-rowtitle{overflow-wrap:anywhere}`; `.m-txt{white-space:pre-wrap;overflow-wrap:anywhere}`; `.m-rowhit` and `.m-rowtext` both carry min-width:0; `.m-rowacts` and `.m-crow` wrap or fit; the only `overflow-x:auto` element (`.m-srow`) is desktop-only. The tightest line is `.m-diffhead` — h3 + \"3 changes\" chip + a nowrap \"Restore original\" button need roughly 347px of natural width in a 328px content box, so the heading will wrap to two lines, but min-content (~274px) fits, so it compresses rather than scrolls.\n\nTwo real weaknesses: the style row is dropped entirely with no replacement, and the naming box has no Cancel, so the phone's Save-as-new-version flow has no exit. The designer's stated worry — that the full ~800-character prompt makes the card very long — is real (the return card alone is roughly two and a half phone screens) but the sticky Copy bar is the right mitigation and the direction explicitly forbade collapsing the prompt."

Problems

• blockingThe Restore-original confirmation is a one-way trap and "Keep my edits" is a dead control. changeCount() is the only writer of data-state back to 'list'/'none' and it self-guards with `!=='confirm'`, so once `restore` sets data-state="confirm" the panel can never leave that state. Concretely: click "Restore original" in the diff header → the confirm block appears and CSS line 103 hides the diff list AND the header's Restore button. Click "Keep my edits" → nothing happens at all; the question stays on screen and the three-row comparison — the thing this screen is built to show — is gone for the rest of the session. Click "Restore original" in the confirm block → the prompt does revert to Retro-Comic and the image swaps, but the dialog keeps asking a question already answered, the chip underneath now reads "0 changes" next to a live "Restore original" button, and the `data-state="none"` panel holding the only undo ("Undo, put my changes back") becomes unreachable. This is in the centrepiece return card, in both frames. — screen_mine.html JS lines 1164-1170 and 1276-1279; markup lines 312 (desktop) and 756 (phone)
• majorSaving a new version fabricates its history and its change record. saveNew clones `host.firstElementChild` (the existing v1 card and row) and rewrites only .m-vname, .m-vstyle, .m-changes, images and .m-ptext. Everything else is carried over verbatim — including `<p class="m-mini">Last opened 3 weeks ago &middot; ran on Q3 board deck.pdf</p>` on a version created one second ago, and the entire `<ul class="m-diffs">` from v1. So: switch to PCB with "Switch, use this style's text", then Save as new version, and the new row's meta correctly says "PCB Schematic Architecture · 1 change" while its own expanded "What I changed" still lists three rows ending "Mine: Engineering Blueprint Schematic / Mine: Industrial Monospace or DIN Condensed, Uppercase / Mine: Technical, Blueprint, Schematic, Board Deck". The screen states edits the user did not make and a run that did not happen. On this project's cardinal rule that is the worst kind of defect, even though it only appears after interaction. — saveNew(), JS lines 1210-1233
• majorChange counting is a hard-coded formula (`style!=='retro' ? 1 : 0` plus `edits==='on' ? 2 : 0`) rather than a comparison of current text against data-orig. Reachable false claim: switch to PCB Schematic Architecture with "Switch, keep my two edits" — PCB's Typography Style is byte-identical to the user's borrowed edit, so the diff shows Recipe and Mine as the same string, the count still says 3 changes, and the prompt line keeps its accent bar and "My edit" tag on a line that is now the catalog's own text. Replace the formula with a per-field `text !== data-orig` test and the diff, the count and the bar marks all become self-correcting. — changeCount(), JS line 1165
• minorEvery saved version gets `data-item="vnew"`. Save twice and two cards and two rows share the id: boxFor's card branch does `app.querySelector('.m-row[data-item="vnew"] .m-ptext')` and returns the first match, so the second version's Copy prompt copies the first version's prompt. unsave/resave would also toggle both at once. — saveNew, line 1218
• invented"Last opened 3 weeks ago" (desktop return band, line 254) and "3 weeks ago" (phone, line 718) — fabricated user history. Not in recipes.md. Defensible as mock user state (the brief says "comes back weeks later"), but it is a specific figure presented as fact.
• invented"Last opened 3 weeks ago &middot; ran on Q3 board deck.pdf" (list row v1, lines 476 and 874) — fabricated run history, and it is cloned verbatim onto newly created versions by saveNew (see problems).