md/design/mcp-federation.md:45 and md/playbooks/building-on-ione.md:32 both describe IONe exposing an aggregated slice:// to MCP clients.
It does not exist. src/mcp_server.rs advertises only whoami:// in resources/list and returns JSON-RPC -32602 for every other URI. slice:// is peer→IONe only: IONe consumes a peer's slice (federation.rs::fetch_slice) and never serves one.
This was found while freezing contract v1 (PR #23). The frozen contract records the divergence in Appendix A and the behaviour is pinned by contract_v1_integration::ione_advertises_only_whoami_and_does_not_serve_slice, so the contract is accurate — but the two design docs still promise the capability.
Decide one of
A. Correct the docs. Cheapest, and matches five years of actual behaviour. slice:// is a peer surface; IONe consuming it is the whole design.
B. Build it. An aggregated slice over a workspace's bound peers is a coherent feature — it is what would let an MCP client treat an IONe workspace as a single context source rather than enumerating peers. If this is wanted, it needs its own design: what it aggregates, how it bounds size (see the MAX_SLICE_BYTES truncation issue), and whether it is workspace-scoped or peer-global.
Recommend A unless there is a client that actually wants it — nothing in the repo consumes it today.
Context: PR #23.
md/design/mcp-federation.md:45andmd/playbooks/building-on-ione.md:32both describe IONe exposing an aggregatedslice://to MCP clients.It does not exist.
src/mcp_server.rsadvertises onlywhoami://inresources/listand returns JSON-RPC-32602for every other URI.slice://is peer→IONe only: IONe consumes a peer's slice (federation.rs::fetch_slice) and never serves one.This was found while freezing contract v1 (PR #23). The frozen contract records the divergence in Appendix A and the behaviour is pinned by
contract_v1_integration::ione_advertises_only_whoami_and_does_not_serve_slice, so the contract is accurate — but the two design docs still promise the capability.Decide one of
A. Correct the docs. Cheapest, and matches five years of actual behaviour.
slice://is a peer surface; IONe consuming it is the whole design.B. Build it. An aggregated slice over a workspace's bound peers is a coherent feature — it is what would let an MCP client treat an IONe workspace as a single context source rather than enumerating peers. If this is wanted, it needs its own design: what it aggregates, how it bounds size (see the
MAX_SLICE_BYTEStruncation issue), and whether it is workspace-scoped or peer-global.Recommend A unless there is a client that actually wants it — nothing in the repo consumes it today.
Context: PR #23.