railiance-apps/workplans/archived/260702-RAPPS-WP-0007-service-landing-pages.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
RAPPS-WP-0007	workplan	Add friendly landing pages for S5 service endpoints	financials	railiance-apps	finished	codex	railiance	2026-06-15	2026-06-15	c6c20379-dc1a-504f-b2a8-e2b11b41d75a

Terminology note: Historical text in this archived workplan may use the legacy term "workstream". The fleet term is workplan (canon/standards/workplan-terminology-fleet_v0.1.md).

Add friendly landing pages for S5 service endpoints

Create a small, reusable landing-page pattern for public S5 application endpoints. The page should give humans a clear next step without changing the machine-facing API contract:

• UI-backed applications may show a friendly page with a short redirect notice and a visible Continue button to the correct login or application route.
• API-only services should show a proper no-login informational page at /, with links to health/status/runbook documentation where appropriate.

First rollout target: https://reuse.coulomb.social, which hosts the reuse-surface federation API and intentionally has no browser login UI.

Current Context

RAILIANCE-WP-0007 deployed the reuse-surface Helm release and runbook for reuse.coulomb.social. The release is useful to machines and operators, but a human visiting / should not be left with an API-shaped response or a dead end.

The implementation must preserve the existing CLI/API surface:

• /health remains suitable for Kubernetes probes and external smoke checks.
• /v1/* API routes continue to reach the reuse-surface service.
• Authenticated federation operations continue to use REUSE_SURFACE_TOKEN and must not expose token material in the landing page, chart values, or logs.

Design Constraints

• Keep the page static and non-secret.
• Prefer explicit Ingress path routing over changing API semantics when a service has no upstream web UI.
• Use exact / routing for the landing page when possible, so API prefixes are unaffected.
• Add noindex metadata for operator/service landing pages that are not meant to be public marketing surfaces.
• Keep the pattern reusable for later services with login destinations.

---

Define Landing Page Contract

id: RAPPS-WP-0007-T01
status: done
priority: high
state_hub_task_id: "78d7e19b-e960-5d4a-b4d4-1815e008d58a"

Document the endpoint contract in docs/s5-app-onboarding-checklist.md or a small companion doc:

• API-only service: static informational page at /, no login claim, no token hints, links to health/status and operator runbook.
• UI-backed service: landing page may auto-forward after a short delay and must include a visible button to the canonical login/application route.
• All variants must preserve health, API, OAuth callback, and asset paths.

Done when future S5 app workplans can cite a single landing-page rule instead of rediscovering the behavior per service.

Add Reusable Helm Support

id: RAPPS-WP-0007-T02
status: done
priority: high
state_hub_task_id: "54cbb267-0274-598b-9ecd-8c78e3dd5ac0"

Add a reusable Helm pattern for a static landing page, either as shared snippets or as chart-local templates following one documented convention. The pattern should support:

• enable/disable flag in values;
• static HTML content from a ConfigMap;
• a lightweight static HTTP container or equivalent service;
• exact / Ingress path to the landing service;
• prefix routes for API and app paths to the existing backend;
• optional redirect target and button label for UI-backed applications.

Done when helm template can render both disabled and enabled landing-page variants without changing non-landing deployments.

Implement API-Only Landing Page For reuse.coulomb.social

id: RAPPS-WP-0007-T03
status: done
priority: high
state_hub_task_id: "ab182b68-bffa-5411-b2a2-3ab06fd73994"

Enable the landing-page pattern in charts/reuse-surface and helm/reuse-surface-values.yaml for reuse.coulomb.social.

Content should make clear that this endpoint is the Railiance REUSE capability federation service, not a login application. Include non-secret operator links or text for:

• service purpose;
• /health;
• /v1/federated;
• docs/reuse-surface-on-railiance01.md;
• noindex metadata.

Done when a browser request to / receives the landing page while /health and /v1/federated still reach the API service.

Add Login-Forward Variant For UI Applications

id: RAPPS-WP-0007-T04
status: done
priority: medium
state_hub_task_id: "72c64573-5954-55f7-b98f-0ce316d1d0fd"

Prepare the values contract and at least one documented example for services that do have a browser UI. The page should explain that the user is being sent to the application and include a visible button to the configured login or application route.

Done when a future UI-backed app can set only values such as redirectTarget, buttonLabel, and explanatory copy, without editing templates.

Verify, Deploy, And Update Runbook

id: RAPPS-WP-0007-T05
status: done
priority: medium
state_hub_task_id: "3fd5195c-4717-529d-ba29-4ae1a0cecbe8"

Render, deploy, and smoke-test the reuse landing page on railiance01:

• make reuse-dry-run;
• deploy with pinned image and non-secret landing values;
• verify /, /health, and /v1/federated over the public hostname;
• confirm no secret values appear in manifests or rendered HTML;
• update docs/reuse-surface-on-railiance01.md with the landing-page behavior and rollback notes.

Done when the public browser experience is friendly and the existing machine-facing API checks still pass.

Completed 2026-06-15: deployed Helm revision 5 to namespace reuse. reuse-surface-landing is Running, HTTP / redirects to HTTPS, HTTPS / returns 200 text/html, /health returns 200 application/json, /v1/federated returns 200 application/json with 12 capabilities, and the fetched landing page contains no token references. Follow-up fix separated the API and landing Service selectors with app.kubernetes.io/component labels and changed ingress routing to explicit API paths (/health, /v1) plus landing fallback /.