ai-qakit 1.0.0

package/templates/.cursor/rules/planner.mdc

@@ -0,0 +1,87 @@
+---
+description: Technical planning specialist for implementation plans and architecture
+globs:
+  - "**/*"
+---
+
+You are an expert planner with deep expertise in software architecture, system design, and technical research. Your role is to thoroughly research, analyze, and plan technical solutions that are scalable, secure, and maintainable.
+
+## Core Responsibilities
+
+### 1. Research & Analysis
+- **IMPORTANT:** You can spawn multiple `researcher` (`.cursor/rules/researcher.mdc`) agents in parallel to investigate different approaches based on the user request
+- You wait for all researcher agents to report back before proceeding with analysis
+- You use `sequential-thinking` (`.cursor/rules/sequential-thinking/sequential-thinking.mdc`) for dynamic and reflective problem-solving through a structured thinking process
+- You use `context7` MCP tools to read and understand documentation for plugins, packages, and frameworks
+- You use `gh` command to read and analyze logs from GitHub Actions, PRs, and Issues when relevant
+- When you are given a Github repository URL, use `repomix` (install if not available) bash command to generate a fresh codebase summary:
+```bash
+# usage: repomix --remote <github-repo-url>
+```
+- You can delegate to `debugger` (`.cursor/rules/debugger.mdc`) agent to find root causes of issues when needed
+
+### 2. Codebase Understanding
+- You ALWAYS read `./docs/codebase-summary.md` first to understand the project structure and current status
+- You ALWAYS read `./docs/code-standards.md` to understand coding conventions and standards
+- You analyze existing development environment, dotenv files, and configuration files
+- You study existing patterns, conventions, and architectural decisions in the codebase
+- You identify how new features should integrate with existing architecture
+
+### 3. Solution Design
+- You analyze technical trade-offs and recommend optimal solutions based on current best practices
+- You identify potential security vulnerabilities during the research phase
+- You identify performance bottlenecks and scalability concerns
+- You consider edge cases, error scenarios, and failure modes in your designs
+- You create scalable, secure, and maintainable system architectures
+- You ALWAYS follow these principles: **YANGI (You Aren't Gonna Need It), KISS (Keep It Simple, Stupid), and DRY (Don't Repeat Yourself)**
+
+### 4. Plan Creation
+- You create detailed technical implementation plans in Markdown format
+- You save plans in the `./.cursor/tasks/[task-id]/plan/` directory with descriptive filenames (e.g., `YYMMDD-feature-name-plan.md`)
+- You structure plans with clear sections:
+- **Overview**: Brief description of the feature/change
+- **Requirements**: Functional and non-functional requirements
+- **Architecture**: System design, component interactions, data flow
+- **Implementation Steps**: Detailed, numbered steps with specific instructions
+- **Files to Modify/Create/Delete**: Complete list of affected files with paths
+- **Testing Strategy**: Unit tests, integration tests, and validation approach
+- **Security Considerations**: Authentication, authorization, data protection
+- **Performance Considerations**: Optimization strategies, caching, resource usage
+- **Risks & Mitigations**: Potential issues and how to address them
+- **TODO Tasks**: Checkbox list for tracking progress
+
+### 5. Task Breakdown
+- You break down complex requirements into manageable, actionable tasks
+- You create implementation instructions that other developers and agents can follow without ambiguity
+- You list all files to be modified, created, or deleted with their full paths
+- You prioritize tasks based on dependencies, risk, and business value
+- You provide clear acceptance criteria for each task
+
+## Workflow Process
+
+1. **Initial Analysis**: Read codebase documentation and understand project context
+2. **Research Phase**: Spawn multiple researcher agents to explore different approaches
+3. **Synthesis**: Analyze all research reports and identify the optimal solution
+4. **Design Phase**: Create detailed architecture and implementation design
+5. **Plan Documentation**: Write comprehensive plan in Markdown format
+6. **Review & Refine**: Ensure plan is complete, clear, and actionable
+
+## Output Requirements
+
+- You DO NOT implement code yourself - you only create plans
+- You respond with the path to the created plan file and a summary of key recommendations
+- You ensure plans are self-contained with all necessary context for implementation
+- You include code snippets or pseudocode when it clarifies implementation details
+- You provide multiple options with clear trade-offs when appropriate
+
+## Quality Standards
+
+- Be thorough and specific in your research and planning
+- Consider long-term maintainability of proposed solutions
+- When uncertain, research more and provide multiple options
+- Ensure all security and performance concerns are addressed
+- Make plans detailed enough that a junior developer could implement them
+- Always validate your recommendations against the existing codebase patterns
+
+**Remember:** Your research and planning directly impacts the success of the implementation. The quality of your plan determines the quality of the final product. Take the time to be comprehensive and consider all aspects of the solution.
+You **DO NOT** start the implementation yourself but respond with the summary and the file path of comprehensive plan.

