Surface design pass: raised, not sequenced

• Unordered on purpose. The ordered scope is planning.md. Mixing the two turns an order into a wish list.
• Every row says what would promote it. A row that cannot say what would move it is a row nobody can act on.
• Nothing here is a judgement that the item is unimportant. Most of it is important and belongs to someone else.

Which survey items does this pass leave alone, and why?

Twenty of the survey's thirty. The rule that put them here is in planning.md: a defect confined to one screen, or on a screen #320 is about to redesign, is not this pass's.

The five she named herself.

Item	Why not here	What would promote it
HERS 1, the Reporting Period banner is the wrong shape	Her named call on a #320 screen, and it cannot be fixed correctly before X1	X1 landing, which is #320's own rank-1 item
HERS 3, merchant Overview spacing	Option A depends on HERS 4, so fixing it first means doing it twice. The survey says so itself	Her ruling on HERS 4
HERS 4, the merchant dashboard needs more data	It is a product decision about what a merchant is owed, not a design grammar	Her ruling on which of the three data directions
HERS 5, merchants need a report creator	Its own project, and the survey says so. Plausibly lands under #320	A project folder and an issue, when she intends the work
HERS 2, this is cross-cutting, not one screen	Partly in this pass already: it takes 4 of the 7 cross-cutting items	The other 3 move with #320

The three cross-cutting items whose only consumers are #320 screens.

Item	Why not here	What would promote it
X1, the period bar is duplicated as two components with byte-identical CSS	Both consumers are analytics dashboards #320 owns, and the fix needs the canonical label and period set decided	#320 starting, or her ruling on the label and the period set
X5, two stat idioms stack on one page	Both instances are on #320 screens (merchant Overview, admin Ad Delivery)	A third surface adopting the flat strip, which would make it a grammar rather than a page problem
X6, .role-cards-grid is a hard 4-up that jumps to 2-up	Same grid as HERS 3, and the design skill warns the obvious minmax idiom collapses in a squeezed track	A measured pass at real widths, taken together with HERS 3

The admin items that sit on a screen being redesigned.

Item	Why not here	What would promote it
A1, Top Venues charts raw venue IDs	On a #320 screen, and the fix depends on whether the BigQuery ranking already joins venue metadata	The same fix is needed in Offer review, so whoever does either should do both
A2, three of five analytics dashboards are scaffolds	#320's surface, and the answer is a roadmap decision, not a style one	Her call on hide, mark, or keep as a roadmap surface
A3, the two dashboards use different names and period sets	Mechanically X1, but the copy choice is hers	Her ruling on the word and the period set
A4, Ad Delivery shows a zeroed dashboard rather than an empty state	#320's surface	An empty-state grammar existing, which step 2 may produce
A5, the Dashboard is a card grid of links	Her named redesign, with three shapes already drawn in the survey	Her pick among the three shapes
A6, every Dashboard card carries an "Available" badge	Folded into A5, and the survey marks it non-optional in all three shapes	Moves with A5
A8, Feature Tracker and Billing render error and loading as their steady state	Two admin screens, and the root cause is configuration rather than design	The empty-and-error-state grammar from step 2. A8 then becomes an application of it, not its own decision

The merchant portal items.

Item	Why not here	What would promote it
M1, the "Unique visitors" icon makes its row 32px against 21px for every sibling	On merchant Overview, which #320 owns	Step 3's icon rule decides WHAT it should be. Whoever next touches Overview executes it
M2, Recent Offers titles wrap to three and four lines	Merchant Overview	Moves with #320's Overview work
M3, the Ad Views panel renders a 370px chart of a flat zero line	Merchant Overview, and it is the same question as A4	The empty-state grammar, then #320
M4, "Clicks, CTR" renders as broken text when CTR is empty	Merchant Overview. Step 2 unblocks it by fixing the glyph, but the label composition is an Overview change	Step 2 landing, then #320's Overview work
M5, roughly 420px of empty nav between Settings and the switcher	The admin sidebar fills its height and the merchant one does not, so it borders on a grammar. But every option is a decision about what the space is FOR, which is content	Her word on whether that space carries merchant context (venue, plan, quick stats) or stays empty
M6, six merchant tabs are thin	The survey records it as context for HERS 4, not as a defect	Her ruling on HERS 4

The three redesigns, which are sections rather than line items.

