memroot 0.1.0-alpha.1 → 0.1.0-alpha.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +26 -2
- package/dist/index.js +1929 -470
- package/dist/plugins/claude/.claude-plugin/plugin.json +2 -2
- package/dist/plugins/claude/README.md +8 -4
- package/dist/plugins/claude/hooks/hooks.json +10 -0
- package/dist/plugins/claude/scripts/capture-worker.mjs +19294 -0
- package/dist/plugins/claude/scripts/session-end.mjs +469 -0
- package/dist/plugins/claude/scripts/session-start.mjs +372 -53
- package/dist/plugins/claude/scripts/status.mjs +152 -12
- package/dist/plugins/claude/skills/memroot-memory/SKILL.md +48 -0
- package/dist/plugins/claude/skills/memroot-memory/references/save.md +76 -0
- package/dist/plugins/claude/skills/memroot-status/SKILL.md +19 -0
- package/dist/plugins/codex/.codex-plugin/plugin.json +4 -4
- package/dist/plugins/codex/README.md +13 -9
- package/dist/plugins/codex/hooks/hooks.json +11 -0
- package/dist/plugins/codex/scripts/capture-worker.mjs +19294 -0
- package/dist/plugins/codex/scripts/session-end.mjs +469 -0
- package/dist/plugins/codex/scripts/session-start.mjs +372 -53
- package/dist/plugins/codex/scripts/status.mjs +149 -9
- package/dist/plugins/codex/skills/memroot-memory/SKILL.md +48 -0
- package/dist/plugins/codex/skills/memroot-memory/references/save.md +76 -0
- package/dist/plugins/codex/skills/memroot-status/SKILL.md +20 -0
- package/dist/plugins/grok/.claude-plugin/plugin.json +2 -2
- package/dist/plugins/grok/README.md +10 -4
- package/dist/plugins/grok/hooks/hooks.json +24 -1
- package/dist/plugins/grok/scripts/capture-worker.mjs +19294 -0
- package/dist/plugins/grok/scripts/session-end.mjs +469 -0
- package/dist/plugins/grok/scripts/session-reminder.mjs +275 -0
- package/dist/plugins/grok/scripts/status.mjs +152 -12
- package/dist/plugins/grok/skills/memroot-memory/SKILL.md +48 -0
- package/dist/plugins/grok/skills/memroot-memory/references/save.md +76 -0
- package/dist/plugins/grok/skills/memroot-status/SKILL.md +20 -0
- package/package.json +6 -3
- package/dist/plugins/claude/skills/status/SKILL.md +0 -18
- package/dist/plugins/codex/skills/status/SKILL.md +0 -22
- package/dist/plugins/grok/skills/status/SKILL.md +0 -18
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
# Building a memory_create request
|
|
2
|
+
|
|
3
|
+
Save one memory per call, a few sentences at most, in your own words. Write the summary so it makes sense to a future reader without this conversation.
|
|
4
|
+
|
|
5
|
+
Use the template below for every kind of memory. Keep `"assertion_type": "descriptive"` with `"predicate": "has_property"` whatever the `memory.kind` is; the server requires that pair to match, and it does not follow the kind. Only `memory.kind`, `memory.title`, `memory.summary`, the assertion `statement`, the literal `value` and `qualifier`, the evidence `summary`, the date, and the two ids change. Other predicates (`requires`, `prefers`, `avoids`, `located_in`, ...) have entity role rules that are easy to get wrong, and some clients show only "Invalid or sensitive tool input" without the failing field, so stay with this form.
|
|
6
|
+
|
|
7
|
+
## Choosing `memory.kind`
|
|
8
|
+
|
|
9
|
+
| What the user wants remembered | kind |
|
|
10
|
+
|---|---|
|
|
11
|
+
| A design or technology choice and why | `architecture_decision` |
|
|
12
|
+
| Something that must always hold ("never call X without Y") | `invariant` |
|
|
13
|
+
| How the team does things (naming, layout, patterns) | `convention` |
|
|
14
|
+
| A known defect or gotcha that is still present | `bug` |
|
|
15
|
+
| Why a failure happens | `root_cause` |
|
|
16
|
+
| What resolved a failure | `fix` |
|
|
17
|
+
| Something that was tried and didn't work | `failed_approach` |
|
|
18
|
+
| A personal or team preference (tools, style) | `preference` |
|
|
19
|
+
| Where something important lives in the code | `code_landmark` |
|
|
20
|
+
| Who owns or maintains a component | `ownership_boundary` |
|
|
21
|
+
| Steps to do a recurring task (release, migration) | `procedure` |
|
|
22
|
+
|
|
23
|
+
## Template
|
|
24
|
+
|
|
25
|
+
Example for "Remember that the deploy fails if migrations run after wrangler deploy":
|
|
26
|
+
|
|
27
|
+
```json
|
|
28
|
+
{
|
|
29
|
+
"idempotency_key": "mr-20261002-deploy-order-7f3a9c2e",
|
|
30
|
+
"memory_request": {
|
|
31
|
+
"schema_version": 1,
|
|
32
|
+
"memory": {
|
|
33
|
+
"kind": "root_cause",
|
|
34
|
+
"title": "Deploy smoke check fails because migrations run after deploy",
|
|
35
|
+
"summary": "scripts/deploy.sh runs wrangler deploy before pnpm db:migrate, so new code briefly sees the old schema. Run migrations first.",
|
|
36
|
+
"valid_time": { "from": "2026-10-02T12:00:00Z", "to": null }
|
|
37
|
+
},
|
|
38
|
+
"entities": [],
|
|
39
|
+
"assertions": [
|
|
40
|
+
{
|
|
41
|
+
"ref": "a1",
|
|
42
|
+
"assertion_type": "descriptive",
|
|
43
|
+
"predicate": "has_property",
|
|
44
|
+
"statement": "Deploys fail intermittently because migrations run after wrangler deploy; running pnpm db:migrate first fixes it.",
|
|
45
|
+
"subject": { "context_entity": "project" },
|
|
46
|
+
"object": { "literal": { "type": "string", "value": "run pnpm db:migrate before wrangler deploy" }, "qualifier": "deploy_order" },
|
|
47
|
+
"confidence": 0.9,
|
|
48
|
+
"importance": 4,
|
|
49
|
+
"valid_time": { "from": "2026-10-02T12:00:00Z", "to": null },
|
|
50
|
+
"git_applicability": { "rule": "all_commits" },
|
|
51
|
+
"evidence_refs": ["e1"],
|
|
52
|
+
"provenance_refs": ["p1"]
|
|
53
|
+
}
|
|
54
|
+
],
|
|
55
|
+
"assertion_relations": [],
|
|
56
|
+
"memory_relations": [],
|
|
57
|
+
"evidence": [
|
|
58
|
+
{ "ref": "e1", "kind": "user_attestation", "locator_version": 1, "locator": {}, "summary": "User asked to remember this root cause." }
|
|
59
|
+
],
|
|
60
|
+
"provenance": [
|
|
61
|
+
{ "ref": "p1", "origin": "direct_api", "adapter": "claude_code", "source_id": "op-8a2d5f0c9e1b4a7d" }
|
|
62
|
+
]
|
|
63
|
+
}
|
|
64
|
+
}
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
Field notes:
|
|
68
|
+
|
|
69
|
+
- `project_id`: leave it out; the server uses the connection's one authorized project. If the call fails with `project_not_found`, or says `project_id` is required (an older server), get the id once from `projects_list`, add it as the top-level `"project_id"` and retry with the same `idempotency_key`.
|
|
70
|
+
- `idempotency_key`: any unique string of 16 to 128 printable characters that you compose yourself (date, short slug, a few random characters). No command is needed to generate it or the other values. Reuse the same key with the identical request if you retry.
|
|
71
|
+
- `valid_time.from` (in both places): the current UTC time, ending in `Z`.
|
|
72
|
+
- `qualifier`: lowercase snake_case, starting with a letter, such as `package_manager` or `deploy_order`. The literal `value` is a short string, at most 512 bytes.
|
|
73
|
+
- `evidence`: keep exactly one `user_attestation` item with an empty `locator`, and summarize what the user said. Don't add other evidence. If the user agreed to your offer, say so, for example "User agreed to save this root cause after the agent offered."
|
|
74
|
+
- `provenance.source_id`: an opaque id you make up (for example `op-` plus 16 hex digits); it is not a session, commit, or file id.
|
|
75
|
+
|
|
76
|
+
If the call fails with `project_not_found`, or says `project_id` is required, use the `project_id` fallback in the field notes first. If the call is rejected for any other reason, compare your request with the template field by field and retry once with the same `idempotency_key`. If it still fails, tell the user nothing was saved.
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: memroot-status
|
|
3
|
+
description: Checks whether Memroot is installed, connected, and capturing sessions, and which project it uses. Use when the user asks if Memroot is set up, signed in, connected or working, whether sessions or memories are being captured, or when Memroot tools are missing or failing. Not for looking up or saving memories.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Memroot status
|
|
7
|
+
|
|
8
|
+
Answer from live checks rather than assumptions, because an installed plugin doesn't prove the account is connected.
|
|
9
|
+
|
|
10
|
+
1. Run the bundled status script for the plugin version and capabilities, including whether session capture is enabled:
|
|
11
|
+
```sh
|
|
12
|
+
node "${CLAUDE_PLUGIN_ROOT}/scripts/status.mjs"
|
|
13
|
+
```
|
|
14
|
+
2. Call the memroot MCP server's `connection_status` tool for the account, authorized project, and retrieval mode. In Claude Code the memroot tools are `mcp__memroot__projects_list`, `mcp__memroot__memory_retrieve`, `mcp__memroot__memory_create` and `mcp__memroot__connection_status`; if they are deferred, load them with tool search first.
|
|
15
|
+
3. Report briefly: plugin version, connected or not, project id, retrieval mode, and whether session capture is on.
|
|
16
|
+
|
|
17
|
+
If the memroot tools aren't available or `connection_status` fails, say that Memroot isn't connected in this session and suggest `npx memroot setup --agent claude --yes`, then `npx memroot doctor` for diagnostics. A successful connection check doesn't prove a memory was saved; only a save followed by a retrieval in a fresh session does.
|
|
18
|
+
|
|
19
|
+
Don't read transcripts or credential files to answer, and don't invent endpoints.
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "memroot",
|
|
3
|
-
"version": "0.1.0-alpha.
|
|
4
|
-
"description": "Connect Memroot
|
|
3
|
+
"version": "0.1.0-alpha.3",
|
|
4
|
+
"description": "Connect Memroot, explicitly save or retrieve engineering knowledge, and optionally capture it after sessions end.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Memroot"
|
|
7
7
|
},
|
|
@@ -9,10 +9,10 @@
|
|
|
9
9
|
"interface": {
|
|
10
10
|
"displayName": "Memroot",
|
|
11
11
|
"shortDescription": "Connect Memroot and manage durable engineering knowledge.",
|
|
12
|
-
"longDescription": "Setup links native Codex MCP OAuth to Memroot. After authorization, explicitly save user-approved knowledge and retrieve structured memory packs.
|
|
12
|
+
"longDescription": "Setup links native Codex MCP OAuth to Memroot. After authorization, explicitly save user-approved knowledge and retrieve structured memory packs. Optional session capture (memroot capture on) runs a bundled background worker after a session ends: it redacts the transcript locally, runs Codex without tools to extract candidates, and uploads only typed memories labeled session-extracted. Trust the Memroot SessionStart and SessionEnd hooks once in /hooks.",
|
|
13
13
|
"developerName": "Memroot",
|
|
14
14
|
"category": "Productivity",
|
|
15
|
-
"capabilities": ["Read"],
|
|
15
|
+
"capabilities": ["Read", "Write"],
|
|
16
16
|
"defaultPrompt": ["Check my Memroot plugin status."]
|
|
17
17
|
}
|
|
18
18
|
}
|
|
@@ -1,18 +1,22 @@
|
|
|
1
1
|
# Memroot for Codex
|
|
2
2
|
|
|
3
|
-
This is the complete, self-contained Memroot plugin root, version `0.1.0-alpha.
|
|
3
|
+
This is the complete, self-contained Memroot plugin root, version `0.1.0-alpha.3`. The setup utility copies this folder into a durable installation before native registration. Node.js is the only runtime requirement. Every script in `scripts/` is generated from the Memroot CLI source and bundled with its dependencies; no script refers to `npx`, the npm cache or files outside this bundle.
|
|
4
4
|
|
|
5
|
-
The status skill and `node scripts/status.mjs` explain this release's capabilities. Setup registers the production remote MCP server with Codex and opens native OAuth sign-in when needed. The MCP tools provide explicit save and retrieval after authorization.
|
|
5
|
+
The memroot-status skill and `node scripts/status.mjs` explain this release's capabilities. Setup registers the production remote MCP server with Codex and opens native OAuth sign-in when needed. The MCP tools provide explicit save and retrieval after authorization.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
Hooks only read the stdin envelope (at most 64 KiB, waiting at most 500 ms) and never echo event fields. They print nothing on SessionEnd, never open a transcript and make no network request. When the user has opted in with `memroot capture on`, the SessionEnd hook writes one small job file (identifiers and paths only; 0600 under `$XDG_STATE_HOME/memroot/capture`) and starts the bundled `scripts/capture-worker.mjs` fully detached, resolved next to the hook script itself. Without consent it does nothing.
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
The bundled worker reads only the referenced session transcript, keeps user and assistant text plus tool names and file paths (never tool output), redacts secrets, personal email addresses and home paths locally and fails closed, runs your own agent CLI headless with no tools to propose memories, validates them, and sends only typed memories labeled session-extracted (not user-attested) to `https://api.memroot.dev/mcp` with the separate Memroot CLI capture connection. Each memory includes up to 3 short evidence quotes (at most 200 characters) from the redacted transcript, repo-relative paths and symbols, the normalized repository remote, and salted hashes of the session id and quoted segments; one retrieval query per session contains only the repository name. Raw transcripts are never uploaded. At most 3 memories per session and 10 per 24 hours. `memroot capture off` stops capture and deletes queued work.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
The SessionStart hook supplies a short static context about memory retrieval (timeout 3 s). The SessionEnd hook has Codex's maximum 3 s timeout and typically returns in about 25 ms.
|
|
12
12
|
|
|
13
|
-
-
|
|
14
|
-
|
|
13
|
+
After installation, review and trust both hooks through `/hooks` in Codex. Plugin installation does not establish hook trust, and Codex skips untrusted hooks. Trust is pinned per hook definition; `hooks/hooks.json` is kept byte-stable across releases (the SessionStart entry is unchanged from `0.1.0-alpha.1`) so upgrades do not require re-trusting. The compatibility manifest relies on default `hooks/hooks.json` discovery; hook commands use `PLUGIN_ROOT`.
|
|
14
|
+
|
|
15
|
+
Setup owns the single user-scope `memroot` MCP registration; this plugin intentionally declares no second MCP server.
|
|
15
16
|
|
|
16
|
-
|
|
17
|
+
Inspect the installed plugin through the agent's native plugin interface.
|
|
17
18
|
|
|
18
|
-
|
|
19
|
+
Official references verified October 2, 2026:
|
|
20
|
+
|
|
21
|
+
- [OpenAI plugin packaging](https://developers.openai.com/plugins/build/plugins)
|
|
22
|
+
- [OpenAI hook contracts and trust](https://learn.chatgpt.com/docs/hooks)
|