package/templates/.cursor/rules/problem-solving/problem-solving.mdc

@@ -0,0 +1,96 @@
+---
+description: Apply systematic problem-solving techniques for complexity spirals (simplification cascades), innovation blocks (collision-zone thinking), recurring patterns (meta-pattern recognition), assumption constraints (inversion exercise), scale uncertainty (scale game), and dispatch when stuck. Techniques derived from Microsoft Amplifier project patterns adapted for immediate application.
+globs:
+  - "**/*"
+---
+
+# Problem-Solving Techniques
+
+Systematic approaches for different types of stuck-ness. Each technique targets specific problem patterns.
+
+## When to Use
+
+Apply when encountering:
+- **Complexity spiraling** - Multiple implementations, growing special cases, excessive branching
+- **Innovation blocks** - Conventional solutions inadequate, need breakthrough thinking
+- **Recurring patterns** - Same issue across domains, reinventing solutions
+- **Assumption constraints** - Forced into "only way", can't question premise
+- **Scale uncertainty** - Production readiness unclear, edge cases unknown
+- **General stuck-ness** - Unsure which technique applies
+
+## Quick Dispatch
+
+**Match symptom to technique:**
+
+| Stuck Symptom | Technique | Reference |
+|---------------|-----------|-----------|
+| Same thing implemented 5+ ways, growing special cases | **Simplification Cascades** | `references/simplification-cascades.md` |
+| Conventional solutions inadequate, need breakthrough | **Collision-Zone Thinking** | `references/collision-zone-thinking.md` |
+| Same issue in different places, reinventing wheels | **Meta-Pattern Recognition** | `references/meta-pattern-recognition.md` |
+| Solution feels forced, "must be done this way" | **Inversion Exercise** | `references/inversion-exercise.md` |
+| Will this work at production? Edge cases unclear? | **Scale Game** | `references/scale-game.md` |
+| Unsure which technique to use | **When Stuck** | `references/when-stuck.md` |
+
+## Core Techniques
+
+### 1. Simplification Cascades
+Find one insight eliminating multiple components. "If this is true, we don't need X, Y, Z."
+
+**Key insight:** Everything is a special case of one general pattern.
+
+**Red flag:** "Just need to add one more case..." (repeating forever)
+
+### 2. Collision-Zone Thinking
+Force unrelated concepts together to discover emergent properties. "What if we treated X like Y?"
+
+**Key insight:** Revolutionary ideas from deliberate metaphor-mixing.
+
+**Red flag:** "I've tried everything in this domain"
+
+### 3. Meta-Pattern Recognition
+Spot patterns appearing in 3+ domains to find universal principles.
+
+**Key insight:** Patterns in how patterns emerge reveal reusable abstractions.
+
+**Red flag:** "This problem is unique" (probably not)
+
+### 4. Inversion Exercise
+Flip core assumptions to reveal hidden constraints. "What if the opposite were true?"
+
+**Key insight:** Valid inversions reveal context-dependence of "rules."
+
+**Red flag:** "There's only one way to do this"
+
+### 5. Scale Game
+Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths.
+
+**Key insight:** What works at one scale fails at another.
+
+**Red flag:** "Should scale fine" (without testing)
+
+## Application Process
+
+1. **Identify stuck-type** - Match symptom to technique above
+2. **Load detailed reference** - Read specific technique from `references/`
+3. **Apply systematically** - Follow technique's process
+4. **Document insights** - Record what worked/failed
+5. **Combine if needed** - Some problems need multiple techniques
+
+## Combining Techniques
+
+Powerful combinations:
+- **Simplification + Meta-pattern** - Find pattern, then simplify all instances
+- **Collision + Inversion** - Force metaphor, then invert its assumptions
+- **Scale + Simplification** - Extremes reveal what to eliminate
+- **Meta-pattern + Scale** - Universal patterns tested at extremes
+
+## References
+
+Load detailed guides as needed:
+- `references/when-stuck.md` - Dispatch flowchart and decision tree
+- `references/simplification-cascades.md` - Cascade detection and extraction
+- `references/collision-zone-thinking.md` - Metaphor collision process
+- `references/meta-pattern-recognition.md` - Pattern abstraction techniques
+- `references/inversion-exercise.md` - Assumption flipping methodology
+- `references/scale-game.md` - Extreme testing procedures
+- `references/attribution.md` - Source and adaptation notes

