This endpoint table lists GET /graph and GET /viz, but those routes do not exist in the current daemon (main.py has /mcp, /health, /search, /context, /memory, /stats, /flush, /reload, /backup, /mine, /silent-save, /repair, /repair/status). Please correct the table (and any downstream references) so the doc matches the implemented API, or explicitly label these as proposed endpoints.

Stale finding — the current doc no longer lists /graph or /viz in the endpoint table. Line 49 says wings/rooms/halls are surfaced by MCP tools (mempalace_list_wings / mempalace_list_rooms / mempalace_list_tunnels), and the endpoint table at lines 63-76 covers only routes that actually exist. The aspirational refs were dropped in a later commit; sorry for not closing the loop sooner.

POST /reload is described as an alias for /repair mode=light, but in code it only clears the client/collection caches and does not participate in the /repair state machine (e.g., no repair locking/state, no quarantine_stale_hnsw note/warning behavior). Consider rewording this to "similar to" / "overlaps with" mode=light, or have /reload delegate to the same implementation if true aliasing is intended.

Fair — "alias" oversimplifies. Both routes DO clear the client/collection cache (the only thing /reload does, and what /repair?mode=light boils down to via flush_palace), but the alias framing implies they share state-machine semantics, which they don't. Will soften to: "Invalidate cached view handles. Same effect as /repair?mode=light from the perspective of cache state, though it doesn't enter the repair state machine."

This section claims the view-coordinator role will keep the same client contract for /graph, but /graph is not currently an implemented endpoint in this repo. Please update the list of "stays the same" endpoints to the ones that actually exist (e.g. /mcp, /silent-save, /search, /stats, /repair, etc.) or annotate /graph as future work.

Resolved by the doc reorganization — the current line 100 is in the "Stays the same" bullet about queue-and-drain. The "client contract" sentence in the current text talks about the role itself (HTTP/MCP API surface), not a specific endpoint. No /graph claim in the current doc.

The "structural fast paths" bullet cites a /graph direct-sqlite read as an existing example, but /graph is not present in the daemon codebase. Please adjust this example to a real endpoint/fast-path, or rephrase it as a potential future optimization under postgres.

Current line 125-127 phrases this generically: "Optional structural fast paths for consumers (e.g. composing a single snapshot across wings + KG + tunnels in one HTTP roundtrip rather than forcing each adapter to fan out across multiple MCP calls). Under chroma the fast path can read the underlying sqlite directly; under postgres it'd be a direct-postgres aggregation query." No longer cites /graph by name. Worth flagging that #13 has since landed an actual GET /graph endpoint that materializes this exact pattern — could be a one-line cross-ref in a follow-up.

Minor terminology/casing: the graph query language is typically capitalized as "Cypher" (not "cypher"). Consider updating for correctness/consistency, especially since it's used as a proper name alongside "Apache AGE" and "Postgres".

Already "Cypher" in the current doc (line 143: "(Cypher on postgres) would be the natural view technology"). Closed via earlier commit; sorry for not closing the comment loop.

The doc references palace-daemon's /graph endpoint as the way wings/rooms/halls are surfaced, but this repo's daemon currently does not implement a /graph route (endpoints are defined in main.py and include e.g. /stats, /repair, /mcp, etc.). Please update this row to reflect the actual API surface or clearly mark /graph as a future/planned endpoint.

Same as the line-49 finding above — the current line says wings/rooms/halls are surfaced by mempalace_list_* MCP tools, not /graph. The earlier draft DID reference /graph as aspirational; removed during revision. With #13 in flight, a one-line cross-ref to the actual endpoint would be reasonable in a follow-up commit.