change-propagationlisted

# Change Propagation — no orphans, ever The most common failure mode is a change applied in one place and forgotten everywhere else: a half-wired feature, a UI button with no backend, dead code, a stale doc. This skill exists to make every change propagate completely. It is the operational form of principle #6. ## Fits in the pipeline - **Stage 9** (`/change-request`) — the formal change path. - **Continuous** — applies to ANY modification at any stage, not only formal change requests. ## The propagation chain (in order — never skip a link) Every add/change/delete flows through, in this order: **PRD → blueprint → code roadmap → graphify → actual code** 1. **PRD** (`prd-authoring`): re-enter at the PRD stage. Edit the full PRD — scope, the affected requirements, acceptance criteria, dependencies. Never start by editing code. 2. **Blueprint** (`platform-blueprint` / `module-architecture`): update affected NFRs, ADRs, module responsibilities, and any contract that changed. A changed contract triggers the upgrade-propagation rule for its dependents. 3. **Code roadmap** (`build-roadmap`): update the plan/milestones and the TDD/UAT/smoke/QA plans for the change. 4. **Graphify** (`codebase-knowledge-graph`): refresh the codebase knowledge graph (or the lighter fallback) so impact analysis reflects reality before touching code. 5. **Actual code**: implement, then propagate through the code itself (below). ## In-code propagation — update EVERY reference Treat the