build_verification_plan composes input_set_id from the config blob, tool_sources blobs, policy packs, baseline, diff reference, changed-file blobs, and normalized options (core/verification_identity.py). Adapters read more than that.
Concrete case. inputs/openai_api.py reads openai_api.prompt_files. Those paths never become blobs in plan.inputs, so changing a prompt file changes what the scan sees while leaving input_set_id byte-identical. The same question applies to every framework block that names paths — anthropic.prompt_files, and the google_adk / langchain / crewai / n8n / codex_plugin / codex_config inputs.
Why it matters beyond one feature. input_set_id is the identity that verification-plan.json, verification-unit-result.json, the terminal receipt, and attestations all rest on. If it does not cover an input, then two runs that read different bytes can claim the same input set — which is exactly the claim those artifacts exist to make. It is a reproducibility gap, not only a caching one.
Found while building Stop-hook verify reuse in #297; the reuse feature was withdrawn partly because of this (see #295). Filing separately because the receipt/attestation surface is the more important consumer.
Suggested shape. Enumerate declared input paths per framework block when building VerificationInputSet, so every path an adapter is configured to read becomes a blob. A stronger variant is to capture the paths at the actual read boundary rather than deriving them from the manifest, which would also cover globbed and adapter-discovered inputs — worth considering if the manifest-derived list turns out to be hard to keep complete.
Verification. A test that changes only a prompt_files target and asserts input_set_id moves.
build_verification_plancomposesinput_set_idfrom the config blob,tool_sourcesblobs, policy packs, baseline, diff reference, changed-file blobs, and normalized options (core/verification_identity.py). Adapters read more than that.Concrete case.
inputs/openai_api.pyreadsopenai_api.prompt_files. Those paths never become blobs inplan.inputs, so changing a prompt file changes what the scan sees while leavinginput_set_idbyte-identical. The same question applies to every framework block that names paths —anthropic.prompt_files, and thegoogle_adk/langchain/crewai/n8n/codex_plugin/codex_configinputs.Why it matters beyond one feature.
input_set_idis the identity thatverification-plan.json,verification-unit-result.json, the terminal receipt, and attestations all rest on. If it does not cover an input, then two runs that read different bytes can claim the same input set — which is exactly the claim those artifacts exist to make. It is a reproducibility gap, not only a caching one.Found while building Stop-hook verify reuse in #297; the reuse feature was withdrawn partly because of this (see #295). Filing separately because the receipt/attestation surface is the more important consumer.
Suggested shape. Enumerate declared input paths per framework block when building
VerificationInputSet, so every path an adapter is configured to read becomes a blob. A stronger variant is to capture the paths at the actual read boundary rather than deriving them from the manifest, which would also cover globbed and adapter-discovered inputs — worth considering if the manifest-derived list turns out to be hard to keep complete.Verification. A test that changes only a
prompt_filestarget and assertsinput_set_idmoves.