fix: cluster tools

.claude/skills/backend-seeding/SKILL.md

@@ -5,8 +5,8 @@ description:
   or changing hackathons, users, projects, teams, submissions, phases and votes
   through the in-process gRPC harness, the step helpers in steps.go,
   capabilities that must be on when they are used, synthetic users who cannot
-  log in, idempotency and re-seeding (locally and on the dev cluster), and how
-  to verify a change without wiping local state. Use when asked to add or change
+  log in, idempotency and re-seeding (locally and on dev or staging), and how to
+  verify a change without wiping local state. Use when asked to add or change
   dev/test data, make a scenario reproducible locally, pick which seeded
   hackathon to test something in, or fix a seeded hackathon nobody can act in.
 ---
@@ -151,9 +151,12 @@ To use the new fixture locally for real: `just clean::state && just start`,
 policy before the seed wrote any, and until it restarts, owners are refused
 their own hackathons.
 
-On the dev cluster, `just cluster::reseed <context>` backs up, wipes the app
-database, seeds from your checkout and restarts the backend. It refuses unless
-`components/backend` matches `origin/main`, so it runs after merging.
+On the deployed instances, `just cluster::reseed dev` or
+`just cluster::reseed staging` backs up, wipes the app database, seeds and
+restarts the backend. The seed is built from the code the instance serves —
+`origin/main` for dev, the newest `origin/release/*` for staging — not from your
+checkout, so a seed change reaches dev only after merging and staging only once
+it is on a release branch.
 
 ## After changing the seed
 

CLAUDE.md

@@ -113,10 +113,10 @@ just helm::template [args]      # render the chart to stdout
 just helm::check-bump           # fail if helm-chart/ changed without a version bump
 just helm::publish              # push the chart if Chart.yaml's version is unpublished
 
-# Deployed dev instance only — takes the kube context, refuses any other cluster
-just cluster::backup <context>  # pg_dumpall to ~/hackagon-backups
-just cluster::wipe <context>    # backup, then drop + recreate the app DB; dev restarts empty
-just cluster::reseed <context>  # backup, wipe, then seed; refuses if components/backend differs from origin/main
+# Deployed dev or staging only — set HACKAGON_KUBECONFIG to the cluster's kubeconfig first
+just cluster::backup <dev|staging>  # pg_dumpall to ~/hackagon-backups
+just cluster::wipe <dev|staging>    # backup, then drop + recreate the app DB; the instance restarts empty
+just cluster::reseed <dev|staging>  # backup, wipe, then seed built from origin/main (dev) or the newest origin/release/* (staging)
 ```
 
 Backend listens on **:3000**, frontend on **:8081**. Dev users (Keycloak
@@ -169,10 +169,12 @@ These hold across the whole codebase; the skills explain the mechanisms.
   focused pull request per change, each carrying its manually added
   `CHANGELOG.md` entry. Each released minor line has a `release/X.Y` branch that
   takes hotfixes only, released from its own tags and cherry-picked back to
-  `main`. Both clusters install the same chart from the GitOps setup in
-  `sdsc-ordes/cloud-infra` and differ only in image overrides: **dev** runs
-  `temporary/*:latest` with `pullPolicy: Always`, so every push to `main`
-  reaches it on the next container restart; **prod** takes the chart defaults,
+  `main`. All three instances install the same chart from the GitOps setup in
+  `sdsc-ordes/cloud-infra` and differ only in image overrides: **dev**
+  (namespace `hackagon-dev`) runs `temporary/*:latest` with
+  `pullPolicy: Always`, so every push to `main` reaches it on the next container
+  restart; **staging** (namespace `hackagon-staging`, same cluster as dev) runs
+  the latest release, hotfixes included; **prod** takes the chart defaults,
   `release/*` at `appVersion`, so nothing merged can reach it until someone
   bumps `appVersion` and installs the new chart version. See `RELEASING.md`.
 - **The chart versions itself; `VERSION` never touches it.**

RELEASING.md

@@ -15,7 +15,7 @@ main ──●──●──●──●──●──●──●──●─
           │
           v0.12.1 + its chart bump
           │
-          └── release/0.12 ──●── v0.12.2 ──●── v0.12.3   hotfixes only; prod runs these tags
+          └── release/0.12 ──●── v0.12.2 ──●── v0.12.3   hotfixes only; staging and prod run these tags
                              ▲
                          hotfix/… PRs
 ```
@@ -44,14 +44,15 @@ itself builds nothing; only its tags do.
 
 ## Deployment
 
-Two clusters, both installed from the Helm chart by the GitOps setup in
-`sdsc-ordes/cloud-infra` — a base `values.yaml` plus per-cluster overrides. The
+Three instances, all installed from the Helm chart by the GitOps setup in
+`sdsc-ordes/cloud-infra` — a base `values.yaml` plus per-instance overrides. The
 only thing that differs between them is which images they pull.
 
-| Cluster | Images                                       | Moves when                       |
-| ------- | -------------------------------------------- | -------------------------------- |
-| dev     | `temporary/*:latest`, `pullPolicy: Always`   | anything is merged to `main`     |
-| prod    | chart defaults — `release/*` at `appVersion` | a new chart version is installed |
+| Instance | Images                                       | Moves when                       |
+| -------- | -------------------------------------------- | -------------------------------- |
+| dev      | `temporary/*:latest`, `pullPolicy: Always`   | anything is merged to `main`     |
+| staging  | the latest release, hotfixes included        | a new release or hotfix is out   |
+| prod     | chart defaults — `release/*` at `appVersion` | a new chart version is installed |
 
 ### dev follows `main`
 
@@ -60,13 +61,6 @@ merge to main ──► CI rebuilds temporary/*:latest ──► next container
                                                      serves the new code
 ```
 
-A restart is not always something you chose: an eviction or a node drain
-restarts the container too. To restart it on purpose:
-
-```bash
-kubectl rollout restart deploy/hackagon-frontend
-```
-
 To see which build it is serving, read the version at the bottom of the page.
 
 `pullPolicy: Always` is what makes this work. The chart defaults to

components/backend/cmd/seed/README.md

@@ -53,10 +53,10 @@ cannot log in — see [Users](#users).
 ## When to re-seed
 
 **Nothing re-seeds automatically.** The backend never runs `cmd/seed`: a deploy,
-a restart or a new image only migrates the schema and keeps every row. So the
-dev cluster holds whatever the last manual re-seed wrote, plus everything people
-have done to it since; production is never seeded at all. CI does run the seed,
-but against a throwaway stack, to prove it still works — nothing it writes
+a restart or a new image only migrates the schema and keeps every row. So dev
+and staging hold whatever the last manual re-seed wrote, plus everything people
+have done to them since; production is never seeded at all. CI does run the
+seed, but against a throwaway stack, to prove it still works — nothing it writes
 survives the job.
 
 Re-seed when one of these is true:
@@ -95,10 +95,12 @@ just deploy::down && just deploy::up # reload the casbin policy, see below
 # Or all of that at once, regenerating code too
 just schema-change
 
-# The dev cluster — backs up, wipes the app database (Keycloak is kept),
-# seeds from your checkout and restarts the backend. Refuses unless
-# components/backend matches origin/main.
-just cluster::reseed <kube-context>
+# Dev or staging — backs up, wipes the app database (Keycloak is kept), seeds
+# and restarts the backend. The seed is built from the code the instance:
+# origin/main for dev, the newest origin/release/* for staging,
+# needs HACKAGON_KUBECONFIG to be set.
+just cluster::reseed dev
+just cluster::reseed staging
 ```
 
 ## Running the seed