felhom.eu/REPORT-romm-ghost-tags-2026-10-16.md

REPORT — RomM finds its games · Ghost does not lock the household out · the floor refuses withdrawn builds (2026-10-16)

Daytime, operator present. A second session works in this repo today, so this is a dated report, not REPORT.md. Design read: architecture/09-update-architecture.md (§0, decisions 4 and 250), 05-hub-architecture.md (floor serving), 02-controller-module-map.md (app e-mail), 07-backup-architecture.md (RomM's optional legs). Evidence: documentation/audits/romm-ghost-2026-10-16/ (A1, A2, B, C1, C2, teardown).

1. RomM (R-1089) — measured, fixed, both scenarios pass

• A1 (9201): a dummy file where the first steps said (roms/gba/) → „No platforms found”, 0 games. One folder deeper (roms/roms/gba/) → found. Cause: RomM 5.3.1 scans library/roms/<platform>/; the drive's roms/ was mounted as library/.
• Fix (catalog fb18471): roms → library/roms; new drive folder roms-bios → library/bios (operator ruling); backup and folder labels for it; first steps corrected; stale admin / admin comment replaced.
• Scenario A (fresh install): the file at roms/gba/ is found. Pass.
• Scenario B (old install, correction, restart): the old-steps file is found; the drive is unchanged byte for byte; the data tab shows both folders backed up. Pass. A game uploaded through RomM under the old mapping becomes „missing” and reappears under a fake platform „roms” (it sits in roms/roms/<platform>/).
• BIOS: a file in roms-bios/psx/ is read as psx firmware.
• Who runs RomM: demo-felhom (N100) and demo-hp only (hub /apps/romm, read only). No customer box.

2. Withdrawn controller builds (R-1085) — refused at input and at serve time, live

• Hub v0.155.0 (b17e9e99, deployed f1e1c8a6 after the operator's yes). One list (hub/internal/store/spoiled_tags.go: 0.315.0, 0.316.3). Both floor forms and the impact probe refuse a listed tag; ResolveManagedFloor holds one that arrives any other way (stored value, override, config/env default), with its own reason and one [WARN] per change. The Configuration and customer pages say „withdrawn".
• The hand deploy: a marked never-deploy line and a chained pre-check in the felhom-build-deploy skill; a test pins that both equal the hub's list.
• Tests: store, forms, probe, both branches of both page notices, the real report handler, the skill parity. Ten red-proofs, each seen failing (B/hub-redproofs.txt). Full hub go build && go vet && go test: green.
• Live (B/hub-live-check.txt): ArgoCD Synced/Healthy at f1e1c8a6, pod on felhom-hub:0.155.0. Impact probe for 0.316.3 → valid:false, spoiled:true; control 0.319.0 → valid. POST 0.316.3 to the global floor with CC's token → 303 flash=floor_spoiled; the floor read back is still 0.319.0; the hub logged one [WARN] … REFUSED. Boxes kept being served 0.319.0.

3. Ghost (R-1090) — measured, fixed, both ways pass

• C1: Ghost 6.67.0 skips the e-mailed code only on the first-ever sign-in; the next new device got 500 „Failed to send email” — locked out.
• Fix (catalog fb18471): the device check is off by default and turned on with the mail settings by a new smtp_mapping when app e-mail is on. One FAQ entry.
• Scenario E, e-mail off: a new device signs in with the password alone (201).
• Scenario E, e-mail on: 403 2FA_NEW_DEVICE_DETECTED; the shim relayed (hub 200); the mail arrived; the code from it was accepted and the device signed in (200).

4. Versions, commits, teardown, register

• Catalog: fb18471 (RomM + Ghost), 806d2d0 (report, box-walk fix). felhom.eu: b17e9e99 (hub code, skill, 09, evidence), f1e1c8a6 (manifest), and this commit (register, STATUS, report, last evidence). Hub v0.154.0 → v0.155.0. Controller and agent: not touched.
• CI by job id: felhom.eu b17e9e99 job 1934 success; catalog fb18471 job 1931 success; the later pushes are listed in the session's final note.
• Teardown: machine (9201) — RomM and Ghost removed, the drive's roms/ as found, app e-mail back off, two empty helper folders removed; kept on purpose: two kept/romm/<date>/ folders (the product's „start fresh" result, 8 KB). The pre-existing broken RomM was removed by operator ruling. Host — nothing. Hub — no record created; the hub deploy is the only hub change.
• Register: 175 rows before, 176 after; 3 closed (R-1085, R-1089, R-1090), 4 opened (R-1096, R-1097, R-1098, R-1099). STATUS: one line for the operator (R-1099). System poster: no poster fact changed — none of the three updates was needed.

5. Observations

• The standing RomM on 9201 crash-looped on Redis files damaged by the 2026-09-24 disk-full — FILED: R-1096.
• RomM keeps saves, states and screenshots in an anonymous volume (/romm/assets), outside the backup — FILED: R-1097.
• The hub build script does not refuse a version that already exists in the registry (the controller's does) — FILED: R-1098. Checked by hand for 0.155.0 today (not found; control 0.154.0 found).
• The N100 may hold RomM uploads in the old place, now under a fake „roms" platform — FILED: R-1099 (operator, STATUS).
• The box walk made a drive folder for a value the caller passed — NOT-A-FINDING: small, fixed (catalog 806d2d0).
• A drill fixture folder (DRILL-2026-08-21) on 9201's drive shows as a RomM platform — NOT-A-FINDING: another session's test file on a test drive, left untouched.
• The task gave the new flash text in Hungarian and English — NOT-A-FINDING: the hub's operator pages are English only, so only the English text was used, like every neighbouring flash.
• The task asked for a RomM FAQ line if a rescan is needed after the mount change — NOT-A-FINDING: a rescan does not fix it (the files must move), and no customer runs RomM; R-1099 covers the one box that may.
• RomM's remove answered 502 while another session restarted 9201's controller; the remove had completed — NOT-A-FINDING: the proxy's answer during a deliberate controller restart.
• 9201's controller moved 0.318.0 → 0.319.0-rc.1 during the test — NOT-A-FINDING: another session's release work.

unproven.py --summary: unchanged — 35 of 55 claims not walked.