feat(memory): add memory extension with core functionality and tests

- Implemented MemoryStore class for managing concepts with YAML frontmatter.
- Added methods for creating, reading, updating, and deleting concepts.
- Introduced locking mechanism for concurrent access.
- Developed search and hinting capabilities for concept retrieval.
- Created tests for access control and store functionality.
- Added long-term memory skill documentation and operational guidelines.
- Included package.json and package-lock.json for dependency management.
This commit is contained in:
syntaxbullet
2026-07-23 20:35:08 +02:00
parent 212af9301e
commit 91e5f44cc8
13 changed files with 1333 additions and 4 deletions

View File

@@ -0,0 +1,35 @@
---
name: long-term-memory
description: Use Kimiko's durable OKF memory when the user asks to remember, forget, or recall something; refers to prior conversations; asks about a known person, project, preference, or decision; states a durable correction or preference; or says something is off the record. Do not use for current-turn-only facts.
---
# Long-term memory
## Decision table
| Situation | Action |
|---|---|
| Explicit “remember this” | Search for duplicates; read a matching concept; then write. |
| Explicit recall or “what do you remember?” | Search, then read only relevant concepts. |
| Reference to an earlier conversation | Search before answering. |
| Stable preference or correction | Ask whether to remember it unless storage was explicitly requested. |
| Confirmed long-lived project decision | Offer to remember it. |
| New information conflicts with memory | Clarify; never silently overwrite. |
| Transient task, speculation, or casual remark | Do not store. |
| Credential, secret, or sensitive fact | Do not store without an explicit informed request. |
| “Don’t remember this” or “off the record” | Do not store it. |
| Explicit forget request | Search, read, then forget with exact-ID confirmation. |
Store only information likely to matter in another session, sufficiently stable, and explicitly requested or confirmed.
## Workflow
1. Call `memory_search` in the current user turn. Retrieval hints do not replace this step.
2. Call `memory_read` only for relevant IDs. Existing concepts must be read before update or deletion.
3. Write one coherent concept with `memory_write`; update an existing ID rather than duplicating it.
4. Use structured Markdown and explicit links such as `[Atlas](/projects/atlas.md)`.
5. After mutation, tell the user briefly which concept was created, updated, or forgotten.
Never author frontmatter, timestamps, indexes, or logs. The extension generates, validates, repairs, and verifies them deterministically.
For diagnostics and recovery policy, read [operations.md](references/operations.md).

View File

@@ -0,0 +1,26 @@
# Memory operations
## Storage
The OKF bundle is `${PI_CODING_AGENT_DIR}/memory`. Concept IDs are lowercase bundle-relative paths without `.md`. `index.md` and `log.md` are reserved.
## Commands
- `/memory-path` — show the bundle path.
- `/memory-check` — report structural problems without modifying concepts.
- `/memory-check --repair` — repair deterministically and regenerate indexes.
## Turn-scoped access
Each user turn clears prior search/read authorization and removes detailed memory tools. Explicit memory language may reveal the tools early, and `memory_search` enables them otherwise; visibility never bypasses the workflow gate. Existing concepts must be returned by search and read in that same turn before mutation. Metadata-only retrieval hints are injected through the ephemeral per-turn system prompt, never session messages, so previous hints do not accumulate.
## Repair policy
- Missing/invalid timestamps use the file's modification time; the model never supplies them.
- Missing types become `Recovered Concept`.
- Invalid or absent frontmatter is backed up under `memory/.recovery/`, then replaced with valid metadata while retaining the recoverable body.
- Generated index sections are replaced between marker comments; human text outside the markers is retained.
- Writes use a bundle lock, atomic rename, read-after-write semantic verification, and one deterministic retry.
- No-op writes retain the prior timestamp and do not create a log entry.
Inspect any concept carrying `repair_backup` because malformed metadata may require human review. The bundle is ignored by Git by default; opt into private versioning only with an explicit retention and deletion policy. The extension never auto-commits.