plane-app-admin backend doesn't handle /god-mode without trailing slash as sent by the Get started button

Summary

When following the README's documented "Custom Ingress Routes" pattern (routing /god-mode/, /spaces/, /live/ etc. to their respective backend services), requests to these paths without a trailing slash don't 404 or redirect — they silently return the main landing page's content with a 200, because the frontend's own in-app links to these routes omit the trailing slash.

Environment: K3s, Traefik ingress controller, standard networking.k8s.io/v1 Ingress (chart's own ingress: templates disabled, custom Ingress written per the README's routing table).

Details

Per the README, /god-mode/, /spaces/, and /live/ route to the plane-app-admin, plane-app-space, and plane-app-live services respectively — separate Next.js apps from the main plane-app-web frontend.

The frontend's own in-app link to these routes (e.g. the "Get Started" button shown on first load, which links to /god-mode) omits the trailing slash. When that bare path is requested:

• With pathType: Prefix on the Ingress rule, Traefik correctly forwards the request to the plane-app-admin backend.
• That backend doesn't have a route/static asset at the exact bare path (only at /god-mode/), and instead of a 404 or redirect, it returns a 200 with content identical to the main landing page (plane-app-web's /).

Reproduction

curl -s https://<host>/god-mode  | md5sum   # identical hash to below
curl -s https://<host>/          | md5sum   # landing page

curl -s https://<host>/god-mode/ | md5sum   # different hash — correct admin content

Impact

Clicking "Get Started" from the landing page silently fails — the browser loads what looks like the same landing page again, with no visible error apart from a couple of minified React hydration errors (#418/#423) in the console (presumably from the mismatched content being hydrated against route state that expected the admin app). Since this is triggered by the frontend's own generated link (not a manually-typed URL), this will affect any self-hoster following the documented custom-Ingress pattern, not just unusual setups — anyone landing on a fresh instance hits this on their very first click.

Workaround we used

Added a Traefik redirectRegex Middleware to force a trailing slash onto /god-mode, /spaces, and /live before the request reaches the backend.

Suggested fix

Either:
(a) the chart ships this redirect Middleware itself as part of its templates when custom-Ingress values are used, or
(b) the affected Next.js apps (admin, space, live) handle the no-trailing-slash case themselves (redirect or correct route match) rather than falling back to serving unrelated content with a 200.

Given the frontend's own generated links omit the trailing slash, (b) feels like the more robust long-term fix, but (a) would be a smaller, chart-only change if that's preferred.

Start with the README's Custom Ingress Routes table and the chart's ingress templates, then reproduce the behavior with the three curl requests for /god-mode, /god-mode/, and /. Trace how the admin, space, and live services handle the bare paths. Done means the documented routing and the frontend's generated links reach the intended app without serving the landing page incorrectly.