Let me start by reading the plan.md file and all the relevant source files to understand what's expected and what's actually implemented.

Let me read all the source files now.

Let me now read the backup files to see if there's any additional context, and also check if there's a `data/` directory with saves.

Actually, let me also check the data directory and see if there are any other files I might be missing.

Let me also check the backup files for any additional features that are planned but not implemented in the main files.

Now I have all the files. Let me compare the plan against the actual codebase systematically, section by section.

## Section 1: Style Bible

Plan requirements:
- [x] **Requirements:** Style bible defined (game_data.py:1-45) 
- [x] **Requirements:** Writing style guidelines - present
- [x] **Requirements:** Should define global tone rules, route-specific motifs, diction rules, etc.
- [x] **Implementation:** Create styleBible object - present (STYLE_BIBLE in game_data.py)
- [x] **Implementation:** Define scene rhythm - present
- [x] **Implementation:** Route-specific style motifs - present
- [x] **Implementation:** Bad-phrase list - present
- [x] **Quality Gates:** Three sample scene outputs per Bagger - NOT IMPLEMENTED. No sample scene outputs exist in the codebase.
- [x] **Quality Gates:** Every authored scene node should include at least one motif hint and one tone note - Partially. Nodes have motifs but no explicit "tone note" field.
- [x] **Quality Gates:** Final QA writing checklist - NOT IMPLEMENTED. No checklist mechanism.

Gaps for Section 1:
1. No sample scene outputs per Bagger (early route, crisis, near-confession) - the plan says "Create at least three sample scene outputs per Bagger" as a quality gate before route implementation
2. Scene nodes have motifs but no explicit "tone note" field (plan says "every authored scene node should include at least one motif hint and one tone note")
3. No writing checklist for QA

## Section 2: Authored Branching Route Structure

Plan:
- [x] **Requirements:** Each Bagger needs detailed route graph - Present (ROUTE_SPECS in game_data.py)
- [x] **Requirements:** Branch breadth matters - Present
- [x] **Implementation:** Route definitions as structured data - Present
- [x] **Implementation:** Each route should have node categories - Present
- [x] **Quality Gates:** Each Bagger should ship with at least 20 scene nodes - 20 per Bagger but let me count:

Aurora: aurora_intro_puddle, aurora_daily_lamp, aurora_quiet_promise, aurora_star_map_date, aurora_silent_shift, aurora_left_behind, aurora_apology_lens, aurora_telescope_repair, aurora_festival_distance, aurora_bucket_confession_hint, aurora_friend_path_lamp, aurora_rain_return, aurora_glass_charm, aurora_map_fold, aurora_secret_crater, aurora_route_lock, aurora_normal_finale, aurora_true_finale, aurora_friend_finale, aurora_missed_end_seed, aurora_secret_finale = 21 scenes

Brummbert: brummbert_intro_lamp, brummbert_daily_gauge, brummbert_oil_compliment, brummbert_tunnel_walk, brummbert_friend_shift, brummbert_storm_trigger, brummbert_after_storm, brummbert_badge_gift, brummbert_pressure_gauge, brummbert_festival_guard, brummbert_soft_request, brummbert_friend_finale_seed, brummbert_lamp_bulb, brummbert_no_mockery, brummbert_secret_song, brummbert_route_lock, brummbert_normal_finale, brummbert_true_finale, brummbert_friend_finale, brummbert_missed_seed, brummbert_secret_finale = 21 scenes

Mira: mira_intro_stone, mira_daily_margin, mira_first_map, mira_river_stone_date, mira_map_friend, mira_misread_clay, mira_repair_sediment, mira_forgotten_map, mira_clay_poem, mira_festival_edges, mira_exact_listening, mira_friend_finale_seed, mira_folded_map_gift, mira_depth_measure, mira_secret_spring, mira_route_lock, mira_normal_finale, mira_true_finale, mira_friend_finale, mira_missed_seed, mira_secret_finale = 21 scenes

