D6 verification flagged 3 stale remnants missed by the Round-12 cleanup pass. Per ground-truth:
- Line 155: relibc "active patches" is stale. Core recipes use PATCHED-VIA-PATH-FORK; 26 patch files in local/patches/relibc/ are reference/archived only.
- Lines 1832, 1902: qtbase 6.11.0 bumped to 6.11.1 to match README and actual fork state.
(NO AI attribution)
Add local/scripts/cleanup-build.sh - a git-aware cleanup script that
uses 'git ls-files' to whitelist tracked files before deletion.
Prevents the class of cleanup disasters that deleted local recipe
sources and local fork sources.
Update AGENTS.md with the new safe cleanup procedure.
Update CONSOLE-TO-KDE-DESKTOP-PLAN.md to v5.8 with the qtdeclarative
qfeatures.h fix and the new safe cleanup script.
Wires the v1.20 SMART data module into the Storage tab UI.
Each disk now shows a health badge (✓ PASSED / ✗ FAILED / error).
Implementation:
- App.smart: SmartInfo field + 11-tick refresh (paired with Storage)
- Conditional refresh (if self.smart.available guard — avoids
re-running smartctl if we already know it's missing)
- render_storage_panel: 4 SMART badge states
1. !available → '(SMART: install smartmontools)'
2. health.passed → ' ✓ PASSED'
3. !health.passed → ' ✗ FAILED'
4. health.error → ' (SMART: <error>)'
Linux host smoke test (this dev host without smartctl):
- Each disk shows '(SMART: install smartmontools)' hint
- No panic, graceful degradation
- Storage tab still works (no regression)
Performance: smartctl subprocess ~5-50ms per disk, 3 disks = 15-150ms
per 11-tick refresh (5.5 sec), well within budget.
76/76 tests pass (no new tests — UI integration only).
Cross-compile SHA256: ed804710fa834f4453a236aa034d50668b948b391ec1d2ccea294d438016d855.
Docs: improvement plan §45, CONSOLE-TO-KDE §3.3.2 v1.21,
RATATUI-APP-PATTERNS §13.14 + §14 (6400 LoC, 21 modules, 76 tests).
Adds the smart.rs module for disk health monitoring. Since
smartctl is not installed on most systems (this dev host has it
absent), v1.20 implements the module with three-tier graceful
degradation per the zero-stub policy.
New module smart.rs (222 lines, 7 unit tests):
- SmartInfo struct with available + per-disk health records
- SmartHealth struct with passed + attributes + error
- SmartAttribute struct with id + name + value + worst + threshold + raw
- SmartInfo::smartctl_available() — checks smartctl --version
- SmartInfo::read(disks) — orchestrates per-disk smartctl -A -H
- parse_smartctl_output(text) — extracts passed/failed + attrs
- parse_attribute_line(line) — single 10-field SMART attribute
- parse_smart_value(s) — handles both hex (0x33) and decimal
- health_for(disk_name) — convenience accessor
Three-tier graceful degradation:
1. smartctl missing → available=false, disks=[]
2. smartctl errors per disk → error captured in SmartHealth
3. NVMe permission issues → error message, no fabrication
Updated main.rs: mod smart declaration.
76/76 tests pass (5 bench + 12 sensor + 13 network + 12 storage +
20 process + 7 pid_detail + 7 smart).
Linux host smoke test (this dev host without smartctl):
- available=false (graceful, no panic)
- Storage tab still works (no regression)
Cross-compile SHA256 unchanged from v1.19 (smart.rs is dead code
on Redox — compiles but never called).
Docs: improvement plan §44, CONSOLE-TO-KDE §3.3.2 v1.20,
RATATUI-APP-PATTERNS §13.14 + §14 (6360 LoC, 21 modules, 76 tests).
Closes the v1.13 §37.6 forward-work item (the last one). Process
tab now supports case-insensitive substring filtering on the
process name (comm).
Implementation summary:
- New App.process_filter: String field
- Hotkey 'f' opens text-input mode (pattern reused from refresh-
interval input):
- chars → push to filter buffer
- Backspace → pop
- Enter → commit filter, flash match count
- Esc → discard buffer + clear filter
- Filter applied in render_process_panel:
- For each process, skip if non-empty filter doesn't match
(case-insensitive substring on comm)
- Header line shows filter indicator + hint
- Helper proc_filter_match_count(app) for status message
- 4 new unit tests (case insensitive + substring + no match + empty)
- 62/62 tests pass
Build: clean
Cross-compile SHA256: 12913dedc9b0ea58ed3e7418527da34c903f70be703b8676e4273042c73ac875
Docs: improvement plan §42, CONSOLE-TO-KDE §3.3.2 v1.18,
RATATUI-APP-PATTERNS §13.14 + §14 (5840 LoC, 62 tests).
Closes the v1.13 §37.6 forward-work item. Process tab now shows
real-time CPU usage per process, computed from the delta of
total CPU ticks between successive 13th-tick refreshes.
Source code already landed (process.rs + app.rs + render.rs).
This commit captures full v1.14 docs:
- Improvement plan §38 (CPU% in Process Tab)
- CONSOLE-TO-KDE §3.3.2 v1.14
- RATATUI-APP-PATTERNS §13.14 (audit table +14) + §14 (19 modules, 47 tests)
Implementation summary:
- New cpu_pct: f64 field on ProcessInfo
- New ProcInfo::read_with_cpu_pct(prev, dt_secs, num_cpus)
- Wall-clock dt (SystemTime) — accurate even when TUI pauses
- saturating_sub on ticks prevents underflow if now < prev
- num_cpus from self.cpus.len() (Per-CPU detection result)
- 4 new unit tests (formula + zero + underflow + dt=0)
- 47/47 total tests pass
Math sanity check (verified by unit test):
utime=100→200, stime=50→80, dt=2sec, num_cpus=4
delta = 280-150 = 130 ticks / 2 sec = 65 ticks/sec
CPU% = 65 / 4 cpus * 100 = 1625.0%
Cross-compile SHA256: d46cd66b8e158e2327839ef502879951877a5500d4a40807d3dbc72ed7397231.
Phase 20 ships the editor's F9 menu bar as a self-contained,
testable widget. Mirrors Midnight Commander's
src/editor/editmenu.c structure (six top-level menus with
arrow-key navigation, dropdown rendering, item dispatch).
Components:
src/editor/menubar.rs — EditorMenuBar + EditorCmd + render()
src/editor/mod.rs — pub mod menubar declaration
Tests: 10 unit tests in editor::menubar cover menu navigation
(arrows, wrapping, separators), Esc/F9 close, Enter dispatch,
letter hotkey menu selection by title, and render smoke test.
Wiring into the editor's main handle_key + render path is the
natural next step; the user has separately committed
dfed245e4a / 0d999dc4ed which add Key::LEFT/RIGHT/UP/DOWN
constants + to_char() method required for the dispatch path.
PLAN.md header bumped to Phase 20 complete.
Adds the 6th tab in the multi-view system: Sensors, reading
hardware monitoring data from /sys/class/hwmon/hwmonN/ on Linux
hosts. Detects all chips (k10temp, coretemp, nvme, mt7921, r8169,
spd5118, zenpower, etc.) and their temp/fan/voltage/power/current
sensors with proper unit conversions.
New module sensor.rs (231 lines):
- SensorKind enum: Temp (m°C) / Fan (RPM) / Voltage (mV) /
Power (µW) / Current (mA), with #[default] on Temp
- SensorReading: kind, label, raw_value, display_value
- HwmonChip: name, path, readings
- SensorInfo::read() walks /sys/class/hwmon/hwmonN/, reads
name + all *_input files (with corresponding *_label for
human-readable names like 'Tctl', 'Composite')
- 7 unit tests covering unit conversions + empty state
Updated app.rs:
- New field sensors: SensorInfo, refreshed every 3rd tick
(1.5 sec at POLL_MS=500). 3-tick modulus is coprime to
meminfo's 4 and battery's 5 — no thundering-herd syscalls.
- TabId::Sensors variant (6th tab)
- TabId::next() cycles PerCpu → System → Info → Motherboard →
Battery → Sensors → PerCpu
Updated render.rs:
- New render_sensor_panel(app, focused) with per-chip sections
using ▸ arrow + chip name as bold header, then Label/Value pairs
in 12-char left-aligned label / 14-char right-aligned value
layout. Empty state: '(no sensors detected — /sys/class/hwmon/
not readable)' rather than wall of ?.
- render_tab_bar() updated for 6 tabs with hotkey 1/2/3/4/5/6
- render_once now dumps Sensors panel for headless verification
Updated main.rs:
- mod sensor; declaration
- New dispatch arm TabId::Sensors => render_sensor_panel
- Hotkey 6 jumps to Sensors tab directly
- render_sensor_panel added to imports
Linux host smoke test (Manjaro, Ryzen 9 7900X, 7 chips, 11 sensors):
▸ mt7921_phy0 temp 58.0 °C
▸ r8169_0_e00:00 temp 51.0 °C
▸ k10temp Tccd1 82.6 °C
Tccd2 57.1 °C
Tctl 85.6 °C
▸ nvme Sensor 2 53.9 °C
Composite 50.9 °C
Sensor 1 50.9 °C
▸ spd5118 temp 50.0 °C
▸ spd5118 temp 51.5 °C
▸ nvme Composite 48.9 °C
Unit conversions verified: m°C → °C (50850 → 50.9°C), mV → V,
µW → W, mA → A. Unit tests: 12/12 pass (5 bench + 7 sensor).
Source state: 4885 LoC across 16 modules.
Redox stripped: 3.8 MB (SHA256 7a7c31bc...).
Docs: improvement plan §33, CONSOLE-TO-KDE §3.3.2 v1.9,
RATATUI-APP-PATTERNS §13.14 + §14 (16 modules, 12 tests).
Closes the v1.6 forward-work item from §30.5: battery state changes
continuously on a laptop (capacity drops, power_now varies,
time_to_empty decreases), so the once-at-startup read was leaving
the Battery tab stale during long TUI sessions.
Updated app.rs::refresh():
- New 5-tick throttled read of BatteryInfo::read()
- Reuses existing refresh_counter (no new field)
- Cadence: 2.5 sec at default POLL_MS=500 (0.04% CPU cost)
- Independent of meminfo's 4-tick modulus (coprime moduli prevent
thundering-herd syscalls — only 5% of ticks see simultaneous
meminfo + battery reads)
- find_battery_dir() re-checks on each refresh, so a laptop
plugged in mid-session populates the Battery tab on the next
5th refresh tick without any external trigger
Verification:
- Mock battery at /tmp/fake-battery/BAT0/ with capacity=67:
redbear-power --once shows Capacity: 67%
- Changed capacity to 50, re-ran --once: shows Capacity: 50%
- Strace confirms 14 sysfs opens per read() call
Cadence rationale (modulus 5 chosen):
- Every tick (500ms): 0.2% CPU — too aggressive
- Every 5th tick (2.5s): 0.04% CPU — chosen
- Once at startup: 0% CPU — too stale
- Every 4th tick would also work but 5 chosen for clean
coprime separation from meminfo's 4-tick modulus
Build: same 3.8 MB stripped Redox binary (single if branch added).
SHA256 f76fe2b454e6a7e8db5a913c8c363de716f8cacc4ac4b4d2f1da22fc1c0f7570.
Docs: improvement plan §31, CONSOLE-TO-KDE §3.3.2 v1.7,
RATATUI-APP-PATTERNS §13.19 (coprime moduli pattern) + §14.
Mesa virgl:
- All virgl C objects compile successfully
- Linker fails: undefined reference to static_assert in virgl_drm_winsys.c
- Root cause: Mesa util/macros.h #define static_assert _Static_assert
not picked up before Linux drm.h uses static_assert() in include chain
- Fix candidates: patch drm.h or add -include util/macros.h to CFLAGS
- swrast-only build verified (stable)
Achievements this session:
- Mesa virgl compilation proven (objects build)
- virgl_screen.c disk cache patched for Redox
- bits/safamily-t.h provided to toolchain
- Linux 7.0 kernel source cached durably
- Virtio-gpu display driver confirmed working in redox-drm
- Credential syscalls fully implemented
Per Oracle review iteration 10: 'Build and archive the currently
buildable KDE substrate on redbear-full, fix dependency ordering for
that subset, and document/defer remaining blockers instead of
resolving them. Explicitly exclude real kwin, kirigami, plasma-*,
breeze, kde-cli-tools, kf6-knewstuff payload, Qt6::Sensors/libinput/
QML gates from this session acceptance criteria.'
- Verified: 29 KDE pkgar files in repo/x86_64-unknown-redox/
- Verified: 36 KDE packages enabled in config with = {}
- Blocked: 12 (48 total - 36 enabled)
- Stage-only: 7 (36 enabled - 29 in repo)
- All counts derived from actual repo artifacts and config
- CONSOLE: removed contradicting 11/12 blocked lines, unified to 37/11
- DESKTOP line 332: 32 KF6→37 KDE, 13→14 in repo, 36→37 enabled
- DESKTOP line 338: 12→11 blocked
- All counts now consistent across both docs
- CONSOLE line 91: removed stale 'commented out/compilation error'
- DESKTOP line 19: removed stale double-text
- DESKTOP line 127: removed kf6-kio from blocked list, breeze count 2→1
- kf6-kio now consistently 'builds, enabled, pkgar in repo' everywhere
Step 2: kf6-kio in repo ✅, kde-cli-tools out of scope (commented)
Step 3: Config accurate — blocked packages commented with reasons
Step 4: CONSOLE plan line 6 replaced with scoped verification claim:
'VERIFIED scope is the currently buildable KDE surface on
redbear-full; packages blocked by QML/Sensors/libinput stay
commented out and are not part of this verification claim'
Step 5: Docs synced with config
- Oracle VERIFIED kf6-kio fix: HostInfo::lookupHost stub using
direct QHostInfo::fromName replaces QtConcurrent chain
- Updated all doc counts: 36→37 buildable, 12→11 blocked
- kf6-kio moved from 'blocked: compilation' to 'builds'
- Fixed repo .pkgar count: 13 (was 15 claimed). Updated all docs.
- Fixed stage-only count: 23 (was 21).
- Removed last stale '9 KF6 reach image' text from bottom line.
- Removed stale '22 additional recipes need enablement' text.
- Live ISO path now depends on 'sources' target (archival parity
with harddrive.img path).
- All counts now verified against actual repo artifacts.
- Wave 4/7 stale enablement notes replaced with current state refs
- '22 KF6 enabled' → current status table reference
- 'knewstuff/kwallet enabled in config' → accurate blocked/building status
- '22 additional recipes need enablement' → removed
- CONSOLE plan: 'KF6 frameworks (32/32)' → 'KDE/Plasma surface (48)'
matching the broader 36/12 count
- All counts now internally consistent across both docs
- 11→12 blocked count in CONSOLE plan table
- Removed '23 additional KF6 not enabled' stale text
- Removed 'kf6-kio enabled/knewstuff+kwallet enabled' stale Wave 7 text
- kde-cli-tools: 'Blocked: dependencies' → 'source-incompatible'
- 48 total, 36 build, 12 blocked — consistent across both docs
- Fixed 47→48 recipe count (kf6-attica)
- Fixed 11→12 blocked count
- Removed all stale '9 KF6', 'only kwin', 'ECM in built' from CONSOLE plan
- Updated to current state referencing canonical DESKTOP-STACK doc
- kf6-attica source archived (sources/ is gitignored)