Fix KQVI puzzle dependency chart QA issues: remove S17 undefined node, S19/S20 dead ends, add Pearl note

src/design-process/bushy-branching.md

@@ -0,0 +1,103 @@
+# Bushy Branching
+
+## Preventing Player Stuckness Through Parallel Paths
+
+"Bushy branching" is the practice of designing multiple parallel puzzle paths so players always have alternatives when they get stuck.
+
+---
+
+## The Core Problem: Linear Lock-In
+
+In a purely linear puzzle chain:
+
+```
+A → B → C → D → E
+```
+
+If a player gets stuck on B, they cannot progress. They must:
+1. Keep trying B
+2. Consult a walkthrough
+3. Stop playing
+
+All three options create frustration.
+
+---
+
+## The Solution: Bushy Branches
+
+```
+    ┌── B1 ──┐
+A ──┼── B2 ──┼── E
+    └── B3 ──┘
+```
+
+If a player gets stuck on one branch, they can try another. The key insight is that **branches should be independent but converge at natural points**.
+
+---
+
+## Types of Branching
+
+### Horizontal Branching
+
+Multiple puzzles in the same "tier" that can be completed in any order.
+
+**Example:** Gathering three map pieces from three different locations.
+
+**Design rule:** Branches should have similar difficulty and length.
+
+### Vertical Branching
+
+Alternative solutions to the same problem.
+
+**Example:** Open a locked door with the key, or pick the lock, or find another way around.
+
+**Design rule:** Alternative solutions should be equally valid but not equally obvious.
+
+---
+
+## Balancing Branch Difficulty
+
+When using parallel branches:
+
+| Problem | Solution |
+|---------|----------|
+| One branch is too hard | Add a hint or easier sub-puzzle |
+| One branch is too easy | Add a wrinkle to extend it |
+| Branches converge too early | Delay convergence points |
+| Branches never converge | Create artificial dependencies |
+
+---
+
+## The Caged Situation Technique
+
+"A caged situation in an adventure game is an easy situation almost all the time."
+
+Start players in a restricted capability scenario, then expand their abilities through the puzzle progression.
+
+**Pattern:**
+1. Player can only do X
+2. Puzzle requires X + Y
+3. Player solves puzzle to get Y
+4. Now player has X + Y
+5. Repeat
+
+This creates natural difficulty progression and prevents early-game stuckness.
+
+---
+
+## Source Material
+
+This technique is documented in:
+- [Why Adventure Games Suck](resources/criticism/why-adventure-games-suck-ron-gilbert.md)
+- [Puzzle Design in Adventure Games - StackExchange](resources/puzzle-design/puzzle-design-adventure-games-stackexchange.md)
+
+---
+
+## Placeholder: Bushy Branching Tutorial
+
+**To be written:** A design exercise showing how to take a linear puzzle chain and add bushy branching to it, with before/after diagrams.
+
+**Key questions to answer:**
+- How many branches are enough?
+- When should branches converge?
+- How do you balance difficulty across branches?

src/design-process/dependency-charts.md

