david.delagneau
1ad707373a
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
96 lines
9.5 KiB
Markdown
96 lines
9.5 KiB
Markdown
# Fidelity AI Workspace Rules
|
|
|
|
This repository is a companion workspace for Fidelity iOS work, not the product codebase.
|
|
|
|
OpenCode should treat this project as a persistent context layer used to:
|
|
|
|
- keep current project state accurate
|
|
- capture durable information from daily work
|
|
- draft standups and Mattermost messages
|
|
- improve communication for the current manager or stakeholder in natural professional English
|
|
|
|
## Hot Context
|
|
|
|
Keep the always-loaded context small. The hot set is:
|
|
|
|
- `profiles/fidelity/profile.md`
|
|
- `agent-memory/behavior/agent-behavior.md`
|
|
- `agent-memory/behavior/learning-sessions.md`
|
|
- `agent-memory/memory/promotion-rules.md`
|
|
- `agent-memory/integrations/technical-verification.md`
|
|
- `agent-memory/workflows/ai-to-ai-prompting.md`
|
|
- `workspaces/fidelity/project-knowledge/00-start/start-here.md`
|
|
- `workspaces/fidelity/project-knowledge/01-current/current-work.md`
|
|
- `workspaces/fidelity/project-knowledge/01-current/work-items.md`
|
|
- `workspaces/fidelity/project-knowledge/03-context/project.md`
|
|
- `workspaces/fidelity/project-knowledge/03-context/process/communication.md`
|
|
- `workspaces/fidelity/project-knowledge/03-context/ios/index.md`
|
|
- `workspaces/fidelity/project-knowledge/03-context/ios/project-swift-guidance.md`
|
|
- `workspaces/fidelity/project-knowledge/04-people/manager.md`
|
|
- `workspaces/fidelity/project-knowledge/04-people/index.md`
|
|
|
|
Load everything else lazily when the task actually needs it.
|
|
|
|
Do not preemptively load broad context sets, all work-item files, or all process notes unless the current task clearly requires them.
|
|
|
|
## Required Behavior
|
|
|
|
- Assume the workspace may contain stale context until checked.
|
|
- Treat `workspaces/fidelity/project-knowledge/` as the canonical clean project memory for humans and AI. Treat `agent-memory/` as agent operating memory. Treat `workspaces/fidelity/inbox/` as raw evidence only.
|
|
- Treat `scripts/memory/` as the project-agnostic interface for creating notes, searching memory, querying Bases, and running project knowledge health checks.
|
|
- Treat `scripts/obsidian/` as the current Obsidian adapter, not as the core memory abstraction.
|
|
- Keep Obsidian Bases clean: templates in `workspaces/fidelity/project-knowledge/09-templates/` must not be treated as real notes, and role mapping files such as `workspaces/fidelity/project-knowledge/04-people/manager.md` must not be typed as people.
|
|
- Maintain useful project-note properties when editing canonical notes, especially work-item relationships (`systems`, `workstreams`, `people`, `related`) and daily note fields (`focus`, `work-items`, `blockers`).
|
|
- Before answering questions that depend on current work state, inspect `workspaces/fidelity/project-knowledge/01-current/current-work.md` and the latest relevant daily note under `workspaces/fidelity/project-knowledge/06-daily/`.
|
|
- Prefer lazy loading over eager loading. Pull in only the smallest relevant files for the active task.
|
|
- For Mattermost evidence, prefer the local proxy mirror under `workspaces/fidelity/inbox/mattermost-mirror/` when present. Use `scripts/mattermost-proxy/read-context.py` or mirror views (`latest.*`, `by-date/`, `channels/`, `threads/`) before falling back to legacy `workspaces/fidelity/inbox/mattermost-latest.md` or `scripts/mattermost/generated/` artifacts.
|
|
- If the user asks for the latest/last/recent Mattermost message, the latest message from Jeff/current manager, or what someone just said, use the explicit latest-message flow and answer from the freshest refreshed evidence; the proxy mirror is primary when available.
|
|
- If automatic refresh is uncertain and the proxy mirror is not available, run the Mattermost sync command, then answer from the refreshed inbox only.
|
|
- Treat latest-message flows as read-first. Report memory update candidates, but do not edit canonical memory from that command unless the user explicitly asks to promote the fact.
|
|
- 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.
|
|
- For analysis, review, translation, or drafting requests, answer first unless a memory update is required to avoid losing a clear durable fact.
|
|
- Do not create new canonical notes before answering unless the user asked to save the information, the destination is obvious, and the write is small and non-blocking.
|
|
- Prefer updating existing canonical files over creating new files during the critical path of a user-facing answer.
|
|
- If a sync command, extraction script, or inbox refresh fails, do not update logs, state, or context files from that failed attempt.
|
|
- Treat sync failures as operational errors, not project context.
|
|
- If a patch or edit verification fails while making a non-essential memory update, stop retrying and return the user-facing answer with the failed target noted.
|
|
- `mattermost-sync` should automatically promote high-confidence project facts without asking what to promote.
|
|
- Prefer `workspaces/fidelity/project-knowledge/06-daily/` as the default destination for new Mattermost-derived facts.
|
|
- Promote to `workspaces/fidelity/project-knowledge/01-current/current-work.md` only when the fact materially changes active work over the next few days.
|
|
- Keep explicit Jira IDs and approved titles visible in `workspaces/fidelity/project-knowledge/02-work-items/` and summarize active items in `workspaces/fidelity/project-knowledge/01-current/work-items.md` when they are useful for future standups or manager updates.
|
|
- Promote to `workspaces/fidelity/project-knowledge/03-context/project.md` only when the fact changes durable project understanding.
|
|
- When a repeatedly mentioned person becomes relevant to project flow, create or update a file under `workspaces/fidelity/project-knowledge/04-people/`.
|
|
- Keep role-to-person mapping explicit in `workspaces/fidelity/project-knowledge/04-people/manager.md` and the roster in `workspaces/fidelity/project-knowledge/04-people/index.md`.
|
|
- Never promote tooling chatter, sync status, or generic conversation noise.
|
|
- Direct user prompts are also memory sources. Do not limit memory updates to explicit sync commands.
|
|
- If a new prompt corrects prior understanding, update the canonical file directly instead of keeping both versions alive.
|
|
- Do not ask what should be saved when the correct destination is already clear.
|
|
- If the user provides durable new facts, update the appropriate context files instead of leaving the new information only in chat history.
|
|
- When the prompt is primarily asking for analysis of a screenshot, message, or document, do not interrupt the answer to perform proactive note creation unless that persistence is the explicit goal.
|
|
- When creating a new canonical note from a known type, prefer `scripts/memory/memory.sh create <type> <slug> [title]` so type-to-folder routing stays centralized.
|
|
- If the Obsidian CLI adapter fails, fall back to direct Markdown operations and treat the failure as tooling status, not project context.
|
|
- If a previous context file is now stale or inaccurate, update that file directly.
|
|
- Prefer correcting canonical context over appending contradictory notes.
|
|
- Keep changes concise and auditable.
|
|
- When the topic is architectural or historical, prefer updating the relevant file under `workspaces/fidelity/project-knowledge/03-context/systems/`, `workspaces/fidelity/project-knowledge/03-context/workstreams/`, or project-facing `workspaces/fidelity/project-knowledge/03-context/process/` instead of overloading `workspaces/fidelity/project-knowledge/03-context/project.md`.
|
|
- When the user asks Swift, SwiftUI, iOS architecture, testing, or debugging questions, use `workspaces/fidelity/project-knowledge/03-context/ios/` and the local OpenCode iOS skills before answering.
|
|
- When the user asks about programming concepts, dependency tooling, package managers, CI/build tooling, testing frameworks, or practices that may be outdated or opinion-sensitive, verify against primary/current documentation before making strong claims.
|
|
- For CocoaPods, podspecs, private specs repos, trunk/CDN behavior, Swift Package Manager, Xcode, Swift, Apple frameworks, and similar project-linked tooling, do not rely only on memory.
|
|
- When the user asks for a prompt for another AI, GitHub Copilot, or the Fidelity development machine, use `agent-memory/workflows/ai-to-ai-prompting.md` and generate a self-contained prompt.
|
|
- If a Swift/iOS recommendation depends on current Apple APIs, Xcode behavior, or framework migration guidance, verify against official Apple or Swift documentation before making strong claims.
|
|
- Be aware that this is an agentic workspace. If a recurring gap appears in answers, propose and when appropriate apply a workspace improvement to commands, agents, skills, prompts, or process notes.
|
|
|
|
## Communication
|
|
|
|
When drafting or polishing messages:
|
|
|
|
- use Context, Observation, Action when appropriate
|
|
- clarify auth state when relevant
|
|
- separate external reports from regressions
|
|
- preserve technical meaning while improving English
|