feat: integrate Obsidian MCP server via opencode config and add migration strategy documentation

.opencode/commands/standup.md

@@ -6,7 +6,30 @@ Generate a standup update using the latest workspace state.
 
 First, refresh Mattermost context before drafting:
 
-!`if [ -n "$FIDELITY_MATTERMOST_SYNC_CMD" ]; then bash -lc "$FIDELITY_MATTERMOST_SYNC_CMD" >/dev/null 2>&1 || true; elif [ -f scripts/mattermost/sync.sh ]; then bash scripts/mattermost/sync.sh >/dev/null 2>&1 || true; fi`
+!`python3 - <<'PY'
+import os
+import subprocess
+from pathlib import Path
+
+cmd = os.environ.get("AIW_MATTERMOST_SYNC_CMD") or os.environ.get("FIDELITY_MATTERMOST_SYNC_CMD")
+if cmd:
+    result = subprocess.run(["bash", "-lc", cmd], capture_output=True, text=True)
+elif Path("scripts/mattermost/sync.sh").is_file():
+    result = subprocess.run(["bash", "scripts/mattermost/sync.sh"], capture_output=True, text=True)
+else:
+    print("No Mattermost sync command configured.")
+    raise SystemExit(0)
+
+if result.returncode != 0:
+    print("__MATTERMOST_SYNC_FAILED__")
+    if result.stdout:
+        print(result.stdout.strip())
+    if result.stderr:
+        print(result.stderr.strip())
+else:
+    if result.stdout.strip():
+        print(result.stdout.strip())
+PY`
 
 Read:
 
@@ -35,7 +58,28 @@ Latest Mattermost context, preferring inbox and falling back to generated JSONL:
 
 Detailed active work item files, if available:
 
