wicked-garden 12.27.0

package/skills/deliberate/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: wicked-garden-deliberate
+context: fork
+description: |
+  Critical thinking framework applied before doing work. Challenges assumptions,
+  reframes problems, identifies hidden opportunities, and validates whether the stated
+  ask is the right ask. A way of approaching work, not a specialist discipline.
+
+  Use when: challenging assumptions before implementation, reframing a stated
+  problem, or asking whether the right thing is being asked at all.
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+
+# Deliberate
+
+A structured way of thinking about work **before doing it**. Applied to any request —
+bugs, features, enhancements, content, design, infrastructure — to ensure we're solving
+the right problem the right way.
+
+## When to Use
+
+- Before accepting any work request at face value
+- During crew **clarify** and **design** phases (auto-integrated)
+- When triaging issues, tickets, or ad-hoc asks
+- Any time the gut response is "just do it" — pause and deliberate first
+
+## The Five Lenses
+
+### 1. Is This Real?
+
+Challenge the premise before solving it.
+
+- Is the reported problem actually a problem, or is it working as intended?
+- Is this a symptom or the root cause? Would fixing it just move the pain?
+- What's the evidence? Observed behavior, user feedback, or speculation?
+- What's the cost of doing nothing? Sometimes inaction is the right action.
+
+### 2. What's Actually Going On?
+
+If the problem is real, dig to the root.
+
+- Trace the issue to its origin — don't stop at the first explanation
+- Is this a design flaw wearing a different mask?
+- Map the blast radius: what else shares the same root cause?
+- Is the framing itself wrong? (e.g., "the button is broken" vs "the flow is confusing")
+
+### 3. What Else Can We Fix While We're Here?
+
+Every change is a window into the surrounding code/content/system.
+
+- Are there adjacent areas suffering from the same weakness?
+- Can we generalize instead of point-fixing?
+- Is there duplication that should be consolidated?
+- Would a structural change prevent entire categories of similar asks?
+
+See [refs/opportunity-patterns.md](refs/opportunity-patterns.md) for common patterns.
+
+### 4. Should We Rethink the Design?
+
+Step back further. Is the current approach the right one?
+
+- Would a different structure make this problem disappear entirely?
+- Are we patching around a leaky abstraction or flawed model?
+- Is the boundary in the wrong place?
+- What would we build if starting fresh with today's knowledge?
+
+See [refs/rethink-framework.md](refs/rethink-framework.md) for evaluation.
+
+### 5. Is There a Better Way?
+
+Before committing to the obvious solution, explore alternatives.
+
+- Can we solve this by **removing** instead of adding?
+- Can we solve this with configuration instead of code?
+- Is there a simpler approach that covers 90% of cases?
+- What are we trading off with each option?
+
+## Output: Deliberation Brief
+
+```markdown
+## Deliberation Brief: {title}
+
+### Assessment
+**Validity**: Real problem / Symptom / Not a problem / Wrong framing
+**Root cause**: {actual cause, not what was reported}
+**Blast radius**: {what else is affected by the same root cause}
+
+### Opportunities
+**Cleanup**: {what can be improved alongside}
+**Generalization**: {can we abstract or consolidate?}
+**Rethink**: {should we redesign the approach?}
+
+### Recommendation
+**Strategy**: Fix / Redesign / Generalize / Defer / Close
+**Rationale**: {why this approach over alternatives}
+**Scope**: Expand / Contract / Same — {what changed from original ask}
+
+### Guidance
+{specific direction for whoever does the work}
+```
+
+## Domain-Specific Depth
+
+The five lenses are universal. The refs provide depth for specific contexts:
+
+- [refs/opportunity-patterns.md](refs/opportunity-patterns.md) — Structural patterns that signal cleanup opportunities
+- [refs/rethink-framework.md](refs/rethink-framework.md) — When and how to propose a redesign
+- [refs/code-lens.md](refs/code-lens.md) — Code-specific patterns (error handling, abstractions, tech debt)
+- [refs/content-lens.md](refs/content-lens.md) — Content/docs patterns (messaging, structure, audience)
+- [refs/design-lens.md](refs/design-lens.md) — Design patterns (UX flows, information architecture)
+- [refs/architecture-lens.md](refs/architecture-lens.md) — System patterns (boundaries, dependencies, scaling)
+- [refs/data-lens.md](refs/data-lens.md) — Data patterns (pipelines, schemas, quality, contracts)
+- [refs/ops-lens.md](refs/ops-lens.md) — Ops patterns (incidents, reliability, deployment, observability)
+- [refs/security-lens.md](refs/security-lens.md) — Security patterns (auth, vulnerabilities, threat models, compliance)
+- [refs/product-lens.md](refs/product-lens.md) — Product patterns (user needs, prioritization, value, strategy)
+- [refs/testing-lens.md](refs/testing-lens.md) — Testing patterns (test strategy, flakiness, coverage, test design)
+- [refs/timing-lens.md](refs/timing-lens.md) — Timing patterns (urgency, sequencing, premature optimization)
+- [refs/assumptions-lens.md](refs/assumptions-lens.md) — Assumption patterns (hidden dependencies, fragile premises)
+
+## Integration
+
+- **Crew workflow**: Auto-invoked during clarify and design phases
+- **Standalone**: `/wicked-garden:deliberate {description or GH#}`
+- **Batch**: Process multiple issues together to find shared root causes

