Commit Graph

1175 Commits

Author SHA1 Message Date
cb1e8c53c9 Test nvidia_config.sh to 100%; the 8-lib campaign is done (85 -> 84)
76/76 lines through run_all.sh at --min 100, exit 0. 45 assertions over
15 cases across all four functions.

XORG_CONF and XORG_CONF_D are plain globals ASSIGNED inside
configure_xorg, so the default had to move to the assignment itself --
exporting a value from the harness alone would have been overwritten on
entry. PROFILE_FILE and USER_HOME take the ordinary `${VAR:-default}`
form. The real /etc/X11/xorg.conf.d/20-nvidia.conf keeps its Jun 2025
mtime and ~/pyroveil does not exist after the suite runs.

configure_xorg's RenderAccel value is asserted to be "true" AND asserted
never to be "false": the lib's own comment records that "false" forces
software rendering and pins Xorg above 30% CPU, so that is a regression
worth a dedicated negative assertion.

install_pyroveil's prompt could not be asserted on its text -- bash
writes a `read -p` prompt straight to the terminal, so it never reaches
captured output. The branches are distinguished by the non-interactive
arm's "Auto-installing" line instead, which is observable.

bt_audio.sh re-measured at 127/127 with the new files present.

That is all eight libs from the original handoff: arch_sysctl (banked as
unmeasurable and quarantined), arch_cpu, arch_hardware, thorium_repairs,
hosts_guard_migrate, hosts_guard_rollback, ubuntu_perf_fixes and
nvidia_config. Allowlist 91 -> 84.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-23 13:14:37 +02:00
558883f281 feat(endurain): self-hosted run viewer fed by RunnerUp WebDAV exports
Stands up Endurain behind the existing Caddy edge and imports RunnerUp
activities into it. Endurain is a VIEWER: screen-locker's workout gate still
reads the phone over adb and is untouched here, because a WebDAV drop folder is
spoofable by anything that can write to ~/cloud and must not become a
screen-unlock authority.

Primary path is phone -> WebDAV (existing dufs) -> ~/cloud/RunnerUp/ ->
importer -> Endurain, with an adb pull as fallback when a run has not been
uploaded yet. A systemd user timer runs the importer every 15 min.

Findings that shaped the implementation, each verified against the running
system rather than assumed:

- Endurain moved to Codeberg; the GitHub repo is a read-only mirror stale at
  v0.17.7 against v0.19.0. The image is pulled from Codeberg.
- postgres:18 moved PGDATA to /var/lib/postgresql/18/docker. Upstream's compose
  example still mounts the pre-18 path, which fails as an unexplained
  "container is unhealthy"; the real cause is only visible in docker logs.
- Endurain seeds a hardcoded admin/admin via an Alembic migration with no env
  override, and endurain.kuhy.duckdns.org already resolved publicly. Publishing
  is therefore a separate script that refuses to install the Caddy site while
  those credentials still work.
- Endurain performs NO duplicate detection, so the importer owns dedupe on two
  axes: a content hash, and an activity key that collapses the .gpx/.tcx pair
  RunnerUp writes for a single run (different bytes, same run).
- Ambiguous uploads (5xx/timeout) are never re-queued, since the activity may
  already have been committed; only definite 4xx rejections are staged for
  retry. The importer exits non-zero so the timer surfaces the problem.
- RunnerUp has no background sync at all, so every upload is a manual tap.
- Its WebDAV synchronizer needs HTTPS with a real cert (Android blocks
  cleartext at targetSdk 36; self-signed is broken upstream) and a URL with no
  trailing slash, and cannot MKCOL against dufs - so the inbox must pre-exist.

The phone gets a dufs credential scoped to /RunnerUp, verified unable to read
Keepass or gdrive_backups.

Verified: 52 tests at 100% branch coverage; the timer imports 4 real runs and
re-runs create zero duplicates; https://endurain.kuhy.duckdns.org serves 200
with a valid cert and the other edge sites are unaffected; screen-locker's
suite still passes 1090 tests at 100% coverage.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GbYEnfGnf1988cdFdGebot
2026-08-23 13:09:18 +02:00
ad55d1b6a1 Test ubuntu_perf_fixes.sh to 100%, take it off the allowlist (86 -> 85)
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
81/81 lines through run_all.sh at --min 100, exit 0, and
check_shell_coverage.sh passes with the allowlist line already deleted.

59 assertions over 14 cases across all four functions: the sysctl
drop-in with both the "already applied" skip and the documented-default
fallback for an unreadable sysctl; both NVIDIA branches, since the
helper-service path and the standalone fallback write different units
and different undo lines; earlyoom install / already-installed /
config-backup; and fix_failed_sssd for none, all five and exactly one
failed unit -- that last one matters because the detection loop breaks
at the first failure while the masking loop re-checks each unit, so a
naive implementation would mask all five.

The four write targets are now behind overrides defaulting to the real
paths. The add_undo lines deliberately KEEP their literal /etc paths and
are asserted to: the undo script runs on the real system, so seaming
those would have written an undo that removes nothing. Neither
/etc/sysctl.d/99-performance-tuning.conf nor /etc/default/earlyoom
exists after the suite runs.

bt_audio.sh re-measured at 127/127 with the new files present -- that
canary runs after every addition to this suite now, because a test file
silently broke it once already.

The handoff is rewritten for the one remaining lib.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-23 12:38:40 +02:00
0201d5460a Clear both hosts-guard libs; teach the instrument done <redirect> (88 -> 86)
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
hosts_guard_migrate.sh 81/81 and hosts_guard_rollback.sh 65/65, both
100.00% through run_all.sh at --min 100, and check_shell_coverage.sh
passes with each allowlist line already deleted.

82 assertions over 36 cases in three files sharing one harness: all four
validate_requirements refusals, plugin installation, the mount-collapse
loop in every arm (clears, fails, hits its 20-iteration bound, dry-run),
per-instance migration for both the bind-mounted and the plugin flavour,
and do_migrate's refusal to retire the legacy pacman hooks when nothing
registered -- the arm that exists so a failed migration cannot leave the
files with no unlock hook at all.

INSTRUMENT FIX: rollback measured 97.01% with lines 69 and 108
uncovered, both `done <redirect>` closing a loop. Reproduced minimally:
in a three-iteration loop ending `done >"$1"`, the body reports hits=3
and the `done` line hits=0, because bash attributes the redirected
compound statement to the loop's OPENING line. That is the same defect
_CLOSING_BRACE_OP already handles for `} |`, so _LOOP_END_OP is its
twin. The redirect is required by the pattern: a bare `done` stays in
the denominator, so genuinely uncovered loops are still caught.

Audited as the instrument notes demand -- every newly excluded line
printed with its text -- and it is exactly those two lines across all of
fixes/lib. Acceptance pair unchanged and exact: dot_resolver_install.sh
39/39, rpi_nc_ca.sh 73/73.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-23 11:50:13 +02:00
0e9629e110 Test thorium_repairs.sh to 100%, lift the gate timeout (89 -> 88)
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
75/75 lines through run_all.sh at --min 100, exit 0, and
check_shell_coverage.sh passes with the allowlist line already deleted
so the pass cannot come from the exemption.

55 assertions over 23 cases: all five profile repairs plus test_thorium,
including every dry-run arm, the partial singleton-lock case, a corrupt
database and the sqlite3-absent path. The lib needed NO production
change -- it already takes every path from $THORIUM_CONFIG_DIR, so
pointing that one variable at the tmpdir confines it completely.

The gate's per-case timeout moves from the jail's 120s default to 600s.
That default is a hang-catcher, not a performance budget, and this suite
has outgrown it: 76s bare at 25 test files, 93s at 27, and kcov roughly
doubles it. The symptom was a lib FAILING the gate while measuring
perfectly -- bt_audio.sh printed "127/127 lines = 100.00%" and then
"warn: case timed out after 120s", which --fail-on-case-error turned
into a non-zero exit. bt_audio.sh and arch_cpu.sh both pass now.

The cost, recorded in the evidence: a genuine hang takes 10 minutes per
pass to surface instead of 2. test_thorium's `read -r -p` is exactly
that shape, so every case here feeds it stdin explicitly.

This also settles the quarantine in b2779059. Re-adding the arch_sysctl
cases still yields "kcov instrumented no lines" for bt_audio at a 600s
timeout with no timeout warning, so runtime was never that file's
problem and the quarantine stands for the reason its header gives.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-23 11:05:56 +02:00
b27790596b Quarantine the arch_sysctl cases: they broke bt_audio's measurement
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
check_shell_coverage.sh was RED on main. bt_audio.sh is off the
allowlist at 127/127, and commit 7c14cfca -- which added
test_arch_sysctl.sh -- made kcov stop registering it entirely, so the
gate failed on a lib nothing had touched.

Bisected by measuring bt_audio.sh at three commits: a2b23521 127/127,
afe6ac3a 127/127, 7c14cfca "kcov instrumented no lines". Removing that
one test file restores 127/127 with every other new file still in the
suite (arch_cpu, arch_hardware x2, thorium x2), and arch_cpu.sh
re-measures at 57/57 alongside it.

