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

This commit is contained in:
2026-05-08 07:28:00 -06:00
parent f72a828805
commit 1c9b9fd51a
6 changed files with 118 additions and 2 deletions

View File

@@ -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.

View File

@@ -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.
---