memorix 1.2.2 → 1.2.4

package/CHANGELOG.md

@@ -2,6 +2,33 @@
 
 All notable changes to this project will be documented in this file.
 
+## [1.2.4] - 2026-07-26
+
+### Added
+- **One-call continuation for CLI-only agents** -- Added `memorix resume "<task>"`, a direct terminal entry that returns the same bounded Memory Autopilot Workset as Project Context without requiring MCP discovery or command probing.
+
+### Changed
+- **Continuation is a delivery choice, not a separate memory silo** -- Project Context now recognizes continuation language independently of its task lens. It adds only the latest meaningful session summary and up to three readable durable anchors, with source records in the existing context receipt. Ordinary new tasks remain free of old-session dumps.
+- **Stable agent fallback guidance** -- Generated skills and rules now direct an agent with unavailable MCP to make exactly one task-aware CLI call: `memorix resume` for prior work or `memorix context` for a new task. Continuation requests must take that brief before local file/Git archaeology, and an absent `.memorix` directory is not treated as proof that no durable memory exists. This prevents broad command enumeration, repeated search loops, and false cold-start conclusions.
+
+### Fixed
+- **Claude continuation delivery** -- Claude Code now receives an explicit continuation's bounded prior-work Workset through its official `UserPromptSubmit.additionalContext` response, rather than relying on an advisory rule or a SessionStart message the host does not place in model context. `memory.inject = "silent"` still disables automatic injection.
+- **Fresh-install SQLite resilience** -- When the optional `better-sqlite3` native binary is missing on a supported Node 22 runtime, Memorix now opens the same local `memorix.db` through Node's built-in SQLite instead of losing session and durable-memory reads across CLI or hook processes. No data migration or configuration change is required.
+- **Standard TOML literal strings** -- Project and global configuration now accepts single-quoted TOML strings, including `#` characters inside the literal value.
+- **MCP continuation summary parity** -- `memorix_project_context` now includes the same bounded prior-session and durable-memory evidence in `format: "summary"` as it does in the default prompt format, so agents that request a compact summary do not lose a valid handoff.
+- **Actionable continuation anchors** -- Bounded continuation text no longer cuts a technical flag or symbol halfway through. The shared guidance also avoids redundant Context Pack/search/detail calls after a complete Autopilot brief, keeping the default agent path compact.
+- **Autopilot duplicate retrieval** -- A completed MCP Project Context now holds a short-lived delivery boundary. Follow-up search/detail calls do not re-send memories already represented in that brief unless the user explicitly asks to inspect the underlying record.
+- **Read-only memory mutation** -- A task that asks for read-only work or says not to modify files now rejects automatic `memorix_store` writes. An agent must have an explicit user request before it can override that boundary.
+- **Prior-work privacy parity** -- Continuation retrieval applies the same project, team, and personal-memory visibility reader as session context, including canonical project aliases. A different identity cannot receive another agent's personal durable memory through the new delivery path.
+- **Rule-surface drift** -- The shared automatic-memory rule file now carries the same one-call CLI fallback contract as setup-generated agent guidance.
+
+## [1.2.3] - 2026-07-25
+
+### Fixed
+- **Session context now respects observation visibility** -- Automatic session handoff and manual session-context reads in the CLI, MCP server, and Workbench apply the caller's project, team, and personal-memory reader. A new identity cannot receive another agent's personal observations through session startup.
+- **Identity before handoff** -- CLI and MCP coordination sessions establish their explicit identity before assembling prior context, so an owner's own personal records remain available while a newly joined agent fails closed.
+- **Graph-side disclosure guard** -- Agent-facing session handoff no longer derives graph-neighbor hints from graph relations that do not yet carry observation visibility metadata.
+
 ## [1.2.2] - 2026-07-25
 
 ### Added

package/README.md

@@ -59,7 +59,7 @@ Memorix is more than a memory store. It also installs agent integrations, keeps
 
 | Capability | What it does | Entry point |
 | --- | --- | --- |