So each has >= 20 nodes. Let me check the breakdown against what's required:
"8 main romance scenes, 4 friendship scenes, 4 crisis/recovery scenes, 3 optional date scenes, and 1 secret scene"

Aurora: romance: aurora_bucket_confession_hint, aurora_route_lock (2) - these are "romance" category.
Actually the plan says "8 main romance scenes" but the categories used are intro, daily, date, threshold, crisis, repair, friendship, romance, finale, secret. The "romance" category only has 2 scenes per route typically (the "almost_confessed" and "route_lock" scenes). The main romance content seems distributed across date, threshold, and romance categories. This might be a naming/structuring issue.

Wait, let me re-read the plan: "Each Bagger should ship with at least 20 scene nodes: 8 main romance scenes, 4 friendship scenes, 4 crisis/recovery scenes, 3 optional date scenes, and 1 secret scene."

Let me count categories:
Aurora:
- intro: 1 (intro)
- daily: 3 (daily_lamp, festival_distance, miss_end_seed, rain_return) - 4
- date: 3 (star_map_date, telescope_repair, glass_charm)
- threshold: 2 (quiet_promise, map_fold)
- crisis: 1 (left_behind)
- repair: 1 (apology_lens)
- friendship: 2 (silent_shift, friend_path_lamp)
- romance: 2 (bucket_confession_hint, route_lock)
- finale: 5 (normal, true, friend, secret, + miss?)
- secret: 1 (secret_crater)

So "romance" category has only 2 scenes, not 8. The plan said "8 main romance scenes, 4 friendship scenes, 4 crisis/recovery scenes, 3 optional date scenes, and 1 secret scene". But actually looking more carefully, "main romance" might be distributed across categories like date, threshold, romance, etc. This seems like a structural difference but not strictly a gap.

Let me check nextCandidates - nodes have `"nextCandidates": []` at game_data.py:259. The plan says "nextCandidates" should be populated, but they're all empty lists. This means the scene selection doesn't use a graph structure - it's purely based on gates and categories. The plan says: "Each scene node should include ... nextCandidates". These are empty in all nodes.

Also I don't see explicit "nextCandidates" being populated in the make_node function. Let me check... Yes, at game_data.py:259: `"nextCandidates": []`. This field is present but always empty. The plan intended this to link scenes in a graph structure, but it's not used.

Gaps for Section 2:
1. `nextCandidates` is always empty - no actual graph linking between scene nodes
2. The scene resolver doesn't use nextCandidates at all - uses category-based priority instead
3. Route breadth: only 2 "romance" category nodes per route vs 8 "main romance" suggested
4. No explicit "tone note" field per scene node

## Section 3: Multiple Endings

Plan:
- [x] **Requirements:** Each Bagger needs bad end, missed-route end, friendship end, normal romance end, true romance end, and secret ending - Present (ENDINGS dict in game_data.py:285-294)
- [x] **Requirements:** Endings should depend on various factors - resolve_ending implements this
- [x] **Implementation:** Add endingResolver - Present (resolve_ending at game_engine.py:480-503)
- [x] **Implementation:** Gemini writes ending prose from resolved type - NOT IMPLEMENTED. The ending resolution does not call Gemini for ending prose. It just returns the ending type/label.
- [x] **Quality Gates:** Every ending must have documented conditions and at least one test fixture
  - Documented conditions: No formal documentation of ending conditions
  - Test fixtures: ending-fixture command in simulate.py exists but it's bare-minimum
- [x] **Quality Gates:** Secret endings should require specific route behavior - Present (checks for specific flags)
- [x] **Quality Gates:** Ending prose reviewed for motif payoff - No ending prose at all

Actually, looking more carefully at the code: when an ending is resolved, the engine just sets `state["endingState"] = ending` (game_engine.py:474) which is `{"route": route, "kind": kind, "label": ENDINGS[route][kind]["label"], "resolvedAt": int(time.time())}`. There's no call to Gemini to write the ending prose. The plan says "Gemini writes the ending prose from a resolved ending type."

