feat: add mem9 integration documentation, enhance AI-to-AI prompting guidelines, and create daily logs for May 1 and May 7

agent-memory/integrations/mem9.md

@@ -0,0 +1,77 @@
+---
+type: agent-integration
+status: proposed
+updated: 2026-05-05
+tags:
+  - memory
+  - integration
+  - mem9
+---
+# mem9 Integration
+
+## Goal
+
+Use mem9 as a cross-session, cross-agent recall layer without replacing the workspace's auditable Markdown memory.
+
+## Source Of Truth
+
+`project-knowledge/` remains the canonical human-readable Fidelity project memory.
+
+`agent-memory/` remains the canonical operating memory for agent behavior, workflows, promotion rules, and integration guidance.
+
+mem9 should recall and surface relevant facts, but durable project updates must still be promoted into the correct Markdown file when they become canonical.
+
+## Recommended Scope
+
+Use a project-scoped mem9 profile for this workspace when possible so Fidelity context, agent behavior, and personal/global memories do not collapse into one undifferentiated pool.
+
+Do not bulk-import raw inboxes, generated sync output, full chat transcripts, or broad project folders by default. Import only curated facts, stable preferences, and distilled summaries.
+
+## What To Store
+
+- Stable user/workspace preferences that should survive sessions.
+- Durable agent behavior rules that are useful across Codex/OpenCode sessions.
+- Verified project facts already present in canonical Markdown.
+- Short summaries of current work that help recall where to begin.
+
+## What Not To Store
+
+- Secrets, credentials, API keys, tokens, auth cookies, or private environment values.
+- Raw Mattermost/Slack inbox dumps.
+- Fidelity product source code or proprietary implementation snippets.
+- Unverified assumptions, temporary sync failures, or tooling chatter.
+- Duplicates of every daily note without curation.
+
+## Efficient Use Pattern
+
+1. Recall mem9 early for user preferences and relevant workspace history.
+2. Load hot Markdown context from `AGENTS.md` / `opencode.json` instructions.
+3. For current-work questions, still inspect `project-knowledge/01-current/current-work.md` and the latest relevant daily note.
+4. Answer or act from verified context.
+5. When the interaction adds durable knowledge, update canonical Markdown first; store a compact mem9 memory only if it improves future recall.
+
+## Codex Setup Notes
+
+The upstream mem9 Codex integration uses a marketplace plugin and managed hooks. `$mem9:setup` is the primary setup command. It manages shared profiles, credentials, user/project scope, and hook repair.
+
+Expected local surfaces include:
+
+- `$CODEX_HOME/hooks.json`
+- `$CODEX_HOME/config.toml`
+- `$CODEX_HOME/mem9/`
+- `$MEM9_HOME/.credentials.json`
+- `<project>/.codex/mem9/config.json` for project overrides
+
+Keep `$MEM9_HOME/.credentials.json` outside the repository and never commit API keys.
+
+## Validation Checklist
+
+- Confirm Codex CLI is at least the version required by the mem9 plugin.
+- Confirm Node.js 22 or newer is available to the Codex runtime.
+- Install the mem9 Codex plugin from the mem9 marketplace.
+- Run `$mem9:setup` and choose hosted API or self-hosted API.
+- Apply project scope for this workspace if using a dedicated Fidelity profile.
+- Verify `$mem9:recall` returns relevant memories.
+- Verify `$mem9:store` stores one approved non-sensitive memory.
+- Inspect mem9 dashboard / memory list for accidental sensitive content.
+- Keep canonical Markdown updates auditable through git.

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

@@ -1,7 +1,7 @@
 ---
 type: agent-workflow
 status: active
-updated: 2026-04-17
+updated: 2026-05-06
 tags:
   - process
   - ai-prompting
@@ -58,6 +58,9 @@ Use this structure by default:
 - 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.