Both plausible causes inside lib_test_core.sh were ruled out by
reverting each on its own in a throwaway worktree: `export out` and the
_t_hide farm cache each left bt_audio broken while the file was
present. Neutering the file's body while keeping the source line does
NOT reproduce it either, so the trigger is cumulative rather than one
construct, and it is not understood.

The file keeps all 23 assertions and still passes when run directly; it
just leaves the test_*.sh glob run_all.sh iterates. That costs nothing
measurable, because arch_sysctl.sh has never measured through the jail
in the first place -- it reports "instrumented no lines" on its own,
like nc_php.sh -- and it stays on the allowlist.

The header records the bisect and what to re-verify before anyone
un-quarantines it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-23 10:15:11 +02:00
aec2b275c1 boot-repair: refuse shadow-file cleanup on BIOS systems with no ESP
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
clean_shadow_files() assumed UEFI with an ESP mounted at /boot. On a
BIOS/GRUB system with no ESP, /boot is a plain directory on the root
filesystem holding the only kernel the machine has -- and neither existing
guard catches it: findmnt /boot is empty (GUARD 1 passes) and there is no
EFI/ or loader/ (GUARD 2 passes). boot-repair therefore read the real
vmlinuz-linux and initramfs-linux.img as "orphaned kernel file(s)
shadowing the ESP" and deleted them, leaving the machine unbootable.

Measured 2026-08-22 in a vmbox BIOS/GRUB sandbox, not theorised: after
sudo boot-repair the guest never booted again.

GUARD 3: if /sys/firmware/efi does not exist the system booted via BIOS,
so there is no ESP and nothing in /boot can be a shadow. warn + return 1,
matching the existing guards' tone and exit convention. Overridable with
the existing --esp DEVICE -- naming the ESP by hand asserts the firmware
assumption the guard otherwise checks -- rather than adding a new flag.

The check goes through rpath(), so a --root fixture declares its own
firmware type and the case is testable without a VM. On the live UEFI
machine it resolves to the real /sys path, so behaviour there is unchanged.

Audit of the other BIOS-unsafe paths (none destructive, left alone):
  * mount_esp(): resolve_esp_device fails with no /boot fstab entry, so it
    reports and does not mount. Non-destructive.
  * sync_kernel_image()/rebuild_initramfs(): gated behind boot_is_mounted,
    which is false on BIOS, so they never write.
  * check_fstab_options(): reports "no /boot entry" -- noise on BIOS, but
    it writes nothing.
  * run_preflight(): aborts every kernel upgrade on a BIOS box. Fail-closed
    and non-destructive, so out of scope here.

Tests: three cases in tests/lib/boot_repair_bios_cases.sh (new file; the
existing case lib is at the 250-line cap) -- the guard refuses and explains,
--esp overrides it, and a UEFI fixture still cleans shadows as before.
Verified failing without the guard (38/4) and passing with it (42/0).

Sandbox: BIOS guest keeps both kernel files, says why, and still boots
afterwards (uname -r 7.1.9-arch1-2 after a clean poweroff). shellcheck clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VdyMBGCrGVGDWtJ9xe48f3
2026-08-22 23:46:20 +02:00
d59932b262 Allow Metrolist during the night curfew, deploy to phone
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
com.metrolist.music was on the day allowlist but missing from the night
list, so it was hidden between 23:00 and 05:00. Add it to
night_allowed_packages in focus_owner's policy asset (the list the
installed Device Owner app actually enforces) and mirror it into
phone_focus_mode's NIGHT_WHITELIST so the two sources do not drift.

policy.json ships as a bundled Flutter asset, so the edit is inert until
the APK is rebuilt: deployed via phone_deploy.sh (build 4,
data-preserving install -r, Device Owner intact).

Verified on the phone at 23:1x device time with the curfew live:
hidden=true before, hidden=false after, and Metrolist launches and holds
the foreground across several enforcer ticks.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U7Wzqp2ub6gW5uVBH5qmhn
2026-08-22 23:20:27 +02:00
88ba911641 Test arch_hardware.sh to 100%, fix its dead journal vacuum (90 -> 89)
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
94/94 lines through run_all.sh at --min 100, exit 0. 42 assertions over
26 cases across all five functions, including both boot-loader flavours
and the no-boot-loader path.

PRODUCTION BUG, found by writing the tests and confirmed against this
host: tweak_journal's regex required a space before the unit, but
journalctl prints "305.5M in the file system" with no separator. The
size check never matched, so the vacuum was unreachable and a
multi-gigabyte journal would never have been trimmed. This is the third
instance of the same defect -- arch_perf_report.sh:36,65 carried it too
-- so the fix is identical: the separator is now optional. One case
asserts the spaced form still matches, making this a widening.

The mitigation tweak edits the boot loader, so /boot/loader/entries,
/etc/default/grub and grub.cfg are now behind overrides defaulting to
the real paths. This machine's boot configuration is never touched.

_t_hide gets a cache: it symlinks every executable on PATH (13.5k here)
and was rebuilding that farm on every call, which took the suite to 92s
and pushed a jail case past its 120s timeout. Now 77s, and arch_cpu.sh
re-measures at 57/57 so the shared change cost nothing.

The cases are split across two files because a single one was 307 lines
and file-length-cap rejected the first commit attempt.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 21:46:42 +02:00
b4b6908d69 Test arch_cpu.sh to 100% and take it off the allowlist (91 -> 90)
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
57/57 lines, measured through run_all.sh and confirmed a second time at
--min 100 so a shortfall would exit non-zero. check_shell_coverage.sh
passes with the exemption removed.

28 assertions over 14 cases: no cpufreq at all, every core already
tuned, the mixed case where only some cores lag, cpupower absent /
unconfigured / already configured, and all three I/O scheduler targets
(none for NVMe, mq-deadline for SATA SSD, bfq for spinning disks).

The sysfs reads and the two /etc write targets are now behind overrides
defaulting to the real paths, so the tests can present hardware this
host does not have -- a rotational disk -- without touching anything.

One assertion initially passed for the wrong reason: _t_hide keeps
$FAKE_BIN on PATH by design, so the harness's own cpupower stub still
satisfied has_cmd and the "not installed" branch never ran. Unstubbing
before hiding is now explicit, and the case fails if that is lost.

This also settles arch_sysctl.sh's diagnosis: it uses this same
harness, so the harness is not why it cannot be measured.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 21:14:57 +02:00
7c14cfca61 Test arch_sysctl.sh and open the optimize_arch_desktop lib family
23 assertions over 8 cases covering both tweak_vm_sysctl and
tweak_network_sysctl: the skip path, the write-when-the-drop-in-is-
missing path that a naive "nothing to do" check gets wrong, the
value-differs path, an unreadable-sysctl path, and the tcp_bbr guard.

arch_desktop_harness.sh is the third family harness, supplying the
globals and apply_tweak that live in optimize_arch_desktop.sh rather
than in any lib. arch_cpu.sh and arch_hardware.sh will reuse it.

SYSCTL_DROPIN_DIR defaults to the real /etc/sysctl.d, matching the
seam ubuntu_perf_more.sh and arch_perf_fixes.sh already carry; the
suite runs un-jailed in ci_mirror.sh and CI, so a bind mount would
protect nothing. Both real drop-ins keep their Mar 2 mtimes.

_t_run lands in lib_test_core.sh because `out="$(func)"` forks a
subshell and kcov never registers a lib whose first execution happens
inside one -- measured as 0 lines via $( ) against 54 lines via a
direct call.

arch_sysctl.sh STAYS on the coverage allowlist: it still reports "kcov
instrumented no lines" through the jail, while ubuntu_perf_more.sh
measures 32/32 in the same worktree and the same invocation. The tests
are real and green; the coverage number is not yet obtainable, and the
exemption may only come off once it is.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 20:54:47 +02:00
afe6ac3a33 Reformat three fixes libs with shfmt ahead of coverage work
shfmt runs on every staged shell file and rewrites drifted libs, which
moves coverage denominators and invalidates measurements taken minutes
earlier. Landing the reformat first makes every number measured from
here the number that survives pre-commit.