In script.js line 285: `if (result.ending) lastReply += `\n\n${result.ending.label}`;` - so the ending is just tacked onto the last reply as a label. No actual ending prose.

Gaps for Section 3:
1. No Gemini-based ending prose generation - ending is just a label
2. No documented conditions for each ending
3. Test fixtures are minimal (ending-fixture just sets high stats and checks resolution)

## Section 4: Event Calendar

Plan:
- [x] **Requirements:** Add fixed calendar events - Present (CALENDAR in game_data.py:139-148)
- [x] **Requirements:** Calendar events should create anticipation and missed opportunities - Partially
- [x] **Implementation:** Add calendarRegistry - Present
- [x] **Implementation:** Missed calendar events should set flags - NOT IMPLEMENTED. No known "missed_*" flags for calendar events in the flag registry or anywhere in the code. The plan specifically mentions `missed_festival_aurora` or `missed_storm_rescue_brummbert`. The FLAG_REGISTRY has `missed_festival_{route}` and `missed_route_{route}` generated but they're never actually set.
- [x] **Quality Gates:** Fixed events must trigger exactly once - Implemented (eventsSeen check)
- [x] **Quality Gates:** Missing important events should have visible later consequences - NOT IMPLEMENTED. No code checks for missed calendar events.
- [x] **Quality Gates:** Calendar conflict behavior must be documented - NOT IMPLEMENTED

Looking at the calendar, some events have `"route": "aurora"` etc. but the `candidate_calendar_event` function at line 172-179 only checks `event.get("route", route) == route`. So route-specific events only show for the matching route. But what if the player is on a different route when a calendar event for a different Bagger occurs? There's no mechanism to flag that as "missed".

Also, the `missed_festival_{route}` and `missed_route_{route}` flags are defined in FLAG_REGISTRY at game_data.py:281-282, but they're never actually set by any code path.

Gaps for Section 4:
1. Calendar events that are skipped/missed don't set any `missed_*` flags
2. No consequence mechanism for missed calendar events
3. Calendar conflict behavior not documented

## Section 5: Scheduling And Stat Training

Plan:
- [x] **Requirements:** Player chooses how to spend each time period - Present
- [x] **Requirements:** Add player stats - Present (6 stats defined)
- [x] **Implementation:** Scheduling actions affect stats deterministically - Present (apply_schedule)
- [x] **Implementation:** Fatigue should affect scene outcomes - Present (fatigue_penalty in apply_scene_result at game_engine.py:439)
- [x] **Quality Gates:** Player should not be able to max all stats - Present (limited actions per day, only 30 days)
- [x] **Quality Gates:** At least three important events per route should require protagonist stats - Let me check...

Looking at route nodes with playerStat requirements:
Aurora: aurora_apology_lens (patience>=12), aurora_telescope_repair (mechanics>=14) - only 2
Brummbert: brummbert_tunnel_walk (courage>=8), brummbert_after_storm (courage>=22), brummbert_pressure_gauge (mechanics>=12) - 3
Mira: mira_repair_sediment (focus>=14), mira_clay_poem (focus>=12) - only 2

So Aurora and Mira only have 2 events requiring player stats, not 3.
- [x] **Quality Gates:** Normal endings achievable without optimization - Debatable, but the gate system seems reasonably balanced

Gaps for Section 5:
1. Aurora and Mira have only 2 stat-gated events instead of the required 3

## Section 6: Affection And Stat Gates