@@ -0,0 +1,122 @@
+# Puzzle Dependency Charts
+
+## The Method LucasArts Used to Design Puzzle Networks
+
+This chapter documents the puzzle dependency charting technique developed by Noah Falstein and used by Ron Gilbert and the LucasArts team to design *Monkey Island* and *Maniac Mansion*.
+
+---
+
+## What Is a Puzzle Dependency Chart?
+
+A puzzle dependency chart is a visual map showing how puzzles relate to each other—which puzzles must be completed before others, which can be done in parallel, and where bottlenecks exist.
+
+**Why it matters:** Without charting, designers create "linear chains" that trap players who get stuck. Charts reveal where to add branching.
+
+---
+
+## Chart Components
+
+### Nodes
+
+Each puzzle or sub-puzzle becomes a node in the chart.
+
+**Example:** In *Monkey Island 2*, "get map piece from Largo" is a node.
+
+### Dependencies
+
+Arrows show which puzzles require completion of others first.
+
+**Example:** "Fight LeChuck" requires "assemble voodoo doll" requires "get voodoo ingredients."
+
+### Parallel Tracks
+
+When puzzles don't depend on each other, they can be done simultaneously.
+
+**Example:** In MI2 Part 2, four map piece chains run in parallel.
+
+---
+
+## How to Create a Chart
+
+1. **List all puzzles** in your game
+2. **Identify dependencies** — what requires what
+3. **Draw nodes and arrows**
+4. **Look for bottlenecks** — single points that gate multiple paths
+5. **Add branches** to reduce bottleneck frustration
+6. **Balance difficulty** — ensure parallel paths have similar length
+
+---
+
+## Bushy vs. Linear Charts
+
+| Type | Structure | Player Experience |
+|------|-----------|------------------|
+| **Linear** | Single chain, one puzzle after another | Frustrating when stuck; no alternatives |
+| **Bushy** | Parallel branches; multiple paths | Players always have something to try |
+
+**Key insight:** "Make your branches 'bushy' by allowing players to work on simultaneous tasks." This is the #1 technique for preventing player stuck-ness.
+
+---
+
+## Quantitative Targets
+
+Based on analysis of *Monkey Island 2*:
+
+| Metric | Target |
+|--------|--------|
+| Items per puzzle chain | 9-10 |
+| Parallel chains | 3-5 |
+| Rooms per chain | Variable |
+| Characters per chain | 3-5 |
+
+These aren't rules—they're reference points from a well-balanced game.
+
+---
+
+## Tools for Charting
+
+- Pen and paper (fast, low-friction)
+- Diagramming tools (Lucidchart, draw.io)
+- Spreadsheets (for tracking item locations)
+
+The tool matters less than actually doing it.
+
+---
+
+## Common Patterns
+
+### The Hub and Spoke
+
+One central puzzle (hub) with multiple prerequisite puzzles (spokes).
+
+**When to use:** Major story beats that require preparation.
+
+### The Diamond
+
+Multiple puzzles feed into one, which feeds into multiple.
+
+**When to use:** climactic moments that summarize earlier progress.
+
+### The Grid
+
+Multiple parallel chains of equal length.
+
+**When to use:** Mid-game when you want players to choose their own path.
+
+---
+
+## Source Material
+
+This technique is documented in:
+- [The Technique LucasArts Used](resources/puzzle-design/lucasarts-puzzle-dependency-charts.md)
+- [Monkey Island 2 Puzzle Design](resources/puzzle-design/monkey-island-2-puzzle-design.md)
+
+---
+
+## Placeholder: Detailed Tutorial
+
+**To be written:** A step-by-step tutorial with a worked example, showing how to chart a small game's puzzles from start to finish.
+
+**Resources to draw from:**
+- LucasArts puzzle dependency chart images
+- Unpoint/Unclick methodology (Christopher Sacchi)

src/design-process/failure-modes.md

