Add local personal memory and fork release workflow option

[alecuba16]

This pull request brings two features that I have been working on in my fork: a local personal memory system and a fork-friendly option for the release workflow.

Personal memory

The main addition is a per-repo personal memory that lives outside the repository, in the user data directory. The goal is to let an agent or a developer store notes, decisions and learnings about a codebase without pushing anything to the repository itself. This keeps the knowledge graph context local to each machine.

A new MCP tool called manage_memory is exposed with the following modes: get, update, sections, settings, bootstrap, delete, list, promote and sync. The manage_adr tool also gained an optional scope parameter so it can target either the project scope (the default, kept for compatibility) or the personal scope.

The memory is disabled by default. It can be enabled through the config with memory_enabled=true. The default scope and the memory directory are also configurable. A new platform helper cbm_resolve_memory_dir takes care of resolving the correct path on each operating system.

Fork release workflow option

The release workflow now accepts a fork_release boolean input. When it is set to true, the workflow skips the upstream-only publishing steps (VirusTotal, npm, PyPI and MCP Registry) and instead runs a lighter publish job that only un-drafts the GitHub release. This is useful for forks that do not have access to the upstream secrets but still want to produce release artifacts through CI.

The default behavior stays the same, so the upstream release path is not affected when the input is not provided.

Other changes

• The README and the embedded skill documentation were updated to explain the personal memory workflow.
• The smoke invariants script was adjusted to cover the new memory paths.
• New tests were added for manage_memory and the personal scope in manage_adr.
• A cross-platform cbm_setenv / cbm_unsetenv helper was introduced to fix the Windows build, where setenv and unsetenv are not available.

All tests pass on the full CI matrix (Ubuntu, macOS and Windows, both amd64 and arm64).

[DeusData]

Thanks for bringing this over from your fork. Triage: high-caution enhancement because it mixes a new MCP memory surface with release workflow changes and installer/runtime behavior.

This should not be reviewed as one broad PR. Please split the release-workflow option away from the local personal-memory feature. For the memory tool itself, review will need a security pass on local-only storage, deletion semantics, sync/promote behavior, sensitive-data logging, and confirmation that nothing leaves the machine. Workflow changes also need separate supply-chain review.

[alecuba16]

Thanks a lot for dedicating some time to look at this.

I will remove the workflow from here. Regarding the security concerns, let me take a look at what can be improved to meet your standards