Add project-knowledge structure and templates

- Introduced new maps for navigating project knowledge, including "Current Work," "Fidelity Domain," "Fidelity Apps," "Work Items," and "People."
- Created base files for daily notes, decisions, people, systems, work items, and workstreams with defined properties and views.
- Developed templates for daily notes, decisions, meeting notes, persons, systems, work items, and workstreams to standardize documentation.
- Updated scripts and prompts to reflect the new project-knowledge directory structure.
- Removed outdated onboarding and start-here documents, consolidating relevant information into the new maps.
- Ensured all references in workflows and scripts point to the new project-knowledge paths.

agent-memory/README.md

@@ -0,0 +1,35 @@
+---
+type: agent-memory
+status: active
+updated: 2026-04-17
+tags:
+  - agent
+  - memory
+---
+
+# Agent Memory
+
+This folder contains the operating memory for the AI agent.
+
+It is not Fidelity project documentation. Do not transfer this folder as project knowledge for a new engineer. Transfer `project-knowledge/` for the project second brain, and use this folder to explain how the agent should maintain that knowledge.
+
+---
+
+## Responsibilities
+
+- Define how the agent learns incrementally.
+- Define how evidence becomes durable project knowledge.
+- Define how the agent uses the memory interface and Obsidian adapter.
+- Define how the agent verifies technical claims.
+- Define how the agent updates commands, prompts, skills, and rules when recurring behavior changes.
+
+---
+
+## Relationship To Project Knowledge
+
+- `project-knowledge/` is the clean Obsidian vault and project second brain.
+- `agent-memory/` is the agent operating manual.
+- `ai/inbox/` and connector `generated/` folders are evidence, not canonical memory.
+- `scripts/memory/` is the project-agnostic interface for reading, searching, creating, querying, and validating project knowledge.
+- `scripts/obsidian/` is the current Obsidian adapter and must not become the core abstraction.
+

agent-memory/behavior/agent-behavior.md

@@ -0,0 +1,228 @@
+---
+type: agent-behavior
+status: active
+updated: 2026-04-17
+tags: [process, memory, agent]
+---
+
+# Agent Memory Rules
+
+## Goal
+
+Make workspace memory maintenance part of the agent's normal job, not a separate optional workflow.
+
+---
+
+## Default Agent Behavior
+
+For any meaningful prompt, the agent should decide whether the interaction changes project memory.
+
+This applies to:
+
+- direct user prompts
+- Mattermost sync results
+- translated notes
+- standup generation
+- manager-update drafting
+- debugging discussions
+- corrections to previous understanding
+
+The agent should not wait for a separate promotion command when the right update is already clear.
+
+---
+
+## Learning Sessions
+
+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
+
+Good learning behavior:
+
+- If the answer is clear from stored context, answer directly and update nothing unless the interaction adds durable context.
+- 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 `project-knowledge/01-current/` or `project-knowledge/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
+
+Capture information automatically when it is:
+
+- project-relevant
+- explicit enough to preserve safely
+- likely to matter in a future session
+- useful for standups, debugging, or supervisor communication
+
+Examples:
+
+- confirmed story creation, points, scope, or priority
+- confirmed reproduction constraints
+- newly clarified root cause framing
+- approved manager guidance that changes work direction
+- confirmed version, dependency, or rollout facts tied to current work
+- corrections to previously stored project context
+- corrections to the agent's answer quality, uncertainty handling, or learning behavior
+- repeated named people with stable roles or communication relevance
+- repeated named people with multi-channel, multi-year, or high-signal technical/process involvement even when the exact formal role is still unknown
+
+---
+
+## What The Agent Must Do
+
+When new memory-worthy information appears, the agent should:
+
+1. decide whether it is daily, current-state, durable, or decision-level context
+2. update the smallest correct set of files
+3. correct stale or conflicting existing statements
+4. answer the user using the refreshed context
+
+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 `project-knowledge/03-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
+
+### `project-knowledge/06-daily/YYYY-MM-DD.md`
+
+Default destination for:
+
+- same-day progress
+- same-day findings
+- scoped reproduction notes
+- story and approval movement
+- context that is important now but may evolve later
+
+### `project-knowledge/01-current/current-work.md`
+
+Use when the fact changes the active work window, including:
+
+- current priorities
+- currently active story scope
+- current blockers or debugging constraints
+- manager direction that changes the next few days of work
+
+### `project-knowledge/02-work-items/*.md` and `project-knowledge/01-current/work-items.md`
+
+Use `project-knowledge/02-work-items/*.md` as the canonical memory for current Jira-linked work that should remain easy to reference across sessions, especially:
+
+- Jira IDs
+- approved or explicit titles
+- currently relevant status notes
+- current points or scope notes
+
+Use `project-knowledge/01-current/work-items.md` as the summary view of what is active now.
+
+These files should help standups and manager updates mention work items precisely.
+
+### `project-knowledge/03-context/project.md`
+
+Use for durable project knowledge that should survive beyond the current work window.
+
+### `project-knowledge/04-people/manager.md`
+
+Use only when a communication preference or manager expectation becomes stable enough to reuse repeatedly.
+
+### `project-knowledge/04-people/index.md` and `project-knowledge/04-people/*.md`
+
+Use these files for:
+
+- mapping roles to actual people
+- keeping named stakeholders recognizable across sessions
+- storing stable communication or responsibility context per person
+
+When the role is not explicit, store:
+
+- where the person tends to appear
+- what kinds of topics they influence
+- how they affect approvals, scope, debugging, or communication
+
+### `project-knowledge/05-decisions/*.md`
+
+Use for explicit confirmed decisions with ongoing impact.
+
+### `.opencode/commands/`, `prompts/`, `.opencode/agents/`, `.opencode/skills/`, and `agent-memory/`
+
+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
+
+Do not store:
+
+- tool failures
+- sync attempts
+- generic urgency messages
+- duplicate paraphrases of the same fact
+- weak guesses
+- operational chatter that does not change project understanding
+
+---
+
+## Correction Rule
+
+If new information supersedes old memory:
+
+- update the existing canonical file
+- do not leave stale and corrected versions side by side
+- preserve qualifiers if the fact is only partially confirmed
+
+The agent should behave like a senior engineer maintaining project notes, not like a chat assistant accumulating transcripts.