@@ -0,0 +1,141 @@
+# Failure Modes
+
+## The 14 Deadly Sins of Adventure Game Design
+
+Jimmy Maher (FilFre) documented 14 common ways adventure game puzzles fail. These remain the definitive catalog of adventure game anti-patterns.
+
+---
+
+## The 14 Sins
+
+### 1. Pixel Hunting
+
+Hiding essential items or actions in visually indistinguishable pixels.
+
+**Why it's bad:** Tests patience, not intelligence.
+
+**Solution:** Make interactive elements visually distinct.
+
+### 2. Guess-the-Verb
+
+Interface opacity where players must guess the specific verb the designer intended.
+
+**Why it's bad:** Punishes correct thinking with failure.
+
+**Solution:** "Reward intent" — accept equivalent actions.
+
+### 3. Unconnected Events
+
+Random events in the game world that gate progress but have no logical connection.
+
+**Why it's bad:** Breaks internal logic; players can't learn.
+
+**Solution:** Every gate should follow from established rules.
+
+### 4. Backwards Puzzles
+
+Requiring players to find a solution before encountering the problem.
+
+**Why it's bad:** Impossible to solve without outside knowledge or luck.
+
+**Solution:** Work backwards from solution (see Design Process chapter).
+
+### 5. "I Forgot to Pick It Up"
+
+Solutions requiring items the player should have collected but can't retrieve now.
+
+**Why it's bad:** Punishment for past actions player didn't know were important.
+
+**Solution:** Don't make critical items optional, or provide alternatives.
+
+### 6. Leap of Logic
+
+Missing steps in a logical chain.
+
+**Why it's bad:** Player has right idea but missing intermediate step.
+
+**Solution:** Test every chain step with playtesters.
+
+### 7. Non-Sensical Solutions
+
+Solutions that violate the game's established internal logic.
+
+**Why it's bad:** Teaches players their model of the world is worthless.
+
+**Solution:** All solutions must follow from established rules.
+
+### 8. Locked-Out Victory
+
+Dead ends where players can't complete the game without loading an earlier save.
+
+**Why it's bad:** Frustration with no recovery path.
+
+**Solution:** Design with alternative paths; add recovery mechanisms.
+
+### 9. Constant Death
+
+Punishing failure with death that doesn't teach anything.
+
+**Why it's bad:** Fear-based design creates anxiety, not engagement.
+
+**Solution:** Death should only occur with warning and learning opportunity.
+
+### 10. Inventory Clutter
+
+Too many items obscure the solution.
+
+**Why it's bad:** Players can't identify relevant items.
+
+**Solution:** Prune inventory; make solution items stand out.
+
+### 11. Dynamic Events Required But Never Seen
+
+Timing-sensitive events that players missed.
+
+**Why it's bad:** Impossible without foreknowledge or walkthrough.
+
+**Solution:** Avoid time-sensitive events, or make them repeatable.
+
+### 12. Padding
+
+Story-irrelevant puzzles that extend playtime without value.
+
+**Why it's bad:** Wastes player time; breaks narrative flow.
+
+**Solution:** Every puzzle should advance story or character.
+
+### 13. Context Clueless
+
+Unclear when something IS a puzzle vs. just scenery.
+
+**Why it's bad:** Players either ignore everything or exhaust themselves trying everything.
+
+**Solution:** Make interactive elements visually or audio distinct.
+
+### 14. Misleading Information
+
+False clues that lead players astray.
+
+**Why it's bad:** Punishes correct exploration; rewards walkthrough use.
+
+**Solution:** Clues should guide, not misdirect.
+
+---
+
+## The Unifying Principle: Testing
+
+Most sins occur because designers didn't playtest enough. A single blind playtest would reveal most of these problems.
+
+---
+
+## Source Material
+
+- [The 14 Deadly Sins of Graphic-Adventure Design](resources/criticism/14-deadly-sins-graphic-adventure-design-filfre.md)
+- [Seven Deadly Sins of Adventure Games](resources/criticism/seven-deadly-sins-adventure-games.md)
+- [10 Things I Hate About Adventure Games](resources/criticism/10-things-hate-adventure-games.md)
+
+---
+
+## Placeholder: Sin Identification Guide
+
+**To be written:** A visual checklist with screenshots from classic games showing each sin in action, and how to fix it.

src/design-process/hint-systems.md

