Memory And Review
How project memory, review artifacts, and docs updates stay aligned with runtime reality.
What “memory” means in this repo
Memory here is not only model memory. It also includes:
.ai/current-state.md.ai/tasks.md.ai/decisions.md- runtime review artifacts
- persisted traces and context packs
- docs pages that explain current working assumptions
Why this matters
A repo this size becomes harder to maintain if implementation, docs, and working assumptions drift apart. The fastest way to make future work slower is to leave behind stale project memory.
When to update repo memory
Update .ai notes when a change affects:
- runtime behavior
- product direction
- developer workflow
- frontend or docs architecture
- QA expectations
- safety boundaries
Review posture
When reviewing a suspicious result, prefer inspectable evidence:
- typed provider or market artifacts
- runtime state and logs
- specialist and manager outputs
- persisted review snapshots
- UI behavior
Do not jump straight from “the answer feels wrong” to “the prompt must be rewritten”.
Docs responsibility
This docs site is part of project memory. Whenever a durable decision changes, the right follow-up is usually:
- update the implementation
- update the relevant docs page
- update
.ai/current-state.md - update
.ai/decisions.md - update
.ai/tasks.mdif work remains
Feedback flow in plain language
The GitHub Pages docs build cannot write to the repository filesystem. Its feedback widget stores a short browser-local draft and prepares a prefilled GitHub issue link for manual submission.
If a future Node-hosted docs instance re-enables server-side feedback, it should keep local auditability explicit and avoid pretending that external forwarding succeeded when it did not.