Repo-owned evidence. Human judgment still visible.
Read the proof split before you trust the packet
This is the evidence desk. It separates what the repo already proves, what still needs human judgment, and which route the operator should take next.
Use this desk when you want the shortest honest answer to three questions: what this route proves, what it does not prove, and which route you should open next.
Best for
Evaluators and builders who need to sort repo-owned evidence before they touch the operator desk or talk about release readiness.
What it proves here
Prompt, changed files, review bundle, acceptance, feature packet structure, and the default proof target can be traced on repo-owned surfaces.
What it does not prove
It does not turn repo-local readiness into Git landing, remote deployment, or final design sign-off. Those still need a human decision.
Sort the proof into three buckets before you move.
A proof desk should separate repo-proved evidence, reviewer-owned judgment, and the next operator move instead of leaving them mixed inside one story.
Repo-proved now
Prompt, changed files, review bundle, acceptance output, and the default proof target are already visible on repo-owned surfaces.
Still needs human judgment
Shared-surface polish, design quality, and final ship confidence still belong to a reviewer even when the packet looks green.
What the operator should do next
Continue to the workbench when the evidence agrees. Mark the slice repo-local ready only when the packet, proof signal, and acceptance story still agree. Commit, push, and PR landing remain a separate operator step.
Choose the next route with the same honesty boundary
The proof desk should hand you to the next surface deliberately: operate, compare, or read deeper docs without blurring those jobs together.
Open the operator desk
Go here when the evidence agrees and you want the next repo-owned move, pause rule, and promotion action in one place.
Open the compare page
Go here when you still need to decide whether OpenUI's repo-aware proof lane is the right fit compared to hosted builders or broader agent traffic.
Open the proof FAQ
Go here when you want command-level proof semantics and repository-level boundaries before making a human review call.
Proof packet anatomy
The point is not only to say that a packet exists. The point is to show which evidence layers the packet leaves behind and how a reviewer can inspect them.
Start from a brief, not a screenshot wish.
The front door shows the same story the repo actually supports: a UI brief goes into a real workspace-aware delivery flow.
Build a pricing surface with a stronger hero, trust row, feature comparison, and review-ready acceptance notes.Generate React + shadcn output that is meant to be applied.
This is not positioned as a pure hosted builder. The real promise is generated UI that can be shaped for the repo you already own.
apps/web/app/pricing/page.tsx
apps/web/components/generated/PricingCards.tsx
apps/web/components/generated/FeatureComparison.tsxKeep changed files visible before trust goes up.
A reviewer can see which paths changed and where shared components or layout impact starts to matter.
workspace-profile.json
change-plan.json
feature-flow-plan.jsonEnd with review bundle, acceptance, and proof.
The strongest difference from a plain generator is that proof, review, and acceptance stay in the loop instead of being post-hoc guesswork.
feature-flow-review-bundle.md
feature-flow-acceptance-result.json
smoke:e2e / visual:qa / repo:doctorWhat the repo already proves and what still needs a reviewer
Use this surface to separate repo-owned proof from reviewer-owned judgment before you decide whether to continue, stop, or escalate.
Already evidenced
You can trace the brief, changed files, review bundle, acceptance result, and proof target without leaving the repo-owned surface.
Human judgment still required
Shared-surface consistency, design polish, and release confidence still belong to a reviewer even when the artifact packet is green.
Use this to choose the next move
If the evidence is coherent, continue into the workbench and record the slice as repo-local ready. If the packet disagrees with itself, stop here and escalate to manual review before any Git landing step.
What feature-level delivery now leaves behind
The product difference is not only that it runs. It is that reviewers can inspect both the feature package and each route’s local evidence.
feature-flow/<feature-slug>/
feature-flow-plan.json
feature-flow-quality.json
feature-flow-acceptance-result.json
feature-flow-review-bundle.md
routes/
01-<route-id>/
workspace-profile.json
change-plan.json
acceptance-pack.json
review-bundle.json
02-<route-id>/
workspace-profile.json
change-plan.json
acceptance-pack.json
review-bundle.jsonWhat acceptance really means here
Acceptance is the part that proves the packet is coherent enough to move, not the part that pretends every human judgment has already been replaced.
Turn the proof split into the next move
This page should help an evaluator decide whether to continue, review, or stop instead of hiding that choice inside prose.
Continue to the workbench
Do this when the evidence is coherent and you want to move the next reviewable packet through review or release. Repo-local completion comes first; Git landing comes second.
Return to the proof FAQ
Do this when you need the command-level meaning of a proof lane before making a call.
Escalate to manual review
Do this when acceptance is partial, shared-surface risk is visible, or the artifacts disagree on readiness.
Not proved here
Think of this strip like the small print on a contract. It is the part that stops the proof desk from over-claiming.