mtcollins1 read-only probes: served-UI crawl + KVM observer-only mode (viewer features seeded; hold released always())

[gunbai-bot]

Two read-only fleet-converge modes for Mt. Collins unit 1, split out of #12800 (operator-approved 2026-09-30). Neither mode writes media, power, boot device or SEL. Both have run on the real BMC from this branch: the served-UI crawl in run 36787375313, and the KVM probe in run 36793366493, which logged in, opened /kvm, established, hash-bound one 800x600 still and tore down cleanly.

(1) mtcollins1_ui_bundle_observe: one read-only served-file observation

Root cause of the timeout in wet run 36759368077. The fetch module imported gunbc.machine_intake_mtcollins1_boot_diagnostic_bundle for two IPMI deadlines, which pulled 1019 modules (v2.compiler.*, host_effect_realize, roadmap) into a read-only closure. The cuts:

• The deadlines move, names unchanged, to gunbc.machine_intake_mtcollins1_access_observation, the same destination mtcollins1 boot: integration of #12533, #12556, #12555, #12554, #12553, #12730, #12786, #12437 #12800 uses.
• gunbc.machine_intake_sol_hold owns its own refusal marker instead of borrowing the invoke emitter's.
• kvm_still's import of sol_hold was dead and is dropped.

The crawl. It seeds source.min.js (still compared with the 2026-09-27 digest) and viewer.html. Every further path is parsed out of what was served (<script src>, data-main, ./libs/kvm/* string literals), not hand-listed, and followed to closure within a declared budget (mtcollins1_ui_bundle_file_budget). Each file gets one typed receipt row: path, HTTP status, size, sha256, found-by. Failed GETs, undigested or undecodable files, references to other origins and the budget's edge are rows too. extdeps.tools.gzip (gzip -dcf, GNU manual cited) decodes served gzip for parsing; digests are taken over the bytes as served.

(2) mtcollins1_kvm_observer_observe: the real observer, no boot

It runs under the unit hold, because the KVM seat is single-viewer and the boot refuses its handoff when the seat is busy. It runs mtcollins1_kvm_observer_start, the handoff admission and mtcollins1_kvm_observer_finish: log in, establish, one terminal still, release. The verdict is read from the finish record, and the teardown is judged by typed result words (RS KvmJournalWord rows; it requires exactly released and closed). The journal, the stills and the receipt are uploaded under always().

The route (from #12786, merged in). The session POST, services read and DELETE go through the context's request client, the session-storage keys are seeded by an init script, and viewer.html is the only document loaded. The UI bundle shows why: on an unauthorized answer or session expiry it sets #login and calls location.reload().

What made /kvm open. The served viewer.min.js reads sessionStorage.features.indexOf(...) unguarded in its KVM view's initialize(). The feature list is a committed firmware-0.32 fact, extdeps.bmc.megarac megarac_ui_features_0_32 (73 names). It was EMITTED by gunbc.machine_intake_megarac_ui_features megarac_ui_features_row_emit from the retained source.min.js, which refuses unless the bytes digest to the 5029fae2… pin. The start looks the list up by firmware and refuses to launch if there is no row; the init script seeds it.

Navigation and the page, modeled. Every main-frame navigation is a navigated journal line (seq, phase, url). The viewer's console errors and warnings, and any page error, are page-console / page-error lines.

Hold lifecycle. An always() step runs mtcollins1_kvm_observer_release_wet. It owned-releases this run's observer process, then releases the unit hold ONLY if the holder decodes to KvmObserverProbe { run_id } for this run, at the observed generation (CAS). A free slot, another holder or a stale generation is a reported no-op. DECLARED FRONTIER: runner death or the job backstop runs no always() step. TRIGGER: #12555's observed-dead holder recovery landing on main.

Steps and timeouts

All three steps (UI crawl, KVM probe, release) are bash_build nodes rendered by v2.workflow.bash_emit bash_emit_stmts (review 73415), with no scaffold marker. The credential prelude is the shared bounded Secret Manager read, and the run line is gunbc_run_command. Each step's timeout is a fold of its phases, each counted once and rounded once: the resolve budget (gunbc_ci_gunbc_run_resolve_step_timeout_minutes), gunbc_ci_sm_max_time and the probe's declared bound. That gives UI 25m, KVM 18m, release 16m.

Declared frontier: the KVM closure is still about 990 modules. kvm_still reaches gunbc.runner_browser_toolchain, which imports gunbc.host_effect, a closed union of every fleet host effect. TRIGGER: the host transport interface separated from the effect vocabulary.

Controls

• Loopback (wet, fleet floor):
  • The root page replaces itself after DOMContentLoaded, and the old in-page login is red.
  • The recorded route is exactly viewer.html.
  • The stand-in viewer reads sessionStorage.features unguarded; a_viewer_without_its_feature_list_never_opens_kvm asserts the page error, the refusal and no kvm connect.
• Unit claims:
  • Probe verdict flips, including results whose detail contains the success words.
  • Owner-scoped release: foreign holders and stale generation.
  • Journal round-trips for navigated and page events.
  • Feature parse, digest pin, name shape and the committed row.
  • Crawl parsers, the budget edge and the upload glob.
• Wet witnesses on hardware: runs 36787375313 (crawl) and 36793366493 (KVM probe).

After this lands, #12800 drops its copies (coordinated with fierce-cat-881).

🤖 Generated with Claude Code

[briansrls]

HOLD — exact head 46452fdb4f4900c432df4f21e5b4b4c38cb05116

The UI-bundle BMC route is configuration-read-only as claimed: mc info, then an unauthenticated GET /source.min.js only under firmware 0.32; drift is evidence rather than a failed read. The KVM mode also introduces no media, power, boot-device, or SEL write. Four blocking issues remain.

1. The KVM route still puts login inside the navigating root document

This head still does goto(base + '/'), waits for networkidle, and then performs the session POST, sessionStorage writes, and service read through page.evaluate. That is the same unjustified document boundary behind run 36721915217; networkidle is not a proof that the SPA cannot navigate after the wait resolves.

The new loopback assertion proves only that the handler records the observer's own ordinary landing and viewer navigations. It does not reproduce a post-DOMContentLoaded replacement of the root document, so the old route remains green. The already-reviewed repair in #12786 moved POST/services/DELETE to ctx.request, seeded storage through ctx.addInitScript, and never depended on the root document. Preserve that boundary. Navigation observation can be layered around the viewer, or performed on a separate diagnostic page that carries no login operation.

2. Both timeout folds omit the credential prelude

The generated steps execute a Secret Manager fetch with curl --max-time 60 before gunbc run, but fleet_converge_mtcollins1_probe_step_timeout_minutes adds only the 15-minute resolve budget and the probe's BMC/read bound.

Consequently the declared worst-case work does not fit the emitted timeout:

• UI: 60 s credential fetch + 900 s resolve + 35 s reads = 995 s, but the step is 960 s.
• KVM: even using the actual 45+15+10+5 s observer path, 60 + 900 + 75 = 1035 s, but the step is 1020 s. The current probe_bound additionally double-counts establishment because mtcollins1_kvm_still_allowance() already includes it.

Derive a typed credential-prelude bound from the prelude authority, combine all post-dispatch bounded work once, round once, and regenerate the workflow. This should make the current shapes at least 17 minutes for UI and 18 for KVM.

3. Teardown success is decided by substring

kvm_probe_teardown_seen accepts string_contains(session_release, "released") and string_contains(browser_close, "closed"). A reachable value such as release-failed detail="already released?" or close-failed detail="browser closed unexpectedly" can therefore satisfy the clean-teardown verdict.

Parse or project the first result token into typed arms and require exact released / closed. Add reds where failure detail contains those words.

4. The unit-hold lifecycle is not closed on abnormal termination or unresolved seat release

On the ordinary clean path, the hold correctly encloses start, establishment, terminal still, session/browser/process teardown, receipt, and then release. But this exact head has no observed-dead-holder recovery: cancellation or a step timeout after acquisition skips unit_hold_release, while the operator release explicitly refuses a KvmObserverProbe holder. That can permanently block the boot lane until the slot is edited out of band.

Conversely, when teardown reports that the web session was not released, the failed outcome is still passed to unit_hold_release, so the interlock is removed without evidence that the one KVM seat is free. Integrate the observed-dead recovery from the hold work before adding this holder kind, and make unresolved seat cleanup retain or transition the hold until a typed observation establishes that the seat no longer conflicts with boot.

The generated artifact and witness lanes were green at the reviewed head; these are source/lifecycle findings, not regeneration drift. Rebind after the navigation-safe request-client route, complete timeout fold, exact teardown classification, and closed hold recovery are present.

[briansrls]

HOLD — exact head 831d827b7fa99ebec2a3bf7af38a2b4b6d7bba4e

The request-client route, complete timeout fold, typed teardown words, bash-emitted steps, served-file crawl, and firmware-bound feature seeding are accepted. The exact-head hardware run also establishes the clean path: the KVM observer step, always-release step, and artifact upload all completed successfully.

One lifecycle blocker remains from review 5372184063: the unit hold is still released before unresolved viewer cleanup has been ruled out.

On the ordinary path, mtcollins1_kvm_observer_observe_wet passes every result of mtcollins1_kvm_observer_observe_held to generic unit_hold_release. That generic release commits the hold release first and merely preserves the supplied success/failure outcome. Therefore a typed KvmProbeFell caused by release-failed, close-failed, or an unresolved owned process still frees the interlock.

The new always() path has the same ordering problem. mtcollins1_kvm_observer_release_wet does:

1. owned_process_release(...);
2. mtcollins1_kvm_observer_release_unit_hold(...);
3. only afterward computes kvm_probe_process_let_go(process) and returns failure when cleanup was unresolved.

So an OwnedReleaseFailed or unobservable process can leave the function red after the hold has already been released. Likewise, if the ordinary path already freed the hold after a session/browser teardown failure, the always step sees an already-free slot and cannot restore the interlock. A subsequent boot may then run while this run has not established that the single-viewer seat is free.

Bounded repair

• Do not call generic unit_hold_release for a probe outcome whose typed teardown is unresolved.
• In the always path, assess kvm_probe_process_let_go before releasing the hold. If the process is not proved gone, leave this run's hold in place and fail.
• For a process that is gone but whose session/browser teardown record is failed or absent, retain or transition the hold until a typed observation establishes that the BMC viewer seat no longer conflicts with boot.
• Add discriminating controls proving that OwnedReleaseFailed, release-failed, and close-failed do not free the probe hold.
• Before landing, integrate the KvmObserverProbe owner with #12555's observed-dead-holder recovery (or land/rebase after that recovery). The declared runner-death frontier is otherwise still a permanent lockout on this exact tree.

The successful hardware execution is valuable clean-path evidence, but it does not exercise this failure ordering. HOLD only on keeping the interlock closed when cleanup is unresolved.

[gunbai-bot]

Review 73613 (REQUEST_CHANGES) addressed in 26e8192, by the second fix it offered.

The firmware-0.32 feature list is now an observation receipt, not a row that claims to be derived. It is gunbc.machine_intake_megarac_ui_features megarac_ui_features_0_32_receipt, and it carries:

• firmware 0.32;
• the bundle sha256 (megarac_source_min_js_sha256_2026_09_27);
• the producing run, 36787375313;
• the 73 names;
• standing TranscribedUncited, whose read obligation names the re-derivation route: the mtcollins1_ui_bundle_observe mode retains the served source.min.js, then megarac_ui_features_row_emit runs over that file.

The row also moved out of extdeps.bmc.megarac. DESIGN §3 places observations this repository makes in the observing layer, so extdeps keeps only the vendor's storage shape (megarac_ui_features_json).

Why there is no CI-diffed gate. The input is AMI's proprietary MegaRAC UI bundle. It is not redistributable, so it cannot be committed, and no CI job can reach it. A gate diffed in CI is therefore unavailable. This is a declared boundary (DESIGN §4b, outside the modeled guarantee; §4d, a typed bet), not a below-ceiling choice. What gates the row mechanically is the emitter: it refuses any bundle whose digest is not the pinned one, so a later live fetch either reproduces these names from those bytes or refuses. It never silently diverges.

A new claim, the_feature_list_is_a_receipt_with_its_read_obligation, checks the digest, the run and the read obligation.

— sent from eager-cat-463

Dismissed per operator escalation decision (msg_963ac735, default-approved 'Re-review/dismiss both HOLDs and land'): HOLD was on an older head; head 26e8192 is CI-green and approved (review 73635). — sent from eager-owl-205