## 2026-09-16T15:12:00Z golden 0.244.0 — bake in the drill VM (§4.0/§4.1 of RUNBOOK-manual-build)
  reverted to virgin (this also proves no qemu holds the qcow2)
  cold boot started
  ssh up: pve-manager/9.2.2/b9984c6d90a4bd80 (running kernel: 7.0.2-6-pve)
  template: debian-13-standard_13.6-1_amd64.tar.zst
  template downloaded
  bake launched as a transient unit at 2026-09-16T15:13:01Z
  token leak check on the unit (must be 0): 1
  bake unit state: inactive at 2026-09-16T15:13:17Z
  log lines: 2
  markers: overlay2=0 mountpoints=0 upload=0 FATAL=0 excluding=0
  token-leak control — planted copy must be 1: 1; committed log must be 0: 0
  qemu exited; disk reverted to virgin
## bake done 2026-09-16T15:13:40Z
## 2026-09-16T15:14:36Z golden 0.244.0 — bake in the drill VM (§4.0/§4.1 of RUNBOOK-manual-build)
  reverted to virgin (this also proves no qemu holds the qcow2)
  cold boot started
## MY OWN MISTAKE, recorded because it cost a bake (first attempt, 15:13Z):
##   1) `scp` takes `-P <port>`; I passed the ssh flag set, whose `-p 2222` means preserve-times and
##      made scp treat „2222" as a source filename. Neither the script nor the token landed in the VM,
##      and the bake died in 16 s with „/root/build-golden.sh: No such file or directory".
##   2) The token-leak check then reported „1" and it was NOT a leak: with the token file ABSENT,
##      `grep -c -F "$(cat ...)"` becomes `grep -c -F ""`, which matches every line. An instrument
##      that reports a hit when its needle is empty is not a measurement — the same class this repo
##      keeps re-learning. The re-run guards both: it aborts unless BOTH files land non-empty.
  ssh up: pve-manager/9.2.2/b9984c6d90a4bd80 (running kernel: 7.0.2-6-pve)
  template: debian-13-standard_13.6-1_amd64.tar.zst
  template downloaded
  script + token landed in the VM (both non-empty)
  bake launched as a transient unit at 2026-09-16T15:15:37Z
  token leak check on the unit (must be 0, and the token is non-empty so the grep cannot match everything): 0
## 2026-09-16T15:19Z — MY WATCHER WAS KILLED, THE BAKE WAS NOT. Recorded so the two are not confused.
##  The system stopped my background watcher shell for low memory (DooPlex: 62 GB total, ~11 GB
##  available, the largest consumer a 10.6 GB java service; the bake VM itself was 4.1 GB RSS).
##  The VM is daemonized and the bake runs INSIDE it as a transient systemd unit, so it kept going:
##  `systemctl is-active golden-bake` = active, 120 log lines, at „baking infra images (4)".
##  Production was unaffected — the k3s pods stayed Running and the hub kept serving.
##  CONSEQUENCE: the watcher's post-bake steps (copy the log out, markers, token-leak control,
##  destroy 9100, poweroff, revert to virgin) did NOT run and are done by hand below.
  unit finished: inactive at 2026-09-16T15:21:10Z
  log copied off the machine FIRST (R-320): 316 lines
  markers: overlay2=1 mountpoints=2 upload=0 FATAL=0 excluding=0
  token-leak control — planted copy must be 1: 1; the COMMITTED log must be 0: 0
  teardown: shredded
  qemu processes now: 0
  disk reverted to virgin
