THOTH

Verification model

Thoth's core claim is a separation most workflows blur: "a check ran and passed" is not the same as "the change is verified." A passing test suite says nothing about whether the code you just changed was exercised.

Pipeline

  • —Diff — Git working tree (staged + unstaged + untracked) vs HEAD (or --base/--staged).
  • —Impact — a TypeScript-API dependency graph maps changed files to direct and transitive dependents; changed symbols propagate to referencing symbols.
  • —Planning — verification steps are selected from trusted sources only: package.json scripts, .thoth/config.json checks, and one inferred read-only tsc --noEmit.
  • —Execution — argv without a shell, with timeouts and bounded output. The working tree is hashed before and after; a command that mutates files is reported.
  • —Report — claims are classified into verified, failed, and not verified, and a verdict is computed.

Verdicts

VerdictCondition
VERIFIEDEvery planned step passed and changed code has linked test evidence
VERIFIED WITH LIMITATIONSExecuted checks passed but some changes produced no evidence
CHECK FAILEDAny step exited non-zero or timed out
NOT VERIFIEDNo executed check produced evidence for the change
NO CHANGESEmpty diff

Honesty rules

  • —Zero tests is not a pass — a test command exiting 0 while running no tests counts as not verified.
  • —Refused scripts — anything that looks mutating (--fix, --write) or non-terminating (watch mode) is never run.
  • —Unknowns are explicit — unresolvable imports and dynamic imports appear in unknowns, never silently dropped.
  • —Blast radius is two numbers — affectedFiles is a conservative upper bound; symbolLinkedFiles is the tighter bound.
  • —--explain attaches evidence trails so every conclusion is inspectable.

Trust boundary

Thoth is not a sandbox. It executes scripts already present in your repository (or explicitly configured). If you wouldn't run the repo's scripts yourself, don't run thoth verify in it.