Skip to main content

​
Tutorial: Ops exception board

Outcome: external numbers land in the app on a schedule; the system flags exceptions; humans review and resolve them. Domain swap: same shape as ops dashboards and watch queues. Use your own CSV or API; keep the tutorial domain generic. Keep alerts as resolvable work items, not only chart annotations.

​
Step 1 | Prompt in Build mode

Stay in Build mode and send:
Build an operations exception board. Roles: operator and manager. Operators upload a weekly CSV of metrics (entity id, period, and a few numeric columns). The app stores the batch, computes simple rollups, and creates alerts when a row crosses configurable thresholds. Failed import rows must surface clearly (count and reason), not fail silently. Operators work an alert queue: acknowledge, resolve with a required note, or escalate. Resolved items leave the open queue and appear in history. Managers see a digest of open high-severity alerts on weekday mornings. That digest must be safe to retry without sending the same message twice. Threshold configuration is role-gated (document who can edit it). Optional later: pull from an external API using secrets stored as environment variables, never pasted in chat. No public unauthenticated API.

​
Step 2 | Review the plan by journeys

Approve when these journeys look right:
  1. Import: operator uploads a small sample CSV → metrics appear → open alerts are created for threshold crossings.
  2. Review: operator resolves an alert with a note; it leaves the open queue and shows in history.
  3. Manager digest: weekday morning summary of open high-severity alerts, visible under Executions when run.
  4. Config: thresholds are editable only by the roles you intended.
Alerts must be rows people can resolve, not only marks on a chart. Adjust the brief if a journey is missing, then approve.

​
Step 3 | Preview, Access, and Executions

Select a project so Preview uses real project data.
  1. Preview as operator: import a sample CSV, confirm open exceptions on the board, resolve one with a note.
  2. Confirm failed rows (if any) show count and reason.
  3. Run the manager digest (Run Now if available) and confirm under Executions. Retry should not duplicate sends.
  4. Open App Blueprint → Access: threshold config and manager views match the story. Re-check with Preview as.
If you later connect an external API, store secrets as environment variables, never in chat. Re-run Access before inviting the wider team.

​
Step 4 | Soft launch

Invite operators and managers under End-Users. Confirm they land in the portal, not Build mode. Then follow Launch checklist.

​
How to verify (checklist)

  • Import or seed creates open exceptions on the board
  • Preview as operator: resolve with a note; item leaves the open queue
  • Manager digest Run Now succeeds under Executions without duplicate sends on retry
  • Threshold config is role-gated as intended