#Monitoring

The operating question is simple: did the version we publish reach people safely? Start with weir app-status --appRoot .. It joins the current manifest with funnel and health reads for every configured flow — a read-only summary and the fastest single check.

#What the dashboard can change

The dashboard is no longer inspection-only. Publish/rollback and the experiment lifecycle moved into it (PLAN.md M6): the flow workspace exposes publish and rollback for a released config, and the Experiments view exposes Start, Stop, and Decide actions (the live experiment view shows real Stop and Decide buttons). Those buttons invoke the same gated paths the agent surface uses — weir_release's build → conform → publish sequence, and the experiment lifecycle's pre-registration → fixed-horizon → decide sequence — so a dashboard action and an agent action go through one identical, auditable path, not two un-gated ones.

What stays out of the dashboard is flow authoring: composing or editing screen JSON, branches, and variables remains repository-owned and agent-first (there is no visual builder). The dashboard operates the lifecycle of a flow you already authored through the agent surface; it does not let a person draw a new screen. If a remote flow is unhealthy, the kill switch (weir_onboarding_enabled in Firebase Remote Config) remains the revert path that does not depend on Weir's own infrastructure being reachable.

#Control room

The dashboard (packages/dashboard) is organized as a Home landing page plus a four-item nav — Home, Experiments, Apps, and the current app's Flows workspace. Funnel, health, events, and release views live inside the flow workspace (including its publish/rollback actions); experiment detail (arms, traffic, results, SRM, Start/Stop/Decide) lives inside Experiments. Every view renders the same read tools listed below or the same write actions described above — there is no dashboard-only data path. The deployed dashboard at the public URL may lag this information architecture until the pending Firebase redeploy lands; the source in packages/dashboard is the source of truth.

#The read tools underneath

• weir app-status --appRoot . — joins the currently published manifest with funnel and health reads for every flow declared in weir/app.json. The fastest single command to answer "is the flow I just shipped actually live and healthy."
• weir funnel --flowId <id> — step-through funnel: starts, per-screen drop-off, completion rate, time-to-paywall.
• weir health --flowId <id> — reliability: crash-free flow-session rate, render time percentiles, native-call error rate, fallback count (how often the app fell back to nativeFallback or the embedded baseline instead of the intended config).
• weir events --flowId <id> — a recent raw event trace, for when the aggregated funnel/health views aren't enough to explain a specific drop.

#Three checks after a release

1. weir app-status --appRoot . — confirm the expected bundle id/spec version is published.
2. weir funnel --flowId onboarding — check starts, screen progression, and completion.
3. weir health --flowId onboarding — check fallback count, render latency, native-call errors, and queue flushes.

If a remote flow is unhealthy, turn off weir_onboarding_enabled in Remote Config. That returns to native onboarding without depending on Weir's delivery origin being reachable at all — see Concepts → Kill switch.