thorium_repairs.sh converts from 2-space indent to tabs; the other two
only lose runs of blank lines. `git diff -w` shows no token changed,
shellcheck is clean, and the 20-file suite stays green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 20:22:23 +02:00
a2b235210f Handoff: 8 libs left; record the array-literal exclusion
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Python tests / test (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
Updates state after arch_perf_fixes.sh and ubuntu_perf_more.sh landed:
allowlist 98 -> 91, seven libs cleared, 14 commits, and a fixes/lib/tests
suite of 22 files and ~330 assertions.

Adds the second instrument finding of the session to the list a future
session must know about: multi-line ARRAY LITERAL elements and their closing
paren are not statements, because bash reports the whole assignment at its
opening line. That took arch_perf_fixes.sh 93.48% -> 100%, and it is
load-bearing for the work that remains -- thorium_repairs.sh has four such
arrays and ubuntu_perf_fixes.sh one.

Also flags that the seven libs measured by an EARLIER session (dwm_config,
aw_autostart, rpi_nc_install, transcribe_*, clean_audio_filters,
pacman_hook_stall_setup) all predate both instrument fixes, so their recorded
percentages are stale and several may already be at 100%. Re-measure before
writing a single test for them.

Drops the "Not caused by this campaign" note about the red Python tests CI to
stay under the 250-line cap; it is unchanged and already in project memory.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 20:15:55 +02:00
28f2925c30 Instrument: multi-line array elements are not statements; clear arch_perf_fixes
Fourth flavour of defect (a) found this session, after multi-line quotes,
`} |` and the backslash-continued assignment. bash reports a multi-line array
assignment at its OPENING line and never emits the element lines or the
closing paren, so kcov instrumenting them inflates the denominator:

    +L3 items=('one' 'two')      # opened line 3, closed line 6
                                 # lines 4, 5, 6: never emitted

The rule is therefore symmetric with the existing multi-line-quote case: the
opening line is the statement, everything up to the closing paren is data.
_closes_array() finds that paren by recomputing quote state per candidate, so
an element like "a(b)" does not end the literal early.

Measured effect through fixes/lib/tests/run_all.sh:

  arch_perf_fixes.sh  93.48% -> 100.00%  (43/43)
  bt_audio.sh        100.00% -> 100.00%  (127/127)
  arch_perf_report.sh 100.00% -> 100.00% (59/59)
  arch_perf_probes.sh 100.00% -> 100.00% (93/93)
  ubuntu_perf_more.sh 100.00% -> 100.00% (32/32)
  bt_report.sh       100.00% -> 100.00%  (37/37)
  bt_pairing.sh      100.00% -> 100.00%  (65/65)

One gained, six held, none went DOWN. Acceptance test unchanged:
dot_resolver_install.sh 39/39 and rpi_nc_ca.sh 73/73. arch_perf_fixes.sh
therefore comes off the allowlist in the same commit, confirmed by the real
gate with no exemption.

The fail-open check, since over-detection INFLATES coverage: the old and new
predicates were diffed over every allowlisted lib plus the six cleared ones,
printing each newly excluded line WITH its text. All 91 across 10 libs are
array elements or closing parens -- common.sh's tool tables, packages.sh's
associative arrays, arch_sysctl.sh's sysctl maps, thorium_repairs.sh's four
path lists, ubuntu_perf_fixes.sh's sssd units, and so on. No statement caught.

Tests cover both directions, including three negatives: a single-line
`x=(a b)`, an element containing a parenthesis, and `x=$(echo hi)` which is a
command substitution rather than an array. Module stays at 100% branch
coverage.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 20:13:45 +02:00
0c92a00f0f Test arch_perf_fixes.sh to 93.48% and fix the journal regex a third time
Eighth of the 16 untested fixes/lib libs. 22 assertions; 43/46 = 93.48%. The
lib STAYS on the allowlist -- see the artifact below.

Third instance of the same dead branch. Line 16 matched on
`([0-9]+\.?[0-9]*)\ G`, a required space before the unit, while journalctl
prints "4.2G" with no separator, so the vacuum could never run. Fixed to an
optional space, as in arch_perf_report.sh.

This one differs from that earlier fix and the difference was confirmed with
the user before landing: arch_perf_report.sh's vacuum sits behind
--apply-safe-fixes, but THIS one runs whenever fix_arch_performance.sh runs.
So the fix makes an unflagged destructive action live -- the script will now
really vacuum the journal to 300M once it passes a gigabyte. That is the
function's evident intent, since its next act is to write a permanent 300M
cap, and the user approved it explicitly.

Three absolute paths moved behind overrides defaulting to the real ones:
JOURNALD_CONF_DIR, SYSTEMD_UNIT_DIR (fix_media_organizer writes
/etc/systemd/system/media-organizer.service) and ORGANIZE_SCRIPT_CANDIDATES.
Verified afterwards that the real unit file still carries its 2026-07-25
mtime and the journald drop-in its 2026-03-02 one, i.e. a bare un-jailed
run_all.sh touched neither.

The three uncovered lines (68-70) are the element lines of a multi-line array
literal. `PS4` + `set -x` on a minimal case shows bash reporting the whole
assignment at its OPENING line and never emitting the elements or the closing
paren, so they are data, not statements -- a fourth flavour of defect (a),
after multi-line quotes, `} |` and the backslash-continued assignment. The
array is provably used: the loop on the next line iterates it and the
media-organizer assertions pass.

Worth fixing, unlike the bt_adapter one-liner: the form appears in three of
the remaining untested libs (thorium_repairs.sh has four) and in nine
allowlisted libs repo-wide. That lands as its own commit next.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 19:34:12 +02:00
99a9804d75 Test ubuntu_perf_more.sh to 100%: allowlist 93 -> 92
Seventh of the 16 untested fixes/lib libs and the first of the ubuntu-perf
pair, which gets its own harness here. 24 assertions; 32/32 = 100.00%
through run_all.sh on the first measurement, confirmed at --min 100 (exit 0),
then cleared with the real gate and no exemption.

Two absolute paths had to move behind env overrides, defaulting to the real
ones: fix_journal writes /etc/systemd/journald.conf.d/size-limit.conf and
run_undo globs /root for undo scripts. Binding those in the jail was rejected
for the same reason as bt_pairing.sh's udev rule -- run_all.sh runs UN-jailed
in ci_mirror.sh and in CI, so a bind mount protects the coverage run and
nothing else. JOURNALD_CONF_DIR and UNDO_DIR follow the UDEV_RULES_DIR
precedent.

Proof the suite is safe where it runs un-jailed: after a bare run_all.sh the
real /etc/systemd/journald.conf.d/size-limit.conf still carries its 2026-03-02
mtime, a genuine artifact of a past production run, and no
undo_ubuntu_performance_*.sh exists in /root.

Worth noting for the rest of the family: run_undo ends in `exit`, so its cases
run inside an explicit subshell. A command substitution already provides one,
so the exit ends only that subshell rather than the whole test file.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 19:25:21 +02:00
d8c4a84470 Handoff: apply prettier formatting
The pre-push prettier hook rejected the hand-formatted markdown, which the
handoff itself warns about. Content unchanged; still exactly 250 lines.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 19:13:58 +02:00
976a111651 Handoff: 10 libs left, and the traps that cost this session time
Rewrites the handoff for the state after five libs were cleared (98 -> 93).

Corrections to the previous handoff, both of which cost time to discover:

- the "arch perf six" do NOT share one entry script. They span four:
  optimize_arch_desktop.sh, diagnose_arch_performance.sh,
  fix_arch_performance.sh and nvidia_troubleshoot.sh. The table now names
  the owner of each remaining lib.
- `_t_unstub` was described as already existing in the pacman harness. It did
  not exist anywhere. It does now, in lib_test_core.sh, along with _t_hide,
  _t_stub_stdin, _t_stub_cat and _t_stub_writes.

Also corrects an arithmetic slip in this session's own commit messages: they
read "95 -> 93" and so on, one low, because they counted total file lines
rather than entries (the allowlist holds 13 comment lines). The diff against
503ba1fc is the authority: five removals, 98 -> 93. Noted in the handoff so
the next session does not inherit the drift.

New material worth carrying forward:

- work the jail in a detached worktree, copying one-way INTO it. Copying out
  is how this session silently reverted its own uncommitted harness edit,
  twice, and briefly misattributed it to another agent.
- shfmt reformats staged shell files and WILL change a lib's denominator. It
  rewrote bt_audio.sh's one-line blocks and invalidated a 100% measurement
  taken minutes earlier. Re-measure after pre-commit touches anything.
- the backslash-continuation predicate is narrower than "has a backslash":
  only a continued ASSIGNMENT caps a lib, because bash attributes those to
  the last line of the run and a continued COMMAND to its first.
- two production bugs were found by writing tests, both dead branches. Check
  whether an untestable-looking branch is reachable at all before working
  around it.
- a background commit reported "completed (exit code 0)" while the commit
  itself had aborted on the file-length cap. Check the result, not the
  notification.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 19:10:05 +02:00
fa7b05da74 Test arch_perf_probes.sh to 100%: allowlist 93 -> 92
Sixth of the 16 untested fixes/lib libs, and the first with no dead branch to
fix -- the whole job was test-writing. 43 assertions across two files;
93/93 = 100.00% through run_all.sh, twice, the second at --min 100 (exit 0),
then cleared with the real gate confirming and no exemption.

The one genuine gap was check_memory_pressure's high-swap branch (lines
158-159), which fires only when swap is heavily used WHILE RAM is still
available -- a state this host does not happen to be in. The lib reads the
absolute /proc/meminfo, but every read goes through `awk`, so stubbing awk
supplies controlled figures without touching /proc: the stub answers on the
pattern being matched and execs the real awk for anything else. Both
directions are covered, including RAM genuinely exhausted, which must NOT be
flagged because it is not the stutter signature.

