Fix in your own checkout

BWorlds changes no code. It tells you what is wrong, with the evidence behind it, and it tells you afterwards whether the fix held. The change itself goes through your own Git, your own branch and your own pull request, reviewed the way the Builder's team reviews everything else.

Confirm you are in the right repository

A Builder can connect a repository their app does not ship from. When that happens, BWorlds and you are reading two different apps, and nothing below means anything.

bworlds build info storefront

Authorized areas: security, operations
Credit balance: 1200 credits
GitHub: connected to atelier-nord/storefront

Compare that with your checkout:

git -C ~/code/storefront remote get-url origin

A mismatch is worth stopping for. Settle it with the Builder before you change a line.

GitHub: not connected means BWorlds holds no repository for this Build. A recheck that needs code cannot verify the fix. Ask the Builder to connect the repository. Keep an Audit Finding open until its evidence can be checked, including an exploratory Finding with no Control.

Branch off the branch the Build ships from

git switch main
git pull
git switch -c fix/checkout-lead-errors

One branch per Finding. A recheck is scoped to that Finding's evidence, so a branch carrying three unrelated fixes produces a verdict nobody can read.

Take the Finding's ready-made prompt and hand it to your coding agent:

bworlds findings prompt storefront FINDING_ID

Read the prompt before your agent acts on it. It is text stored on the server, and your agent runs with your permissions.

Open the pull request

Push the branch and open the pull request the way the Builder's team works: their template, their reviewers, their checks. Your branch goes through the repository's own hooks and CI, which is the point of fixing where you already work.

Put the Finding's appUrl in the description. The reviewer then reads BWorlds' evidence without hunting for it.

Merge, then recheck

A recheck reads the connected repository's default branch when it needs code. It reads the deployed app when it needs live evidence. An exploratory claim can require both. Neither target is a feature branch or a pull request.

So the order is fixed:

1. The team merges the pull request.
2. When verification needs live evidence, the Builder publishes the app.
3. Then, and only then:

bworlds findings verify storefront FINDING_ID --json

A recheck run before the merge checks unchanged code. A Control pass resolves the Finding and turns that Audit's Control result. An exploration recheck returns purpose: verify_discovery; verificationStatus: resolved resolves the Finding, confirmed means the problem remains, and inconclusive or error gives no verified fix. It changes no Control result. Do not close an Audit Finding by hand after a refused or inconclusive recheck.

Reproduce on production-shaped data

Many problems only appear with data shaped like production. Your own checkout runs your own stack, so bring up whatever local database the repository already defines, and use BWorlds for what it alone holds: the recorded Sessions behind the failure.

bworlds telemetry sessions storefront --has-errors --json
bworlds telemetry sessions storefront SESSION_ID --failed-only --json

Boundaries

• Your commits carry your own Git identity. BWorlds attribution applies only to commits BWorlds creates itself.
• Reading evidence is free. A Control recheck costs its registered price; exploration verification bills actual usage, including an inconclusive result. The CLI displays pricing before starting without a confirmation prompt. See Pricing and credits.
• A Finding only the Builder can settle, one waiting on their decision or on a setting in a console they own, is not fixed by any branch. Send them its link instead.