--- name: feedback-design-overhaul-unit-scope description: "When a task message and its build-plan doc imply different scope, ask rather than guess — the owner favours the tightest reading" metadata: node_type: memory type: feedback originSessionId: 545706c4-7ca3-40c5-a791-8f8d8ff7907f --- **Closed as a unit-tracking record** — the Design Overhaul program it tracked is finished. The principle below is the reason to keep this file. **The principle:** when a session's task message and the build plan's own narrative for that unit could imply different scope, **ask before implementing** rather than picking the broader reading. The owner has consistently favoured the narrowest, most literal reading of "what does THIS unit's name mean", even where the plan prose could support either. **Confirmed twice on the same unit:** first via an explicit question at the start of the session (chrome+nav only vs chrome+nav+full subsystem redesign — owner picked chrome+nav only), then again unprompted after it shipped, in sharper terms: *"SHELL ONLY... do NOT dress any subsystem's content... Keep it that tight."* **Why:** the owner wants each unit's diff small and auditable — a "shell" unit should ship literally only the shell. Pulling a later unit's scope forward muddies the audit that the narrow units exist to de-risk, one bet at a time.