Everything else here is branch coverage of probes whose inputs are external
commands: failed systemd units, ACPI error counts, a CPU-hungry Xorg,
governors all-performance vs one-powersave vs unsupported, thermal
throttling excerpts, the TLP/power-profiles-daemon conflict in all three
combinations, and storage health with and without fstrim/smartctl.

lib_test_core.sh gains _t_stub_cat. "Print this fixture file" is by far the
commonest stub shape, and writing it inline forces every call site to embed
a literal ${LIB_TEST_DEV} that must not expand at write time -- SC2016 on
every use. Passing the fixture NAME as data removes the class outright, and
two earlier bluetooth test files are simplified onto it. All 21 test files
and three harnesses now lint clean with no suppression anywhere.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 19:04:50 +02:00
c309c95f5a Clear bt_audio.sh and arch_perf_report.sh: allowlist 95 -> 93
Both were already tested to their reachable ceiling earlier in this session
(a5b6663c, ffcf99f1) and held below 100% only by the closing-brace artifact
that d989cd7e removed. With the instrument corrected they measure:

  bt_audio.sh          127/127 = 100.00%
  arch_perf_report.sh   59/59  = 100.00%

both at --min 100 with exit 0, and check_shell_coverage.sh returns
"every checked shell library meets the coverage bar" with their allowlist
lines already gone, i.e. with no exemption. bt_report.sh and bt_pairing.sh
were gated in the same run to confirm the two libs cleared earlier did not
regress.

Note that the closing-brace exclusion is now load-bearing: reverting
d989cd7e without also restoring these two lines would turn every subsequent
commit red.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 18:40:05 +02:00
d989cd7ebf Coverage instrument: a closing brace plus an operator is not a statement
continuation_lines() excluded the continuation lines of multi-line QUOTED
arguments but nothing else, so a line holding only a group's closing brace
and an operator -- `} |`, `} >>"$REPORT_FILE"` -- stayed in the denominator
while bash attributed no statement to it. That capped four fixes/lib libs
below 100% with no test able to move them.

Why the anchor makes this safe: bash attributes every command INSIDE a group
to its own line, and a pipe's right-hand side to its own line, leaving the
brace-plus-operator line with nothing. Anchoring the pattern on a LEADING
`}` therefore excludes only lines that can hold no statement. A one-liner
`{ echo a; } >file` begins with `{` and is untouched; a bare `}` closing a
function has no operator and is untouched.

Measured effect, all through fixes/lib/tests/run_all.sh:

  bt_audio.sh          96.97% -> 100.00%  (127/127)
  arch_perf_report.sh  98.33% -> 100.00%  (59/59)
  bt_report.sh        100.00% -> 100.00%  (37/37)
  bt_pairing.sh       100.00% -> 100.00%  (65/65)
  bt_adapter.sh        98.55% ->  98.55%  (68/69, capped by a different flavour)

Two gained, three held, none went DOWN -- the handoff's regression signal.
That is not luck: _measure computes covered_set = (executed|traced) &
denominator, so for a lib already at 100% the covered set IS the denominator
and removing a subset cannot lower it. The five gated pacman_hook_stall libs
are safe by the same arithmetic.

Acceptance test from the handoff passes unchanged: dot_resolver_install.sh
39/39 and rpi_nc_ca.sh 73/73, both 100.00%.

The fail-open check that actually matters, since over-detection INFLATES
coverage and could promote an untested lib: the new predicate was run over
every lib in the allowlist plus the cleared ones, printing each newly
excluded line WITH its text. All 17 across 10 libs are genuine
brace-plus-operator lines; no ordinary statement was caught.

Tests cover both directions, including the two negative cases (a bare `}`
and a single-line `{ ...; } >file`), keeping the module at 100% branch
coverage. The quote scanner moved into _quote_after() to stay under the
C901 complexity limit rather than suppressing it.

Deliberately NOT fixed here: the backslash-continued ASSIGNMENT flavour that
caps bt_adapter.sh line 97. bash attributes those to the LAST line of the run
but a backslash-continued plain COMMAND to its FIRST, so that predicate needs
a command-vs-assignment distinction. One line in one lib; not worth the
landmine today.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 18:29:47 +02:00
ffcf99f102 Test arch_perf_report.sh to 98.33% and fix its dead journal-size check
Fifth of the 16 untested fixes/lib libs and the first of the arch-performance
group, which gets its own harness here. 38 assertions across two files. The
lib STAYS on the allowlist at 59/60 = 98.33%, measured twice.

The second dead branch this campaign has found, fixed here. Lines 36 and 65
matched on:

    ([0-9]+\.?[0-9]*)\ (G|M)

a REQUIRED space before the unit. journalctl actually prints "Archived and
active journals take up 305.5M in the file system." with no separator --
verified against the real binary on this machine. So check_journal_size could
never report a large journal and apply_safe_fixes could never vacuum one:
both were unreachable. The space is now optional, and tests cover the spaced
and unspaced forms so neither can rot.

NOTE: this makes a previously-dead DESTRUCTIVE action live. With
--apply-safe-fixes and a journal over a gigabyte, the entry script will now
really run `journalctl --vacuum-size=300M`. That is the flag's documented
purpose and it stays behind the flag, but it has never actually executed
before today.

Line 20, the one uncovered line, is `} >>"$REPORT_FILE"` -- the closing brace
of a redirected group. A minimal probe writes both inner lines to the file
while bash attributes no statement to the brace, and the report assertions
independently prove the group runs, since they read the text it writes. Same
defect (a) class as bt_audio's `} |`.

That form now caps four libs: bt_audio.sh, arch_perf_report.sh, and
arch_perf_probes.sh and nvidia_config.sh which are still untested. So the
continuation_lines() fix is worth landing after all -- as its own commit,
next, so a denominator change can be reverted without taking these tests
with it.

_t_hide and _t_full_path move from bt_harness.sh into lib_test_core.sh: they
are generic PATH plumbing and the arch harness needs them for the
"nvidia-smi is not installed" branch. All twelve existing suites re-run green
after the move.

One trap worth recording: apply_safe_fixes appends to the ACTIONS array, so
it must be called directly rather than inside "$(...)" -- a command
substitution runs it in a subshell where the appends die with it, and the
assertions read an empty array.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 18:06:57 +02:00
a5b6663c02 Test bt_audio.sh to 96.97% and fix its wpctl health check
Fourth of the 16 untested fixes/lib libs, the largest at 214 lines, and the
last of the bluetooth family. 47 assertions across three files. The lib
STAYS on the allowlist: 128/132 = 96.97%, twice with the same line set.

The bug the tests found, fixed here. Line 21 read:

    if timeout 3 _run_as_user wpctl status &>/dev/null; then

`timeout` is a binary and `_run_as_user` is a shell function that is never
exported, so this always failed with rc=127 -- "timeout: failed to run
command '_run_as_user'". check_pipewire_health therefore reported PipeWire
hung on EVERY run and restarted a healthy audio stack every time
fix_bluetooth.sh ran. The healthy branch was unreachable, which is why the
test for it could not be written without first noticing. Now
`_run_as_user timeout 3 wpctl status`: same bound, inside the sudo'd command.