-| Memory Autopilot | A bounded task Workset with start files, current memory, source-backed knowledge, workflow starts, cautions, and verification | `memorix context --task "..."`, `memorix_project_context` |
+| Memory Autopilot | A bounded task Workset with start files, current memory, source-backed knowledge, workflow starts, cautions, and verification | `memorix context "..."`, `memorix resume "..."`, `memorix_project_context` |
 | Observation Memory | Searchable facts, fixes, gotchas, session summaries, and implementation notes scoped to the current Git project | `memorix memory`, MCP memory tools |
 | Code State and Code Memory | Versioned local code snapshots, file/symbol links, and freshness checks. The built-in Lite index is always honest about its limits; an already-indexed local CodeGraph can add a bounded semantic outline | `memorix codegraph`, automatic context refresh |
 | Git Memory | Commit-derived engineering facts that answer what changed, where, and why it matters | `memorix ingest commit`, git hook |
@@ -317,7 +317,7 @@ npm uninstall -g memorix
 ### Work from the CLI
 
 ```bash
-memorix --cwd /path/to/repo context --task "continue release blocker"
+memorix --cwd /path/to/repo resume "continue release blocker"
 memorix memory search --query "release blocker"
 memorix memory --help
 
@@ -357,7 +357,7 @@ This opens memcode, a terminal coding agent that uses the same Memorix project m
 
 Search is project-scoped by default. `scope="global"` searches across projects. The search boosts Git Memory for "what changed" questions and reasoning records for "why" questions.
 
-`memorix context --task "..."` is the default Memory Autopilot entry. It builds a compact task-lensed brief for agents: bugfix tasks lean toward tests and repros, release tasks lean toward package/changelog/build checks, onboarding tasks lean toward docs and entry points, and stale or unrelated memories stay in warning lanes instead of flooding the prompt. Agents should read the suggested files before trusting stored memory.
+`memorix context "..."` is the default Memory Autopilot entry. It builds a compact task-lensed brief for agents: bugfix tasks lean toward tests and repros, release tasks lean toward package/changelog/build checks, onboarding tasks lean toward docs and entry points, and stale or unrelated memories stay in warning lanes instead of flooding the prompt. A normal new task does not receive an old-session dump. For an explicit continuation, `memorix resume "..."` adds only the latest useful session summary and up to three readable durable anchors. Agents should read the suggested files before trusting stored memory.
 
 <h2 id="runtime-modes"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-runtime.svg"><img src="assets/tags/section-runtime.svg" alt="Runtime Modes" height="32" /></picture></h2>
 

package/README.zh-CN.md

@@ -59,7 +59,7 @@ Memorix 不只是一个记忆库。它还负责安装 Agent 接入、保留有
 
 | 能力 | 作用 | 入口 |
 | --- | --- | --- |
-| Memory Autopilot | 给新 Agent session 一份有预算的任务 Workset，包含起步文件、当前记忆、来源知识、工作流首步、风险提示和验证建议 | `memorix context --task "..."`、`memorix_project_context` |
+| Memory Autopilot | 给新 Agent session 一份有预算的任务 Workset，包含起步文件、当前记忆、来源知识、工作流首步、风险提示和验证建议 | `memorix context "..."`、`memorix resume "..."`、`memorix_project_context` |
 | Observation Memory | 当前 Git 项目内可检索的事实、修复、坑点、session 摘要和实现记录 | `memorix memory`、MCP memory tools |
 | Code State 和 Code Memory | 可版本化的本地代码快照、文件 / symbol 关联和 freshness 检查。内置 Lite 会如实说明边界；已有本地索引的 CodeGraph 可额外给出有预算的语义关系 | `memorix codegraph`、自动 context refresh |
 | Git Memory | 从 commit 中提取工程事实，回答改了什么、在哪里改、为什么重要 | `memorix ingest commit`、git hook |
@@ -317,7 +317,7 @@ npm uninstall -g memorix
 ### 从 CLI 管理记忆
 
 ```bash
