Snapshots & edit verification

Signalint 1.2.1 retains diagnostic snapshots in the running MCP server. A response’s checkId can identify an earlier retained result—not just the most recent check.

Baseline → edit → verify

1. Call check_project and save its checkId along with the engine statuses and checked scope.
2. Make the intended edit using your normal editor or agent. Checking does not generate a patch.
3. Call after_edit_check with the changed files and the baseline ID.
4. Inspect the new check’s status, engines, and scope before interpreting delta.

{
  "files": ["src/pricing.ts"],
  "baselineCheckId": "baseline-check-id"
}

after_edit_check uses the configured file-check provider. With a retained baseline, its result includes introduced, resolved and unchanged normalized issue arrays, plus errorsIntroduced, errorsResolved, and netDelta (introduced errors minus resolved errors). Warnings appear in the arrays but not those error counters.

A scoped file result and a whole-project baseline do not have identical coverage. Issues outside the requested files can appear resolved simply because they were not included in the new result. Re-run the relevant project scope before claiming project-wide resolution.

Inspect or compare retained checks

Call get_diagnostic_snapshot:

{ "checkId": "baseline-check-id" }

It returns metadata, source (project, files or lsp), engine statuses, total, clusters, bounded remaining records and optional cache metrics. It does not return the complete normalized issues array. Use get_issue_detail for a known cluster or issue:

{ "clusterId": "cluster-id", "checkId": "baseline-check-id" }

checkId is required by get_issue_detail in 1.2.1. Missing it is an invalid-arguments refusal; there is no implicit latest-result fallback. Keep the ID with its references when checks/ingestion overlap. The old latestIssues / latestCheckId handler state has been removed.

For two already retained results, call compare_diagnostics:

{ "baselineCheckId": "baseline-check-id", "currentCheckId": "current-check-id" }

An expired or unknown ID produces a stale result. An after_edit_check with a stale baseline still runs the new check and reports a stale delta; it does not resurrect historical state.

Matching is a heuristic

The delta first matches exact issue IDs, then unmatched issues by file, rule, normalized message and severity, choosing the nearest line. Semantic matching does not include engine or column. It tolerates line shifts; it is not a proof that two diagnostics have the same underlying cause.

The delta’s nextStep is advisory. In this edition it can say “Clean check” when an empty current result came from failed/disabled engines. Always inspect engine execution and actual check status independently.

Retention and identity limits

• Default snapshot capacity: 50. Default TTL: 30 minutes.
• Snapshots are not persisted and do not survive server restart. Expired-reference markers are bounded to 200.
• IDs are content-derived, not guaranteed unique per invocation. Saving the same ID replaces that map entry.
• Stored snapshots are now deep-cloned and recursively frozen. A lookup returns a detached clone: mutating the input or a retrieved copy cannot mutate the stored record. Retrieved copies need not themselves be frozen. This is in-process data isolation, not persistence or a unique-per-run identity guarantee.

Compact-key caveat

With SIGNALINT_COMPACT=1, snapshot construction still reads normal-key totals/remaining records. Snapshot metadata can therefore omit the total and lose its flat summary while retaining normalized issues. Closed structured check schemas also omit compact aliases. Use normal keys with snapshots and validating structured clients; see payload modes.

Progress and cancellation

When the client supplies _meta.progressToken, the check path can emit monotonic progress stages 0, 60, 100 with a 50 ms rate limit. Fast stages can be skipped; these are coarse milestones, not per-engine percentages.

MCP cancellation is passed to the native check providers and engine processes. An aborted check is not deliberately converted into a clean check. This wiring does not establish equivalent cancellation/rollback behavior for every new tool, especially apply operations.

Source: snapshots.ts, delta.ts, and the check handlers.