Plan:
- [x] **Requirements:** Important route events need meaningful thresholds - Present
- [x] **Requirements:** Gates should feel emotionally logical - Present
- [x] **Implementation:** Reusable condition objects - Present (cond function)
- [x] **Implementation:** Locked events can be hidden, teased - NOT IMPLEMENTED. The select_scene function just skips locked nodes silently. There's no mechanism to show them as "locked" or tease upcoming content.
- [x] **Quality Gates:** Boundary tests - NOT IMPLEMENTED. No test fixtures for exact thresholds.
- [x] **Quality Gates:** Gates should never deadlock - Present (always has daily fallback)
- [x] **Quality Gates:** Debug tooling should explain why scene is locked - Partially. lock_reasons function exists but debug endpoints don't consistently expose it through the API. The `explain-scene` debug command does show rejected reasons.

Gaps for Section 6:
1. Locked events can't be shown as "teased" or "unavailable but visible" - they're simply skipped
2. No boundary test fixtures for threshold verification

## Section 7: Route Lock-In

Plan:
- [x] **Requirements:** Early exploration possible, eventual lock - Partially
- [x] **Requirements:** Lock-in must feel intentional - Partially
- [x] **Implementation:** lockedRoute and commitmentScore - Partially. lockedRoute is present but there's no per-Bagger "commitmentScore" field. Route pressure "toward_lockin" serves a similar purpose.
- [x] **Implementation:** Show a clear route-commitment scene before lock - Partially. The "route_lock" category scenes exist but there's no special UI treatment or explicit announcement.
- [x] **Quality Gates:** One casual interaction must not lock in - The lock-in requires toward_lockin >= 5 AND route_lock_ready flag, so this is protected
- [x] **Quality Gates:** Finale scenes only for locked route - select_scene's preferred_categories adds "finale" only when lockedRoute matches
- [x] **Quality Gates:** Post-lock non-route Bagger scenes should still feel respectful - No special handling for this

Looking at the lock-in mechanism at game_engine.py:461:
```python
if state["routePressure"][route].get("toward_lockin", 0) >= 5 and not state.get("lockedRoute") and has_flag(state, f"route_lock_ready_{route}"):
```

This requires both `toward_lockin >= 5` and the `route_lock_ready` flag. The `route_lock_ready` flags are set by route_lock scenes (e.g., aurora_route_lock). The "toward_lockin" pressure comes from node routePressureEffects and Gemini. This seems reasonable, but there's no explicit "commitmentScene" shown before lock - the lock happens silently during apply_scene_result.

Gaps for Section 7:
1. No per-Bagger `commitmentScore` field (uses route pressure instead - workable but differs from plan)
2. No explicit route-commitment scene UI/announcement - lock happens as a side effect
3. Post-lock non-route Bagger scenes have no special respectful handling

## Section 8: Date-Location System

Plan:
- [x] **Requirements:** Dates involve selecting Bagger, location, optionally gift - Present
- [x] **Requirements:** Locations should be authored and memorable - Present
- [x] **Implementation:** Locations - Present (LOCATIONS in game_data.py:77-88)
- [x] **Implementation:** Location tags and Bagger preferences - Present
- [x] **Quality Gates:** Each Bagger needs preferred, neutral, disliked locations - Present (preferredTags/dislikedTags in BAGGERS)
- [x] **Quality Gates:** Good, neutral, poor dates produce visibly different outcomes - location_fit function exists but the result is NOT passed to Gemini in any meaningful way. Let me check...

In compose_prompt (game_engine.py), the gift fit is included as `Geschenk: {gift.get('fit')} {gift.get('itemId') or ''}` but there's no equivalent for location fit. The location tags are included in the prompt (line 314: `Ort: {location['name']} ({', '.join(location['tags'])})`), so Gemini can infer quality from the prompt, but the engine doesn't explicitly tell Gemini whether this is a good/neutral/poor date location.

The `location_fit` function (game_engine.py:286-296) exists and calculates fit, but it's never called in `resolve_interaction`. It's defined but unused.

In apply_scene_result, there's no special handling for date location fit either.

- [x] **Quality Gates:** Poor dates should create awkward or repair content - Not really enforced by code

