Report Gallery
Ruhroh reports let a reader move from an aggregate number to the runs, reviewer decisions, transcripts, workspaces, and blockers behind it. Start with the sample result, then follow the question you want answered.
These reports make the inspect and compare stages of loop engineering visible, so the next improvement can be based on evidence from the last run.
Featured proof
One task, two runs, one incomplete conclusion
The same example connector attempts the newsletter task twice. One run delivers three stories and passes. The other delivers one story and fails with a goal mismatch.
The requested newsletter outcome was delivered.
The page exists, but required content is missing.
Only 2 of 5 runs exist, a reviewer warning remains, and one run merits review.
Open the comparisonInspect the review queueSee the claim status
Follow A Question
| What you need to know | Open this report | What it shows |
|---|---|---|
| Did one run deliver the outcome? | Single-run report | Verdict, reviewer result, implementation timeline, commands, criteria, and saved evidence. |
| Did the reviewer support the score? | Evaluation evidence report | Missing evidence, criteria coverage, commands, confidence, and judge details. |
| What needs a person to inspect? | Review queue | Required and recommended review items with reasons and evidence links. |
| What changes across repeated runs? | Compare report | Pass rates, uncertainty, failure modes, usage, cohort warnings, review state, and source runs. |
| Can the conclusion be cited? | Claim index | Publishability, blockers, suite identity, run counts, evidence coverage, and packet links. |
Understand The Whole Loop
The workflow guide shows how a project moves from the credential-free fixture through task authoring, reviewer calibration, run planning, comparison, and publication readiness. Each stage stays open until the evidence required for that stage exists.
Use it when you need the next action. Use the reports above when you need to understand a particular result or blocker.
Inspect A Portable Packet
publish-check --bundle packages the claim, summary, reports, manifest, and hashed source evidence so another person can inspect the result without the original working directory.
| Packet view | Purpose |
|---|---|
| Comparison | Review the aggregate result, cohorts, warnings, and source-run links. |
| Evaluation evidence | Check whether reviewer judgments contain enough support. |
| Review queue | Resolve the human-review items that remain in the packet. |
| Manifest | Verify the packet inventory and versioned contract. |
The packet remains blocked for the same reasons as the source comparison. A portable packet makes the evidence durable; it does not make weak evidence publishable.
How To Read Surprising Results
- Start with the compare matrix and identify the task-agent group that looks surprising.
- Open its saved result and check the final outcome, failure bucket, and unmet criteria.
- Inspect the journey, transcript, commands, and workspace evidence.
- Check evaluator-quality warnings and the human-review queue.
- Decide whether the issue belongs to the agent, prompt, connector, task, reviewer, or execution environment before changing the next run.
See Evidence Files for the underlying artifacts and Publish Claims for publication requirements.
Maintainer: regenerate the gallery
Read Report Sample Routing before changing links to generated HTML reports. The .html extension, deployment base, and native-navigation behavior are all part of the link contract.
After a report contract changes:
pnpm build
pnpm run docs:samples
pnpm run docs:samples:check