Production evidence
See what breaks in production and what your users live through, then turn it into a Finding the Builder can act on.
Once the Builder installed the BWorlds SDK in the app, the CLI reads three kinds of production evidence. All reads are free.
Errors first
bworlds telemetry errors storefrontHeartbeat: alive (last seen: 2026-09-07T09:41:12Z)
COUNT MESSAGE LAST SEEN SOURCE
----- ------------------------------------------------------------ -------------------- ------
38 TypeError: Cannot read properties of undefined (reading 'id') 2026-09-07T09:38:50Z window.onerror
12 Failed to fetch /api/leads: 500 2026-09-07T08:12:04Z fetchThe heartbeat line tells you whether the SDK is still reporting. The table groups errors by message: how often, how recently, and where they came from. Start with the most frequent recent one.
Then the sessions that hit it
bworlds telemetry sessions storefront --time-range 24h --has-errorsID STARTED DURATION PAGES ERRORS RAGE
------------------------------------ -------------------- ---------- ----- ------ ----
6b1e6b4e-2c3d-4e5f-8a9b-1c2d3e4f5a6b 2026-09-07T09:37:02Z 4m 12s 6 yes yes
0f8a7d6c-5b4a-4c3d-9e8f-7a6b5c4d3e2f 2026-09-07T08:11:40Z 1m 3s 2 yes -
Showing 20 of 43 sessions (use --json for full results)Open one:
bworlds telemetry sessions storefront 6b1e6b4e-2c3d-4e5f-8a9b-1c2d3e4f5a6bSession: 6b1e6b4e-2c3d-4e5f-8a9b-1c2d3e4f5a6b
Started: 2026-09-07T09:37:02Z
Ended: 2026-09-07T09:41:14Z
Duration: 4m 12s
Pages: 6
Errors: yes Rage clicks: yes
Error Events (2):
[184230ms] TypeError: Cannot read properties of undefined (reading 'id') (window.onerror)
[184260ms] Failed to fetch /api/leads: 500 (fetch)
Rage Clicks (1):
[186900ms] 7 clicks on button.checkout-submit
Console Entries (3):
[184100ms] [error] POST /api/leads 500
...A timeline like this takes a coding agent from "an error happened" to "this button, on this page, right after this request". Correlate it with the route and the code path, reproduce, then edit.
Friction without an error
Users struggle silently: a button that does nothing, a form that never confirms. Rage clicks catch that.
bworlds telemetry sessions storefront --time-range 7d --has-rage-clicksTreat the clicked element and what happened around it as a clue, and verify in the code before concluding.
Uptime
bworlds telemetry uptime storefrontStatus: up
Uptime: 99.87%
Avg Response: 412ms
Daily Rollups (7 days):
DATE UPTIME % AVG RESP MS INCIDENT
2026-09-07 100.00 398 -
2026-09-06 99.12 455 yes
...
Recent Incidents (1):
2026-09-06T02:14:00Z - 2026-09-06T02:27:00Z (780s): connection refusedNotifications for this Build
bworlds build notifications storefront --window 7This reads notifications associated with storefront only. The Build route does not expose Builder-wide or Build-less administration notifications. Filter by --workflow when you are tracing one notification workflow.
Record what you found as a Finding
When the investigation yields something durable, write it where the Builder and the next operator will see it: a Finding, with why it matters and the concrete steps.
bworlds findings create storefront \
--service-line run \
--area operations \
--severity high \
--title "Checkout fails silently when /api/leads returns 500" \
--description "Since 2026-09-06, 12 sessions hit a 500 on /api/leads. The button stays enabled and shows nothing." \
--rationale "Customers abandon checkout without knowing it failed, and nobody is alerted." \
--steps "Surface the terminal error state on the checkout button" \
--steps "Log and alert on 5xx responses from /api/leads" \
--confirmFinding 5e7d1c2b-8a9f-4e3d-b6c5-2f1a0e9d8c7b created for build "storefront".The Finding appears on the Build's Findings screen with you as reporter. Add --ai-prompt to hand the Builder a ready-made prompt for their coding tool, and --source-ref to give a recurring check a stable identifier so it never files the same Finding twice.
Follow it through its lifecycle in Shared memory.