Memory Crystal Private

# Memory Crystal stops shipping `ldm-backup.sh` ## Narrative Per the bin ownership decision in PR #717 design pass (Q3): the LDM CLI owns `ldm-backup.sh`; Memory Crystal drops its copy. With both packages now on the manifest model (memory-crystal v0.7.37 declared `crystal-capture.sh`; wip-ldm-os v0.4.83 declared `ldm-backup.sh` and four other LDM-owned files), the runtime resolves any cron target back to its declarer, install-time self-heal restores from canonical sources, and the manifest aggregator refuses to act when two declarers claim the same name. The remaining hygiene step is removing MC's duplicate so there is one source of truth on disk and in published artifacts. Closes the last item from the parent ticket on `wip-ldm-os-private` (`ai/product/bugs/installer/2026-04-28--cc-mini--ldm-bin-overwrite-wipes-crystal-capture.md`); refs #124. This release does not affect runtime behavior on installs that already received both packages: the LDM CLI's `wipLdmOs.binFiles` is the authoritative source for `ldm-backup.sh`, and `ldm install` keeps it deployed at `~/.ldm/bin/ldm-backup.sh`. The MC-side change just stops competing for the file and removes it from MC's published artifact and `crystal init` flow. ## What changed - **`openclaw.plugin.json`** unchanged. MC continues to declare only `crystal-capture.sh` in `binFiles`, so the runtime aggregator never saw a manifest-level conflict on `ldm-backup.sh` from this side. - **`package.json` `files`** drops `scripts/ldm-backup.sh`. The published npm tarball no longer carries MC's copy. - **`package.json` `scripts.build`** drops the `cp scripts/ldm-backup.sh dist/` step. The build no longer copies a duplicate into `dist/`. - **`src/installer.ts`** Step 6 (in `runInstallOrUpdate`) replaces the `deployBackupScript()` call with a verify of `~/.ldm/bin/ldm-backup.sh`. If the file is absent, the install fails loudly with `expected ~/.ldm/bin/ldm-backup.sh (LDM CLI-owned); run "ldm install" first`. - **`src/cli.ts`** `crystal backup setup` replaces `deployBackupScript()` with the same verify and a clear error message pointing at `ldm install`. `crystal backup` (no subcommand) updates its missing-file message from "Run crystal init first" to "Run ldm install first". - **`deployBackupScript`** import is removed from both `installer.ts` and `cli.ts`. The function and `scripts/ldm-backup.sh` themselves stay in the repo for now (delete-restricted by the per-edit guard on this codebase) but are no longer called and no longer published. ## Why this is safe The LDM CLI's manifest already covers `ldm-backup.sh`: - After `wip-release patch` for wip-ldm-os v0.4.83, the LDM CLI declares ownership in `package.json#wipLdmOs.binFiles`. - After `ldm install`, the manifest heal walk restores `~/.ldm/bin/ldm-backup.sh` from the LDM CLI's `scripts/ldm-backup.sh`. - `crystal backup setup` is operator-invoked and now verifies-then-installs the LaunchAgent. Failure mode: clear "run ldm install first" message instead of silently double-deploying or relying on whoever ran last. - `crystal init` similarly verifies-then-throws if the LDM CLI hasn't run. The only behavior change visible to operators is: `crystal init` and `crystal backup setup` now expect the LDM CLI to have run first. Since `crystal init` already delegates to `ldm install` when the LDM CLI is on PATH (`installer.ts` line 633 `runLdmInstall(repoRoot)`), this is the normal flow for every existing install. ## Tests - `npm run validate:bin-manifest` ... passes. - `npm run build` ... passes; `dist/ldm-backup.sh` is no longer produced. - `node scripts/test-shim-integrity.mjs` ... still 7/7 assertions pass; capture-shim diagnostics unchanged. ## What this does NOT do - **`deployBackupScript` function** stays defined in `src/ldm.ts`. The function is dead code now (no callers in the package). A future cleanup can remove it; restricted by the per-edit guard on this PR's surface. - **`scripts/ldm-backup.sh` file** stays in the source tree. Not in the published artifact. Removable in a future cleanup once the per-edit guard is satisfied. - **No runtime behavior change for already-installed operators** beyond the verify-instead-of-deploy in MC's installer paths. `~/.ldm/bin/ldm-backup.sh` keeps working because the LDM CLI manifest deploys it on every `ldm install`.

# Memory Crystal declares `binFiles` for the LDM bin manifest ## Narrative On 2026-04-28 a capture outage exposed the failure mode at the heart of this release: cron lines in `~/.ldm/bin/` are sticky, but the files they reference can disappear, and nothing in either Memory Crystal's or the LDM CLI's diagnostic surface said who owned what. PR #123 closed the install-time invariant and `crystal doctor --fix` recovery on the Memory Crystal side. The parent ticket on `wip-ldm-os-private` (`ai/product/bugs/installer/2026-04-28--cc-mini--ldm-bin-overwrite-wipes-crystal-capture.md`) then called for a shared ownership model so the LDM CLI could heal extension shims without hardcoded knowledge. This release contributes Memory Crystal's half of that contract: an explicit `binFiles` declaration in `openclaw.plugin.json` naming `crystal-capture.sh`, plus a prepublish validator that prevents a broken declaration from ever reaching npm. After this lands and the operator runs `ldm install` (with LDM CLI v0.4.83+), `ldm doctor` resolves Memory Crystal as the explicit owner of `crystal-capture.sh`, and the LDM CLI can self-heal a missing or non-executable shim from Memory Crystal's extension dist without any LDM-side hardcoded mapping. Closes #124. ## What changed - `openclaw.plugin.json` now declares `binFiles` with one entry: `crystal-capture.sh` from `dist/crystal-capture.sh`. This lets the LDM CLI's bin-ownership manifest aggregate Crystal's shim and self-heal it during `ldm install` or `ldm doctor --fix`. Previously the LDM CLI fell back to a hard-coded match for this file; now ownership is explicit and symmetric with every other declarer. - `scripts/validate-bin-manifest.mjs` (new) runs from `prepublishOnly` after `npm run build`. Asserts each declared `source` exists in the published artifact, no internal duplicates, `name` is a basename. A broken declaration cannot reach npm. Layer 1 of the release-blocker design. - `package.json` `prepublishOnly` chains `validate:bin-manifest` after the existing build step. ## Why Closes the Memory Crystal half of the LDM bin-ownership manifest follow-up tracked in `wipcomputer/wip-ldm-os-private:ai/product/bugs/installer/2026-04-28--cc-mini--ldm-bin-overwrite-wipes-crystal-capture.md`. With this declaration: - `ldm doctor` resolves `crystal-capture.sh` as `declarer = memory-crystal` instead of `owner unknown`. - `ldm install` can self-heal a missing or non-executable `~/.ldm/bin/crystal-capture.sh` from `~/.ldm/extensions/memory-crystal/dist/crystal-capture.sh` without any LDM-side hardcode. - A future broken declaration (missing source, internal duplicate, non-basename name) is caught at publish time, not at install time on the operator's machine. ## What this does NOT do - **`ldm-backup.sh` collision cleanup.** Memory Crystal still ships and deploys its own copy of `ldm-backup.sh`. Per the agreed ownership in the design pass (LDM CLI keeps it, MC drops its copy), that cleanup lands as a separate small PR. This PR is intentionally scoped to the binFiles declaration so review is small. If MC declared `ldm-backup.sh` here it would conflict at the manifest level with the LDM CLI's declaration; we are avoiding that until the cleanup PR runs. - **Layer 2 cross-package CI gate.** That is a workflow on `wip-ldm-os-private` and is independent of MC.

# Memory Crystal v0.7.35 One-line release: **`crystal status` and every other CLI verb now actually run on global installs under modern Node**. Before this release, a silent packaging mistake made every `crystal <verb>` command throw `ERR_MODULE_NOT_FOUND` at startup on Node 25.6+, which is the first Node version to enforce strict ESM resolution against an unresolvable bare import. Ingestion continued to work the whole time because the Claude Code Stop hook takes a different code path. ## What was wrong `package.json` declared its dream-weaver-protocol dependency with a `file:` relative path intended for local dev (`file:../dream-weaver-protocol-private`). When users ran `npm install -g @wipcomputer/memory-crystal`, npm tried to resolve that path relative to the global install root, could not find the sibling directory, and left the module unresolvable. Older Node resolvers tolerated the resulting empty state; Node 25 does not. Any entrypoint that imports `dream-weaver.ts` — which is every interactive CLI — threw on startup. ## What changed Added `tsup.config.ts` with `noExternal: ['dream-weaver-protocol']`. Tsup now bundles dream-weaver's source code into each memory-crystal dist entrypoint at build time, so the published tarball is self-contained and needs no runtime resolution of that dep. The CLI verbs work on any Node from 18 to 25+. ## What did not change - Ingestion: the Claude Code Stop hook path was never broken. Continuous capture kept going at normal rate. - Search: the MCP server entrypoint was never broken. Agents that use `crystal_search` through MCP were unaffected. - Data: zero chunks were lost. Today's DB count is 92,696 and growing. ## Related bugs filed in this release - `ai/product/bugs/2026-04-18--cc-mini--crystal-status-cli-broken-node-25.md` — this bug in full, with root cause, discovery narrative, and follow-up work - `ai/product/bugs/2026-04-18--cc-mini--lesa-capture-gap-2026-04-17.md` — a separate concern: during the Opus 4.7 rollout incident on Apr 17, Lēsa's gateway failed repeatedly on an unknown model ID and emitted no successful agent_end events, so ingestion for that day dropped to ~46 chunks vs ~300 baseline. Propose backfill + structural prevention in that bug. ## Install ```bash npm install -g @wipcomputer/memory-crystal@latest crystal status ``` If that reports your chunk count and agent list cleanly, you're on the fix. Closes wipcomputer/memory-crystal#68.

# Release Notes: memory-crystal v0.7.33 Related: #255 ## Fix npm publish: include dist/ in package The npm package was missing the `dist/` directory because `.gitignore` excludes it and there was no `files` array in package.json to override. The `crystal` CLI binary pointed to `dist/cli.js` which didn't exist in the published package. Every `npm install -g` installed a broken CLI. Added `files` array to explicitly include `dist/` in the tarball. Added `prepublishOnly: npm run build` so the package is always built before publishing. The npm tarball now contains the compiled JavaScript that the CLI and MCP server need.

# Release Notes: memory-crystal v0.7.32 **Date:** 2026-03-31 ## What changed ### Dream Weaver is a required dependency again Reverts PR #101 (optional Dream Weaver import). dream-weaver-protocol is back in `dependencies` instead of `optionalDependencies`. The static import in `dream-weaver.ts` is restored. The dynamic import with try/catch wrapper is removed. The null check in `cli.ts` for when DW is unavailable is removed. ## Why PR #101 made dream-weaver-protocol optional because `file:../dream-weaver-protocol-private` failed in fresh clones where the sibling directory doesn't exist. The installer (v0.4.68+) now resolves `file:` dependencies from installed extensions at `~/.ldm/extensions/` before building, so the sibling directory is no longer needed. The build succeeds without it. Making DW optional added complexity (dynamic imports, null checks, degraded type safety) that is no longer necessary. This revert simplifies the code back to what it was. ## How to verify ```bash # Build should succeed (installer resolves file: deps) cd memory-crystal-private && npm run build # dream-weaver-protocol should be in dependencies, not optionalDependencies node -e "const p = require('./package.json'); console.log('deps:', !!p.dependencies['dream-weaver-protocol']); console.log('optional:', !!p.optionalDependencies?.['dream-weaver-protocol'])" # Should print: deps: true, optional: false ```

# Release Notes: memory-crystal v0.7.31 Closes #101 ## Dream Weaver protocol is now optional The dream-weaver-protocol dependency was a `file:` reference to a sibling directory. This worked in the development environment but broke when the installer cloned the repo to build (the sibling doesn't exist in a clone context). The build failed with "Cannot find module 'dream-weaver-protocol'". The protocol is now an optional dependency with a dynamic import. If dream-weaver-protocol is available (installed locally or linked), Dream Weaver features work normally. If not, crystal operations continue without Dream Weaver. The build succeeds either way. This is part of a broader fix to make all repos buildable in isolation. The installer (v0.4.67+) now resolves `file:` dependencies from installed extensions before building, so the protocol will be linked automatically when both packages are installed.

# Release Notes: memory-crystal v0.7.30 **Date:** 2026-03-30 ## What changed ### Hardcoded path removal Two files had `/Users/lesa` hardcoded as a fallback path. Both now use portable alternatives. **migrate-lance-to-sqlite.mjs** had a fallback that resolved the OpenClaw workspace to `/Users/lesa/.openclaw`. The migration script now calls `os.homedir()` to build the path dynamically, so it works on any machine without assuming a specific username. This was the last remaining hardcoded path in the migration pipeline (#99). **dev-update.ts** (the ai/dev-updates scanner) had an iCloud path baked in for reading team documents. It now calls `resolveWorkspace()` to read the workspace root from LDM config (`~/.ldm/config.json`), making it portable across machines and user accounts (#98). ## Why These paths broke on any machine where the username is not `lesa`. Part of a broader audit across all LDM OS repos to eliminate hardcoded user paths and make everything portable. ## Issues closed - #98 - #99 ## How to verify ```bash grep -r "/Users/lesa" src/ scripts/ --include="*.ts" --include="*.mjs" # Should return zero results ```

# Release Notes: memory-crystal v0.7.29 **Doc audit: MLX setup, deep search params, log paths, role clarification.** ## What changed SKILL.md and TECHNICAL.md updated for 2 weeks of undocumented features: - **MLX local LLM:** Added as Option A in SKILL.md Step 2. CLI commands (setup, status, stop) added to TECHNICAL.md. - **Deep search parameters:** `--intent`, `--explain`, `--candidates` documented in both SKILL.md (crystal_search tool) and TECHNICAL.md (CLI reference + new sections for intent, explain, candidate limit, LLM cache). - **Log paths:** Fixed obsolete `/tmp/ldm-dev-tools/` reference to `~/.ldm/logs/`. Added logs/ to directory structure. - **Role clarification:** Two-role architecture (Core and Node) explicitly stated. Standalone role was removed in v0.7.22. ## Why 29 releases in 13 days. Docs didn't keep pace. Agents using crystal_search didn't know about --intent (query disambiguation) or --explain (scoring transparency). ## Issues closed - #57 ## How to verify ```bash grep "intent" SKILL.md TECHNICAL.md grep "mlx" SKILL.md TECHNICAL.md grep "ldm/logs" TECHNICAL.md ```

# Release Notes: memory-crystal v0.7.28 **One-line summary of what this release does** ## What changed Describe the changes. Not a commit list. Explain: - What was built or fixed - Why it matters - What the user should know ## Why What problem does this solve? What was broken or missing? ## Issues closed - #91 ## How to verify ```bash # Commands to test the changes ```

# Add root SKILL.md + ldm install as primary path Added SKILL.md to repo root (source of truth for wip-release website publishing). `ldm install wipcomputer/memory-crystal` is now the recommended install path. `crystal init` stays for MC-specific setup (database, cron, role, pairing). Also added `.publish-skill.json` so wip-release publishes SKILL.md to wip.computer/install/. Closes wipcomputer/wip-ldm-os#97. Convergence tracked in wipcomputer/wip-ldm-os#99.