Why 96.97% and not 100%. An earlier run of this suite read 99/99 = 100.00%,
and that number was wrong -- it measured the file before pre-commit's
`shfmt -w` reformatted it. shfmt rewrites the `{ ...; } \` + `| bluetoothctl`
one-liners into multi-line blocks ending in `} |`, which raises the
denominator 99 -> 132. Confirmed unavoidable by running shfmt against HEAD's
own copy: it rewrites there too, so reverting the reformat is not stable.

The four uncovered lines (90, 113, 137, 157) are each that `} |` -- the pipe
operator joining a block to bluetoothctl, not a statement. They do execute:
a `{ echo a; echo b; } | consumer` block writes every marker to a file even
though bash's xtrace never reports the left-hand side, because a pipe's LHS
runs in a subshell whose xtrace is not captured. kcov instruments them and
cannot attribute them; defect (a) in docs/kcov-under-report.md, third flavour.

Scope, measured: the continuation-pipe form appears ONLY in bt_adapter.sh
(pre-format) and bt_audio.sh (post-shfmt). None of the remaining twelve
untested libs carries either, so this does not block the campaign and the
detector fix stays off the critical path.

Also worth 90.91% -> 96.97% on its own: the bluetoothctl stubs now drain
stdin before exiting. Real bluetoothctl consumes its whole input; a stub
that read one line and exited closed the pipe early, so the writing block
took SIGPIPE partway through and its later lines never ran.

NOTE for whoever edits this file next: bt_audio.sh is now exactly 250 lines,
at the cap. The next change to it needs a split, not a comment trim.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 17:52:24 +02:00
434cb7587e Test bt_adapter.sh to 98.55%; line 97 is unreachable by construction
Third of the 16 untested fixes/lib libs, and the first that does NOT come
off the allowlist. 68/69 = 98.55%, up from 45/69. The remaining line is
not a missing test:

  PS4='+TRACE:${BASH_SOURCE##*/}:${LINENO} ' bash -x

shows bash attributing the whole multi-line dbus-send assignment in
_services_resolved to line 100, and never emitting line 97 at all. Line 97
is the OPENING line of a backslash-continued statement; kcov instruments
it, bash never attributes a statement to it. That is defect (a) in
docs/kcov-under-report.md -- a wrong denominator -- and no test can move it.

continuation_lines() in shell_coverage_lines.py already excludes such lines,
but only detects them by tracking QUOTE state, so a line ending in an
unquoted backslash slips through. Fixing that is deliberately left out of
this commit: it changes the denominator for every measured lib, and if it
regresses one of the libs now gated with no exemption, reverting a mixed
commit would throw away these tests too.

Scope of the problem, measured rather than guessed -- backslash
continuations are confined to the bluetooth family: bt_audio.sh 10,
bt_adapter.sh 7, bt_pairing.sh 3, pacman_hook_stall_summary.sh 2, and ZERO
in the other 12 remaining libs. So this caps bt_audio.sh next and then stops
mattering.

Also replaces the harness's _t_only_path with _t_hide. _t_only_path dropped
PATH to $FAKE_BIN alone, which hid grep, head and sort as well as the tool
under test -- so the "usbreset is not installed" case died in a cascade of
"command not found" and passed for the wrong reason instead of exercising
the fallback. _t_hide rebuilds PATH from symlinks to every real executable
except the named ones; verified directly that command -v usbreset is then
empty while grep and head still resolve.

bt_report.sh (37/37) and bt_pairing.sh (65/65) re-measured at --min 100,
both exit 0, so neither cleared lib regressed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 17:10:15 +02:00
0e9cc0ce95 Test bt_pairing.sh to 100%: allowlist 97 -> 96
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
Second of the 16 untested fixes/lib libs. 65/65 = 100.00% through
run_all.sh, twice, the second at --min 100 (exit 0), then cleared from the
allowlist and confirmed by the real gate with no exemption.

Two findings worth keeping:

- udevadm was NOT in the harness's stub list, so `udevadm control
  --reload-rules` was reaching the REAL binary during the suite. A
  prepended stub dir cannot hide a tool the host actually has. Caught by
  asserting on the recorded call rather than by reading the code, which is
  the argument for asserting on calls at all.

- _disable_usb_autosuspend writes /etc/udev/rules.d/50-bluetooth-no-
  autosuspend.rules. Binding /etc in the jail would have covered it, and
  was rejected: run_all.sh runs UN-jailed in ci_mirror.sh and in the
  shell-tests workflow, as its own header says, so a bind mount protects
  the coverage run and leaves every bare run writing to a real root-owned
  file. Instead the lib gained a UDEV_RULES_DIR override, defaulting to the
  real path -- the same env-override seam pacman_hook_stall_harness.sh uses
  for PACMAN_LOG/CACHE_DIR/PACMAN_LOCK.

Proof the suite is safe where it runs un-jailed: after a bare run_all.sh,
the real rule file still has its 2026-02-21 mtime (it is a genuine artifact
of a production run six months ago) and the probed power/control values are
unchanged. The jail cannot give that check.

fix_usb_autosuspend globs the real /sys/bus/usb/devices/*/ with no override,
so its branches are driven through stubbed lsusb output: ffff:ffff matches
nothing on any machine and reaches the not-found arm, while 046d:c077
(control=on) and 046d:0825 (control=auto) are read-only probes, each guarded
so the case self-skips with a note if the host state changes rather than
silently asserting nothing.

Split across two test files to stay under the 250-line cap; run_all.sh globs
test_*.sh, so splitting costs nothing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 16:47:40 +02:00
4cfc3fdde1 Test bt_report.sh to 100%: allowlist 98 -> 97
First of the 16 untested fixes/lib libs. Measured 37/37 = 100.00% through
lib/tests/run_all.sh, twice, the second run at --min 100 (exit 0), then
removed from the allowlist and confirmed with the real gate and no
exemption.

Adds two reusable pieces rather than a per-family harness clone:

- lib_test_core.sh -- PASS/FAIL tally, _t_eq/_t_contains/_t_lacks, a
  mktemp -d sandbox wiped on EXIT, a FAKE_BIN stub dir on PATH, and
  _t_stub/_t_unstub. _t_unstub runs `hash -r`: deleting a stub file alone
  does not drop bash's cached executable path, so the real binary would
  never be reached again.
- bt_harness.sh -- sources the core, sources the real scripts/lib/common.sh
  for the production log_*/has_cmd helpers (verified inert at source time),
  and redefines _btctl and apply_fix verbatim from fix_bluetooth.sh, since
  those live in the entry script rather than in any lib. Same trade-off
  pacman_hook_stall_harness.sh already makes with log_size.

pacman_hook_stall_harness.sh is deliberately left alone: its six libs are
already off the allowlist, i.e. gated at 100% with no exemption, so
refactoring it onto the new core would risk banked work for no gain. jscpd
reads 1.6% against the hook's own flags, and **/lib/tests/** is excluded
from that scan anyway, so the duplication budget is not at stake.

_t_only_path exists because every tool these libs call (usbreset, pactl,
lsusb, ...) genuinely exists on an Arch desktop: a prepended stub dir
cannot exercise a "not installed" branch, so those cases drop PATH to
FAKE_BIN alone.

The three coverage runs were made in a detached worktree: a second session
was writing to this repo concurrently, and the jail aborts on any
working-tree delta during a run.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 16:33:33 +02:00
98ca3ac56a Whitelist com.kuhy.lyricanki in focus mode
Focus Owner hides every package absent from the allowlist, so a newly
installed lyricanki was installed=true but hidden=true: absent from the
launcher and from `pm list packages`, and `am start` reported the activity
did not exist even though dumpsys listed its MAIN/LAUNCHER filter. Nothing
about the app itself was wrong.

policy.json is regenerated from config.sh by python_pkg.focus_policy, never
hand-edited.

Also drops com.android.launcher3 and com.android.camera2 from
SYSTEM_NEVER_DISABLE. That list is prefix-matched and both are strict
supersets of entries already in it, so coverage is byte-identical; this
keeps config.sh under the 250-line cap without weakening the policy.
com.android.settings stays: its only shorter match is com.android.se, an
accidental substring rather than intent.

Verified on the phone: signer matched so the Device Owner upgraded in
place, dpm still reports DeviceOwner, lyricanki flipped to hidden=false,
and workout_app + the dialer are untouched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RAEChhK3sWGxd6ucsUQmcT
2026-08-22 16:26:52 +02:00
503ba1fcca Handoff: the 16 untested fixes/lib libs, ordered smallest-first
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
Retargets the handoff from 're-measure the allowlist' (done) to the work that
is actually left: writing test suites for the 16 libs in fixes/lib that have
none, to 100% line coverage.

Includes the size-ordered table, the family groupings (bluetooth four, arch
perf six, hosts guard two) so shared stubs get reused, the two entry scripts
that source them, and what they actually call -- systemctl, bluetoothctl,
pacman, sysctl, nvidia-*, apt-get.

Says explicitly NOT to build a new harness: fixes/lib/tests already has a
205-line lib harness, a 142-line entry harness and eight test files to copy
from, and jscpd fails the commit above 2% duplication.

Records the three-step bar the five cleared libs met -- measure 100.00%,
re-measure at --min 100, then run the real gate with no exemption -- so the
next session does not have to re-derive why one reading is not enough.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 16:11:13 +02:00
105d869776 Handoff: record the five cleared libs and the bar used to clear them
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
Allowlist 103 -> 98. Each of the five was measured twice, the second run
gating at --min 100, then confirmed through the real check_shell_coverage.sh
with no exemption -- all exit 0.

States the reusable bar explicitly (two matching runs, the second at
--min 100, then the real gate) so the next session does not have to re-derive
why one reading is not enough.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 15:06:43 +02:00
83de41f470 Clear five pacman_hook_stall libs: allowlist 103 -> 98
Each measured 100.00% through fixes/lib/tests/run_all.sh, twice, with the
second run gating at --min 100 so a shortfall would exit non-zero rather than
print a number I might misread:

  pacman_hook_stall_capture.sh   59/59
  pacman_hook_stall_load.sh      25/25
  pacman_hook_stall_summary.sh   18/18
  pacman_hook_stall_watch.sh     24/24
  pacman_hook_stall_usage.sh       1/1

Two matching runs was the bar because this directory's suites drive
watch_forever timing loops, and a timing-dependent suite can vary its line
set between runs -- dwm_config.sh was observed doing exactly that. These five
did not vary.

pacman_hook_stall_setup.sh stays: 26/27 = 96.30%, uncovered line 7.

usage.sh's denominator of 1 is honest rather than broken. The lib is a single
usage() whose body is one `cat <<EOF` heredoc plus `exit 0`, and heredoc
content is data, not statements. Its tests assert on the rendered text, so
the behaviour is exercised even though only one line is instrumentable.

summary.sh has one off-set line (36). That cannot inflate the figure -- an
off-set line is by construction one the trace SAW EXECUTE -- but it does mean
the lib is measured over a subset of its statements.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 14:57:01 +02:00
f65d247c23 Record the fixes/lib measurements and two traps that each cost a run
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Python tests / test (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
Adds the measured table so the next session starts from fourteen known
numbers instead of re-deriving them. Seven libs are at 100.00% and are
allowlist-removal candidates; they are deliberately NOT removed yet, because
fixes/lib's suites drive watch_forever timing loops and a timing-dependent
suite can vary its line set run to run (dwm_config.sh was seen to). Reproduce
each at --min 100 twice before editing the allowlist.

Also settles a question the run_all.sh commit raised: allowlist entries are
static per-file lines, so adding fixes/lib/tests/run_all.sh did NOT start
failing the 16 untested libs there. check_shell_coverage.sh on one of them
still exits 0. The allowlist header's "every file in that directory is
enforced" describes intent, not current mechanics.

Two traps recorded, both hit this session:

- Editing ANY file while a measurement runs aborts it with "a write escaped
  the jail". The jail fingerprints git status before each case, so an
  unrelated doc edit trips it. False alarm; cost two runs, the second time
  after I had already diagnosed the first.
- A sweep's output file buffers, so pgrep is the liveness signal, not file
  growth. A measurement silent for minutes is usually still running.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 14:48:06 +02:00
347222b921 Add fixes/lib run_all.sh; the previous handoff was wrong about that directory
The handoff recorded fixes/lib as having "no harness at all". It already had
8 test files and 2 harnesses. What was missing is run_all.sh -- the subject
is_covered() actually builds, and the only thing the gate measures through.
All 8 test files pass through it.

No jail_args beside it, deliberately: the harness confines every write to its
own `mktemp -d` and intercepts external commands with a PATH stub dir, and
grep finds no absolute write to /etc, /var or /usr in any of the tests. So it
runs bare, like the transcribe suite.

First measurement through it: pacman_hook_stall_usage.sh is 1/1 = 100.00%.
That denominator is honest, not broken -- the lib is a single usage() whose
body is one `cat <<EOF` heredoc plus `exit 0`, and heredoc content is data
rather than statements.

16 of the 22 libs there still have no tests at all. That is now the largest
block of real test-writing work left in the campaign.

Also rewrites NEXT_SESSION_PROMPT.md, whose central claim ("the instrument is
the bottleneck, not the tests") stopped being true this session. The new one
leads with re-measuring the 103 allowlisted libs on the fixed instrument
before writing any new test.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 14:40:31 +02:00
d58910d916 Apply prettier formatting to docs/kcov-under-report.md
The pre-push prettier hook rejected the table and list formatting introduced
by the two preceding commits. Formatting only -- no content, number or claim
is changed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 14:35:35 +02:00
11aea86920 Land the token_audit standing-cost checkup (116 tests, 100% branch coverage)
Answers "what is billed on every turn regardless of use" by measurement
instead of recall, which is the part earlier audits kept getting wrong.

A surface is reported dead only when unused in BOTH windows. One earlier
audit's seven-day dead list included six servers that had been used within
thirty days, so a single window is not evidence. Shares are weighted with
cache-read weight 0.1, so a cached surface is not billed as though it were
re-read in full each turn.

Verified by running it, not just by tests: the report renders over 44,311
turns, putting rules/ at 4,907 tokens (1.77%), MEMORY.md at 4,312 (1.55%),
memories/ at 3,758 (1.35%), skill descriptions at 3,279 (1.18%) and CLAUDE.md
at 2,057 (0.74%), with per-MCP 7d/30d call counts behind each verdict.

The files were found untracked in the tree from an earlier session; every
module is already under the 250-line cap, so nothing needed splitting, and
the package was already at 100% branch coverage, so nothing needed new tests.
This lands the instrument only -- no surface is unregistered on its say-so.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 14:33:03 +02:00
29b8c5a788 Name the lines outside kcov's line set; bound defect (c) as fail-closed
The report printed a COUNT of traced lines that kcov never listed as
instrumentable. A count cannot be acted on: deciding whether such a line is a
real statement or a function declaration needs the line number. It now lists
them, the way it already lists uncovered lines.

Reading them across every lib with a harness splits them cleanly:

  benign  dwm_config.sh:27 (`heal_config() {`), transcribe_deps.sh:9
          (one-line function declaration), clean_audio_filters.sh:197,200
          (`((running++))`) -- correctly not statements
  real    aw_autostart.sh 68,70,73,79-81,83-84,87-88,94 -- plain echo, local,
          if, `sudo -u ... mkdir`, `cat >` heredoc. kcov lists nothing after
          the `{ ... } >>"$file"` command group at lines 61-65.

So kcov's LINE SET is incomplete too, not just its hit counts. This does NOT
inflate anything: a line reaches that list only because the TRACE SAW IT RUN,
so folding all 11 into both halves moves aw_autostart from 80/82 = 97.56% to
91/93 = 97.85% -- up. An off-set line is by construction an executed line, so
it can only ever be a missing COVERED line, never a missing uncovered one.

What it does mean is that such a subject is measured over a subset of its
statements. The percentage is honest about the subset, not the whole file,
which is why the lines are now printed rather than tallied.

Separately: nc_php.sh reports "kcov instrumented no lines" on the PRE-FIX
instrument too -- checked at 078d3463 in a throwaway worktree -- so it is not
a regression from the two-pass change. The 84/85 = 98.82% in earlier notes
does not reproduce and is recorded as unverified.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 14:30:39 +02:00
81191f40e6 Fix both kcov defects: dwm_config 47.95% -> 98.48%, rpi_nc_install 11.36% -> 96.59%
The instrument, not the tests, was the bottleneck. Coverage is now
(PS4-traced lines | kcov hits) & (kcov line set - continuation lines).

The trace deliberately does NOT supply the denominator. A trace reports only
lines that RAN, so using it for both halves would make every subject 100.00%
and arm a repo-wide gate that checks nothing.

Three measured findings, each of which yields a silently wrong trace:

1. kcov's ptrace and bash's xtrace cannot share a process. Under
   SHELLOPTS=xtrace every line kcov recorded as hits="1" comes back hits="0"
   -- reproduced A/B on one subject. Hence two passes, two namespaces.
2. SHELLOPTS is readonly inside bash, so `export SHELLOPTS=xtrace` fails and
   tracing never turns on; and `set -x` does not reach child processes.
3. Decisive: bash under `unshare --map-root-user` runs PRIVILEGED and
   DISCARDS an inherited PS4, falling back to "+ " while still honouring
   xtrace. The trace loses its file:line prefix and every subject reads 0%.
   Fixed by delivering PS4 and `set -x` through a BASH_ENV file, which also
   solves child-process propagation.

A fourth trap, in the report: kcov records filename="dwm_config.sh", a bare
basename. The source path comes from the trace's ${BASH_SOURCE} or a unique
repo search; an ambiguous basename yields no exclusion rather than a guess.

Measured through run_all.sh, nothing down:

  dot_resolver_install.sh  39/39 = 100.00%  (acceptance, unchanged)
  rpi_nc_ca.sh             73/73 = 100.00%  (was 72/73 = 98.63%)
  dwm_config.sh            65/66 =  98.48%  (was 35/73 = 47.95%)
  rpi_nc_install.sh        85/88 =  96.59%  (was 10/88 = 11.36%)

rpi_nc_ca reaching 100% is the load-bearing check: its missing line 141 was
cross-process contagion, and the trace pass has no kcov in it to contaminate.

dwm_config's remaining line 39 is a `done < <(...)`. Left in the denominator
on purpose -- removing lines inflates coverage, the fail-open direction, so a
second exclusion rule needs per-line justification, not a pattern from one lib.

Both new Python modules hold 100% branch coverage (29 tests).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 14:24:25 +02:00
078d3463bd Prove kcov's under-report is TWO defects, one of them a numerator bug
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
Settles a question the campaign has worked around for three sessions:
rpi_nc_install.sh's 11.36% is an instrument failure, not a testing gap.

Measured against an independent instrument. Driving the lib under
PS4='+PS4:${BASH_SOURCE##*/}:${LINENO} ' with set -x traces 55 distinct lines
as executed, and 45 of them are lines kcov reports as UNCOVERED -- including
61, 62, 63, 66, 68, 102, 118 and 146. The lines run; kcov does not record
them.

That splits the problem in two, and they need different fixes:

  (a) WRONG DENOMINATOR -- continuation lines of a multi-line quoted argument
      counted as statements, which bash -x never calls executable at all.
      Fixable in shell_coverage_report.py. Holds dwm_config.sh down.
  (b) WRONG NUMERATOR -- ordinary statements executing unrecorded. Caps
      rpi_nc_install.sh, and no test can move it.

The distinction is the point. A denominator filter is the obvious fix and I
nearly built one last session; it would have done nothing for (b).

Also confirmed no test can raise rpi_nc_install.sh: the file is one 227-line
function called twice, an `exit 88` sentinel proves the suite runs to
completion, and its assertions on save_config (line 219) and the password
message (line 227) PASS while kcov calls both lines uncovered.

kcov 43 is the current release, so upgrading is not an available fix.

The kcov material moved to docs/kcov-under-report.md (the 250-line cap), and
NEXT_SESSION_PROMPT.md now leads with the instrument work rather than the
next lib -- 201 in-scope libs, 98 passing, 103 exempt, and the instrument is
the bottleneck.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016sxxsDHWgdRhmdmzNMA6XM
2026-08-22 13:57:33 +02:00
bcb3e59fa7 Refresh the handoff: allowlist 105 -> 103, gate is ready, kcov bounded
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
Records what changed this session so the next one does not re-derive it:

- The allowlist dropped to 103. unity_handler.sh and transcribe_venv.sh both
  measure 100% and are off it, verified through check_shell_coverage.sh with
  the exemption deleted rather than by the measurement alone.
- The gate itself is now ready to arm: is_covered() reads jail_args and
  passes --fail-on-case-error. Only the allowlist remains.
- Two directories have harnesses where one had none.
- The kcov problem is bounded, not solved: one artifact CONFIRMED, six
  hypotheses DISPROVEN and listed so nobody retries them.

The trap list is rewritten around what actually cost time: measuring through
run_all.sh rather than a single file, --fail-on-case-error, the exit-sentinel
technique, and the two ways a stub silently fails to hide a tool.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016sxxsDHWgdRhmdmzNMA6XM
2026-08-22 13:47:13 +02:00
0091608b08 Make the gate read jail_args and refuse a suite that dies partway
Two defects found in review, both of which made checks PASS more easily, so
neither ever went red.

GATE: is_covered() hardcoded its jail flags and never read the jail_args
marker that ci_mirror.sh and shell-tests.yml both consume. The features/lib
suite needs /usr/local/share and /etc/pki and aborts under set -e without
them -- but the coverage number still printed, because kcov had already
recorded whatever the dead run reached. The gate would have graded 44 libs on
a suite that never finished. It now reads the marker, keeps the historical
defaults for suites without one, fails closed on an empty marker, and passes
--fail-on-case-error.

Negative control: stripping the binds makes the gate exit 1 and restoring
them returns exit 0. Before this commit both cases exited 0 -- the gate could
not fail on an aborting suite.

HASH CACHE: the _t_unstub helper written earlier today for the transcribe
harness was needed in features_harness.sh too. Two assertions were vacuous --
test_dwm_config's "verify still reports when dwm is absent", and
test_rpi_nc_ca's uname removal, where a cached uname left every later branch
running under a faked Darwin. All four `rm -f "$TEST_TMPDIR/bin/` sites in
the repo were audited; the other two are sound (one probes with [[ -f ]], the
other runs in a subshell).

No measured figure moved: dot_resolver_install.sh still 39/39 = 100.00% with
real absence enforced, so its off-allowlist clearance holds.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016sxxsDHWgdRhmdmzNMA6XM
2026-08-22 13:36:54 +02:00
d277369aca Cover clean_audio_filters.sh (89.25%), completing testsAndMisc-bash/lib
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
A 38-assertion suite for the last lib in the directory without one. Every
one of its five libs now has a suite; at the start of the session it had
none. 118 assertions across the directory, 0 failures.

build_filters is asserted on the EXACT filter string it emits, because that
string is the lib's entire product. An arnndn chain missing its mandatory
48 kHz resample, or a preset silently falling through to no dynamics, yields
worse audio and never an error -- nothing else would catch it.

Every exit code is pinned: 1 for a missing command, 11 for "RNNoise required
but unavailable" (refusing to quietly fall back to afftdn), 8 for an ffmpeg
whose afftdn lacks md=.

Measured 83/93 = 89.25%; it stays on the allowlist. All ten uncovered lines
are the documented under-report, not gaps: an `exit 66` sentinel proves
require_cmd's lines 37-38 execute, 52-58 are a multi-line array literal (the
confirmed continuation-line artifact), and 129 is an empty `*) ;;` arm whose
branch has a passing assertion. The gate uses the measured figure, so the
exemption stands regardless.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016sxxsDHWgdRhmdmzNMA6XM
2026-08-22 13:27:44 +02:00
154b416617 Clear transcribe_venv.sh: 100%, off the allowlist, 104 -> 103
A 29-assertion suite covering all six functions. transcribe_venv.sh measures
53/53 = 100.00% through the directory runner, and check_shell_coverage.sh
passes it with the exemption deleted.