package/templates/.cursor/rules/problem-solving/references/attribution.md

@@ -0,0 +1,69 @@
+# Problem-Solving Skills - Attribution
+
+These skills were derived from agent patterns in the Microsoft Amplifier project.
+
+## Source Repository
+
+- **Name:** Amplifier
+- **URL:** https://github.com/microsoft/amplifier
+- **Commit:** 2adb63f858e7d760e188197c8e8d4c1ef721e2a6
+- **Date:** 2025-10-10
+
+## Skills Derived from Amplifier Agents
+
+### From insight-synthesizer agent:
+- **simplification-cascades** - Finding insights that eliminate multiple components
+- **collision-zone-thinking** - Forcing unrelated concepts together for breakthroughs
+- **meta-pattern-recognition** - Spotting patterns across 3+ domains
+- **inversion-exercise** - Flipping assumptions to reveal alternatives
+- **scale-game** - Testing at extremes to expose fundamental truths
+
+### From ambiguity-guardian agent:
+- **preserving-productive-tensions** - Preserving multiple valid approaches (in architecture skill)
+
+### From knowledge-archaeologist agent:
+- **tracing-knowledge-lineages** - Understanding how ideas evolved (in research skill)
+
+### Dispatch pattern:
+- **when-stuck** - Maps stuck-symptoms to appropriate technique
+
+## What Was Adapted
+
+The Amplifier agents are specialized long-lived agents with structured JSON output. These skills extract the core problem-solving techniques and adapt them as:
+
+- **Scannable quick-reference guides** (~60-80 lines each)
+- **Symptom-based discovery** via when_to_use descriptions
+- **Immediate application** without special tooling
+- **Composable patterns** through dispatch system
+- **Progressive disclosure** via SKILL.md + references structure
+
+## Core Insight
+
+Agent capabilities are domain-agnostic patterns. Whether packaged as "amplifier agent" or "problem-solving skill", the underlying technique is the same.
+
+We extracted the techniques and made them:
+- Portable across contexts
+- Immediately applicable
+- Token-efficient through progressive disclosure
+- Discoverable through symptom-matching
+- Combinable for complex problems
+
+## License
+
+Original Amplifier project uses MIT License. These adapted skills maintain attribution and follow the same open spirit.
+
+## Adaptation Notes
+
+**Changes from original:**
+- Converted from long-lived agent to scannable reference
+- Added symptom-based dispatch system
+- Removed JSON output requirements
+- Focused on immediate application
+- Added concrete examples
+- Structured for progressive disclosure
+
+**Preserved from original:**
+- Core problem-solving techniques
+- Recognition patterns
+- Application processes
+- Fundamental insights

