feat:Add local personal memory

[alecuba16]

This pull request adds a local personal memory system for codebase notes, decisions, and learnings. It is intentionally separated from the fork release workflow work so this PR only contains the personal-memory feature.

This replaces the closed broad PR #761 with the workflow option removed, and addresses the security review note from #761 (comment).

Personal memory

The main addition is a per-repo personal memory that lives outside the repository, in the user's local data directory. The goal is to let an agent or developer store notes, decisions, and learnings about a codebase without writing files into the source repository or pushing that context upstream.

A new MCP tool called manage_memory is exposed with these modes:

• get
• update
• sections
• settings
• bootstrap
• delete
• list
• promote
• sync

manage_adr also gains an optional scope parameter so it can target either project-scoped ADRs, which remains the default for compatibility, or personal memory.

The memory directory, default scope, and enablement are configurable. A new platform helper, cbm_resolve_memory_dir, resolves the correct local user-data path for each operating system.

Security and local-only behavior

After the review comment on #761, I added a focused security hardening pass in commit 5f0f4b6:

• Personal memory storage directories are created with private 0700 permissions on POSIX systems.
• Existing memory directories are chmod-corrected to 0700 when opened for writes.
• manage_memory(settings) redacts local filesystem paths by default.
• Local paths can only be shown explicitly with reveal_paths=true.
• MCP responses redact repo IDs and storage keys because they are derived from local canonical repo paths.
• delete is now idempotent, returns not_found when appropriate, and no longer creates a DB just to delete from it.
• promote and sync are local copy operations only. Responses now explicitly report local_only and network_sync=disabled.
• Tests cover path redaction, private directory permissions, local-only metadata, and delete semantics.

Nothing in this feature uploads personal memory to the repository, remotes, package registries, or external services. Storage is local SQLite under the resolved personal memory directory.

Other changes

• README and embedded skill documentation explain the personal memory workflow.
• The smoke invariants script covers the new memory paths.
• Tests cover manage_memory and personal scope in manage_adr.
• A cross-platform cbm_setenv / cbm_unsetenv helper was added for Windows-compatible tests.

Validation

• Rebased on current upstream main at 09148ab.
• make -f Makefile.cbm test passes locally: 5766 passed.

[DeusData]

Thanks for splitting the local personal memory work out from #761. Triage: high-caution local-memory enhancement.

This is a better review shape than the combined workflow PR, but it still needs a security/privacy pass: local-only storage boundaries, delete semantics, sync/promote behavior, no external transmission, no sensitive-data logging, and clear docs on where data lives. Please keep the PR scoped to the memory feature only.

[alecuba16]

Thanks for the review. I updated the PR with a security/privacy pass and kept it scoped to the memory feature.

What changed:

• manage_memory now rejects memory storage paths that are relative or inside the source repo.
• Responses now state local_only, external_transmission=false, network_sync=disabled, repo_upload=disabled, and sensitive_data_logging=disabled.
• mode="sync" is now disabled and returns sync_disabled. There is no network sync.
• mode="promote" is documented and returned as a local copy from branch memory to base branch memory only.
• mode="delete" is documented and returned as deleting only the selected repo/branch/doc row, not the DB file or other memory.
• Docs now explain where memory.db lives, how CBM_MEMORY_DIR works, path redaction, and reset/delete limits.
• Tests were added for repo-local storage rejection, sync disabled, privacy fields, delete semantics, and path redaction.

I also adjusted the default behavior to avoid changing existing installs:

• memory_enabled=false by default.
• memory_default_scope=project by default.
• Local personal memory is opt-in.
• Added a test that default-disabled memory does not create memory.db.

Validation:

• lint-format
• lint-no-suppress
• git diff --check
• full test suite: 5768 passed

I squashed it back to one commit: cfa69f3.

[DeusData]

Status update after a full review pass — being straight with you about where this stands.

Review outcome: security-clean (no network/exec surface, storage-path validation works as described, env access through the safe helpers), the Makefile/lint wiring is correct, and the privacy rework you did after #761 addressed the concerns from that thread. Two mechanical items would still be needed: a rebase (main has moved substantially — the PR currently conflicts) and the three raw remove() calls on memory/config DB paths should be cbm_unlink (raw ANSI file ops break on non-ASCII Windows paths — same class we just fixed in #996).

Decision: deferring this past the v0.9.1 release. The honest reason is direction, not quality: a personal-memory subsystem is a significant permanent surface (a 9-mode MCP tool, a new storage location, sync/promote semantics across scopes), and whether cbm should grow a notes store alongside its knowledge-graph core — versus leaving that to the agents' native memory systems — is a product question we want to settle deliberately, not under release pressure.

No action needed from you right now; specifically NOT asking for the rebase yet, so you don't invest in churn while the concept decision is pending. We'll come back to this PR after 0.9.1 ships with a clear yes/no/reduced-scope answer. Sorry for the long runway on this one — the split from #761 and the privacy pass were genuinely good work, and this deferral is not a soft rejection.

[alecuba16]

No problem, thanks for taking a look anyway