VoidBot/state/map.yaml

92 lines
6.3 KiB
YAML

experiment:
name: VoidBot
status: active
phase: legibility_hardening
premise: >
Keep VoidBot operable as a Discord-native assistant with real retrieval,
durable ops, and explicit project memory surfaces instead of letting
continuity dissolve into transcript fog.
objective:
primary: >
Maintain and extend VoidBot as a Discord-native assistant for GameCult with
grounded answers from archived Discord history, indexed source trees, and
Aetheria lore, while keeping the system understandable enough to modify
safely.
current: >
Keep the new persistent state spine honest while cutting oversized runtime
organs into clearer seams before they grow another layer of moss.
constraints:
- Public traffic still rides one remote Qwen box plus local embedding and ops infrastructure.
- Owner flow and public flow share infrastructure but have different provider and safety boundaries.
- Postgres, Qdrant, Ollama, Docker, and Discord failures are operationally real; observability matters as much as features.
- Adjacent-service monitoring is allowed locally, but the public watchdog surface should stay generic and load private fire-signal logic through ignored extension hooks instead of hardcoded project gossip.
- Persistent project state must stay small enough to rehydrate from without becoming a second swamp.
invariants:
- The map is canonical and slow-changing.
- Scratch is temporary and disposable.
- Evidence is durable and distilled; routine activity proof belongs in git history, commits, smoke artifacts, or targeted logs.
- Jobs, audit events, interaction memory, and rate-limit state live in Postgres; vectors live in Qdrant; archives, artifacts, logs, and backups remain under `.voidbot/`.
- Source, repo, and lore answers must be grounded through source-side retrieval instead of vibes.
- When GameCult history, repo, or lore retrieval can answer the question, use the VoidBot MCP surfaces before raw repo spelunking.
data_flow:
observe:
- user request
- repository state
- canonical project state files
- provider and runtime health
- verifier results and smoke outputs
process:
- rehydrate from map, handoff, system map, and implementation plan
- reason over one bounded organ
- modify only the surface that deserves the change
- verify the seam that matters
- record only durable evidence that changes future belief
- commit or backtrack
cut:
- revert failed hypotheses instead of preserving churn
- distill obsolete state instead of accumulating transcript-shaped sludge
- keep persistent state lean enough that re-entry sharpens the next turn instead of drowning it
active_subgoals:
- Make the new project-state surfaces the default continuity path for nontrivial VoidBot work.
- Keep public-lane limits, moderation, and provider behavior constrained enough that one 4060 Ti box does not get flayed for sport.
- Preserve boring observability around Postgres, Qdrant, Ollama, Docker, backups, watchdogs, and any private local fire-signal extensions.
- Continue splitting oversized runtime files where concern boundaries are already obvious, starting with the remaining bot, worker, and memory-policy monarchies.
accepted_design:
- Bot, worker, providers, and RAG remain the main structural seams.
- State storage stays intentionally split: Postgres for operational state, Qdrant for vectors, `.voidbot/` for archives, artifacts, logs, and backup material.
- `owner_codex` and `local_llm` remain distinct lanes with different tool-execution and safety posture.
- The VoidBot MCP server is the preferred search plane for archived Discord, indexed GameCult repos, Aetheria lore, and owner notifications.
- Long-running work should expose durable logs or status files instead of relying on one attached session and hope.
- Persistent project memory must stay ruthlessly distilled; git history and artifacts carry routine proof.
landed_baseline:
phases:
- Discord bot, worker, provider registry, and retrieval stack are live.
- Postgres-backed jobs, audit events, interaction memory, and rate-limit state are live.
- Qdrant-backed history and source retrieval are live.
- Local and offsite backups, watchdogs, and the operations dashboard are live.
- Interaction memory and behavioral profiling are live.
- Source-grounding enforcement and tool-driven retrieval are live.
- The operations watchdog can now load ignored local extension checks, so adjacent-service fire signals can piggyback on the owner DM path without turning the public repo into cross-project gossip.
- The owner Codex lane is now split into orchestration, runtime/parsing, shared helpers, and rendering modules instead of one swollen provider file.
- The Discord bot lane is now split into a gateway shell plus dedicated command-handler and support helper modules instead of one swollen entrypoint file.
- Interaction-memory logic is now split into event/tone analysis and profile-synthesis modules instead of one slab trying to be both the ear and the therapist.
- State storage is now split into a thin factory plus per-domain Postgres/file store modules and bootstrap/migration helpers instead of one persistence omnibus.
rejected_paths:
- name: transcript_only_continuity
reason: repo complexity is now too high to trust chat fog as the only memory surface
- name: monolithic_local_state_blobs
reason: giant shared files for unrelated state hide costs and rot the next rehydrate
- name: source_answers_without_retrieval
reason: vibes produce plausible slop that sounds smart and lies with a straight face
current_status:
summary: VoidBot now has a real project-memory spine plus four legibility-hardening passes on major runtime organs. The owner Codex lane, Discord bot lane, interaction-memory logic, and state-storage persistence layer were all split into smaller seams, and the ops spine now supports ignored local watchdog extensions for adjacent fire signals without baking private infrastructure gossip into the public repo. The stack is still dense, but it no longer depends purely on transcript memory or one-file monarchies to stay coherent.
next_action: Keep using the canonical state files for re-entry, then continue decomposing the next oversized organ with the clearest concern boundaries, likely the MCP server or local LLM provider.