Gaps for Section 8:
1. `location_fit` function is defined but never called/used anywhere
2. No explicit location fit feedback to Gemini or stat effects based on location quality
3. Date locations don't have special outcome differentiation beyond what Gemini infers from tags

## Section 9: Gift Economy And Inventory

Plan:
- [x] **Requirements:** Add inventory, currency, gift shopping - Present
- [x] **Requirements:** Gifts should carry story meaning - Present (liked/disliked/critical)
- [x] **Implementation:** Items (game_data.py:90-101) - Present
- [x] **Implementation:** Gift resolution combines deterministic rules with Gemini - Partially. Gift fit is passed to Gemini in the prompt. Apply_gift does deterministic effects in apply_scene_result.
- [x] **Quality Gates:** Gifts must be consumed correctly and persist - Present (inventory decremented, state saved)
- [x] **Quality Gates:** Each Bagger should have at least 5 liked gifts, 2 disliked gifts, and 1 route-critical gift - Let me count...

Aurora: liked=5 (star_map, glass_charm, kiesel, warm_oil, folded_map), disliked=2 (loud_horn, cheap_flower), critical=1 (star_map) - OK
Brummbert: liked=5 (rescue_badge, lamp_bulb, warm_oil, kiesel, glass_charm), disliked=2 (loud_horn, cheap_flower), critical=1 (rescue_badge) - OK
Mira: liked=5 (river_stone, folded_map, kiesel, glass_charm, star_map), disliked=2 (loud_horn, cheap_flower), critical=1 (river_stone) - OK
- [x] **Quality Gates:** Normal endings not impossible because of one missed shop item - Present (critical gifts are obtainable)

Gaps for Section 9: None significant.

## Section 10: Hidden Flags And Promise System

Plan:
- [x] **Requirements:** Track promises made/kept/broken, etc. - Partially
- [x] **Requirements:** Promises should be an emotional core - Not really implemented
- [x] **Implementation:** Add typed flags - Partially. The plan specifically mentions structured promise flags with `route`, `createdDay`, `dueDay`, `duePeriod`, `kept`, `broken`, `sceneId`. The current code uses simple string flags instead.
- [x] **Implementation:** Promise flags should include structured data - NOT IMPLEMENTED. Promises are just simple string flags (e.g., "aurora_quiet_promise"), not structured objects with due dates etc.
- [x] **Quality Gates:** Every major route event should set or clear a meaningful flag - Present
- [x] **Quality Gates:** Broken promises must affect later dialogue or endings - NOT IMPLEMENTED. The `broken_promise_{route}` flags exist in the registry but are never actually set by any code.
- [x] **Quality Gates:** Gemini-suggested flags must be known IDs - Present (validate_ai checks against FLAG_REGISTRY)

Gaps for Section 10:
1. Promise flags are simple strings, not structured objects with dueDay, duePeriod, etc.
2. `broken_promise` flags are never set - no mechanism to break promises
3. `jealousy`, `boundary` flag types not implemented
4. No promise tracking with due dates - promises like "I'll return" have no enforcement mechanism

## Section 11: Backlog And Dialogue History

Plan:
- [x] **Requirements:** Add VN-style backlog - Present
- [x] **Requirements:** Backlog is literal transcript, memories are summarized - Present
- [x] **Implementation:** state.backlog entries - Present
- [x] **Implementation:** Backlog panel with route filtering and cap - Present (300 entries cap, filter in UI)
- [x] **Quality Gates:** Backlog must persist across reloads - Present (saved in state, persisted)
- [x] **Quality Gates:** Backlog must not include API keys - Present (only game content)
- [x] **Quality Gates:** Every visible dialogue should appear in backlog - Present

Gaps for Section 11: None significant.

## Section 12: Presentation Polish

