sync: merge main into release/3.2.0 (preserve history)#764
Merged
igorls merged 5 commits intorelease/3.2.0from Apr 13, 2026
Merged
sync: merge main into release/3.2.0 (preserve history)#764igorls merged 5 commits intorelease/3.2.0from
igorls merged 5 commits intorelease/3.2.0from
Conversation
Replace "your memory system" with explicit MemPalace references and tool names (mempalace_diary_write, mempalace_add_drawer, mempalace_kg_add) in stop and precompact hook block reasons. This prevents Claude Code from misinterpreting the hook as a native auto-memory save instruction. Updated in both Python (hooks_cli.py) and standalone shell scripts. Also fix CONTRIBUTING.md Getting Started to show the fork-first workflow, matching the PR Guidelines section.
The current constraint `chromadb>=0.5.0,<0.7` forces pip to install chromadb 0.6.x, but palaces created with chromadb 1.x (which is what the mempalace dev environment actually uses — 1.5.7 per uv.lock) have an incompatible SQLite schema. Specifically, chromadb 0.6.x fails with `KeyError: '_type'` when opening a collection written by 1.x. This means a fresh `pip install mempalace` gives users a chromadb version that cannot read palaces created in the maintainer's own environment. The fix removes the upper bound so pip can resolve to the current stable chromadb release. Reproduction: python3 -m venv .venv && source .venv/bin/activate pip install mempalace # installs chromadb 0.6.3 # Try opening a palace created with chromadb 1.x: # -> _get_collection() returns None, tool_status() returns "No palace found" pip install chromadb==1.5.7 # force upgrade # -> tool_status() returns real data (26k drawers in our case)
fix: remove chromadb <0.7 upper bound — blocks 1.x installs
# Conflicts: # CONTRIBUTING.md
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why another sync PR
PR #763 resolved the content divergence between
mainandrelease/3.2.0— but it was squash-merged, which collapsed main's history into a single unrelated commit. GitHub still sees main and release/3.2.0 as divergent, so PR #762 (release/3.2.0 → main) remains marked CONFLICTING even though the file contents match.This PR re-does the sync as a true merge commit so that
release/3.2.0becomes a proper descendant ofmain.When merging this PR, click the dropdown arrow next to the green button and choose "Create a merge commit". Do NOT squash. Squashing will erase main's ancestry again and we'll be back to the same problem.
Conflicts resolved
CONTRIBUTING.md— kept release/3.2.0's version (upstream →MemPalace/mempalace.git, the correct org). Main still had the stalemilla-jovovich/mempalace.gitURL.pyproject.toml— auto-merged (version 3.2.0 + unbounded chromadb pin from fix: remove chromadb <0.7 upper bound — blocks 1.x installs #690)Verification
git log --oneline origin/main ^HEAD— empty (main fully contained)