package/skills/deliberate/refs/architecture-lens.md

@@ -0,0 +1,37 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Architecture Lens
+
+Additional questions for the five lenses when the work involves system architecture.
+
+## Lens 1 Additions: Is This Real?
+
+- Is this a scalability problem now, or a theoretical future concern?
+- Is this an architecture issue, or an implementation issue within a sound architecture?
+- Are we solving for the current scale or a projected scale we may never reach?
+
+## Lens 2 Additions: What's Actually Going On?
+
+- Is the service boundary in the wrong place?
+- Is the coupling between components the root cause?
+- Is this a data model issue masquerading as an application issue?
+
+## Lens 3 Additions: What Else Can We Fix?
+
+- Are other service boundaries suffering from the same poor decomposition?
+- Can we introduce a shared contract that prevents integration drift?
+- Are there undocumented architectural decisions (ADRs) that should be captured?
+
+## Lens 4 Additions: Should We Rethink?
+
+- Would merging two services be simpler than fixing their interaction?
+- Would an event-driven approach replace fragile synchronous coupling?
+- Would a different data ownership model eliminate the coordination problem?
+
+## Lens 5 Additions: Better Way?
+
+- Can we solve this with a configuration change instead of code?
+- Can we solve this with a proxy/gateway instead of modifying services?
+- Can we defer the architectural change with a well-placed facade?

package/skills/deliberate/refs/assumptions-lens.md

@@ -0,0 +1,43 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Assumptions Lens
+
+Additional questions for the five lenses that surface hidden assumptions and
+fragile dependencies. Maps what we're taking for granted and what breaks if we're wrong.
+
+## Lens 1 Additions: Is This Real?
+
+- What assumption makes us believe this is a problem? Is that assumption verified?
+- Are we assuming user behavior that we haven't observed?
+- Are we assuming a dependency will remain stable (API, library, service)?
+- Are we assuming this environment/context will stay the same?
+
+## Lens 2 Additions: What's Actually Going On?
+
+- What are the implicit assumptions in the current design that led to this issue?
+- Is the problem caused by an assumption that was once true but no longer is?
+- Are we assuming cause and effect, or just correlation?
+- What would we discover if we questioned the constraint we think is fixed?
+
+## Lens 3 Additions: What Else Can We Fix?
+
+- Are there other parts of the system built on the same fragile assumption?
+- Can we make assumptions explicit — document them so they're auditable?
+- Can we add assertions or contracts that fail loudly when assumptions break?
+- Are there undocumented dependencies between components?
+
+## Lens 4 Additions: Should We Rethink?
+
+- Would designing for the assumption being WRONG be more resilient?
+- Can we eliminate the assumption entirely instead of coding around it?
+- Should we build an abstraction layer so changing this assumption later is cheap?
+- Would a different architecture have fewer hidden assumptions?
+
+## Lens 5 Additions: Better Way?
+
+- Can we validate the key assumption before building? (prototype, data check, user test)
+- Can we design for graceful degradation when assumptions fail?
+- Can we add monitoring that alerts us when an assumption is violated?
+- Can we make the dependency explicit and versioned instead of implicit?

