Joseph Doherty c86b0df411 feat: T44 multi-entity turn flow with interjection support
Rewrites post_turn for the multi-entity world:

- Addressee detection via case-insensitive whole-word match against the
  guest name; defaults to host on no-match or both-match.
- Multi-entity prompt assembly: forwards guest_id so the prompt sees
  the third party's activity / edges / group-node.
- Multi-witness memory write: record_turn_memory_for_present writes one
  memory per present bot witness when a guest is in the room.
- Multi-pair state-update: compute_state_updates_for_present emits one
  edge_update per directed pair (6 with a guest, 2 without).
- Interjection branch (T39): when a guest is present and the primary
  beat completes, the silent witness may follow on. detect_interjection
  decides; on True we stream a second narrative as the witness, append a
  second assistant_turn linked to the same user_turn_id, and re-run the
  multi-pair state update + memory write for the follow-on beat. Cancel
  collapses both halves; a cancelled interjection skips its downstream
  passes so we don't classifier-spam against a half-formed beat.
- Scene-close runs after both beats so apply_scene_close_summary sees
  the full closing scene; T45's guest-aware summarizer handles per-POV
  rewrites for each present witness.

regenerate.py mirrors the prompt / memory / state-update changes for
1:1 and multi-entity scenes. Per the Phase 2 spec, interjection
regeneration is deferred to Phase 2.5 — regenerate only re-streams the
addressee turn for v2.

Tests: adds 5 cases to tests/test_turn_flow.py covering the no-guest
regression, multi-bot without interjection, multi-bot with interjection,
scene-close per-POV rewrites, and addressee routing on a named-bot
prose. Each test pins its own canned MockLLMClient queue with the call
shape documented in the docstring.
2026-04-26 16:18:38 -04:00

chat

A local-first roleplay chat engine that treats fiction as a simulation, not a chat log.

The LLM is a renderer for structured world state — it does not hold the state. State lives in an event-sourced SQLite database and is projected on demand. Models can be swapped freely behind a stateless generate(prompt, params) -> text interface.

Status: design phase. No code yet. See rp-engine-design.md for the full design and CLAUDE.md for the working summary and conventions.

Why

Conventional RP chatbots have three persistent failure modes:

  1. Memory loss — old context drops as history grows.
  2. Quality decay — bots get terse and generic over long conversations.
  3. Stale state pollution — bots fixate on past props (the "picnic basket" problem: bring a basket to one scene, the bot reaches for it forever).

The fix is to model the world as structured state — locations, time, who's present, what they're doing, what they remember, how they feel about each other — and use the LLM only to render that state into prose.

Scope

Deliberately small, so the design can be made to actually work:

  • Single user, single machine.
  • Maximum 3 entities per scene: you + up to 2 bots. The 3-entity cap is load-bearing — it makes the relationship graph fully enumerable (6 directed edges + 1 group node).
  • Chat-only. No voice, no real-time.

Multi-session casts and N-entity scenes are explicit non-goals for v1.

How it works (at a glance)

  • Entities (you, botA, botB) have identity, state (mood/goals/status), an activity record (where they are, what they're doing, what they're holding, where their attention is), and per-POV memory.
  • Containers (car, restaurant booth, room) hold entities in defined slots and provide spatial constraints the model can reason over.
  • Relationship graph: 6 directed edges + 1 group node. Asymmetric feelings are first-class — BotA can secretly resent BotB while BotB thinks they're best friends.
  • Witnessed-by flags: every memory carries a 3-bit [you, botA, botB] mask. A speaker can only retrieve memories their bit is set on. This is what stops bots referencing things they couldn't possibly know.
  • Events have lifecycles (planned → active → completed) and own their own props. When the picnic ends, the basket goes back into the closed event record. Only narrative gist, acquired objects, learned facts, and relationship changes promote to permanent memory.
  • Per-POV scene summaries: every witness gets their own version of a closed scene, written from their angle. Different details, different interpretations. This is what gives bots inner lives.
  • Event sourcing: state is a projection of an append-only event log. Free rewind, branching ("what if BotA had said yes"), surgical delete with impact preview, and survivable schema changes — all fall out for free.

Architecture

┌──────────────────────────────────────────────┐    ┌────────────────────────┐
│ Mac (always-on)                              │    │ Inference endpoint     │
│                                              │    │ (stateless)            │
│  Web UI                                      │    │                        │
│  Orchestrator                                │ →  │  Anthropic API         │
│  Event log + projector  ← SQLite (one file)  │    │  OpenAI / OpenRouter   │
│  Persistence + retrieval + prompt builder    │    │  Local MLX / llama.cpp │
│                                              │    │  Rented GPU            │
└──────────────────────────────────────────────┘    └────────────────────────┘

The Mac side holds everything that survives — state, history, retrieval, orchestration. Inference is a swappable, stateless service. State outlives any one model.

Stack

  • SQLite (single file) for everything structured. WAL mode, foreign keys on, each turn in a transaction.
  • sqlite-vss / sqlite-vec for embedding search in the same DB file (Phase 4).
  • JSON for snapshots, character templates, scene exports.
  • No Postgres. No Redis. No Pinecone. No Docker.

Roadmap

  1. Core loop — schema, entities + edges, single container, event log + projector, single-bot conversation, one LLM backend, streaming UI, manual rollback.
  2. Multi-entity — second bot, group node, scene configurations, witness filtering, per-POV memories, activity/containers, scene transitions with compression.
  3. Events & skips — event queue with triggers, time skips (elision and jump), active threads, significance classifier.
  4. Polish — vector retrieval, branching, surgical delete + regenerate, snapshots, backup automation, impact-preview UI for rewinds.

Each phase must work end-to-end before the next begins.

Repository

License

TBD.

S
Description
No description provided
Readme 3.1 MiB
Languages
Python 94.4%
HTML 4.5%
CSS 1%