diff --git a/README.md b/README.md
index 84914d5..82b209c 100644
--- a/README.md
+++ b/README.md
@@ -15,14 +15,16 @@ A taxonomy of puzzle design patterns derived from analysis of classic Sierra and
 | 7 | [Cross-Realm Logistics Puzzle](./puzzles/cross-realm-logistics.md) | Inventory management across multiple locations/realms; rewards forward planning | KQVI |
 | 8 | [Truth Revelation Mechanic](./puzzles/truth-revelation.md) | Items reveal hidden truth; truth itself is the solution | KQVI |
 | 9 | [Observation Replay Puzzle](./puzzles/observation-replay.md) | Single viewing of sequence, must reproduce exactly when opportunity arises | MI/MM/SIMON |
-| 10 | [Pattern Learning / Knowledge Transfer](./puzzles/pattern-learning.md) | Learn rule set in low-stakes domain; apply exhaustively under consequences | MI |
+| 10 | [Pattern Learning / Knowledge Transfer](./puzzles/pattern-learning.md) | Learn rule set in low-stakes domain; apply exhaustively under consequences | MI/TD |
 | 11 | [Environmental Memo Chain](./puzzles/memo-chain.md) | Scattered written fragments across locations; synthesize narrative to reveal solution | MI |
 | 12 | [NPC Distraction Physics](./puzzles/distraction-physics.md) | Manipulate environment to break NPC blocking pattern without confrontation | MI |
-| 13 | [Meta-Puzzle Construction](./puzzles/meta-puzzle-construction.md) | Sequential interdependence; each step's output becomes next step's input | MI/MM/SMHTR/IJOA |
-| 14 | [Multi-Character Coordination Puzzle](./puzzles/multi-character-coordination.md) | Multiple characters required for separated location actions; single character physically impossible | MM/DOTT |
+| 13 | [Meta-Puzzle Construction](./puzzles/meta-puzzle-construction.md) | Sequential interdependence; each step's output becomes next step's input | MI/MM/SMHTR/IJOA/TD |
+| 14 | [Multi-Character Coordination Puzzle](./puzzles/multi-character-coordination.md) | Multiple characters required for separated location actions; single character physically impossible | MM/DOTT/TD |
 | 15 | [Cross-Temporal Causality Puzzle](./puzzles/cross-temporal-causality.md) | Actions in one time period create immediate consequences in another; solution requires understanding historical causality | DOTT |
 | 16 | [Surreal Logic Bridge](./puzzles/surreal-logic-bridge.md) | Real-world causality rejected for cartoon/comedy equivalences; success requires abandoning realistic reasoning | SMHTR |
 | 17 | [Comedy-Based NPC Persuasion](./puzzles/comedy-based-persuasion.md) | Dialogue success depends on tonal comedy matching, not logical argument or trade | SMHTR |
+| 18 | [Symbol Code Translation](./puzzles/symbol-code-translation.md) | Visual symbols on artifact translate to interface actions via shape/color+order matching; applied exhaustively | TD |
+| 19 | [Robot Programming / Color-Encoded Sequences](./puzzles/robot-programming.md) | Abstract color→action rule discovery through experimentation; compose original sequences | TD |
 
 ---
 
diff --git a/puzzles/meta-puzzle-construction.md b/puzzles/meta-puzzle-construction.md
index 6e0c5ec..13e7009 100644
--- a/puzzles/meta-puzzle-construction.md
+++ b/puzzles/meta-puzzle-construction.md
@@ -343,6 +343,68 @@ Exactly one path to completed costume. No branching allowed during assembly phas
 
 ---
 
+### The Dig: Planetarium Creature Trap Construction (TD)
+
+**Problem**: In the Planetarium Spire, a small critter guards a green engraved rod behind a sealed door. The door requires a machine part that only the trapped critter possesses. Player must construct a functioning trap from scattered components, then lure the critter into it to retrieve the door component and access the rod.
+
+<small>Source: mogelpower_morgana_walkthrough.txt, lines 1477-1506 — dowel+pin→wheel, pole+pin→hook, hook+cage→trapping mechanism, rod+cage→trap assembly</small>
+
+**Sequential Assembly Chain**:
+```
+PHASE 1: Component Discovery (scattered collection)
+- DOWEL: Wooden peg found near large wheel (cannot take directly)
+- POLE: Movable pole attached to wall nearby (not inventory-accessible)
+- RIB CAGE: Animal remains scattered across floor (can be collected)
+- ROD: Wooden stick found with rib cage area
+
+PHASE 2: Meta-Puzzle Construction (STRICT SEQUENCE):
+Step 1: Use DOWEL with WHEEL → creates PIN in wheel center
+        - DOWEL alone has no other function
+        - Step produces PIN as intermediate state (not inventory item)
+
+Step 2: Use POLE with PIN in wheel → converts to HOOK  
+        - POLE can only be moved via LOOK action
+        - Result: HOOK attached to wall (environment modification)
+
+Step 3: Use RIB CAGE with HOOK → creates CAGE structure
+        - Cage cannot exist without hook attachment point
+        - Transforms trapless cage into potential trapping device
+    
+Step 4: Use ROD with CAGE → completes TRAP mechanism
+        - Rod props up cage to create spring-loaded trigger
+        - Final assembly = functional trap ready for bait
+
+PHASE 3: Critter Luring and Capture (behavior exploitation):
+Step 5: Click HOLE near trap location → critter emerges from wall
+Step 6: Walk Boston DOWNSCREEN then LEFT in front of wheels (NOT between them)
+Step 7: Return RIGHT through wheel gap → critter follows into trap path
+        - Critter AI chases player along shortest route
+        - Specific positioning triggers automatic trap entry
+Step 8: CRITTER catches in TRAP automatically
+
+PHASE 4: Trap Resolution:
+Step 9: Attach BRACELET tracker to CRITTER before release
+Step 10: Release trapped critter (door part now accessible)
+Step 11: Use DEVICE/SHOVEL at TRACKER SPOT in cave → MACHINE PART unearthed
+Step 12: Return MACHINE PART + COVER to DOOR PANEL → door opens → GREEN ROD obtained
+```
+
+<small>Source: mogelpower_morgana_walkthrough.txt, lines 1514-1543 — critter luring technique and machine part retrieval</small>
+
+**Why It's Meta-Puzzle Construction**: Strict sequential dependency with output interdependence:
+- Dowel must first create pin (intermediate state A) before pole can become hook (state B)
+- Hook is environmental prerequisite for cage attachment—cage cannot function alone
+- Rod only completes trap AFTER cage properly mounted on hook
+- Cannot reorder any step; each transformation produces required input for next
+
+**Hybrid Design Element**: Puzzle combines two distinct mechanical patterns:
+1. **Meta-Construction**: Trap assembly chain (dowel→pin, pole→hook, cage+hook+rod=trap)
+2. **Behavior Exploitation**: Critter luring requires understanding AI positioning rules (walk in specific pattern to exploit shortest-path chasing logic)
+
+The trap construction itself is pure Meta-Construction; the creature capture adds positional puzzle-solving layered on top. Walkthrough author explicitly references LucasArts trap-building tradition: "I was somewhat familiar with the LucasArts theory of trap building; I'd done something similar in that game" (referencing Monkey Island 2).
+
+---
+
 ## Related Types
 
 - **Multi-Faceted Plan**: When requirements discovered in parallel, not sequence