agent-memory/behavior/learning-sessions.md

@@ -0,0 +1,34 @@
+---
+type: agent-behavior
+status: active
+updated: 2026-04-17
+tags:
+  - agent
+  - learning
+---
+
+# Learning Sessions
+
+Learning sessions are used to clarify durable project understanding, not to chase transient ticket status.
+
+---
+
+## Rules
+
+- Answer from known context and verified facts only.
+- Label unknowns, assumptions, and inferences.
+- Ask 3 to 5 high-leverage questions when the user asks what should be clarified.
+- Prefer questions about architecture, ownership, process, release mechanics, debugging strategy, domain concepts, and decision rules.
+- Avoid questions that only ask whether a task moved today unless the answer changes a durable rule.
+- When the user teaches or corrects the agent, update the smallest correct canonical file or behavior surface.
+
+---
+
+## Good Clarification Targets
+
+- Ownership boundary between app, SDK, adapter, feature module, backend service, and backend-driven configuration.
+- Release propagation path across SDK, adapter, consuming app, and validation environments.
+- Evidence required before classifying an external issue as a regression.
+- REST vs GraphQL parity rules and fallback behavior.
+- Authenticated vs non-authenticated flow differences.
+

agent-memory/behavior/self-maintenance.md

@@ -0,0 +1,35 @@
+---
+type: agent-behavior
+status: active
+updated: 2026-04-17
+tags:
+  - agent
+  - self-maintenance
+---
+
+# Agent Self-Maintenance
+
+The agent must keep the workspace behavior aligned with recurring user corrections.
+
+---
+
+## Rules
+
+- If a correction changes future output, update the file that controls that output.
+- Update `.opencode/commands/` for slash-command behavior.
+- Update `prompts/` for reusable drafting shape.
+- Update `.opencode/agents/` and `AGENTS.md` for default agent behavior.
+- Update `.opencode/skills/` for specialized workflows.
+- Update `agent-memory/` for reusable agent operating rules.
+- Update `project-knowledge/` only when the correction changes project knowledge or project-facing process documentation.
+
+---
+
+## Do Not Store As Project Knowledge
+
+- Sync failures.
+- Tool dependency errors.
+- Agent implementation chatter.
+- Generic preference notes that only affect agent behavior.
+- Duplicate summaries of already-correct project facts.
+

agent-memory/integrations/communication-sources.md

@@ -0,0 +1,34 @@
+---
+type: agent-integration
+status: active
+updated: 2026-04-17
+tags:
+  - communication
+  - evidence
+---
+
+# Communication Sources
+
+Communication connectors extract evidence. The agent decides what to promote.
+
+---
+
+## Live Communication
+
+Mattermost is the current live communication connector.
+
+- Fresh output goes to `ai/inbox/mattermost-latest.md`.
+- Generated extraction artifacts stay under `scripts/mattermost/generated/`.
+- Failed syncs must not update project knowledge.
+- Latest-message requests must refresh Mattermost before answering.
+
+---
+
+## Historical Archive
+
+Slack export import is the current historical archive connector.
+
+- Archive evidence stays outside `project-knowledge/`.
+- Promote only durable project facts, people context, process rules, or historical architecture lessons.
+- Do not promote dated status details unless they explain current context.
+

