The console was a flat form: every control on the root window, 48 operations
as undifferentiated rows, a giant output textarea, privilege as a buried
sentence. It now has a shell: a fixed header band (product, target, device
state, privilege) plus a page body, and in detailed mode a sidebar with five
operation categories and an Activity page.
What changed (presentation layer only; _execute, gates, run_plan, audit and
redaction untouched):
- simple mode is an Overview: four state cards (target/device/privilege/
inventory) plus Install/Status/Exit, instead of the raw form;
- the target is one segmented control (Device/Wave/Entire fleet) with a single
scope source of truth; the dealer text can no longer silently override the
wave, and the scope stays visible across pages;
- operations are browsed, not dumped: icon + name + explanation + scope/risk
badges, with a detail panel (meta grid, warnings, options form, backend-built
command preview on demand);
- destructive confirmations are dedicated dialogs showing OPERATION/TARGET/
SCOPE/EFFECT with a fleet/production strip and focus on Cancel; the token
dialog is styled; secrets never enter either;
- the output textarea is an execution drawer (IDLE/RUNNING with mm:ss /
DONE-FAILED with duration and exit code) streaming the same backend output;
- write operations stay visible but disabled with their reason when
unprivileged, in both entry points;
- new module bfos/ui_widgets.py (~490 lines, stdlib + tkinter only, no colour
literals): canvas line icons, segmented control, collapsible panel, meta
grid, timer, the two safety dialogs.
Tests: test_bfos_gui_static.py 95 OK, test_bfos.py 155 OK, run-all.sh 12/12.
The colour-literal test now also scans ui_widgets.py (proven by mutation:
a #ff0000 probe goes red, green after removal). Live QA: zero geometry errors
over 712 widgets, all 48 operations listed, 13 write ops disabled with reasons
without root, TUI and --list smoke-tested.
Known limits: no dark theme (tokens ready); the detail page's target line does
not refresh when the target changes mid-form (the confirmation dialog always
shows the current one); visual QA was geometry + OCR, not a human eye.
The console was a default-grey tkinter window: no grouping, no state colour, no
type scale, the privilege warning buried inside a monospace paragraph beside the
repository path, "Çık" offered twice at two different sizes, and an output area
that looked editable. The catalogue is 48 operations, 13 of them destructive, so
the screen an operator actually reads before touching a fleet was the one surface
with no hierarchy at all.
Adds bfos/ui_theme.py, which mirrors web/static/tokens.css value for value --
the two surfaces describe the same fleet and must not disagree about what a
colour means. It selects the `clam` theme because that renderer honours
background/bordercolor on the elements being restyled; note that theming an
element is not the same as redesigning a control, and the remaining gap is
recorded in docs/UI-REMAINING-WORK.md rather than claimed as finished.
What the redesign changes:
- sections get headed regions instead of floating on the root background;
- the privilege level becomes a header element and a banner, not a sentence;
- one exit action, not two;
- write operations are disabled with their reason visible when unprivileged,
rather than hidden or silently listed;
- the output well is styled as the read-only evidence it is.
Tests: tests/test_bfos_gui_static.py moves to the new contract (68 -> assertions
updated, none deleted); tests/test_bfos.py still 155/155, which is the check that
the CLI and backend contracts survived a UI rewrite.
The guide claimed four secondary tools (environment info, live hardware check,
remote-access status, hardware inventory) exist only in the terminal console.
Measured against the loaded catalogue, all of them are reachable from the GUI's
Detaylı mod tabs -- the Araçlar tab lists 9 operations and Cihaz bilgisi carries
the info screens -- and the TUI uses the same bfos.operations catalogue, so
neither surface holds anything the other lacks. `--tui` is a fallback for a
missing window, not a place where missing features live.
The package pool was committed but the installer still stopped at "no local
package repository": it requires the compiled bundle (Packages, Packages.gz,
packages.lock.tsv, SHA256SUMS), and building that had never run.
The bundle
- 1321 packages, 884 MiB, Ubuntu 26.04 amd64, built with apt-ftparchive on the
fleet's own release so the closure matches the devices.
- built/pool/ is gitignored: those .deb files are already tracked once under
provisioning/offline-repo/packages/, and the same ~890 MB does not need a
second path. What the installer reads from the bundle is the index.
- The output directory is chmod 0755: mktemp -d created it 0700 and left it
so, which made a valid bundle unreadable to the installer's probe.
dpkg-deb output was parsed wrong in four places
- `dpkg-deb -f <file> Package Version` prints "<Field>: <value>", and the
callers kept the whole line, so the value carried its label. build-index.sh
therefore accepted no package at all and reported an empty pool;
add-packages.sh rejected every real .deb as an invalid name, missed version
conflicts, and copied a duplicate; build-offline-repo.sh never matched a pin.
- The test suite could not see any of this: its dpkg-deb stub emitted bare
values. The stub now prints the labels exactly as the real tool does, which
is what surfaced the remaining three sites.
Tests
- The secret scan covers the files we author, not apt-ftparchive's index over
third-party packages: polkit's own description reads "...asked for their
password:", which is prose in the packages, not a leak. Any secret reaching a
manifest, README or tool is still caught.
- The "test build must not touch the bundle" assertion now compares the
directory before and after instead of demanding it be empty, so a
maintainer's real build is not reported as test spill.
Simplifies the primary path from "build a custom ISO" to "install from git and
run one menu", which is what the operator actually asked for. The ISO tooling
stays in the tree as a secondary/optional route and is not removed.
admin/bf-bootstrap.sh -- one command on Ubuntu:
- clones the repo to /opt/blueforce-linux or fast-forwards an existing checkout
(a dirty tree is reported and skipped, never reset or stashed)
- installs git/curl/ansible-core, links admin/bf-* and scripts/*/bf-* into
/usr/local/bin, and finishes with the exact next command
- --check is read-only, works without root, and mutates nothing; the piped form
(curl ... | sudo -S -p '' bash) is guarded against eating the script
admin/bf-menu -- numbered operator console (categories 1-5):
- 1 installs THIS device locally; 2 and 5 drive the fleet through the existing
21 Ansible playbooks; 3 prepares and verifies central integration without
installing a central server; 4 holds local tools
- every operation picks one target: a dealer number or an approved wave group.
Scope is derived from the playbook file itself, so a playbook whose declared
scope disagrees with the console's table is refused rather than run
- the command is always shown before it runs; release-gated operations require
a typed wave token, production requires a second token, and "all" runs
wave-by-wave, stopping at the first failure
- audit log at /var/log/blueforce-console.log (mode 600, falls back to
$XDG_STATE_HOME when not writable), recording sanitized target/command/exit
only: no playbook output, no secrets
admin/bf-creds -- optional credential record, DEFAULT OFF:
- a bare run generates nothing and reports what already exists (device id,
WireGuard public key, private key path only, RustDesk id)
- --generate writes /root/blueforce-credentials.txt (0600) and --fetch delivers
it to admin/secrets/<dealer>.txt (0700/0600, git-ignored). The secret never
reaches stdout, stderr or argv
- this does not change the SSH design: password auth stays off and the
blueforce account stays locked, per docs/06. It is a local delivery aid only
docs/33-OPERATOR-CONSOLE.md -- step-by-step guide for an operator new to Linux
and DevOps: which command to type where, what the screen will ask, both
end-to-end sample sessions, the five most common errors, and the security rules.
Tests: run-all.sh -> 9/9 pass, exit 0 (adds check-admin-static.sh, 159 checks,
with negative controls and mutation-proven non-vacuity).
