Known limitations in v1.1.0¶

v1.1.0 is the first release with deployment tooling. A few rough edges are documented here so you know what to expect — and which of them are fixed in the next release (v1.1.1, K8s + Helm + image registry).

`/api` route returns 404¶

The frontend's vite.config.ts proxies both /ws AND /api to port 8765. The /ws route works (it's the WebSocket bridge). The /api route is reserved-but-unimplemented — there is no HTTP REST endpoint on the backend yet.

The nginx config explicitly returns a JSON 404 with a documented error message instead of proxying to a dead route:

{"error":"reserved","message":"REST API is reserved for v1.2.0+. WebSocket events at /ws."}

The React app degrades gracefully when /api/* returns 404 — pages that were going to fetch REST data show a "no data" placeholder instead of crashing. Real REST endpoints land in v1.2.0+.

MCP server is experimental¶

The fcc protocol mcp-server CLI command exists but in non-fallback mode it just prints tool/resource/prompt counts and exits — it does NOT start a long-running server. The fallback stdio mode (--fallback) does run, but stdio doesn't work cleanly inside containers without stdin attachment.

For v1.1.0:

The MCP server is not part of the default make docker-up stack
Treat fcc protocol mcp-server as experimental
Real MCP server containerization comes with the K8s/Helm work in v1.1.1

A2A server is a stub¶

fcc protocol a2a-server accepts a --port argument but its implementation just echoes "Not yet implemented — requires HTTP server setup". This is documented in the CLI help text. A2A server work is expected in v1.1.1 alongside the K8s/Helm push.

No image registry push¶

CI builds all four images on every PR but does NOT push them anywhere. You build locally with make docker-build and run via Compose.

Why: v1.1.0's deliberate scope is "build-only Docker." Image publishing to ghcr.io lands in v1.1.1 paired with the Helm chart so helm install works on first try (a Helm chart without pullable images is broken — you'd get ImagePullBackOff immediately).

If you need to push images yourself in the meantime:

docker tag fcc-backend:dev registry.example.com/fcc-backend:v1.1.0
docker push registry.example.com/fcc-backend:v1.1.0

For offline distribution:

docker save -o fcc-backend-v1.1.0.tar fcc-backend:dev
docker load -i fcc-backend-v1.1.0.tar

No Kubernetes manifests or Helm chart¶

K8s manifests and Helm chart land in v1.1.1 alongside image registry push. v1.1.0's deployment story is intentionally Docker + Compose only.

If you need K8s today, you can write your own manifests using the v1.1.0 Dockerfiles as a starting point. The container interface is stable — v1.1.1 will add Helm without breaking standalone Docker usage.

No automatic provider probing¶

Plugin providers (Ollama, LiteLLM) only auto-detect when their hint env var is explicitly set:

Provider	Triggered by
`ollama`	`OLLAMA_BASE_URL` set
`litellm`	`LITELLM_DEFAULT_MODEL` set

This is by design — see the provider matrix for the rationale.

Linux-only `host.docker.internal`¶

The Ollama walkthrough recommends OLLAMA_BASE_URL=http://host.docker.internal:11434/v1 inside containers. This DNS name resolves automatically on Docker Desktop (Mac/Windows) and recent Docker Engine on Linux, but older Docker Engine versions don't have it. Use the host's LAN IP as a fallback.