Dashboard brainstorm

What is this?

The raw input for the dashboard work, in her words, before anyone scopes it.

• Opened 2026-08-24 when the block was still scoped as "make the placeholders show real numbers". Her response was that this is not the job.
• Her words: "I don't want just real numbers, we need to scaffold the actual design correctly."
• This file is the input to a brainstorm, not the output of one. Nothing here is decided. Her closing line was "There is a myriad of other shit but that is what the brainstorm would be for."

What did she name specifically?

The reporting period banner is the wrong shape.

• On the admin Venue Activity screen it spans the full page width, with the 24h / 7d / 30d / 90d control pushed to the far right and a large dead span between.
• Her call: dynamic width based on the content, not full bleed.
• Lives at VenueActivityDashboard.jsx:214.

This is a cross-cutting design problem, not one screen.

• Her framing: "there are also some design choices that need to get fixed across the board", with the banner as one example rather than the whole list.
• So the pass has to look at the shared primitives, not patch the two screens it was noticed on.

The merchant dashboard spacing is wrong.

• Her words: "simply even just the spacing here is fucked".
• Visible in the screenshot: the four stat cards carry different amounts of sub-content ( Active Offers has two rows, Venues has one ), so the cards are ragged and the short ones sit in dead space.

The merchant dashboard needs more data on it.

• Her words: "we honestly need to add more data to this". What data is a brainstorm question, not an assumption to make here.
• Context worth carrying: the whole Ad Delivery panel currently reads zero across impressions, clicks, CTR, claims and redemptions, and the Ad Views chart is a flat line at zero.

Merchants need a report creator.

• Her words: "we need to build a report creator so merchants can actually pull data they want".
• This is a feature, not a fix, and it is the largest thing named here.

What is the current state?

Nothing is decided and nothing is built.

• The session that was going to make placeholders read real data has been re-scoped rather than run.
• The build follows the brainstorm. Building first is what produces the half-designed screens above.

One thing checked and cleared.

• The - next to "Unique visitors" is an EN dash ( U+2013 ) from the statValue placeholder helper, not an em dash. Not a rule break. Whether a dash is the right empty state at all is a brainstorm question.

What else is related?

• #320: Phase 3: Venue analytics, aggregate interest and vibe insights for merchants, which is a Phase 3 feature build with unmet Phase 1 and Phase 2 dependencies. The report creator may belong to it; the spacing and banner fixes clearly do not.
• The design skill, which forbids inventing a hex value or a raw pixel: every value comes from the tokens and Storybook.
• The design-mockups skill, which renders layout variants with the app's real CSS and screenshots them. It is the cheapest way to settle the banner width without arguing about it in words.

What did she add before the survey ran?

Given 2026-08-24, with her own reason: "Some quick items before we begin that survey since I am not sure how it may affect stuff." It does affect it, so it is here rather than in the survey's findings.

The admin sidebar is being rearranged, and most of it is DECIDED rather than open.

The sections today, in apps/admin/src/admin/AdminShell.jsx, are Main ( 186 ), Development ( 207 ), Platform ( 268 ), Operations ( 316 ), Settings ( 326 ).

• System Health moves into Development. It sits in Operations today at line 321.
• The Costs tab moves out of System Health and into Billing. It is SystemHealth.jsx:184, already carrying id: 'billing', with its component at line 998. The move mostly follows an id that was already pointing at the destination.
• Development moves down to sit directly above Settings, making the order Main, Platform, Operations, Development, Settings.
• Nothing sits below Development or Settings. Once Development moves, this already holds.
• OPEN: where Billing goes. Her words: "I am wondering if billing needs to move? I am just not sure where." It is in Operations today at line 322.

Three surfaces she has already called redesigns, not fixes.

• The Dashboard. Her words: "Having cards to links doesn't do anyone anygood." What she wants instead is links to releases, news, what we are, and similar. She marked this one NEEDS BRAINSTORM explicitly, so it is the least settled of the three.
• Ad Network must become a first class surface, like Venues. Today it is dashboards/ads, a route under Analytics, while Venues is a plain top level item in Platform. Her words: "It needs its own dedicated considerations."
• Offer review. Her words: "REALLY needs a redesign." It is a sub item under Merchants at merchants/offer-review.

The line between these two lists matters for whoever picks this up.

