rejectedLocal evidence
Starboard
A plausible incremental token scanner passed focused correctness but ran slower, so CodeVetter rejected it and restored the original code.
Availability: Uses the current local Vitest performance path.
Largest tested catalog
5.3% slower
47.496 → 50.026 ms/op
Peak RSS
0.6% lower
did not offset the speed regression
Allocation evidence
Incomplete
collection bound exceeded
Tested boundary
- Flow
- src/__tests__/project-recommendations-performance.test.ts — project recommendations scale across local catalog sizes
- Source
- src/lib/project-recommendations.ts:101
- Revision
- 7af23ce31ac10c7c552713f92985934de116abee
Decision path
- observedTokenization appeared in the CPU profile10.8% of CPU samples pointed at meaningfulTokens.
- testedIncremental regular-expression scanThe one-file experiment stayed within the change-cost budget and passed focused correctness.
- rejectedSlower and too noisy to trustThe candidate was slower, sample spread was high, allocation evidence was incomplete, and the source was restored.
Patch cost
1 file · +12 / -7 · 19 gross · net 5 · 0 dependencies
Correctness: 13 focused tests passed before performance rejected the candidate.
What this does not prove
- Wall-time sample spreads were 86.332% and 91.255%, so host or startup noise may dominate.
- The candidate was slower at the largest input and heap evidence was incomplete; no optimization claim is made.
- No production, cloud, deployment, package installation, paid model, or secret operation was used.