agent-memory/integrations/memory-interface.md

@@ -0,0 +1,34 @@
+---
+type: agent-integration
+status: active
+updated: 2026-04-17
+tags:
+  - memory
+  - integration
+---
+
+# Memory Interface
+
+Use `scripts/memory/memory.sh` as the project-agnostic interface to project knowledge.
+
+---
+
+## Default Root
+
+The primary project knowledge directory is `project-knowledge/`.
+
+Environment variable precedence:
+
+1. `AIW_PROJECT_KNOWLEDGE_DIR`
+2. `AIW_MEMORY_VAULT_DIR`
+3. `AIW_OBSIDIAN_VAULT_DIR`
+4. `<workspace-root>/project-knowledge`
+
+`AIW_MEMORY_VAULT_DIR` and `AIW_OBSIDIAN_VAULT_DIR` are transition aliases only.
+
+---
+
+## Agent Rule
+
+Prefer the memory interface for typed note creation, search, Base queries, and health checks. Use direct Markdown edits when the adapter fails or when precise edits are simpler and safer.
+

agent-memory/integrations/obsidian.md

@@ -0,0 +1,153 @@
+---
+type: guide
+audience: workspace-user
+tags:
+  - onboarding
+  - obsidian
+---
+
+# Obsidian Adapter
+
+Use Obsidian to navigate and review project knowledge. Do not use it as a separate memory database.
+
+Obsidian is the current interface over canonical Markdown memory. The workspace-level abstraction is `scripts/memory/`, so agents should use Obsidian-specific commands only through that adapter when possible.
+
+---
+
+## Recommended Start
+
+Open the `project-knowledge/` folder as the Obsidian vault, not the repository root and not `agent-memory/`.
+
+Open:
+
+- [Start Here](../../project-knowledge/00-start/start-here.md)
+- [New Member Onboarding](../../project-knowledge/00-start/onboarding.md)
+- [Knowledge Maps](../../project-knowledge/07-maps/index.md)
+
+---
+
+## Best Views
+
+### New Member View
+
+Start with:
+
+- [New Member Onboarding](../../project-knowledge/00-start/onboarding.md)
+- [Glossary](../../project-knowledge/00-start/glossary.md)
+- [Current Work Map](../../project-knowledge/07-maps/current-work.md)
+- [Fidelity Domain Map](../../project-knowledge/07-maps/fidelity-domain.md)
+
+### Daily Work View
+
+Start with:
+
+- [Current Work Map](../../project-knowledge/07-maps/current-work.md)
+- [Work Items Map](../../project-knowledge/07-maps/work-items.md)
+- [Daily Notes Index](../../project-knowledge/06-daily/index.md)
+
+### System Understanding View
+
+Start with:
+
+- [Fidelity Domain Map](../../project-knowledge/07-maps/fidelity-domain.md)
+- [Fidelity Apps Map](../../project-knowledge/07-maps/fidelity-apps.md)
+- [People Map](../../project-knowledge/07-maps/people.md)
+
+---
+
+## Graph Guidance
+
+Use the graph to find clusters, not to infer truth.
+
+High-value graph hubs:
+
+- `start-here`
+- `onboarding`
+- `current-work`
+- `fidelity-domain`
+- `work-items`
+- `people`
+- `fidelity-apps`
+- `fidelity-domain`
+
+If a node is isolated, it may still be valid. It may be:
+
+- a daily log
+- raw evidence
+- a command/prompt file
+- a file that needs to be linked from a map
+
+---
+
+## Global Graph Defaults
+
+The global graph is configured for onboarding and project navigation, not full filesystem inspection.
+
+It intentionally hides generic technical filenames such as:
+
+- `index`
+- `README`
+- `AGENTS`
+- `SKILL`
+- `08-bases`
+- `09-templates`
+
+Those files still exist and remain valid workspace files. They are hidden from the graph because Obsidian displays only the basename, which creates many indistinguishable nodes.
+
+Use the file explorer or search when you need a specific technical file. Use the graph when you want to understand relationships between project concepts.
+
+---
+
+## When To Show Technical Files
+
+Temporarily remove these filters from the graph search when debugging workspace internals:
+
+```text
+-file:index -file:README -file:AGENTS -file:SKILL
+```
+
+For normal onboarding, keep them hidden and navigate through the named maps.
+
+---
+
+## Editing Rules
+
+- Edit canonical memory files when the fact is clear.
+- Prefer updating existing notes over adding duplicate summaries.
+- Do not edit generated files as durable memory.
+- Do not treat inbox files as confirmed truth.
+- Use maps to improve navigation, not to store detailed facts.
+
+---
+
+## Daily Notes, Templates, And Bases
+
+- Daily notes live under `06-daily/` and use `09-templates/daily.md`.
+- Templates live under `09-templates/`.
+- Bases live under `08-bases/` and use simple `type` properties plus a folder exclusion for `09-templates/`.
+- Templates may contain the final note `type` so newly created notes are useful immediately, but Bases must exclude the template folder so template files do not appear as data rows.
+- Role mapping files such as `04-people/manager.md` should use `type: role-map`, not `type: person`.
+- Bookmarks should keep `00-start/start-here.md`, `00-start/onboarding.md`, current work, work items, people, and high-value Bases easy to open.
+
+---
+
+## CLI And Templates
+
+The official Obsidian CLI can create notes from templates, query Bases, inspect properties, and search the vault.
+
+In this workspace, prefer the platform-agnostic memory wrapper:
+
+```bash
+bash scripts/memory/memory.sh create work-item pdiap-15999 "Example title"
+bash scripts/memory/memory.sh search "PDIAP-15765"
+bash scripts/memory/memory.sh base-query work-items
+bash scripts/memory/memory.sh health
+```
+
+The wrapper owns note type routing, so a `work-item` goes to `02-work-items/`, a `person` goes to `04-people/`, a `decision` goes to `05-decisions/`, and so on.
+
+Use Obsidian CLI directly only when debugging Obsidian-specific behavior:
+
+```bash
+bash scripts/obsidian/cli.sh help
+```

