dream-state（梦境）

Dream State

"In REM sleep, the brain replays experiences but scrambles the connections — combining memories that were never together in waking life. Most combinations are nonsense. Some are breakthroughs. This is how problems get solved while you sleep."

What It Does

You've tried every approach you can think of. You've read the docs, searched Stack Overflow, asked colleagues. The solution space feels exhausted. You're *stuck* — not because the problem is unsolvable, but because your solution search is trapped in a local optimum.

Dream State breaks you out by applying cross-domain transfer: taking solution patterns from biology, physics, music theory, economics, urban planning, game theory, and other fields — then rigorously mapping them onto your technical problem.

This isn't random brainstorming. It's structured analogy. The most powerful engineering breakthroughs in history came from cross-domain transfer:

• TCP congestion control came from studying *highway traffic flow*
• Garbage collection came from *reference counting in library science*
• PageRank came from *academic citation networks*
• Neural networks came from (simplified) *neurobiology*
• Agile methodology came from *lean manufacturing* (Toyota Production System)

The Twelve Domain Lenses

Each lens is a different domain's fundamental problem-solving pattern, mapped to software:

1. Biology: Immune System

Pattern: Don't predict threats — remember them. Develop antibodies from exposure.

Best for: Error handling, resilience patterns, adaptive systems, chaos engineering.

2. Music Theory: Counterpoint

Pattern: Two independent melodies that sound good together because they follow harmonic rules, not because they're the same.

Best for: Microservice coordination, event-driven architectures, concurrent systems, API design.

3. Urban Planning: Desire Paths

Pattern: Don't decide where people should walk — pave where they already walk.

Best for: UX design, API design, feature prioritization, infrastructure decisions.

4. Game Theory: Nash Equilibrium

Pattern: What happens when multiple independent actors each optimize for themselves?

Best for: Multi-tenant systems, resource allocation, caching strategies, API design incentives.

5. Fluid Dynamics: Flow & Turbulence

Pattern: Smooth flow (laminar) is efficient but fragile. Turbulent flow is chaotic but robust.

Best for: Load balancing, queue management, rate limiting, autoscaling, stream processing.

6. Ecology: Succession

Pattern: Ecosystems don't mature all at once — pioneer species prepare the ground for later species.

Best for: Migration strategies, technical debt management, dependency selection, system maturation.

7. Thermodynamics: Entropy

Pattern: Systems naturally tend toward disorder. Maintaining order requires constant energy input.

Best for: Technical debt strategy, refactoring decisions, system lifecycle planning.

8. Cartography: Map Projections

Pattern: Every map distorts reality. The question is which distortion is acceptable for your use case.

Best for: Data modeling, abstraction design, API versioning, documentation strategy.

9. Epidemiology: Contagion

Pattern: Things spread through networks. The structure of the network determines the spread.

Best for: Failure cascade prevention, dependency risk, deployment strategy, incident response.

10. Linguistics: Grammar

Pattern: Infinite sentences from finite rules. The power is in the composition rules, not the vocabulary.

Best for: DSL design, API design, plugin architectures, protocol design.

11. Martial Arts: Judo

Pattern: Don't oppose force — redirect it. Use the attacker's energy against them.

Best for: Constraint-based problem solving, error handling philosophy, performance optimization, simplification.

12. Mycology: Fungal Networks

Pattern: Mushrooms are the visible tip. The real organism is an underground network connecting entire forests.

Best for: Event-driven architecture, distributed systems, data pipeline design, infrastructure design.

The Dream Process

INPUT: A problem statement + what approaches have already been tried

Phase 1: PROBLEM DECOMPOSITION
├── Strip the problem to its structural essence
├── Identify: What type of problem is this?
│   ├── Distribution problem (where to put things)
│   ├── Flow problem (how things move)
│   ├── Coordination problem (how things synchronize)
│   ├── Evolution problem (how things change over time)
│   ├── Scaling problem (how things grow)
│   └── Boundary problem (how things interact across interfaces)
└── Express the problem without any software-specific terminology

