Here is a file from a real, well-known open-source repository:

pages/api/stripe/webhook.ts

If you grep a codebase and find that file, you will conclude the app handles Stripe webhooks. Your coding agent will conclude the same thing, faster, and with more confidence.

Here is the entire handler:

export default function handler(_req: NextApiRequest, res: NextApiResponse) {

  res.status(404).json({ message: "Billing webhooks are not available in community edition" });

}

It does nothing. The feature lives in a paid edition. The file name makes a claim the code does not keep.

I found this while testing my own tool against Cal.com, and it changed what I was building.

DevTime started as a local-first CLI that scans a repository and explains it from evidence. As of v0.4.0, it has become something more specific: a verification layer. You state a claim about the repository, and DevTime tells you whether the code can actually back it.

The Idea: Claims, Not Vibes

A claim is a statement about a repository. "Billing webhooks verify signatures." "Authentication uses JWT access tokens."

Most tools answer these questions with pattern matching and confidence. DevTime answers with a status and receipts:

pipx install devtime-ei

cd your-repo

dtc init

dtc scan

dtc verify billing-webhook-signature

Billing Webhook Signature Verification

Claim: Incoming billing webhooks verify the provider's signature.

Status: SUPPORTED



Why:

  - Signature verification behavior evidence was found.

  - A test exercises signature behavior.



Supporting evidence:

  - src/billing/stripe-webhook.ts  [strong]

      Verifies the provider's webhook signature.

  - tests/stripe-signature.test.ts  [moderate]

      Test exercises webhook signature behavior.

Four possible statuses:

• 
  SUPPORTED - required behavior evidence exists in the current scan


• 
  WEAK - the surface exists, but the proving evidence is missing


• 
  CONTRADICTED - credible evidence conflicts with the claim


• 
  UNKNOWN - no relevant surface found, or coverage cannot responsibly decide

Statuses mean "per the evidence rules", never formal proof. The tool says so itself.

Contradictions Show Both Sides, Always

Back to that stub file. Run the same claim against a repo where the handler is a 404 stub:

Status: CONTRADICTED



Contradictions:

  - The billing webhook endpoint cannot verify signatures

    because it is a disabled stub.

      claimed:  pages/api/stripe/webhook.ts is named and routed

                as a billing webhook endpoint.

      observed: The handler's only behavior is a 404/501 response.

No vague "authentication may be inconsistent" warnings. A contradiction names what claimed the behavior, what the code actually does, and the exact paths. You can go check.

There is a second detector for the classic case: documentation says JWT, but the only JWT usage in the code is invitation tokens, not access tokens. Both sides, exact files.

One rule I care about a lot: absence is not a contradiction. Documentation with no matching code is WEAK, missing evidence. CONTRADICTED requires positive conflicting evidence on both sides. A tool that cries contradiction on every gap would be noise within a week.

Truth and Freshness Are Separate Axes

A claim you verified last month is not the same as a claim that still holds.

Every verification stores fingerprints of its evidence files. When any of them changes, the claim goes stale, and DevTime names the file:

billing-webhook-signature

  last status: SUPPORTED   freshness: STALE

    changed since verification: src/billing/stripe-webhook.ts

Only evidence files count. You can rewrite the rest of the repo and nothing flags. That restraint is deliberate: staleness alerts that fire on every commit train people to ignore staleness alerts.

The diff review picks this up too:

dtc risk --diff

Claim impact:

  - billing-webhook-signature (previous status: SUPPORTED)

      changed evidence: src/billing/stripe-webhook.ts

      re-verify: dtc verify billing-webhook-signature

Your diff does not just touch files. It destabilizes specific verified claims, and now the review says which ones.

Why This Matters More With Agents

Coding agents read file names and README statements, then act on them with full confidence. The stub webhook above is exactly the kind of thing an agent gets wrong: it would "know" the repo handles Stripe webhooks, and build on payment logic that does not exist in that edition.

DevTime ships a read-only MCP server, so agents can ask instead of guess:

pipx install "devtime-ei[mcp]"

claude mcp add devtime -- dtc mcp start

The agent gets four tools, including this one:

verify_claim -> status, why, supporting evidence, contradictions,

                missing evidence, coverage limitations

Local stdio only. No network listener. No source code returned. And no LLM anywhere in the truth path: verification is deterministic and rule-driven, so the same repo state always produces the same answer.

What It Is Not

Honesty section, because the tool is built on one:

• It is a heuristic scanner. Evidence comes from static patterns, not execution.


• Two built-in claims so far (billing webhook signatures, JWT authentication). User-defined claims are deliberately postponed until the built-in ones prove trustworthy on real repositories.


• Statuses are evidence policy, not security certification.


• Strongest on TypeScript/Next.js/Express/FastAPI-style repos. Coverage limits are documented, and the tool prints its own blind spots during scans.

Every wrong output can become a regression fixture. That is the deal I offer: if DevTime says something your repository cannot back up, that report makes the tool permanently better.

Try It

pipx install devtime-ei

dtc demo init

cd devtime-demo-saas

dtc init

dtc scan

dtc verify

The demo repo ships in the package, so you can see SUPPORTED and then break it yourself and watch the status flip.

Links

pipx install devtime-ei

dtc demo init

cd devtime-demo-saas

dtc init

dtc scan

dtc concepts

dtc explain "Billing Webhooks"

git

• PyPI: https://pypi.org/project/devtime-ei/
  


• The verification model in full: https://github.com/Shakargy/devtime/blob/main/VERIFICATION.md
  


• Release notes: https://github.com/Shakargy/devtime/releases
  

If you run it on a repo and it claims something your code cannot prove, open an issue. That is exactly the feedback I am looking for!