agent-memory/integrations/technical-verification.md

@@ -0,0 +1,82 @@
+---
+type: agent-integration
+status: active
+updated: 2026-04-17
+tags:
+  - process
+  - engineering
+  - verification
+---
+# Technical Verification
+
+## Goal
+
+Ensure the agent gives senior-engineer technical advice instead of relying on stale model memory or generic best-practice claims.
+
+---
+
+## When To Verify
+
+Verify against primary/current documentation before making strong claims about:
+
+- dependency managers and package managers
+- CocoaPods, podspecs, private specs repos, trunk/CDN behavior, and migration strategy
+- Swift Package Manager behavior or migration strategy
+- Xcode, Swift, SwiftUI, Swift concurrency, Swift Testing, XCTest, or Apple framework behavior
+- CI/build systems and release propagation
+- security, authentication, networking, or migration practices
+- any claim that a pattern is a bad practice when project constraints may change the recommendation
+
+---
+
+## Source Priority
+
+Prefer:
+
+- official vendor documentation
+- language or framework documentation
+- official migration guides
+- source repository documentation when it is the canonical project source
+- current project memory when the question is project-specific
+
+Use blogs, forum posts, or third-party guides only as supporting context, not as the primary basis for a strong recommendation.
+
+---
+
+## Answering Pattern
+
+For technical recommendations:
+
+1. State what is known from workspace context.
+2. Verify current external behavior when the topic is version-sensitive or disputed.
+3. Separate general best practice from project-safe recommendation.
+4. Explain tradeoffs and validation path.
+5. If context is missing, ask the smallest material clarification question.
+
+---
+
+## Bad Practice Claims
+
+Avoid blanket claims such as:
+
+- "CocoaPods is bad practice"
+- "SPM is always better"
+- "This architecture is an anti-pattern"
+- "This should be removed"
+
+Instead explain:
+
+- what risk the pattern introduces
+- whether the risk is current or theoretical
+- whether the project has constraints that justify it
+- what a safer migration path would look like
+
+---
+
+## Agentic Self-Improvement
+
+The agent should be aware it is maintaining a workspace, not just answering chat prompts.
+
+If a conversation reveals a recurring gap in technical quality, source verification, command behavior, or memory routing, the agent should propose or apply a workspace improvement in the correct file.
+
+Do not store tool failures or one-off uncertainty as project facts. Store reusable rules and source anchors when they improve future technical answers.

agent-memory/maps/ai-workspace-core.md

