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

This commit is contained in:
2026-04-16 07:50:07 -06:00
parent a375b3c3b1
commit 1f57597ca3
21 changed files with 146 additions and 15 deletions

View File

@@ -69,6 +69,7 @@ When drafting messages for a manager or stakeholder:
- 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 and then answer from the refreshed inbox
- If automatic refresh is uncertain, use the explicit latest-message flow: run the Mattermost sync command, then answer from refreshed output only
- Treat all meaningful user prompts as potential memory updates, not only explicit sync commands
- Treat meaningful user corrections about workspace behavior as tool-maintenance inputs, not only as notes. If a correction affects a command, prompt, agent, skill, or knowledge rule, update that linked file directly.
- If a Mattermost sync or other context-ingestion step fails, do not update `ai/logs/`, `ai/state/`, or stable context files based on that failure
- Do not record missing dependencies, failed sync attempts, or missing inbox files as project facts unless the user explicitly asks to track the operational issue
- Auto-promote Mattermost content when it is clearly project-relevant, explicit, and high-confidence
@@ -81,6 +82,7 @@ When drafting messages for a manager or stakeholder:
- Maintain `ai/context/people/` when repeated names, roles, or stakeholder relationships become useful for future sessions
- Update existing memory when the new information is a correction, clarification, or refinement of something already stored
- Prefer updating stable project context over appending generic operational summaries
- Do not leave reusable behavior rules only in daily logs. Promote them to the prompt, command, agent, skill, or process file that controls future behavior.
- Do not create daily log entries for tooling activity, sync status, or generic chat noise
- For Swift/iOS best-practice answers, distinguish current Apple guidance from project-safe recommendations when Fidelity constraints may change the answer
- For Copilot prompts, include only relevant context, tell Copilot what to inspect, and state constraints, non-goals, expected output, and validation
@@ -93,6 +95,12 @@ When drafting messages for a manager or stakeholder:
- `ai/context/people/index.md` for active roster mapping
- `ai/context/people/<person>.md` for person-specific context
- `ai/context/decisions/*.md` for confirmed decisions
- If the new fact changes how this workspace should operate, update the linked tool surface as well:
- `.opencode/commands/*.md` for slash-command behavior
- `prompts/*.md` for reusable output templates
- `.opencode/agents/*.md` and `ai/AGENTS.md` for default agent behavior
- `.opencode/skills/*/SKILL.md` for specialized workflows
- `knowledge/*.md` or `ai/context/process/*.md` for durable process rules
- Prefer updating stale context over leaving conflicting statements in different files
- If context is still uncertain, record it in the daily log rather than promoting it to a stable context file