Add project-knowledge structure and templates
- Introduced new maps for navigating project knowledge, including "Current Work," "Fidelity Domain," "Fidelity Apps," "Work Items," and "People." - Created base files for daily notes, decisions, people, systems, work items, and workstreams with defined properties and views. - Developed templates for daily notes, decisions, meeting notes, persons, systems, work items, and workstreams to standardize documentation. - Updated scripts and prompts to reflect the new project-knowledge directory structure. - Removed outdated onboarding and start-here documents, consolidating relevant information into the new maps. - Ensured all references in workflows and scripts point to the new project-knowledge paths.
This commit is contained in:
54
agent-memory/memory/context-maintenance.md
Normal file
54
agent-memory/memory/context-maintenance.md
Normal file
@@ -0,0 +1,54 @@
|
||||
---
|
||||
type: agent-memory
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- process
|
||||
- memory
|
||||
---
|
||||
# Context Maintenance
|
||||
|
||||
## Goal
|
||||
|
||||
Keep this workspace useful as living memory instead of a pile of disconnected notes.
|
||||
|
||||
---
|
||||
|
||||
## Stable Rules
|
||||
|
||||
- Update canonical context when a durable fact changes.
|
||||
- Prefer correcting stale context over appending contradictory notes.
|
||||
- If a canonical note appears in an Obsidian Base, update its frontmatter properties together with the prose content.
|
||||
- When changing frontmatter properties on existing canonical notes, prefer Obsidian CLI property operations through `scripts/obsidian/cli.sh` when available so YAML spacing and property formatting stay clean; fall back to direct Markdown edits only when the CLI is unavailable or the operation is unsupported.
|
||||
- Keep templates under `project-knowledge/09-templates/` out of real-note Bases by filtering the template folder.
|
||||
- Role mapping files should not use `type: person`; reserve `type: person` for actual people profiles.
|
||||
- Work-item notes should keep known `systems`, `workstreams`, `people`, and `related` properties current.
|
||||
- Daily notes should keep `focus`, `work-items`, and `blockers` properties current when the values are clear.
|
||||
- Use the smallest correct destination:
|
||||
- `project-knowledge/06-daily/YYYY-MM-DD.md` for daily progress and evolving findings
|
||||
- `project-knowledge/01-current/current-work.md` for near-term active work
|
||||
- `project-knowledge/02-work-items/*.md` for canonical Jira-linked active work
|
||||
- `project-knowledge/01-current/work-items.md` for the compact active-work summary
|
||||
- `project-knowledge/03-context/` for durable project knowledge
|
||||
- `project-knowledge/04-people/` for named person context
|
||||
- `.opencode/commands/`, `prompts/`, `.opencode/agents/`, `.opencode/skills/`, `agent-memory/`, `core/`, or `scripts/` for reusable behavior rules that control how the workspace responds
|
||||
|
||||
---
|
||||
|
||||
## Ingestion Rules
|
||||
|
||||
- Treat Mattermost, Slack history, and direct prompts as potential memory sources.
|
||||
- Treat learning sessions as durable-understanding sessions, not status refreshes.
|
||||
- In learning sessions, prioritize architecture, ownership, release mechanics, debugging strategy, domain concepts, and process rules.
|
||||
- Avoid promoting transient ticket status from learning sessions unless it exposes a reusable rule.
|
||||
- Do not promote failed syncs or tooling errors as project facts.
|
||||
- Promote repeated durable patterns from historical archives into stable context when confidence is high.
|
||||
- Keep old status-only details archive-only unless they still change current understanding.
|
||||
- Treat user corrections about command output, prompt structure, memory handling, or agent behavior as inputs to the operational surface, not just as daily notes.
|
||||
|
||||
---
|
||||
|
||||
## Curation Rule
|
||||
|
||||
- If a new stable context file is added, keep `project.md` and `index.md` aligned so future sessions can discover it quickly.
|
||||
- If a new rule affects a slash command or reusable prompt, update that command or prompt directly so the behavior changes on the next run.
|
||||
39
agent-memory/memory/operational-memory.md
Normal file
39
agent-memory/memory/operational-memory.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
type: agent-memory
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- memory
|
||||
- operations
|
||||
---
|
||||
|
||||
# Operational Memory
|
||||
|
||||
Operational memory is the mechanism that turns daily evidence into durable, searchable project knowledge.
|
||||
|
||||
The reusable model lives in `core/memory/operational-memory.md`. This file records the active agent-specific interpretation for this workspace.
|
||||
|
||||
---
|
||||
|
||||
## Memory Classes
|
||||
|
||||
- `daily`: dated progress and evidence in `project-knowledge/06-daily/`.
|
||||
- `state`: near-term active work in `project-knowledge/01-current/`.
|
||||
- `work-items`: ticket-scoped memory in `project-knowledge/02-work-items/`.
|
||||
- `stable-context`: durable systems, workstreams, process, and iOS context in `project-knowledge/03-context/`.
|
||||
- `people`: collaborators, stakeholders, and role mappings in `project-knowledge/04-people/`.
|
||||
- `decisions`: accepted durable decisions in `project-knowledge/05-decisions/`.
|
||||
- `tooling-behavior`: agent and workspace behavior in `agent-memory/`, `.opencode/`, `prompts/`, `scripts/`, and `core/`.
|
||||
|
||||
---
|
||||
|
||||
## Evidence Boundary
|
||||
|
||||
Raw evidence stays outside project knowledge:
|
||||
|
||||
- `ai/inbox/`
|
||||
- `scripts/mattermost/generated/`
|
||||
- `scripts/slack/generated/`
|
||||
|
||||
Only curated, high-confidence project facts should be promoted into `project-knowledge/`.
|
||||
|
||||
145
agent-memory/memory/promotion-rules.md
Normal file
145
agent-memory/memory/promotion-rules.md
Normal file
@@ -0,0 +1,145 @@
|
||||
---
|
||||
type: agent-memory
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags: [process, memory, promotion]
|
||||
---
|
||||
|
||||
# Memory Promotion Rules
|
||||
|
||||
## Goal
|
||||
|
||||
Keep workspace memory current automatically without asking the user what to promote after every successful sync.
|
||||
|
||||
---
|
||||
|
||||
## Default Rule
|
||||
|
||||
When new Mattermost context is explicit, project-relevant, and high-confidence, promote it automatically.
|
||||
|
||||
Do not ask for promotion confirmation by default.
|
||||
|
||||
If a fact is ambiguous, skip it or keep it only in the daily log with appropriate qualifiers.
|
||||
|
||||
---
|
||||
|
||||
## File Selection
|
||||
|
||||
### Promote to `project-knowledge/06-daily/YYYY-MM-DD.md`
|
||||
|
||||
Use the daily log for:
|
||||
|
||||
- concrete same-day work updates
|
||||
- story creation, sizing, approval, and scope updates
|
||||
- manager-approved wording or root-cause framing tied to current work
|
||||
- confirmed version checks tied to active work
|
||||
- reproduction findings that are useful now but may still evolve
|
||||
|
||||
Daily logs are the default destination for most promoted Mattermost facts.
|
||||
|
||||
### Promote to `project-knowledge/01-current/current-work.md`
|
||||
|
||||
Use current state only for facts that materially affect active work over the next few days, such as:
|
||||
|
||||
- approved active story scope
|
||||
- confirmed current debugging constraints
|
||||
- current reproduction conditions that change how the work is approached
|
||||
- near-term priorities confirmed by manager communication
|
||||
|
||||
Do not copy every daily update into current state.
|
||||
|
||||
### Promote to `project-knowledge/02-work-items/*.md` and `project-knowledge/01-current/work-items.md`
|
||||
|
||||
Use `project-knowledge/02-work-items/*.md` for:
|
||||
|
||||
- explicit Jira IDs
|
||||
- approved or explicit story titles
|
||||
- current story points
|
||||
- current scope notes
|
||||
- active status notes that still matter for future updates
|
||||
|
||||
If a Jira item is likely to appear again in standups or manager updates, it belongs here.
|
||||
|
||||
Use `project-knowledge/01-current/work-items.md` as the compact summary of which ticket files are active.
|
||||
|
||||
### Promote to `project-knowledge/03-context/project.md`
|
||||
|
||||
Use project context only for durable project knowledge that should survive beyond the current work window, such as:
|
||||
|
||||
- stable architecture constraints
|
||||
- recurring debugging truths
|
||||
- persistent testing limitations
|
||||
- enduring behavior of REST, GraphQL, XFlow, auth, or entry points
|
||||
|
||||
Do not promote story-specific daily movement into project context unless it changes durable project understanding.
|
||||
|
||||
### Promote to `project-knowledge/05-decisions/*.md`
|
||||
|
||||
Use decisions only for explicit confirmed decisions with medium or long-term impact.
|
||||
|
||||
### Promote to `project-knowledge/04-people/index.md` and `project-knowledge/04-people/*.md`
|
||||
|
||||
Use these files when:
|
||||
|
||||
- a person's identity matters repeatedly
|
||||
- a role becomes associated with a specific person
|
||||
- a stakeholder's communication or approval patterns affect future work
|
||||
- a human appears across multiple channels or years with repeated technical, process, or approval signal
|
||||
- the archive makes the collaboration pattern clear even if the formal title is still unknown
|
||||
|
||||
Prefer:
|
||||
|
||||
- `manager.md` for role mapping
|
||||
- `index.md` for active roster
|
||||
- one file per person for person-specific context
|
||||
|
||||
If exact role confidence is low, store the person's repeated project relationship instead of inventing a title.
|
||||
|
||||
---
|
||||
|
||||
## Do Not Promote
|
||||
|
||||
Do not record these as project memory:
|
||||
|
||||
- tooling activity
|
||||
- sync status
|
||||
- missing dependencies
|
||||
- empty inbox situations
|
||||
- reminders or urgency without project substance
|
||||
- unapproved drafts
|
||||
- generic chat noise
|
||||
|
||||
---
|
||||
|
||||
## Confidence Rules
|
||||
|
||||
Auto-promote when the signal is high-confidence, for example:
|
||||
|
||||
- the manager explicitly approves something
|
||||
- a Jira story number, title, points, or scope is explicitly confirmed
|
||||
- a version is stated directly and tied to the active project
|
||||
- a reproduction condition is clearly stated with scope qualifiers
|
||||
|
||||
If confidence is mixed:
|
||||
|
||||
- prefer the daily log
|
||||
- preserve qualifiers such as "appears", "currently", or "for authenticated users"
|
||||
- avoid promoting to stable project context
|
||||
|
||||
---
|
||||
|
||||
## Example Policy
|
||||
|
||||
Given Mattermost updates like:
|
||||
|
||||
- PDIAP-15836 created and sized at 8 points
|
||||
- the manager approved a story title
|
||||
- REST-removal scope was approved
|
||||
- XFlowViewMaker 0.5.0 is already in Fid4
|
||||
- AO DOB validation issue appears auth-only in TeenIdentityCheck
|
||||
|
||||
Automatic behavior should be:
|
||||
|
||||
- add all of them to today's log if they are relevant to today's work
|
||||
- promote only the currently actionable subset to `project-knowledge/01-current/current-work.md`
|
||||
- keep story-specific details out of `project-knowledge/03-context/project.md` unless they reveal a durable project rule
|
||||
Reference in New Issue
Block a user