Phase 2: DOMAIN SCANNING
├── Select the 3 most structurally similar domains
├── For each domain, identify the analogous problem and its known solutions
├── Map domain solution → software solution
└── Evaluate: Does the analogy hold? Where does it break?

Phase 3: SYNTHESIS
├── For each viable mapping, generate a concrete technical approach
├── Evaluate against the tried-and-failed approaches (must be genuinely different)
├── Rank by: novelty × feasibility × elegance
└── Present top 3 with full domain reasoning

Phase 4: REALITY CHECK
├── For each approach, identify where the analogy breaks
├── What assumptions from the source domain don't hold in software?
├── What constraints exist in software that don't exist in the source domain?
└── Adjusted recommendation with analogy limits clearly stated

OUTPUT: 3 novel approaches with domain reasoning, feasibility, and known limits

Output Format

╔══════════════════════════════════════════════════════════════╗
║                   DREAM STATE ACTIVATED                     ║
║     Problem: "Rate limiting that adapts to traffic shape"   ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║  Previously tried: Fixed window, sliding window, token       ║
║  bucket, leaky bucket — all too rigid or too permissive.     ║
║                                                              ║
║  APPROACH 1: Immune System (Biology)                         ║
║  ├── Instead of fixed limits, let the system develop         ║
║  │   "antibodies" for specific traffic patterns               ║
║  ├── Normal traffic → no resistance                          ║
║  ├── Anomalous burst → generate pattern-specific limit       ║
║  ├── Future similar burst → instant recognition & response   ║
║  ├── Feasibility: ★★★★ (pattern DB + signature matching)    ║
║  └── Analogy breaks: Immune systems have false positives     ║
║      (autoimmune). Need manual override for legitimate spikes║
║                                                              ║
║  APPROACH 2: Fluid Dynamics (Physics)                        ║
║  ├── Model request flow as fluid through a pipe              ║
║  ├── Calculate Reynolds number (traffic-to-capacity ratio)   ║
║  ├── Below threshold → laminar (pass all)                    ║
║  ├── Above threshold → turbulent (shaped, not blocked)       ║
║  ├── Feasibility: ★★★★★ (simple math, well-understood)      ║
║  └── Analogy breaks: Real fluids are homogeneous. Requests   ║
║      have different priorities. Need weighted flow.          ║
║                                                              ║
║  APPROACH 3: Traffic Calming (Urban Planning)                ║
║  ├── Don't block traffic — slow it down selectively          ║
║  ├── "Speed bumps": Add latency to deprioritized requests    ║
║  ├── "Roundabouts": Queue → batch → process in turns         ║
║  ├── "One-way streets": Time-based directional throughput    ║
║  ├── Feasibility: ★★★ (UX impact needs careful tuning)      ║
║  └── Analogy breaks: Cars can't be duplicated. Requests can. ║
║      Retry storms could amplify instead of calm.             ║
║                                                              ║
║  RECOMMENDED: Approach 2 (Fluid Dynamics model) with         ║
║  weighted flow from Approach 3 (priority lanes).             ║
╚══════════════════════════════════════════════════════════════╝

When to Invoke

• When you've tried every "standard" solution and none fits
• When the problem feels like it shouldn't be this hard (it's probably the wrong frame)
• When two requirements seem fundamentally contradictory
• During design sessions when the team is stuck in convergent thinking
• When you need to explain a complex system to non-technical stakeholders (domain analogies bridge the gap)

Why It Matters

The solution to your problem has probably already been solved — just not in software. Biology has spent 3.8 billion years solving distribution, coordination, resilience, and scaling problems. Physics has universal laws for flow, pressure, and equilibrium. Music has centuries of theory about how independent voices harmonize.

Dream State doesn't invent solutions. It *translates* them.

Zero external dependencies. Zero API calls. Pure cross-domain reasoning.