Files
Open_Ultra_SAST/.kiro/specs/zero-with-a-reason
Marius CiepluchandClaude Opus 5 bffadd5741 docs(zero-with-a-reason): the instrument must prove it can read its input
Four instrument failures in one day, all the same shape: the input was
unreadable and the tool reported a plausible zero. file_exists() false, parser
writes nothing, frontend exits 0, and "0 dropped, 5,703-byte graph" reads
exactly like success.

  * a docker php shim not mounting ~/.cache -- twice, hours apart, the second
    time after I had already diagnosed the first
  * a measurement harness whose script path did not resolve from its cwd,
    which printed 0.5s and `rows=?` where a JVM takes 15s just to start
  * a container that could not follow the symlinks in the tree it was given

The rule that catches all four is one line and runs before the work: make the
tool open one input and fail loudly if it cannot. Every mechanism in this brief
so far checks the OUTPUT; this checks that the input arrived.

Also records that nothing compiles the CPG queries. A signature change to
rowsFor shipped with 850 tests passing and broke every query at runtime -- found
by a measurement failing, not by CI. The canary already proposed here covers it,
since a query that cannot compile cannot entail the canary.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01T7XD7x5KonMdmGRkp63EQG
2026-09-10 11:28:56 +02:00
..