Splash screen: embed the real upstream response (hidden) so it's visible in dev tools

[ClaydeCode]

Problem

shard_core renders a splash screen in place of an app's actual response (for every app). When an app returns an error or a non-OK status, the real response body — e.g. a FastAPI 422 {"detail":[...]} — is replaced by the splash HTML and lost. This makes debugging app/API errors from the client impossible: you only ever see the splash.

Scoping the splash off by path prefix (e.g. only wrap non-/api) is not viable — apps don't all use an /api prefix, and the splash is applied uniformly.

Desired behavior

Keep the user-facing splash as-is, but embed the original upstream response in the splash HTML, visually hidden, so a developer can read it via browser dev tools / view-source / the raw HTTP body. Options:

• A hidden element, e.g. <script type="application/json" id="upstream-response">…</script> or <div hidden data-upstream>…</div>.
• Include at least: original status code and response body (and ideally Content-Type).
• HTML-escape / encode the embedded body so it can't break the page or inject.

Acceptance

• Rendered splash looks unchanged to end users.
• The raw HTML of the splash contains the original status + response body in a hidden element, readable via dev tools.
• Works regardless of the app's URL scheme (no /api assumption).

Context

Surfaced while debugging a controller 422 (POST /api/shards/{id}/core_update) — the FastAPI validation detail was swallowed by the splash. Supersedes the misfiled FreeshardBase/freeshard-controller#266 (wrong repo + wrong approach). Related: FreeshardBase/freeshard-controller#267.

[ClaydeCode]

I've implemented the fix in PR #92.

Approach: Traefik's errors middleware discards the original response body before calling the error handler — there's no way to get it without routing through shard_core. The fix inserts shard_core as an internal reverse proxy between Traefik and app containers.

What changed:

• New /internal/app_proxy/{path:path} endpoint proxies requests to app containers via httpx, captures the full response, and — for 4xx/5xx — renders the splash with the upstream body embedded in a hidden <script type="application/json" id="upstream-response"> element
• Traefik app routers now point to shard_core (with a new app-proxy-prefix addPrefix middleware) rather than directly to each app container; the old app-error error-page middleware is no longer used for app traffic
• Success responses (2xx/3xx) are passed through unchanged; connection errors show the splash without upstream data (container still starting)
• </script> in the body is escaped to <\/script> to prevent injection

Acceptance criteria: ✅ splash appearance unchanged for users; ✅ raw HTML contains the upstream status + body in the hidden element readable via dev tools; ✅ no path-prefix assumption.

[ClaydeCode]

Implemented fix for #91 by adding an internal reverse proxy (app_proxy) in shard_core that sits between Traefik and app containers. Since Traefik's errors middleware discards the original response body, the fix routes app traffic through shard_core's new /internal/app_proxy/{path:path} endpoint instead of directly to containers. For 4xx/5xx responses the proxy captures the full upstream body and embeds it as a hidden <script type="application/json" id="upstream-response"> element in the splash HTML (with </script> sequences escaped for safety). Success responses pass through unchanged. Traefik config updated with a new app-proxy-prefix addPrefix middleware and app routers changed to use shard_core as the service. Added build_upstream_json() helper, make_splash_behaviour_for_proxy(), updated SplashBehaviour model, and a new test file with unit and integration tests. Opened PR #92.

[ClaydeCode]

I've completed my analysis and posted a clarifying response rather than blindly reworking the code, because the review feedback conflicts with a hard technical constraint.

What I found: The maintainer asked to drop the proxy and "just extend the app_error endpoint with the upstream json." But Traefik's errors middleware discards the app's response body — it only forwards a fresh copy of the original request to /internal/app_error/{status}. So the app_error endpoint can see the statu