Assertions are on recorded ARGV because which index a pip install points at
IS the behaviour: the OpenNMT cu12 wheel index on the NVIDIA path, the
CPU-only torch index for diarization (forced to avoid mismatched CUDA
builds). "pip was called" cannot see either.

generate_test_audio's four-deep fallback chain is covered by failing each
generator in turn. Every stub materialises the wav, because the chain
advances on `[[ ! -s $tmpwav ]]` -- a record-only stub would silently
exercise the branch after the one under test.

One assertion was wrong and got corrected rather than forced: I claimed a
wholly-failing pip still returns 0, but the final `python "$PY_HELPERS"
deps-installed` carries no `|| log`, so it does not. The suite now asserts
what the subject actually guarantees -- all four warnings emitted, no earlier
failure aborting the run.

SC2016 fixed at the source with a quoted heredoc, not suppressed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016sxxsDHWgdRhmdmzNMA6XM
2026-08-22 13:24:28 +02:00
b91be3099d Clear unity_handler.sh: 100%, off the allowlist, 105 -> 104
The first allowlist removal of the campaign this session. unity_handler.sh
measures 32/32 = 100.00% through its directory's runner, and
check_shell_coverage.sh passes it with the exemption DELETED -- the real
gate, not just the measurement.

HARNESS BUG found getting there: bash caches executable locations in a hash
table, so `command -v foo` keeps succeeding after foo is removed from the
stub dir. Every "tool is missing" test was therefore running as a "tool is
present" test, asserting the opposite of its own name while looking
plausible. Reproduced minimally: after rm, STILL FOUND; after `hash -r`,
gone.

