spike: local HTTP/server mode (evaluation only)

[ernestprovo23]

Evaluate a local HTTP/server mode for convenience.

Hard boundary: must NOT become a hosted token path or violate the no-middleman non-goal. This is a spike to decide go/no-go, not a commitment to build.

Source: docs/PRODUCT_DESIGN_DOCUMENT.md §9 #6 (under evaluation).

[ernestprovo23]

spike outcome: recommend no-go on an http server, and instead consider a thin stdio MCP server if we want programmatic / cross-process access.

reasoning:

• localhost bind is not "safe by default". a 127.0.0.1 http endpoint is still reachable by dns-rebinding / csrf from any browser tab and by every other local process/user. defending it properly (origin checks, anti-csrf, maybe a local token) drags us toward the key-manager / proxy complexity that §8 explicitly rules out.
• §8 says we compete by being small. a web framework or http.server lifecycle + a port + a daemon to babysit is the opposite of that.
• in-process python is already fully covered by the library api (from conclave import Council). the only genuine gap is cross-language / cross-process local access.
• a stdio MCP server fills that gap with zero network bind (no socket, no localhost attack surface), matches the mcp-warden sibling story, and frames the council as a tool. peer llm-council-core shipped mcp + http; the mcp half is the part worth copying.

net: the convenience is real but http is the wrong shape. library for in-process, mcp-over-stdio for everything else, no socket opened, all of §8 (no-middleman, no-proxy, small) stays intact.

proposed disposition: close #8 as evaluated (no-go on http). if there's appetite, open a separate scoped issue for an optional stdio MCP server. leaving the call to the maintainer.