@@ -0,0 +1,53 @@
+---
+type: agent-map
+domain: workspace-core
+updated: 2026-04-17
+tags:
+  - map
+  - core
+  - agent
+---
+
+# AI Workspace Core Map
+
+Reusable workspace logic and project-independent operating rules.
+
+---
+
+## Behavior
+
+- [Agent Behavior](../behavior/agent-behavior.md)
+- [Learning Sessions](../behavior/learning-sessions.md)
+- [Self-Maintenance](../behavior/self-maintenance.md)
+
+---
+
+## Memory
+
+- [Operational Memory](../memory/operational-memory.md)
+- [Promotion Rules](../memory/promotion-rules.md)
+- [Context Maintenance](../memory/context-maintenance.md)
+
+---
+
+## Integrations
+
+- [Memory Interface](../integrations/memory-interface.md)
+- [Obsidian Adapter](../integrations/obsidian.md)
+- [Communication Sources](../integrations/communication-sources.md)
+- [Technical Verification](../integrations/technical-verification.md)
+
+---
+
+## Workflows
+
+- [AI-To-AI Prompting](../workflows/ai-to-ai-prompting.md)
+- [Workspace Model](../workflows/workspace-model.md)
+- [Workspace Architecture](../workflows/workspace-architecture.md)
+
+---
+
+## Project Profile
+
+- Active project profile: `profiles/fidelity/profile.md`
+- Project knowledge vault: `project-knowledge/`

agent-memory/maps/tooling.md

@@ -0,0 +1,65 @@
+---
+type: agent-map
+domain: tooling
+updated: 2026-04-17
+tags:
+  - map
+  - tooling
+---
+
+# Tooling Map
+
+Commands, prompts, skills, workflows, and automation surfaces that make the workspace operate consistently.
+
+---
+
+## OpenCode Agents
+
+- [AI Workspace Core Map](ai-workspace-core.md)
+- Fidelity agent: `.opencode/agents/fidelity.md`
+- Workspace agent: `.opencode/agents/workspace.md`
+
+---
+
+## Commands
+
+- Commands index: `.opencode/commands/index.md`
+- Workspace context: `.opencode/commands/workspace-context.md`
+- Memory health: `.opencode/commands/memory-health.md`
+- Memory create: `.opencode/commands/memory-create.md`
+- Communication sync: `.opencode/commands/communication-sync.md`
+- Archive import: `.opencode/commands/archive-import.md`
+- AI prompt: `.opencode/commands/ai-prompt.md`
+- Standup: `.opencode/commands/standup.md`
+- Manager update: `.opencode/commands/manager-update.md`
+- Sync context: `.opencode/commands/sync-context.md`
+
+---
+
+## Skills
+
+- Skills index: `.opencode/skills/index.md`
+- Workspace memory curation: `.opencode/skills/workspace-memory-curation/SKILL.md`
+- Professional communication: `.opencode/skills/professional-communication/SKILL.md`
+- Status reporting: `.opencode/skills/status-reporting/SKILL.md`
+- AI prompt engineering: `.opencode/skills/ai-prompt-engineering/SKILL.md`
+
+---
+
+## Prompts And Workflows
+
+- Prompts index: `prompts/index.md`
+- Standup prompt: `prompts/standup.md`
+- Manager update prompt: `prompts/manager-update.md`
+- Story draft prompt: `prompts/story-draft.md`
+- OpenCode entry workflow: `workflows/opencode-entry.md`
+- Daily context sync: `workflows/daily-context-sync.md`
+
+---
+
+## Memory Interface
+
+- Project-agnostic memory scripts: `scripts/memory/`
+- Current Obsidian adapter: `scripts/obsidian/`
+- Project knowledge vault: `project-knowledge/`
+- Agent operating memory: `agent-memory/`

agent-memory/memory/context-maintenance.md

@@ -0,0 +1,54 @@
+---
+type: agent-memory
+status: active
+updated: 2026-04-17
+tags:
+  - process
+  - memory
+---
+# Context Maintenance
+
+## Goal
+
+Keep this workspace useful as living memory instead of a pile of disconnected notes.
+
+---
+
+## Stable Rules
+
+- Update canonical context when a durable fact changes.
+- Prefer correcting stale context over appending contradictory notes.
+- If a canonical note appears in an Obsidian Base, update its frontmatter properties together with the prose content.
+- When changing frontmatter properties on existing canonical notes, prefer Obsidian CLI property operations through `scripts/obsidian/cli.sh` when available so YAML spacing and property formatting stay clean; fall back to direct Markdown edits only when the CLI is unavailable or the operation is unsupported.
+- Keep templates under `project-knowledge/09-templates/` out of real-note Bases by filtering the template folder.
+- Role mapping files should not use `type: person`; reserve `type: person` for actual people profiles.
+- Work-item notes should keep known `systems`, `workstreams`, `people`, and `related` properties current.
+- Daily notes should keep `focus`, `work-items`, and `blockers` properties current when the values are clear.
+- Use the smallest correct destination:
+  - `project-knowledge/06-daily/YYYY-MM-DD.md` for daily progress and evolving findings
+  - `project-knowledge/01-current/current-work.md` for near-term active work
+  - `project-knowledge/02-work-items/*.md` for canonical Jira-linked active work
+  - `project-knowledge/01-current/work-items.md` for the compact active-work summary
+  - `project-knowledge/03-context/` for durable project knowledge
+  - `project-knowledge/04-people/` for named person context
+  - `.opencode/commands/`, `prompts/`, `.opencode/agents/`, `.opencode/skills/`, `agent-memory/`, `core/`, or `scripts/` for reusable behavior rules that control how the workspace responds
+
+---
+
+## 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.
+- Treat user corrections about command output, prompt structure, memory handling, or agent behavior as inputs to the operational surface, not just as daily notes.
+
+---
+
+## Curation Rule
+
+- If a new stable context file is added, keep `project.md` and `index.md` aligned so future sessions can discover it quickly.
+- If a new rule affects a slash command or reusable prompt, update that command or prompt directly so the behavior changes on the next run.