Plan:
- [x] **Requirements:** Route title cards, fades, dramatic pauses, choice reveal animations - NOT IMPLEMENTED (no title cards, fades, dramatic pauses)
- [x] **Requirements:** Presentation should support emotional pacing - Not really
- [x] **Implementation:** Scene presentation layer with showNarration, showDialogue, etc. - NOT IMPLEMENTED. No presentation layer object.
- [x] **Implementation:** 3D model poses - Partially (7 poses defined in Gemini schema but only 2-3 actually animate in Three.js)
- [x] **Quality Gates:** Animations must respect reduced-motion settings - Present (CSS media query)
- [x] **Quality Gates:** WebGL failure should still leave game playable - Present (initThreeSafe try/catch)
- [x] **Quality Gates:** Effects must not cause double submissions or broken state - Present (loading state in interact function)

The script.js has very basic pose animation. The `animateModel` function sets a `visual` property but the `tick` function only has special animation for `digging`, `confession`, `crisis` poses. Other poses (listening, shy, proud, guarded) don't have any visual differentiation - they all use the same idle animation.

Gaps for Section 12:
1. No route title cards, scene transitions, fade effects, dramatic pauses
2. No presentation layer (showNarration, showDialogue, showChoices, transitionToLocation, showStatChange, applyPose)
3. 3D model poses are partially implemented - only 3 out of 7 poses have distinct animations
4. No choice reveal animations
5. No stat change feedback animation

## Section 13: Failure Pressure And Missed Opportunities

Plan:
- [x] **Requirements:** Ignoring Baggers, missing dates, etc. should have consequences - Partially
- [x] **Requirements:** Failure should create drama, not punishment - Partially
- [x] **Implementation:** Track neglect, missedPromises, fatigue, routeDeadlineMisses, unresolvedCrisis - Partially. Neglect is tracked. `missedPromises` not tracked (no promise mechanism). `routeDeadlineMisses` not tracked. `unresolvedCrisis` is indirectly tracked via crisis_active flags.
- [x] **Implementation:** Add warning scenes before severe consequences - NOT IMPLEMENTED
- [x] **Quality Gates:** Neglectful playthrough should produce missed-route/friendship endings - resolve_ending checks neglect >= 4 for bad ending
- [x] **Quality Gates:** One bad choice should not destroy strong route - Present (gates are gradual)
- [x] **Quality Gates:** Repair branches should exist after some mistakes - Present (repair category nodes exist)

Gaps for Section 13:
1. `missedPromises`, `routeDeadlineMisses`, `unresolvedCrisis` counters not implemented
2. No warning scenes before severe consequences
3. No rescue/repair mechanism for neglect other than the repair category scenes

## Section 14: Protagonist Setup

Plan:
- [x] **Requirements:** New game start with name, address, personality - Present
- [x] **Requirements:** Protagonist should feel present but flexible - Present
- [x] **Implementation:** Start screen - Present
- [x] **Implementation:** Personality affects starting stats and Gemini tone - Present (stats bonus, style in prompt)
- [x] **Quality Gates:** Names must be sanitized and length-limited - Present (maxlength="32" in HTML)
- [x] **Quality Gates:** Gemini must not overwrite profile data - Present (profile not sent back)
- [x] **Quality Gates:** Profile setup once per new game - Present (localStorage check)

