PR #299 ↔ #304 merge assessment

Evaluation of the changes required to wesm/msgvault#299 ("feat: add --http flag to mcp command for StreamableHTTP transport") once wesm/msgvault#304 (identities-collections-dedup) is merged into upstream main.

Conflict surface (mechanical)

Zero file overlap. Zero textual conflicts. Truly orthogonal.

File	PR299	#304	Overlap?
cmd/msgvault/cmd/mcp.go	adds --http flag, branches to ServeHTTPWithOptions	untouched	No
cmd/msgvault/cmd/mcp_test.go	new file	untouched	No
internal/mcp/server.go	extracts newMCPServer(opts), adds ServeHTTPWithOptions	untouched	No
internal/mcp/server_test.go	new test cases	untouched	No

#304 modifies internal/mcp/handlers.go (the per-tool MCP handler functions), but not server.go, not mcp.go, and not the test files PR299 touches. The two PRs are working on entirely disjoint files.

Semantic interactions to verify

1. Read-only store in MCP path (already correct)

cmd/msgvault/cmd/mcp.go opens the store via store.OpenReadOnly(dbPath) and explicitly does not call runStartupMigrations. This is by design — MCP is a query-only workload, and the existing s.SchemaStale() check tells the user to run init-db first if migrations haven't been applied. #304 does not change this contract — it only adds new tables/indexes that fall under the same staleness check via SchemaStale.

After #304 lands, an MCP client connecting to a not-yet-migrated database will get the same "database schema is outdated; run 'msgvault init-db' to update" error message. PR299's --http transport inherits this behavior unchanged. No action needed.

2. New scope-aware MCP tools (no interaction)

#304 adds collections, account-identities, scope semantics across CLI commands. The MCP tool surface that gets new behavior is in internal/mcp/handlers.go (e.g. searchMessages migrating from q.AccountID to q.AccountIDs, stageDeletion next-step hint referencing MSGVAULT_ENABLE_REMOTE_DELETE=1). PR299 doesn't touch any of those handlers; it only changes the transport layer. The new behavior is independent of stdio vs HTTP. No action needed.

3. Concurrent client safety on HTTP transport (informational)

PR299's stated motivation includes "multiple MCP clients ... share a single archive." Once #304 lands and dedup operations become possible, a concurrent HTTP MCP client could theoretically observe mid-dedup state (some messages visible, some hidden, depending on transaction ordering). #304's LiveMessagesWhere predicate is applied per-query, so each individual MCP request sees a consistent point-in-time view via the SQLite snapshot — but a long-lived HTTP session that issues two queries straddling a deduplicate run will see different counts.

This is the same correctness model as the existing REST serve API, which #304 already operates against. PR299's HTTP MCP transport doesn't introduce a new concurrency hazard beyond what serve already exposes. No action needed, but worth a sentence in PR299's release note acknowledging that read-after-write across MCP requests is per-query-consistent, not session-consistent.

4. Vector / hybrid backend wiring (already correct)

PR299's PR description specifically calls out: "Vector/hybrid options propagate the same way they do for stdio." #304 adds internal/vector/sqlitevec/backend.go changes for live-message filtering, but those are inside the vector backend; the way ServeOptions plumbs vector config from CLI to newMCPServer is unchanged. No action needed.

5. systemd / deployment (orthogonal)

PR299's systemd example and Tailscale deployment narrative are entirely about transport — no interaction with #304's identity/dedup work.

Resolution recipe (when #299 rebases onto post-#304 main)

1. git rebase origin/main — should apply with literally zero hunks even touched. PR299's files are untouched on #304.
2. Run make test. Both PR299's new tests (mcp_test.go and the new server_test.go cases) and #304's new tests should pass.
3. Optional sentence in PR299's release note: "MCP requests are per-query-consistent against the underlying SQLite snapshot. Long-lived HTTP MCP sessions that span dedup operations may observe message-count changes between requests, identical to the behavior of the existing REST serve API."

Verdict

Cleanest merge in the queue. Zero file overlap, zero textual conflicts, zero semantic interactions that require code changes. PR299 and #304 are working on completely different layers: PR299 is transport (stdio vs StreamableHTTP), #304 is data model (identity, scope, dedup). They cannot conflict.

Total fix surface after rebase: 0 lines required. Recommend landing PR299 first or independently — it is risk-free relative to #304.