Merchant report creator: what to review

Field	Value
Branch	feat/admin-and-merchant-portals, draft PR #976: feat(admin): portal navigation, financials and monitoring, plus the agent-process work behind them, not merged
Project	README.md
Issue	None yet. Per project-creation, an item gets an issue when the work is actually intended, and this is backlog
Servers you need	None. Nothing was built.
Local origins	Not applicable

Is there anything to look at?

No. Nothing was built, and this file exists so you never have to wonder whether the folder was considered.

• The only change this branch made here is one commit that recorded your rulings on announcements, alerts and merchant parity.
• Only README.md exists in this project. No planning.md, no design.md, no code.

What changed here?

The project was split out of merchant-and-venue-dashboards on 2026-08-27 and given a home.

• The survey called it its own project, and you confirmed it as a separate page: "for merchant, the dashboard should be closer to what admin has, then they would have their own analytics page to get reports, etc".
• So the split you want is: the dashboard answers "how am I doing", and this answers "let me go and look".

What is deliberately NOT done, and what is worth knowing before it starts?

Nothing is sequenced, because it is backlog.

• What would promote it: your word that it is intended work, which is what mints the issue. Realistically also the query console settling, since this builds on what that becomes.

Its ancestor got significantly closer on this branch, and that changes the starting point.

• The Report Builder component built for #987: feat(admin/analytics): a configurations page, a BigQuery-sourced schema viewer, and the BigQuery page becomes the Report Builder is a guided builder over a bounded metric set, which is this surface minus the privacy gate.
• It is Storybook-only, on port 6008. If you want to see roughly what this project would start from, that is where it renders: Report Builder, via npm run storybook:admin.
• Practical consequence: this project starts by reading what the query console and the Report Builder became, not from a blank page.

The hard part is the privacy gate, not the interface.

• A merchant pulling arbitrary cuts of venue data is exactly the shape that leaks a small cohort. A quiet venue, a narrow date range and one dimension too many resolves to a single person.
• #874: design(privacy): one data-classification and egress policy, before search, the assistant, and the apps platform each invent their own is the open Prototype P0 that would answer this once rather than having this project invent a fifth ad hoc answer.

The three design options are NOT copied here, on purpose.

• They live in ../merchant-and-venue-dashboards/design-survey.md, item HERS 5. A second copy is a copy that drifts.

Which launch plan row this is remains an open question for you.

• Candidate A is the existing "Merchant-side dashboards" row, but pointing a second project at it repeats the one-issue-two-rows problem.
• Candidate B is no row at all, because a report creator may be post-Alpha.
• Candidate C is a new row, which is not an agent's decision to make. Nothing is written into the launch plan until you pick.

What open findings touch this project?

• Nothing. No code exists here, so no finding in ../merchant-and-venue-dashboards/branch-review-0828.md can land on it.

What issue does each piece close?

Piece	Issue	State
The project itself	None yet	Backlog, awaiting your word
Where merchant-facing aggregate analytics already lives	#320: Phase 3: Venue analytics, aggregate interest and vibe insights for merchants	Open
The admin ancestor of this surface	#958: feat(admin/analytics): promote Query Console to its own surface and teach it to query Firestore	Built on branch
The k-anonymity question that must be answered once	#874: design(privacy): one data-classification and egress policy, before search, the assistant, and the apps platform each invent their own	Open, Prototype P0