Hi — ran into cdd-mempalace while sweeping the MemPalace ecosystem and it's genuinely useful framing. The MAPPING.md (CDD primitives → wings/halls/rooms) is exactly the kind of structural overlay I've been improvising ad-hoc on jphein/mempalace for multi-project engineering work.
Background, briefly. I maintain a production MemPalace fork running ~165K drawers across ~28 wings since 2026-04-09 — heavy use for cross-project software work with Claude Code. Our current active upstream queue is a mix of reliability hardening (ChromaDB 1.5.x segfault workarounds, silent-save hooks, miner.status pagination) and ergonomics (cmd_export, cmd_purge, configurable chunking, diary wing routing). The full picture is in our fork change queue.
Our usage maps almost exactly onto the Hades / four-delivery-wave pattern you've written up in #765, #891, #910 — handoff capsules, shared-memory cold starts, multi-project engineering memory. I'd read those discussions before I knew cdd-mempalace existed, so there's strong convergence.
A few questions if you have time:
- What does cdd-mempalace's roadmap look like for the next few weeks? I've been tracking whether to treat this as a reference (read MAPPING.md, apply the patterns manually to our wings) or a tool to adopt directly. Happy to contribute if there are concrete gaps.
- Any patterns you've developed that you'd like to see upstreamed to mempalace? Your upstream PRs look substantial (test coverage, Windows fixes, engineering-memory docs). If there's overlap with what we're filing — wing derivation, hook scoping, CDD-aware room detection — happy to coordinate so we're not stepping on each other.
- Specific to our fork: we've been hitting the "hooks pollute curated palaces" problem that @kostadis raised in #1018 — auto-mined chat content mixing with manually-curated engineering memory. Does CDD's structural separation (products/subsystems/task streams) handle this naturally, or is it something you've had to work around separately?
- Eval / measurement: CDD places emphasis on decisions surviving handoffs. Have you built any measurement for this — whether a cold-start actually recovers the decision chain correctly? We've been eyeing M0nkeyFl0wer/multipass-structural-memory-eval's "Category 9: The Handshake" as a candidate framework but haven't run it yet.
No rush on any of these — just opening the conversation rather than landing code unbidden. Genuinely appreciate the work you've put into making the engineering-memory axis legible.
— JP / jphein
Hi — ran into cdd-mempalace while sweeping the MemPalace ecosystem and it's genuinely useful framing. The MAPPING.md (CDD primitives → wings/halls/rooms) is exactly the kind of structural overlay I've been improvising ad-hoc on jphein/mempalace for multi-project engineering work.
Background, briefly. I maintain a production MemPalace fork running ~165K drawers across ~28 wings since 2026-04-09 — heavy use for cross-project software work with Claude Code. Our current active upstream queue is a mix of reliability hardening (ChromaDB 1.5.x segfault workarounds, silent-save hooks, miner.status pagination) and ergonomics (
cmd_export,cmd_purge, configurable chunking, diary wing routing). The full picture is in our fork change queue.Our usage maps almost exactly onto the Hades / four-delivery-wave pattern you've written up in #765, #891, #910 — handoff capsules, shared-memory cold starts, multi-project engineering memory. I'd read those discussions before I knew cdd-mempalace existed, so there's strong convergence.
A few questions if you have time:
No rush on any of these — just opening the conversation rather than landing code unbidden. Genuinely appreciate the work you've put into making the engineering-memory axis legible.
— JP / jphein