Connect modeled operations to finding predicates before excluding standing findings

[pengfei-threemoonslab]

Found during #557/#606 implementation and independent review. Deferred from this implementation pass as requested; this issue isolates the remaining operation/predicate relationship, rather than extending the Boolean model and implying it can already exclude a finding.

Problem

A complete comparison of a named source function is not yet attribution of an action-policy finding. #599 compares a first imported Boolean guard; #606 additionally compares every return in a closed Boolean function and its literal source Agent membership. Both deliberately retain incomplete capability dependency coverage and prohibit finding exclusion.

The existing policy checks ask a different question. checks/policy.py emits missing approval/confirmation findings from the capability effect and declared policy. core/capability_policy.py builds predicate support from semantic claim IDs and evidence eligibility. A caller-controlled approved: bool, a true return, an unchanged support hash, and an opaque external call do not establish the operation, resource, approver or policy relationship.

The concrete counterexamples in #606 show why this join cannot be inferred: a narrowed first guard can accompany a wider whole-function true-return domain; unchanged returns can accompany newly added source Agent membership. An actual external operation adds further argument/resource/configuration dependencies that the finite Boolean profile intentionally refuses.

Required implementation

Choose a bounded real operation in an existing supported reader and specify what the reader can establish from source, what requires an existing reviewed declaration, and what remains unknown. Preserve the exact operation/call identity, argument/resource/configuration dependencies and relevant binding provenance. Join that evidence through the canonical capability reference to the existing finding's specific predicates and claim IDs.

Define comparison semantics per predicate. A narrower Boolean domain is not a generic permission reduction, and a guard named approved is not human approval. Unsupported operation semantics, missing dependencies or ambiguous subjects must remain unresolved. No effect/authority/binding declaration may be synthesized to make the fixture pass.

Acceptance

• A real paired fixture links an existing action-policy finding to a named operation and its relevant base/head predicate dependencies, with source and claim provenance.
• Standing weakness, strict improvement, newly widened operation/resource and new reachability are distinguished only where the operation/predicate contract supports that inference.
• A caller-controlled approval Boolean, an unknown terminal call, configuration indirection, conflicting declarations, missing base evidence and ambiguous canonical subjects cannot yield exclusion eligibility.
• Reconstructed base and head evidence bind the same operation/profile identity and actual dependency bytes; a supplied report or equal hash is not proof.
• Scope the verdict to the diff by default, with an opt-in whole-tree mode #515 receives typed attribution with explicit unresolved cases. Default/gate changes remain in Scope the verdict to the diff by default, with an opt-in whole-tree mode #515 and still require Fixed-history release regression: establish reviewed scope for refused monorepo cases #563/benchmark: re-run the labeled corpus on the v0.18 candidate and compare with W27 #312's independently reviewed historical evidence.

Boundaries

#557 continues to own reader dependency-coverage proof. This issue owns the missing relationship from a modeled operation to a particular finding predicate; it is not another CLI scope switch or a general Python execution engine. #515 owns decision consumption and scope/receipt compatibility. An SDK-only demonstration does not satisfy #515's named TypeScript MongoDB cal-1 acceptance case. No release bar or current gate is weakened by deferring this work.

Refs #557, #515, #563, #312, #572.