diff --git a/.opencode/agents/fidelity.md b/.opencode/agents/fidelity.md index 758f4e2..44a6afc 100644 --- a/.opencode/agents/fidelity.md +++ b/.opencode/agents/fidelity.md @@ -26,6 +26,9 @@ Behavior rules: - Before answering a prompt that depends on current state, verify the latest relevant files instead of relying only on conversation history. - If the prompt asks for the latest Mattermost message, the last message from Jeff/current manager, or what someone just said, force a Mattermost refresh before answering and do not rely on stale inbox context. - For learning-style questions, answer from known context and verified facts only; explicitly label unknowns, assumptions, and inferences. +- For learning sessions, prioritize durable architecture, process, ownership, debugging strategy, release mechanics, domain concepts, and decision rules over transient ticket status. +- If the user asks what to clarify, ask 3 to 5 high-leverage questions that would help a senior iOS engineer ramp into the project; include why each question matters. +- Do not turn learning sessions into standup preparation unless the user explicitly asks for status or daily-progress learning. - If missing context materially affects the answer, ask a concise clarification question instead of inventing details. - If the user corrects or teaches the agent during a learning session, update the smallest correct canonical file or behavior surface so future sessions benefit. - For any meaningful prompt, decide whether the interaction adds, corrects, or sharpens project memory. diff --git a/.opencode/agents/workspace.md b/.opencode/agents/workspace.md index 377e38b..2f99d46 100644 --- a/.opencode/agents/workspace.md +++ b/.opencode/agents/workspace.md @@ -20,6 +20,8 @@ Behavior rules: - When updating canonical vault notes, maintain relationship metadata and `updated` fields so the vault remains useful to both humans and agents. - Before answering current-state questions, inspect current state, active work items, recent logs, and inbox evidence when available. - For learning-style questions, answer only from known context and verified facts, label assumptions and unknowns, and ask concise clarification questions when guessing would be misleading. +- For learning sessions, prefer durable architecture, process, ownership, debugging strategy, release mechanics, domain concepts, and decision rules over transient status. +- If the user asks what to clarify, propose 3 to 5 high-leverage questions and explain why each matters for future reasoning. - Treat user corrections during learning sessions as high-value input and update the smallest correct canonical file or behavior surface when the learning should persist. - For any meaningful prompt, decide whether it adds, corrects, or invalidates memory. - Update the smallest correct canonical file when memory should change. diff --git a/.opencode/commands/sync-context.md b/.opencode/commands/sync-context.md index e2d8663..0853900 100644 --- a/.opencode/commands/sync-context.md +++ b/.opencode/commands/sync-context.md @@ -30,6 +30,8 @@ Instructions: - use `workspace-memory-curation` when available - Treat direct user corrections and learning-session updates as memory sources. +- For learning-session updates, prefer durable project understanding over transient ticket status. +- Route durable learning to architecture/process/system/workstream notes; route only truly current operational state to `vault/01-current/` or `vault/06-daily/`. - If the new information corrects the agent's uncertainty handling or recurring behavior, update the command, prompt, agent, skill, or process rule that controls that behavior. - Decide whether the new information belongs in: - today's daily note: `vault/06-daily/$(date +%F).md` diff --git a/AGENTS.md b/AGENTS.md index d25f5eb..9a34190 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -47,6 +47,8 @@ These are also loaded through `opencode.json`. - If the user asks for the latest/last/recent Mattermost message, the latest message from Jeff/current manager, or what someone just said, synchronize Mattermost first instead of relying on existing inbox context. - If automatic refresh is uncertain, use the explicit latest-message flow: run the Mattermost sync command, then answer from the refreshed inbox only. - For learning-style questions, answer from known context and verified facts only; label unknowns, assumptions, and inferences instead of inventing missing details. +- For learning sessions, prioritize durable architecture, process, ownership, debugging strategy, release mechanics, domain concepts, and decision rules over transient ticket status. +- If the user asks what to clarify, ask 3 to 5 high-leverage questions that would help a senior engineer ramp into the project, and include why each matters. - Ask a concise clarification question when missing context materially changes the answer. - If the user corrects or teaches the agent during a learning session, update the smallest correct canonical file or behavior surface when that learning should persist. - For any meaningful prompt, decide whether the interaction introduces or corrects project memory. diff --git a/core/memory/operational-memory.md b/core/memory/operational-memory.md index 80eeebb..0afcf29 100644 --- a/core/memory/operational-memory.md +++ b/core/memory/operational-memory.md @@ -116,6 +116,8 @@ If confidence is mixed, prefer the daily log and preserve uncertainty. A learning session is any interaction where the user asks the agent to explain, reason about, or improve understanding of a topic and may then correct or extend the answer. +Learning sessions are for durable understanding, not for standup status collection. + The agent should: - answer from known workspace context and verified sources only @@ -123,10 +125,20 @@ The agent should: - avoid inventing missing context, names, tickets, implementation details, or causal explanations - ask a concise clarification question when the missing information materially affects the answer - provide a partial answer when useful, clearly labeling assumptions and uncertainty +- prioritize architecture, system boundaries, ownership, release process, debugging strategy, reusable workflows, domain concepts, and decision rules +- avoid defaulting to in-progress ticket status unless the user asks for current work or the status exposes a durable process/architecture gap +- ask questions that would help a senior engineer ramp into the project, not questions that merely refresh the latest daily update - treat user corrections as high-value learning input - update the smallest correct canonical file when the correction changes future behavior or project understanding - avoid turning every answer into memory; promote only reusable or project-relevant learning +When proposing clarification questions, keep them concise and high-leverage: + +- prefer 3 to 5 questions +- group by durable learning area +- state why each question matters for future reasoning +- avoid multi-level status checklists + When the user is teaching the agent how to behave, update `tooling-behavior`. When the user is teaching project/domain facts, update the relevant `state`, `work-items`, `stable-context`, `people`, or `decisions` file. diff --git a/vault/03-context/process/agent-memory-rules.md b/vault/03-context/process/agent-memory-rules.md index 1314086..f9f039c 100644 --- a/vault/03-context/process/agent-memory-rules.md +++ b/vault/03-context/process/agent-memory-rules.md @@ -38,12 +38,16 @@ The agent should support incremental self-learning sessions. When the user asks a question, the agent may answer from existing context, but must not invent missing facts. +Learning sessions should improve durable project understanding. They are not the same as standup preparation, daily status refresh, or ticket triage unless the user explicitly asks for that. + The agent should: - say what is known from the workspace - say what is unclear or not available - label assumptions and inferences explicitly - ask a concise clarification question when the missing context materially changes the answer +- focus clarification questions on architecture, process, ownership, debugging patterns, domain concepts, release mechanics, and decision rules +- avoid asking mostly about transient ticket state unless the answer would clarify a durable project rule - learn from user corrections or confirmations by updating the smallest correct canonical file - avoid promoting unconfirmed exploration as durable truth @@ -53,9 +57,25 @@ Good learning behavior: - If the answer is partly clear, answer the known part, state the gap, and ask for the missing detail. - If the user corrects the answer, update the stale memory or behavior rule directly. - If the user teaches a reusable workflow preference, update the relevant command, prompt, skill, agent rule, or process note. +- If the user asks what the agent wants to clarify, propose 3 to 5 high-leverage questions that would help a senior engineer ramp into the project. Do not ask for clarification just to avoid work. Ask only when the missing context is material or when guessing would create misleading memory. +Avoid low-value learning-session questions such as: + +- whether a specific PR was approved today +- whether a ticket moved columns today +- what the next standup line should be +- temporary sequencing questions that belong in `vault/01-current/` or `vault/06-daily/` + +Prefer high-value questions such as: + +- what determines ownership between SDK, adapter, feature module, app, and backend configuration +- how release propagation works across SDK, adapter, consuming app, and validation environment +- what invariants define REST vs GraphQL parity +- how authenticated and non-authenticated flows differ operationally +- what evidence is required before classifying an external issue as a regression + --- ## What Counts As Memory-Worthy diff --git a/vault/03-context/process/context-maintenance.md b/vault/03-context/process/context-maintenance.md index bf23ce3..9b5d309 100644 --- a/vault/03-context/process/context-maintenance.md +++ b/vault/03-context/process/context-maintenance.md @@ -38,6 +38,9 @@ Keep this workspace useful as living memory instead of a pile of disconnected no ## 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.