package/skills/deliberate/refs/code-lens.md

@@ -0,0 +1,38 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Code Lens
+
+Additional questions for the five lenses when the work involves code changes.
+
+## Lens 1 Additions: Is This Real?
+
+- Is this a bug or a misunderstanding of the API contract?
+- Does the error message accurately describe the problem, or is it misleading?
+- Is the "fix" already in place but behind a flag or config?
+
+## Lens 2 Additions: What's Actually Going On?
+
+- Is the error handling the problem, not the error itself?
+- Is a race condition or timing issue masquerading as a logic bug?
+- Is the test wrong rather than the code?
+
+## Lens 3 Additions: What Else Can We Fix?
+
+- Are exception handlers swallowing errors that should propagate?
+- Is there dead code adjacent to the change that should be removed?
+- Can we add types or validation to prevent this class of bug?
+- Are there missing tests that would have caught this?
+
+## Lens 4 Additions: Should We Rethink?
+
+- Would a Result type replace scattered try/catch?
+- Would dependency injection replace the tight coupling causing the bug?
+- Would an event-driven approach replace the fragile sequential flow?
+
+## Lens 5 Additions: Better Way?
+
+- Can we use a library/stdlib function instead of custom code?
+- Can we make the compiler/type system catch this automatically?
+- Can we add a linter rule to prevent recurrence?

package/skills/deliberate/refs/content-lens.md

@@ -0,0 +1,37 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Content Lens
+
+Additional questions for the five lenses when the work involves content, docs, or copy.
+
+## Lens 1 Additions: Is This Real?
+
+- Is the content actually wrong, or is the reader's context different than expected?
+- Is this a gap in the content, or should the reader be directed elsewhere?
+- Is the complaint about accuracy, clarity, or discoverability?
+
+## Lens 2 Additions: What's Actually Going On?
+
+- Is the information correct but poorly structured?
+- Is the audience assumption wrong? (writing for experts, read by beginners)
+- Is the content stale because the source of truth changed but docs weren't updated?
+
+## Lens 3 Additions: What Else Can We Fix?
+
+- Are other docs making the same assumption about audience?
+- Is there a pattern of content going stale? Can we automate freshness checks?
+- Are related pages consistent in terminology, tone, and structure?
+
+## Lens 4 Additions: Should We Rethink?
+
+- Should this be a tutorial instead of reference docs (or vice versa)?
+- Should this content be generated from code/schema instead of hand-written?
+- Is the information architecture putting this in the wrong place?
+
+## Lens 5 Additions: Better Way?
+
+- Can we link to existing content instead of writing new?
+- Can we use a diagram instead of three paragraphs?
+- Can we add an example instead of more explanation?

package/skills/deliberate/refs/data-lens.md

@@ -0,0 +1,43 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Data Lens
+
+Additional questions for the five lenses when the work involves data pipelines,
+schemas, analytics, or data quality.
+
+## Lens 1 Additions: Is This Real?
+
+- Is the data actually wrong, or is the expectation wrong?
+- Is this a data quality issue or a schema/contract issue?
+- Is the "missing data" actually filtered out by a rule that's working correctly?
+- Are we measuring the right thing, or is the metric definition flawed?
+
+## Lens 2 Additions: What's Actually Going On?
+
+- Is the issue at ingestion, transformation, or presentation?
+- Is a schema change upstream silently breaking downstream consumers?
+- Is this a timing issue? (data not yet available vs. actually missing)
+- Is the pipeline idempotent? Could reruns have introduced duplicates?
+
+## Lens 3 Additions: What Else Can We Fix?
+
+- Are other pipelines consuming the same source with the same vulnerability?
+- Is there missing data validation at ingestion boundaries?
+- Are schema contracts documented and enforced, or assumed?
+- Can we add data quality checks that catch this class of issue automatically?
+
+## Lens 4 Additions: Should We Rethink?
+
+- Should this be a streaming pipeline instead of batch (or vice versa)?
+- Would schema evolution tooling prevent breaking changes?
+- Should the data ownership boundary move? (who produces vs. consumes)
+- Would a data contract between producer and consumer prevent this?
+
+## Lens 5 Additions: Better Way?
+
+- Can we fix the source instead of patching the consumer?
+- Can we add a dead-letter queue instead of failing silently?
+- Can we use schema registry to catch incompatibilities before deploy?
+- Can we solve this with monitoring/alerting instead of code changes?

