Buyer / interoperability gap
Protected main@83eba56149eb802cd63642c507c324c9976ec78e already pins the official Python MCP SDK mcp==2.0.0, but LineageWeave's executable MCP client/acceptance contract still hard-codes the handshake-era 2025-11-25 path: initialize / notifications/initialized, Mcp-Session-Id, and no server/discover or modern request path.
The official MCP 2026-07-28 specification is now current. It removes protocol-level handshake/session state, makes every request self-describing, introduces optional server/discover, and requires Mcp-Method / Mcp-Name routing headers over Streamable HTTP. The official Python SDK v2 supports 2026-07-28 and earlier revisions simultaneously from the same streamable_http_app(), so this does not require a LineageWeave-local protocol fork or removal of legacy compatibility.
This is an interoperability/operability gap, not a reason to copy MCP implementation or contextual-orchestrator functionality into LineageWeave.
Existing authority to preserve
- ADR 0218 owns the authenticated Global Ask MCP boundary and remains the product decision authority until a superseding Proposed ADR is reviewed.
submit_global_ask / read_global_ask_job must continue to delegate to the same durable application-service contract as REST; MCP must not compute a second answer.
- Keyverse OAuth audience/scope, exact Host/Origin admission, request-byte framing, Valkey per-principal quota, PostgreSQL evidence authorization, and contextual-orchestrator boundaries remain unchanged.
- The pinned official
mcp SDK is the protocol implementation owner. Do not hand-roll a second MCP parser/router where the released SDK already supports the current protocol.
- Legacy
2025-11-25 clients remain supported through the SDK's dual-era compatibility during the upstream deprecation window; do not break them merely to make the modern tests pass.
Realistic RED → GREEN acceptance
- RED current protected contract: a modern
2026-07-28 authenticated request to the existing MCP app is exercised without initialize / Mcp-Session-Id. The test must fail on the current LineageWeave client/acceptance assumptions rather than on an invented mock protocol.
- Add an explicit modern interoperability contract using the released SDK behavior:
server/discover succeeds where applicable; a direct tools/call request carries protocol/client/capability metadata and the required routing headers, and reaches the same durable Global Ask tools without transport session state.
- Preserve a separate legacy regression proving a
2025-11-25 client can still initialize, receive/use Mcp-Session-Id, and call the same tools. Do not conflate the two eras.
- Modern requests must not require sticky routing or a shared MCP session. Prove two sequential authenticated modern tool requests can be served without a transport session identifier and without loss of application-level ownership/authorization.
- Keep JSON-RPC response identity/protocol validation fail-closed in load/acceptance tooling. A response with the wrong/missing id, wrong protocol envelope, or both result/error must never be attributed to the current observation; response content remains absent from diagnostics.
- Keep Host/Origin/OAuth/body-admission/rate-limit order unchanged. Add modern-header allow/expose handling only where the official SDK/spec requires it; do not broaden CORS origins or authorization.
- Update
scripts/k6_mcp_e2e.js so load evidence can exercise the modern stateless path. Legacy-path k6 may remain as a separate explicitly named compatibility lane if useful; do not silently call the legacy handshake the current protocol.
- Measure authenticated modern MCP submit/read buyer-path latency with realistic PostgreSQL/Valkey/Keyverse dependencies. Record p95 and profile if an applicable synchronous boundary exceeds 20 ms; do not shrink samples or hide cold/error paths to meet the target. Multi-minute Global Ask orchestration remains asynchronous and outside transport latency.
- Update ADR/doctoring/ARCHITECTURE/OPERABILITY/TEST_STRATEGY and
docs/product-technical-gap-baseline.md with a code-current dual-era boundary. Keep the decision Proposed while unmerged and cite current authoritative MCP sources in APA 7th form.
- Exact-head tests/security/SAST/CodeQL, authenticated PostgreSQL acceptance, reproducible dependency lock, and qualifying independent review must be fresh before normal merge. No self-approval, gate weakening, force push, or predecessor evidence transfer.
Standards / released dependency evidence
Scope boundary
This issue owns current-protocol interoperability and transport acceptance only. It does not expand Global Ask semantics, add a LineageWeave-local LLM/provider path, replace Keyverse, duplicate canonical MCP SDK code, or absorb #269's separate browser/request-byte/rate-limit product slices. If implementation discovers an upstream SDK defect, reduce it to an owner-path reproduction and repair/upgrade the released dependency rather than forking protocol behavior locally.
Buyer / interoperability gap
Protected
main@83eba56149eb802cd63642c507c324c9976ec78ealready pins the official Python MCP SDKmcp==2.0.0, but LineageWeave's executable MCP client/acceptance contract still hard-codes the handshake-era2025-11-25path:initialize/notifications/initialized,Mcp-Session-Id, and noserver/discoveror modern request path.The official MCP
2026-07-28specification is now current. It removes protocol-level handshake/session state, makes every request self-describing, introduces optionalserver/discover, and requiresMcp-Method/Mcp-Namerouting headers over Streamable HTTP. The official Python SDK v2 supports2026-07-28and earlier revisions simultaneously from the samestreamable_http_app(), so this does not require a LineageWeave-local protocol fork or removal of legacy compatibility.This is an interoperability/operability gap, not a reason to copy MCP implementation or contextual-orchestrator functionality into LineageWeave.
Existing authority to preserve
submit_global_ask/read_global_ask_jobmust continue to delegate to the same durable application-service contract as REST; MCP must not compute a second answer.mcpSDK is the protocol implementation owner. Do not hand-roll a second MCP parser/router where the released SDK already supports the current protocol.2025-11-25clients remain supported through the SDK's dual-era compatibility during the upstream deprecation window; do not break them merely to make the modern tests pass.Realistic RED → GREEN acceptance
2026-07-28authenticated request to the existing MCP app is exercised withoutinitialize/Mcp-Session-Id. The test must fail on the current LineageWeave client/acceptance assumptions rather than on an invented mock protocol.server/discoversucceeds where applicable; a directtools/callrequest carries protocol/client/capability metadata and the required routing headers, and reaches the same durable Global Ask tools without transport session state.2025-11-25client can still initialize, receive/useMcp-Session-Id, and call the same tools. Do not conflate the two eras.scripts/k6_mcp_e2e.jsso load evidence can exercise the modern stateless path. Legacy-path k6 may remain as a separate explicitly named compatibility lane if useful; do not silently call the legacy handshake the current protocol.docs/product-technical-gap-baseline.mdwith a code-current dual-era boundary. Keep the decisionProposedwhile unmerged and cite current authoritative MCP sources in APA 7th form.Standards / released dependency evidence
mcp==2.0.0was released 2026-07-28 as the stable v2 line and explicitly supports the 2026-07-28 specification and every earlier revision.Scope boundary
This issue owns current-protocol interoperability and transport acceptance only. It does not expand Global Ask semantics, add a LineageWeave-local LLM/provider path, replace Keyverse, duplicate canonical MCP SDK code, or absorb #269's separate browser/request-byte/rate-limit product slices. If implementation discovers an upstream SDK defect, reduce it to an owner-path reproduction and repair/upgrade the released dependency rather than forking protocol behavior locally.