---
name: feedback-summary-before-changes
description: "Standing rule: present a summary of issues found + proposed fixes BEFORE editing any code, and wait for approval"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: b5dc3603-f990-4b73-8fd0-cd0db278aa10
  modified: 2026-07-26T10:37:21.887Z
---

Always lead with a **summary of the issues found and the proposed fixes** *before* making any code changes — put it at the front end of the work, not after. Then let Shane approve before editing.

**Why:** Shane's words — "this whole session could get unapproved if you missed anything." A pile of already-applied edits is all-or-nothing to review; a plan up front lets him veto or redirect individual items cheaply, and catches the case where I've mis-diagnosed before the diff exists. This matters most on shared/core files (e.g. the two [[evolution_two_accounting_files]] GL posters) where a change reaches every tenant.

**How to apply:**
- Diagnose first, then write up: one line per issue (root cause + blast radius) and the specific fix proposed for each, plus anything that is data/config for Shane to run vs. code for me to change.
- Flag behaviour changes to shared paths explicitly, with the tenant blast radius measured (survey prod, don't guess) — see [[prod_mysql_access]].
- Use `EnterPlanMode`/ExitPlanMode for anything multi-file, so approval is an explicit gate rather than a hope.
- Then implement. Related: [[feature_release_docs_policy]] still applies at the end (release notes + docs page).