# ihp-railiance-probe — Intent

## Purpose

`ihp-railiance-probe` is a minimal, test-first IHP application whose sole purpose
is to **validate the complete build-to-deployment pipeline** for IHP-on-Railiance
before any production workload runs through it.

It is a *probe* — not a product. Every decision favours diagnostic speed over
feature richness.

## Why it exists

Building `inter-hub` revealed two classes of expensive problems:

1. **Build-time surprises** — GHC 9.10.3 bugs (oversized `.hi` files, truncated
   static archives) that only manifest in production (`nix build .#docker`), not
   in the development GHCi loop. Debugging these inside a 477-module codebase
   cost many build cycles and hours of iteration.

2. **Pipeline unknowns** — The full chain (haskelseed build → Gitea registry push
   → Railiance01 Kubernetes deployment) had never been exercised end-to-end in a
   clean, reproducible way before inter-hub attempted production.

A minimal probe surfaces both problem classes on a trivially small codebase where
failures are cheap to diagnose and fix.

## Success criteria

The probe is *complete* when all of the following hold without manual intervention:

| # | Check | Verified by |
|---|-------|-------------|
| 1 | `nix build .#docker` succeeds on haskelseed | Zero-error build log |
| 2 | OCI image pushed to `92.205.130.254:32166/coulomb/ihp-railiance-probe:SHA` | `skopeo inspect` |
| 3 | Helm chart deploys pod to Railiance01 | `kubectl get pods` — Running |
| 4 | Health endpoint responds | `curl /healthz` → 200 |
| 5 | At least one Hspec integration test passes in CI | `test` command green |

## Design constraints

- **Minimal schema**: one table (`probes`) with `id`, `name`, `created_at`.
  Enough to exercise the IHP code-gen path without generating hundreds of modules.
- **Test-first**: every controller action has a corresponding Hspec test before
  it is implemented.
- **Diagnostic-first flake**: `flake.nix` starts from the hard-won inter-hub
  overlay (ActualTypes.hi fix, haskelseed resource limits) so GHC 9.10.3 quirks
  are handled from day one.
- **No application logic**: the probe is a canary. Application features belong
  in inter-hub or its successors.

## Relationship to inter-hub

`ihp-railiance-probe` is upstream in confidence, not in code. A successful probe
means:

- The Nix/GHC/cabal production build is healthy for the current flake lock.
- The Gitea registry + Railiance01 deployment chain is operational.
- A new IHP project can be promoted to production without the build archaeology
  that inter-hub required.

Once the pipeline is validated, the probe continues to serve as a **regression
canary**: rebuild it whenever the flake lock is updated before touching inter-hub.