SPIKE 4: a .deb in the ISO DOES deliver on an interactive install

Findings only — no script, profile or build file changed; no release ISO built, nothing published.
documentation/audits/SPIKE-universal-iso-4-2026-07-31.md

MEASURED, with a control, and the negative control is in the SAME box. One ISO (15 GRUB entries),
a trivial probe .deb injected into /proxmox/packages/, two qm-created VMs on demo-hp (400
interactive / 401 automated control) on a scratch dir storage at the /mnt/nvme-1tb mount ROOT.

Interactive (Terminal UI) install:
- package installed (ii felhom-spike4-probe 0.0.1)
- postinst RAN (marker + content intact)
- it enabled a systemd unit, and that unit FIRED ON FIRST BOOT (uptime 7.98s, pid1=systemd)
- while on the same machine proxmox-first-boot is NOT installed and /var/lib/proxmox-first-boot
  does not exist — Spike 3's negative reproduced, not assumed.

Postinst environment (identical both paths): pid1=unconfigured.sh, NO running systemd, but
'systemctl enable' SUCCEEDS; /proc+/sys mounted; network+DNS happened to be up (inherited from the
installer's DHCP — must NOT be relied on). Constraints: never systemctl start/daemon-reload, never
require network, never fail, do the real work in the unit at first boot.

Repack preserves it, but a naive 'xorriso -boot_image any replay' fails with 'Overlapping MBR
partition entries' — iso-repack.sh:270-292 already documents that exact failure and its fix.

R-153 RETRACTED into R-94 leg (b): OPEN-ITEMS.md:15 carries it verbatim at READY (XS), and R-29
says explicitly 'do not mint a new ID for a new instance'. Spike 3's further claim that the drift
leaves the generator 'three minor versions stale' was FALSE and is corrected — R-94 retracts that
exact reading; the served script is always main, so 1.22.0 is what every install already gets.

No new R-rows opened.

scripts/CHANGELOG.md

@@ -1,3 +1,40 @@
+## SPIKE 4 (no code change) — a `.deb` in the ISO DOES deliver on an interactive install (2026-07-31)
+
+**No script, profile or build file was modified.** Findings:
+`documentation/audits/SPIKE-universal-iso-4-2026-07-31.md`. **No new R-rows; R-153 RETRACTED.**
+
+**MEASURED, with a control, and the negative control is in the same box.** One ISO (15 GRUB entries),
+a trivial probe `.deb` injected into `/proxmox/packages/`, two VMs on demo-hp created with `qm` (400
+interactive / 401 automated control) on a scratch dir storage at the `/mnt/nvme-1tb` mount ROOT.
+
+On the **Terminal-UI (interactive)** install: the package is installed (`ii felhom-spike4-probe`), its
+postinst ran, it enabled a systemd unit, and **that unit FIRED on first boot** (uptime 7.98s,
+pid1=systemd) — while on the *same machine* `proxmox-first-boot` is not installed and
+`/var/lib/proxmox-first-boot` does not exist, reproducing Spike 3's negative rather than assuming it.
+The automated control delivered both mechanisms.
+
+**The postinst environment (identical on both paths):** `pid1=unconfigured.sh`, **no running systemd**,
+but `systemctl enable` SUCCEEDS; `/proc` + `/sys` mounted; network and DNS happened to be up (inherited
+from the installer's DHCP — **must not be relied on**). Constraints for a real postinst: never
+`systemctl start`/`daemon-reload`, never require network, never fail (`dpkg --configure -a` surfaces it
+as an install error), do the real work in the unit at first boot.
+
+**Repack preserves it** — but a naive `xorriso -boot_image any replay` fails with "Overlapping MBR
+partition entries"; `iso-repack.sh:270-292` already documents that exact failure and its fix, and
+mirroring it produced a working image (19 El Torito entries, probe `.deb` byte-identical out of the
+finished ISO).
+
+**Q3:** `iso-repack.sh:100-106` refuses an ISO without `auto-installer-mode.toml` — a guard, not a
+structural requirement, already filed as R-155 and cited exactly here. With no mode file the stock
+grub.cfg does not emit the Automated entry at all; with a mode file but no answer, the automated entry
+aborts safely and loudly.
+
+**R-153 is RETRACTED** into R-94 leg (b): `OPEN-ITEMS.md:15` already carries it verbatim at
+`READY (XS)`, and R-29 (the class) says explicitly "do not mint a new ID for a new instance".
+**Spike 3's claim that the drift leaves the install-command generator "three minor versions stale" was
+also FALSE and is corrected** — R-94 retracts exactly that reading: the constant selects no script, the
+served script is always `main`, so it is a wrong number on a screen and nothing more.
+
 ## SPIKE 3 (no code change) — `[first-boot]` does NOT fire on an interactive install (2026-07-31)
 
 **No script, profile or build file was modified.** Findings: