@clawmem-ai/clawmem 0.1.9 → 0.1.11

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.
@@ -0,0 +1,223 @@
1
+ # ClawMem Collaboration
2
+
3
+ Use this reference when memory should live in a shared repo instead of one agent's private default repo, or when multiple agents or teammates need to read and write the same memory space. Use it for both `collaboration` and `collabration` requests.
4
+
5
+ ## Contents
6
+
7
+ - When to use
8
+ - Default operating style
9
+ - Repo routing and shared spaces
10
+ - Collaboration model
11
+ - Choose the right mechanism
12
+ - Pre-mutation checklist
13
+ - Prompt-to-tool mapping
14
+ - Team memory quality bar
15
+ - Collaboration rule of thumb
16
+ - Manual org-owned shared repo creation
17
+ - Fallback mode
18
+
19
+ ## When to use
20
+
21
+ Use this reference when the user asks to:
22
+
23
+ - create or manage an organization
24
+ - invite someone into an organization
25
+ - inspect, accept, or decline an invitation sent to the current user
26
+ - create or manage a team
27
+ - add or remove a repository collaborator
28
+ - grant a team access to a repo
29
+ - inspect outside collaborators
30
+ - create a shared team memory repo or org-owned memory space
31
+ - debug why a user can or cannot access a repo
32
+
33
+ Do not use this workflow for ordinary memory recall or save actions unless the user is specifically asking to change who can access a memory repo.
34
+
35
+ ## Default operating style
36
+
37
+ - Prefer the built-in ClawMem collaboration tools first.
38
+ - Inspect current state before mutating anything.
39
+ - Set `confirmed=true` only after the user has approved the exact org, team, repo, invitation, or permission change.
40
+ - Fall back to `gh api` or `curl` only when plugin tools are unavailable, when debugging backend behavior directly, or when you must create an org-owned repo because the plugin does not expose an org-repo creation tool yet.
41
+ - Reuse the main `clawmem` skill's route-resolution helper when raw shell access is required.
42
+ - Think in canonical runtime permissions: `read`, `write`, `admin`.
43
+ - Treat GitHub-compatible aliases such as `pull`, `triage`, `push`, and `maintain` as transport compatibility only.
44
+
45
+ Tool-first rule:
46
+ - Read-only inspection:
47
+ - `collaboration_orgs`
48
+ - `collaboration_teams`
49
+ - `collaboration_team_repos`
50
+ - `collaboration_repo_collaborators`
51
+ - `collaboration_repo_invitations`
52
+ - `collaboration_user_repo_invitations`
53
+ - `collaboration_org_invitations`
54
+ - `collaboration_user_org_invitations`
55
+ - `collaboration_outside_collaborators`
56
+ - `collaboration_repo_access_inspect`
57
+ - Mutations:
58
+ - `collaboration_org_create`
59
+ - `collaboration_team_create`
60
+ - `collaboration_team_membership_set`
61
+ - `collaboration_team_membership_remove`
62
+ - `collaboration_team_repo_set`
63
+ - `collaboration_team_repo_remove`
64
+ - `collaboration_repo_collaborator_set`
65
+ - `collaboration_repo_collaborator_remove`
66
+ - `collaboration_user_repo_invitation_accept`
67
+ - `collaboration_user_repo_invitation_decline`
68
+ - `collaboration_org_invitation_create`
69
+ - `collaboration_user_org_invitation_accept`
70
+ - `collaboration_user_org_invitation_decline`
71
+
72
+ ## Repo routing and shared spaces
73
+
74
+ Before explicit memory operations, choose the right repo:
75
+ - Private personal memory: usually the current agent's `defaultRepo`
76
+ - Project memory: the relevant project repo
77
+ - Shared or team knowledge: the shared repo for that team or project
78
+ - Unclear: inspect `memory_repos`, then choose deliberately
79
+
80
+ Do not treat `defaultRepo` as the only space. It is only the fallback.
81
+
82
+ Default tool path:
83
+ - Use `memory_repos` to inspect accessible spaces
84
+ - Use `memory_repo_create` when a new repo should be owned by the current agent identity
85
+ - Create an org-owned repo with raw `gh api` or `curl` when the memory space must be governed by an organization team
86
+ - Pass `repo` explicitly to `memory_recall`, `memory_list`, `memory_get`, `memory_store`, `memory_update`, and `memory_forget` when the target is not the current `defaultRepo`
87
+
88
+ This keeps private memory, project memory, and shared memory separate without forcing extra plugin configuration changes.
89
+
90
+ ## Collaboration model
91
+
92
+ Reason with these rules before every collaboration action:
93
+
94
+ - An organization is an explicit governance boundary.
95
+ - Org membership is explicit and separate from team membership.
96
+ - Teams are org-scoped authorization groups, not social groups.
97
+ - Effective repo access is `max(org base permission, direct collaborator grant, team grant)` after owner or admin shortcuts.
98
+ - Runtime permissions are only `none`, `read`, `write`, and `admin`.
99
+ - `memory_repos` only shows repos that are already accessible now; it does not prove there are no pending invitations.
100
+ - A repo collaborator grant may create a pending repository invitation instead of immediate access when the target user is not already a collaborator.
101
+ - Accepting a repository invitation is what turns a pending share into visible repo access for the invitee.
102
+ - Outside collaborators are non-members who still have direct collaborator access to at least one org-owned repo.
103
+ - Accepting an org invitation creates org membership, joins invited teams as `member`, and removes the pending invitation.
104
+ - If a user becomes an org member, any outside-collaborator row for that org should disappear.
105
+ - The system-managed `admins` team is an implementation mechanism, not a user-facing product primitive.
106
+
107
+ ## Choose the right mechanism
108
+
109
+ Use this decision map:
110
+
111
+ | Goal | Use |
112
+ |---|---|
113
+ | Give one user access to one repo without org membership | Direct collaborator |
114
+ | Bring one user into the org | Org invitation |
115
+ | Grant a group access to selected repos | Team + team-repo grant |
116
+ | Create a shared team memory space | Org-owned repo + team-repo grant |
117
+ | Create another memory space under the current agent identity | `memory_repo_create` |
118
+ | Inspect non-members who still have repo access | Outside collaborator listing |
119
+
120
+ Hard rules:
121
+ - Never assume team membership creates org membership.
122
+ - Never use team membership as a side-door org bootstrap.
123
+ - Never assume a repo share should become org membership; choose intentionally.
124
+ - If the task is org-scoped, ensure the org already exists or create it explicitly first.
125
+
126
+ ## Pre-mutation checklist
127
+
128
+ Before any write action:
129
+
130
+ 1. Identify the acting identity, target org, target repo, target user, target team, and desired permission.
131
+ 2. Normalize the user's requested permission mentally to `read`, `write`, or `admin` before reasoning.
132
+ 3. Inspect current state first when the request is ambiguous.
133
+ 4. If the action changes governance, permissions, membership, or invitations, require explicit user intent or confirmation.
134
+ 5. Never paste raw tokens into chat or files.
135
+
136
+ Read-only checks can run without confirmation.
137
+
138
+ ## Prompt-to-tool mapping
139
+
140
+ Translate user intent like this:
141
+
142
+ - `Create a shared memory repo for team X`
143
+ - inspect or create the org and team first
144
+ - if the repo should be team-governed, create an org-owned repo with raw `gh api` or `curl`; `memory_repo_create` only creates repos under the current agent identity
145
+ - grant the team access with `collaboration_team_repo_set`
146
+ - `Give Alice access to this one memory repo`
147
+ - inspect direct collaborators first with `collaboration_repo_collaborators`
148
+ - then use `collaboration_repo_collaborator_set`
149
+ - if the user was not already a collaborator, expect a pending repo invitation and verify with `collaboration_repo_invitations`
150
+ - `Bring Alice into the org and platform team`
151
+ - inspect teams first with `collaboration_teams`
152
+ - then use `collaboration_org_invitation_create`
153
+ - `Someone shared a memory repo with me; can you see it and accept it?`
154
+ - start with `collaboration_user_repo_invitations`
155
+ - do not treat a `memory_repos` miss as proof that no share exists
156
+ - if the correct pending invite is visible and the user asked to accept it, use `collaboration_user_repo_invitation_accept`
157
+ - `I still cannot see the shared memory repo`
158
+ - inspect `collaboration_user_repo_invitations` first
159
+ - if needed, have the repo owner inspect `collaboration_repo_invitations`
160
+ - `Why can Bob still see this repo?`
161
+ - start with `collaboration_repo_access_inspect`
162
+ - then drill into `collaboration_repo_collaborators`, `collaboration_repo_invitations`, `collaboration_team_repos`, `collaboration_outside_collaborators`, and `collaboration_org_invitations` as needed
163
+ - `Remove Carol from org-shared memory access`
164
+ - identify whether access comes from a direct collaborator grant, a team repo grant, or a pending invitation
165
+ - remove the actual source of access rather than guessing
166
+
167
+ ## Team memory quality bar
168
+
169
+ - Private memories can start rough and become cleaner over time
170
+ - Shared memories should be conclusions, not speculation
171
+ - When access is governed by teams or org policy, prefer org-owned repos over one user's private space
172
+ - Use stable `kind:*` and `topic:*` labels so different agents can retrieve the same schema
173
+ - Prefer updating a canonical shared fact in place instead of creating competing duplicates
174
+
175
+ ## Collaboration rule of thumb
176
+
177
+ If knowledge should stay personal, keep it in the agent's default repo. If it should shape multiple agents or people, put it in a shared repo and target that repo explicitly on retrieval and save.
178
+
179
+ ## Manual org-owned shared repo creation
180
+
181
+ Use the plugin tool path first. If the memory space must be org-governed, create an org-owned repo directly because `memory_repo_create` only creates repos under the current agent identity.
182
+
183
+ ### With `gh api`
184
+
185
+ ```sh
186
+ GH_HOST="$CLAWMEM_HOST" GH_ENTERPRISE_TOKEN="$CLAWMEM_TOKEN" \
187
+ gh api -X POST "/orgs/<org>/repos" \
188
+ -f name='team-memory' \
189
+ -F private=true \
190
+ -F has_issues=true
191
+ ```
192
+
193
+ ### With `curl`
194
+
195
+ ```sh
196
+ curl -sf -X POST "$CLAWMEM_BASE_URL/orgs/<org>/repos" \
197
+ -H "Authorization: token $CLAWMEM_TOKEN" \
198
+ -H "Content-Type: application/json" \
199
+ -d '{"name": "team-memory", "private": true, "has_issues": true}'
200
+ ```
201
+
202
+ After the repo exists:
203
+ - grant the team access with `collaboration_team_repo_set`
204
+ - use the main memory tools with explicit `repo` targeting for read and write flows
205
+ - reuse [manual-ops.md](manual-ops.md) only if you need raw memory issue control after the repo already exists
206
+
207
+ ## Fallback mode
208
+
209
+ If the collaboration tools are unavailable, use `gh api` against the ClawMem host; fall back to `curl` only when `gh` is unavailable or broken.
210
+
211
+ Command pattern:
212
+
213
+ ```sh
214
+ GH_HOST="$CLAWMEM_HOST" GH_ENTERPRISE_TOKEN="$CLAWMEM_TOKEN" \
215
+ gh api "/user"
216
+ ```
217
+
218
+ If `gh` cannot be used:
219
+
220
+ ```sh
221
+ curl -sf -H "Authorization: token $CLAWMEM_TOKEN" \
222
+ "$CLAWMEM_BASE_URL/user"
223
+ ```
@@ -0,0 +1,82 @@
1
+ # ClawMem Communication And First-Run Messaging
2
+
3
+ Use this reference when you need user-facing copy after setup succeeds, need a short first-run message, want to generate a memory console link, or want stronger post-save communication after memory operations.
4
+
5
+ ## Contents
6
+
7
+ - Keep the user posted
8
+ - Restart notice protocol
9
+ - First-run message
10
+ - Memory visualization console
11
+
12
+ ## Keep the user posted
13
+
14
+ Nothing interesting should happen silently. If memory shaped the answer or changed after the turn, tell the user what happened.
15
+
16
+ Preferred retrieval transparency:
17
+ - `Memory hit #<id>: <title>`
18
+
19
+ Use a miss note only when the user would reasonably expect that you checked:
20
+ - `Memory miss: no prior decision found on staging cutover`
21
+
22
+ Preferred confirmation:
23
+ - `Locked memory #<id>: <title>`
24
+
25
+ Friendlier variants are fine as long as they stay truthful and short.
26
+
27
+ Examples:
28
+ - `Memory hit #14: Team demo moved to Wednesday`
29
+ - `Locked memory #10: API rate limiting uses a sliding window policy`
30
+ - `Locked memory #27: Client meeting is Thursday at 2pm`
31
+
32
+ ## Restart notice protocol
33
+
34
+ If setup requires an OpenClaw gateway restart and that restart may interrupt outgoing replies, send a short notice before restarting.
35
+
36
+ Suggested notice:
37
+
38
+ > ClawMem is installed and selected as the active memory plugin. Restarting the OpenClaw gateway to load it now.
39
+ > If the connection drops for a moment, say hi again and I will continue from there.
40
+
41
+ ## First-run message
42
+
43
+ After restart completes and verification passes, use a short onboarding note. Keep it high-signal and avoid dumping the full skill into chat.
44
+
45
+ Suggested structure:
46
+ - ClawMem is active and now persists durable memories across sessions.
47
+ - The agent will proactively recall relevant preferences, decisions, lessons, and active tasks.
48
+ - The agent will tell the user when it locks a memory.
49
+ - The agent can evolve its schema over time by adding reusable kinds or topics when the current schema is not expressive enough.
50
+ - The user can inspect the memory graph in the console link below.
51
+
52
+ Optional fuller note:
53
+
54
+ > ClawMem is active. I now carry durable memories across sessions instead of starting from zero each time.
55
+ > I will proactively recall relevant preferences, decisions, lessons, workflows, and active tasks when they can help.
56
+ > When I learn something reusable, I can lock it in immediately and evolve the schema deliberately so future retrieval gets better.
57
+ > When I save something important, I will tell you. You can inspect the memory graph in the console link below.
58
+
59
+ ## Memory visualization console
60
+
61
+ The ClawMem Console provides an interactive graph view of memory nodes, labels, and links.
62
+
63
+ ### Generate a console login URL
64
+
65
+ Construct the URL from the current agent token:
66
+
67
+ ```text
68
+ https://console.clawmem.ai/login.html?token={CLAWMEM_TOKEN}
69
+ ```
70
+
71
+ Read `CLAWMEM_TOKEN` from the current route, substitute it into the URL, and show the full untruncated URL directly to the authenticated user.
72
+
73
+ ### When to show the console link
74
+
75
+ - During onboarding after a successful install
76
+ - When the user asks to view memories, the graph, or a dashboard
77
+ - After significant memory operations, such as bulk saves
78
+ - When a visual overview would clearly help the user
79
+
80
+ ### Security
81
+
82
+ The console login URL contains the agent token. Never store it in memory nodes, files, logs, or commits. Only show it directly to the authenticated user.
@@ -0,0 +1,205 @@
1
+ # ClawMem Manual Operations And Troubleshooting
2
+
3
+ Use this reference only when:
4
+ - the user explicitly wants raw GitHub-style repo or issue operations
5
+ - you are debugging backend state or labels
6
+ - the plugin memory tools are unavailable
7
+
8
+ ClawMem runs on a GitHub-compatible backend, so repo, issue, label, invitation, and team operations follow GitHub-shaped APIs. That is why `gh` and `curl` are valid fallback tools here.
9
+
10
+ ## Contents
11
+
12
+ - Route resolution
13
+ - Preflight
14
+ - Save a memory manually
15
+ - Search memories manually
16
+ - Mark memory as stale manually
17
+ - Link related memories manually
18
+ - `git push` to ClawMem
19
+ - Known pitfalls
20
+ - Autonomy
21
+
22
+ If the plugin tools are available, prefer:
23
+ - `memory_repos` to inspect available repos
24
+ - `memory_list` to inspect the current active-memory index
25
+ - `memory_get` to verify one exact memory
26
+ - `memory_labels` to inspect current schema
27
+ - `memory_repo_create` to create a new memory repo
28
+ - `memory_store` to save
29
+ - `memory_update` to evolve one canonical memory in place
30
+ - `memory_recall` to search
31
+ - `memory_forget` to retire stale memories
32
+
33
+ ## Route resolution
34
+
35
+ ClawMem is routed per agent identity, not through one global repo or token.
36
+
37
+ Resolve the current route with the bundled helper:
38
+
39
+ ```sh
40
+ eval "$(python3 scripts/clawmem_exports.py)"
41
+ ```
42
+
43
+ That exports:
44
+ - `CLAWMEM_AGENT_ID`
45
+ - `CLAWMEM_BASE_URL`
46
+ - `CLAWMEM_HOST`
47
+ - `CLAWMEM_DEFAULT_REPO`
48
+ - `CLAWMEM_REPO`
49
+ - `CLAWMEM_TOKEN`
50
+
51
+ Rules:
52
+ - Never store tokens in files or chat
53
+ - `CLAWMEM_DEFAULT_REPO` is the fallback memory space for automatic flows
54
+ - `CLAWMEM_REPO` is the repo chosen for the current operation
55
+ - If `CLAWMEM_TOKEN` is empty, this agent identity has not been provisioned yet
56
+
57
+ ## Preflight
58
+
59
+ ```sh
60
+ eval "$(python3 scripts/clawmem_exports.py)"
61
+
62
+ test -n "$CLAWMEM_REPO" || { echo "ClawMem repo missing for agent $CLAWMEM_AGENT_ID"; exit 1; }
63
+ test -n "$CLAWMEM_TOKEN" || { echo "ClawMem token missing for agent $CLAWMEM_AGENT_ID"; exit 1; }
64
+ case "$CLAWMEM_REPO" in
65
+ */*) ;;
66
+ *) echo "Invalid CLAWMEM_REPO='$CLAWMEM_REPO' (expected owner/repo)"; exit 1 ;;
67
+ esac
68
+ ```
69
+
70
+ For ClawMem, always pass `--repo "$CLAWMEM_REPO"` to `gh` or use `$CLAWMEM_BASE_URL/repos/$CLAWMEM_REPO/...` with `curl` explicitly.
71
+
72
+ Do not export `GH_HOST` or `GH_ENTERPRISE_TOKEN` globally for unrelated github.com work. Use per-command env prefixes if you need isolation.
73
+
74
+ ## Save a memory manually
75
+
76
+ Use the tool path first. If raw issue control is required:
77
+
78
+ ### With `gh`
79
+
80
+ ```sh
81
+ for lbl in "type:memory" "kind:core-fact" "kind:convention" "kind:lesson" "kind:skill" "kind:task"; do
82
+ GH_HOST="$CLAWMEM_HOST" GH_ENTERPRISE_TOKEN="$CLAWMEM_TOKEN" \
83
+ gh label create "$lbl" --repo "$CLAWMEM_REPO" --color "5319e7" 2>/dev/null || true
84
+ done
85
+
86
+ GH_HOST="$CLAWMEM_HOST" GH_ENTERPRISE_TOKEN="$CLAWMEM_TOKEN" \
87
+ gh issue create --repo "$CLAWMEM_REPO" \
88
+ --title "Memory: <concise title>" \
89
+ --body "<durable detail in plain language>" \
90
+ --label "type:memory" \
91
+ --label "kind:lesson"
92
+ ```
93
+
94
+ ### With `curl`
95
+
96
+ ```sh
97
+ for lbl in "type:memory" "kind:core-fact" "kind:convention" "kind:lesson" "kind:skill" "kind:task"; do
98
+ curl -sf -X POST -H "Authorization: token $CLAWMEM_TOKEN" \
99
+ -H "Content-Type: application/json" \
100
+ "$CLAWMEM_BASE_URL/repos/$CLAWMEM_REPO/labels" \
101
+ -d "{\"name\":\"$lbl\",\"color\":\"5319e7\"}" >/dev/null 2>&1 || true
102
+ done
103
+
104
+ curl -sf -X POST -H "Authorization: token $CLAWMEM_TOKEN" \
105
+ -H "Content-Type: application/json" \
106
+ "$CLAWMEM_BASE_URL/repos/$CLAWMEM_REPO/issues" \
107
+ -d "{
108
+ \"title\": \"Memory: <concise title>\",
109
+ \"body\": \"<durable detail in plain language>\",
110
+ \"labels\": [\"type:memory\", \"kind:lesson\"]
111
+ }" | jq '{number, title, url: .html_url}'
112
+ ```
113
+
114
+ ## Search memories manually
115
+
116
+ ### With `gh`
117
+
118
+ ```sh
119
+ GH_HOST="$CLAWMEM_HOST" GH_ENTERPRISE_TOKEN="$CLAWMEM_TOKEN" \
120
+ gh issue list --repo "$CLAWMEM_REPO" \
121
+ --state open \
122
+ --label "type:memory" \
123
+ --search "<keywords>" \
124
+ --limit 100 \
125
+ --json number,title,body,labels,updatedAt
126
+ ```
127
+
128
+ ### With `curl`
129
+
130
+ ```sh
131
+ curl -sf -H "Authorization: token $CLAWMEM_TOKEN" \
132
+ "$CLAWMEM_BASE_URL/repos/$CLAWMEM_REPO/issues?state=open&labels=type:memory&per_page=100&type=issues" | \
133
+ jq --arg q "<keywords>" '
134
+ ($q | ascii_downcase) as $needle
135
+ | map(select(
136
+ ((.title // "") + "\n" + (.body // "")) | ascii_downcase | contains($needle)
137
+ ))
138
+ | map({number, title, body, labels: [.labels[]?.name], updatedAt: .updated_at})
139
+ '
140
+ ```
141
+
142
+ ## Mark memory as stale manually
143
+
144
+ If this is still the same canonical fact or task, prefer `memory_update` instead of retiring the old node.
145
+
146
+ ### With `gh`
147
+
148
+ ```sh
149
+ GH_HOST="$CLAWMEM_HOST" GH_ENTERPRISE_TOKEN="$CLAWMEM_TOKEN" \
150
+ gh issue close <number> --repo "$CLAWMEM_REPO"
151
+ ```
152
+
153
+ ### With `curl`
154
+
155
+ ```sh
156
+ curl -sf -X PATCH -H "Authorization: token $CLAWMEM_TOKEN" \
157
+ -H "Content-Type: application/json" \
158
+ "$CLAWMEM_BASE_URL/repos/$CLAWMEM_REPO/issues/<number>" \
159
+ -d '{"state": "closed"}'
160
+ ```
161
+
162
+ If a new memory replaces an old one, save the new memory first and mention the old `#ID` in the replacement body so the supersession is explicit.
163
+
164
+ ## Link related memories manually
165
+
166
+ When one memory depends on, refines, or supersedes another, mention `#<id>` in the body so the graph keeps an explicit edge.
167
+
168
+ Prefer doing this when you create a curated raw memory, or when you are already rewriting the full issue body intentionally.
169
+
170
+ If you patch an existing plugin-managed memory body by hand, preserve the existing structured body and add the `#<id>` relation into the durable detail instead of overwriting metadata fields blindly.
171
+
172
+ ## `git push` to ClawMem
173
+
174
+ `GH_HOST` and `GH_ENTERPRISE_TOKEN` affect `gh`, not `git push`. If you need to push code to a ClawMem git service repo:
175
+
176
+ ```sh
177
+ echo "$CLAWMEM_TOKEN" | gh auth login -h "$CLAWMEM_HOST" --with-token
178
+ ```
179
+
180
+ After that, `git push` to `https://git.clawmem.ai/...` works normally.
181
+
182
+ ## Known pitfalls
183
+
184
+ | Problem | Fix |
185
+ |---|---|
186
+ | Labels do not update reliably via `PATCH` on some backends | Use `PUT /repos/{owner}/{repo}/issues/{n}/labels` when you need exact label replacement |
187
+ | `openclaw config get` returns redacted token values | Read the config file path via `openclaw config file`, then inspect the JSON directly |
188
+ | Conversation mirror returns `404` | The cached conversation issue was deleted; the plugin recreates it on the next session |
189
+ | New session gets `401 Unauthorized` | Re-read the current agent route. If this is first use, trigger one real turn so the plugin can finish provisioning |
190
+ | Agent uses the wrong memory repo | Resolve `config.agents.<agentId>` for the current agent; do not read only top-level legacy repo settings |
191
+ | `gh` is not the official GitHub CLI | Run `gh --version`; if it is the npm `gh` package instead of the official CLI, use `curl` or replace the CLI install |
192
+
193
+ ## Autonomy
194
+
195
+ Without confirmation:
196
+ - creating or updating memory nodes
197
+ - adding comments
198
+ - reusing or creating labels
199
+ - closing stale memory nodes
200
+ - creating new memory repos when a new space is clearly needed
201
+
202
+ Requires confirmation:
203
+ - OpenClaw config changes
204
+ - service restarts
205
+ - deletions that go beyond ordinary memory retirement
@@ -0,0 +1,127 @@
1
+ # ClawMem Repair And Verification
2
+
3
+ Use this reference when ClawMem is already installed but is not selected as the active memory plugin, is missing per-agent provisioning, has a broken route, or needs verification after setup.
4
+
5
+ The website bootstrap `SKILL.md` is the primary setup guide. This reference is for post-install repair, diagnostics, and compatibility-file reminders.
6
+
7
+ ## Contents
8
+
9
+ - Verify activation and provisioning
10
+ - Verify read access without manual login
11
+ - Verify the plugin tool path
12
+ - Compatibility mode for SOUL.md, AGENTS.md, and TOOLS.md
13
+ - Definition of done
14
+ - If ClawMem is still broken
15
+
16
+ ## Step 1: Verify activation and provisioning
17
+
18
+ First verify that ClawMem is the active memory plugin.
19
+
20
+ ```sh
21
+ openclaw status
22
+ python3 - <<'PY'
23
+ import json, os, subprocess
24
+ cfg_path = subprocess.check_output(["openclaw", "config", "file"], text=True).strip()
25
+ with open(os.path.expanduser(cfg_path)) as f:
26
+ root = json.load(f)
27
+ slots = (root.get("plugins") or {}).get("slots") or {}
28
+ print(f"plugins.slots.memory = {slots.get('memory', 'MISSING')}")
29
+ PY
30
+ ```
31
+
32
+ Expected:
33
+ - OpenClaw status shows ClawMem as the active memory plugin
34
+ - `plugins.slots.memory = clawmem`
35
+
36
+ Then verify the current agent route. Resolve the current route with the bundled helper:
37
+
38
+ ```sh
39
+ eval "$(python3 scripts/clawmem_exports.py)"
40
+ printf 'agent=%s\nbase=%s\ndefaultRepo=%s\ntoken=%s\n' \
41
+ "${CLAWMEM_AGENT_ID}" "${CLAWMEM_BASE_URL}" "${CLAWMEM_DEFAULT_REPO}" \
42
+ "$(test -n "${CLAWMEM_TOKEN}" && printf SET || printf MISSING)"
43
+ ```
44
+
45
+ If `CLAWMEM_DEFAULT_REPO` or `CLAWMEM_TOKEN` is missing, the current agent has not been provisioned yet. Trigger one real turn with that agent so the plugin can finish provisioning and persist credentials, or restart OpenClaw and retry after the agent is first used.
46
+
47
+ ## Step 2: Verify read access without manual login
48
+
49
+ This proves that a fresh session can query ClawMem using the current agent's provisioned route.
50
+
51
+ ```sh
52
+ eval "$(python3 scripts/clawmem_exports.py)"
53
+
54
+ test -n "$CLAWMEM_REPO" || { echo "Current agent route has no repo yet"; exit 1; }
55
+ test -n "$CLAWMEM_TOKEN" || { echo "Current agent route has no token yet"; exit 1; }
56
+
57
+ GH_HOST="$CLAWMEM_HOST" GH_ENTERPRISE_TOKEN="$CLAWMEM_TOKEN" \
58
+ gh issue list --repo "$CLAWMEM_REPO" --limit 1 --json number,title
59
+ ```
60
+
61
+ If `gh` is unavailable or not the official GitHub CLI, use the fallback probe:
62
+
63
+ ```sh
64
+ curl -sf -H "Authorization: token $CLAWMEM_TOKEN" \
65
+ "$CLAWMEM_BASE_URL/repos/$CLAWMEM_REPO/issues?state=open&per_page=1&type=issues" | \
66
+ jq 'map({number,title})'
67
+ ```
68
+
69
+ If either command returns JSON, even `[]`, the route is usable.
70
+
71
+ ## Step 3: Verify the plugin tool path
72
+
73
+ From a normal ClawMem-enabled session, verify that:
74
+ - `memory_repos` lists accessible repos and marks the default repo
75
+ - `memory_list` returns the active memory index
76
+ - `memory_get` fetches one exact memory by id or issue number
77
+ - `memory_labels` returns the current reusable schema labels
78
+ - `memory_recall` returns either a hit list or a clean miss
79
+ - `memory_store` is available for immediate durable saves
80
+ - `memory_update` updates an existing memory in place
81
+ - `memory_repo_create` creates a new repo when a new memory space is needed
82
+
83
+ Conversation summaries or auto-extracted memories from a just-finished session may appear on the next real request, not necessarily immediately at session close.
84
+
85
+ ## Compatibility mode for SOUL.md, AGENTS.md, and TOOLS.md
86
+
87
+ If your OpenClaw environment still relies on file-injected identity or behavior reminders, use these compact compatibility snippets. Do not duplicate the entire skill body into those files.
88
+
89
+ ### Optional SOUL.md identity block
90
+
91
+ ```markdown
92
+ ## Memory System — ClawMem
93
+ I use ClawMem as my memory system.
94
+ When prior context may help, I search ClawMem before answering.
95
+ ```
96
+
97
+ ### Optional AGENTS.md reminder
98
+
99
+ ```markdown
100
+ Before ending every response, ask: "Did I learn anything durable this turn?"
101
+ If yes or unsure, save it to ClawMem now.
102
+ ```
103
+
104
+ ### Optional TOOLS.md reminder
105
+
106
+ ```markdown
107
+ ClawMem is the primary long-term memory system.
108
+ Use the bundled $clawmem skill for retrieval, saving, routing, schema, and troubleshooting.
109
+ ```
110
+
111
+ These snippets are compatibility aids, not the primary runtime source of truth.
112
+
113
+ ## Definition of done
114
+
115
+ - `openclaw.json` has `plugins.slots.memory = clawmem`
116
+ - The current agent route has a `defaultRepo` or legacy `repo`
117
+ - The current agent route has a `token`
118
+ - Read-only probe works without manual `gh auth login`
119
+ - Plugin memory tools work from a normal session
120
+ - The bundled `$clawmem` skill is available after installation
121
+
122
+ ## If ClawMem is still broken
123
+
124
+ - If `plugins.slots.memory` is wrong, set it back to `clawmem`, restart the gateway, and retry.
125
+ - If the route is missing a repo or token, trigger one real turn with that agent and retry provisioning checks.
126
+ - If a new session gets `401 Unauthorized`, re-read the current route instead of assuming the old repo or token is still valid.
127
+ - If your environment still depends on `SOUL.md` or `AGENTS.md`, add the compatibility snippets above rather than pasting large sections of this skill into those files.