+- For VS Code multi-root Copilot workflows, preserve repo-provided customizations such as `.github/prompts`, `.github/instructions`, `.github/agents`, `.github/skills`, and `AGENTS.md`. Shared `fidelity-ai-copilot` customizations should supplement these repo files, while repo-specific instructions should be treated as the practical authority when they conflict.
+- For Fidelity Jira/Confluence access from GitHub Copilot CLI or VS Code, do not assume the approved access method. First have the target AI read the current Fidelity-provided human instructions from Confluence or local exported docs, then configure the smallest matching workflow. If those instructions require terminal `curl` with environment variables such as `COPILOT_JIRA_URL` and `COPILOT_JIRA_TOKEN`, enforce that path; otherwise follow the documented Fidelity-approved method. Never print, persist, or hardcode tokens.
+- Treat `fidelity-ai-copilot` as a self-improving AI harness rather than a static prompt dump: the target AI should notice recurring useful workflows, newly discovered internal instructions, and tool changes, then propose small auditable updates to instructions, skills, prompts, agents, specs, or validation checklists. It should ask before making broad changes and keep product repos clean.
 
 ---
 

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

@@ -103,6 +103,7 @@ tags:
 - For standups that may also be sent to Teams, keep the update concise, omit internal review-feedback details, and avoid phrasing like `confirmed` when the audience lacks the internal context for what was confirmed
 - When a release item is waiting on approvals or pipeline work, make the parallel story work explicit instead of making the update sound blocked on waiting alone
 - Standups should omit side questions or manager-only context refreshes unless they materially changed story work
+- For `PDIAP-16167` standups after May 1, do not report story creation as previous-day work unless the previous-workday evidence explicitly says the story was created that day; focus on report publication, findings shared, closure, or remaining follow-up instead
 - For `PDIAP-15838` standups, focus on Apollo-removal progress and the `PicoSDK` transitive dependency work; omit extra exploratory asks unless they directly changed the story outcome or created a blocker
 - If a root cause document or other documentation update directly supports a story, it should be reported under that story instead of as a separate standalone item
 - Standups should omit items not tied to a story unless they are real blockers

project-knowledge/02-work-items/IA improvements.md

@@ -0,0 +1,17 @@
+- Experiment-driven investigation
+	- Debug print auto added
+		- Iteratively detect now possible debug prints
+	- Structured ticket artifacts with jira, patch, prompts, sessions
+	- Tolerant to pre-experiment fix steps to fix any build error between experiments
+	- Swift skill, specialized to debug prints
+- Xcode logs analysis
+	- Find and read the full Xcode artifacts
+	- Extract relevant logs
+- Xcode Integration
+	- Efficient use of xcode commands to build, test, contexted for tuist, cocoapods, sample projects
+	- Execute unit test proficiently, like executing only new tests or related
+- Investigation: Differences from skills with cli commands vs mcps
+- Investigation: Differences of skills vs instructions from vscode copilot
+- Investigation: Differences from agents vs skills using agent, what is more general? correct relationship and use
+- Charles Proxy integration
+- LaunchDarkly integration

project-knowledge/06-daily/2026-05-01.md

@@ -22,7 +22,6 @@ updated: 2026-05-04
 
 ## Work Done
 
-- Created `PDIAP-16167 - AccountLink - XFlow causing web view rewrites investigation`.
 - Prepared the root-cause report for the FTTransfer AccountLink issue.
 - Verified that XFlow eventing does not appear to be the direct cause of the reload.
 - Verified that the issue persists when rolling back `XFlowSDK` to `v0.1.0`, which predates REST and modern architecture changes.

project-knowledge/06-daily/2026-05-07.md

@@ -0,0 +1,19 @@
+---
+type: daily
+project: fidelity
+date: 2026-05-07
+updated: 2026-05-07
+focus: [pdiap-15836, pdiap-12284, rest-validation]
+work-items: [PDIAP-15836, PDIAP-12284]
+blockers: [production-test-account]
+tags:
+  - daily
+  - fidelity
+---
+
+# 2026-05-07
+
+## Notes
+
+- Clarified REST validation context: forcing Fid4 production endpoints by editing `initializeAppEnvironment` is related to validating REST enablement, not to the Apollo-removal story. It was a point-in-time ask that may still be useful later, but the immediate need is access to a production test account to complete validation.
+- Clarified `PDIAP-15836` status: the dismissal approach David tested appears coupled to the `UIHostingController` removal path, but there may be a strategy to isolate the fix. David will investigate whether the lifecycle/dismissal fix can be applied independently.