A _t_unstub helper now removes the stub and clears the table. The two suites
committed an hour ago had the same defect and are corrected here --
test_transcribe_pkgmgr.sh goes from 15 to 18 passing assertions, so three of
its checks had been vacuous. This is exactly the failure the campaign exists
to catch, found in its own test code.

`basename` joins the restricted PATH because the SUBJECT calls it; the suite
avoids needing `tail` via a parameter expansion instead, since every binary
in that PATH is one more thing a stub's shebang can trip over.

transcribe_deps.sh (92.31%) and transcribe_pkgmgr.sh (98.00%) re-measured
unchanged and stay on the allowlist.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016sxxsDHWgdRhmdmzNMA6XM
2026-08-22 13:20:54 +02:00
ac1cf57656 Give testsAndMisc-bash/lib a harness; cover transcribe_deps and _pkgmgr
The directory held five allowlisted libs and no tests. It now has a harness,
a runner, and suites for two libs: transcribe_deps.sh (the fourth
hardest-first target, 48/52 = 92.31%) and transcribe_pkgmgr.sh (49/50 =
98.00%). Both stay on the allowlist. 15 + 18 assertions, 0 failures.

No jail is needed here and no jail_args marker is created: every branch turns
on `command -v <manager>` and every install goes through sudo, both
intercepted by a PATH stub dir. Verified the runner exits 0 when invoked
bare, which is how both gates call it.

The harness REPLACES PATH rather than prepending. This host really has
pacman, and a prepended stub dir cannot HIDE a binary, so every "manager not
installed" case would have asserted nothing. `bash` and `env` are in the
private coreutils dir for a non-obvious reason: every stub's
`#!/usr/bin/env bash` shebang resolves through that restricted PATH, and
without them each stub died with "env: 'bash': No such file or directory"
while looking exactly like a coverage gap.

Assertions are on recorded ARGV rather than on the call happening, because
which packages a branch installs is what differs between distros --
pacman gets python-virtualenv where apt gets python3-venv.

Three assertions aimed at the libsndfile branch were REMOVED rather than left
green-but-vacuous: /usr/lib/libsndfile.so exists on this host, so
need_libsndfile is legitimately 0 and lines 19/52/53/55 are unreachable
without a jail that hides the library. The limitation is written into the
suite instead of asserted around.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016sxxsDHWgdRhmdmzNMA6XM
2026-08-22 13:14:02 +02:00
b830734cad Correct the cause of rpi_nc_ca.sh's missing line: it is cross-process
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
The previous commit attributed rpi_nc_ca.sh's 72/73 to a heredoc BODY being
counted in the denominator. That was wrong. Line 141 is `cat <<'EOF'` -- the
heredoc's OPENING line, an ordinary statement. The body starts at 142.

The real cause is that the kcov under-report is contagious across processes
sharing one jail. Bisected over the five sibling suites: run
test_dwm_config.sh before test_rpi_nc_ca.sh and line 141 is lost; run
test_aw_autostart.sh or test_dot_resolver_install.sh first and it is kept.
Alone the CA suite reports 73/73 = 100.00%; through run_all.sh it reports
72/73 = 98.63%. Both figures reproduce twice, so this is deterministic
contamination rather than flakiness.

Nothing is untested: with dwm_config running first, the CA suite still exits
0 with every assertion passing, show_help included. The line executes and is
not traced.