package/skills/deliberate/refs/design-lens.md

@@ -0,0 +1,37 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Design Lens
+
+Additional questions for the five lenses when the work involves UX, UI, or design.
+
+## Lens 1 Additions: Is This Real?
+
+- Is this a usability issue or a learning curve? Would onboarding solve it?
+- Is the user's mental model wrong, or is the design misleading?
+- How many users are affected vs. how many adapted without issue?
+
+## Lens 2 Additions: What's Actually Going On?
+
+- Is the problem in this screen, or in the flow that led here?
+- Is the information hierarchy wrong? (important things not prominent)
+- Is the issue visual (styling) or structural (wrong component/pattern)?
+
+## Lens 3 Additions: What Else Can We Fix?
+
+- Do other screens have the same usability issue?
+- Is the design system missing a component this screen needs?
+- Are similar interactions inconsistent across the product?
+
+## Lens 4 Additions: Should We Rethink?
+
+- Would removing a step eliminate the confusion entirely?
+- Would progressive disclosure solve the overwhelm?
+- Should this be a different interaction pattern altogether?
+
+## Lens 5 Additions: Better Way?
+
+- Can we use a standard platform pattern users already know?
+- Can we show instead of tell? (preview, inline help, smart defaults)
+- Can we remove options instead of adding explanations?

package/skills/deliberate/refs/opportunity-patterns.md

@@ -0,0 +1,107 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Opportunity Patterns
+
+Common patterns where a single issue reveals broader improvement opportunities.
+These are domain-agnostic — they apply to code, content, design, and systems alike.
+
+## Pattern: Shotgun Surgery
+
+**Signal**: A single change requires edits in many places.
+**Opportunity**: Extract the scattered concern into a shared abstraction.
+**Examples**:
+- Code: Date formatting fix needed in 12 controllers → extract DateFormatter
+- Content: Brand voice update required across 30 pages → extract style tokens
+- Design: Color change needed in 15 components → extract design tokens
+
+## Pattern: Silent Failure
+
+**Signal**: Problem caused by something failing silently — no error, no log, no feedback.
+**Opportunity**: Audit the area for other silent failures. Add observability.
+**Examples**:
+- Code: Exception swallowed, returns None → add structured error types
+- Content: Broken link returns 200 with wrong page → add link validation
+- Design: Form submits but nothing happens → add feedback states
+
+## Pattern: Duplication
+
+**Signal**: Fix needs to be applied in multiple places with similar logic.
+**Opportunity**: Consolidate into a single source of truth.
+**Examples**:
+- Code: Validation logic copy-pasted across endpoints → extract Validator
+- Content: Same instructions written differently in 3 guides → single source
+- Design: Same component built differently in 4 views → shared component
+
+## Pattern: Missing Abstraction
+
+**Signal**: Multiple consumers implement the same multi-step process inline.
+**Opportunity**: Name the process and give it a proper interface.
+**Examples**:
+- Code: Three services each query→transform→save → extract Pipeline
+- Content: Writers each invent their own tutorial structure → extract template
+- Design: Each page builds its own nav → extract navigation pattern
+
+## Pattern: Leaky Boundary
+
+**Signal**: Consumers need internal knowledge to use something correctly.
+**Opportunity**: Redesign the interface to hide the complexity.
+**Examples**:
+- Code: Must call init() before use() → use context manager
+- Content: Reader must know jargon to understand docs → add glossary/simplify
+- Design: User must know hidden gesture to access feature → improve discoverability
+
+## Pattern: Config Drift
+
+**Signal**: Problem from inconsistent settings across environments or components.
+**Opportunity**: Centralize with validation and parity checks.
+**Examples**:
+- Code: Two services define timeouts independently → shared config
+- Content: Style guide says one thing, templates do another → sync
+- Design: Mobile and desktop use different spacing scales → unify
+
+## Pattern: Temporal Coupling
+
+**Signal**: Problem caused by doing things in the wrong order.
+**Opportunity**: Make invalid sequences impossible.
+**Examples**:
+- Code: Must call connect() before query() → auto-connect on first query
+- Content: Must read Part 1 before Part 2 but nothing says so → add prereqs
+- Design: Must complete Step A before Step B but UI allows skipping → enforce flow
+
+## Pattern: Primitive Obsession
+
+**Signal**: Problem from using generic types where domain types would prevent errors.
+**Opportunity**: Introduce named types that carry meaning.
+**Examples**:
+- Code: User ID and session ID both strings, swapped in call → typed IDs
+- Content: All metadata stored as free text → structured fields
+- Design: All buttons look the same regardless of action → semantic variants
+
+## Pattern: Feature Envy
+
+**Signal**: Something reaches deep into another area's internals to get what it needs.
+**Opportunity**: Move the logic to where the data lives, expose a proper interface.
+**Examples**:
+- Code: Report reads 5 private fields → add summary method on the owner
+- Content: FAQ duplicates info from other pages → link instead of copy
+- Design: Dashboard rebuilds data viz from raw data → expose chart-ready API
+
+## Evaluation
+
+When reviewing an issue, check which patterns apply:
+
+| Pattern | Present? | Severity (0-3) | Fix Effort | Payoff |
+|---------|----------|-----------------|------------|--------|
+| Shotgun surgery | | | | |
+| Silent failure | | | | |
+| Duplication | | | | |
+| Missing abstraction | | | | |
+| Leaky boundary | | | | |
+| Config drift | | | | |
+| Temporal coupling | | | | |
+| Primitive obsession | | | | |
+| Feature envy | | | | |
+
+**Priority**: High severity + low effort + high payoff = do it now alongside the fix.

