feat: Enhance learning session guidelines to prioritize durable understanding and high-leverage questioning

.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.

.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.

.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`

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.

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.

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

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.