git:20260718.7cc9d66 to git:20260718.206351f

11 added, 8 removed. Audit A to A.

---

name: changes-explain

- description: Explain a pull request, commit range, branch, or local diff from a system-design perspective. Use when readers need practical understanding of changed behavior, boundaries, data flow, ownership, operations, risks, and verification without a line-by-line code walkthrough.

+ description: Explain a pull request, commit range, branch, or local diff from a system-design perspective. Use for practical understanding of changed behavior, boundaries, flow, ownership, operations, risks, and verification rather than defect review.

---

# Explain Changes

- Translate a code change into its system effects without inventing intent.

+ Translate a confirmed code comparison into system effects without inventing intent or exposing sensitive content.

## Workflow

- 1. Confirm the comparison scope and read the diff, full changed files, relevant surrounding code, tests, configuration, and any linked brief or issue available in scope.

- 2. Group related edits by changed behavior or responsibility rather than enumerating files mechanically.

- 3. For each meaningful group, explain the previous and new behavior, affected boundary or owner, data and control flow, external interactions, and user, developer, runtime, or operational effect.

- 4. Describe failure modes, compatibility implications, rollout or CI effects, verification, and unresolved risks where they materially changed.

- 5. Distinguish documented intent from inference. Do not claim why a change was made unless the request, issue, tests, or repository evidence supports it.

+ 1. Confirm the comparison scope; stop or qualify the explanation when it cannot be isolated.

+ 2. Read the diff, full changed files, relevant surrounding code, tests, configuration, and linked in-scope brief.

+ 3. Group edits by changed behavior or responsibility rather than file mechanics.

+ 4. Explain previous and new behavior, affected owner or boundary, data and control flow, external interactions, and user, developer, runtime, or operational effects.

+ 5. Describe materially changed failure, compatibility, rollout, CI, verification, and residual-risk behavior.

+ 6. Distinguish observed evidence, documented intent, and inference.

- Lead with a concise system-level summary, then explain meaningful change groups in dependency or execution order. Omit syntax trivia, unchanged context, and empty report sections.

+ Keep the task read-only. Redact secrets and sensitive diff content. Use `code-review` for defect findings and `rollout-readiness-review` for operational-readiness judgment.

+ Finish when every material change group is explained and evidence limitations are stated. Omit syntax trivia and empty sections.