A heredoc-body detector was prototyped and deleted once it showed line 141 is
not a body line -- a fix aimed at the wrong defect.

The operational rule this implies is now written down: is_covered() measures
through run_all.sh, so the runner's number is the lib's coverage, and a
suite's own single-file figure must never be reported in its place.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016sxxsDHWgdRhmdmzNMA6XM
2026-08-22 13:05:52 +02:00
92678c9506 Cover rpi_nc_ca.sh (98.63%) and bind the two paths its suite needed
A 26-assertion suite for rpi_nc_ca.sh, third in the hardest-first order. All
five OS branches are exercised by seeding the marker file each one tests for
inside the jailed /etc, plus a uname stub for Darwin; both NSS stores and all
three Firefox outcomes are covered.

SHARED-FILE BUG: the Debian branch does `mkdir -p
/usr/local/share/ca-certificates` and jail_args bound only /usr/local/bin, so
the suite aborted there under set -e. /usr/local/share and /etc/pki are now
bound. jail_args is shared by every suite in the directory, so all five libs
were re-measured: dot_resolver_install.sh still 39/39 = 100.00%, and
rpi_nc_install.sh, dwm_config.sh and aw_autostart.sh are unchanged. An
over-aggressive mount looks exactly like unreachable code, so this check is
not optional.

That bind also unblocked the runner for the whole directory: with the old
args the run exited 1 before nc_php.sh could be measured at all.

Measured 72/73 = 98.63% through run_all.sh, which is the exact subject
is_covered() builds -- the gate's own view -- so the lib STAYS on the
allowlist. The single test file alone reports 73/73 = 100.00%, both figures
reproduced twice. The one-line delta is line 141, the first line of
show_help's heredoc BODY: not a statement, so the denominator is wrong rather
than a test missing. Excluding heredoc bodies from the denominator is the
next piece of work; it is what stands between this suite and the bar.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016sxxsDHWgdRhmdmzNMA6XM
2026-08-22 12:59:51 +02:00
26afe4390c Cover aw_autostart.sh (82.93%), executing the script it generates
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
A 25-assertion suite for aw_autostart.sh, second in the hardest-first order.

The generated i3blocks status script is asserted by RUNNING it against
stubbed pacman/pgrep across all four of its branches -- uninstalled,
installed-but-stopped, running, installed-via-package -- rather than by
grepping the heredoc's text. A heredoc that emits syntactically broken bash
passes a text check and fails in front of the user.

One assertion was silently testing nothing at first: aw-qt is genuinely
installed at /usr/bin/aw-qt on this host, so the "not installed" case found
the real binary through the PREPENDED stub dir. PATH is now REPLACED for that
one case. The suite went 24-passed-1-failed -> 25-passed-0-failed, and the
gate caught it rather than the number.

Measured 68/82 = 82.93%; it STAYS on the allowlist. The residue is the
`[[ $EUID -eq 0 ]]` false branches, which are unreachable inside the jail
because the process is uid 0 there, plus the documented kcov under-report --
an `exit 44` sentinel proves create_i3blocks_status runs to completion while
its lines 145-162 report zero hits. Third lib to show it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016sxxsDHWgdRhmdmzNMA6XM
2026-08-22 12:49:51 +02:00
768e73249d Cover dwm_config.sh and fix its unreachable upstream-drift warning
A 27-assertion suite for dwm_config.sh, the highest-scored remaining
allowlisted lib. It drives the lib for real inside the jail: rewriting dwm.c
with perl, appending to config.h, compiling with cc and installing into
/usr/local/bin. The generated content is asserted, not just the call.

LATENT BUG, found by writing the test: apply_fullscreen_confine_hook does
`on=$(grep -c 'pconfine-auto on' "$src")`, and grep -c exits 1 when the count
is zero. The caller runs `set -euo pipefail`, so the function aborted at that
line exactly when the count was zero -- which is precisely when the
"setfullscreen/unmanage were likely refactored upstream" warning three lines
below was the thing needed. The warn branch was dead code in the only
situation it exists for. Both call sites now use `|| true`, and the suite
asserts the warning fires.

Measured: dwm_config.sh 35/73 = 47.95%. It STAYS on the allowlist -- the bar
is 100% and it is measured, not asserted.

That number is an under-report. An `exit 43` sentinel proves build_install,
build_pointer_confine, write_session_files and verify all execute inside the
jail while kcov reports their bodies at zero hits. One kcov artifact is now
CONFIRMED against a minimal repro: continuation lines inside a multi-line
quoted argument (the `perl -0777 -pe '...'` blocks) are counted as
statements that never run, which is the wrong denominator. A sixth
hypothesis -- that the exec-ing sudo shim or a pipeline loses the trace --
was tested and disproven. The two-strike time-box on this hunt is spent;
docs/shell-split-verification.md records what is known, including the
exit-sentinel technique for telling a tracing failure from an aborted suite.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016sxxsDHWgdRhmdmzNMA6XM
2026-08-22 12:44:12 +02:00
6ebb3462ab CI: skip the kcov-jail suites instead of failing to install kcov
The previous commit added kcov to the shell-tests apt step on the assumption
it was packaged for Ubuntu. It is not -- CI went red in 34s on "E: Unable to
locate package kcov" -- and upstream ships no prebuilt binary either, so it
would have to be built from source on every run.

CI now skips jail_args-marked suites with a printed reason, the same trade
the arch-tests job already makes for Arch-only tests: declare what this
runner cannot do rather than pretend to check it. Enforcement is not lost --
ci_mirror.sh runs those suites through the real jail on every push, and that
gate is already proven to fail on a broken assertion. An empty jail_args is
still a hard failure.

Simulated over all six discovered runners: 5 PASS, 1 SKIP, none dropped.
Committed with CI_GREEN_SKIP=1, the ci-baseline-green hook's documented
escape hatch for a commit that IS the fix for the red baseline.

Also records the kcov instrument defect in docs/shell-split-verification.md.
rpi_nc_install.sh measures 11.36% while its 29 assertions pass and its writes
land on disk. Five hypotheses are now disproven against minimal
reproductions -- the three from the previous session, plus `cd`-relocation
and a heredoc piped into a stubbed external. The cause is still unknown, so
the rule is documented instead: a suspicious percentage means re-measure, not
re-write the test. The failure only ever under-reports, so it can keep a lib
on the allowlist but can never promote an untested one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016sxxsDHWgdRhmdmzNMA6XM
2026-08-22 12:31:36 +02:00
170f843481 Make the jailed lib/tests gate able to fail, without breaking measurement
Some checks are pending
Pre-commit checks / pre-commit (push) Waiting to run
Shell tests / shell-tests (push) Waiting to run
Shell tests / arch-tests (push) Waiting to run
The jail recorded each case's exit code but reported only timeouts,
discarding every other non-zero status. A suite with a failing assertion
exited 0 through the push gate -- the same blind spot that let an earlier
session ship 2 failing assertions in the nc_php suite. Found by negative
control, not by reading: a deliberately failing assertion still exited 0.

Propagating that status unconditionally was wrong, and caught before landing:
the jail's own usage example passes a `bogus` case that exits non-zero to
cover an error path, so a clean 5/5 = 100.00% run started failing. That is
the mode the 105-lib campaign runs in.

So the behaviour sits behind --fail-on-case-error, default off, passed only
by ci_mirror.sh and shell-tests.yml. Verified in all four quadrants:
measurement + error case = 0, gate + error case = 1, gate + clean suite = 0,
gate + broken assertion = 1.

Both gates also pass --min 0: with no --measure the jail was measuring
run_all.sh itself against its default --min 100 and failing the push at
54.55%, a coverage verdict neither gate asked for. ci_mirror.sh now prints
the jail's output on failure, so a red gate can be diagnosed.

The added flag pushed the jail over the 250-line cap, so the in-namespace
case runner moved to lib/shell_coverage_case_runner.sh, following the
existing lib/shell_coverage_jail_setup.sh split. All four quadrants were
re-run after the extraction.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016sxxsDHWgdRhmdmzNMA6XM
2026-08-22 12:16:18 +02:00
08b58794e2 Teach both lib/tests gates to run jail-requiring suites
ci_mirror.sh and shell-tests.yml discovered every */lib/tests/run_all.sh and
invoked it bare. The features/lib suite refuses to run bare -- that guard is
what stops it rewriting the real /etc -- so the pre-push gate blocked all six
pending commits, and CI would have gone red on the same suite the moment they
landed.

A suite now DECLARES its jail requirement with a jail_args file beside its
run_all.sh, holding the --bind/--seed-* flags it needs. Both consumers branch
on the marker. The 105 still-allowlisted libs were scored on root ops and
system writes, so most future suites will need the jail too; naming the path
in two runners would drift, which is the failure ci_mirror.sh's own comments
say it exists to prevent.

Both branches fail closed: a marker present but empty is an error, not a skip.
Verified the extracted flags reproduce the independently measured
dot_resolver_install.sh 39/39 = 100.00%, and that the other five suites still
pass bare.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016sxxsDHWgdRhmdmzNMA6XM
2026-08-22 12:05:45 +02:00