package/skills/deliberate/refs/ops-lens.md

@@ -0,0 +1,43 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Ops Lens
+
+Additional questions for the five lenses when the work involves infrastructure,
+deployments, incidents, reliability, or operational concerns.
+
+## Lens 1 Additions: Is This Real?
+
+- Is this an actual outage/degradation, or a monitoring false positive?
+- Is this a one-time event or a recurring pattern?
+- Is the alert threshold wrong rather than the system behavior?
+- Is this impacting users, or just triggering internal noise?
+
+## Lens 2 Additions: What's Actually Going On?
+
+- Is this a capacity issue, a config issue, or a code issue?
+- Is the root cause in our system or in a dependency?
+- Is the failure domain isolated, or can it cascade?
+- Did a recent deployment, config change, or scaling event trigger this?
+
+## Lens 3 Additions: What Else Can We Fix?
+
+- Are other services vulnerable to the same failure mode?
+- Is there missing observability that made diagnosis slow?
+- Are runbooks stale or missing for this scenario?
+- Can we add circuit breakers, retries, or fallbacks for similar failures?
+
+## Lens 4 Additions: Should We Rethink?
+
+- Should this be a managed service instead of self-hosted?
+- Would a different deployment strategy (canary, blue-green) prevent blast radius?
+- Should we rearchitect for graceful degradation instead of hard failure?
+- Would chaos engineering have caught this before production?
+
+## Lens 5 Additions: Better Way?
+
+- Can we auto-remediate instead of alerting a human?
+- Can we solve this with resource limits/quotas instead of code?
+- Can we add a health check that catches this before users do?
+- Can we shift this left — catch it in CI instead of production?

package/skills/deliberate/refs/product-lens.md

