Verify a Claim About a Change
verify_claimValidates a structured claim about a code change by diffing baseline and changed analysis sessions, returning confirmed, refuted, or indeterminate with reason and evidence.
Instructions
Verify a structured claim about a change by diffing two analyzed sessions (baseline → changed). Supported claim types (MVP): 'no_new_api' (no types/methods were ADDED AND no method signatures changed) and 'symbol_removed_unused' (the named symbol was removed AND had no usages in the baseline's static fan-in graph). Returns a verdict of confirmed / refuted / indeterminate with a reason + evidence. NOTE THE SCOPE OF 'no_new_api': it is about ADDITIONS and SIGNATURE CHANGES, so a REMOVAL does not refute it - a change set that only deletes public API is legitimately 'confirmed'. Removals are therefore never silent: the reason states the boundary and every removal the same diff records is listed as evidence, prefixed '-'. For the removal question ask verify_claim(symbol_removed_unused), or diff_public_contract (outside the default profile's pool). Conservative in BOTH directions: what the diff cannot prove is never falsely confirmed - and never falsely refuted either, because 'was not removed' is a claim about the change that is only made once the string resolves to something this diff could report on. A name that resolves to nothing, a property/field/event/enum member (the diff models types and methods only), and the simple name of a removed type the diff had to render by its FULL name because it is ambiguous, each return 'indeterminate' naming that cause - not a confident 'was not removed'. A removed method whose only baseline callers called an interface or abstract member it implemented (find_usages' viaContract) is 'indeterminate' too: such a call ran its body only when the instance was of its type, and the reason says whether that credit was exact. Baseline and changed must be two states: the same session twice, or two sessions of one solution with an equal file-set hash and an empty diff, answers 'indeterminate' and says so. Unsupported claim types return indeterminate.
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"baselineSessionId": "<baselineSessionId>",
"changedSessionId": "<changedSessionId>",
"claimType": "<claimType>"
},
"name": "verify_claim"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | The symbol name the claim is about (required for symbol_removed_unused) - a bare name or the qualified Type.Member form, the same strings find_usages / impact_of_change / find_tests_for resolve. A removed type whose simple name is ambiguous solution-wide is recorded under its FULL name; pass that full name for it. A namespace-qualified TYPE name is accepted here even when nothing was removed - this tool resolves it against the baseline's declared type identities, which the fan-in tools (simple name only) do not, and the answer then names the simple name to carry on with. A dotted name no namespace declares stays unresolved rather than falling back to whatever type carries its last segment. | |
| claimType | Yes | Claim type: 'no_new_api' or 'symbol_removed_unused'. | |
| changedSessionId | Yes | The changed session_id (after the change). | |
| baselineSessionId | Yes | The baseline session_id (before the change). |