Repository navigation
Wire --interrupt-autoboot into the TUI dashboard - #30
Merged
Merged
Conversation
It was refused there rather than silently ignored, which was right while it was unwired and left the dashboard as the one mode that could not take the prompt. The verdicts render at the top of the findings pane, above the detector findings, because they were read from the device at the prompt and that is better evidence than anything matched out of the scrollback. Putting them in the server pane would have been easier and wrong: that pane says "server" and this is decided entirely locally. The notes go to the status bar and never through the analyzer. Feeding the tool's own output back in would let a detector match it and report bootintel's messages as evidence about the device, so there is a test for that rather than a comment asking someone to be careful. Verified against the socat fake board: the TUI hammered, caught a bootdelay=0 board's single check (582 bytes waiting at the check), and ran printenv, bdinfo and mtdparts. The rendering itself is unit-tested instead, because `script` gives ratatui no real terminal to size against and the alt-screen capture comes back empty. Saying the visual was verified on that evidence would have been wrong, so the part with a decision in it was extracted and driven directly. 390 tests with --features tui, 369 without, clippy clean under -D warnings in both, rustfmt clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Zenofex
added a commit
that referenced
this pull request
Sep 29, 2026
Version bump, lockfile, changelog. No code changes: everything here is on `main` and was reviewed in #30. ## What ships `--interrupt-autoboot` works with `--tui`. It was **refused** there rather than silently ignored, which was right while it was unwired and left the dashboard as the one mode that could not take the prompt. ``` findings (client) — 12 + 5 boot chain ! Secure boot anchor hab fuse not enabled * U-Boot shell reached => printenv ``` Verdicts sit above the detector findings because they were read from the device at the prompt, which is better evidence than anything matched out of the scrollback. ## Why MINOR New behaviour. No flag renamed or removed, no exit-code policy change, no output-format schema broken. ## Verification - `cargo test --workspace --features tui`: 390 passed, 0 failed - `cargo test --workspace`: 369 passed, 0 failed - `clippy --workspace --all-targets --features tui -- -D warnings` and `fmt --all --check`: clean - `cargo build --release --features tui` then `bootintel --version` reports `bootintel 0.12.0` Both version bumps landed first try, fourth release running for `docs/releasing.md` step 1. This was the last item on the gap list carried through the previous few releases. Everything else from the last two days moved on the engine side, which needs no release: the boot chain is now persisted on the scan, rendered in the dashboard, carried into the PDF report, and compared between scans. After merge: dispatch `cli-release` for `0.12.0` with `publish_crates`, verify the draft against `SHA256SUMS`, publish and mark latest, then move the tap (step 7) and sync the in-repo reference copy. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the last gap on my list.
--interrupt-autobootwas refused with--tuirather than silently ignored, which was the right call while it was unwired and left the dashboard as the one mode that could not take the prompt.Where the verdicts go
Top of the findings pane, above the detector findings:
They were read from the device at the prompt, which is better evidence than anything matched out of the scrollback, so burying them under the detector list would invert that. The server pane would have been easier and wrong: its title says "server" and this is decided entirely locally.
Notes go to the status bar, with a longer TTL for the two an operator has to act on (the miss explanation and the completion summary).
The thing worth a test rather than a comment
The tool's own notes never pass through the analyzer. Feeding them back would let a detector match bootintel's output and report it as evidence about the device, so
notes_do_not_become_analyzer_inputasserts it.On verification, honestly
The functional path was verified end to end against the socat fake board: the TUI hammered, caught a
bootdelay=0board's single check (582 bytes waiting at the check), and ranprintenv,bdinfoandmtdparts.The rendering was not verified that way.
scriptgives ratatui no real terminal to size against, so the alt-screen capture comes back empty, and claiming a visual check on that basis would have been false. The part with a decision in it (record_boot_chain) was extracted and is driven directly by three unit tests instead.Verification
cargo test --workspace --features tui: 390 passed, 0 failedcargo test --workspace: 369 passed, 0 failedclippy --workspace --all-targets --features tui -- -D warningsandfmt --all --check: cleanbootdelay=0board, board-side log confirming all three commands ran🤖 Generated with Claude Code