Motivation
Wings currently connect only through explicit relationships. Projects that use the same tech stack, framework, vendor, or concept often have meaningfully related memories across wings, but today there is no way to surface that.
Example: if two wings both discuss a specific framework (Angular, OpenAPI, a given cloud vendor), the user searching for notes about that framework in one wing may reasonably want to see what the other wing captured about it.
The LLM refine step introduced in #1150 already emits a TOPIC label for framework/vendor/product references the user confirms. That is the right signal source for this feature.
Proposal
After confirmation, when two wings share one or more TOPICs above a weight threshold, automatically drop a tunnel between them in palace_graph.py. Tunnels are labeled with the shared topic and its co-occurrence strength.
Design tradeoffs worth discussing before building
- Weight threshold. Too loose and every wing links to every other via broadly-used topics (Python, Docker). Too tight and real connections are missed. Needs a sensible default plus a config knob.
- Signal source. Topics-from-LLM only, or also entity co-occurrence and manifest-dependency overlap (e.g. two
package.json files declaring the same non-trivial dependency)? Manifest overlap is harder signal but narrower scope.
- When to compute. Mine-time (slow first mine, nothing extra at search), search-time (slow search, always fresh), or nightly rebuild. Mine-time is probably right since the graph changes infrequently.
- User control. Some shared topics make useful tunnels, others are noise. Consider: a confirm step analogous to
confirm_entities, or a per-topic allowlist/denylist the user maintains once.
- Display. How are these tunnels surfaced in search results? A separate "related wings" section, or inline as breadcrumbs on each drawer?
Acceptance criteria (draft)
palace_graph.py can add topic-weighted tunnels between two wings given a shared TOPIC set
- Mine-time pass (or explicit
mempalace rebuild-tunnels command) populates these from confirmed entity data
- Search results can traverse tunnels to surface related drawers from adjacent wings
- Config knob for minimum weight threshold
- Tests covering: topic-only link, manifest-only link (if included), threshold honored, no link when below threshold
Out of scope for this issue
- Automatic tunnel naming / semantic labels beyond the shared topic
- Cross-palace tunnels
- Dependency graph ingestion from lockfiles (separate idea)
Motivation
Wings currently connect only through explicit relationships. Projects that use the same tech stack, framework, vendor, or concept often have meaningfully related memories across wings, but today there is no way to surface that.
Example: if two wings both discuss a specific framework (Angular, OpenAPI, a given cloud vendor), the user searching for notes about that framework in one wing may reasonably want to see what the other wing captured about it.
The LLM refine step introduced in #1150 already emits a
TOPIClabel for framework/vendor/product references the user confirms. That is the right signal source for this feature.Proposal
After confirmation, when two wings share one or more TOPICs above a weight threshold, automatically drop a tunnel between them in
palace_graph.py. Tunnels are labeled with the shared topic and its co-occurrence strength.Design tradeoffs worth discussing before building
package.jsonfiles declaring the same non-trivial dependency)? Manifest overlap is harder signal but narrower scope.confirm_entities, or a per-topic allowlist/denylist the user maintains once.Acceptance criteria (draft)
palace_graph.pycan add topic-weighted tunnels between two wings given a shared TOPIC setmempalace rebuild-tunnelscommand) populates these from confirmed entity dataOut of scope for this issue