package/templates/.cursor/rules/problem-solving/references/collision-zone-thinking.md

@@ -0,0 +1,79 @@
+# Collision-Zone Thinking
+
+Force unrelated concepts together to discover emergent properties. "What if we treated X like Y?"
+
+## Core Principle
+
+Revolutionary insights from deliberate metaphor-mixing. Treat X like Y and see what emerges.
+
+## When to Use
+
+| Symptom | Action |
+|---------|--------|
+| Stuck in conventional thinking | Force wild domain collision |
+| Solutions feel incremental | Need breakthrough, not optimization |
+| "Tried everything in this domain" | Import concepts from elsewhere |
+| Need innovation, not iteration | Deliberately mix unrelated ideas |
+
+## Quick Reference Collisions
+
+| Treat This | Like This | Discovers |
+|------------|-----------|-----------|
+| Code organization | DNA/genetics | Mutation testing, evolutionary algorithms |
+| Service architecture | Lego bricks | Composable microservices, plug-and-play |
+| Data management | Water flow | Streaming, data lakes, flow-based systems |
+| Request handling | Postal mail | Message queues, async processing |
+| Error handling | Circuit breakers | Fault isolation, graceful degradation |
+
+## Process
+
+1. **Pick two unrelated concepts** from different domains
+2. **Force combination** - "What if we treated [A] like [B]?"
+3. **Explore emergent properties** - What new capabilities appear?
+4. **Test boundaries** - Where does the metaphor break?
+5. **Extract insight** - What did we learn?
+
+## Detailed Example
+
+**Problem:** Complex distributed system with cascading failures
+
+**Collision:** "What if we treated services like electrical circuits?"
+
+**Emergent properties:**
+- Circuit breakers (disconnect on overload)
+- Fuses (one-time failure protection)
+- Ground faults (error isolation)
+- Load balancing (current distribution)
+- Voltage regulation (rate limiting)
+
+**Where it works:** Preventing cascade failures, fault isolation
+
+**Where it breaks:** Circuits don't have retry logic, healing mechanisms
+
+**Insight gained:** Failure isolation patterns from electrical engineering
+
+## Best Source Domains
+
+Rich domains for concept mining:
+- **Physics** - Forces, thermodynamics, relativity
+- **Biology** - Evolution, ecosystems, immune systems
+- **Economics** - Markets, incentives, game theory
+- **Psychology** - Cognition, behavior, motivation
+- **Architecture** - Structure, flow, space utilization
+
+## Red Flags
+
+You need collision-zone thinking when:
+- "I've tried everything in this domain"
+- Solutions feel incremental, not breakthrough
+- Stuck in conventional thinking
+- Need innovation, not optimization
+- "Standard approach isn't working"
+
+## Remember
+
+- Wild combinations often yield best insights
+- Test metaphor boundaries rigorously
+- Document even failed collisions (they teach)
+- Breakthrough > incremental improvement
+- Question: "What would [domain expert] do?"

package/templates/.cursor/rules/problem-solving/references/inversion-exercise.md

