[FEATURE] Evidence-bound response commit gate: bind assertions to verification events, target, phase, and continuation

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Preflight Checklist

• [x] I searched existing issues for response-commit gates, fact-check gates, verification actions, and evidence binding.
• [x] This is a single feature request.
• [x] This extends rather than duplicates #65982, which was auto-closed as stale.

Problem Statement

#65982 proposed an important primitive: before Claude commits a factual state/environment assertion, require evidence that a verification action actually occurred.

That is necessary, but it is not sufficient.

The existence of a prior tool_use does not prove that the evidence produced by that tool belongs to the assertion being committed.

For example:

verification tool ran        ✅
tool result exists           ✅
assistant assertion exists   ✅

but:

wrong target                 ❌
stale execution              ❌
wrong phase                  ❌
different continuation       ❌
misrouted tool result        ❌

A response can therefore be "verified" structurally while still being unsupported by the evidence that actually belongs to the current execution.

The stronger invariant is:

A measured assertion may be committed only when it is bound to valid evidence for the exact target, execution continuation, and relevant phase.

This matters increasingly in agentic workflows where Claude reads files, runs tests, performs shell operations, resumes tasks, recovers from interruptions, and takes side-effecting actions.

Why "a tool ran" is too weak

Consider:

1. Read config A
2. Context changes / execution continues
3. Operate on config B
4. Assert: "config B contains X"

A session-level ledger may truthfully say that a Read happened.

But it does not establish that the read is evidence for config B.

Likewise:

test run #41 -> PASS

code changes

test run #42 never occurs

assistant: "tests pass"

Evidence exists, but it belongs to the wrong state of the trajectory.

There are also related failure classes already visible in this tracker:

• tool results appearing to bleed across unrelated Bash executions (#85156)
• fabricated user instructions followed by real side effects (#85215)
• earlier discussion in #65982 around tool_use_id ↔ tool_result correlation

All of these point toward the same missing abstraction:

evidence must be bound, not merely present.