CompositeCubeView currently uses a simple fast-mode strategy for multiple memory cubes: writes and feedback are fanned out to all cube views, while search results are merged from all cubes.

This is useful as a baseline, but it is not the ideal long-term behavior. In a mature multi-cube memory system, a new memory should not automatically be added to every accessible cube. It should be routed to the cube or cubes whose responsibility best matches that memory.

Context

Target file:

• src/memos/multi_mem_cube/composite_cube.py

Current design note:

A composite view over multiple logical cubes.

For now (fast mode), it simply fan-out writes to all cubes;
later we can add smarter routing / slow mode here.

Goals

Improve CompositeCubeView so multi-cube behavior becomes more responsibility-aware:

• Avoid blindly writing every memory to all accessible cubes.
• Route add/feedback operations based on cube responsibility, request context, memory type, user/session metadata, or another explicit policy.
• Keep the current fan-out behavior available as a fallback or fast mode.
• Improve search aggregation so results preserve useful cube provenance.
• Handle partial failures clearly when one cube fails but others succeed.

Questions to Consider

• How should a cube declare or expose its responsibility?
• Should routing be rule-based, metadata-based, model-assisted, or configurable?
• When should a memory be written to multiple cubes vs exactly one cube?
• Should search results include cube_id so downstream consumers know where each memory came from?
• What should happen when no cube clearly matches the memory?

Acceptance Criteria

• CompositeCubeView has a clearer routing strategy beyond unconditional fan-out.
• The default/fast fan-out behavior remains available for compatibility.
• Add/search/feedback behavior is covered by tests in a multi-cube scenario.
• The implementation documents how cube responsibility is used or configured.