Update planning package after Phase 0B

planning/MEDIA-EXTENSION-CONTRACT.md

@@ -1,6 +1,6 @@
 # Adventure Storyteller — Media Extension Contract
 
-**Status:** Draft v0.1  
+**Status:** v1.0 architecture contract — providers remain future/optional  
 **Purpose:** Define the stable interfaces and data boundaries needed to add local image, video, and audio generation later without coupling media generation to the core story engine.
 
 ## 1. Design Goal
@@ -1287,13 +1287,9 @@ Open Dungeon is especially relevant for:
 - character visual continuity,
 - image workflow UX.
 
-During Phase 0B, inspect:
-- how scene prompts are built,
-- how images are attached to story,
-- provider coupling,
-- whether media can be separated from destructive history model.
+Phase 0B confirmed Open Dungeon should remain a media/UX reference rather than the production base. Study its local image worker protocol, scene/image attachment, and character visual-continuity ideas during the future media implementation stage if useful.
 
-Do not copy its persistence limitations into the core story architecture.
+Do not copy its linear/destructive persistence assumptions into the core story architecture.
 
 ## 80. Gamentic Reuse
 
@@ -1313,23 +1309,18 @@ Corvus may be useful for:
 
 Again, use concepts selectively.
 
-## 82. V1 Physical Schema Decision
+## 82. V1 Physical Schema Direction
 
-Open question:
+The v1 requirement is architectural compatibility, not media generation.
 
-Should media tables physically exist in v1?
+Required now:
+- scene snapshots,
+- stable optional visual profiles,
+- provider-neutral request/result types or equivalent interface contract.
 
-Recommended:
+A physical media job/asset table may be introduced in the dedicated future-media-hooks milestone if it is inexpensive and useful for schema stability. Its physical presence is an implementation detail, not a prerequisite for story functionality.
 
-> Include minimal media-ready schema/interfaces if inexpensive, but do not build provider implementation solely to justify them.
-
-Minimum useful v1 fields:
-- scene snapshot,
-- stable visual profiles,
-- media provider interface/types,
-- optional media asset table.
-
-Phase 0B should determine cost.
+Do not implement a provider merely to justify a table.
 
 ## 83. V1 Required Media Readiness
 
@@ -1383,20 +1374,14 @@ Pass if:
 - abandoned-branch events are not included,
 - media generation does not mutate story.
 
-## 87. Phase 0B Validation Questions
+## 87. Phase 0B Findings Applied
 
-Codex should answer:
-
-1. How does Open Dungeon attach generated images to story messages/scenes?
-2. Is image generation coupled to linear/destructive message history?
-3. Can its visual character continuity data be reused independently?
-4. What provider assumptions are hardcoded?
-5. Can ComfyUI/local provider calls run fully offline?
-6. Does AI-DnD already have scene-like structured state suitable for media extraction?
-7. Can scene snapshots be added without RPG schema coupling?
-8. What parts of Gamentic's provider abstraction are worth reimplementing?
-9. Should media asset tables exist in v1 or be deferred?
-10. Can media generation remain entirely optional without special-casing core story logic?
+- Open Dungeon has useful local image-generation and visual-continuity concepts, but they are not a reason to use it as the production fork.
+- The production base has no required media subsystem today; this is acceptable for v1.
+- Media must remain derived from accepted scene/story state and branch-aware.
+- Provider portability for Open Dungeon's image worker is deferred until image generation is actually scheduled.
+- Scene snapshots and visual continuity fields are sufficient near-term architecture commitments.
+- TTS/STT/video remain future providers behind the same local optional boundary.
 
 ## 88. Acceptance Criteria for Architecture
 
@@ -1410,11 +1395,11 @@ The architecture passes if:
 - provider-specific syntax stays outside Story Engine,
 - local providers can be substituted,
 - future image/video/audio/TTS types fit the output job/asset model,
-- future STT fits the same provider architecture while feeding editable draft input rather than story state,
+- future STT fits the provider architecture while feeding editable draft input rather than story state,
 - generated media never automatically becomes canon,
 - abandoned-history media remains recoverable but inactive.
 
-## 89. Current Recommendation
+## 89. Selected Contract
 
 Use this conceptual contract:
 
@@ -1422,25 +1407,16 @@ Use this conceptual contract:
 Authoritative Story
        |
        v
-Scene Snapshot
+Scene Snapshot / Scene Packet
        |
        v
-Scene Packet
+Optional Media Coordinator
        |
-       v
-Media Coordinator
-       |
-       +--> Local Image Provider
-       +--> Local Video Provider
-       +--> Local Audio Provider
-       +--> Local TTS Provider
-       |
-       v
-Media Asset + Provenance
+       +--> Image Provider
+       +--> Video Provider
+       +--> Audio Provider
+       +--> TTS Provider
+       +--> STT Provider (draft input path)
 ```
 
-The media subsystem should depend on the story engine.
-
-The story engine should not depend on the media subsystem.
-
-That one-way dependency is the most important architectural requirement in this document.
+No production media provider is required for v1.