Checking a repair

trialone verify compares a new recording with an earlier diagnosis, without a model call. It reports the outcome per finding. A quieter symptom does not count as repaired while the same finding remains.

$ trialone diagnose ./before.mcap --json$ trialone verify <diagnosis.json> ./after-repair.mcap

The verdict is pass (exit code 0), fail (1) or inconclusive (2). A new candidate that is not certain makes the verdict inconclusive, never a pass.

A pass means the supplied follow-up meets these checks. Use a fresh recording of the triggering task under comparable conditions. A short quiet interval or a different task is not evidence that an intermittent failure has been removed everywhere.

Measure both the same way

Use the same --healthy reference and the same --max-false-alarm rate you diagnosed with. Otherwise a finding can appear or vanish because the bar moved, not because the machine changed.

Crashes

A crash does not repeat inside one log. Pass a folder with the logs of several runs of the scenario that triggered it, one log per run; each counts as one repetition.

From the website

On an issue, Check repair on lets you describe the applied change and request a follow-up on a robot. Its watcher must be connected and its recordings folder configured. Run the triggering task with your recorder active. The check waits up to 24 hours for evidence and reports missing setup or inconclusive results; you can cancel a waiting request.

Automatic deployment confirmation currently covers supported native Linux executables with a supplied build identity and observable scenario activity. Other deployment types may need manual evidence and remain unverified by this mechanism. The job does not deploy code, start a recorder or move the robot. See Coding agents for the connected workflow.