Shared memory

Two things outlive a session on a Build. The Findings say what needs attention. The Dossier says how this Build works and what never to touch. Both live on the server, under the identity that wrote them.

Findings: the Build's to-do list

bworlds findings list storefront

ID                                    STATUS      SEVERITY  DETECTION  AUTHORITY  AREA        TITLE
5e7d1c2b-8a9f-4e3d-b6c5-2f1a0e9d8c7b  open        high      telemetry  -          operations  Checkout fails silently when /api/leads returns 500
2a41f0e9-7d6c-4b5a-9e8f-3c2d1b0a9f8e  needs_user  medium    audit      -          security    Rate limiting: confirm the Cloudflare rule covers /api/*
c09b8a7d-6e5f-4a3b-8c2d-1e0f9a8b7c6d  resolved    high      manual     workspace  security    Database is open to the public

Narrow the list instead of pulling it whole. Each flag repeats and widens its own set; two flags together narrow:

bworlds findings list storefront --status open --status in_progress --severity critical
bworlds findings list storefront --detection audit --stage launch

--status takes open, needs_user, in_progress, resolved, dismissed. --stage takes launch, run, improve. --detection takes audit, manual, telemetry. --authority takes bworlds, workspace, and keeps the Findings recorded under that authority; the AUTHORITY column is a dash for a Finding no person recorded. --severity takes critical, high, medium, low.

This list carries every detection. Until BWorlds switches telemetry Findings on, the Builder's Finding lists leave out Telemetry-detected Findings, so your list can be longer than theirs; the command says how many when it is. Each Finding still opens on its own page, so send the link rather than pasting the fix.

Open one Finding and fix it

bworlds findings show storefront 5e7d1c2b-8a9f-4e3d-b6c5-2f1a0e9d8c7b

findings show prints what the Finding is, why it matters, and every fix step. Most Findings also carry a ready-made fix prompt. findings prompt writes that prompt alone on standard output, so it pipes into a coding agent with nothing to parse:

bworlds findings prompt storefront 5e7d1c2b-8a9f-4e3d-b6c5-2f1a0e9d8c7b | claude -p

After the fix ships, ask BWorlds to recheck an Audit Finding. You name the Finding; BWorlds selects its Control or its recorded exploratory claim:

bworlds findings verify storefront FINDING_ID

auditOrigin.kind distinguishes control from exploration. A Control recheck costs its registered price. An exploration recheck bills actual usage, including inconclusive results, and returns purpose: verify_discovery. The CLI displays pricing before starting; --confirm is optional. Its verificationStatus is resolved, confirmed, inconclusive, or error. Only resolved verifies the fix; confirmed means the problem remains. No Control result changes.

An Audit Finding stays open when verification is refused or inconclusive. Restore the required evidence and verify again. A manual or telemetry Finding has no Audit verification contract; close those Findings on your own evidence with findings update-status.

Move a Finding as work happens. The reason you give becomes part of its history in the app:

bworlds findings update-status storefront 5e7d1c2b-8a9f-4e3d-b6c5-2f1a0e9d8c7b in_progress \
  --reason "Fix in review on branch fix/checkout-errors" \
  --confirm

bworlds findings update-status storefront 5e7d1c2b-8a9f-4e3d-b6c5-2f1a0e9d8c7b resolved \
  --reason "Shipped in 2f8a1c0, verified in production" \
  --confirm

Use needs_user when only the Builder can move it forward, and say what you need from them:

bworlds findings update-status storefront 2a41f0e9-7d6c-4b5a-9e8f-3c2d1b0a9f8e needs_user \
  --decision-summary "Confirm whether the Cloudflare rate-limit rule also covers /api/webhooks" \
  --confirm

Dismiss an open or needs_user Finding that does not apply, Audit Findings included. It records the same Dismissal as the app's Dismiss action, attributed to your identity:

bworlds findings dismiss storefront 2a41f0e9-7d6c-4b5a-9e8f-3c2d1b0a9f8e --confirm

Statuses are open, needs_user, in_progress, resolved, and dismissed. Their meaning is in the Product model. Creating a Finding is covered in Production evidence.

Edit content and inspect attributed activity through the same Build-scoped surface:

bworlds findings edit storefront 5e7d1c2b-8a9f-4e3d-b6c5-2f1a0e9d8c7b \
  --severity medium \
  --confirm
bworlds findings history storefront 5e7d1c2b-8a9f-4e3d-b6c5-2f1a0e9d8c7b

Both commands resolve the Finding inside the named Build. A direct Finding ID never grants access outside the Build's Workspace.

Dossier: context and guardrails

bworlds dossier pull storefront

Workspace: /Users/lea/.local/share/bworlds/prod/storefront
Pulled context (4812 bytes, updated 2026-09-02T16:40:11Z by maxime)
Pulled guardrails (1290 bytes, updated 2026-09-02T16:40:11Z by maxime)

Read context.md and guardrails.md before changing anything, and have your agent read them too. When nobody has written a Dossier yet, the pull succeeds with a notice. That is the normal state of a fresh Build.

Edit the files, then publish:

bworlds dossier push storefront --confirm

Pushed context (5104 bytes)
Pushed guardrails (1290 bytes)

What keeps the Dossier trustworthy:

• Pull at the start of a session, push right after you edit. The server is the source of truth and the last push wins. Attribution shows who overwrote what.
• The workspace is outside every clone. Nothing from the Dossier goes into the Builder's repository.
• context.md holds how the app works and what matters to its Builder. guardrails.md holds what never to touch and what to check before shipping.