[Architecture] Split Engineering Memory SQLite persistence monolith
Labels: enhancement, architecture, memory
Priority: P2 (architecture triage)
Subject: codeclone/memory/sqlite_store.py
Signal: responsibility_overload
Triage run: e28867ed (health 91/A)
Summary
SqliteEngineeringMemoryStore is a single high-blast persistence sink that owns records, trajectories, experiences, FTS search, and retention in one ~1,140-line class.
Environment
- Product/Service: CodeClone
- Version: 2.1.0a1 (run
e28867ed)
- Area: Engineering Memory / persistence (
codeclone.memory)
Current State
codeclone/memory/sqlite_store.py has fan-in 38 (production) and overloaded score 0.988.
- Unwind signals:
central_sink, chain_bottleneck.
- Impact blast: high — 19 production direct importers (governance, retrieval, trajectory, ingest, CLI memory, MCP memory mixin).
SqliteEngineeringMemoryStore exposes 66 methods spanning record CRUD, trajectory projection storage, experience counts, FTS, vacuum/retention.
Expected Behavior
Persistence lanes that evolve independently (records, trajectories, experiences, FTS/retention) should have bounded repositories or slices under codeclone.memory, with sqlite_store as a thin coordinator or facade — not the sole owner of every SQL path.
Actual Behavior
All memory persistence lanes converge in one production class. Schema or lane changes (trajectory projection, Experience promotion, semantic rebuild) require coordinated edits in the same high-blast module.
Impact
Medium — No correctness bug today; regression and review cost scale with every memory feature. Correct package placement (codeclone.memory), but change risk is concentrated.
Proposed Direction
- Extract lane-specific repositories (records, trajectories, experiences, search index) behind stable internal protocols.
- Keep policy/governance in existing
codeclone.memory.* owners; limit store modules to persistence I/O.
- Preserve public store API or migrate callers incrementally with contract tests.
Additional Context
- Architecture triage score: C+D+E → 30 (P2).
tests/test_memory_sqlite_store_coverage.py, tests/test_memory_store.py are primary regression guards.
- Not a boundary violation: module is in the correct package; defect is multi-lane overload inside one owner.
[Architecture] Split Engineering Memory SQLite persistence monolith
Labels:
enhancement,architecture,memoryPriority: P2 (architecture triage)
Subject:
codeclone/memory/sqlite_store.pySignal:
responsibility_overloadTriage run:
e28867ed(health 91/A)Summary
SqliteEngineeringMemoryStoreis a single high-blast persistence sink that owns records, trajectories, experiences, FTS search, and retention in one ~1,140-line class.Environment
e28867ed)codeclone.memory)Current State
codeclone/memory/sqlite_store.pyhas fan-in 38 (production) and overloaded score 0.988.central_sink,chain_bottleneck.SqliteEngineeringMemoryStoreexposes 66 methods spanning record CRUD, trajectory projection storage, experience counts, FTS, vacuum/retention.Expected Behavior
Persistence lanes that evolve independently (records, trajectories, experiences, FTS/retention) should have bounded repositories or slices under
codeclone.memory, withsqlite_storeas a thin coordinator or facade — not the sole owner of every SQL path.Actual Behavior
All memory persistence lanes converge in one production class. Schema or lane changes (trajectory projection, Experience promotion, semantic rebuild) require coordinated edits in the same high-blast module.
Impact
Medium — No correctness bug today; regression and review cost scale with every memory feature. Correct package placement (
codeclone.memory), but change risk is concentrated.Proposed Direction
codeclone.memory.*owners; limit store modules to persistence I/O.Additional Context
tests/test_memory_sqlite_store_coverage.py,tests/test_memory_store.pyare primary regression guards.