-memorix --cwd /path/to/repo context --task "继续处理发布阻塞问题"
+memorix --cwd /path/to/repo resume "继续处理发布阻塞问题"
 memorix memory search --query "release blocker"
 memorix memory --help
 
@@ -357,7 +357,7 @@ memcode
 
 默认搜索当前项目。`scope="global"` 可以跨项目搜索。“改了什么”优先匹配 Git Memory，“为什么”优先匹配 reasoning / decision 记录。
 
-`memorix context --task "..."` 是默认的 Memory Autopilot 入口。它会按任务生成紧凑 brief：修 bug 时偏向测试和复现，发版时偏向 package/changelog/build 检查，接手项目时偏向文档和入口文件；过期或不相关的记忆只作为 warning，不会一股脑塞进 prompt。Agent 应该先读 suggested files，再相信历史记忆。
+`memorix context "..."` 是默认的 Memory Autopilot 入口。它会按任务生成紧凑 brief：修 bug 时偏向测试和复现，发版时偏向 package/changelog/build 检查，接手项目时偏向文档和入口文件；过期或不相关的记忆只作为 warning，不会一股脑塞进 prompt。普通新任务不会自动得到旧会话的文本倾倒；明确要继续之前工作时，用 `memorix resume "..."`，只会补入最近一份有用的会话总结和最多三条当前可读的长期记忆锚点。Agent 应该先读 suggested files，再相信历史记忆。
 
 <h2 id="运行模式"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-runtime.svg"><img src="assets/tags/section-runtime.svg" alt="运行模式" height="32" /></picture></h2>
 

package/TEAM.md

@@ -1,18 +1,18 @@
-# Memorix Team Protocol
-
+# Memorix Team Protocol
+
 Rules for project-scoped autonomous-agent coordination via Memorix team tools. The Team page is an **Agent Team status surface** — it shows explicitly joined autonomous agents, open tasks, locks, messages, handoffs, and what needs attention. It is NOT an organization backend, staffing admin tool, or automatic chat room between separate IDE windows.
 
 Only agents that are intentionally participating in team/task/message/lock workflows need this protocol. Memory-only sessions should stay lightweight and do not need a team identity.
 
 For real autonomous multi-agent development, prefer `memorix orchestrate`: it launches and supervises CLI agent workers through Memorix tasks, context, verification, and fix loops. The team tools support that workflow; they should not be interpreted as proof that unrelated IDE conversation windows can autonomously contact each other.
-
-There are 4 team tools, each with an `action` parameter:
-
-- `team_manage` — action: join / leave / status
-- `team_file_lock` — action: lock / unlock / status
-- `team_task` — action: create / claim / complete / list
-- `team_message` — action: send / broadcast / inbox
-
+
+There are 4 team tools, each with an `action` parameter:
+
+- `team_manage` — action: join / leave / status
+- `team_file_lock` — action: lock / unlock / status
+- `team_task` — action: create / claim / complete / list
+- `team_message` — action: send / broadcast / inbox
+
 ## RULE 1: Start Lightweight, Join Team Explicitly
 
 At the **beginning of every memory session**, before project-scoped memory work:
@@ -25,82 +25,82 @@ At the **beginning of every memory session**, before project-scoped memory work:
 4. Store the returned **agent ID** only after an explicit join — you will need it for subsequent team operations.
 5. Call `memorix_poll` with your agent ID to see current autonomous agents, check available tasks, and read unread messages.
 6. If you need a custom role or capabilities, use explicit `team_manage(join)` so the role overrides the default mapping cleanly.