@@ -0,0 +1,123 @@
+# Hint System Design
+
+## When and How to Help Stuck Players
+
+Every adventure game player will get stuck. Hint systems are how you help them without breaking the experience.
+
+---
+
+## The Principle: Help Without Removing Satisfaction
+
+A good hint:
+- Acknowledges the player is stuck
+- Provides just enough guidance to unstick
+- Preserves the "aha" moment
+
+A bad hint:
+- Reveals the entire solution
+- Triggers too early or too late
+- Feels like the game is insulting you
+
+---
+
+## Types of Hint Systems
+
+### 1. In-World Hint Characters
+
+A character in the game world provides hints when consulted.
+
+**Example:** Gabriel Knight 3's hint character.
+
+**Advantages:** Can be integrated into narrative; feels diegetic.
+
+**Disadvantages:** Requires dialogue writing; can feel contrived.
+
+### 2. Contextual Nudges
+
+The game detects stuckness and offers subtle prompts.
+
+**Example:** Thimbleweed Park's hint line.
+
+**Advantages:** Automatic; can calibrate to player behavior.
+
+**Disadvantages:** Requires detecting stuckness accurately.
+
+### 3. Graduated Hint Systems
+
+Multiple levels of hints, from vague to specific.
+
+**Level 1:** "Are you sure you want to do that?"
+**Level 2:** "Have you tried looking in the basement?"
+**Level 3:** "The key is in the basement, behind the barrels."
+
+**Advantages:** Respects player autonomy; lets them choose how much help.
+
+**Disadvantages:** Requires designing multiple hint levels.
+
+---
+
+## Detecting Stuckness
+
+### Quantitative Triggers
+
+- No forward progress for N seconds
+- Repeated failed attempts on same puzzle
+- Excessive exploration of same area
+
+### Qualitative Triggers
+
+- Player hasn't interacted for extended time
+- Player is revisiting areas already completed
+- Player has collected items but not tried combinations
+
+### Playtest-Derived Triggers
+
+Watch where blind testers get stuck. These become your hint triggers.
+
+---
+
+## The "Dead Air" Reduction Principle
+
+Every second a player is stuck with no feedback is a failure of design. Either:
+1. The puzzle should have given better feedback, or
+2. A hint should trigger
+
+The goal is to minimize "dead air" without removing challenge.
+
+---
+
+## Designing Good Hints
+
+### Good Hint Characteristics
+
+| Characteristic | Description |
+|----------------|-------------|
+| **Specific location** | Directs player to area |
+| **Partial information** | Narrows possibility space without revealing solution |
+| **Actionable** | Player knows what to try next |
+| **Non-spoiling** | Player still feels they solved it |
+
+### Bad Hint Characteristics
+
+| Characteristic | Why It's Bad |
+|---------------|--------------|
+| Full solution | Removes challenge entirely |
+| Wrong direction | Wastes player time |
+| Too vague | Doesn't help unstick |
+| Too early | Removes opportunity to struggle |
+
+---
+
+## Source Material
+
+- [Thimbleweed Park Preview](resources/history/thimbleweed-park-ron-gilbert-rockpapershotgun.md) — discusses hint line design
+- [Puzzle Design StackExchange](resources/puzzle-design/puzzle-design-adventure-games-stackexchange.md)
+
+---
+
+## Placeholder: Hint System Implementation Guide
+
+**To be written:** Technical guide for implementing hint systems in common adventure game engines (Ren'Py, Adventure Game Studio, custom engines), including:
+- Stuckness detection algorithms
+- Graduated hint UI design
+- Playtesting hint calibration

src/design-process/internal-logic-fairness.md

@@ -0,0 +1,79 @@
+# Internal Logic & Fairness
+
+## Why Solutions Must Follow the Rules You've Established
+
+Ron Gilbert's rule #4 states: "Arbitrary puzzles should not exist." This is the principle of internal logic—solutions must follow from rules established by the game world.
+
+---
+
+## What Is Internal Logic?
+
+Internal logic means that the game world operates by consistent rules, and puzzle solutions derive from those rules.
+
+**Good puzzle:** "You need acid to dissolve the lock. Earlier, you found a still that makes acid."
+**Bad puzzle:** "You need a rubber chicken. No explanation why."
+
+The second isn't just surprising—it's **unfair**. It teaches players that their model of the world is worthless.
+
+---
+
+## Establishing Internal Logic
+
+### The Rule Introduction Pattern
+
+1. **Introduce the rule early** — Show how the world works through a non-puzzle example
+2. **Reinforce the rule** — Let players use the rule in a simple context
+3. **Escalate** — Require the rule in a more complex puzzle
+
+**Example from *Monkey Island*:**
+1. Voodoo is established as real ( Mardi Gras masks, ghost ship)
+2. Voodoo doll principle is demonstrated (Murray)
+3. Player must apply voodoo doll to LeChuck
+
+---
+
+## The Three Types of Logic Violations
+
+### 1. Non-Sequiturs
+
+Solutions that ignore established rules.
+
+**Example:** A door requires a key, but the solution is to use a fish on it.
+
+### 2. Leap of Logic
+
+Missing steps between cause and effect.
+
+**Example:** "Use the doll on LeChuck" works, but there's no indication that voodoo affects ghosts.
+
+### 3. Retroactive Rules
+
+Rules that only exist when needed for a puzzle.
+
+**Example:** "Oh, the ghost is actually vulnerable to rubber duckies" revealed only at the climax.
+
+---
+
+## Fairness Checklist
+
+When designing a puzzle, verify:
+
+| Question | If No |
+|----------|-------|
+| Did I establish the rule earlier? | Add a demonstration scene |
+| Is the solution logical given the rule? | Redesign the solution |
+| Could a player predict this solution? | Add more hints |
+| Does the solution feel earned? | Add more buildup |
+
+---
+
+## Source Material
+
+- [14 Deadly Sins](resources/criticism/14-deadly-sins-graphic-adventure-design-filfre.md)
+- [Adventure Puzzle Design](resources/puzzle-design/adventure-puzzle-design-stanislav-costiuc.md)
+
+---
+
+## Placeholder: Internal Logic Testing Guide
+
+**To be written:** A guide for playtesters to identify internal logic violations, with a checklist and examples from classic games.

src/design-process/player-psychology.md

@@ -0,0 +1,89 @@
+# Player Psychology
+
+## The Cognitive Contract Between Designer and Player
+
+Stanislav Costiuc's most important insight: "The goal of an adventure game designer is to perform inception on its players."
+
+---
+
+## Inception vs. Extraction
+
+These are the two fundamental modes of puzzle design:
+
+### Inception (Good)
+
+The designer plants the solution in the player's mind through earlier puzzles.
+
+**Example:** Earlier, the player used a voodoo doll on Largo's henchman. Now they face LeChuck. The earlier puzzle taught the voodoo doll pattern. Player thinks: "Another voodoo doll?" — and they feel clever for realizing it.
+
+**Player experience:** "I figured it out!"
+
+### Extraction (Bad)
+
+The designer forces the player to guess random combinations.
+
+**Example:** Player faces LeChuck with no preparation. They try everything. Eventually, by accident, they use the voodoo doll. There's no connection to earlier learning.
+
+**Player experience:** "I got lucky."
+
+---
+
+## The Possibility Space
+
+Players approach puzzles with a "possibility space"—the set of actions they believe might be valid.
+
+### Good Design: Narrowed Possibility Space
+
+Good puzzles narrow the possibility space through feedback.
+
+**Example:** Player has a crowbar but no rope. "Use crowbar on grate" fails. "Use crowbar on rope" — wait, there's no rope. The failure teaches the player they need something else.
+
+### Bad Design: Expanded Possibility Space
+
+Bad puzzles expand the possibility space through confusion.
+
+**Example:** Player doesn't know if they're supposed to fight LeChuck, run away, find a weapon, talk to someone, or explore more. Every direction seems equally valid. The player is lost.
+
+---
+
+## The Cognitive Load Problem
+
+Adventure games are unique in that they combine:
+- **Narrative comprehension** — understanding the story
+- **Spatial memory** — remembering where things are
+- **Inventory management** — tracking what you have
+- **Puzzle logic** — understanding how solutions work
+
+Too much cognitive load at once overwhelms players.
+
+**Design principle:** When narrative is heavy, puzzles should be light. When puzzles are complex, narrative should be simple.
+
+---
+
+## Motivation and Agency
+
+Adventure games risk making players **passive** — watching dialogue, examining rooms, waiting for solutions.
+
+**The antidote:** Agency.
+
+- Let players make meaningful choices
+- Allow alternative solutions
+- Enable creative problem-solving
+- Reward exploration with discovery
+
+---
+
+## Source Material
+
+- [Adventure Puzzle Design - Costiuc](resources/puzzle-design/adventure-puzzle-design-stanislav-costiuc.md)
+- [Moon Logic and Divergent Thinking](resources/moon-logic/moon-logic-divergent-thinking.md)
+- [10 Things I Hate About Adventure Games](resources/criticism/10-things-hate-adventure-games.md)
+
+---
+
+## Placeholder: Cognitive Load Management Guide
+
+**To be written:** Practical techniques for managing cognitive load in adventure game puzzles, including:
+- When to add vs. remove puzzle complexity
+- How to sequence narrative and puzzle elements
+- Playtesting for cognitive overload

src/design-process/playtesting-methodology.md

@@ -0,0 +1,102 @@
+# Playtesting Methodology
+
+## Why Adventure Games Need More Testing Than Any Other Genre
+
+Jimmy Maher wrote: "Testing is vital to any other form of game, but with adventures it can mean *everything*. A terrible adventure can become a great one following just a few weeks of testing."
+
+---
+
+## Why Testing Matters More for Adventure Games
+
+Unlike action games where skill is the primary challenge, adventure games challenge **understanding**. When players get stuck, it's often because:
+
+- They didn't understand a clue
+- They missed an item
+- They formed an incorrect mental model
+- The solution violated their expectations
+
+Only playtesting reveals these gaps.
+
+---
+
+## Types of Playtests
+
+### Blind Playtest
+
+New players experience the game with no guidance.
+
+**What it reveals:** Where players naturally get stuck, what confuses them, what they try that doesn't work.
+
+### Focused Testing
+
+Testers target specific puzzles or sections.
+
+**What it reveals:** Whether specific puzzles work as intended.
+
+### Stress Testing
+
+Rapid, aggressive play — testers try to break the game.
+
+**What it reveals:** Edge cases, dead ends, sequence breaks.
+
+---
+
+## Identifying Stuck States
+
+### The "Dead Air" Signal
+
+When a player stops interacting for more than 10-15 seconds, they're likely stuck.
+
+**Design response:** This is where hint systems should trigger (see Hint System Design chapter).
+
+### The Wandering Signal
+
+When players repeatedly visit the same rooms without purpose, they lack direction.
+
+**Design response:** Sub-goals may be unclear.
+
+### The Frustration Signal
+
+When players express annoyance or start trying random actions, they've lost confidence.
+
+**Design response:** Failure feedback may be unclear or misleading.
+
+---
+
+## Iteration Patterns
+
+| Problem | Response |
+|---------|----------|
+| Players stuck on puzzle X | Add a hint, or add alternative path |
+| Players missing item Y | Add visual/audio cue, or move item |
+| Players forming wrong model | Add clarifying NPC dialogue |
+| Players bored | Remove padding, add stakes |
+
+---
+
+## Community Testing
+
+Modern indie developers use:
+- itch.io beta testers
+- Discord communities
+- Game jam feedback
+- Let's Play analysis
+
+Watch where players get stuck in videos. Where do they pause? Where do they ask questions?
+
+---
+
+## Source Material
+
+- [14 Deadly Sins](resources/criticism/14-deadly-sins-graphic-adventure-design-filfre.md) — "Testing is everything" quote
+- [Flaws of Point & Click Adventures](resources/criticism/flaws-undead-genre-point-click-adventures.md)
+
+---
+
+## Placeholder: Playtesting Protocol Template
+
+**To be written:** A downloadable/playable template for conducting adventure game playtests, including:
+- Observer checklist
+- Tester questionnaire
+- Stuck state identification guide
+- Iteration prioritization matrix

src/design-process/working-backwards.md

@@ -0,0 +1,74 @@
+# Working Backwards from Solution
+
+## The Design Technique That Prevents Backwards Puzzles
+
+One of Ron Gilbert's rules states: "Never find the solution before you face the problem." Working backwards is the technique that makes this possible.
+
+---
+
+## The Problem with Forward Design
+
+Most designers start from the beginning of the game and design puzzles as they go. This leads to:
+
+- Puzzles that make sense to the designer but not to players
+- Missing logical steps because the designer knows the solution
+- "Backwards puzzles" where players must discover something before encountering the problem
+
+---
+
+## The Solution: Work Backwards
+
+1. **Start with the climax** — What is the player's ultimate achievement?
+2. **Identify the final lock** — What single action completes the game?
+3. **Work backwards** — What key opens that lock?
+4. **Continue until you reach the starting point**
+5. **Verify forward playability** — Can a new player follow this chain?
+
+---
+
+## Why Backwards Design Works
+
+When you design from solution to problem, you naturally ensure:
+- The solution exists before the problem is encountered
+- Each step has a logical relationship to the next
+- No missing steps or leaps in logic
+
+---
+
+## Application to Puzzle Types
+
+### Sequential Construction
+
+Working backwards is natural for sequential puzzles: start with the finished product and identify each component.
+
+**Example:** A voodoo doll puzzle
+- Final: Use doll on LeChuck
+- Backwards: Need assembled doll → Need body parts → Need to find locations
+
+### Multi-Faceted Plans
+
+Work backwards from the completed plan, then identify independent branches that can run in parallel.
+
+---
+
+## Common Mistakes When Working Backwards
+
+| Mistake | Result |
+|---------|--------|
+| Skipping steps | "Leap of logic" puzzles |
+| Assuming player knowledge | Hidden requirements |
+| Not testing forward | Backwards puzzles |
+
+---
+
+## Source Material
+
+This principle underlies:
+- [Why Adventure Games Suck](resources/criticism/why-adventure-games-suck-ron-gilbert.md) (Rule #9: Avoid backwards puzzles)
+- [Sequential Construction](puzzles/sequential-construction.md)
+
+---
+
+## Placeholder: Worked Example
+
+**To be written:** Take a simple puzzle (e.g., "open locked door") and demonstrate working backwards through the design process, showing how this prevents common pitfalls.