module-propagationlisted

# Module: Change Propagation — the Mirror Sites Gates Miss **Loaded by:** `planning-architect` · `implementing-architect` · `code-review-architect` · `debugging-architect` · `deployment-architect` · `maintenance-architect` · `security-architect`. Read it when a run reaches a change of the shapes below; do not restate its content in a skill file. **Why this exists:** a green pipeline is **not** proof a change fully landed. Each protocol below covers sites the automated gates structurally cannot reach. They trigger on the **shape** of the change, not on the project. > Every concrete example here is an **illustration of a category**, not a rule. Substitute what exists in the project you are in. Categories are what survive; a catalogue of last month's field names is what rots. --- ## When each protocol fires | Protocol | Fires when the change… | |---|---| | **A — Shared data shape** | renames, removes, retypes, or restructures a shared field (object↔array, string↔object); changes an enum value; moves a numeric bound | | **B — Public API & test doubles** | adds, renames, removes, or re-signs a method on a service, module, or class's public surface | | **C — External origins & configuration** | makes the app load a new external origin (tiles, an API host, a font, an image CDN, a third-party script), or depends on new runtime configuration | More than one can apply to a single change. If none apply, say so in one line rather than omitting the section. ## The three moments it