-
-## RULE 2: Lock Before Edit
-
-Before modifying any file that another agent might also be working on:
-
-1. Call `team_file_lock` with `action: "status"` and the file path to check if it is already locked.
-2. If unlocked, call `team_file_lock` with `action: "lock"`, the file path, and your agent ID.
-3. If locked by another agent, **do not edit that file**. Either:
-   - Work on a different file.
-   - Send a `request` message to the lock owner asking them to release it.
-   - Wait and re-check later.
-4. When you are done editing, call `team_file_lock` with `action: "unlock"` to release the lock.
-
-**Never edit a file locked by another agent.** Lock violations cause merge conflicts and data loss.
-
-Locks auto-expire after 10 minutes. If you hold a lock for extended work, re-lock periodically to refresh the TTL.
-
-## RULE 3: Use Tasks for Work Coordination
-
-When the user assigns work that involves multiple agents or multiple steps:
-
-1. Call `team_task` with `action: "create"` to break the work into discrete tasks with clear descriptions.
-2. Use `deps` to declare dependencies between tasks (a task cannot be claimed until its dependencies are completed).
-3. Call `team_task` with `action: "claim"` to assign a task to yourself before starting work on it.
-4. Call `team_task` with `action: "complete"` and a `result` summary when the task is done.
-5. Call `team_task` with `action: "list"` to see overall progress and find available work.
-
-Rules:
-- Only claim tasks whose dependencies are all completed.
-- Only one agent may claim a given task.
-- If you cannot complete a claimed task, leave the team so the task returns to pending and another agent can pick it up.
-
-## RULE 4: Communication Protocol
-
-Use `team_message` with `action: "send"` for direct messages and `action: "broadcast"` for announcements. Message types and their intended use:
-
-| Type | Use |
-|------|-----|
-| `request` | Ask another agent to do something, release a lock, or provide information. |
-| `response` | Reply to a prior request. |
-| `info` | Share context: discoveries, status updates, warnings about tricky code. |
-| `announcement` | Broadcast to all agents: major state changes, deployment events, breaking changes. |
-| `contract` | Propose or agree on a division of work. Both agents should acknowledge. |
-| `error` | Report a blocking issue that requires another agent's attention. |
-
-Rules:
-- `action: "send"` requires the full UUID of the target agent. Get it from `team_manage` with `action: "status"`.
-- Check your inbox (`action: "inbox"`) at least once before starting new work and once before ending a session.
-- Keep message content under 10KB. Be concise and actionable.
-
-## RULE 5: Leave on Session End
-
-When the session is ending:
-
-1. Call `team_file_lock` with `action: "unlock"` for every file you have locked, or they will remain locked until TTL expiry (10 min).
-2. If you have in-progress tasks you cannot finish, leave them — leaving releases your tasks back to pending.
-3. Call `team_manage` with `action: "leave"` and your agent ID. This marks you inactive, releases all your locks, and clears your inbox.
-
-## RULE 6: Conflict Prevention
-
-- **Check before acting.** Always check team status and file lock status before starting work to understand the current state.
-- **Communicate before diverging.** If you plan to refactor shared code, broadcast an `announcement` first so other agents can save their work.
-- **Respect lock ownership.** The lock holder has exclusive write access. No exceptions.
-- **Prefer small, scoped changes.** Large cross-cutting changes increase conflict risk. Coordinate via tasks and messages if a change touches files other agents are working on.
-- **Do not duplicate work.** Check the task list before creating new tasks. If a similar task exists, claim it instead of creating a duplicate.
-
-## Summary of Required Calls
-
-| When | Tool Call |
-|------|-----------|
+
+## RULE 2: Lock Before Edit
+
+Before modifying any file that another agent might also be working on:
+
+1. Call `team_file_lock` with `action: "status"` and the file path to check if it is already locked.
+2. If unlocked, call `team_file_lock` with `action: "lock"`, the file path, and your agent ID.
+3. If locked by another agent, **do not edit that file**. Either:
+   - Work on a different file.
+   - Send a `request` message to the lock owner asking them to release it.
+   - Wait and re-check later.
+4. When you are done editing, call `team_file_lock` with `action: "unlock"` to release the lock.
+
+**Never edit a file locked by another agent.** Lock violations cause merge conflicts and data loss.
+
+Locks auto-expire after 10 minutes. If you hold a lock for extended work, re-lock periodically to refresh the TTL.
+
+## RULE 3: Use Tasks for Work Coordination
+
+When the user assigns work that involves multiple agents or multiple steps:
+
+1. Call `team_task` with `action: "create"` to break the work into discrete tasks with clear descriptions.
+2. Use `deps` to declare dependencies between tasks (a task cannot be claimed until its dependencies are completed).
+3. Call `team_task` with `action: "claim"` to assign a task to yourself before starting work on it.
+4. Call `team_task` with `action: "complete"` and a `result` summary when the task is done.
+5. Call `team_task` with `action: "list"` to see overall progress and find available work.
+
+Rules:
+- Only claim tasks whose dependencies are all completed.
+- Only one agent may claim a given task.
+- If you cannot complete a claimed task, leave the team so the task returns to pending and another agent can pick it up.
+
+## RULE 4: Communication Protocol
+
+Use `team_message` with `action: "send"` for direct messages and `action: "broadcast"` for announcements. Message types and their intended use:
+
+| Type | Use |
+|------|-----|
+| `request` | Ask another agent to do something, release a lock, or provide information. |
+| `response` | Reply to a prior request. |
+| `info` | Share context: discoveries, status updates, warnings about tricky code. |
+| `announcement` | Broadcast to all agents: major state changes, deployment events, breaking changes. |
+| `contract` | Propose or agree on a division of work. Both agents should acknowledge. |
+| `error` | Report a blocking issue that requires another agent's attention. |
+
+Rules:
+- `action: "send"` requires the full UUID of the target agent. Get it from `team_manage` with `action: "status"`.
+- Check your inbox (`action: "inbox"`) at least once before starting new work and once before ending a session.
+- Keep message content under 10KB. Be concise and actionable.
+
+## RULE 5: Leave on Session End
+
+When the session is ending:
+
+1. Call `team_file_lock` with `action: "unlock"` for every file you have locked, or they will remain locked until TTL expiry (10 min).
+2. If you have in-progress tasks you cannot finish, leave them — leaving releases your tasks back to pending.
+3. Call `team_manage` with `action: "leave"` and your agent ID. This marks you inactive, releases all your locks, and clears your inbox.
+
+## RULE 6: Conflict Prevention
+
+- **Check before acting.** Always check team status and file lock status before starting work to understand the current state.
+- **Communicate before diverging.** If you plan to refactor shared code, broadcast an `announcement` first so other agents can save their work.
+- **Respect lock ownership.** The lock holder has exclusive write access. No exceptions.
+- **Prefer small, scoped changes.** Large cross-cutting changes increase conflict risk. Coordinate via tasks and messages if a change touches files other agents are working on.
+- **Do not duplicate work.** Check the task list before creating new tasks. If a similar task exists, claim it instead of creating a duplicate.
+
+## Summary of Required Calls
+
+| When | Tool Call |
+|------|-----------|
 | Session start | `memorix_session_start` (lightweight) |
 | Join Agent Team | `memorix_session_start(joinTeam=true)` or `team_manage(join)` |
 | After joining | `memorix_poll` (check status + inbox) |
-| Before editing a shared file | `team_file_lock(status)`, `team_file_lock(lock)` |
-| After editing | `team_file_lock(unlock)` |
-| Starting a unit of work | `team_task(claim)` or `team_task(create)` + `team_task(claim)` |
-| Finishing a unit of work | `team_task(complete)` |
-| Need to coordinate | `team_message(send)` or `team_message(broadcast)` |
-| Session end | `team_file_lock(unlock)` (all), `team_manage(leave)` |
+| Before editing a shared file | `team_file_lock(status)`, `team_file_lock(lock)` |
+| After editing | `team_file_lock(unlock)` |
+| Starting a unit of work | `team_task(claim)` or `team_task(create)` + `team_task(claim)` |
+| Finishing a unit of work | `team_task(complete)` |
+| Need to coordinate | `team_message(send)` or `team_message(broadcast)` |
+| Session end | `team_file_lock(unlock)` (all), `team_manage(leave)` |