@@ -0,0 +1,91 @@
+# Inversion Exercise
+
+Flip core assumptions to reveal hidden constraints and alternative approaches. "What if the opposite were true?"
+
+## Core Principle
+
+**Inversion exposes hidden assumptions.** Sometimes the opposite reveals the truth.
+
+## When to Use
+
+| Symptom | Action |
+|---------|--------|
+| "There's only one way" | Flip the assumption |
+| Solution feels forced | Invert the constraints |
+| Can't articulate why necessary | Question the "must" |
+| "This is just how it's done" | Try the opposite |
+
+## Quick Reference
+
+| Normal Assumption | Inverted | What It Reveals |
+|-------------------|----------|-----------------|
+| Cache to reduce latency | Add latency to enable caching | Debouncing patterns |
+| Pull data when needed | Push data before needed | Prefetching, eager loading |
+| Handle errors when occur | Make errors impossible | Type systems, contracts |
+| Build features users want | Remove features users don't need | Simplicity >> addition |
+| Optimize for common case | Optimize for worst case | Resilience patterns |
+
+## Process
+
+1. **List core assumptions** - What "must" be true?
+2. **Invert each systematically** - "What if opposite were true?"
+3. **Explore implications** - What would we do differently?
+4. **Find valid inversions** - Which actually work somewhere?
+5. **Document insights** - What did we learn?
+
+## Detailed Example
+
+**Problem:** Users complain app is slow
+
+**Normal approach:** Make everything faster
+- Add caching
+- Optimize queries
+- Use CDN
+- Reduce bundle size
+
+**Inverted approach:** Make things intentionally slower in some places
+- **Debounce search** - Add latency → enable better results (wait for full query)
+- **Rate limit requests** - Add friction → prevent abuse, improve for others
+- **Lazy load content** - Delay loading → reduce initial load time
+- **Progressive rendering** - Show slower → perceived performance
+
+**Insight:** Strategic slowness can improve UX
+
+## Valid vs Invalid Inversions
+
+**Valid inversion example:**
+- Normal: "Store data in database"
+- Inverted: "Derive data on-demand instead of storing"
+- Valid when: Computation cheaper than storage, data changes frequently
+
+**Invalid inversion example:**
+- Normal: "Validate user input"
+- Inverted: "Trust all user input"
+- Invalid because: Security vulnerability, not context-dependent
+
+**Test validity:** Does the inversion work in ANY context? If yes, it's valid somewhere.
+
+## Common Inversions
+
+- **Eager → Lazy** (or vice versa)
+- **Push → Pull** (or vice versa)
+- **Store → Compute** (or vice versa)
+- **Optimize → Simplify** (or vice versa)
+- **Add features → Remove features** (or vice versa)
+
+## Red Flags
+
+You need inversion exercise when:
+- "There's only one way to do this"
+- Forcing solution that feels wrong
+- Can't articulate why approach is necessary
+- "This is just how it's done"
+- Stuck on unquestioned assumptions
+
+## Remember
+
+- Not all inversions work (test boundaries)
+- Valid inversions reveal context-dependence
+- Sometimes opposite is the answer
+- Question "must be" statements
+- Document both successful and failed inversions

package/templates/.cursor/rules/problem-solving/references/meta-pattern-recognition.md

@@ -0,0 +1,87 @@
+# Meta-Pattern Recognition
+
+Spot patterns appearing in 3+ domains to find universal principles.
+
+## Core Principle
+
+**Find patterns in how patterns emerge.** When the same pattern appears in 3+ domains, it's likely a universal principle worth extracting.
+
+## When to Use
+
+| Symptom | Action |
+|---------|--------|
+| Same issue in different places | Extract the abstract form |
+| Déjà vu in problem-solving | Find the universal pattern |
+| Reinventing wheels across domains | Identify the meta-pattern |
+| "Haven't we done this before?" | Yes, find and reuse it |
+
+## Quick Reference
+
+| Pattern Appears In | Abstract Form | Where Else? |
+|-------------------|---------------|-------------|
+| CPU/DB/HTTP/DNS caching | Store frequently-accessed data closer | LLM prompt caching, CDN |
+| Layering (network/storage/compute) | Separate concerns into abstraction levels | Architecture, org structure |
+| Queuing (message/task/request) | Decouple producer from consumer with buffer | Event systems, async |
+| Pooling (connection/thread/object) | Reuse expensive resources | Memory mgmt, governance |
+
+## Process
+
+1. **Spot repetition** - See same shape in 3+ places
+2. **Extract abstract form** - Describe independent of any domain
+3. **Identify variations** - How does it adapt per domain?
+4. **Check applicability** - Where else might this help?
+5. **Document pattern** - Make it reusable
+
+## Detailed Example
+
+**Pattern spotted:** Rate limiting appears in:
+- API throttling (requests per minute)
+- Traffic shaping (packets per second)
+- Circuit breakers (failures per window)
+- Admission control (concurrent connections)
+
+**Abstract form:** Bound resource consumption to prevent exhaustion
+
+**Variation points:**
+- What resource (requests, packets, failures, connections)
+- What limit (per time window, concurrent, cumulative)
+- What happens when exceeded (reject, queue, degrade)
+
+**New application:** LLM token budgets
+- Same pattern: prevent context window exhaustion
+- Resource: tokens
+- Limit: context window size
+- Action: truncate or reject
+
+## 3+ Domain Rule
+
+**Why 3 domains?**
+- 1 occurrence = coincidence
+- 2 occurrences = possible pattern
+- 3+ occurrences = likely universal
+
+**Domain independence test:**
+Can you describe the pattern without mentioning specific domains?
+
+## Red Flags
+
+Signs you're missing meta-patterns:
+- "This problem is unique" (probably not)
+- Multiple teams solving "different" problems identically
+- Reinventing wheels across domains
+- "Haven't we done something like this?" (yes, find it)
+
+## Benefits of Meta-Patterns
+
+- **Battle-tested** - Proven across multiple domains
+- **Reusable** - Apply to new situations
+- **Universal** - Domain-independent solutions
+- **Documented** - Known variations and trade-offs
+
+## Remember
+
+- 3+ domains = likely universal
+- Abstract form reveals new applications
+- Variations show adaptation points
+- Universal patterns save time
+- Document for future reuse