@@ -0,0 +1,46 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Product Lens
+
+Additional questions for the five lenses when the work involves features, user needs,
+prioritization, or product strategy.
+
+## Lens 1 Additions: Is This Real?
+
+- Does anyone actually want this? What's the evidence of demand?
+- Is this one user's request or a pattern across many?
+- Is the pain real and frequent, or mild and rare?
+- Would users notice if we did nothing?
+- Are we building this because a stakeholder asked, or because users need it?
+
+## Lens 2 Additions: What's Actually Going On?
+
+- Is the user struggling with our product, or with the underlying problem?
+- Is the feature request actually a workaround for a missing capability?
+- Is the complaint about the feature, or about how they discovered it?
+- Are users asking for what they want, or describing what they think the solution is?
+  (What's the job-to-be-done behind the request?)
+
+## Lens 3 Additions: What Else Can We Fix?
+
+- Are there related user pain points in the same workflow?
+- Would improving onboarding/docs reduce the need for this feature?
+- Are there power-user workarounds that indicate a broader need?
+- Can we improve the existing feature instead of adding a new one?
+
+## Lens 4 Additions: Should We Rethink?
+
+- Should this be a configuration option instead of a feature?
+- Should this feature exist at all, or does it add complexity without proportional value?
+- Would simplifying the product (removing features) solve the underlying confusion?
+- Is this the right product to solve this problem, or should it be a separate tool?
+
+## Lens 5 Additions: Better Way?
+
+- Can we solve this with better defaults instead of a new setting?
+- Can we solve this with documentation/education instead of code?
+- Can we let users solve it themselves with an extension/API/integration?
+- Is there a 10% effort solution that delivers 80% of the value?
+- Can we validate the approach with a prototype before full investment?

package/skills/deliberate/refs/rethink-framework.md

@@ -0,0 +1,77 @@
+---
+phase_relevance: ["clarify", "design"]
+archetype_relevance: ["*"]
+---
+# Rethink Framework
+
+When to step back from fixing and consider redesigning. Not every issue needs a
+rethink — but every issue deserves the question.
+
+## The Rethink Test
+
+Answer these five questions. If 3+ are "yes", consider a structural change:
+
+1. **Recurrence**: Has this type of issue come up before in this area?
+2. **Complexity**: Is the fix more complex than the thing it patches?
+3. **Fragility**: Would the fix make things harder to change next time?
+4. **Workaround**: Are we working around the design rather than with it?
+5. **Regret**: If we'd known this need earlier, would we have built it differently?
+
+## Rethink Strategies
+
+### Invert the Dependency
+
+**When**: A depends on B's internals, and the problem is in the coupling.
+**How**: Have B expose what A needs. Or invert — have B call A.
+**Risk**: Touches both sides. Test carefully.
+
+### Split the Responsibility
+
+**When**: One thing does too many jobs, and the problem is in their interaction.
+**How**: Separate into distinct pieces with clear interfaces.
+**Risk**: More pieces, but each is simpler. Split along natural boundaries.
+
+### Replace Conditionals with Structure
+
+**When**: Problem in a complex if/else chain handling different cases.
+**How**: Define a base type and specialized variants. Route via registry/factory.
+**Risk**: Over-engineering if only 2-3 cases. Good when cases grow.
+
+### Make Invalid States Impossible
+
+**When**: Problem from something being in a state that shouldn't exist.
+**How**: Use types, enums, or state machines to constrain what's possible.
+**Risk**: May require interface changes. Worth it for core concepts.
+
+### Extract the Policy
+
+**When**: Rules are embedded in infrastructure.
+**How**: Pull rules into a separate, testable policy object.
+**Risk**: Adds indirection. Justified when rules change frequently.
+
+### Simplify by Removing
+
+**When**: Problem is in unused or rarely-used functionality.
+**How**: Delete it. Check usage, deprecate if needed, then remove.
+**Risk**: Low — less surface area = fewer problems.
+
+## Cost-Benefit Check
+
+Before proposing a rethink, estimate:
+
+```
+Rethink Cost  = (things touched x complexity) + (test rewrite) + (review overhead)
+Ongoing Cost  = (similar issues per quarter x fix time) + (confusion x ramp-up time)
+
+If annualized Ongoing Cost > 2x Rethink Cost → rethink now
+If Ongoing Cost < Rethink Cost → fix and document the debt
+```
+
+## Scope Control
+
+Rethinks can expand without bounds. Constrain them:
+
+1. **Time-box**: Set a maximum. If it takes longer, it's a separate project.
+2. **Blast radius cap**: Touch at most N things. If more, split into phases.
+3. **Quality parity**: New approach must have equal or better coverage before shipping.
+4. **Rollback plan**: Ensure the old approach can be restored if needed.