david.delagneau
b82194bc55
- Created daily log entries for April 13-16, 2026, capturing standup contexts, Mattermost syncs, and ongoing work items. - Established a daily logs index for easy navigation of daily entries. - Introduced templates for daily notes, decisions, meeting notes, people, systems, and work items to standardize documentation. - Developed maps for AI workspace core, current work, Fidelity domain, and work items to enhance workspace navigation. - Implemented base configurations for daily notes, decisions, people, systems, work items, and workstreams to streamline data management. - Added a placeholder for attachments to facilitate file organization.
183 lines
5.4 KiB
Markdown
183 lines
5.4 KiB
Markdown
---
|
|
type: process
|
|
project: fidelity
|
|
status: active
|
|
updated: 2026-04-16
|
|
tags: [process, memory, agent]
|
|
---
|
|
|
|
# Agent Memory Rules
|
|
|
|
## Goal
|
|
|
|
Make workspace memory maintenance part of the agent's normal job, not a separate optional workflow.
|
|
|
|
---
|
|
|
|
## Default Agent Behavior
|
|
|
|
For any meaningful prompt, the agent should decide whether the interaction changes project memory.
|
|
|
|
This applies to:
|
|
|
|
- direct user prompts
|
|
- Mattermost sync results
|
|
- translated notes
|
|
- standup generation
|
|
- manager-update drafting
|
|
- debugging discussions
|
|
- corrections to previous understanding
|
|
|
|
The agent should not wait for a separate promotion command when the right update is already clear.
|
|
|
|
---
|
|
|
|
## What Counts As Memory-Worthy
|
|
|
|
Capture information automatically when it is:
|
|
|
|
- project-relevant
|
|
- explicit enough to preserve safely
|
|
- likely to matter in a future session
|
|
- useful for standups, debugging, or supervisor communication
|
|
|
|
Examples:
|
|
|
|
- confirmed story creation, points, scope, or priority
|
|
- confirmed reproduction constraints
|
|
- newly clarified root cause framing
|
|
- approved manager guidance that changes work direction
|
|
- confirmed version, dependency, or rollout facts tied to current work
|
|
- corrections to previously stored project context
|
|
- repeated named people with stable roles or communication relevance
|
|
- repeated named people with multi-channel, multi-year, or high-signal technical/process involvement even when the exact formal role is still unknown
|
|
|
|
---
|
|
|
|
## What The Agent Must Do
|
|
|
|
When new memory-worthy information appears, the agent should:
|
|
|
|
1. decide whether it is daily, current-state, durable, or decision-level context
|
|
2. update the smallest correct set of files
|
|
3. correct stale or conflicting existing statements
|
|
4. answer the user using the refreshed context
|
|
|
|
Do not ask the user what to promote unless the ambiguity is real and material.
|
|
|
|
---
|
|
|
|
## Tooling Self-Maintenance
|
|
|
|
User corrections about how the workspace should behave are memory-worthy when they affect future output.
|
|
|
|
If a correction applies to a command, prompt, skill, agent, or reusable rule, update the linked tool directly instead of only logging the correction.
|
|
|
|
Examples:
|
|
|
|
- A standup formatting correction should update `prompts/standup.md` and `.opencode/commands/standup.md`.
|
|
- A Mattermost freshness correction should update the Mattermost command/plugin instructions.
|
|
- A Copilot prompt-structure correction should update `prompts/copilot-prompt.md`, `.opencode/commands/copilot-prompt.md`, or the Copilot skill.
|
|
- A Swift answer-quality correction should update the relevant iOS skill or `vault/03-context/ios/` guidance.
|
|
|
|
Keep the daily log as evidence of what happened, but make the reusable behavior live in the file that controls that behavior.
|
|
|
|
---
|
|
|
|
## File Selection
|
|
|
|
### `vault/06-daily/YYYY-MM-DD.md`
|
|
|
|
Default destination for:
|
|
|
|
- same-day progress
|
|
- same-day findings
|
|
- scoped reproduction notes
|
|
- story and approval movement
|
|
- context that is important now but may evolve later
|
|
|
|
### `vault/01-current/current-work.md`
|
|
|
|
Use when the fact changes the active work window, including:
|
|
|
|
- current priorities
|
|
- currently active story scope
|
|
- current blockers or debugging constraints
|
|
- manager direction that changes the next few days of work
|
|
|
|
### `vault/02-work-items/*.md` and `vault/01-current/work-items.md`
|
|
|
|
Use `vault/02-work-items/*.md` as the canonical memory for current Jira-linked work that should remain easy to reference across sessions, especially:
|
|
|
|
- Jira IDs
|
|
- approved or explicit titles
|
|
- currently relevant status notes
|
|
- current points or scope notes
|
|
|
|
Use `vault/01-current/work-items.md` as the summary view of what is active now.
|
|
|
|
These files should help standups and manager updates mention work items precisely.
|
|
|
|
### `vault/03-context/project.md`
|
|
|
|
Use for durable project knowledge that should survive beyond the current work window.
|
|
|
|
### `vault/04-people/manager.md`
|
|
|
|
Use only when a communication preference or manager expectation becomes stable enough to reuse repeatedly.
|
|
|
|
### `vault/04-people/index.md` and `vault/04-people/*.md`
|
|
|
|
Use these files for:
|
|
|
|
- mapping roles to actual people
|
|
- keeping named stakeholders recognizable across sessions
|
|
- storing stable communication or responsibility context per person
|
|
|
|
When the role is not explicit, store:
|
|
|
|
- where the person tends to appear
|
|
- what kinds of topics they influence
|
|
- how they affect approvals, scope, debugging, or communication
|
|
|
|
### `vault/05-decisions/*.md`
|
|
|
|
Use for explicit confirmed decisions with ongoing impact.
|
|
|
|
### `.opencode/commands/`, `prompts/`, `.opencode/agents/`, `.opencode/skills/`, `vault/00-start/`, and `vault/03-context/process/`
|
|
|
|
Use these when the new information changes how the workspace should operate:
|
|
|
|
- command invocation behavior
|
|
- reusable output format
|
|
- default agent behavior
|
|
- specialized skill workflow
|
|
- persistent process or memory rules
|
|
|
|
Do not create a separate note when an existing command, prompt, agent, or skill is the source of truth.
|
|
|
|
---
|
|
|
|
## What Not To Store
|
|
|
|
Do not store:
|
|
|
|
- tool failures
|
|
- sync attempts
|
|
- generic urgency messages
|
|
- duplicate paraphrases of the same fact
|
|
- weak guesses
|
|
- operational chatter that does not change project understanding
|
|
|
|
---
|
|
|
|
## Correction Rule
|
|
|
|
If new information supersedes old memory:
|
|
|
|
- update the existing canonical file
|
|
- do not leave stale and corrected versions side by side
|
|
- preserve qualifiers if the fact is only partially confirmed
|
|
|
|
The agent should behave like a senior engineer maintaining project notes, not like a chat assistant accumulating transcripts.
|