package/templates/.cursor/rules/problem-solving/references/scale-game.md

@@ -0,0 +1,95 @@
+# Scale Game
+
+Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths hidden at normal scales.
+
+## Core Principle
+
+**Extremes expose fundamentals.** What works at one scale fails at another.
+
+## When to Use
+
+| Symptom | Action |
+|---------|--------|
+| "Should scale fine" (without testing) | Test at extremes |
+| Uncertain about production behavior | Scale up 1000x |
+| Edge cases unclear | Test minimum and maximum |
+| Architecture validation needed | Extreme testing |
+
+## Quick Reference
+
+| Scale Dimension | Test At Extremes | What It Reveals |
+|-----------------|------------------|-----------------|
+| **Volume** | 1 item vs 1B items | Algorithmic complexity limits |
+| **Speed** | Instant vs 1 year | Async requirements, caching needs |
+| **Users** | 1 user vs 1B users | Concurrency issues, resource limits |
+| **Duration** | Milliseconds vs years | Memory leaks, state growth |
+| **Failure rate** | Never fails vs always fails | Error handling adequacy |
+
+## Process
+
+1. **Pick dimension** - What could vary extremely?
+2. **Test minimum** - What if 1000x smaller/faster/fewer?
+3. **Test maximum** - What if 1000x bigger/slower/more?
+4. **Note what breaks** - Where do limits appear?
+5. **Note what survives** - What's fundamentally sound?
+6. **Design for reality** - Use insights to validate architecture
+
+## Detailed Examples
+
+### Example 1: Error Handling
+- **Normal scale:** "Handle errors when they occur" works fine
+- **At 1B scale:** Error volume overwhelms logging, crashes system
+- **Reveals:** Need to make errors impossible (type systems) or expect them (chaos engineering)
+- **Action:** Design error handling for volume, not just occurrence
+
+### Example 2: Synchronous APIs
+- **Normal scale:** Direct function calls work, < 100ms latency
+- **At global scale:** Network latency makes synchronous unusable (200-500ms)
+- **Reveals:** Async/messaging becomes survival requirement, not optimization
+- **Action:** Design async-first from start
+
+### Example 3: In-Memory State
+- **Normal duration:** Works for hours/days in development
+- **At years:** Memory grows unbounded, eventual crash (weeks → months → years)
+- **Reveals:** Need persistence or periodic cleanup, can't rely on memory forever
+- **Action:** Design for stateless or externalized state
+
+### Example 4: Single vs Million Users
+- **Normal scale:** Session in memory works for 100 users
+- **At 1M scale:** Memory exhausted, server crashes
+- **Reveals:** Need distributed session store (Redis, database)
+- **Action:** Design for horizontal scaling from start
+
+## Both Directions Matter
+
+**Test smaller too:**
+- What if only 1 user? Does complexity make sense?
+- What if only 10 items? Is optimization premature?
+- What if instant response? What becomes unnecessary?
+
+Often reveals over-engineering or premature optimization.
+
+## Red Flags
+
+You need scale game when:
+- "It works in dev" (but will it work in production?)
+- No idea where limits are
+- "Should scale fine" (without evidence)
+- Surprised by production behavior
+- Architecture feels arbitrary
+
+## Success Metrics
+
+After scale game, you should know:
+- Where system breaks (exact limits)
+- What survives (fundamentally sound parts)
+- What needs redesign (scale-dependent)
+- Production readiness (validated architecture)
+
+## Remember
+
+- Extremes reveal fundamentals hidden at normal scales
+- What works at one scale fails at another
+- Test BOTH directions (bigger AND smaller)
+- Use insights to validate architecture early
+- Don't guess - test at extremes

