Track upstream v0.10.x adoption without compromising Zova-native architecture

[ata-sesli]

Goal

Adopt valuable changes from upstream DeusData/codebase-memory-mcp v0.10.x without compromising this fork's Zova-native storage architecture, cross-repository behavior, correctness, or performance.

The first evaluated baseline is upstream tag v0.10.2, commit b377c62a. The common ancestor with this fork is b637e333. At the time of evaluation, the fork had 38 commits and upstream had 793 commits after that ancestor; 78 files were changed on both sides, and a three-way merge simulation produced conflicts across core MCP, pipeline, store, CLI, installer, build, and test surfaces.

This is therefore an adoption program, not a mechanical rebase.

Integration policy

• Do not rebase main directly onto upstream v0.10.x.
• Port or adapt upstream capabilities in independently reviewable PRs.
• Pin every child issue and PR to exact upstream tags, PRs, or commits.
• State whether a change is cherry-picked, rewritten for Zova, or deliberately rejected.
• Keep unrelated cleanup out of adoption PRs.
• Use Closes #N for child issues; individual PRs must not close this tracking issue.
• Close this issue only after final qualification passes.

Non-negotiable Zova invariants

Every adopted change must preserve:

• One shared cbm.zova database.
• Isolated workspaces within that database.
• Zova full-authority indexing and queries by default.
• Cross-repository search with exact project selectors and project prefiltering.
• Native incremental graph, metadata, FTS, and vector publication.
• Atomic publication, workspace health, backup, recovery, and fault behavior.
• Exact result parity with the pure-SQLite compatibility route.
• Zero unexpected fallbacks.
• Existing traversal and vector performance expectations.
• Fork-owned installers, pinned Zova SDK, and cross-platform release artifacts.

Workstreams

MCP and query behavior

• Adopt upstream MCP structuredContent, request backpressure, and config correctness fixes #5
• Evaluate and adopt upstream compact tree-format tool output and pagination #6
• Port upstream Cypher semantic-correctness fixes #7
• Port upstream Cypher bounds, timeout, and memory-safety fixes #8

Extraction, language, and indexed semantics

• Port upstream core extraction and parser correctness fixes #9
• Evaluate and port upstream v0.10.x language surfaces #10
• Define and implement CALL_REFERENCE semantics through the Zova-native stack #11
• Implement workspace-scoped coverage storage and check_index_coverage for Zova #12
• Adapt the upstream missed-code skeleton and coverage UI to shared Zova workspaces #13
• Reconcile upstream delta-merge indexing with Zova native incremental publication #14
• Port upstream indexing-boundary, discovery, watcher, and lifecycle fixes #17

Zova publication, operations, and coordination

• Port applicable upstream publication, WAL, artifact, and corruption fixes to Zova operations #15
• Evaluate the upstream coordination daemon for one shared Zova database #16
• Port applicable v0.10.2 installer, update, and uninstall fixes #18
• Port upstream allocator, memory-accounting, and Windows path fixes #20

Integrations and distribution

• Evaluate upstream agent integrations and generated tool-profile extensions #19
• Reconcile upstream build, CI, release, packaging, and security gates #21

Documentation and qualification

• Update fork documentation and compatibility matrix for v0.10.x adoption #22
• Run final v0.10.x adoption parity, performance, and platform qualification #23

Architecture decisions requiring explicit review

The following upstream changes must not be copied mechanically:

Coordination daemon

Upstream coordinates per-user clients and indexing through a daemon. Our evaluation must define how it owns or brokers one cbm.zova, authenticates clients, admits workspace writers, handles version/ABI mismatches, and interacts with Zova recovery and operations.

Delta-merge indexing

Upstream's SQLite delta-merge pipeline overlaps conceptually with Zova's native delta publication. Adopt useful extraction/planning improvements without reintroducing duplicate topology or bypassing Zova transactions.

Coverage system

Coverage state and missed-code data must be workspace-scoped inside the shared database and participate correctly in publication, deletion, export/import, health checks, and cross-repository selection.

CALL_REFERENCE

The new edge class must remain deterministic and survive native publication, edge-payload encoding, incremental replacement, traversal/query APIs, snapshots, integrity digests, and UI counts.

Store publication and recovery

Upstream's atomic SQLite publication cannot replace the fork's Zova transaction, generation, health, backup, and recovery model without a dedicated compatibility analysis.

Required PR evidence

Each adoption PR must include:

• Exact upstream source references.
• A short adaptation note explaining Zova-specific differences.
• Focused regression tests that fail without the change when practical.
• The affected Zova invariants and evidence that they remain intact.
• Any intentionally omitted upstream behavior and why.
• No unrelated formatting or refactoring churn.

Final acceptance gates

• All child issues are closed or explicitly rejected with rationale.
• Zova, incremental-native, operations/recovery, pipeline, MCP, Cypher, language, installer, and workflow suites pass.
• Cross-repository searches return correct owning projects and honor selected-project prefilters.
• Pure-SQLite comparison reports exact parity and zero unexpected fallbacks.
• TOPS and four-worker Deno benchmarks report full and incremental indexing, publication phases, storage, and vector p95.
• No unacceptable regression in traversal performance or full-index/storage targets.
• macOS, Linux, and Windows release artifacts pass build and smoke verification on amd64 and arm64.
• README, configuration, operations, and release notes describe the resulting behavior accurately.

Recommended dependency order

correctness, safety, and boundary ports (#7-#9, #15, #17, #20)
-> MCP protocol and output behavior (#5, #6)
-> language, installer, and agent surfaces (#10, #18, #19)
-> indexed semantic features and delta reconciliation (#11-#14)
-> daemon architecture decision (#16)
-> build/release reconciliation and documentation (#21, #22)
-> full qualification (#23)

References

• Upstream v0.10.0
• Upstream v0.10.1
• Upstream v0.10.2
• Upstream v0.9.0...v0.10.2 comparison