BACKLOG P: the fresh install tried, and what it left open

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

BACKLOG.md

@@ -2050,6 +2050,13 @@ lent, partition`); the leader tells each named node's agent (root) what to be, t
   AccountingStorageTRES=gres/gpu, priority/multifactor. Tried on the PoC: five jobs started on
   submission, `sacct -a` has them with their TRES. Not tried: a fresh `server init --slurm` (needs VMs);
   a Red Hat controller.
+- Fresh install tried 2026-11-12 on VMs (3 control planes with Patroni, 2 CPU nodes, `server init
+  --slurm`): Slurm, slurmdbd and MariaDB came up with the install; two-node srun/sbatch on the lent nodes,
+  `sacct` has them; leader failover kept serving. Open from it: `--slurm` needs the first machine to be a
+  node (the controller is its node), so a site wanting control planes without nodes chooses the
+  controller later with `ctl slurm setup`; batch output lands on the job's first node until there is
+  shared storage; on shared CPUs the judge refuses the first request after a placement change (fail
+  closed, ~10 s), and its advice repeats `--cores 4` to a judge that has 4.
 - P6, Slurm's jobs in llmgw's accounting (written 2026-11-12, not started). The tenancy tree to Slurm:
   each project an account (`sacctmgr add account`, parent its team and organization), each member a user
   of it, kept by the leader from the store; `sbatch --account=PROJECT`. The records back: the leader reads