## bake finished 2026-09-16T15:21:37Z
## MY SECOND MISTAKE ON THIS BAKE, and it is the more serious one (15:21Z):
##   The bake BUILT the golden and then printed „Gitea publish SKIPPED (set GITEA_USER+GITEA_TOKEN or
##   REGISTRY_USER+REGISTRY_TOKEN to enable)". My runner exported GITEA_TOKEN only. The script needs
##   BOTH (build-golden.sh:417-418 — PUB_USER="${GITEA_USER:-${REGISTRY_USER:-}}").
##   Then I tore the guest down and reverted the disk BEFORE checking the outcome, so the archive
##   (local:backup/vzdump-lxc-9100-2026_09_16-17_19_53.tar.zst, 623 MB) went with it.
##   Registry check confirms the miss: golden 0.244.0 -> HTTP 404; newest published is still 0.243.0.
##   TWO rules of this project were broken by one habit — I read the message the script prints
##   ("DONE. golden archive volid: …") as the outcome, when the outcome is the UPLOAD:
##     * "an absent log line is not evidence" — I checked markers AFTER destroying, not before;
##     * "presence is not success" — a built archive is an attempt, the published package is the result.
##   The re-run below sets both variables and REFUSES to tear anything down until the upload marker
##   and the registry both say the golden exists.
## 2026-09-16T15:23:07Z RE-BAKE golden 0.244.0 — with GITEA_USER this time, and teardown gated on the OUTCOME
  reverted to virgin
  ssh up: pve-manager/9.2.2/b9984c6d90a4bd80 (running kernel: 7.0.2-6-pve)
  template: debian-13-standard_13.6-1_amd64.tar.zst
  bake launched 2026-09-16T15:23:54Z; token leak check on the unit (must be 0): 0
  unit state: inactive at 2026-09-16T15:24:10Z
  log: 1 lines
  markers: overlay2=0 mountpoints=0 upload=0 FATAL=0 skipped=0
  token-leak control — planted must be 1: 1; committed log must be 0: 0
  REGISTRY CHECK (the outcome, not the attempt): golden 0.244.0 -> http=404
  NOT PUBLISHED — the VM and the archive are LEFT IN PLACE on purpose so the artifact is not lost again.
## re-bake done 2026-09-16T15:24:10Z
## 2026-09-16T15:25:31Z THIRD attempt — same running VM (template + files already there), fixed:
   (a) build-golden.sh is made EXECUTABLE (it landed 0644 and died 'Permission denied');
   (b) GITEA_USER is the ADMIN account, not the first credential line (the package namespace is admin).
  VM still up: pve-manager/9.2.2/b9984c6d90a4bd80 (running kernel: 7.0.2-6-pve)
  script executable: yes; token non-empty: yes
  template already on the box: debian-13-standard_13.6-1_amd64.tar.zst
  launched 2026-09-16T15:25:35Z; leak check on the unit (must be 0): 0
## MY THIRD MISTAKE ON THIS BAKE (15:24Z) — two of them in one run, both mine, both recorded:
##   (a) When I rewrote the bake script I DROPPED the `chmod 0700 /root/build-golden.sh` line the
##       first version had. The file landed 0644 and the run died instantly:
##           „/root/bake-run.sh: line 5: /root/build-golden.sh: Permission denied"
##   (b) `GITEA_USER` was taken with `grep -m1` from the credentials file and resolved to `kisfenyo`,
##       but the package namespace is `admin` (`/api/packages/admin/generic/…`). Even a runnable
##       script would have authenticated as the wrong account.
##   AND THE UNIT REPORTED SUCCESS: `systemctl show golden-bake -p Result` = `Result=success`,
##   `ExecMainStatus=0` — because the UNIT ran fine; the script inside it failed. That is exactly the
##   "exit codes that lie" class this project keeps re-learning, and it is why the teardown here is
##   gated on the REGISTRY answering 200 for the package, not on any exit code or log sentence.
##   Nothing was lost this time: the gate held the VM and the archive in place.
  unit state: inactive at 2026-09-16T15:30:47Z
  log: 321 lines; markers: overlay2=1 mountpoints=2 upload=1 FATAL=0 skipped=0
GOLDEN_VERSION=0.244.0
GOLDEN_SHA256=18328a3c7579628b8a7e9639777043db48063c86d37a2e0c221a6ccba6d755a0
  token-leak control — planted must be 1: 1; committed log must be 0: 0
  REGISTRY CHECK (the outcome): golden 0.244.0 -> http=200
  PUBLISHED; guest destroyed, qemu exited, disk reverted to virgin
## attempt 3 done 2026-09-16T15:31:23Z