agent-memory/memory/operational-memory.md

@@ -0,0 +1,39 @@
+---
+type: agent-memory
+status: active
+updated: 2026-04-17
+tags:
+  - memory
+  - operations
+---
+
+# Operational Memory
+
+Operational memory is the mechanism that turns daily evidence into durable, searchable project knowledge.
+
+The reusable model lives in `core/memory/operational-memory.md`. This file records the active agent-specific interpretation for this workspace.
+
+---
+
+## Memory Classes
+
+- `daily`: dated progress and evidence in `project-knowledge/06-daily/`.
+- `state`: near-term active work in `project-knowledge/01-current/`.
+- `work-items`: ticket-scoped memory in `project-knowledge/02-work-items/`.
+- `stable-context`: durable systems, workstreams, process, and iOS context in `project-knowledge/03-context/`.
+- `people`: collaborators, stakeholders, and role mappings in `project-knowledge/04-people/`.
+- `decisions`: accepted durable decisions in `project-knowledge/05-decisions/`.
+- `tooling-behavior`: agent and workspace behavior in `agent-memory/`, `.opencode/`, `prompts/`, `scripts/`, and `core/`.
+
+---
+
+## Evidence Boundary
+
+Raw evidence stays outside project knowledge:
+
+- `ai/inbox/`
+- `scripts/mattermost/generated/`
+- `scripts/slack/generated/`
+
+Only curated, high-confidence project facts should be promoted into `project-knowledge/`.
+

agent-memory/memory/promotion-rules.md

@@ -0,0 +1,145 @@
+---
+type: agent-memory
+status: active
+updated: 2026-04-17
+tags: [process, memory, promotion]
+---
+
+# Memory Promotion Rules
+
+## Goal
+
+Keep workspace memory current automatically without asking the user what to promote after every successful sync.
+
+---
+
+## Default Rule
+
+When new Mattermost context is explicit, project-relevant, and high-confidence, promote it automatically.
+
+Do not ask for promotion confirmation by default.
+
+If a fact is ambiguous, skip it or keep it only in the daily log with appropriate qualifiers.
+
+---
+
+## File Selection
+
+### Promote to `project-knowledge/06-daily/YYYY-MM-DD.md`
+
+Use the daily log for:
+
+- concrete same-day work updates
+- story creation, sizing, approval, and scope updates
+- manager-approved wording or root-cause framing tied to current work
+- confirmed version checks tied to active work
+- reproduction findings that are useful now but may still evolve
+
+Daily logs are the default destination for most promoted Mattermost facts.
+
+### Promote to `project-knowledge/01-current/current-work.md`
+
+Use current state only for facts that materially affect active work over the next few days, such as:
+
+- approved active story scope
+- confirmed current debugging constraints
+- current reproduction conditions that change how the work is approached
+- near-term priorities confirmed by manager communication
+
+Do not copy every daily update into current state.
+
+### Promote to `project-knowledge/02-work-items/*.md` and `project-knowledge/01-current/work-items.md`
+
+Use `project-knowledge/02-work-items/*.md` for:
+
+- explicit Jira IDs
+- approved or explicit story titles
+- current story points
+- current scope notes
+- active status notes that still matter for future updates
+
+If a Jira item is likely to appear again in standups or manager updates, it belongs here.
+
+Use `project-knowledge/01-current/work-items.md` as the compact summary of which ticket files are active.
+
+### Promote to `project-knowledge/03-context/project.md`
+
+Use project context only for durable project knowledge that should survive beyond the current work window, such as:
+
+- stable architecture constraints
+- recurring debugging truths
+- persistent testing limitations
+- enduring behavior of REST, GraphQL, XFlow, auth, or entry points
+
+Do not promote story-specific daily movement into project context unless it changes durable project understanding.
+
+### Promote to `project-knowledge/05-decisions/*.md`
+
+Use decisions only for explicit confirmed decisions with medium or long-term impact.
+
+### Promote to `project-knowledge/04-people/index.md` and `project-knowledge/04-people/*.md`
+
+Use these files when:
+
+- a person's identity matters repeatedly
+- a role becomes associated with a specific person
+- a stakeholder's communication or approval patterns affect future work
+- a human appears across multiple channels or years with repeated technical, process, or approval signal
+- the archive makes the collaboration pattern clear even if the formal title is still unknown
+
+Prefer:
+
+- `manager.md` for role mapping
+- `index.md` for active roster
+- one file per person for person-specific context
+
+If exact role confidence is low, store the person's repeated project relationship instead of inventing a title.
+
+---
+
+## Do Not Promote
+
+Do not record these as project memory:
+
+- tooling activity
+- sync status
+- missing dependencies
+- empty inbox situations
+- reminders or urgency without project substance
+- unapproved drafts
+- generic chat noise
+
+---
+
+## Confidence Rules
+
+Auto-promote when the signal is high-confidence, for example:
+
+- the manager explicitly approves something
+- a Jira story number, title, points, or scope is explicitly confirmed
+- a version is stated directly and tied to the active project
+- a reproduction condition is clearly stated with scope qualifiers
+
+If confidence is mixed:
+
+- prefer the daily log
+- preserve qualifiers such as "appears", "currently", or "for authenticated users"
+- avoid promoting to stable project context
+
+---
+
+## Example Policy
+
+Given Mattermost updates like:
+
+- PDIAP-15836 created and sized at 8 points
+- the manager approved a story title
+- REST-removal scope was approved
+- XFlowViewMaker 0.5.0 is already in Fid4
+- AO DOB validation issue appears auth-only in TeenIdentityCheck
+
+Automatic behavior should be:
+
+- add all of them to today's log if they are relevant to today's work
+- promote only the currently actionable subset to `project-knowledge/01-current/current-work.md`
+- keep story-specific details out of `project-knowledge/03-context/project.md` unless they reveal a durable project rule