• The nav rearrange is a defined change with one open question. It does not need a brainstorm and should not wait for one.
• The three redesigns are genuinely open, and the Dashboard one she named as needing a brainstorm in so many words.

On where Billing goes, which she left open: leave it in Operations.

• A recommendation, not a decision. Hers to make.
• Once System Health leaves for Development, Operations reads Users, Moderation, Tasks, Billing. Those four share something real: they are the things you do on a running business, day to day. Nothing else in the tree fits that description.
• The Costs merge strengthens the case rather than complicating it. Money is split across two places today, System Health's Costs tab and Billing. After the merge Billing is the single money surface in the product, and a single complete surface earns a top level slot in the section she actually works in.
• Considered and rejected: moving it beside Development, on the theory that infrastructure cost is a developer concern. That is true of where the cost comes FROM and false of who reads the number. She reads it as an operator deciding what to spend, not as an engineer debugging a service.
• Considered and rejected: its own section. A section of one item is a heading pretending to be structure.

What did she add after the survey ran?

A conversation on 2026-08-27, after the survey landed and while task 2 was rearranging the sidebar. Her words are quoted; the reasoning under each is the discussion that followed, not her ruling.

Announcements folds into the Dashboard rather than becoming its own page.

• Her words: "I think I agree on the announcements component."
• What she was agreeing to: an Announcements page and Dashboard Shape 2 ( the changelog front page ) are the same feature under two names, and building both produces two pages doing one job, which is the duplication her original complaint was about.
• Consequence for whoever builds the Dashboard: the reading column IS the announcements surface. There is no separate nav entry to add.
• The split that stays open: admin-facing announcements read from the repo ( releases, changelog, what Lantern is ) and cost nothing to author. MERCHANT-facing announcements are us writing to merchants, which needs an authoring surface, a publish flow, targeting and read state. Those are different features, and only the first one is in scope here.

Alerts are a different thing, and they are threshold and health, not counts.

• Her words: "I still think alerts are different, but could potentially be on the dashboard as well. Alerts are more along the lines of 'x increase in cost, or admin dev is down, etc'."
• She is right and an earlier reading here was wrong. Alerts had been framed as counts that should be badges. Her examples are not counts: a cost spike has no screen to go and resolve, which is what separates it from "five offers awaiting review".
• The page is the small part. Something has to evaluate a rule on a schedule and deliver the result. The page is only the readout and the configuration: what rules exist, what fired, what is still firing, was it acknowledged.
• Delivery is per alert, not one channel. "Admin dev is down" cannot be delivered to a page inside the admin portal, because if the backend is down so is the page and nobody is looking at it. That one goes out of band, and discord-notify.yml is the delivery this repo already owns. "Cost up X percent" nobody needs at 3am, so that one is a digest.
• Build order that follows from this: detection, then delivery, then the page. Building the page first produces an empty page.
• Where it sits if it goes on the Dashboard: it is Shape 1's left rail with threshold state instead of counts. "Cost up 40 percent this week" and "auth-api down 6m" beside the reading column is a coherent page.
• The prerequisite, and it is not optional. SystemHealth.jsx has a known false DOWN defect, carried as a P2 on the Prototype page. Alerting on a health check that cries wolf gets the alert muted, and a muted alert protects nothing. That is fixed before this is worth building.
• One timing note: task 2 is moving System Health into Development and the Costs tab into Billing. Deciding where Alerts lives before that lands is deciding against a layout that is mid-change.

The merchant dashboard should look like the admin one, with reports on a separate page.

• Her words: "for merchant, the dashboard should be closer to what admin has, then they would have their own analytics page to get reports, etc"
• What that means concretely: the same two-column shape as whichever Dashboard shape wins, scoped to the merchant's own venue. Their numbers on the rail, a reading column beside it.
• The open question it creates: what fills the merchant's reading column. For admin it is our releases, free from the repo. For a merchant it is either announcements we write to merchants, which is the content-ops commitment named above, or their own recent activity, which is cheap. Different features in the same slot, and she has not ruled.
• What goes on their rail is already scoped as HERS 4 above, three options, all carrying the same k-anonymity risk: a quiet venue produces suppressed counts and the page fills with the empty glyph.
• The separate analytics page is HERS 5, the report creator, which the survey already called its own project. It now has one, at docs/projects/merchant-report-creator/.