Design durable session and project state store

[xodapi]

Why

Important context is still lost between Codex/OpenCode sessions. Chat history and transient process state are not enough for long-running work, especially when audits, PRs, model-health findings, GitHub issues, and follow-up decisions span multiple sessions.

Scope

Design a local durable state layer for this project that records only privacy-safe operational context:

• active repo/fork/PR/issue pointers;
• last validation commands and results;
• current proxy/runtime state summary;
• pending handoff notes and next actions;
• model health / upstream limit status summaries;
• configuration facts needed to resume safely.

Do not store prompts, model responses, API keys, local chat text, or secret file contents.

redb-first storage question

The user specifically called out redb as a possible answer for lost cross-session context. Treat redb as a serious local embedded-state candidate, not Redis.

Compare these staged options:

• JSONL snapshots + latest-state JSON: easiest first step for Node-only code, inspectable, no dependency, but weaker querying and consistency guarantees.
• redb through a small Rust helper: strong embedded local DB, no external service, good fit for future opencode-proxy-doctor.exe / launcher / state reader. This may be the best long-term durable-state layer if we accept a Rust helper boundary.
• SQLite: mature and query-friendly, but adds native dependency/packaging questions to the current no-dependency Node proxy.
• Redis: not the local-first answer here; requires a separate service and should be considered only for a future shared/team deployment, not the default desktop proxy.

Acceptance criteria

• A short design doc defines the state schema, file locations, retention policy, and privacy boundary.
• The design makes a clear recommendation for JSONL-first, redb-first, SQLite, or a staged JSONL -> redb path.
• The design explains how Node code and a future Rust helper would share/read the state.
• The design includes migration/compatibility with existing usage.jsonl.
• The design includes tests or fixtures for no-secret persistence.