Design Journal — Dialogue Engine Runtime Upgrade


🎯 Intent

What was I trying to achieve today?

  • Align the implementation with the Timewarp Dialogue Engine blueprint.
  • Rename confusing components to reflect their true roles.
  • Introduce a clean separation between decision logic, runtime orchestration, and interaction surface.
  • Ensure persistence of answers and active state across sessions.
  • Reintroduce actor / assistant / system semantics in the UI.
  • Stabilize the app after refactoring.
  • Keep the system cognitively manageable for onboarding others.

🧭 Guiding Questions

What questions are shaping my thinking right now?

  • What is the minimum runtime needed for scripts as actionable content?
  • How do we separate policy decisions from execution and rendering?
  • Where should persistence live in a conversational system?
  • What belongs to Director vs Controller vs Surface?
  • How can the system resume experiences without page-based navigation?
  • How can conversational UI feel like one continuous experience?

🧠 Insight

What clicked?

  • “Everything is a Script” simplifies the architecture dramatically.
  • Home, App Store, and Inventory are not pages — they are scripts.
  • A DialogueDirector can control experience flow without rendering UI.
  • The DialogueController acts as a runtime coordinator between data and UI.
  • The DialogueSurface is the actual interaction scene.
  • Persistence turns conversations into resumable experiences.
  • Actor / assistant / system roles create semantic clarity in dialogue.

🧱 Structure

What did I build / define?

  • Renamed uiModedialogueDirector (Nanostore).
  • Renamed DialogueShellDialogueController.
  • Established a Director → Controller → Surface hierarchy.
  • Implemented persistence for answers and active question ID.
  • Stabilized initialization to avoid loading deadlocks.
  • Restored role-based Bubble rendering.
  • Moved input to the actor side of the conversation.
  • Introduced layout width control for the dialogue rail.
  • Documented the architecture in Timewarp Dialogue Engine.md.

⚙️ Decisions

What did I choose (and why)?

  • Scripts over pages or views to keep everything conversational.
  • Director handles decisions only, never rendering.
  • Controller handles runtime wiring and mounting.
  • Surface handles interaction and message flow.
  • Keep persistence in dedicated stores, not inside components.
  • Pause the inline ResumePanel experiment to maintain stability.
  • Commit frequently to avoid losing working states.

🔄 Friction

What felt messy or uncomfortable?

  • Refactoring while the app is live.
  • Cascading breakages from small naming changes.
  • Svelte store reactivity quirks.
  • Persistence issues leading to lost answers during experiments.
  • Vite cache warnings and port conflicts.
  • Cognitive overload after many hours of deep focus.
  • Difficulty stepping away once momentum builds.

🌱 Learning

What new mental model formed?

  • Dialogue systems need a runtime architecture, not just UI components.
  • Conversational experiences can be treated as executable scripts.
  • Persistence is the backbone of meaningful interaction.
  • Separation of concerns reduces cognitive load for both designers and developers.
  • Stable layers enable experimentation without breaking everything.
  • Taking breaks is part of system design, not a distraction from it.

➡️ Next Move

Single clear next step.

  • Reintroduce ResumePanel inline as a safe, low-risk experiment.
  • Restore content selection using the existing overview model.
  • Continue refining actor / assistant / system behavior.
  • Expand DialogueDirector capabilities beyond binary modes.
  • Gradually introduce script selection and transitions.
  • Keep the system stable while evolving toward a full conversational runtime.