agent-memory/workflows/ai-to-ai-prompting.md

@@ -0,0 +1,77 @@
+---
+type: agent-workflow
+status: active
+updated: 2026-04-17
+tags:
+  - process
+  - ai-prompting
+---
+# AI-To-AI Prompting
+
+## Goal
+
+Generate prompts that can be sent to another AI assistant on the Fidelity development machine, especially GitHub Copilot.
+
+---
+
+## Operating Assumption
+
+This workspace does not contain the product codebase. The target AI has access to the Fidelity codebase on another machine.
+
+Therefore prompts must:
+
+- include only the relevant project context from this workspace
+- tell the target AI what files/modules to inspect
+- ask for a concrete output
+- specify constraints and non-goals
+- avoid pretending the target AI already has this workspace memory
+
+---
+
+## Prompt Structure
+
+Use this structure by default:
+
+1. Role
+2. Project context
+3. Current task
+4. Relevant ticket/context
+5. Files/modules to inspect
+6. Constraints
+7. Expected output
+8. Validation requirements
+
+---
+
+## Prompt Quality Rules
+
+- Prefer precise task framing over long background dumps.
+- Include Jira ID and title when the work maps to a ticket.
+- Include current constraints such as REST feature flag, GraphQL fallback, auth state, backend-driven behavior, and consumer validation when relevant.
+- Ask the target AI to inspect code before proposing changes.
+- Ask for a plan first when the implementation scope is uncertain.
+- Ask for code changes only when the desired write scope is clear.
+- Include "Do not assume REST is active by default" for REST migration tasks.
+- Include "Separate external issue from regression" for AO/Discourse issues.
+- Include "Validate against Fid4/consumer path when needed" for XFlow integration tasks.
+
+---
+
+## Bad Prompt Pattern
+
+"Fix this issue in XFlow."
+
+Why bad:
+
+- no entry point
+- no auth state
+- no expected behavior
+- no ticket context
+- no validation path
+- no scope boundary
+
+---
+
+## Good Prompt Pattern
+
+"You are working in the Fidelity iOS codebase. Inspect the XFlowSDK and XFlowViewMaker integration path for `PDIAP-14859 - Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation`. First identify where XFlow currently exposes SwiftUI through `UIHostingController`, where XFlowViewMaker consumes it, and what feature flag protects the migration path. Do not change code yet. Return a concise plan with affected files, risks, consumer validation needs in Fid4/FTTransfer, and any questions that block implementation."

agent-memory/workflows/workspace-architecture.md

