memorix 1.1.10 → 1.1.12

package/CHANGELOG.md

@@ -2,6 +2,44 @@
 
 All notable changes to this project will be documented in this file.
 
+## [Unreleased]
+
+## [1.1.12] - 2026-07-17
+
+### Added
+- **Codex lifecycle hook capture** -- The Memorix Codex plugin now bundles the documented `SessionStart`, `UserPromptSubmit`, `PostToolUse`, `PreCompact`, and `Stop` hook events, with a Windows-safe `commandWindows` command override.
+
+### Fixed
+- **Codex hook normalization and injection** -- Codex lifecycle payloads now preserve their event names, `SessionStart` returns Codex-native `hookSpecificOutput.additionalContext`, and capture-only events stay quiet instead of filling the agent context with save-status messages.
+- **OpenCode hooks on Windows** -- The generated plugin resolves the installed npm `memorix.cmd` shim while setup runs and uses that stable path inside OpenCode, instead of relying on OpenCode's inherited `PATH`. Hook delivery stays quiet unless `MEMORIX_HOOK_DEBUG=1` is explicitly set. Fixes #125.
+- **Setup scope isolation** -- Project-level setup no longer installs Claude, Codex, or Copilot plugin bundles in the user home. Use `--global` for user-level plugins, skills, and lifecycle hooks.
+- **TUI embedding startup** -- TUI health, chat, and quick-search paths now use the same lexical-ready startup flow as MCP instead of making a remote dimension probe during the first screen or search.
+- **Semantic recall after restart** -- API-backed embeddings now restore compatible vectors from the local cache during index hydration, without placing remote embedding calls on the MCP startup path. Redundant namespace-scoped cache metadata survives a lost dimensions cache; cache misses enter the existing bounded background recovery lane, and the first successful vector upgrades a cache-less lexical index in the same process. Based on the diagnosis in #126 by @Tom-Ma-Ming.
+- **Concurrent index startup** -- Cache-only startup and ordinary database callers now share one Orama initialization, so a later vector-schema attempt cannot replace an already hydrated lexical index. Resets also discard obsolete in-flight instances.
+- **Lazy API vector-cache I/O** -- A cache-only start with no trusted dimension metadata now skips parsing the potentially large API vector cache entirely; the cache is loaded only after compatible local metadata or a normal embedding initialization establishes its dimensions.
+
+## [1.1.11] - 2026-07-16
+
+### Added
+- **Durable runtime maintenance** -- Added a SQLite-backed maintenance ledger for vector recovery, retention, consolidation, and Code Memory refresh. Jobs use dedupe keys, leases, heartbeats, retry backoff, resumable cursors, and operator-visible state.
+- **Isolated maintenance runner** -- Retention, consolidation, and Code Memory scans now run through a compiled child-process runner instead of sharing an MCP request/event loop. Vector recovery stays with the owning process because its Orama index is process-local.
+- **Code Memory scan safeguards** -- CodeGraph Lite now skips common dependency/build directories and source files larger than 2 MiB by default. Configure the limit with `[codegraph].max_file_bytes` or YAML `codegraph.maxFileBytes`.
+- **Maintenance diagnostics** -- Dashboard APIs and System Status now show queued/running/failed maintenance state without mixing projects.
+
+### Changed
+- **First-turn MCP readiness** -- `memorix_project_context`, `memorix_context_pack`, `memorix_graph_context`, and `memorix_codegraph_status` now read the current project's SQLite state directly before full Orama hydration. Search, writes, and sessions retain their full-runtime boundary.
+- **Bounded memory lifecycle** -- Automatic retention and consolidation process one project page at a time and resume through durable cursors, avoiding corpus-sized work in an interactive request.
+- **Incremental Code Memory** -- Changed files are reparsed, unchanged files keep their metadata, and removed/oversized files are removed from the graph without replacing the entire project graph.
+- **Mobile dashboard navigation** -- The desktop sidebar becomes a compact mobile navigation layout so dashboard content remains readable on narrow screens.
+
+### Fixed
+- **Cross-process refresh model** -- Removed the obsolete JSON-file polling watcher. SQLite generation checks are now the sole authoritative mechanism for cross-process observation freshness.
+- **Maintenance history and diagnostics** -- Completed maintenance records expire after a retention window; persisted failure messages redact credential values.
+- **Maintenance enqueue atomicity** -- History pruning now runs inside the enqueue transaction, so a failed enqueue cannot discard completed diagnostic history.
+- **Dashboard project scope** -- Knowledge, graph, retention, observation, and export reads use project-scoped SQLite queries instead of loading and filtering the full flat memory store.
+- **Behavior configuration alignment** -- TOML/YAML memory behavior settings now drive runtime injection, formation, auto-cleanup, and sync advisory behavior; legacy `config.json` is a fallback rather than a separate source of truth.
+- **Container runtime privilege** -- The official HTTP control-plane image is explicitly verified to run as the non-root `node` user.
+
 ## [1.1.10] - 2026-07-13
 
 ### Fixed

package/README.md

@@ -245,7 +245,7 @@ memorix setup --agent omp --global
 What it installs depends on the target agent, but the goal is the same: make Memorix available wherever you open that agent without asking you to wire every repo by hand.
 
 - Claude Code: installs the Memorix plugin package, adds `CLAUDE.md` guidance, and enables hook capture when you do not pass `--noHooks`.
-- Codex: installs the Memorix plugin package, adds `AGENTS.md` guidance, and enables hook capture when you do not pass `--noHooks`.
+- Codex: installs the Memorix plugin package with stdio MCP, skills, and lifecycle hooks, then adds `AGENTS.md` guidance. When Codex asks, review the plugin hook definition once with `/hooks`; `--noHooks` skips automatic capture.
 - GitHub Copilot CLI: installs the Copilot plugin package and official Memorix skills.
 - Pi: installs the user-level Pi package and official skills.
 - Cursor: writes Cursor MCP/rules/config entries in the chosen scope.

package/README.zh-CN.md

@@ -245,7 +245,7 @@ memorix setup --agent omp --global
 它会做的事情取决于目标 Agent，但目标是一致的：你以后在哪里打开这个 Agent，Memorix 就可以在哪里被使用，而不是让你一个仓库一个仓库重复配置。
 
 - Claude Code：安装 Memorix 插件包，写入 `CLAUDE.md` 使用规范；不加 `--noHooks` 时会启用自动捕获。
-- Codex：安装 Memorix 插件包，写入 `AGENTS.md` 使用规范；不加 `--noHooks` 时会启用自动捕获。
+- Codex：安装包含 stdio MCP、skills 和生命周期 hooks 的 Memorix 插件包，并写入 `AGENTS.md` 使用规范。Codex 首次要求时，在 `/hooks` 中审核一次插件 hook；使用 `--noHooks` 可跳过自动捕获。
 - GitHub Copilot CLI：安装 Copilot 插件包和官方 Memorix skills。
 - Pi：安装用户级 Pi package 和官方 skills。
 - Cursor：写入 Cursor 的 MCP / rules / 配置。

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)` |