9703eb2b6b
Worldtree Conversation API debug TUI. Multi-pane observability dashboard: chat transcript + persona/Vili affect log + tool events + admin events + Bifrost state + tool inventory + (opt-in) raw server log. Design locked at docs/design-brief.md (originated as brokkr-smithy/docs/ratatoskr-design-brief.md). Operator-locked decisions: - Textual application-shell framework (multi-pane dashboard, not REPL). - Separate repo + separate dev team (no Worldtree-source imports). - httpx-sse for SSE consumption (reference Python SSE-resume impl). - Triple version-skew mitigation: spec-pin in pyproject.toml + recorded SSE snapshot tests + conformance smoke. Initial pin: Worldtree v0.19.0 at 55101e909abcd2219833266b6f905c5bc956e0f0. - Persona pane: label-don't-refuse PII posture. - Server-log pane: opt-in via --server-log <path>. - Two-stage Ctrl-C (cancel then exit). - Markdown rendering default-on; --raw opt-out. In the box: - docs/design-brief.md — the locked design with full rationale. - docs/SPEC-PIN.md — Worldtree spec pin + bump procedure. - docs/conversation-api-spec.md + docs/conversation_api.contract.md — vendored Worldtree spec snapshots at the pinned SHA. - pyproject.toml — Python 3.12, hatchling, uv-managed, deps locked. - src/ratatoskr/ — stub package (cli.py raises NotImplementedError). - tests/test_no_worldtree_imports.py — boundary smoke test PASSING. - tests/snapshots/README.md — recording convention for SSE snapshot tests. Not in the box yet: - Gitea remote (operator/infra-ops to register at vh/ratatoskr). - Implementation — the dev team owns this; design brief is the spec. Origin: althing thread 01KS3R34XD3N6HMK91VXESHGW7 (worldtree-dev → brokkr-smithy-dev, 2026-05-20). Volva consulted via thread 01KS3VF6W33N3V5FNMGQ91YNVD.
967 B
967 B
ratatoskr — architecture
Top-level module map for ratatoskr. Author this once modules exist; until then, this file is a placeholder pointing at the empty skeleton.
Module map
TODO. Mirror Worldtree's docs/architecture.md shape: top-level modules,
dependency graph, session-load boundaries, execution order.
Dependency graph
TODO once modules exist.
Session-load boundaries
When a development session focuses on one module, load that module's
CLAUDE.md plus its declared stable-infrastructure dependencies. The
top-level CLAUDE.md plus persistent-memory.md are always-load.
Execution order
TODO once a runtime exists.
Cross-references
../CLAUDE.md— top-level Claude Code conventions and project-wide rules../persistent-memory.md— durable intent across context resetscontracts/CONTRACT-FORMAT.md— contract spec format (v2.0)contracts/issues/— issue-scoped contracts (<N>.contract.mdshape)