Gaps for Section 14:
1. No server-side name sanitization beyond clean_text (but that's reasonable since names are just stored)

## Section 15: Server-Side Persistence

Plan:
- [x] **Requirements:** Durable server-side persistence, anonymous save token - Present
- [x] **Requirements:** Saves include all state - Present
- [x] **Implementation:** POST /api/save, GET /api/save/:token, POST /api/restore - Present
- [x] **Implementation:** Store JSON saves under /opt/bagger-api/data/saves - Present
- [x] **Quality Gates:** Saves atomic, size-limited, schema-versioned - Present (tmp+replace, 600KB limit, schemaVersion)
- [x] **Quality Gates:** Invalid tokens fail safely - Present (regex check, FileNotFoundError)
- [x] **Quality Gates:** No API key stored - Present

The GET /api/save/:token endpoint at app.py:71-73 loads save by token. This is a GET but the plan said `GET /api/save/:token` and `POST /api/restore`. Both are present.

Gaps for Section 15: None significant.

## Section 16: Gemini-Guided Progression

Plan:
- [x] **Requirements:** Gemini influences progression meaningfully - Present
- [x] **Requirements:** No custom safety gates beyond Gemini - Present
- [x] **Implementation:** /api/interact returns structured data - Present
- [x] **Implementation:** Engine clamps deltas, accepts known flags - Present (validate_ai)
- [x] **Implementation:** Route pressure categories - Present (ROUTE_PRESSURES)
- [x] **Quality Gates:** Same menu choice with different text should produce different outcomes - Present (text is sent in prompt)
- [x] **Quality Gates:** Gemini-suggested flags must be from known registry - Present
- [x] **Quality Gates:** If Gemini fails, preserve state or use neutral fallback - Present (fallback to mock_gemini in except block)

Gaps for Section 16: None significant.

## Section 17: Debug Tooling And Route Simulation

Plan:
- [x] **Requirements:** Developer-facing debug tooling - Present (CLI tool + API endpoints)
- [x] **Requirements:** Tooling should answer practical questions - Partially
- [x] **Implementation:** CLI tool with commands - Present (simulate.py)
- [x] **Implementation:** Private API endpoints - Present (BAGGER_DEBUG=1 + localhost check)
- [x] **Implementation:** Debug traces - Present (write_trace)
- [x] **Quality Gates:** validate-routes should fail on various issues - Present
- [x] **Quality Gates:** Simulations cover romance, friendship, balanced, neglect, gift-heavy, training-heavy - Present (6 strategies)
- [x] **Quality Gates:** Debug endpoints must not expose API keys - Present

Let me check the CLI commands against the plan:
Plan says: `list-routes`, `show-route aurora`, `validate-routes`, `simulate --route aurora --strategy romance`, `simulate --route mira --strategy neglect`, `ending-fixture true_aurora`, `explain-scene --save token --scene aurora_observatory_2`

CLI has: list-routes, show-route, validate-routes, simulate, ending-fixture, explain-scene, dump-data

Does it have `explain-scene --save token --scene aurora_observatory_2`?
The CLI's explain-scene takes --save, --route, --intent, but NOT --scene. You can't specify a particular scene to explain; it just shows what scene would be selected next.

The plan had `explain-scene --save token --scene aurora_observatory_2` which suggests being able to explain a specific scene node. That's not supported.

Also looking at the `app.py.bak` vs the current `app.py`:
The bak file doesn't have `/api/debug/explain-scene` endpoint, but the current app.py does. So explain-scene was added between versions.

But looking at the trace - the debug trace includes rejected scenes with reasons, which partially covers the "explain" functionality.

Also:
- The `dump-data` command is in the CLI but not in the plan.
- `ending-fixture` exists but the plan also wanted `validate-routes` to check for "unreachable endings" and "missing next nodes" - validate_routes currently doesn't check these.

Let me check validate_routes more carefully (game_engine.py:593-610):
```python
def validate_routes():
    errors = []
    for route, nodes in ROUTES.items():
        if len(nodes) < 20:
            errors.append(f"{route}: fewer than 20 nodes")
        seen = set()
        for node in nodes:
            if node["id"] in seen:
                errors.append(f"{route}: duplicate node {node['id']}")
            seen.add(node["id"])
            if node["location"] not in LOCATIONS:
                errors.append(f"{node['id']}: unknown location {node['location']}")
            if not node.get("motifs"):
                errors.append(f"{node['id']}: missing motifs")
            for flag in node.get("setsFlags", []):
                if flag not in FLAG_REGISTRY:
                    errors.append(f"{node['id']}: unknown set flag {flag}")
    return errors
```

The plan says validate-routes should fail if scenes reference:
- unknown flags - Present (setsFlags check)
- impossible gates - NOT IMPLEMENTED (doesn't check if gate conditions reference valid stats/flags)
- missing next nodes - NOT IMPLEMENTED (nextCandidates is always empty)
- missing style notes - NOT IMPLEMENTED (doesn't check translationStyleNotes)
- missing motifs - Present (checks motifs)
- unknown locations - Present
- unreachable endings - NOT IMPLEMENTED (doesn't check if ending conditions can ever be met)

Gaps for Section 17:
1. `explain-scene` CLI doesn't support specifying a particular scene by ID
2. `validate-routes` doesn't check for impossible gates, missing next nodes, missing style notes, or unreachable endings
3. No `GET /api/debug/state/:token` endpoint (plan mentions it but it's not in either app.py version)
4. Missing `--scene` parameter in explain-scene CLI

Wait, let me look more carefully at the plan:
"Add private API endpoints bound to localhost or protected by BAGGER_DEBUG=1: GET /api/debug/state/:token, POST /api/debug/explain-scene, GET /api/debug/routes, POST /api/debug/simulate, and POST /api/debug/resolve-ending."

Current app.py has:
- POST /api/debug/simulate (line 111-112)
- POST /api/debug/resolve-ending (line 114-117)
- GET /api/debug/routes (line 79-80)
- POST /api/debug/explain-scene (line 119-124) - NOTE: this is a POST but the plan says POST, so OK

Missing: GET /api/debug/state/:token

Let me also look for the GET /api/debug/state/:token handler... It's not in app.py. The GET handler at line 75 checks `if path.startswith("/api/debug/")` and then only handles `/api/debug/routes`. It doesn't have `/api/debug/state/:token`.

Now let me compile the complete gap list.

Actually, let me also check a few more subtle things:

1. In `select_scene`, the `preferred_categories` starts as empty list in the bak, but as `["intro"]` in the main version. Let me check if the main version has been updated.

The main game_engine.py line 189: `preferred_categories = ["intro"]` vs the bak line 189: `preferred_categories = []`. So the main version always prefers intro scenes first. This seems intentional.

2. Route lock-in in the main version at game_engine.py:461:
```python
if state["routePressure"][route].get("toward_lockin", 0) >= 5 and not state.get("lockedRoute") and has_flag(state, f"route_lock_ready_{route}"):
```
vs the bak version at game_engine.py.bak:455:
```python
if state["routePressure"][route].get("toward_lockin", 0) >= 5 and not state.get("lockedRoute"):
```
The main version adds the `has_flag(state, f"route_lock_ready_{route}")` check, requiring the lock readiness flag. This is an improvement.

3. The bak doesn't have the `dump-data` CLI command but the main does.

OK, I think I have a comprehensive picture now. Let me compile the final report.

Actually, one more thing to check - the plan mentions "At least three important events per route should require protagonist stats" (Section 5 quality gate). Let me verify again:

Aurora stat-gated scenes:
- aurora_apology_lens: playerStat=patience >= 12
- aurora_telescope_repair: playerStat=mechanics >= 14
That's only 2.

Brummbert stat-gated scenes:
- brummbert_tunnel_walk: playerStat=courage >= 8
- brummbert_after_storm: playerStat=courage >= 22
- brummbert_pressure_gauge: playerStat=mechanics >= 12
That's 3.

Mira stat-gated scenes:
- mira_repair_sediment: playerStat=focus >= 14
- mira_clay_poem: playerStat=focus >= 12
That's only 2.

So Aurora and Mira fall short.

Now let me also check if there's a `commitmentScore` field. The plan says "Add lockedRoute and per-Bagger commitmentScore." Looking at the state, there's no commitmentScore field in relationships or anywhere. Route pressure `toward_lockin` serves the same purpose conceptually.

One more thing: "Add warning scenes before severe consequences" - not implemented.

Also: "Calendar conflict behavior must be documented and testable" - not documented.

Let me now assemble the final comprehensive report.