# 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](/docs/concepts/#kill-switch).