Verify the pull request against the spec it was built from

"Done" is the least reliable word in software. An agent reports success, the PR looks plausible, and whether the spec's outcomes are actually true in the code is a question nobody re-checks. Verification closes that gap by grading the implementation against the spec, and it grades the artifact, not the story: you name the pull request, and Pathmode goes and reads the diff.

The input

Two things:

• A pull request, as a URL or owner/repo#123, readable by the workspace's GitHub connection
• The IntentSpec the work was built against, with its outcomes, constraints, edge cases, and verification checks

The flow

1. Point verification at the PR. The agent (or you) calls verify_implementation with the intent ID and the PR URL. This usually happens as the last step of an agent run, right after the PR opens.

2. Pathmode reads the diff itself. The files come from GitHub, not from the builder's memory of them. Low-signal paths like lockfiles and build output are ranked out so the grader's budget goes to code that can actually answer the question.

3. Every item gets a verdict, with citations. Each outcome, constraint, constitution rule, edge case, and verification check is graded pass or fail against what the diff shows, with reasoning that cites the code. Items the diff genuinely can't answer come back as not applicable instead of being waved through.

4. The verdict records what it rests on. Every result carries its basis. A run graded on the real diff says so; a run with no PR to read is marked as a self-report, which is context for the grader, not evidence. The distinction is kept, so a self-graded "pass" never masquerades as an inspection.

5. The result lands on the intent. The verdict is logged as an implementation note, next to the spec it graded. When it holds up, flip the status to verified.

The output

• A pass/fail per item, not a single vibes score, so you know which outcome is unproven
• Reasoning that cites the diff, so a skeptical reviewer can check the checker
• A recorded basis for the verdict: what was read, and whether it was the artifact or a self-report
• An audit trail on the intent, so "did we verify this?" has an answer six months later

Why this beats trusting the agent's summary

When the builder describes its own work and the grader grades the description, the evidence and the thing being graded have the same author. That's not verification, it's a book report. A pointer is checkable; prose is not. Reading the PR breaks the loop: the code either shows the outcome or it doesn't, and the citation says where.

Try it yourself

1. Finish an agent run that ends in a pull request
2. Have the agent call verify_implementation with the intent ID and the PR URL
3. Read the per-item verdicts and citations on the intent
4. Fix what failed, or flip the status to verified

Related

• Use case: Generate a PR description from the linked IntentSpec
• Use case: Let a coding agent correct the spec it's building from
• Playbook: The Anatomy of an Agent-Ready Spec