The storefront admin home.
Every storefront gets one home. It opens with the storefront's own clearance status — are the compliance-critical checks green right now? — and puts the work that needs a human first.
- ✓ A storefront-level seal: this storefront is clear — age gate, excise, jurisdiction all green.
- 1 Review & release is the centerpiece — 1 change is held, surfaced before anything else.
- → Future surfaces — releases, feedback inbox, storefront health, theme — ring the same home.
Everything waiting on a human decision.
The review queue shows only this storefront's changes in ready_for_review. Each row reads in plain language and shows its evidence state at a glance — so you triage before you open anything.
- ✓ Plain-language summary · opaque submitter id (dev:agent-7Q2K) · time in queue.
- ✕ A held row names which compliance checks fail right on the card — age_gate, excise.
- ◆ Per-tenant isolation is structural: no other storefront's work appears here.
Decide from evidence — the Release Manifest.
The reviewer decides primarily from one EvidenceReport. We render it as a sealed manifest: compliance-critical checks are visually load-bearing and sit apart from advisory ones.
- ! Compliance-critical — age_gate · excise · jurisdiction. Any non-pass blocks release.
- i Advisory — llms_txt · json_ld · sitemap · cutover_crawl. Informational; never blocks.
- ↗ Every row links to its proof — a route, a crawl report, the llms.txt path.
Green evidence unlocks the seal.
When every compliance-critical check passes, promotable is true: the Clearance Seal stamps CLEARED FOR RELEASE and Approve is a live, one-click action — with the proof sitting right beside it.
- ✓ The seal's microtext ring encodes the verdict — legible, not decorative.
- ✓ Approve & release is one click — no committee, no second screen.
- ↩ A reviewer can still reject a green change — with a typed reason.
Red evidence: Approve doesn't exist.
This is the non-negotiable. When promotable is false, Approve is structurally absent — not a greyed-out button you could wish into working. In its place: a locked plate naming the exact failing checks.
- ✕ The seal is broken & hazard-hatched: 2 of 3 fail · do not promote.
- 🔒 age_gate bypassable · excise unmapped — shown as the reason, not a footnote.
- ↩ Only Reject remains. A change that hides the age gate can't be approved through this UI.
The manifest shows why — in the reviewer's words.
The same blocked change, end to end: the before→after preview catches the bundle route rendering before the age gate, and the manifest's compliance-critical rows turn red with a plain-language detail and a link to the crawl proof.
- ✕ age_gate · Fail — “the bundle route renders products without firing the 21+ interstitial.”
- ✕ excise · Fail — “the $120 bundle SKU isn't mapped to excise categories.”
- ▲ Advisory rows can warn or skip without blocking — the gate only cares about the critical three.
Sending it back takes a reason.
Reject isn't a silent bounce. It requires a typed reason, returns the change to in_progress, and writes an immutable audit entry — approver identity, reason, timestamp. Even a green change can be rejected this way.
- ✎ The reason goes to the developer by their opaque id — no PII on this screen.
- ↩ The change drops back to in_progress; the feedback item stays open.
- ⎘ Every decision — approve or reject — is recorded against op:rae-m.
Ship, then announce — nothing auto-publishes.
On approval the change ships and an editable announcement draft is generated from the change summary and the feedback it closes. The reviewer edits, then publishes — to the changelog, and as a notification back to the original reporter.
- ▲ A guardrail: announcements describe the change only — never legal, age, excise, or price copy.
- → Publishing notifies rpt:8F3C by opaque id — the loop closes back to who reported it.
- ⏸ Nothing publishes until the reviewer presses the button.
Every change knows where it sits.
A lifecycle track rides the top of every detail screen, so the reviewer always knows the stage — and the off-track outcomes are explicit.
And it degrades gracefully: when the queue is clear, the screen is an invitation, not a void.
