mcp-memory-bucket 0.5.1 → 0.5.4
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 +21 -21
- package/dist/client/assets/{index-DPkF4wtg.js → index-6BCcM6pL.js} +244 -132
- package/dist/client/index.html +1 -1
- package/dist/src/config.js +17 -17
- package/dist/src/memory/repository.js +41 -41
- package/dist/src/memory/tools.js +16 -16
- package/dist/src/server.js +13 -13
- package/dist/src/shared/bucket-folder-tool.js +66 -0
- package/dist/src/shared/relocate-tool.js +2 -2
- package/dist/src/shared/relocate.js +2 -2
- package/dist/src/skills/builtin/memory-bucket-authoring/SKILL.md +28 -28
- package/dist/src/skills/repository.js +58 -58
- package/dist/src/skills/tools.js +18 -18
- package/dist/src/store/db.js +4 -4
- package/dist/src/store/search.js +1 -1
- package/dist/src/store/sync.js +20 -20
- package/dist/src/web/routes.js +33 -33
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -81,28 +81,28 @@ or `MEMORY_BUCKET_DIR`/`--memory-dir` — see Configuration below). It's a
|
|
|
81
81
|
scan cache, not the source of truth — the markdown files on disk always
|
|
82
82
|
are, and the cache can be safely deleted; it's rebuilt on next startup.
|
|
83
83
|
|
|
84
|
-
- **On startup**, every configured
|
|
84
|
+
- **On startup**, every configured folder is fully walked and each file is
|
|
85
85
|
upserted into the cache, keyed by mtime — a file whose mtime hasn't
|
|
86
86
|
changed since it was last cached is skipped, so restarting is cheap
|
|
87
|
-
even with a large
|
|
88
|
-
- **While running**, each
|
|
87
|
+
even with a large folder.
|
|
88
|
+
- **While running**, each folder is watched (via `chokidar`) for `add`,
|
|
89
89
|
`change`, and `unlink` events on matching files, and the cache is
|
|
90
90
|
updated incrementally as they happen — no polling, no manual reindex.
|
|
91
|
-
Only `SKILL.md` files count for skill
|
|
92
|
-
memory
|
|
91
|
+
Only `SKILL.md` files count for skill folders; any `.md` file counts for
|
|
92
|
+
memory folders. The watcher only looks 10 directories deep. A rename
|
|
93
93
|
arrives as a delete-then-add, not a single rename event.
|
|
94
|
-
- **Adding a
|
|
95
|
-
entry present at startup) triggers a scan of just that
|
|
96
|
-
full rescan of every
|
|
97
|
-
- **Removing a
|
|
94
|
+
- **Adding a folder** (via the web UI, or a `skill_sources`/`memory_sources`
|
|
95
|
+
entry present at startup) triggers a scan of just that folder, not a
|
|
96
|
+
full rescan of every folder already cached.
|
|
97
|
+
- **Removing a folder** (via the web UI) drops its rows from the cache and
|
|
98
98
|
search index immediately — it never touches files on disk.
|
|
99
99
|
|
|
100
100
|
The same process also serves a browser UI at `http://localhost:8767/` for
|
|
101
|
-
searching/filtering skills and memory docs by tag,
|
|
101
|
+
searching/filtering skills and memory docs by tag, folder, status, owner,
|
|
102
102
|
deprecated flag, and fulltext (SQLite FTS5), and sorting by creation date
|
|
103
103
|
or last-touched — a way to review and clean up what's in the index
|
|
104
|
-
without going through an agent. It also manages **
|
|
105
|
-
memory
|
|
104
|
+
without going through an agent. It also manages **folders**: add a skill or
|
|
105
|
+
memory folder by browsing the filesystem, or remove one (unregisters it and
|
|
106
106
|
drops its cached rows — never deletes files on disk). Beyond browsing,
|
|
107
107
|
the UI supports marking entries **deprecated** (independent of `status`,
|
|
108
108
|
so you don't lose "shipped"/"active" context when flagging something
|
|
@@ -110,8 +110,8 @@ stale) and **deleting** entries — both single-item and multi-select bulk,
|
|
|
110
110
|
with a confirm dialog before any delete. Deeper edits (renaming, editing
|
|
111
111
|
body content, changing tags) still go through the `skill_*`/`memory_*`
|
|
112
112
|
tools or the files directly. From an MCP session connected to this
|
|
113
|
-
server, call `bucket_open_ui` to get the URL. If no
|
|
114
|
-
yet, the UI opens straight into a first-run "add your first
|
|
113
|
+
server, call `bucket_open_ui` to get the URL. If no folders are configured
|
|
114
|
+
yet, the UI opens straight into a first-run "add your first folder" screen.
|
|
115
115
|
The UI is a Lit + `avosignals` app built with Vite (`src/client/`,
|
|
116
116
|
bundled to `dist/client/`) — `npm run build` builds it (along with the
|
|
117
117
|
server); `npm start` does **not** rebuild it, so run `npm run build`
|
|
@@ -133,10 +133,10 @@ memory/skill sources. Override that with one of:
|
|
|
133
133
|
Paths are resolved relative to the working directory. If no
|
|
134
134
|
`skill_sources`/`memory_sources` key is present, each defaults to the
|
|
135
135
|
example above only when that directory already exists on disk;
|
|
136
|
-
otherwise the server starts with zero
|
|
136
|
+
otherwise the server starts with zero folders and the UI's first-run
|
|
137
137
|
screen offers to add one.
|
|
138
138
|
|
|
139
|
-
**Multiple
|
|
139
|
+
**Multiple folders** (e.g. a personal skills folder plus a shared company
|
|
140
140
|
repo) are supported — give each source a name instead of a bare path:
|
|
141
141
|
|
|
142
142
|
```json
|
|
@@ -149,11 +149,11 @@ memory/skill sources. Override that with one of:
|
|
|
149
149
|
```
|
|
150
150
|
|
|
151
151
|
Bare-string and `{name, path}` entries can be mixed in the same array.
|
|
152
|
-
With a single
|
|
153
|
-
exactly as before. Once 2+
|
|
154
|
-
`
|
|
155
|
-
filter) — every list/get response also includes which `
|
|
156
|
-
came from.
|
|
152
|
+
With a single folder of a kind, `skill_create`/`memory_create`/etc. work
|
|
153
|
+
exactly as before. Once 2+ folders exist, those tools require an explicit
|
|
154
|
+
`folder` argument (and `skill_list`/`memory_list` gain an optional `folder`
|
|
155
|
+
filter) — every list/get response also includes which `folder` each item
|
|
156
|
+
came from. Folders can be added or removed at runtime through the web UI
|
|
157
157
|
without a restart; adding one there also appends it to this config file.
|
|
158
158
|
|
|
159
159
|
- the `MEMORY_BUCKET_DIR` environment variable, or the `--memory-dir <path>`
|