feat: Update behavior rules and documentation for workspace maintenance and flow references

knowledge/agent-memory-rules.md

@@ -59,6 +59,23 @@ 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 `ai/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
 
 ### `ai/logs/YYYY-MM-DD.md`
@@ -119,6 +136,18 @@ When the role is not explicit, store:
 
 Use for explicit confirmed decisions with ongoing impact.
 
+### `.opencode/commands/`, `prompts/`, `.opencode/agents/`, `.opencode/skills/`, and `knowledge/`
+
+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

knowledge/communication-rules.md

@@ -16,6 +16,8 @@ These rules keep standups, Jira notes, and Mattermost messages aligned with the
 - Distinguish clearly between the current issue, unrelated preexisting bugs, workarounds, and follow-up work
 - Prefer evidence-backed statements over intuition when communicating status
 - Include branch, build, environment, account, flow, or entry-point details when they materially affect reproduction or ownership
+- When reporting several updates for the same Jira item, group them under one top-level `JIRA-ID - Title` bullet with indented markdown sub-bullets
+- Use real flow identifiers and page names when shorthand could be ambiguous
 - Route ownership explicitly when the issue belongs to a consumer app, service/configuration, or another framework instead of XFlow
 - Do not present a fix as ready if it introduces a new bug or unresolved regression
 - Administrative/project-tracking updates should be prompt when others are visibly waiting on them

knowledge/workspace-model.md

@@ -13,6 +13,7 @@ This repository is a support workspace, not the implementation repository.
 - manager update drafts
 - stable project knowledge
 - debugging summaries
+- reusable command, prompt, skill, and agent rules that make the workspace behave consistently
 
 ---
 
@@ -21,3 +22,17 @@ This repository is a support workspace, not the implementation repository.
 - product source code
 - assumptions about code changes not yet verified
 - statements that imply work was executed from this machine unless explicitly true
+
+---
+
+## Operational Surface
+
+When the user corrects a recurring behavior, the workspace should update the file that controls that behavior:
+
+- `.opencode/commands/` for slash commands
+- `prompts/` for reusable drafting templates
+- `.opencode/agents/` and `ai/AGENTS.md` for default agent behavior
+- `.opencode/skills/` for specialized workflows
+- `knowledge/` and `ai/context/process/` for durable process rules
+
+Daily logs can preserve evidence, but they should not be the only place where a reusable behavior rule lives.