generated from coulomb/repo-seed
tegwick
52f312bf8e
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>
64 lines
2.7 KiB
Markdown
64 lines
2.7 KiB
Markdown
# 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.
|