# Dashboard discovery through Core API ingress

Dashboard serves the canonical public discovery URLs. Its server-side proxy
fetches Core aliases under `/api/discovery/`, so these documents work when the
Core ingress forwards `/api/*` but handles root-level paths elsewhere.

| Public Dashboard path | Core upstream path |
| --- | --- |
| `/.well-known/api-catalog` | `/api/discovery/api-catalog` |
| `/auth.md` | `/api/discovery/auth.md` |
| `/.well-known/oauth-authorization-server` | `/api/discovery/oauth-authorization-server` |
| `/.well-known/agent-card.json` | `/api/discovery/agent-card.json` |
| `/openapi.json` | `/api/discovery/public-openapi.json` |
| `/health` | `/api/discovery/health` |

Deploy Core before Dashboard. No database migration or new environment variable
is required by this routing change. Keep the Dashboard backend base URL unchanged;
do not append `/api` to it because existing API requests already include that prefix.
The existing ingress must forward `/api/discovery/*` to FastAPI without stripping
`/api`. If its allowlist is more restrictive, add this specific prefix.

OAuth and A2A metadata aliases preserve the existing Core feature flag and proxy
secret requirements. A JSON 404 from these aliases can indicate disabled agent
access or a mismatched proxy secret. An HTML web-server 404 indicates that routing
to FastAPI still needs investigation. Do not remove the guards to resolve a 404.

After both deployments, check the public Dashboard paths above and follow the
marketing site's catalog redirect. Expect JSON for the catalog and OAuth metadata,
Markdown for auth.md, and successful HEAD responses. Verify the OAuth issuer is
the Dashboard origin and the metadata contains no private upstream hostname or
`/api/discovery/` paths. Then rescan Cloudflare diagnostics.

An enabled MCP health response only describes the MCP Worker; it does not verify
Dashboard discovery, OAuth, or Core connectivity. Verify a real client connection
separately after discovery succeeds.