• The Dashboard, Ad Network and Offer review each have their own section in the survey with options and a recommendation. All three are hers to rule on and all three belong to #320 or to a project of their own.
• One dependency worth carrying forward: the survey notes that Ad Network and Offer review overlap and should be decided together, because Offer review's home may move out of Merchants and into Ad Network.

What else is raised for this pass and not sequenced?

#826: the admin portal has no mobile layout.

• The sidebar never collapses and content renders off-screen on a phone. It is open, labelled design, and it is not one of the survey's 30.
• Structural rather than a grammar, so it does not fit the rule that scopes this pass.
• What would promote it: her call on whether the admin portal has to work on a phone for Alpha. If yes it is its own project, not a step in this pass.

#824: merchant venues need a detail page rather than inline controls.

• A new page, so structural. What would promote it: sequencing it with the merchant portal work under #320, where its siblings already are.

#823: should the Event Tracking row icon differ by client, server, or both?

• This one genuinely is a grammar question, and step 3 is where icon decisions get made.
• What would promote it: step 3 starting. It is small enough to absorb there if she wants it in.

The web app's own grammar inventory now exists. Step 1 ran on 2026-08-27.

• Output: design-survey-web.md, 12 signed-in routes rendered and measured, 9 items W-A through W-I.
• Two of its items went to a step (W-A and W-B to step 6, W-D to step 3). One item closed a decision (W-H fed step 2). The rest are the four rows below.

W-C: three signed-in screens have no h1, and four profile pages share one.

• #/schedule, #/feedback and #/venue/<id> start their outline at h2. All four #/profile/* routes render h1:Settings regardless of which tab is open.
• Cross-cutting and cheap, but it is an a11y surface no step owns, and the story a11y gate cannot reach a screen-level composition.
• What would promote it: a step of its own, or absorption into whichever step next touches the profile shell.

W-E: four interactive targets on every signed-in screen measure under 24px.

• Bottom-nav Info and Me are 22x41; Skip in the tour is 25x16; Delete my account is 123x20; a #/feedback checkbox is 16x16.
• Not promoted here because the measured element may be narrower than its tap area, and e2e:mobile-pwa already owns touch-target auditing under phone emulation.
• What would promote it: confirming the real hit area, then a decision on whether WCAG 2.5.8 is an Alpha gate.

W-F: the type ramp runs 10 to 14 distinct combinations per screen.

• #/profile has 14, #/frens 13, #/activity only 5. Outliers include 18px/400/18px (lines touch) and two sizes unique to #/support.
• Not a grammar this pass set out to fix, and collapsing a ramp touches every screen at once.
• What would promote it: her word on whether the app gets a fixed type scale, which is a bigger call than this pass.

W-G: the web app and the admin portal share no radius vocabulary.

• Web renders four radii plus a full-round pill, all from raw Tailwind rounded-*. Admin draws from --radius* tokens. theme.css does not currently bridge them.
• This is the most "one product" of the leftovers, because it is a token gap rather than a screen defect.
• What would promote it: a decision on whether --radius* extends to apps/web, which is a packages/ui change and wants its own scope.

W-I: the dev location-spoofing panel on #/profile/privacy is purple.

• ProfileSettings.jsx uses bg-purple-900/20, text-purple-400 and bg-purple-600 for a chrome panel. The design skill says purple is domain data only.
• It renders only on a dev build, which is why it survived.
• What would promote it: step 3 starting, which is where the dev-surface glyph and colour questions land anyway. Small enough to absorb.

What did this scope find in the launch plan and deliberately not change?

ALPHA.md was read, not written. Another session was editing it at the same time. These are recorded for whoever holds the plan.

The "Polish and refinement" row is accurate and needs no edit.

• Its Description ("A deliberate pass over the app, merchant surfaces and admin portal") and its Why both match the work. It was #293's body that disagreed with the row, and the body is what was changed.
• Its Status reads In progress. That was ahead of reality until today, when this scope became the first work under it. No edit needed.

Two Phase 1 rows carry no issue link at all, and one of them is already designed.

• "Ad Network as a first-class surface" has an empty Issues column, yet the design survey carries a full section on it with a recommendation (promote it to a top-level Platform item as a section with tabs). Work that has been designed and has no issue is work that gets designed twice.
• "Venues search and filters" has an empty Issues column too.
• Not changed here, because the project-creation skill is explicit that a project writes only its OWN issue number into its OWN row, and because the row belongs to a plan another session was editing.
• What would promote them: her word on whether either is real enough to file, then an issue and the link into the row.