Verification

Writing code is not the same as finishing a task. Rinari records verification evidence — which checks ran and what they returned — and the engine decides how complete the work is from that evidence, not from what the model says about it.

Evidence

Each piece of evidence is a record with a kind, a scope, the command when there is one, and a result. The kinds include:

• test, lint, typecheck and build;
• schema and custom checks;
• manual checks, when a step can only be confirmed by hand.

Before verifying, Rinari can plan what to check for the files that changed: the targeted tests, adjacent tests, the lint, type check and build commands the project uses, and escalation to the full suite when a shared file or configuration changed.

Completion states

After a turn with activity, the engine evaluates a completion gate with the most recent evidence:

State	Meaning
DONE	Implemented and reasonably verified.
IMPLEMENTED_UNVERIFIED	The implementation exists, but meaningful verification wasn’t possible.
PARTIAL	Some of the requested outcomes are incomplete.
BLOCKED	Progress needs information, access, an approval or external state that isn’t available.
FAILED	The attempted solution didn’t succeed.

The gate rejects claims the evidence doesn’t support. If the model says “tests pass” but the latest relevant test exited with an error, or claims “fixed” without passing evidence, the result is not DONE. A check that reported success while its output contains a failure, or a run where no tests actually ran, doesn’t count either.

In the app

• The Verification tab of the workspace panel shows the Latest evidence and a Suggested plan. Before anything has been checked, it says No verification evidence yet.
• In Flows, each stage shows Verification N ok · M failed, and a stage without recorded checks says so instead of claiming a result.
• The verifier subagent re-runs the named validations independently, inspects the final diff and decides the state with its evidence.

In the terminal

rinari verify            # run the verification planner
rinari verify changed    # focus on what changed
rinari verify task
rinari verify project

Keep reviewing

Verification records and completion checks expose what was tested; they don’t make generated code automatically correct. Check the diff in Changes, read the evidence, and use Checkpoints — you can preview a restore before confirming it. Checkpoints are recovery tools, not a replacement for backups.