Review regression risk after a change

• Change summary: What changed, why it changed, and which behavior, API, schema, configuration, dependency, integration, or runtime area may be affected.
• Changed files or excerpts: The relevant code, configuration, schema, API contract, dependency, integration, or runtime-behavior excerpts needed to assess regression risk.

Run a regression-risk review for the supplied change.

TASK:
Identify behavior, interfaces, flows, dependencies, contracts, configuration, and adjacent paths that may regress because of the supplied change.

SCOPE:
Assess regression risk caused by the supplied change.
Separate direct impact from adjacent impact.
Use existing tests only as optional supporting evidence.
Do not perform a test coverage review.

EVIDENCE RULES:
Base findings only on the supplied materials.
Do not invent architecture, dependencies, runtime behavior, logs, coverage, test results, defects, or pass/fail status.
If the supplied change is not specific enough to assess risk, write INSUFFICIENT_EVIDENCE.

RISK LENSES:
- changed behavior
- directly affected interfaces
- adjacent flows
- contracts / schemas / API boundaries
- dependency and integration points
- shared state
- configuration or runtime behavior
- backward compatibility
- authorization or permission boundaries
- error handling
- data shape or validation

OUTPUT:
A) Change snapshot
B) Directly affected behavior
C) Potentially affected adjacent behavior
D) Regression-sensitive paths
E) Interface / contract / dependency risks
F) Risk-prioritized verification focus areas
G) Missing evidence
H) Out-of-scope requests
I) Confidence

FORBIDDEN:
- do not claim test coverage unless test evidence is supplied

MATERIALS:
"""
Replace this block with:
- change summary
- changed files or excerpts
- affected modules, APIs, schemas, configuration, or runtime settings, if available
- dependency or integration context, if available
- known production constraints, if available
- existing tests, only as supporting evidence, if supplied
"""