nexusmem 0.10.1 → 0.10.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/CHANGELOG.md +32 -0
- package/README.md +555 -550
- package/dist/cli/index.js +360 -68
- package/dist/cli/index.js.map +1 -1
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -11,6 +11,38 @@ built from, matched by publish timestamp: `v0.1.0` → `67a4776`, `v0.1.1` → `
|
|
|
11
11
|
|
|
12
12
|
No unreleased changes yet.
|
|
13
13
|
|
|
14
|
+
## [0.10.3] — 2026-08-31
|
|
15
|
+
|
|
16
|
+
### Added
|
|
17
|
+
|
|
18
|
+
- `hook git-post install|remove|status`: an opt-in git post-commit hook that runs a full
|
|
19
|
+
`nexusmem sync` (including embedding) in the background after every commit. Detached (`nohup ... &`),
|
|
20
|
+
so it never makes `git commit` itself wait; output goes to `.nexusmem/post-commit-sync.log` instead
|
|
21
|
+
of the terminal. `sync` gained a matching `--auto` flag (used only by this hook) that skips instead
|
|
22
|
+
of running if another `--auto` sync already holds an advisory lock over the project's workspace dir —
|
|
23
|
+
a burst of commits (e.g. a rebase) coalesces into one sync instead of piling up. The log file is
|
|
24
|
+
reset once it passes 2000 lines so it can't grow forever, and a skipped/coalesced run is always
|
|
25
|
+
reported there, even though the hook always passes `--quiet`.
|
|
26
|
+
|
|
27
|
+
### Known limitations
|
|
28
|
+
|
|
29
|
+
- A burst of commits fast enough to launch genuinely overlapping `sync --auto` processes can
|
|
30
|
+
interleave two runs' text mid-line in `.nexusmem/post-commit-sync.log` — the advisory lock
|
|
31
|
+
serializes the actual database writes (never at risk), not who gets to write to this diagnostic
|
|
32
|
+
log file. Cosmetic only; not planned to be fixed unless it turns out to matter in practice.
|
|
33
|
+
|
|
34
|
+
## [0.10.2] — 2026-08-30
|
|
35
|
+
|
|
36
|
+
### Security
|
|
37
|
+
|
|
38
|
+
- `shell_command` nodes never ran through the same secret-redaction pass `conversation_turn` and
|
|
39
|
+
`code_diff` nodes already get: a command like `export API_KEY=...` landed verbatim in `title`/`body`,
|
|
40
|
+
which is exactly what the FTS index and vector embeddings are built from — a secret typed at a
|
|
41
|
+
prompt could resurface later through `search_memory`/`nexusmem query`. Fixed by running `redact()`
|
|
42
|
+
over the command before it reaches those fields. `meta.command` is kept raw on purpose: project-id
|
|
43
|
+
reconciliation and failure/fix correlation both hash or exact-match against the real command text,
|
|
44
|
+
and redacting that copy too would have silently orphaned nodes on a project-id migration.
|
|
45
|
+
|
|
14
46
|
## [0.10.1] — 2026-08-30
|
|
15
47
|
|
|
16
48
|
### Added
|