Complete: Remaining restructure tasks - design notes, cross-reference index, worksheet, FAQ

- Add Design Process Notes to 5 puzzle taxonomy overviews
- Create cross-reference-index.md mapping 28 games to puzzle types
- Create quick-start-worksheet.md with design checklist and templates
- Create comprehensive FAQ with 10 common design questions answered

src/puzzles/cognitive-transfer-overview.md

@@ -49,3 +49,19 @@ Cognitive transfer puzzles differ from other categories by their emphasis:
 **Insufficient Transfer Distance**: If the application context looks identical to the learning context, players don't experience cognitive transfer—they recognize surface similarity rather than rule abstraction.
 
 **Hidden Learning Opportunities**: Players must have clear opportunities to learn the system before being asked to apply it. No tutorial means no fair transfer.
+
+## Design Process Notes
+
+**Failure Modes to Avoid:**
+- Creating "aha moments" that depend on pixel hunting rather than reasoning about learned rules
+- Making the learning phase too short or too long relative to the transfer challenge
+- Allowing players to brute-force the transfer through trial-and-error instead of applying the rule
+
+**Playtesting Focus:**
+- Do players articulate what rule they learned, or just stumble into the solution?
+- Is the transfer distance calibrated—visible enough to be fair, hidden enough to feel earned?
+- Do players recognize the learned system applies before or after encountering the transfer context?
+
+**Connection to Design Process:**
+- See [working-backwards.md](../design-process/working-backwards.md) for designing cognitive transfer puzzles from the solution backward
+- See [failure-modes.md](../design-process/failure-modes.md) for the dependency chart anti-pattern where transfer feels arbitrary

src/puzzles/non-standard-domains-overview.md

@@ -23,3 +23,19 @@ Non-Standard Logic Domains focuses on **physics-breaking actions within gameplay
 | Player Action | Use banana peel + floor = slip gag as intentional solution | Deliver absurd lie that NPCs accept based on personality |
 
 The former requires abandoning real-world physics; the latter requires understanding fictional character psychology. Both use humor, but in fundamentally different layers of interaction.
+
+## Design Process Notes
+
+**Failure Modes to Avoid:**
+- Breaking internal consistency—absurd solutions must follow the cartoon logic's own rules
+- Relying on "it's funny so it works" without establishing the comedic premise as mechanically valid
+- Making the absurdity random rather than rooted in genre conventions players recognize
+
+**Playtesting Focus:**
+- Do players accept the impossible premise as valid before attempting solutions?
+- Can players articulate why a solution works within the cartoon logic framework?
+- Does the comedy emerge from rule exploitation or from random nonsense?
+
+**Connection to Design Process:**
+- See [internal-logic-fairness.md](../design-process/internal-logic-fairness.md) for maintaining consistency even when violating physics
+- See [failure-modes.md](../design-process/failure-modes.md) for "false absurdity" where players can't distinguish valid from invalid solutions

src/puzzles/npc-interaction-overview.md

@@ -24,3 +24,19 @@ The core distinction: solutions require reading NPC motivations, exploiting pers
 - NPC has internal state that dialogue or observed behavior can modify
 - Multiple approaches exist because the character responds differently based on player strategy
 - Understanding the character's rules matters more than finding the "correct" answer
+
+## Design Process Notes
+
+**Failure Modes to Avoid:**
+- Making NPC behavior inconsistent so players can't develop reliable strategies
+- Having personality traits that are flavor-only with no mechanical impact on outcomes
+- Designing one "correct" dialogue path that works regardless of observed NPC behavior
+
+**Playtesting Focus:**
+- Do players discover the NPC's mechanical rules through observation and experimentation?
+- Can players predict how the NPC will respond to unfamiliar approaches?
+- Do players feel their social strategy succeeded due to understanding, not luck?
+
+**Connection to Design Process:**
+- See [player-psychology.md](../design-process/player-psychology.md) for understanding what makes NPCs feel like systems worth mastering
+- See [internal-logic-fairness.md](../design-process/internal-logic-fairness.md) for ensuring NPC behavior follows discoverable rules

src/puzzles/spatial-temporal-coordination-overview.md

@@ -40,3 +40,19 @@ Urgency framed narratively rather than through UI timers, requiring the player t
 - **MI2** (Cross-Temporal): Time-travel puzzle where future actions enable past discoveries
 - **KQVI** (Cross-Realm): Transferring objects between human world and faerie dimension with different physics
 - **Curse of Monkey Island** (Multi-Character): Coordinating Guybrush and the Elysian Fields' residents simultaneously
+
+## Design Process Notes
+
+**Failure Modes to Avoid:**
+- Making boundary rules ambiguous so players can't predict cross-context effects
+- Forgetting to provide feedback in the source context after actions propagate elsewhere
+- Creating arbitrary constraints that feel like busywork rather than meaningful sequencing
+
+**Playtesting Focus:**
+- Do players understand how contexts connect before needing to use that connection?
+- Can they predict what will happen in Context B after acting in Context A?
+- Do players feel forced into linear sequences or discover multiple coordination approaches?
+
+**Connection to Design Process:**
+- See [internal-logic-fairness.md](../design-process/internal-logic-fairness.md) for maintaining consistent cross-boundary rules
+- See [bushy-branching.md](../design-process/bushy-branching.md) for offering parallel coordination paths

src/puzzles/systems-and-logic-overview.md

@@ -17,3 +17,19 @@ Unlike inventory puzzles that depend on item combinations or observation puzzles
 Systems & logic puzzles stand apart through their **deterministic nature**: given identical inputs, the system always produces identical outputs. This contrasts with brokerage (where NPC behavior may vary) or meta-construction (which depends on cumulative item discovery). Players solve these through analysis and prediction, not experimentation or resource accumulation.
 
 The mechanical depth comes from layered complexity—simple individual rules that generate sophisticated interactions when combined. Mastery requires understanding each rule's boundaries and how they conflict or reinforce one another within the system.
+
+## Design Process Notes
+
+**Failure Modes to Avoid:**
+- Allowing players to brute-force solutions through trial-and-error rather than requiring analysis
+- Introducing hidden rules that weren't seeded during earlier system exposure
+- Making solutions so opaque that players must externalize the system to paper to solve
+
+**Playtesting Focus:**
+- Do players engage with the system analytically, or just try random combinations?
+- Can players explain why their solution works, or did they stumble into it?
+- Does the system scale appropriately—early challenges teach, later challenges require synthesis?
+
+**Connection to Design Process:**
+- See [working-backwards.md](../design-process/working-backwards.md) for designing systems puzzles from solution to seedable rules
+- See [puzzle-dependency-charts.md](../design-process/puzzle-dependency-charts.md) for ensuring system complexity remains traceable