INTENT.md captures why the probe exists (validate build-to-deploy before inter-hub attempts production again) and its success criteria. DeploymentBlueprint.md is a textual C4 deployment diagram covering all four nodes: workstation, haskelseed, CoulombCore/Gitea, and Railiance01/k3s, plus the full artifact flow and known infrastructure constraints. IRP-WP-0001 is a 12-task workplan: flake bootstrap → minimal IHP scaffold → schema → health endpoint → Hspec test → production build → push → Helm chart → k3s registry config → deploy → smoke test → optional CI. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2.7 KiB
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:
-
Build-time surprises — GHC 9.10.3 bugs (oversized
.hifiles, 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. -
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) withid,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.nixstarts 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.