@@ -0,0 +1,71 @@
+---
+type: agent-workflow
+status: active
+updated: 2026-04-17
+tags: [onboarding, obsidian, workspace]
+related:
+  - ../maps/ai-workspace-core.md
+---
+
+# Workspace Architecture
+
+This repository separates project knowledge from agent operation:
+
+- `project-knowledge/` is the clean Obsidian second brain and transferable project memory.
+- `agent-memory/` is the operating manual for the AI agent.
+- Everything else is technical runtime, reusable core, profile configuration, scripts, commands, prompts, or raw evidence.
+
+---
+
+## Canonical Memory
+
+Use these folders as the source of truth for project knowledge:
+
+- `00-start/` for project onboarding and terminology
+- `01-current/` for current work state
+- `02-work-items/` for ticket/task memory
+- `03-context/` for systems, workstreams, project-facing process, and iOS context
+- `04-people/` for people and role memory
+- `05-decisions/` for confirmed decisions
+- `06-daily/` for daily notes
+- `07-maps/` for graph hubs
+- `08-bases/` for table-style review
+- `09-templates/` for note templates
+
+---
+
+## Runtime Outside The Vault
+
+These folders are intentionally outside Obsidian memory:
+
+- `.opencode/` stores agents and slash commands.
+- `core/` stores reusable workspace logic.
+- `profiles/` stores project-specific profile declarations.
+- `scripts/` stores connectors, importers, and wrappers.
+- `ai/inbox/` stores live evidence from communication sync.
+- `scripts/*/generated/` stores extracted evidence.
+
+Runtime and generated files can be used as evidence, but durable project facts should be promoted into `project-knowledge/`.
+
+Agent behavior rules belong in `agent-memory/`, not in the project vault.
+
+---
+
+## Memory Access Layer
+
+Use `scripts/memory/` as the platform-agnostic interface to canonical memory.
+
+Obsidian is the current visual and CLI-backed adapter, but the source of truth remains Markdown under `project-knowledge/`.
+
+- Agents use `scripts/memory/memory.sh create` when a new typed note is needed.
+- Agents use `scripts/memory/memory.sh search` or direct Markdown reads for context lookup.
+- Agents use `scripts/memory/memory.sh base-query` and `health` for structured review.
+- Precise memory edits should still be made directly to Markdown so changes stay auditable.
+
+---
+
+## Memory Rule
+
+Promoted memory lives in `project-knowledge/`.
+
+Raw inbox and generated connector evidence stays outside the vault until the agent promotes durable facts.

agent-memory/workflows/workspace-model.md

@@ -0,0 +1,61 @@
+---
+type: agent-workflow
+status: active
+updated: 2026-04-17
+tags: [process, workspace, memory]
+---
+
+# Workspace Model
+
+## Purpose
+
+This repository is a support workspace, not the implementation repository.
+
+It separates reusable tooling, project knowledge, and agent operating memory:
+
+- `core/` contains reusable project-independent operating rules
+- `profiles/<project>/` contains project-specific configuration and assumptions
+- `project-knowledge/` contains transferable project documentation and current work memory
+- `agent-memory/` contains agent behavior, learning, promotion, integration, and verification rules
+
+---
+
+## What belongs here
+
+- daily logs
+- communication context
+- manager update drafts
+- stable project knowledge
+- debugging summaries
+- reusable command, prompt, skill, and agent rules that make the workspace behave consistently
+- project profiles that configure the reusable core for a specific project
+- optional navigation notes and portable Obsidian configuration
+
+---
+
+## What does not belong here
+
+- product source code
+- assumptions about code changes not yet verified
+- statements that imply work was executed from this machine unless explicitly true
+- Obsidian local layout, plugin cache, or runtime state
+
+---
+
+## Operational Surface
+
+When the user corrects a recurring behavior, the workspace should update the file that controls that behavior:
+
+- `core/` for reusable project-independent behavior
+- `profiles/<project>/` for project-specific assumptions
+- `project-knowledge/.obsidian/` only for portable Obsidian configuration, not project memory content
+- `scripts/memory/` for project-agnostic memory access, creation, search, Base queries, and health checks
+- `scripts/obsidian/` for the current Obsidian adapter, not for core memory semantics
+- `.opencode/commands/` for slash commands
+- `prompts/` for reusable drafting templates
+- `.opencode/agents/` and `AGENTS.md` for default agent behavior
+- `.opencode/skills/` for specialized workflows
+- `project-knowledge/00-start/` and `project-knowledge/03-context/process/` for project-facing onboarding and process rules
+- `agent-memory/` for agent-specific behavior, learning, promotion, verification, and self-maintenance rules
+
+Daily logs can preserve evidence, but they should not be the only place where a reusable behavior rule lives.