Assess an MDK change's blast radius

Identify material effects beyond the diff, the contracts they depend on, and the evidence needed to decide whether the change is safe. A caller inventory is a starting point, not an impact assessment.

Bound the assessment

Use the change, files, PR, or proposal the user named. For an existing branch without a narrower scope, identify its merge base with the intended target branch (master by default) and include relevant staged, unstaged, and untracked changes. Record the base/head and working-tree scope. Do not treat an unavailable or stale target ref as current without checking it. A proposal needs an explicit before/after contract; it does not need an invented patch.

Read the root and nearest AGENTS.md for affected owners. Inspect the actual implementation and relevant caller expectations, not just the PR description. Use history when the reason for a guard or compatibility path affects the assessment. Do not weaken a documented invariant to make the proposal safe.

Keep the assessment non-mutating for product code and external state unless the user also authorized implementation. Existing focused checks and isolated scratch probes may produce local evidence; they do not authorize fixes, migrations of user data, or public posting. Before a destructive, irreversible, or external-state probe, verify that the user's authorization covers the exact operation, target, and scope; general implementation authorization alone is insufficient. If that authorization is missing, obtain confirmation before executing. Preserve any stricter reviewer restrictions: a review-local seat reports a proposed executable check to the author rather than writing a probe or building in its protected checkout.

Follow the changed contract

State what changes observably, including errors, defaults, side effects, ordering, ownership, and persistence. Follow both direct consumers and the indirect readers that symbol searches miss: stored rows, serialized fields, events/subscriptions, callbacks, background workers, and another language reading the same bytes. Check the dependency version and local patch that MDK actually uses when a library contract is decisive.

Use the relevant boundaries below; do not run an exhaustive workspace audit for a small local change. An unrelated boundary needs no speculative risk.

Name affected consumers by their role and cite the actual source locations. For each material risk, describe the reachable trigger, changed behavior, and user or system consequence. State exposure conditions and uncertainty instead of inventing probability percentages. Missing external consumer access is an unknown, not proof that no consumer exists.

Check the decisive assumptions

Find the facts on which safety depends, such as "the retry retains the exact published event" or "this row is derived and startup rebuilds it before use." Do not force the assessment into one assumption when independent contracts are at risk. Prioritize the facts whose failure changes the conclusion.

For each, establish the strongest useful evidence within the task's budget:

• Read the actual implementation and specification, and trace the failure path through reachable inputs, ordering, and state. A type signature alone may not establish a runtime or persistence guarantee.
• Reuse an existing focused check when it exercises the disputed production path. Use verify-mdk for runtime selection, readiness, fidelity, evidence retention, and cleanup. Prefer a saved input or existing owner-level regression to a new duplicate test.
• Use formal-verification when the decisive question needs a model or proof. Keep bounds, fairness, and the connection to implementation explicit; a model pass does not clear every caller.
• If a new probe is useful, keep it isolated and run the actual operation, not a restatement of the algorithm. Use test-audit for changes to tests or test support. Do not modify production code solely to make the assessment runnable.

Keep execution scoped. Follow root/crate requirements when code changes require broader gates, but do not launch workspace builds, broad campaigns, benchmarks, or platform suites merely because many consumers were found. When a check cannot run, retain the reasoning and name the missing evidence.

Classify findings by evidence, separately from severity:

• Reproduced: a recorded execution at an identified revision/configuration demonstrates the failure. Give the command/input, actual result, expected result, and relevant artifacts.
• Code-supported: a concrete reachable path or a direct contract contradiction establishes the problem from source/specification. Cite the premises and trace. State that it was not reproduced; lack of a practical reproducer does not invalidate a sound correctness or security finding.
• Unresolved: a material risk depends on a fact not established yet. Name that fact and the cheapest way to settle it. Do not report a hypothesis as a confirmed defect.

A passing check clears only the failure it can observe under its actual conditions. A no-match search, compile success, timeout, skipped test, or unexercised fault does not clear a behavioral risk. Preserve known counterexamples until evidence actually resolves them.

Hand back a bounded conclusion

Lead with the behavioral change and whether the assessed scope is safe, needs changes, or remains inconclusive. Then give:

• Affected contracts/consumers and decisive assumptions, with citations.
• Findings, each with severity, evidence class, trigger, consequence, and suggested remedy. Keep code-supported defects actionable.
• Risks checked and cleared, with the evidence and its limits; unresolved gaps remain separate.
• The smallest remaining validation or design change needed before relying on the result, including checks not run and external consumers not examined.

Scale the report to the change; omit empty sections and raw tool dumps. Do not fix unrelated problems or present this assessment as independent approval. review-local owns independent reviews, and land-change owns the delivery gates and queue.

Adapted from PStack's blast-radius. The upstream copyright and permission notice are retained in PSTACK_LICENSE.md.