package/templates/.cursor/rules/problem-solving/references/simplification-cascades.md

@@ -0,0 +1,80 @@
+# Simplification Cascades
+
+Find one insight eliminating multiple components. "If this is true, we don't need X, Y, Z."
+
+## Core Principle
+
+**Everything is a special case of...** collapses complexity dramatically.
+
+One powerful abstraction > ten clever hacks.
+
+## When to Use
+
+| Symptom | Action |
+|---------|--------|
+| Same thing implemented 5+ ways | Abstract the common pattern |
+| Growing special case list | Find the general case |
+| Complex rules with exceptions | Find rule with no exceptions |
+| Excessive config options | Find defaults working for 95% |
+
+## The Pattern
+
+**Look for:**
+- Multiple implementations of similar concepts
+- Special case handling everywhere
+- "We need to handle A, B, C, D differently..."
+- Complex rules with many exceptions
+
+**Ask:** "What if they're all the same thing underneath?"
+
+## Examples
+
+### Example 1: Stream Abstraction
+- **Before:** Separate handlers for batch/real-time/file/network data
+- **Insight:** "All inputs are streams - just different sources"
+- **After:** One stream processor, multiple stream sources
+- **Eliminated:** 4 separate implementations
+
+### Example 2: Resource Governance
+- **Before:** Session tracking, rate limiting, file validation, connection pooling (all separate)
+- **Insight:** "All are per-entity resource limits"
+- **After:** One ResourceGovernor with 4 resource types
+- **Eliminated:** 4 custom enforcement systems
+
+### Example 3: Immutability
+- **Before:** Defensive copying, locking, cache invalidation, temporal coupling
+- **Insight:** "Treat everything as immutable data + transformations"
+- **After:** Functional programming patterns
+- **Eliminated:** Entire classes of synchronization problems
+
+## Process
+
+1. **List variations** - What's implemented multiple ways?
+2. **Find essence** - What's the same underneath?
+3. **Extract abstraction** - What's the domain-independent pattern?
+4. **Test fit** - Do all cases fit cleanly?
+5. **Measure cascade** - How many things become unnecessary?
+
+## Red Flags
+
+Signs you're missing a cascade:
+- "Just need to add one more case..." (repeating forever)
+- "These are similar but different" (maybe they're the same?)
+- Refactoring feels like whack-a-mole (fix one, break another)
+- Growing configuration file
+- "Don't touch that, it's complicated" (complexity hiding pattern)
+
+## Success Metrics
+
+- **10x wins, not 10% improvements**
+- Measure in "how many things can we delete?"
+- Lines of code removed > lines added
+- Configuration options eliminated
+- Special cases unified
+
+## Remember
+
+- The pattern is usually already there, just needs recognition
+- Valid cascades feel obvious in retrospect
+- Test with "can this handle all existing cases?"
+- Document the insight for future reference