Operator tools — the dev switches, off the dashboardOwner: PRODUCT (FG) — and FG-unique (round 3: “Operator tools (sandbox emulator) — FG-only ✓ dev tool”). Moved OFF the dashboard by the founder’s round-2 ruling: “dashboards carry no dev/build tooling — sandbox controls are an operator page.” This is that page.
Scope (§17): every toggle here acts on ONE named FG creator account, put into emulation. Nothing here is platform state — platform-wide modes and flags live in Platform control.
Operator test: the ONE thing this page does is put a named test creator into sandbox — safely, audited, and never a real one.
Scope (§17): every toggle here acts on ONE named FG creator account, put into emulation. Nothing here is platform state — platform-wide modes and flags live in Platform control.
Operator test: the ONE thing this page does is put a named test creator into sandbox — safely, audited, and never a real one.
Per-creator sandbox emulation for KYC and payments, plus the demo, preview and dev utilities that used to clutter the dashboard.
Live · auditedDemo rows
Sandbox controlsEmulation, per creator. A sandboxed account runs the real product against emulated rails: KYC decisions come from the emulator, payments settle nowhere. Sandbox interacts with feature flags — a sandboxed creator evaluates flags as themselves, so a rollout can be rehearsed end-to-end without money or identity risk.
Look up a creator, flip their rails to emulated. Every flip is audit-logged with actor + reason.
⌕
⚒
@qa-aria · test seedsandbox account · created for rehearsals · never fan-visible
KYC emu
Payments emu
⚒
@qa-onboard · test seedsandbox account · onboarding-flow rehearsal
KYC emu
Payments emu
⛔
Never real creators. Sandboxing an earning account would silently void its checkouts and KYC state. The lookup filters to test-flagged accounts; forcing a real account requires the Impersonate/act-as permission AND a typed confirmation naming the account — and the sheet tells you why you almost certainly should not.
≡
Write path: sandbox flags write via the FG admin API and land in the audit log (walks §11: “per-creator KYC/payments emulator, audit-logged”). Fail-safe: if the flag read fails, rails resolve to REAL — an account can never get stuck half-emulated because a cache missed.
Demo & previews
The marketing-aside surfaces, KEPT per the disposition ledger (hero · miniapp · seo · demo-previews).
▶
Demo & previewsguided demo states for stakeholder walkthroughs — read-only, no live data
▤
Hero previewmarketing hero variants as they render on fanogram.co
◫
Miniapp previewthe in-messenger miniapp surface, framed for review
⌕
SEO & metadatatitle/description/OG previews per public route
Dev utilities — out of scope, never droppedDisposition honesty (§14 acceptance): every live FG route carries a disposition — MERGED, KEPT or OUT-OF-SCOPE, never absent. These three are OUT-OF-SCOPE of the redesign: dev harnesses, not admin surfaces. They are named here so nothing is silently dropped.
md-preview — markdown preview harness. Not an admin surface; not redesigned.
out-of-scope/demo-walkthrough — guided demo harness. Not an admin surface; not redesigned.
out-of-scope/console — legacy console, superseded by the admin shell.
out-of-scope§
Ledger: briefs/fg-admin-route-disposition-2026-08-09.md — 65 of 65 routes accounted for, none absent.