diff --git a/puzzles/multi-character-coordination.md b/puzzles/multi-character-coordination.md
index e65df15..5d5477a 100644
--- a/puzzles/multi-character-coordination.md
+++ b/puzzles/multi-character-coordination.md
@@ -496,3 +496,105 @@ All three characters must execute their respective actions within same game fram
 
 **Why It's Multi-Character Coordination**:  
 This is the PUREST expression of MCC in DOTT—the three-character coordination requirement applies across temporal boundaries as well as spatial ones. Character switching happens continuously during resolution phase, and all three timelines must be "live" simultaneously for success. Traditional MCC puzzles occur in single timeline; this extends the coordination requirement across CENTURIES while demanding simultaneous action windows (impressive design synthesis of Cross-Temporal Causality + Multi-Character Coordination).
+
+---
+
+## The Dig Character-Coordination Patterns (Four Aliens, Shared Inventory)
+
+### The Dig: Crew Task Distribution via Radio Communication (TD)
+
+**Problem**: After arriving on the alien planet, crew members split up and explore different locations independently. Unlike traditional multi-character games with explicit character-switching mechanics, The Dig uses a hybrid system: player controls Boston (protagonist) directly while coordinating with Maggie and Brink through radio communication (Penultimate device). Character abilities are specialized—Maggie's linguistic expertise can interpret alien symbols, Brink's archaeology knowledge identifies artifacts—but they are physically SEPARATED by the game world. Coordination occurs through INFORMATION SHARING rather than simultaneous action.
+
+<small>
+Source: mogelpower_morgana_walkthrough.txt, lines 1-25 — "Maggie ... renowned journalist and linguistic expert"; "Ludger Brink (noted geologist and archaeologist)"
+
+Source: spoiler_paul_greunke_walkthrough.txt, multiple instances of "talk to Maggie about" and "talk to Brink about" as information exchange points
+</small>
+
+**Distribution Requirements**:
+```
+CHARACTER SPECIALIZATIONS:
+- Boston Low (player-controlled): Physical actions, inventory management, exploration
+- Maggie Robbins (linguist): Can interpret alien language symbols when shown artifacts
+- Ludger Brink (archaeologist/geologist): Expert knowledge of ancient technologies, burial chambers, artifacts
+
+INVENTORY SHARING LIMITATION:
+Unlike MM or DOTT where each character has separate inventory, The Dig uses a SINGLE SHARED INVENTORY managed by Boston. However, items must be physically carried TO separated locations where other characters can examine them via TALK/SHOW interactions.
+
+COORDINATION PATTERN ASYNCRONOUS (not simultaneous):
+1. Player/Boston collects artifact at Location A
+2. Travel to Location B where Maggie/Brink positioned
+3. SHOW item → character provides domain-specific insight
+4. Apply knowledge gained when returning puzzle context
+```
+
+**Information Exchange Solution Pattern**:
+
+[Source: mogelpower_morgana_walkthrough.txt, lines 1120-1137]
+
+Example - Glowing Crystals and Life Restoration:
+```
+DISCOVERY PHASE (Boston/Museum):
+→ Boston collects GLOWING CRYSTALS from museum floor
+→ Exhibits show skeleton transformation imagery but no explicit explanation
+
+COORDINATION PHASE (Maggie/Library):  
+→ Boston radios Maggie via Penultimate device
+→ SHOWS crystals to Maggie over radio
+→ Dialogue reveals: "the dead could be raised" via crystal display interpretation
+→ Maggie's linguistic knowledge decodes the museum display meaning
+
+APPLICATION PHASE (Boston/Nexus):
+→ Boston returns to Brink's body with crystals
+→ USEs crystals on body → Brink resurrected as undead being
+```
+
+**Why It's NOT Traditional Multi-Character Coordination**:
+1. **No Simultaneous Actions**: Characters never act in PARALLEL—no character switching for synchronized tasks
+2. **Single Actor Physicality**: All physical actions performed by Boston alone; Maggie and Brink are advisors not doers
+3. **Information Transfer, Not Spatial Coordination**: Puzzle resolution comes from Maggie's KNOWLEDGE being applied to Boston's ITEMS
+
+**Correct Classification**: This is more accurately **Information Brokerage** where NPCs (separated party members) provide expert interpretation. The "multi-character" aspect is narrative framing only—mechanically it's NPC expertise acquisition.
+
+---
+
+### The Dig: Weak Door Opening Requires Crew Member Strength (TD, Positional Coordination)
+
+**Problem**: On the Museum Spire, a WEAKENED DOOR cannot be opened by Boston alone despite being unlocked. It requires TWO crew members to apply force simultaneously—one character pushes while the other assists. This is a physical constraint based on character positioning rather than inventory or knowledge distribution.
+
+<small>
+Source: spoiler_paul_greunke_walkthrough.txt, lines 184-186 — "try to open weakened door (can't open it yet)"
+
+Source: mogelpower_morgana_walkthrough.txt, lines 1052-1053, 1187-1192 — "I couldn't OPEN the WEAKENED DOOR without help... Brink followed me back through... he did help me OPEN the WEAKENED DOOR"
+</small>
+
+**Coordination Requirements**:
+```
+PHYSICAL CONSTRAINT:
+Door mechanism functional but requires combined strength of two characters
+
+CHARACTER DISTRIBUTION:
+- Boston (Player): Positioned at door initially
+- Brink (NPC): Must be physically present at SAME location
+
+NOT INVENTORY DEPENDENT: Cannot solve through items alone—requires crew positioning
+
+SOLUTION SEQUENCE:
+1. [Boston]: Opens doors to Museum Spire, finds weakened door cannot be opened solo
+2. [Boston]: Resurrects Brink using glowing crystals at Nexus
+3. [Both Characters Together]: Enter tram together (Brink follows Boston on-screen)  
+4. [Both at Weak Door]: With BOTH characters present in scene → door can now be OPENED
+5. [Result]: Life crystal chamber revealed, additional crystals can be collected
+```
+
+**Why It's Multi-Character Coordination (Minimal Form)**:
+1. **Physical Presence Requirement**: Puzzle explicitly requires TWO bodies at same location—single character attempt fails with clear feedback ("can't open it yet")
+2. **Not Inventory or Knowledge Based**: No item makes Boston stronger; no conversation provides "how to pry door open"
+3. **Simplified Coordination Pattern**: Unlike MM's complex spatial separation + timing, this is simple PRESENCE DEPENDENCY—two characters adjacent = action possible
+
+**Distinction from Standard MCC**: This is the MINIMAL form of Multi-Character Coordination requiring:
+- Only two characters (not three)
+- No simultaneous actions across separated locations
+- Simple adjacency requirement for unlock condition
+
+It demonstrates that not all multi-character puzzles require MM's dual-location parallel execution—some merely need character stacking at single locus. The "coordination" is simplified to ensuring BOTH characters arrive BEFORE attempting action, rather than sequencing actions DURING puzzle resolution.
diff --git a/puzzles/robot-programming.md b/puzzles/robot-programming.md
new file mode 100644
index 0000000..9d894b9
--- /dev/null
+++ b/puzzles/robot-programming.md
@@ -0,0 +1,314 @@
+# Robot Programming / Color-Encoded Action Sequences (Pattern Learning Variant)
+
+**Information Architecture**: Player discovers mechanical rule system through trial-and-error with no explicit tutorial. Each button color maps to specific robot action (directional movement or item manipulation). Rules are consistent and exhaustive—once discovered, player understands COMPLETE control framework. Later puzzles invoke identical mechanics for different goals, requiring players to compose NEW sequences using mastered framework rather than learning new rules.
+
+**Player Action Pattern**:
+1. Encounter robot/control panel interface with multiple color-coded buttons
+2. Experiment with individual button colors to discover action mappings (purple=left, blue=up, etc.)  
+3. Observe robot behavior provides immediate visual feedback for each input
+4. Compose sequences by entering multiple colored commands before execution trigger
+5. Press execution button (triangle) to run programmed sequence
+6. If goal not achieved: review failed sequence, adjust color/order, re-execute
+7. When framework mastered: apply same rules to entirely different objectives without new teaching
+
+**Core Mechanic**: Color-coded interface buttons map to specific robot actions; player learns exhaustive rule set through experimentation in low-stakes puzzle context, then applies IDENTICAL framework to new goals where failure has higher consequences (power restoration affects game progression).
+
+---
+
+## Variations
+
+| Type | Learning Method | Feedback Clarity | Application Diversity | Example |
+|------|-----------------|------------------|----------------------|---------|
+| **Direct Experimentation** | Trial-and-error with no hints | High (visible robot movement) | Multiple goals, same rules | Robot lens retrieval → power restoration |
+| **Environmental Hints** | Murals/displays suggest button-color meanings | Medium (requires interpretation) | Single complex goal | Light bridge controls via museum display interpretation |
+| **Progressive Unlocking** | First rule reveals access to discover second | Low-Medium | Linear sequence discovery | Multi-stage control room puzzles |
+
+---
+
+## Adventure Game Implementation
+
+### Standard Actions Applied:
+- **CLICK** individual colored buttons = Input commands into program buffer (does NOT execute immediately)
+- **OBSERVE** robot display = Monitor command queue accumulation before execution
+- **CLICK TRIANGULAR/EXECUTION BUTTON** = Run programmed sequence
+- **WHITE CLEAR/BACKSPACE BUTTONS** = Reset or edit command queue mid-programming
+
+### Learning Through Failure:
+Unlike combat systems (swordfight) where failed attempts produce loss states, robot programming failures are benign—the robot simply doesn't achieve the desired outcome and returns to starting position. Player can retry indefinitely with modified sequences. This creates a sandbox learning environment with no penalty for experimentation.
+
+---
+
+## Example Structure: The Dig Robot Lens Retrieval
+
+### Learning Phase (Nexus Power Room)
+
+**Environment Setup**:
+[Source: spoiler_paul_greunke_walkthrough.txt, lines 158-173]
+
+```
+LOCATION: Nexus power room beneath main floor
+INTERFACE: Control panel with 7 color-coded buttons:
+→ Purple = ??? 
+→ Blue = ???
+→ Yellow = ???  
+→ Green = ???
+→ Orange/Red = ??? (contextually changes function)
+→ Top White = Backspace (remove last command)
+→ Bottom White = Clear (reset all commands)
+
+PHYSICAL CONTEXT: Robot descends through chute when triangular execution button pressed. Below robot can move over a pit containing an unattached lens that needs to be retrieved and placed in lens slot.
+
+PLAYER KNOWLEDGE STATE: Zero—no hints provided about button functions.
+```
+
+**Discovery Process Through Experimentation**:
+
+Based on walkthrough reconstruction and logical deduction:
+
+[Source: mogelpower_morgana_walkthrough.txt, lines 916-923]
+
+The walkthrough author describes the actual discovery method:
+
+> "The simplest way to figure out what the BUTTONS did seemed to be to plug in a line of one color on the CONTROL PANEL, PUSH the TRIANGULAR BUTTON, watch what happened, and then repeat with the next color. This way I'd be able to devise a program that would get the thing to the UNATTACHED LENS..."
+
+**Systematic Discovery Process**:
+```
+STEP 1: Test Purple Button
+→ Input: purple [execute]
+→ Observation: Robot moves LEFT one step
+→ Rule discovered: PURPLE = MOVE LEFT
+
+STEP 2: Test Blue Button  
+→ Input: blue [execute]
+→ Observation: Robot moves UP (toward top of screen/away from lens area)
+→ Rule discovered: BLUE = MOVE UP
+
+STEP 3: Test Yellow Button
+→ Input: yellow [execute]  
+→ Observation: Robot moves DOWN (toward lens area)
+→ Rule discovered: YELLOW = MOVE DOWN
+
+STEP 4: Test Green Button
+→ Input: green [execute]
+→ Observation: Robot moves RIGHT
+→ Rule discovered: GREEN = MOVE RIGHT
+
+STEP 5: Understand Orange/Red Contextual Function
+→ When robot positioned over item: orange/red = GRAB
+→ When robot holding item: orange/red = DROP
+→ Rule discovered: ORANGE/RED = contextual (GRAB/DROP toggle)
+
+RULE SET NOW COMPLETE—all button mappings known
+```
+
+**Application 1: Lens Retrieval Program**:
+
+[Source: spoiler_paul_greunke_walkthrough.txt, lines 173-175]
+
+> "to get the lens push: purple 4 times, yellow 2 times, and red 1 time"
+
+**Translation to Robot Commands**:
+```
+PROGRAM QUEUE (before execution):
+purple, purple, purple, purple, yellow, yellow, orange
+
+EXECUTED ACTIONS:
+LEFT → LEFT → LEFT → LEFT (robot positions over lens)
+DOWN → DOWN (robot descends to lens level)  
+ORANGE/RED = GRAB (robot picks up lens)
+
+[Execution button pressed] → Robot completes sequence, returns via chute with lens
+[Result check]: Lens slot now filled → Power activates → Nexus doors unlockable
+```
+
+**Key Design Element**: The walkthrough author notes in [mogelpower_morgana_walkthrough.txt, lines 919-923]:
+
+> "I had to PUSH the TRIANGULAR BUTTON a few times as I was putting the program together to make sure it was working right"
+
+This confirms player can ITERATE development—build partial sequence, test, add more commands, test again. This creates an accessible programming environment that mirrors modern incremental software development practices.
+
+---
+
+### Application 2: Power Restoration (Identical Rules, Different Goal)
+
+[Source: spoiler_paul_greunke_walkthrough.txt, lines 176-180]
+
+After lens retrieval, power activates but is temporarily on. Player must now create SECOND program to permanently restore power by placing lens into correct slot.
+
+> "to restore power (to open doors) push: purple 5 times, blue 4 times, and red 1 time"
+
+**Translation to Robot Commands**:
+```
+PROGRAM QUEUE:
+purple, purple, purple, purple, purple, blue, blue, blue, blue, orange
+
+EXECUTED ACTIONS:
+LEFT x5 (position robot over slot)  
+UP x4 (ascend to slot height)
+ORANGE/RED = DROP (release lens into slot)
+
+[Result check]: Lens installed → Power permanently restored → Door panels functional
+```
+
+**Why This Is Pattern Learning**:
+1. **Same Mechanic, Different Target**: Robot doesn't learn anything new—player knows all rules from Application 1. Only goal changed (retrieval vs installation).
+2. **New Sequence Required**: Cannot reuse lens retrieval program; player must compose fresh command sequence for different spatial objective.
+3. **Same Framework**: Purple still = left, blue still = up, etc. Zero new teaching occurs.
+
+The robot puzzle teaches the COLOR→ACTION rule set ONCE in Application 1, then requires EXHAUSTIVE APPLICATION of those rules to solve Application 2 without any additional hints or tutorials.
+
+---
+
+### Extended Application: Light Bridge Controls (Same Framework, New Domain)
+
+A related Puzzle Learning example exists throughout The Dig with the light bridge "strange device" controls found on each spire.
+
+**Light Bridge Control Pattern**:
+[Source: spoiler_paul_greunke_walkthrough.txt, lines 200-203; mogelpower_morgana_walkthrough.txt, lines 1278-1295]
+
+```
+MECHANIC: Three-lens positioning puzzle with timing component
+
+REPEATING FRAMEWORK on EACH spire light bridge:
+1. Position LENS to one of three angles (each produces different audio tone)
+2. Listen for which position produces DISTINCT/DIFFERENT tone  
+3. PUSH and HOLD switch until crystal above glows
+4. Maintain hold until line completes drawing across pentagonal display
+5. EXIT interface → BRIGHT LIGHT walkable bridge now appears connecting to central sphere
+
+WALKTHROUGH AUTHOR NOTE: Same process applies at least FOUR TIMES (Museum Spire, Planetarium Spire, Map Spire, Tomb Spire)
+[mogelpower_morgana_walkthrough.txt, lines 1599-1627 — light bridge solutions repeated across multiple spires with identical procedures]
+
+VARIATION: Last active light bridge encountered includes hidden prism puzzle within control panel—randomly placed to add unexpected complexity after framework mastery
+```
+
+**Why Light Bridges Are Pattern Learning (not Symbol Code Translation)**:
+- No visual symbol matching—player learns procedural sequence, not visual equivalencies
+- Identical process applies across ALL instances with zero re-teaching  
+- Player discovers rule set ONCE through first successful light bridge activation, then applies exhaustively
+- Audio feedback (different tone) becomes learned indicator of correct state
+
+---
+
+## Why Robot Programming Is Pattern Learning vs. Other Types
+
+### Distinction from Multi-Faceted Plan:
+- **MFP**: Scatter multiple DIFFERENT puzzle requirements (key, code, distractor); collect all, SYNTHESIZE into solution
+- **Robot Programming**: Discover ONE rule system (colors = actions); APPLY to multiple goals
+
+The robot uses a SINGLE mechanical framework applied repeatedly, not synthesis of disparate elements.
+
+### Distinction from Meta-Puzzle Construction:  
+- **MPC**: Step A produces output → Step B consumes that output → Step C builds on previous result
+- **Robot Programming**: Lens retrieval succeeds as complete unit; power restoration is separate task using same tools
+
+While both robot programs achieve related goals in same location, they are INDEPENDENT solutions not a chain where one's output becomes another's input. Player could restore power then retrieve lens—the order doesn't create dependencies.
+
+### Distinction from Observation Replay:
+- **OR**: Watch exact sequence once, reproduce verbatim—NO rule understanding required  
+- **Robot Programming**: Discover abstract rules ("purple moves left"), compose ORIGINAL sequences for new goals
+
+Player didn't watch "purple-purple-yellow-red" and memorize it for later repetition. Player discovered PURPLE=LEFT as a reusable rule, then COMPOSED custom programs for each objective.
+
+---
+
+## Design Considerations for Robot/Programming Puzzles
+
+**Implementation Patterns**:
+1. **Incremental Testing Capability**: Allow players to test partial sequences before full commits
+2. **Clear Visual Feedback**: Robot movement must be unambiguous—exactly 1 step per command with visible positioning
+3. **Command Queue Display**: Show entered sequence BEFORE execution so player can verify correctness mentally
+4. **Benign Failure States**: Incorrect programs should reset without permanent consequences or item loss
+
+**Best Practices**:
+1. Keep rule set small and memorable (5-7 actions maximum)
+2. First goal requires shorter sequence (~5-8 commands) to teach without overwhelming  
+3. Later applications require longer/more complex sequences using same rules (~10+ commands)
+4. Provide visual/auditory feedback for each command type (different sounds/animations per action)
+
+**Common Pitfalls**:
+- Rules too abstract or counterintuitive ("blue means diagonal movement" violates spatial intuition)
+- No way to test partial sequences—player must get entire program right on first attempt  
+- Robot pathfinding obscured by visual clutter (can't see if robot actually moved correct number of steps)
+
+---
+
+## Related Types
+
+| Type | Similarity to Robot Programming | Distinction |
+|------|----------------------------------|-------------|
+| **Pattern Learning / Knowledge Transfer** | Same core mechanism: learn rules once, apply exhaustively | Robot programming is concrete spatial manipulation; PL often abstract (dialogue, ingredient categories) |
+| **Symbol Code Translation** | Both systematic rule discovery through experimentation | SCT adds visual matching layer; robot programming uses direct abstraction (color→action, no intermediate symbol artifact) |
+| **Observation Replay** | Both require remembering sequences | OR copies watched sequence exactly; Robot requires composing NEW sequences from learned rules |
+
+---
+
+## Game Examples
+
+### The Dig: Nexus Robot Programming - Complete Walkthrough Solution
+
+**Setup**: After Brink dies and crew enters Nexus, player descends ramp to power room. Blue crystal provides temporary light but removing it causes blackout. An unattached lens hangs over a pit below—must be retrieved and installed to restore permanent power so Nexus doors can open.
+
+**Solution Chain**:
+[Source: Combined from spoiler_paul_greunke_walkthrough.txt lines 150-183; mogelpower_morgana_walkthrough.txt lines 915-925]
+
+**PHASE 1 - Rule Discovery (Tutorial Sandbox)**:
+1. Return to control panel with blue crystal in place (lights on for visibility)
+2. Click individual colored buttons one at a time, execute single-command programs:
+   - Purple alone → observe robot movement direction
+   - Blue alone → observe robot movement direction  
+   - Yellow/Green same process
+3. Discover purple=left, blue=up, yellow=down, green=right through systematic testing
+4. Learn orange/red button = GRAB/DROP (contextual based on robot state)
+
+**PHASE 2 - Lens Retrieval Program Composition**:
+5. Input sequence: P-P-P-P-Y-Y-O (purple×4, yellow×2, orange)
+6. Execute with triangular button → robot descends, navigates to lens position, grabs it
+7. Robot returns to chute with lens—lens now in inventory
+
+**PHASE 3 - Power Restoration Program Composition**:  
+8. Return to control panel (lights off but can interact)
+9. Input sequence: P-P-P-P-P-B-B-B-B-O (purple×5, blue×4, orange)
+10. Execute → robot navigates to slot position, drops lens into mount
+11. Power activates permanently, Nexus doors now unlockable with engraved rods
+
+**Why It's Extended Pattern Learning**:
+- Phase 1 teaches COMPLETE rule framework through experimentation
+- Phases 2 and 3 REQUIRE application of learned rules without additional hints
+- Player must COMPPOSE original sequences (not recall watched actions) using abstract mappings (colors → directions → spatial navigation)
+- Same system could theoretically be taught via explicit tutorial ("purple is left") but game design deliberately WITHHOLDS instruction, forcing discovery learning
+
+**Design Significance**: Unlike typical adventure game puzzle types where player solves discrete problems with unique solutions, the robot programming puzzle teaches a REUSABLE SYSTEM. This is mechanically closer to video game tutorial levels or mini-games that teach controls—except there's no explicit teaching text, only discovery through trial-and-error in authentic gameplay context.
+
+---
+
+## When to Document as Robot Programming / Color-Encoded Sequences
+
+Document as this type when:
+1. ✓ Interface uses abstract symbols (colors/shapes) mapping to specific actions via consistent rules  
+2. ✓ Player must DISCOVER mappings through experimentation—not taught explicitly
+3. ✓ Learned rule set applies to MULTIPLE puzzle goals requiring different sequences  
+4. ✓ Framework functions without visual artifact matching (unlike Symbol Code Translation's rod→button equivalence)
+
+DO NOT classify as this type if:
+- Only ONE solution sequence exists (no repeated application of learned rules = not Pattern Learning)
+- Mappings taught through explicit text/tutorial rather than discovery
+- Different rule sets required for different goals (not consistent framework = Multi-Faceted Plan instead)
+
+---
+
+## Cross-Reference to Related Mechanics
+
+### Contrast with Symbol Code Translation:
+Both teach systems through first-instance learning but differ in COGNITIVE LAYER:
+- **Robot Programming**: Abstraction learning ("purple → left")  
+- **Symbol Translation**: Visual matching learning ("red triangle on artifact → red triangle button on interface")
+
+In practice, The Dig uses BOTH systems extensively—robots for power restoration and spatial puzzles, rods for door unlocking. Each exemplifies Pattern Learning through different cognitive mechanisms (abstract vs visual).
+
+### Contrast with Observation Replay:
+Both involve sequences but differ in FLEXIBILITY:
+- **Robot Programming**: Player composes custom sequences based on understood rules
+- **Observation Replay**: Player reproduces EXACT watched sequence—no modification possible
+
+If player can think "I need to go LEFT 6 times instead of 4" rather than "I must repeat purple-purple-yellow-red exactly as shown," it's Robot Programming/Pattern Learning, not Observation Replay.
diff --git a/puzzles/symbol-code-translation.md b/puzzles/symbol-code-translation.md
new file mode 100644
index 0000000..c8049cd
--- /dev/null
+++ b/puzzles/symbol-code-translation.md
@@ -0,0 +1,267 @@
+# Symbol Code Translation / Extended Pattern Learning
+
+**Information Architecture**: Game establishes a mechanical system in a low-stakes domain (first engraved rod + door panel combination), then requires application of IDENTICAL rules across multiple instances with different targets. The player learns the translation framework once, then exhaustively applies it to new symbol sequences discovered throughout exploration. This extends Pattern Learning by adding a VISUAL SYMBOL RECOGNITION layer—player must observe symbol shapes and colors, map them to interface buttons with matching visual properties, then input exact sequence order.
+
+**Player Action Pattern**:
+1. Acquire engraved rod or similar symbol-bearing artifact from environment
+2. EXAMINE artifact to view full symbolic sequence (4-5 colored geometric shapes in specific order)
+3. Locate corresponding interface panel with selectable symbol/color buttons
+4. Map each observed symbol → matching button on panel (visual equivalency check)
+5. Input sequence from left-to-right (order matters; random attempts fail)
+6. Panel validates → door/mechanism unlocks
+
+**Core Mechanic**: The learning domain and application domain share IDENTICAL underlying rules with an ADDITIONAL visual mapping layer—player must recognize that Symbol Domain A (engraved rod sequence) translates to Action Domain B (panel button presses) through SHAPE+COLOR matching, not just mechanical repetition like standard swordfight insults or voodoo ingredient categories.
+
+---
+
+## Variations
+
+| Type | Learning Instance | Application Count | Visual Mapping Complexity | Example |
+|------|-------------------|-------------------|--------------------------|---------|
+| **Direct Translation** | Single rod learned | Multiple rods applied | Low (shapes/colors match directly) | Engraved rods → Nexus doors |
+| **Multi-Source Map Generation** | All rods collected | Single panel application | Medium (sequential code entry, output is informational) | Map Room: all rods reveal spire locations |
+| **Hidden Sequence Discovery** | Pattern visible after power activation | One-time use | High (symbols only readable AFTER prerequisite puzzle) | Crystal control room panels |
+
+---
+
+## Adventure Game Implementation
+
+### Standard Actions Applied:
+- **EXAMINE** = Reveal symbol sequence on artifact (cannot proceed without observation)
+- **LOOK/USE** on panel = Access button interface for input
+- **CLICK** on individual buttons = Select symbols in sequence (order sensitive, no "backspace" mechanic in most implementations)
+- **TAKE** artifact first = Must possess symbol source in inventory before translation is possible
+
+### Key Distinctions from Pattern Learning:
+1. **No combat/training domain**: Player doesn't practice with dummy doors; first rod is a FUNCTIONAL puzzle
+2. **Visual recognition layer added**: Not just "insult A → retort B" rules but also "red triangle shape on rod = red triangle button on panel" mapping
+3. **Exploration-dependent progression**: New rods discovered across scattered locations (museum, underwater caves, creature encounters) rather than sequential tutorial flow
+
+---
+
+## Example Structure: The Dig Engraved Rod System
+
+### Learning Phase (First Door in Nexus):
+
+```
+ACQUISITION:
+→ Purple engraved rod obtained after activating wire in Wreck chamber
+   [Source: spoiler_paul_greunke_walkthrough.txt, lines 107-108 — "get wire / get engraved rod"]
+   
+EXAMINATION PHASE:
+→ EXAMINE purple rod reveals: 4 colored geometric shapes in sequence
+   [Source: mogelpower_morgana_walkthrough.txt, lines 690-698 — "I EXAMINED it and found some 
+   colored geometric symbols on it... The shapes seemed to resemble the BUTTONS on the PANELS"]
+   
+→ IMPORTANT NOTE from walkthrough: Symbol arrangements appear RANDOM per playthrough
+   [Source: mogelpower_morgana_walkthrough.txt, lines 692-697 — "I discovered in replaying 
+   the game that the symbols appear to be set randomly from game to game...red triangle, green 
+   hexagon, green cube, another red triangle"]
+
+INTERFACE DISCOVERY:
+→ First sealed door panel shows 4 rows of color-coded geometric buttons
+→ Each row corresponds to ONE position in rod sequence
+→ Player must scroll through button options until each position matches rod shape+color
+   
+VALIDATION DISCOVERY:
+→ Input order is LEFT-TO-RIGHT (matches visual reading direction on rod)
+   [Source: mogelpower_morgana_walkthrough.txt, lines 995-997 — "I plugged in the combination 
+   on the PURPLE ENGRAVED ROD as it appeared there from left to right and the SEALED DOOR opened!"]
+
+SUCCESS = Door opens → Tram access unlocked
+```
+
+### Application Phase (Subsequent Doors - No Teaching Reminders):
+
+**Orange Rod (Underwater Cave) → Second Door**:
+```
+→ Player acquires orange rod AFTER defeating sea monster, swimming underwater
+[Source: spoiler_paul_greunke_walkthrough.txt, lines 257-258 — "get plate / get orange engraved rod"]
+
+→ EXAMINATION reveals 4 new symbols (randomized, different from purple rod)
+NO REMINDER that left-to-right order matters
+NO EXPLANATION of color+shape matching principle
+
+→ Player must self-instruct: "this works the same way purple rod did"
+→ Door opens successfully via IDENTICAL process
+```
+
+**Red Rod (Museum Spire) → Third Door**:
+```
+[Source: spoiler_paul_greunke_walkthrough.txt, line 212 — "get red engraved rod"]
+→ Same mechanical translation, zero reinforcement of rules
+```
+
+**Green Rod (Planetarium Spire Creature Trap Puzzle) → Fourth Door**:
+```
+[Source: spoiler_paul_greunke_walkthrough.txt, line 361 — "get green rod"]
+→ Requires completing meta-puzzle construction (dowel+pole+rib cage trap sequence)
+→ THEN symbol translation applies identically to door 4
+```
+
+**Yellow Rod (Tomb Spire/Eclipse Mechanism) → Final Door Access**:
+```
+[Source: spoiler_paul_greunke_walkthrough.txt, line 415 — "use yellow engraved rod with slot"]
+→ Requires solving eclipse/tomb opening puzzle first
+→ Translation mechanic applies same way as doors 1-4
+```
+
+### Extended Application (Map Room - Multi-Rod Synthesis):
+
+The Map Spire introduces a SECONDARY application of the translation system:
+
+**Map Panel Information Generation**:
+[Source: mogelpower_morgana_walkthrough.txt, lines 1633-1653]
+
+```
+SINGLE PANEL with 5 input slots = Requires ALL rods collected from previous spires
+
+PROCEDURE:
+→ Plug in purple rod sequence → View Museum Spire location on map display
+→ Plug in orange rod sequence → View Underwater Cave/Tunnel locations on map  
+→ Plug in red rod sequence → View TOMBE location with "way below it" highlighted (critical late-game clue)
+→ Plug in green rod sequence → View Planetarium Spire chamber locations
+→ Each output is INFORMATION only, not door unlock
+
+KEY DIFFERENCE: Rods previously functioned as KEYS (open single target). Here they function as MAP COORDINATES (reveal information about game world layout)—SAME mechanical translation, different output type.
+```
+
+**Critical Clue Extraction**:
+The Red Rod's map view specifically shows "a crypt somewhere -- with a way below it" which:
+1. Alerts player that tomb has hidden lower chambers
+2. Required for later puzzle progression (cannot access crypt unless player has seen map)
+   [Source: mogelpower_morgana_walkthrough.txt, lines 1650-1658 — "NOTE: It appears that viewing the crypt in the MAP ROOM as just described can save you a lot of trouble later"]
+
+---
+
+## Why This Is Extended Pattern Learning vs. Other Types
+
+### Distinction from Observation Replay:
+- **OR**: Memorize exact button sequence (e.g., "up-down-left-left-down"), reproduce exactly
+- **Symbol Translation**: Memorize RULE ("rod symbols = panel buttons, left-to-right, shape+color match") then apply to NEW values each time
+
+The engraved rod system cannot be Observation Replay because:
+1. Symbols are randomized per playthrough—walkthroughs cannot hard-code solutions
+2. Player applies FRAMEWORK (translation rule) not specific VALUES (button sequence)
+3. Each new rod requires fresh visual recognition, not "remember the last one"
+
+### Distinction from Multi-Faceted Plan:
+- **MFP**: Gather scattered requirements (key+code+distractor), SYNTHESIZE into single solution
+- **Symbol Translation**: Gather scattered instances of SAME requirement type, apply FRAMEWORK repeatedly
+
+Each rod is independently complete—no synthesis across rods needed. The purple rod doesn't "combine" with orange rod; they each individually open one door using identical mechanics.
+
+### Distinction from Standard Pattern Learning (MI1 Sword Fighting):
+**Additional Visual Mapping Layer**: MI1 player learns abstract rule pairs ("My tongue is sharper → feather duster"). The Dig player must ALSO perform visual recognition: "this red hexagon on rod = this red hexagon button on panel." It's not just mechanical transfer (rule applies elsewhere), it's VISUAL-to-ACTION translation.
+
+---
+
+## Design Considerations for Symbol Code Translation Puzzles
+
+**Implementation Patterns**:
+1. **Randomization per Playthrough**: Ensures walkthroughs cannot hard-code solutions; forces player engagement with the MECHANIC not memory
+2. **Consistent Visual Grammar**: Shapes and colors on rods MUST match button interfaces exactly (no "close enough" matching)
+3. **First Instance as Sandbox**: First rod/door pair has no penalty for wrong order attempts (can retry indefinitely until pattern discovered)
+4. **No Backspace Mechanic** (optional): Increases difficulty by requiring complete sequence re-entry if one position is wrong
+
+**Best Practices**:
+1. Provide clear visual feedback on EXAMINATION—symbols must be readable and unambiguous
+2. First success should produce immediate, unmistakable result (door HUMS then opens with cutscene)
+3. Consider varying OUTPUT TYPE across instances (some doors open, some panels generate information like Map Room) to keep mechanic fresh while maintaining same underlying rules
+
+**Common Pitfalls**:
+- Players may incorrectly believe symbols are cipher codes requiring "decryption" rather than direct visual matching
+- Order sensitivity should be obvious (left-to-right reading direction is intuitive but should be reinforced by first instance)
+- If randomized, ensure ALL symbol shapes/colors appear available on panels—nothing on rod that panel cannot display
+
+---
+
+## Related Types
+
+| Type | Similarity to Symbol Code Translation | Distinction |
+|------|---------------------------------------|-------------|
+| **Pattern Learning / Knowledge Transfer** | Both teach system once, apply exhaustively across new targets | SCT adds visual recognition matching layer; standard PL is abstract rule transfer only |
+| **Observation Replay** | Both require careful observation of symbolic sequence | OR copies exact values repeated; SCT translates symbols to interface actions each time |
+| **Multi-Faceted Plan Puzzle** | Both involve collecting scattered artifacts across exploration | MFP SYNTHESIZES multiple unique requirements; SCT applies ONE framework to multiple instances |
+
+---
+
+## Game Examples
+
+### The Dig: Purple Engraved Rod → First Nexus Door (Learning Instance)
+
+**Setup**: After Brink dies, player explores central Nexus chamber with 5 sealed doors and corresponding control panels. One door has no panel but an alchove for plates. Four doors have panels with geometric button interfaces.
+
+**Solution Chain**:
+1. Obtain purple engraved rod from Wreck chamber (pulled wire activates ghost light, revealing hidden rod)
+2. EXAMINE rod in inventory—reveals 4-symbol sequence (e.g., red triangle, green hexagon, blue cube, red circle—varies per playthrough)
+3. Note that rods have NO intrinsic function other than being examined for symbols
+4. Move to first door panel with button interface and examine
+5. Each of 4 rows on panel scrolls through different colored shapes when clicked
+6. Input sequence from left to right, matching rod order exactly:
+   - Row 1: Scroll until shows red triangle → Click to set
+   - Row 2: Scroll until shows green hexagon → Click to set  
+   - Row 3: Scroll until shows blue cube → Click to set
+   - Row 4: Scroll until shows red circle → Click to set
+7. Exit panel interface—door hums briefly then slides open
+
+**Why It's Symbol Code Translation**: This is the TUTORIAL instance—player learns framework here without explicit instruction. Success depends on recognizing visual equivalency (shape+color match) AND order sensitivity (left-to-right reading). The rod itself provides NO information other than symbol display—it must be paired with a panel interface to have function.
+
+**Citation**: 
+- [spoiler_paul_greunke_walkthrough.txt, lines 149-150 — "examine purple rod / click on the buttons until they match the purple rod"]
+- [mogelpower_morgana_walkthrough.txt, lines 682-700 — rod examination and button matching process]
+
+---
+
+### The Dig: Robot Programming via Symbol Sequences (Pattern Learning Variant)
+
+A related but distinct mechanic in The Dig demonstrates Pattern Learning without the symbol translation layer—pure action sequence learning.
+
+**Lens Retrieval Robot Control Panel**:
+[Source: spoiler_paul_greunke_walkthrough.txt, lines 164-173]
+
+```
+COLOR-CODED BUTTON FUNCTIONS (learnt through experimentation):
+→ Purple button = robot moves left
+→ Blue button = robot moves up  
+→ Yellow button = robot moves down
+→ Green button = robot moves right
+→ Orange/Red button = robot GRABS/DROPS item (context sensitive)
+→ White buttons = backspace / clear
+
+PROGRAMMING PHASE:
+Player discovers functions via trial-and-error with no explicit tutorial
+
+TO RETRIEVE LENS:
+Sequence learned through experimentation:
+"purple 4 times, yellow 2 times, and red 1 time" [Source: spoiler_paul_greunke_walkthrough.txt, line 173]
+Translation: LEFT x4, DOWN x2, GRAB = robot navigates over edge to unattached lens
+
+TO RESTORE POWER (different task, SAME mechanics):
+"purple 5 times, blue 4 times, and red 1 time" [Source: spoiler_paul_greunke_walkthrough.txt, line 179]
+Translation: LEFT x5, UP x4, DROP = robot returns lens to slot
+```
+
+**Why This IS Pattern Learning (not Symbol Code Translation)**:
+- No visual symbol mapping layer—player learns abstract rule set "color → directional action"
+- Same framework applies to TWO different goals with DIFFERENT sequences
+- Framework is mechanical (button press → movement command), not visual (symbol A = button B)
+
+**Distinction from Engraved Rod System**:
+The robot uses Pattern Learning's abstract rule transfer while the rods use Symbol Code Translation's visual matching. Both teach system once and apply multiple times, but through different cognitive layers (abstract vs visual).
+
+---
+
+## When to Document as Symbol Code Translation
+
+Document a puzzle as Symbol Code Translation when:
+1. ✓ Visual symbols on ONE artifact (rod/code plate/map key) must be matched to interface elements with matching PROPERTIES (shape/color/type)
+2. ✓ Sequence ORDER matters and must be maintained through translation process
+3. ✓ Same mechanical framework applies to MULTIPLE instances across gameplay (at least 3+ uses of system)
+4. ✓ First instance functions as implicit tutorial without explicit teaching
+
+DO NOT use this classification if:
+- Symbols are fixed values player simply memorizes (Observation Replay instead)
+- Only ONE translation occurs with no repeated applications (Simple Code Puzzle, not system-based)
+- Visual recognition is irrelevant—abstract rule transfer only (Pattern Learning / Knowledge Transfer instead)
+- Multiple DIFFERENT artifacts must be combined (Multi-Faceted Plan or Meta-Puzzle Construction instead)
diff --git a/walkthroughs/analysis-checklist.md b/walkthroughs/analysis-checklist.md
index b7bae9c..1190547 100644
--- a/walkthroughs/analysis-checklist.md
+++ b/walkthroughs/analysis-checklist.md
@@ -15,7 +15,7 @@ Status legend:
 - [ ] Indiana Jones and the Fate of Atlantis (1992)
 - [ ] Day of the Tentacle (1993)
 - [x] Sam & Max Hit the Road (1993) - SMHTR
-- [ ] The Dig (1995)
+- [x] The Dig (1995) - TD
 - [ ] Full Throttle (1995)
 - [ ] Grim Fandango (1998)
 
@@ -59,5 +59,5 @@ Status legend:
 ## Analysis Progress
 
 **Total:** 30 games  
-**Complete:** 10 games (KQVI, MI1, MI2, SIMON, LK1, MM, ZAK, INDY1, LOOM, SMHTR)  
-**Remaining:** 20 games
+**Complete:** 11 games (KQVI, MI1, MI2, SIMON, LK1, MM, ZAK, INDY1, LOOM, SMHTR, TD)  
+**Remaining:** 19 games