Set up a verified mission for high-risk work

For auth, billing, database migrations, or anything security-sensitive, a single ship verdict is not enough. Run the change as a mission: a builder implements it, an independent reviewer challenges it, and your repo's own checks run before the result is accepted. The output is a diff plus an Evidence Pack, not just a diff.

When to use a mission instead of an inline change

Use a mission when a mistake is expensive or hard to reverse: authentication and authorization, payments and billing, schema/data migrations, secret handling, or anything touching a critical hub. For routine edits, the inline verify loop is enough.

Create and run one

openthunder mission create      # describe the goal
openthunder mission list        # see your missions
openthunder mission run <id>    # build → review → verify

The reviewer is independent from the builder by design , the point is an adversarial check, not a rubber stamp. When it finishes, inspect the evidence and the report:

openthunder mission verify <id>   # check the evidence requirements held
openthunder mission report <id>   # the mission report

A failed proof is a hard block: the change is not accepted just because a diff was produced.

From your editor or agent

Let the router pick the models

When you create missions programmatically, omit the builder/reviewer fields and the router picks from available providers by task. To force a specific model, set the builder explicitly. OpenThunder is provider-neutral; agents are interchangeable and governed, never silently bundled.