Dashboard backlog

Raised but not sequenced. Unordered on purpose: planning.md is where order lives, and putting an unsequenced item in an ordered list turns the list into a wish list where the loudest row wins.

Every row says what would promote it. A row that cannot say that is a row nobody can act on.

What is raised?

Merchant dashboard parity with the admin one.

• What it is: The merchant dashboard adopts the same two-column shape as whichever admin Dashboard shape wins, scoped to the merchant's own venue. Her words, 2026-08-27: "for merchant, the dashboard should be closer to what admin has, then they would have their own analytics page to get reports, etc".
• Why it is here rather than in its own project: this project already owns the ALPHA.md row "Merchant-side dashboards" and its issue #320: Phase 3: Venue analytics, aggregate interest and vibe insights for merchants. A second project would be a second thing pointing at one row, which is the duplication non-negotiable rule 13 exists to stop.
• What would promote it: the admin Dashboard shape being chosen. There is no parity to build until there is something to be at parity WITH, so this is strictly downstream of that decision.
• What it depends on beyond that: HERS 4 above, since the rail needs data and all three data options carry a k-anonymity risk. And her ruling on what fills the merchant's reading column, which is either merchant-facing announcements or their own recent activity, and those are weeks apart in cost.

Alerts on the Dashboard: threshold and health state.

• What it is: Cost and service-health alerts surfaced on the Dashboard rail. Her words, 2026-08-27: "Alerts are more along the lines of 'x increase in cost, or admin dev is down, etc'." The reasoning and the build order are in brainstorm.md under "What did she add after the survey ran?".
• What would promote it: two things, and neither is a design decision. The SystemHealth.jsx false DOWN defect being fixed, because alerting on a health check that cries wolf gets muted. And task 2's sidebar rearrange landing, because System Health and Costs are both moving and their new homes decide where this reads from.
• THE FIRST CONDITION HAS LARGELY FIRED, on 2026-08-27 at 0846. Task 2 found while moving System Health that three of its four uptime checks could never pass: two probed admin.ourlantern.app and storybook.ourlantern.app, which do not resolve on prod at all, and the third probed an HTTP health endpoint on the Discord bot, which is a gateway client with no HTTP listener. Commit c4337370, and its own reasoning was the same one written here: a check that cannot succeed teaches everyone to ignore the tab. Nine real endpoints now. Whether every false DOWN is gone is not proven, so treat this as the defect being addressed rather than closed.
• What it is NOT: a page. The evaluation and the delivery are backend work, and the surface is only the readout. Building the surface first produces an empty one.

Mass email to admins or to merchants.

• What it is: A way to send an email to every admin, or to every merchant, from inside the portal. Her ask, 2026-08-28, captured for backlog rather than sequenced.
• Why it is here rather than in its own project: it is the same family as the announcements gap below it, and splitting outbound communication across two projects is how one of them goes quiet. If either gets sequenced, they should be scoped together.
• What would promote it: her word that it is intended work, plus one decision that shapes everything else: is this operational (a service notice, a policy change, an outage) or is it marketing (a campaign, an offer, a nudge)? Operational mail is transactional and short; marketing mail needs unsubscribe handling, send scheduling, and a compliance read. They look identical in a mockup and are months apart in cost.
• What nobody has checked yet, and it decides feasibility: whether this repo has any outbound email capability at all today. Nothing in the survey or the brainstorm mentions a mail provider. Check that before designing anything, because "add a compose box" and "adopt a mail provider, verify a sending domain, and handle bounces" are different projects wearing the same sentence.
• The privacy read is not optional. Merchant email addresses are account data. A send-to-all path is a bulk read of that data plus an egress to a third-party sender, which is exactly the shape #874: design(privacy): one data-classification and egress policy, before search, the assistant, and the apps platform each invent their own exists to rule on once rather than per feature.

Announcements that someone WRITES, as opposed to ones read from the repo.

• What it is: the half of the announcements feature that the 2026-08-27 scoping deliberately left out. Her question, 2026-08-28: "If I want to submit an announcement, where exactly would it go?" The answer today is nowhere.
• Why the gap exists: brainstorm.md decided the Dashboard reading column IS the announcements surface, which is true for admin-facing announcements because they read from the repo and cost nothing to author. It then named the split: announcements someone writes need an authoring surface, a publish flow, targeting, and read state. Only the read half was ever in scope, and nothing carried the other half forward.
• What would promote it: her word. It is a real feature rather than a page, and the same operational-versus-marketing question above applies to it.
• Its relationship to mass email: probably one feature with two delivery channels, in-portal and email, rather than two features. Deciding that first is cheaper than building either.