-!`if [ -d project-knowledge/02-work-items ]; then for f in project-knowledge/02-work-items/*.md; do case "$f" in *README.md|*index.md) continue;; esac; echo "\n### $f"; cat "$f"; done; else echo "No work item files available."; fi`
+!`python3 - <<'PY'
+import re
+from pathlib import Path
+
+summary = Path("project-knowledge/01-current/work-items.md")
+if not summary.is_file():
+    print("No work item files available.")
+    raise SystemExit(0)
+
+text = summary.read_text()
+paths = re.findall(r"Detail: `(project-knowledge/02-work-items/[^`]+)`", text)
+if not paths:
+    print("No work item files available.")
+    raise SystemExit(0)
+
+for rel in paths:
+    path = Path(rel)
+    if not path.is_file():
+        continue
+    print(f"\n### {rel}")
+    print(path.read_text())
+PY`
 
 Before drafting:
 
@@ -51,6 +95,8 @@ Before drafting:
 - use `project-knowledge/03-context/workstreams/flow-page-references.md` to preserve real flow/page identifiers when shorthand appears in logs or messages
 - for standups that will also be sent to Teams, prefer plain language over internal implementation jargon; avoid unexplained terms like `fallback`
 - if work is in release-process waiting state, show the parallel story work explicitly instead of implying idle waiting
+- if Mattermost sync failed, acknowledge that internally and rely on the latest saved workspace context instead of inventing fresher communication
+- prefer only the detailed work-item files referenced by `project-knowledge/01-current/work-items.md`; do not mine unrelated or completed ticket files unless they are explicitly active in current memory
 
 Return a standup that is:
 
@@ -60,8 +106,12 @@ Return a standup that is:
 - safe to send without overstating certainty
 - written in natural US English that can be sent externally without rewriting
 - written as David's progress report
-- free of any mention of Jeff by name
 - free of any mention of Mattermost, since it is internal-only communication
+- starts with exactly `Hi @jeff, here’s my daily scrum update:` for the active Fidelity profile
+- does not mention Jeff again after the greeting unless explicitly needed
 - uses bullet points for each item
 - groups multiple updates for the same Jira item as indented sub-bullets
 - uses `JIRA-ID - Title` or `JIRA-ID Title` formatting instead of comma-separated ID/title formatting
+- preserves chronological order within each Jira item's sub-bullets
+- omits future-sprint stories from `Today` unless they are real blockers
+- is ready to copy/paste into Mattermost as Markdown

.opencode/skills/copilot-prompt-engineering/SKILL.md

@@ -31,6 +31,7 @@ Use this skill when the user wants a prompt for another AI assistant, GitHub Cop
 - Write the final prompt in English unless the user explicitly requests another language.
 - Default to first-person wording so the user can paste the prompt directly into Copilot.
 - Keep the prompt short unless the user asks for more detail.
+- For follow-up prompts in the same AI session, assume recent shared context and avoid repeating which side made the previous changes unless it matters for the task.
 - Include Jira ID and approved title when available.
 - For REST work, say REST is behind a feature flag and GraphQL is fallback unless confirmed otherwise.
 - For XFlow work, say behavior may depend on entry point, auth state, backend config, and consumer integration.

agent-memory/README.md

@@ -22,6 +22,7 @@ It is not Fidelity project documentation. Do not transfer this folder as project
 - 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.
+- Preserve reusable prompting and output-quality lessons so the agent does not need to rediscover them in later sessions.
 
 ---
 
@@ -32,4 +33,3 @@ It is not Fidelity project documentation. Do not transfer this folder as project
 - `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

@@ -1,7 +1,7 @@
 ---
 type: agent-behavior
 status: active
-updated: 2026-04-17
+updated: 2026-04-21
 tags: [process, memory, agent]
 ---
 
@@ -29,6 +29,9 @@ This applies to:
 
 The agent should not wait for a separate promotion command when the right update is already clear.
 
+- When editing `project-knowledge/`, write as a human engineer maintaining shared project documentation.
+- Keep agent-operating logic out of `project-knowledge/`; store that logic in prompts, commands, skills, agents, or `agent-memory/`.
+
 ---
 
 ## Learning Sessions

agent-memory/maps/tooling.md

@@ -1,7 +1,7 @@
 ---
 type: agent-map
 domain: tooling
-updated: 2026-04-17
+updated: 2026-04-27
 tags:
   - map
   - tooling
@@ -61,5 +61,6 @@ Commands, prompts, skills, workflows, and automation surfaces that make the work
 
 - Project-agnostic memory scripts: `scripts/memory/`
 - Current Obsidian adapter: `scripts/obsidian/`
+- Obsidian MCP migration plan: `agent-memory/workflows/obsidian-mcp-migration.md`
 - Project knowledge vault: `project-knowledge/`
 - Agent operating memory: `agent-memory/`

agent-memory/memory/context-maintenance.md

@@ -1,7 +1,7 @@
 ---
 type: agent-memory
 status: active
-updated: 2026-04-17
+updated: 2026-04-21
 tags:
   - process
   - memory
@@ -18,6 +18,9 @@ Keep this workspace useful as living memory instead of a pile of disconnected no
 
 - Update canonical context when a durable fact changes.
 - Prefer correcting stale context over appending contradictory notes.
+- Keep `project-knowledge/` human-facing and project-facing: write it as an engineer maintaining shared project notes, not as an AI maintaining its own operating instructions.
+- Do not place agent-only logic, output contracts, prompting tactics, evaluation heuristics, or command-behavior rules in `project-knowledge/` unless a human engineer on the project would reasonably want that exact guidance there.
+- Put agent behavior, prompt logic, formatting contracts, and slash-command rules in `agent-memory/`, `.opencode/commands/`, `prompts/`, `.opencode/agents/`, or `.opencode/skills/` instead of `project-knowledge/`.
 - 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.

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

@@ -48,6 +48,7 @@ Use this structure by default:
 - Write prompts in English by default for GitHub Copilot and other development-machine AI tools unless the user explicitly asks for another language.
 - Prefer first-person phrasing when drafting a prompt the user will paste directly into another AI tool, unless the user asks for a different voice.
 - Keep prompts concise by default; include only the context needed for correct execution.
+- In follow-up prompts to the same AI session, do not restate completed work or who performed it unless that detail is needed for the next step.
 - 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.

agent-memory/workflows/obsidian-mcp-migration.md

@@ -0,0 +1,274 @@
+---
+type: agent-workflow
+status: in-progress
+updated: 2026-04-27
+tags: [obsidian, mcp, migration, memory]
+---
+
+# Obsidian MCP Migration Plan
+
+## Goal
+
+Replace the current Obsidian CLI-backed adapter path with an Obsidian MCP-first integration while preserving the workspace memory model:
+
+- `project-knowledge/` remains the canonical source of truth
+- `scripts/memory/` remains the stable workspace memory contract
+- direct Markdown edits remain the safe fallback for precise curation
+- Obsidian stays an adapter/navigation layer, not a second memory store
+
+---
+
+## Current State
+
+Current access path:
+
+```text
+agent -> scripts/memory/memory.sh -> scripts/obsidian/cli.sh -> obsidian CLI -> vault
+```
+
+Current Obsidian-specific helper scripts:
+
+- `scripts/obsidian/cli.sh`
+- `scripts/obsidian/open.sh`
+- `scripts/obsidian/search.sh`
+- `scripts/obsidian/daily.sh`
+- `scripts/obsidian/uri.sh`
+
+Current memory-interface features that rely on Obsidian CLI when available:
+
+- note creation from templates
+- search with context
+- Base queries
+- selected health/navigation checks
+
+Phase 1 integration status as of 2026-04-27:
+
+- OpenCode project config now declares a local MCP server named `obsidian`.
+- The configured command is `/opt/homebrew/bin/uvx mcp-obsidian`.
+- The Obsidian Local REST API endpoint is reachable at `https://127.0.0.1:27124/` and reports plugin version `3.6.1` with Obsidian `1.12.7`.
+- The server currently depends on the caller providing `OBSIDIAN_API_KEY` through the shell environment; do not commit this secret.
+
+---
+
+## Target State
+
+Preferred access path:
+
+```text
+agent -> memory interface rules -> Obsidian MCP -> vault
+```
+
+The migration should change the adapter, not the memory model.
+
+---
+
+## Non-Goals
+
+- Do not move canonical memory out of Markdown
+- Do not encode promotion rules into the MCP layer
+- Do not make `project-knowledge/` depend on Obsidian-only storage
+- Do not remove direct Markdown editing as a fallback
+- Do not delete the current scripts until MCP coverage is validated in real use
+
+---
+
+## Capability Mapping
+
+### Move to Obsidian MCP
+
+- vault search
+- search with context
+- Base queries
+- backlinks / links / orphans / unresolved checks
+- property read/write operations
+- template-based note creation if supported cleanly by the MCP
+
+### Keep as workspace logic
+
+- note type routing (`work-item`, `person`, `decision`, etc.)
+- memory promotion rules
+- evidence vs canonical-memory separation
+- workspace-specific health expectations
+- fallback to direct Markdown operations
+- metadata expectations for work items, daily notes, people, decisions, and context notes
+
+---
+
+## Phased Rollout
+
+## Phase 1 - Validate MCP Coverage
+
+Confirm the selected Obsidian MCP supports the operations the workspace already depends on.
+
+Required coverage:
+
+- read file contents
+- create note from path and optionally template
+- search vault
+- query Bases or equivalent structured views
+- read and write frontmatter/properties
+- list backlinks/links or equivalent relationship data
+
+Current Phase 1 checklist:
+
+- [x] Confirm Obsidian Local REST API plugin is reachable locally.
+- [x] Install `uv` / `uvx` runtime for `mcp-obsidian`.
+- [x] Add OpenCode MCP config using `OBSIDIAN_API_KEY` environment substitution.
+- [x] Export `OBSIDIAN_API_KEY` in the shell that launches OpenCode.
+- [x] Restart OpenCode and confirm `opencode mcp list` shows `obsidian` connected.
+- [x] Validate read/search tools against `project-knowledge/` notes.
+- [x] Validate write/append/delete behavior on a disposable test note before touching canonical memory.
+- [ ] Determine whether Bases/properties/backlinks/template behavior needs to remain on the existing CLI/direct-Markdown path.
+
+Phase 1 validation results:
+
+- `list_files_in_vault` works and returns the expected top-level project-knowledge folders.
+- `list_files_in_dir` works for folders such as `01-current`.
+- `get_file_contents` works for canonical notes such as `01-current/current-work.md`.
+- `simple_search` works and returns scored/contextual matches across the vault.
+- `append_content` can create and append to a disposable note.
+- `delete_file` can delete a disposable note.
+- `patch_content` with `target_type=heading` failed against a disposable note with `invalid-target`; treat heading-targeted patching as not yet validated.
+
+Decision rule:
+
+- If MCP cannot cover create/search/properties/Base-query well enough, keep the current CLI path as a partial adapter instead of forcing a full replacement.
+
+---
+
+## Phase 2 - Switch Documentation To MCP-First
+
+Update behavior and architecture docs so they describe:
+
+- Obsidian MCP as the preferred adapter when available
+- `scripts/memory/` as the stable workspace contract
+- direct Markdown editing as the safe fallback
+- the CLI path as legacy or transitional
+
+Primary files to update:
+
+- `AGENTS.md`
+- `.opencode/agents/fidelity.md`
+- `.opencode/agents/workspace.md`
+- `README.md`
+- `profiles/fidelity/profile.md`
+- `core/README.md`
+- `core/integrations/memory-vault-model.md`
+- `core/integrations/obsidian-model.md`
+- `agent-memory/integrations/memory-interface.md`
+- `agent-memory/integrations/obsidian.md`
+- `agent-memory/memory/context-maintenance.md`
+- `agent-memory/workflows/workspace-architecture.md`
+- `scripts/memory/README.md`
+- `.opencode/commands/memory-create.md`
+- `.opencode/commands/memory-health.md`
+
+---
+
+## Phase 3 - Deprecate Obsidian CLI Helpers
+
+Mark these as deprecated in comments/docs before removal:
+
+- `scripts/obsidian/cli.sh`
+- `scripts/obsidian/open.sh`
+- `scripts/obsidian/search.sh`
+- `scripts/obsidian/daily.sh`
+- `scripts/obsidian/uri.sh`
+
+Notes:
+
+- human convenience wrappers may be kept longer than agent-facing wrappers
+- `scripts/memory/` should not be deleted just because the adapter changes
+
+---
+
+## Phase 4 - Remove Unused Adapter Scripts
+
+Delete only after:
+
+- MCP has been used successfully in normal workflows
+- no agent instructions still reference the old scripts
+- command docs no longer direct users to the old CLI path
+- there is no remaining human workflow dependency worth preserving
+
+Likely delete first:
+
+- `scripts/obsidian/cli.sh`
+- `scripts/obsidian/uri.sh`
+
+Delete later only if truly unused:
+
+- `scripts/obsidian/open.sh`
+- `scripts/obsidian/search.sh`
+- `scripts/obsidian/daily.sh`
+
+---
+
+## Cleanup Matrix
+
+### Keep
+
+- `project-knowledge/.obsidian/`
+- `project-knowledge/08-bases/*.base`
+- `project-knowledge/09-templates/`
+- `scripts/memory/`
+
+### Deprecate then remove
+
+- `scripts/obsidian/*` agent-facing wrappers that become redundant under MCP
+
+### Update in place
+
+- commands that call `bash scripts/memory/memory.sh ...`
+- docs that explicitly say "Obsidian CLI" is the preferred adapter
+- rules that recommend CLI property edits
+
+---
+
+## Risks
+
+- over-coupling the workspace to a specific MCP implementation
+- deleting the stable memory contract too early
+- partial migration that leaves conflicting instructions in docs
+- assuming MCP supports templates/Bases/properties exactly like the CLI
+
+---
+
+## Rollback Strategy
+
+If MCP integration is incomplete or unstable:
+
+- keep `scripts/memory/` as the default contract
+- keep CLI helpers until capability parity exists
+- continue direct Markdown edits for precise curation
+- treat MCP as additive until it proves reliable in real workflows
+
+---
+
+## Immediate Next Steps
+
+1. Choose the exact Obsidian MCP implementation and document its supported operations.
+2. Build a capability parity checklist against the current CLI-backed flow.
+3. Update the workspace docs to MCP-first wording without deleting the CLI path yet.
+4. Add deprecation notes to `scripts/obsidian/*` once the new path is active.
+5. Remove old scripts only after references and real usage are gone.
+
+---
+
+## Initial Candidate
+
+- `MarkusPfundstein/mcp-obsidian`
+  - GitHub: `https://github.com/MarkusPfundstein/mcp-obsidian`
+  - Integration model: MCP server that talks to Obsidian through the Obsidian Local REST API community plugin.
+  - Documented tools include file listing, file reads, search, content patching, append, and delete.
+  - Requires validating whether it covers this workspace's Base-query, property/frontmatter, backlinks, and template workflows well enough to replace the current CLI adapter.
+
+## Candidate Rejected Or Not Recommended
+
+- `jacksteamdev/obsidian-mcp-tools`
+  - GitHub: `https://github.com/jacksteamdev/obsidian-mcp-tools`
+  - Features documented by the project include vault access, semantic search, and template integration.
+  - Dependencies include Obsidian Local REST API, and optional/recommended plugins such as Templater and Smart Connections.
+  - The repository currently carries a prominent "Project Unmaintained" security notice from the maintainer.
+  - The maintainer specifically recommends migrating to a plugin that implements MCP over HTTP/SSE rather than relying on a downloaded local executable model.
+  - Do not use this as the primary migration target for this workspace unless no safer maintained option is available and the risk is explicitly accepted.

agent-memory/workflows/prompt-engineering-lessons.md

@@ -0,0 +1,51 @@
+---
+type: agent-workflow
+status: active
+updated: 2026-04-21
+tags:
+  - prompting
+  - quality
+  - standup
+  - workflow
+---
+
+# Prompt Engineering Lessons
+
+## Goal
+
+Capture reusable prompting lessons so the agent does not need to re-research the same quality patterns for future prompt and command improvements.
+
+---
+
+## Stable Lessons
+
+- Start with the smallest prompt that solves the measured failure mode, then add constraints only where they fix a real recurring error.
+- Prefer explicit output contracts over vague quality goals.
+- Define completion criteria clearly so the model knows what "done" looks like.
+- Separate sections by purpose: source selection, decision rules, output rules, and anti-patterns.
+- Put high-priority behavioral instructions in the command or prompt that directly controls the output, not in project-facing notes.
+- Use concrete anti-patterns when a recurring failure mode is known; models respond better to explicit "do not do X" guidance than to general advice alone.
+- Prefer source-bound selection rules when stale or overly broad context can pollute the answer.
+- If a task depends on chronology, state chronology explicitly as an output rule.
+- If concision matters, define how to compress: what should be merged, what should remain split, and what should be omitted.
+- If the output is meant to be sent directly, make "copy/paste ready" part of the contract.
+- Avoid mixing task logic with human-facing project documentation; reusable prompting logic belongs in prompts, commands, skills, or agent memory.
+
+---
+
+## Standup-Specific Lessons
+
+- The model should not infer "worked yesterday" from durable status alone.
+- `Yesterday` should be tied to previous-workday evidence first, then disambiguated with current memory.
+- Only active work items should be expanded by default; avoid loading every ticket note when generating short status output.
+- Future-sprint work should be excluded from `Today` unless it is a real blocker or the user explicitly wants forward-looking planning.
+- Chronological ordering inside a Jira item reduces awkward or misleading summaries.
+- Closely related events should usually be compressed into one concise sub-bullet when they belong to the same continuous investigation.
+
+---
+
+## Quality Loop
+
+- Treat prompt improvement as eval-driven iteration: identify the exact bad output pattern, add the smallest correction, and check whether it fixes the failure without bloating the prompt.
+- When a correction is about workspace behavior, update the controlling prompt or command immediately so the next run benefits.
+- Keep project memory clean while improving prompt quality; do not store agent heuristics in `project-knowledge/`.

opencode.json

@@ -2,6 +2,19 @@
   "$schema": "https://opencode.ai/config.json",
   "default_agent": "fidelity",
   "share": "manual",
+  "mcp": {
+    "obsidian": {
+      "type": "local",
+      "command": ["/opt/homebrew/bin/uvx", "mcp-obsidian"],
+      "enabled": true,
+      "timeout": 15000,
+      "environment": {
+        "OBSIDIAN_API_KEY": "{env:OBSIDIAN_API_KEY}",
+        "OBSIDIAN_HOST": "127.0.0.1",
+        "OBSIDIAN_PORT": "27124"
+      }
+    }
+  },
   "permission": {
     "*": "ask",
     "read": {

project-knowledge/01-current/work-items.md

@@ -20,7 +20,7 @@ Update the per-ticket files first when scope, status, sequencing, or communicati
 
 - `PDIAP-15838` - Remove Apollo for iOS
   Detail: `project-knowledge/02-work-items/pdiap-15838.md`
-  Current note: assigned to the next sprint; current context and investigation notes remain relevant, but it should not be described as current-sprint in-progress implementation work.
+  Current note: assigned to the next sprint; current context and investigation notes remain relevant, model decoupling for the active path is now cleaner, and the next technical focus is the remaining Apollo runtime/infrastructure cleanup rather than Apollo-generated model replacement.
 
 - `PDIAP-15836` - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment
   Detail: `project-knowledge/02-work-items/pdiap-15836.md`

project-knowledge/02-work-items/pdiap-15836.md

@@ -8,7 +8,7 @@ systems: [xflowsdk, xflowviewmaker, ftframeworks]
 workstreams: [xflow-swiftui-migration, consumer-integration]
 people: [jeff-dewitte]
 related: [pdiap-14859]
-updated: 2026-04-16
+updated: 2026-04-21
 tags:
   - work-item
   - fidelity
@@ -53,3 +53,6 @@ tags:
 
 - Keep the scope framed as lifecycle sequencing in a pure SwiftUI environment, not only as a symptom like multiple modal presentation.
 - If mentioned externally, keep it separate from `PDIAP-15838`.
+- The Confluence/root-cause document was updated to reflect that FTTransfer changes are not the primary need anymore.
+- The primary recommendation is to adjust the dismissal handling/sequencing correctly in the hosting path.
+- FTTransfer improvements can still be mentioned as a secondary improvement, but not as a required change to reproduce the same visual behavior.

project-knowledge/02-work-items/pdiap-15838.md

@@ -59,6 +59,14 @@ tags:
 - The next AI follow-up should focus only on the first step and ask GitHub Copilot to corroborate residual Apollo-model dependencies by using `xcodebuild` failures, not just static reference search.
 - Follow-up enum validation indicates at least some Apollo-generated enum types can likely be replaced with native Swift `enum Name: String` definitions without preserving Apollo `EnumType` behavior. For the currently checked production callers, Copilot reported no Apollo-specific enum API dependency for `XFlow.ContentType`, `XFlow.ScreenshotFormat`, and `XFlow.NextTransitionType`; current behavior relies on `rawValue`, equality/switch use, and `init?(rawValue:)`-style parsing.
 - The currently observed fallback behavior is simple and code-local: unknown `ContentType` values are skipped by converter guards, unknown `ScreenshotFormat` values fall back to PDF in downstream callers, and unknown `NextTransitionType` values currently propagate as `nil` where the target property is optional.
+- Design direction for the Phase 1 Apollo cleanup: prefer replacing `XFlow.Slot` with a native Swift `Slot` model instead of collapsing it to `[String: String]` through the full production path. Keep `[String: String]` only at the boundary where the REST request/DTO is built in the worker or transport layer.
+- The current implementation state is cleaner on the model side: Apollo-generated production models have now been replaced with native Swift models/enums for the active path, so the next focus should move from model decoupling to remaining Apollo runtime/infrastructure dependencies.
+- The `XFlowInitManager` runtime/init cleanup step has now been applied successfully: the three `NetworkClient.shared.updateAppSyncURL(...)` calls were removed from the start/session lifecycle paths, `getAppSyncEndPoint()` was removed after becoming unused, and the project still compiles with `getEndPoint()` left intact for current REST selection.
+- `NetworkClient.swift` can likely stay temporarily in the tree as a disconnected compatibility shim until broader package/project cleanup, and `XFlowInitManagerConfig.swift` may need to keep AppSync getter/config surface temporarily to avoid an accidental public API break.
+- Follow-up runtime scan now suggests `GraphQL/NetworkClient.swift` has no live production callers and only self-references remain inside the file. The proposed next removal order is to delete `GraphQL/NetworkClient.swift` first, build/reference-check, then delete `GraphQL/ApolloGeneratedCode`, while keeping the AppSync members in `XFlowInitManagerConfig.swift` temporarily as compatibility-only surface.
+- Current local state after broader cleanup: runtime Apollo decoupling and most Apollo-specific test cleanup now appear complete, production code compiles cleanly aside from a pre-existing environment issue, and no live Apollo imports/references remain in production code. Remaining work is mainly package/build cleanup plus the deferred compatibility API surface in `XFlowInitManagerConfig.swift`.
+- Current local state now also indicates the test target compiles cleanly after a minimal follow-up update to `XFlowTransportSelectionTests.swift`, preserving REST-relevant transport tests while removing obsolete GraphQL/Apollo assertions. The remaining Apollo-removal work appears concentrated in package/build cleanup plus the deferred compatibility API surface in `XFlowInitManagerConfig.swift`.
+- Latest follow-up says the Apollo package/build cleanup has also now been applied: direct Apollo dependency references were removed from package/build ownership surfaces, leaving the main remaining follow-up as Fid4 validation plus any later decision on whether to deprecate/remove the temporary AppSync compatibility getters in `XFlowInitManagerConfig.swift`.
 - Apollo source-level cleanup appears sequenced as: replace `XFlow.Slot` with a transport-agnostic model first, decouple `XFlowInitManager` from `NetworkClient` while preserving current REST endpoint behavior, then remove runtime GraphQL code, project wiring, Apollo-only tests/scripts/docs, and finally treat any transitive PicoSDK Apollo dependency as a separate dependency-exit task.
 - Apollo may still remain in the pod graph transitively through PicoSDK even after source-level cleanup, so "Apollo removed" should be framed carefully unless the dependency graph is also cleared.
 

project-knowledge/03-context/process/communication-rules.md

@@ -2,7 +2,7 @@
 type: process
 project: fidelity
 status: active
-updated: 2026-04-16
+updated: 2026-04-21
 tags: [process, communication]
 ---
 
@@ -26,12 +26,11 @@ These rules keep standups, Jira notes, and Mattermost messages aligned with the
 - 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
+- Prefer `toggle` over `flag` in Fidelity-facing communication, unless naming a specific external tool concept such as LaunchDarkly feature flags
 - 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
 
----
-
 ## English Quality Rules
 
 - Write in natural, professional US English that sounds like a fluent engineer wrote it

project-knowledge/06-daily/2026-04-20.md

@@ -50,6 +50,7 @@ updated: 2026-04-20
 - Follow-up AI analysis says the `XFlow.Slot` replacement may be simpler than expected: no new model may be needed because `activitySession?.stagedValues()` already yields `[String: String]` and `XFlowUpdateSlotsRequest.slots` already accepts `[String: String]`. If that holds in code, the current Apollo dependency is mostly an unnecessary intermediate conversion step.
 - Local trial changes showed that `XFlow.Slot` is likely not the only remaining Apollo-dependent model in the first-step cleanup path, so the next Copilot pass should validate the real dependency surface through `xcodebuild` errors instead of assuming static references tell the whole story.
 - Additional Copilot validation on Apollo-generated enums says the checked production callers for `XFlow.ContentType`, `XFlow.ScreenshotFormat`, and `XFlow.NextTransitionType` appear to need only native `String`-backed enums plus the current local fallback behavior, not Apollo `EnumType` semantics.
+- Current design preference for the Apollo cleanup is to keep domain-facing code using a native `Slot` model and limit `[String: String]` to the REST boundary/DTO construction layer instead of pushing the dictionary type through the full interactor/worker path.
 - David clarified additional Fidelity-side process context: Quy acts as Scrum Master, manages retrospectives, DSE/daily syncs, sprint review, and sprint planning, retrospectives use Miro, Jira is the tracking system, and the Fidelity-side sprint cadence is two weeks with labels like `PDIAP 26Q1.1` and `PDIAP 26Q2.1`.
 - David corrected the Q2 sprint examples: `PDIAP 26Q2.1` is `3/26 - 4/09`, and `PDIAP 26Q2.2` is `4/09 - 4/23`.
 - David clarified that Jira should be represented as a first-class Fidelity tool/system because it is used more heavily than Confluence in day-to-day work tracking.

project-knowledge/06-daily/2026-04-21.md

@@ -0,0 +1,66 @@
+---
+type: daily
+project: fidelity
+date: 2026-04-21
+status: active
+focus: [rest-migration, xflow-swiftui-migration]
+work-items: [pdiap-15838, pdiap-15836]
+blockers: []
+tags:
+  - daily
+  - fidelity
+updated: 2026-04-21
+---
+
+# 2026-04-21
+
+## Focus
+
+- Continue `PDIAP-15838` Apollo-removal cleanup.
+- Continue validating the Apollo-removal state.
+- If time allows, publish new XFlow and XFlowViewMaker versions.
+
+---
+
+## Work Done
+
+- Cleaned up the active production model layer so it no longer depends on Apollo-generated models for the current path.
+- Removed the three `NetworkClient.shared.updateAppSyncURL(...)` calls from `XFlowInitManager` and removed `getAppSyncEndPoint()` after it became unused; the project still compiles.
+- Updated the Confluence/root-cause document for the FTTransfer discussion so it now reflects the current recommendation.
+- Removed the `ApolloGeneratedCode` runtime tree and its project wiring from XFlowSDK.
+
+---
+
+## Findings
+
+- The model-decoupling step for `PDIAP-15838` is now in a cleaner state.
+- The next focus should shift to the remaining Apollo-dependent runtime and infrastructure surface: init/session coupling through `NetworkClient`, Apollo-generated/runtime code that is no longer needed, and Apollo-specific tests/scripts/build wiring.
+- Any Apollo dependency that remains only through PicoSDK should be treated separately from source-level cleanup.
+- Copilot's focused runtime/init guidance says the safest next source-level step is to remove only the three `updateAppSyncURL(...)` calls from `XFlowInitManager`, then delete internal `getAppSyncEndPoint()` if it becomes unused, while leaving `NetworkClient.swift` and `XFlowInitManagerConfig.swift` in place temporarily as disconnected compatibility surface until later cleanup.
+- After that step, no live init/session runtime wiring from `XFlowInitManager` into Apollo/AppSync remains; the remaining Apollo surface appears to be disconnected compatibility/runtime code plus later package/build/test cleanup.
+- Follow-up scan says `GraphQL/NetworkClient.swift` now appears runtime-dead for production, `GraphQL/ApolloGeneratedCode` appears unreferenced by production runtime after model cleanup, and the safest next step is to remove `NetworkClient.swift` first, then validate before removing `ApolloGeneratedCode`.
+- Broader Apollo cleanup has now removed `NetworkClient.swift`, `ApolloGeneratedCode`, Apollo-specific test files/mocks, and related project-file entries. Current reported state says production code has zero live Apollo imports/references and retained REST behavior, while remaining follow-up work is package/build cleanup plus the deferred compatibility API surface in `XFlowInitManagerConfig.swift`.
+- Test-target cleanup is now also in a good state: a minimal update to `XFlowTransportSelectionTests.swift` removed obsolete GraphQL/Apollo assertions, preserved REST-oriented coverage, and left no remaining non-environment test-target compile errors.
+- The latest cleanup pass also removed the remaining direct Apollo package/build references, so the story is now in a cleaner post-removal state and ready for consumer-side validation from Fid4.
+- The current FTTransfer communication should say the primary fix is the dismissal adjustment in the UIKit hosting path; FTTransfer-side improvements are secondary and not strictly required to reproduce the same visual behavior.
+- After the `ApolloGeneratedCode` removal, local compilation still succeeds for David; the Copilot-reported `ApexKitSwiftUI` blocker should be treated as environment-specific noise unless it becomes reproducible in the real local build.
+- No live production Apollo runtime references remain in `XFlowSDK/XFlowSDK`; the next cleanup surface is deferred test references plus any intentionally retained AppSync compatibility APIs.
+
+---
+
+## Next Steps
+
+- Confirm whether `NetworkClient.swift` still has any live production callers or can now be treated as removable runtime dead code.
+- Confirm whether `XFlowInitManagerConfig.swift` AppSync getters are truly compatibility-only or still externally used.
+- Identify the runtime Apollo files that can now be removed safely after the model and init cleanup.
+- Remove Apollo-only tests, mocks, codegen scripts, and build wiring once runtime references are gone.
+- Treat any transitive PicoSDK Apollo dependency as a separate dependency-exit step.
+- Continue cleanup by removing GraphQL/Apollo-era test references and related test-only helpers without changing production runtime behavior.
+- Continue validating the Apollo-removal state today.
+- If time allows, publish new XFlow and XFlowViewMaker versions.
+
+---
+
+## Blockers
+
+- None currently.

prompts/standup.md

@@ -1,53 +1,87 @@
 # Standup Prompt
 
-Use `project-knowledge/01-current/current-work.md`, `project-knowledge/01-current/work-items.md`, the relevant files under `project-knowledge/02-work-items/`, `project-knowledge/03-context/project.md`, `project-knowledge/03-context/workstreams/index.md`, `project-knowledge/03-context/process/communication.md`, `project-knowledge/04-people/manager.md`, the previous workday Mattermost context, today's daily note if present, and the latest available Mattermost context.
+Use `project-knowledge/01-current/current-work.md`, `project-knowledge/01-current/work-items.md`, the detailed files referenced from that active-work summary, `project-knowledge/03-context/project.md`, `project-knowledge/03-context/workstreams/index.md`, `project-knowledge/03-context/process/communication.md`, `project-knowledge/04-people/manager.md`, the previous workday communication context, today's daily note if present, and the latest available communication context.
 
-Generate a standup update for an iOS engineer working on Fidelity.
+Generate a standup update for the active project profile.
 
-Requirements:
+## Output contract
+
+- Use the greeting required by the active profile or command. If no greeting is specified, omit the greeting and start with the previous-work section.
+- Return the greeting, a previous-work section, and `Today:`
+- Include `Blockers:` only when there is a real blocker to report; omit the entire section when there are no blockers
+- Use `Yesterday:` only when the previous-work section truly refers to yesterday; otherwise use a truthful label such as `Last workday:` or the weekday/date when clearer
+- Return Markdown that is ready to copy/paste directly into the configured team communication tool
+- Use one top-level bullet per work item
+- Use indented sub-bullets only when they improve clarity
+- Prefer one concise sub-bullet when nearby events are part of the same continuous context
+- Keep sub-bullets in chronological order within each work item
+- Keep the whole standup concise and ready to send
+
+## Selection rules
 
 - Use the most recent context only
-- Be specific about what was worked on during the previous workday, not necessarily the previous calendar day
+- `Yesterday` must describe work that actually happened on the previous workday, not older status changes that still appear in current memory
 - On Mondays, use Friday's work context unless a later prior day has Mattermost activity
 - If the previous calendar day has no work activity or is OOO/weekend, use the latest prior day with Mattermost activity
-- Mention debugging findings only if they materially changed understanding
-- Clarify auth-dependent behavior when relevant
-- Mention Jira IDs and approved titles when they are available and clearly tied to the reported work
+- Treat the previous workday communication context as the primary source for the previous-work section
+- If a latest daily log exists, use its `Work Done` and same-day findings as the primary source for `Yesterday`; use current memory only to disambiguate, not to backfill unrelated older events
+- Do not reuse older investigation context from `current-work.md` as `Yesterday` unless the latest daily log or previous-workday communication confirms it happened on that workday
+- Prefer updates directly tied to active work items over side questions, context refreshes, or manager-only reminders
+- Exclude items that are not directly tied to a story unless they are true blockers
+- Do not mention stories assigned to a future sprint unless they are a real blocker for today's work
+- Do not include `Today` items that are known not to be worked on today
+
+## Story handling rules
+
+- Mention work item IDs and approved titles when they are available and clearly tied to the reported work
 - Prefer including story titles whenever a reported update maps clearly to a Jira item
 - Prefer story-based reporting when the work maps clearly to a Jira item
-- Prefer updates directly tied to active work items over side questions, context refreshes, or manager-only reminders
-- If documentation or root cause updates directly support a story, group that work under the related story instead of reporting it as a separate unrelated item
-- Avoid vague phrases and generic progress language
-- Separate the main issue from unrelated follow-up work unless both are explicitly relevant today
-- Omit standup items that are not directly related to a story unless they are a real blocker
-- Prefer evidence-backed statements over assumptions
+- If documentation, root-cause analysis, or implementation analysis directly supports a story, group that work under the related story instead of listing it separately
+- When one work item has multiple concrete updates, keep them under one top-level `ID - Title` bullet
+- When pairing a work item ID with a title, prefer `ID - Title` or `ID Title`; do not use commas between them
+
+## Writing rules
+
 - Write in natural US English that can be forwarded externally without rewriting
-- Write the standup as David's external progress report
-- For standups that will also be sent to Teams, prefer plain outcome language over internal implementation jargon; avoid terms like `fallback` unless they are explained well enough for a broader audience
+- Write the standup as the workspace user's progress report
+- Be specific, concise, and evidence-backed
+- Avoid vague phrases and generic progress language
+- Mention debugging findings only if they materially changed understanding
+- Clarify auth-dependent behavior when relevant
+- Separate external issues from regressions when that distinction matters
+- For standups that may also be sent outside the immediate team, prefer plain outcome language over internal implementation jargon; avoid unexplained terms like `fallback`
 - If a release or propagation step is waiting on approvals or pipeline work, make the parallel work explicit instead of sounding like the day is blocked on waiting alone
-- Do not mention Jeff by name
-- Do not mention Mattermost because it is internal-only communication
-- Use bullet points for each item
-- When one Jira item has multiple concrete updates, use one top-level Jira bullet and indented markdown sub-bullets instead of repeating the same Jira ID/title multiple times
-- When pairing a Jira ID with a title, prefer `ID - Title` or `ID Title`; do not use commas between them
-- Keep the sub-bullets in chronological order within each Jira item
-- Do not mention stories assigned to a future sprint unless they are a real blocker for today's work
-- Do not include "today" items that are known not to be worked on today
-- Return Markdown that is ready to copy/paste directly into Mattermost
-- Prefer one concise sub-bullet when nearby events are part of the same continuous context; split into multiple sub-bullets only when separation improves clarity
-- Keep it concise and ready to send
+- Do not mention manager or stakeholder names except in the configured greeting or when the user explicitly asks
+- Do not mention internal evidence sources or communication tools unless the user explicitly asks
+
+## Compression rules
+
+- Combine closely related events into one sentence when they share the same context and timeline
+- Split into multiple sub-bullets only when separation improves accuracy or readability
+- Prefer direct chronological phrasing such as `Started by...`, `Then...`, `Later...` when that keeps one bullet accurate and concise
+
+## Anti-patterns to avoid
+
+- Do not report a work item as worked yesterday just because it is now `Done`
+- Do not pull old closure events from durable memory into a new standup unless they happened on the previous workday
+- Do not mention next-sprint work in `Today` when today's plan is already known and different
+- Do not turn context notes into fake progress lines
 
 Format:
 
+<optional configured greeting>
+
 Yesterday:
-- PDIAP-#### - Title
+- ITEM-#### - Title
   - Update 1
   - Update 2
 
 Today:
-- PDIAP-#### - Title
+- ITEM-#### - Title
   - Next action 1
   - Next action 2
 
 Blockers:
 - ...
+
+If there are no blockers, omit `Blockers:` entirely.