david.delagneau
374991a568
- Deleted obsolete files: obsidian-vault.md, onboarding.md, workspace-model.md - Updated opencode.json to remove references to deleted files. - Revised profile.md to clarify the status of legacy paths and communication evidence. - Adjusted prompts to reflect new file paths and improve clarity. - Enhanced daily logs with focus, work-items, and blockers properties. - Updated work-item notes to include systems, workstreams, people, and related properties. - Improved context maintenance guidelines to ensure accurate and durable project knowledge. - Refined base filters to exclude template files and ensure only relevant notes are displayed. - Updated daily templates to ensure proper formatting and consistency. - Modified workflows to align with the new vault structure and improve context synchronization.
3.3 KiB
Operational Memory
Definition
Operational memory is a versionable file-based system where the agent decides whether each interaction introduces, corrects, or invalidates knowledge, then updates the smallest correct canonical file.
The goal is not transcript storage. The goal is a curated working memory that improves future reasoning, communication, and execution.
Memory Classes
daily
Use for same-day progress, findings, evolving reproduction notes, and work that may change soon.
Default path pattern:
vault/06-daily/YYYY-MM-DD.md
state
Use for current priorities, active blockers, near-term constraints, and communication needs that affect the next few days.
Default paths:
vault/01-current/current-work.md
vault/01-current/work-items.md
work-items
Use for canonical memory about active tickets, tasks, stories, investigations, or other units of work.
Default path pattern:
vault/02-work-items/<id-or-slug>.md
stable-context
Use for durable project knowledge that should survive beyond the current work window.
Default path pattern:
vault/03-context/<domain>/*.md
people
Use for repeated collaborators, role mappings, manager/stakeholder context, and communication preferences.
Default path pattern:
vault/04-people/*.md
decisions
Use for confirmed decisions with ongoing impact.
Default path pattern:
vault/05-decisions/*.md
tooling-behavior
Use when a user correction changes how the workspace should behave in the future.
Default path patterns:
.opencode/commands/*.md
.opencode/agents/*.md
.opencode/skills/*/SKILL.md
prompts/*.md
vault/00-start/*.md
vault/03-context/process/*.md
Raw evidence stays outside vault/; promoted memory is written to vault/.
Promotion Rules
Promote information when it is:
- explicit enough to preserve safely
- relevant to the current project or workflow
- likely to matter in a future session
- useful for standups, status updates, debugging, planning, or decision making
Do not promote:
- tool failures
- sync attempts
- empty inbox states
- generic chat noise
- unverified guesses
- duplicate paraphrases of existing memory
If confidence is mixed, prefer the daily log and preserve uncertainty.
Correction Rules
When new information supersedes old memory:
- update the existing canonical file directly
- do not leave stale and corrected versions side by side
- preserve qualifiers when the fact remains partially confirmed
- update indexes when adding new stable context files
The agent should behave like a senior engineer maintaining project notes, not like a transcript accumulator.
Self-Maintenance Rules
When the user corrects recurring output or behavior, update the operational surface that controls that behavior.
Examples:
- standup format correction -> update
prompts/standup.mdand the standup command - communication freshness correction -> update the communication sync command/plugin
- prompt-engineering correction -> update the AI prompt command or skill
- memory routing correction -> update memory rules and context-maintenance guidance
The daily log may preserve evidence, but reusable behavior must live in the command, prompt, skill, agent, or knowledge file that enforces it.