Fix Deep Tier Sampling & Finding Accuracy
The deep tier's proportional sampler produces a depth-biased sample that systematically over-represents shallow files (config, types, barrel exports) and under-represents application code (API routes, services, domain logic). This bias causes the API validation finding to produce misleading results on real customer repos — "1/1 sampled API routes have no input validation" on Dub (which has 139 API routes, 76 with validation imports), "12/12" on Formbricks (which has 96 routes, 30+ with direct validation). The error-boundaries finding has the same sample-dependency problem. And the import convention classifier has a separate bug that misclassifies alias imports, producing wrong results for any project with multiple tsconfig path aliases.
Pipeline timeline
Intent to proven code in 1h 21m across Think, Plan, Build, and Verify.
Assertion ledger
21 claims, each independently verified. Showing 8 — show all →
| ID | Says | Matcher | |
|---|---|---|---|
| A001 | The validation rule finds all API routes in a project, not just sampled ones | verified | ok |
| A002 | Routes with validation library imports are correctly detected as validated | verified | ok |
| A003 | Both App Router and Pages Router API routes are discovered | verified | ok |
| A004 | Small projects with few API routes get info severity at most, not warn | verified | ok |
| A005 | Projects with no API routes produce no validation finding | verified | ok |
| A006 | The validation finding title shows actual counts instead of saying sampled | verified | ok |
| A007 | Partially validated projects include a limitation note about wrapper-based validation | verified | ok |
| A008 | Routes importing schema or validate path patterns count as validated | verified | ok |