The last unit over the cap is now github.com/kuhyx/digital-wellbeing, cloned
at ~/digital-wellbeing, and `--warn` is gone from the directory-depth-cap
hook. `check_directory_depth.sh --all` exits 0 with zero violations, down from
46 at the start of the session. That was the point of the campaign.
History was filtered across all three paths the unit has lived at (63
commits); the current path alone holds 2.
The six suites that test this code lived in linux_configuration/tests/ rather
than beside it, so they were filtered separately (24 commits) and merged in as
a second root. A path filter of the unit alone would have left them here,
testing code that had left the repo -- and their names would still have been
in shell-tests.yml's hardcoded arrays, failing CI on missing files.
linux_configuration/lib/common.sh is vendored into vendor/ rather than trimmed
to the four functions actually used: set_actual_user_vars calls two of the
others, so a trim breaks silently. It is in vendor/ and not lib/ because
test_music_parallelism.sh copies the unit's own lib/ into a scratch worktree
while stubbing the shared lib; in one directory the real common.sh overwrote
the stub, and the suite silently measured the wrong library.
Running the callers caught what shellcheck and grep both missed:
check_and_enable_services.sh died with "DW_REPO: unbound variable" because the
definition sat below its first use. It now runs clean and reports ok for every
extracted-unit check.
Two long-standing live defects fixed as a consequence. The pacman-wrapper
drift manifest embeds ABSOLUTE paths and had named deleted scripts/ paths
since the flatten, so the check reported a permanent false "stale or
tampered"; it now verifies, with unchanged hashes proving the extracted bytes
are identical. And the last two stale live references are gone: 8 -> 0.
The two pre-commit excludes for setup_midnight_shutdown.sh are dropped rather
than moved. lsattr shows nothing in the unit is chattr +i any more, and the
fixer hooks leave the file alone when allowed to run.
Removing 80 shell files also shrank the jscpd denominator enough that the
virtualenv/tqdm clones inside the GENERATED .ci-mirror-venv/ tipped the repo
to 2.09% and blocked this commit, which adds no duplication. That directory is
the same vendored third-party shell the ignore list already excludes as
.venv/, just under another name; jscpd walks the working tree rather than the
index, so being untracked did not spare it. Excluded by name: 1.74%.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
161 tracked files, 3.2M. All 158 episodic entries have retrieval_count 0 --
the store was written to and never once read from. Last write 2026-05-28, the
tool is uninstalled, and nothing references it: the only code hit for "hippo"
anywhere in the tree is the blocked domain "wordhippo" in
leechblock_defaults.json.
No .gitignore entry was needed after all. The handoff anticipated one for
hippo.db, which was untracked only because *.db is ignored -- but with the
whole directory gone there is nothing left to ignore.
Tracked files: 1346 -> 1175.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Five live mechanisms were silently pointing at paths that no longer exist.
None of them announced it; each degraded to a log line or a missing file.
- hosts-file-monitor.service is ACTIVE and watches /etc/hosts for tampering,
but its embedded installer path was the pre-flatten scripts/ one. It logged
"Hosts install script not found" 37 times: it detected tampering it could
not repair.
- dns-blocklist-refresh.service (enabled, next run 00:01) named a deleted
single_use/features/ path, as did media-organizer.service under utils/.
- setup_periodic_system.sh read all TEN of its templates from
periodic_background/system-maintenance/, which has held nothing but
untracked .pyc and .coverage residue since system-maintenance was
extracted. Every install of a service, timer or script was reading a file
that was not there.
- /etc/sudoers.d/hosts-install-no-passwd granted NOPASSWD on the old hosts
installer path.
Running the fixed dns unit then caught a bug the static checks missed: under
systemd there is no SUDO_USER and `id -un` is root, so the new resolver
returned /root/hosts-blocker and the service died with "Feed generator not
found". extracted_repo_home() now handles the bare-root case by falling back
to the owner of the lib file itself. Verified across all four invocation
modes: as the user, via sudo, as root with SUDO_USER unset, and with an
explicit *_DIR override.
The service now reports "Feed refreshed and dnsmasq reloaded (189038 lines)".
/etc/hosts is untouched throughout -- still 176888 lines, still chattr +i,
still bind-mounted by its guard.
Live artifacts were patched via validated temp files, never in-place: the
sudoers drop-in was checked with `visudo -cf` before install, and every
original is backed up under /var/tmp/*.pre-{extract,fix}.
Stale live references: 8 -> 2. The 2 that remain name digital_wellbeing
paths and can only be fixed when that unit is extracted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
linux_configuration/periodic_background/hosts/ is now
github.com/kuhyx/hosts-blocker, cloned at ~/hosts-blocker. Clears 5 of the 46
directory-depth violations; the remaining 41 are all digital_wellbeing, so
--warn stays on the depth hook until that unit moves too.
History was filtered across ALL FOUR paths the unit has lived at (hosts/,
linux_configuration/hosts/, linux_configuration/scripts/periodic_background/
hosts/, and the current one). Filtering on the current path alone would have
preserved 1 commit out of 51 -- the flatten moved it recently, so a naive
single --path silently truncates the history to the flatten commit and still
looks fine in `git log | head`.
No source line changed: all 15 files are byte-identical to the copies removed
here. install.sh already resolved its lib/ via BASH_SOURCE.
The six callers now resolve the checkout through a new shared helper,
linux_configuration/lib/extracted_repos.sh, which reads the invoking user's
home from SUDO_USER's passwd entry rather than $HOME -- several of these
scripts re-exec under sudo, where $HOME is /root. A missing checkout fails
loudly with a clone instruction; it is never a silent skip, which is the
failure mode that left screen-locker's self-repair dead for five months after
the 2026-05-15 reorg.
The live blocker is untouched: /etc/hosts keeps its chattr +i, and the guards
load their plugins from /usr/local/share/guard-lib-plugins/ (byte-identical by
md5), not from a repo path.
Verified: 25 tests pass from ~/hosts-blocker; shellcheck clean on the helper
and all six callers; sudo resolution prints /home/kuhy/hosts-blocker;
test_setup_dns_blocker.sh passes; report_live_state.sh --check is byte-identical
before and after, so no new stale references.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
It was untracked until this rename, so the pre-push prettier hook had never
seen it. Table separators and one blockquote marker; no prose changes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Three files starting NEXT_SESSION_ meant neither I nor a future agent could
tell which one to open: a prompt, its reference doc, and an unrelated
installer task all competed for the same name.
Now one file per job, named after the job. RESTRUCTURE_HANDOFF.md carries
the prompt and its reference in a single paste; the header says where to
start and what is superseded. The installer work becomes
INSTALLER_FIX_TASK.md — still a real task, no longer pretending to be the
next session.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
ci-baseline-green also runs inside ci-mirror's clean worktree, so a red main
blocks the very commit that fixes it. CI_GREEN_SKIP=1 has to be set on the
push, not just the commit. Cost a failed push to discover.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Shell tests went red on my last push. test_network_diagnostics.bats sourced
its scripts through $REPO_DIR/scripts/diagnostics, a level the flatten
removed, so setup() failed and all 30 tests errored.
Latent rather than new: the previous run was green only because ci-mirror
aborted before the bats stage. Fixing the concurrency OOM let the gate reach
this suite for the first time since the flatten.
Grepped the tree for the removed scripts/ and single_use/ levels; this was
the last one in tracked code.
Also rewrites the two handoff docs around the units that remain.
CI_GREEN_SKIP=1 because this commit is the fix for the red baseline.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
The push kept failing with "1798 passed" immediately followed by "Killed".
The suite was never the problem: it peaks at ~0.29 GiB against its own 2G
cap. ci_mirror.sh runs pre-commit --all-files and the pytest gate
concurrently, and the pre-commit tree peaks at ~1.75 GiB (mypy and pylint
repo-wide, invisible to /usr/bin/time because it measures only the parent).
The pair wants ~2 GiB at once; the pytest scope has MemorySwapMax=0, so on
a loaded machine it is the one that dies.
Concurrency is now conditional on MemAvailable. Above 4 GiB the fast path
is unchanged. The probe lives in ci_mirror_mem.sh, following the existing
ci_mirror_range/ci_mirror_shell split, which also keeps ci_mirror.sh under
the line cap.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Item 1's "the classifier blocks me" note was stale. Ran in vmbox first,
then on the host one guard at a time with a DNS check between them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
The pre-push gate was failing on a layout that is actually correct. The
script sources ../../lib/common.sh, which is right for where it sits after
the flattening; the test's guard still hardcoded ../lib/common.sh from
before the move, so it reported drift against itself.
The prefix is now read out of the script under test, so the two cannot
desynchronise the next time the tree moves. Verified non-vacuous: rewriting
the script to ../../../lib/common.sh in a throwaway worktree still fails
the guard, and it now names the real prefix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Both were non-conforming before this session and block every push, not
just this one, since the hook runs over all files. The diff is entirely
table-separator widths and emphasis markers; no prose changes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Caught by the pre-push prettier hook. Only this file is touched: the two
other files it flags were already non-conforming before this session.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
A gate that blocks a commit with no tooling to clear it just moves the
problem to whoever hits it. --prune stages the removal of the oldest
artifacts, keeping the newest 20 per directory plus the template, and
leaves the commit to the operator.
Running it caught a bug that reading it would not: sorting on %cs (date
only) ties every artifact committed the same day, so sort fell back to the
path and the prune deleted alphabetically - it picked one of today's
newest files instead of the oldest. Sorts on %ct with -rn now.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Items 4 and 5 are done. Item 6 gets a recommendation against, with the
measurement behind it: the doc's ~2,780-line estimate was right and my
first grep was wrong (filenames only, 400 lines), but the two lib families
are parallel evolutions rather than copies, on 20% test coverage against
hardware I cannot reach.
Adds item 7: 3.7 GB of untracked build residue from the extractions, with
the checks showing it holds no source.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
The prune commit's evidence noted that "a recurring prune or a hard cap
would be the durable fix if this recurs" - which is advice, not a fix. The
tree would have regrown at one artifact per commit and been noticed months
later, exactly as it was this time.
check_repo_size.sh now caps evidence/ and contracts/ at 60 files each: the
headroom the prune bought, against 21 today. main accumulates failures
rather than returning on the first, so tripping both the source ceiling and
the artifact cap reports both.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
These accumulate roughly one per commit and were the largest single driver
of tracked-file growth: 695 artifacts, 487 of them from 2026-08 alone.
Kept the 20 most recent of each plus both templates. A count cap rather
than a time window, because the growth is bursty - a 7-day window would
still have kept 393 files and bounded nothing. Selection is by git commit
date, not by filename: the corpus mixes -2026-05, -20260604 and undated
slugs, so a filename filter would have mis-sorted ~48 files.
Safe to delete: nothing reads the historical corpus. Every reference in
meta/scripts is either template.json or validation of files staged in the
current commit, and the three hooks still pass. sessions/ is append-only
and untouched.
Tracked files 1993 -> 1340.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
The depth cap had 104 violations. 57 are structural: whole projects with
their own layout (C/, dwm/, artgate/), a tool split into modules to satisfy
the line cap, prose trees, and directories whose name an external format
dictates (systemd, hooks, workflows, patches, fixtures). Those are exempted
the same way lib/ and tests/ already were.
The other 47 all sit under periodic_background/{hosts,digital_wellbeing},
which can only come down by extracting those units - blocked on a manual
guard repoint. So the hook runs --warn: the number stays visible on every
commit without blocking unrelated work. Enforcement is one flag away.
Also guards the argument order: `--all --warn` used to ignore --warn and
exit 1, which as a hook entry would have blocked every commit.
check_repo_size.sh is the companion gate - depth stops one subtree growing
a taxonomy, this stops the repo absorbing everything. It counts tracked
files (git ls-files, never find: the tree holds ~30k untracked extraction
leftovers) minus vendored and hook-generated trees: 1049 against a 1200
ceiling, printed every run so the threshold is auditable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Depth 556 -> 104, tracked files 2295 -> ~1980. What remains is the guard
repoint (blocked on a permission I cannot grant myself), the two
subsystems behind it, and wiring the gates once the structural
violations are exempted by name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
check_file_length.sh required a dot in the filename, so every
extensionless executable was silently uncapped. is_source_file() now
reads the first two bytes and accepts a shebang, which catches real
scripts while still skipping data files like i3/config.
That immediately surfaced boot_recovery/boot-repair at 756 lines --
three times the largest capped shell file in the repo, uncapped purely
because its name has no dot in it. Split along its own section markers
into lib/{discovery,repair_fs,repair_kernel,modes}.sh, leaving the entry
script at 218.
The report block stays inline on purpose. It is top-level code with exit
calls rather than function definitions, and sourcing it changed control
flow: 30 of 42 tests failed. That is recorded in the lib headers so the
next reader does not retry it.
No vmbox pass for this one, deliberately. boot-repair is UEFI/ESP tooling
and the guest is BIOS/GRUB, so a sandbox green would be actively
misleading -- the vmbox skill says so itself. The evidence is the fixture
suite, which drives the real script against synthetic root trees: 42
passed before, 42 passed after.
verify_shell_split.sh reports 31 of 32 functions byte-identical. The one
difference is clean_shadow_files, where quoting $ESP_MOUNTPOINT fixed a
genuine SC2086 that only became visible once the function left the
monolith -- shellcheck could no longer see the readonly declaration and
stopped assuming the expansion was safe.
lib/tests/run_all.sh delegates to that same suite rather than standing up
a second, weaker harness: these libraries need the entry script's strict
mode and globals, so testing them in isolation would test a fiction.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
i3 config was filed under periodic_background, which it never was. It is
now linux_configuration/i3/ (config + installer) and
linux_configuration/i3blocks/ (the status scripts), both at depth 2.
misc/testsAndMisc-bash/ was a directory named after the repo it already
lived in, so its contents moved up to misc/. Its stray .gitignore came
along, keeping the media rules working from the new location; its
.vscode/tasks.json did not, because it invoked Bash/transcribe.sh, a path
this repo dropped long ago.
Most of this commit is the references the previous flatten missed. Its
regex skipped anything with a variable prefix, which left 16 files --
including check_and_enable_services.sh and install_core_system.sh, the
orchestrators -- still naming $CONFIG_DIR/scripts/periodic_background/...
It had also rewritten three i3 paths into scripts/i3blocks/, a directory
that has never existed; the i3blocks suites caught that by failing.
13 more symlinks broke on the i3 move. Repointed, and cpu_monitor/volume/
disk were run again to confirm the bar still reports.
Depth 139 -> 104. Roughly 47 of the remainder sit in digital_wellbeing
and hosts, still deferred. The rest encode real structure -- a C project,
Python package directories, artgate's routes/styles, systemd unit dirs --
so flattening them further would destroy information rather than
taxonomy.
Verified: 1798 tests at 100%, both i3blocks suites pass, the shell
coverage gate is clean, and the relocated media rules still ignore what
they should while test_fw.srt stays tracked.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Two levels of pure taxonomy carrying no information, and a 2-directory
cap leaves no room for them. Categories now sit directly under
linux_configuration/: features, fixes, utils, misc, fresh-install,
installers, diagnostics, gaming, boot_recovery, periodic_background, lib,
meta, tests. A script's own lib/ and tests/ are exempt from the cap, so
those stay put.
Depth violations 248 -> 139; roughly 40 of the remainder are inside
digital_wellbeing and hosts, deferred until the guard-lib repoint.
The moves are the easy half. What breaks is every path that counted
levels, and three classes of it had to be found by resolving paths rather
than reading diffs:
- 52 relative `source` lines for lib/common.sh and lib/android.sh. The
correct prefix differs per file: 40 were ../../ and 12 were ../../../,
so a blanket replace would have fixed one set and broken the other.
- REPO_ROOT in 7 fixes/lib/tests harnesses and setup_syncyomi_guard.sh,
each walking up four levels from a directory now two levels shallower.
This caused a real regression -- the fixes suite went red with
"log_warn: command not found" -- caught by running it and comparing
against the pre-move baseline worktree.
- conftest.py's sys.path entries, which took the pytest gate down with
14 collection errors, and the `# shellcheck source=` directives, which
took shellcheck down with SC1091.
16 symlinks in $HOME broke, including the entire i3blocks bar. All
repointed, and cpu_monitor/memory/disk/time/volume were run to confirm
they emit real output rather than merely resolving.
Verified: 1798 tests pass at 100% coverage, 8 of 9 lib/tests suites pass
(the ninth needs the coverage jail, identically at baseline), pre-commit
is clean, and the two untracked secret configs are still ignored after
their gitignore paths changed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
github.com/kuhyx/phone-focus-mode
The two halves go as one repo: focus_policy parses phone_focus_mode's
config.sh into the typed policy that focus-owner consumes, and nothing
else references it. 77 commits of history, plus the two Python suites
from linux_configuration/tests/ and the six mutation fixtures from
meta/scripts/fixtures/, all of which named phone_focus_mode paths.
Running the suites -- not reading them -- turned up a real defect the
extraction would otherwise have inherited. config.sh sources the
untracked config_secrets.sh, and ctl_libs_harness.sh never pinned
HOME_LAT/HOME_LON, so the distance assertions were checking against
whatever real coordinates that file happened to hold. The suite passed on
this machine and could not run anywhere else, and a real home location
was load-bearing in a pass/fail condition. The harness now pins a pair
4300 m south of the coordinate its own case seeds, and config.sh sources
the secrets file only when it exists. 136/136 pass with no secrets file
present.
Before making the repo public I scanned the whole history for the known
home coordinates and for any committed config_secrets.sh: zero hits, and
the file was never tracked. The new repo also gained a .gitignore, since
none came across in the filter-repo pass.
test_magisk_service.sh hangs. It hangs identically in the pre-extraction
baseline worktree and appears in no CI list here, so the new repo's CI
skips it with that reason rather than pretending it passes.
check_python_location.sh loses its phone_focus_mode exception now that
the directory is gone; every tracked .py still passes it. The .gitignore
rules for config_secrets.sh and the keystore STAY -- the working copy is
still on this machine and still holds a real location.
Depth 262 -> 248.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
test_usage_monitoring_installer_efficiency.sh left with
system-maintenance, but shell-tests.yml keeps TWO hand-maintained lists
and I had only cleaned the Arch-specific one. The side-effect-free list
still named it, so ci-mirror rejected every push since that extraction.
Cross-checked the whole workflow this time: every test_*.sh it names now
exists on disk.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Also records that syncyomi-guard has been red since 00:00 today for
reasons unrelated to this work -- the library collapsed to 8 manga and
the guard is correctly refusing to let it pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
github.com/kuhyx/android-guardian, cloned to ~/android-guardian
periodic_background/utils/ held two unrelated things: the Magisk module
and heavy_job_lock.sh. Only the module was a unit, so the directory is
split rather than moved.
heavy_job_lock.sh goes to digital_wellbeing/, NOT to ~/utils. Measured
rather than assumed: of its consumers only install_pacman_wrapper.sh
reads the repo copy, while pacman_wrapper.sh, makepkg_capped.sh and
meta/scripts/run_with_heavy_lock.sh all read the installed
/usr/local/bin copy. A library belongs with whoever installs it, and
exporting it would have added a cross-repo edge for one caller.
Fixed a bug that predates the extraction: update_android_hosts.sh set
GUARDIAN_MODULE_DIR to "$SCRIPT_DIR/android_guardian", a sibling that
never existed at that path -- packaging could not have worked from this
checkout at all. It now reads ${ANDROID_GUARDIAN_DIR:-~/android-guardian}
and require_guardian_module() gates build_module(), the single funnel
every packaging path goes through, so a missing checkout names the clone
command instead of failing inside a cp four helpers deep.
Verified both directions: with no checkout the guard fires with
instructions; with one, the module builds -- 182331 blocked domains, a
1.1 MB zip. The subsequent adb push failed on device-side storage, which
this commit does not touch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
github.com/kuhyx/system-maintenance, cloned to ~/system-maintenance
First of the four live subsystems, and the one with no cross-unit source
edges, so it establishes the pattern for the harder three. Passed in
vmbox first -- the installer ran from an extracted-layout copy in the
guest and detected its distro without any monorepo path -- then on the
host.
Its 21 Python and shell test files lived in linux_configuration/tests/,
reaching bin/ through a shared conftest. Twenty moved with the code and
got their own conftest; the shared one stays, since it serves several
script directories that are not going anywhere.
test_shutdown_timer_monitor.sh stays here. It is a pair test: it checks
that digital_wellbeing's installer template and the monitor it installs
still agree, so it belongs to whichever half owns the installer. It now
reads the monitor from ~/system-maintenance and SKIPs when that checkout
is absent.
An intermediate version of that test fell back to /usr/local/bin, which
HUNG -- the installed copy is stale and differs from source, so the test
was comparing an installer template against a binary it never generated.
Falling back to it would have been worse than skipping, so the fallback
is gone and the comment says why.
Also removed test_hosts_file_monitor.sh from shell-tests.yml's explicit
list: it left with the subsystem, and CI would have failed on the missing
file rather than quietly skipping it.
Verified: 136 tests pass in the new repo, 202 still pass here, the pair
test passes against the checkout and skips without it, and both the shell
coverage gate and shellcheck are clean. Depth 294 -> 267.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Five units out, gates written but not wired, and the four live subsystems
still to go. Captures the decisions that came from measurement rather than
the plan -- common.sh and periodic_background/lib both stay -- and the
traps already paid for, so the next session does not rediscover them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Found while surveying system-maintenance: /usr/local/bin holds copies
that hardcode repo paths, and no section of the inventory looked there.
The installed copy is what actually runs, so grepping the repo for its
own paths never finds them.
Three were invisible until now:
periodic-system-maintenance.sh 3 paths into digital_wellbeing + hosts
hosts-file-monitor.sh 1 path into hosts
wsg-grabber PYTHONPATH into the repo root
The first runs hourly, which means the two subsystem extractions coming
next have to reinstall it -- editing the repo copy alone would leave the
live one pointing at a directory that no longer exists.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
github.com/kuhyx/mtk-root
Unlike the app extractions, mtk_root could not travel alone: its four
libraries and three of its four test suites sat in scripts/lib/, one
directory up from the stages that source them. Taking only the directory
would have orphaned eight files here and left the new repo unable to
source anything, so all twelve moved in one filter-repo pass. The
mtk_root/ + lib/ sibling layout is preserved, so every
`source "$SCRIPT_DIR/../lib/..."` resolves with no call site edited.
Two things the new repo needed that the monorepo provided implicitly:
lib/tests/run_all.sh -- the copy here is shared with the non-mtk suite
and stays. Without a new one, shell-tests.yml's
glob over */lib/tests/run_all.sh would have
stopped covering these suites on a green build.
.shellcheckrc -- external-sources + source-path=SCRIPTDIR, which
is what lets shellcheck run with no severity
filter and still pass on the ../lib/ sources.
mtk_harness.sh stays here despite the name: test_common_datetime.sh
sources it. Removing it broke that suite outright, which running the
suite caught immediately. Its header now describes what it actually
serves; the misleading name is kept on purpose, since renaming would
churn its one consumer for nothing.
Verified: 84 tests pass in the new repo with shellcheck clean, 55 still
pass here, and check_shell_coverage.sh --all exits 0 with the four
mtk_root allowlist entries gone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Three self-contained apps move to their own public repos with full
history (8, 14 and 30 commits, each matching the monorepo count):
github.com/kuhyx/reverse-survivors
github.com/kuhyx/kcd2-dice-solver (cloned to ~/kcd2-dice-solver)
github.com/kuhyx/focus-owner
Each gained a CI workflow. Only reverse_survivors had one here; the other
two were never gated by anything, which is part of why they no longer
belong in a repo whose CI is shared.
What stayed: setup_kcd2_dice_solver.sh, which deploys the solver rather
than being part of it. It now builds from ~/kcd2-dice-solver, and the
post-commit hook it generates drops its `git diff -- kcd2_dice_solver/`
filter -- in a standalone repo every commit is solver code, so the old
filter could never match again.
focus_owner's two references to python_pkg.focus_policy now name the
phone-focus-mode repo, where that generator is headed.
Running the live kcd2 unit -- rather than reading it -- found three real
breakages that no amount of grepping would have: pnpm ignoring the
package.json "pnpm" field, pnpm refusing to purge node_modules without a
TTY, and the Docker container still bind-mounting the deleted monorepo
path. All three are fixed; the unit exits 0 and
https://dice.kuhy.duckdns.org/ serves the freshly built bundle.
Depth violations 417 -> 303.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
The coupled case the previous archive commit deferred. billsplit is not
just a directory: a coverage package exists only to gate it, app_icons
holds a registry entry pointing into it, a CI workflow builds it, and
.binary-allowlist / .gitignore carry a paired set of rules for its
launcher icons. Removing the directory alone would have failed the 100%
coverage gate and left three configs naming a missing path.
So all of it goes in one commit:
billsplit/ 73 files
python_pkg/billsplit_coverage/ 5 files, gated billsplit only
.github/workflows/billsplit-ci.yml
the app_icons AppIcon(key="billsplit") entry
the .binary-allowlist patterns and their .gitignore ! overrides
the .prettierignore fixture line
billsplit/ and billsplit_coverage/ were extracted in a single filter-repo
pass (8 commits, matching the monorepo) and pushed to
github.com/kuhyx/testsAndMisc-archive, where the coverage package joins
the archive's existing python_pkg/ tree. Presence was confirmed through
the GitHub API before anything was deleted here.
.binary-allowlist is now empty of patterns -- billsplit's icons were its
only entries. The policy header stays and records that no exception is in
force, and check_no_binaries.sh still exits 0 on a comment-only file.
Verified: 2095 tests pass at 100% coverage, down from 2114 by exactly the
19 billsplit_coverage tests. Depth violations 451 -> 417.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Two self-contained apps, neither referenced by any other code, systemd
unit or symlink -- which is why they go first in the restructure.
Full history preserved via git filter-repo and merged into
github.com/kuhyx/testsAndMisc-archive at their original repo-relative
paths, matching how C/, CPP/, horatio/ and the rest already sit there.
Archived commit counts match the monorepo exactly: bucket_catch 10,
poker-stakes 2.
poker-stakes-ci.yml goes with the app it builds, so no workflow is left
pointing at a missing path. bucket_catch had no workflow.
Verified before deleting: file counts match (64 and 65), diff -r against
the working tree is clean, and the GitHub API lists both units in the
archive. Depth violations drop 556 -> 451.
billsplit is deliberately NOT part of this commit: it is coupled to
python_pkg/billsplit_coverage and an app_icons registry entry that the
100% coverage gate requires be deleted in the same commit as the app.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Two scripts and a baseline record, ahead of the archive/extract/flatten
campaign. Nothing moves in this commit.
report_live_state.sh enumerates everything on this machine that names an
absolute path inside the repo -- 6 systemd units, 2 /etc/guard-lib plugin
targets and 19 symlinks. Moving a subtree silently breaks these, so each
later step repoints its own references and re-runs this with --check.
check_directory_depth.sh is the 2-directory cap, modelled on
check_file_length.sh. It is deliberately NOT wired into pre-commit yet:
the tree has 556 violations, so enforcing it now would block every
unrelated commit -- the same reason file-length-cap landed after its
campaign rather than before.
Run as a dry run it sizes the work: 349 of those 556 disappear with the
planned removals, leaving 207 to flatten, ~130 of them under
scripts/single_use.
Exemptions are prefix-based (third_party/, docs/superpowers/,
.github/skills/) plus the lib/ and tests/ path segments, matched as whole
segments so libvirt/ and lib.sh are not caught. Capping lib/ and tests/
would put this gate in conflict with the 250-line cap and the
shell-coverage ratchet, which require exactly that layout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
The run that added the hook-environment cache could not benefit from it:
its key is a hash of .pre-commit-config.yaml, which that same commit
changed, so it logged "Cache not found" and then saved. Six hook
environments were still built from scratch -- including pylint's, which
pulls a dozen extra packages -- and that is most of the 126s hook step.
Without a dispatch there is no way to re-run the job on an unchanged tree
to see the cached number, so the saving could only be asserted, not
measured. Now it can be measured.
Confirmed in the same log that the previous commit landed:
"pytest with coverage enforcement....Skipped".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Per-step timings showed the real cost was not the install I had just
cached:
Pre-commit checks Run pre-commit hooks 152s
Install dependencies 55s
The log explains it -- "pytest with coverage enforcement....Passed"
inside the Pre-commit checks job. `pre-commit run --all-files` fires the
pytest-coverage hook, which runs every python_pkg suite with
--cov-fail-under=100: precisely what the Python tests workflow had
already done on the same commit. Two full 2174-test runs per push.
SKIP=pytest-coverage in that job only. It is the one hook skipped, and it
is skipped for being DUPLICATED rather than for being slow -- noted in
the workflow so it gets dropped if Python tests ever goes away.
Also checked and deliberately left alone:
session-autopsy-hook-mutations costs ~50s locally, but self-skips when
~/.claude/hooks is absent, which is always true on a runner. It was never
a CI cost.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
python-tests.yml runs pytest and nothing else, but installed the full
requirements.txt -- 79 packages, of which ~62 are linters, formatters and
type checkers that job never invokes. Installing them was the workflow's
slowest step: 49s, against 35s actually running the tests.
meta/requirements-test.txt holds the 17 that matter. Derived by static
import analysis over python_pkg/ and linux_configuration/tests/, then
VERIFIED rather than assumed -- a clean Python 3.11 venv with only this
list runs the whole suite:
2174 passed, TOTAL 100.00%, 7138 stmts / 1748 branches, 0 missing
identical to the full-requirements run. Install of the subset: 6.2s.
The pytest-* entries are in the list even though nothing imports them:
randomly reorders tests, timeout enforces a limit, sugar changes
reporting and xdist provides -n. Dropping one changes how the suite runs.
Drift is gated, not left to discipline: a new requirements-test-sync hook
reuses check_requirements_sync.py's existing --requirements flag, so a
new third-party import fails at commit time rather than as a bare
ModuleNotFoundError in CI. The new file is also in both path filters.
pre-commit.yml keeps the full list -- it needs every formatter.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Measured per-step timings, rather than guessing where the time went:
Pre-commit checks Install dependencies 63s (next slowest: 16s)
Python tests Install dependencies 49s (pytest itself: 35s)
Both workflows re-downloaded ~80 packages from PyPI on every run. The
Node workflows already cache npm; the Python ones were the outliers.
* cache: pip on actions/setup-python in both, keyed on
meta/requirements.txt -- the REAL file, not the root symlink, since
the key is hashed from the file at the given path and hashing a
symlink is not hashing its target. (That same symlink already cost
us a silently-skipped workflow earlier today.)
* ~/.cache/pre-commit via actions/cache@v4, keyed on
.pre-commit-config.yaml. pre-commit builds a virtualenv per hook repo
on first use, which costs more than the pip install itself, and it
only needs rebuilding when a hook's repo or rev changes.
The first run after this lands is a cache miss and will be no faster;
the saving starts from the second.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
The previous commit fixed the dependency resolution failure that had kept
Python tests red since ~2026-08-19 -- and then did not run it, because
the workflow's path filter lists "requirements.txt" while the root file
is a SYMLINK into meta/. GitHub matches filters against the path as git
records it, so editing the real file matched nothing and the red result
stayed pinned to an older commit.
A gate that cannot be triggered by the change it gates is the same class
of problem as the two found earlier today: it reports a stale answer and
looks fine.
Both spellings are now listed, in the push and pull_request filters.
The other root symlinks -- pyproject.toml, run.sh, lint_python.sh,
.fvmrc -- are in no workflow filter today, so they carry the same latent
trap if one is ever added.
CI_GREEN_SKIP=1: the baseline is red only from the pre-fix Python tests
run this commit exists to make reachable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Python tests has been red since ~2026-08-19, failing in "Install
dependencies" with pip's resolution-too-deep. That is an install failure,
not a test failure -- which means no Python test has actually run in CI
for days, on a repo whose Python bar is 100% branch coverage.
The CI log names the cause: the resolver backtracks through Brotli
1.0.6 -> 1.0.4 -> 1.0.1 and asgiref 3.8.0 -> 3.7.1 -> 3.6.0, all dragged
in by mitmproxy>=10.0, then gives up. Nothing imports it: `git grep
mitmproxy` finds it only in a pacman whitelist and a docs file, and
check_requirements_sync.py passes without it.
Reproduced and fixed locally rather than guessed, on Python 3.11.11 with
pip 26.2.1 -- the versions CI uses:
pip install --dry-run -r <with mitmproxy> exit 1, resolution-too-deep
pip install --dry-run -r <without mitmproxy> exit 0
Left standing: 78 of the 80 requirements are unpinned >= ranges, so this
can recur the next time a package with a wide dependency graph is added.
CI_GREEN_SKIP=1: this commit IS the fix for the red baseline.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
The original handoff's scope is obsolete: job 1 is done, and job 2 was
deliberately dropped rather than completed. Prepends the outcome and the
numbers rather than rewriting the file, because its kcov/jail notes are
still the reference for measuring a lib on purpose.
Also records the two traps that cost the most time this session: never
`git reset --hard` to undo a probe commit (it discards unstaged work --
recoverable from ~/.cache/pre-commit/patch*), and read a gate's predicate
rather than its header comment, which in this repo was a full day stale
and produced a confidently wrong scope estimate.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
check_shell_coverage.sh has existed for a while and was never in
.pre-commit-config.yaml, so nothing ran it: a new shell library with no
suite beside it could land freely. Wiring it was unaffordable while the
gate measured a jail-run 100% bar (--all took over 600s). After 578c4a6c
dropped that, --all is 0.31s and the per-file mode this hook uses is
milliseconds, so it goes in.
Also fixes a bug 578c4a6c introduced: the failure path still interpolated
${COVERAGE_BAR}, which that commit deleted, so every rejection printed
"COVERAGE_BAR: unbound variable" and advised a 100% line-coverage bar
that no longer exists. The message now describes what is enforced.
Three libs blocked the wiring -- meta/scripts/lib/shell_coverage_{bar,
case_runner,jail_setup}.sh, the code that BUILDS the jail, and so the one
corner of the repo the jail cannot measure itself. They are pure
file-writers, so they get a suite that calls them against a temp $JAIL
and asserts on what was written: 48 assertions, nothing mounted, no
unshare, no kcov.
Several assertions check that an emitted file contains an UNEXPANDED
${BASH_SOURCE} or $1 -- the whole point of the quoted heredocs the jail
relies on. Written as single-quoted literals that is SC2016 on every
line, so the needles compose the dollar from an exported constant
instead. No suppressions were added.
check_shell_coverage.sh --all: 3 BLOCK -> 0 BLOCK
hook, repo-wide: 0.16s
new suite: 48 assertions, green
Proved the ratchet still bites: an untested lib dropped into
mtk_root/lib is refused with "needs: .../tests/run_all.sh". Probe removed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
bca70b67 (2026-08-22) turned the shell ratchet from "a run_all.sh exists
beside this lib" into a measured 100% line-coverage bar, run through the
kcov+userns jail. It works -- dot_resolver_install.sh really does measure
39/39 -- but the price is one hand-written test file per lib: fixes/lib
took 34 test files for 22 libs, the jail runs serially at 37-90s a pass
(concurrent jails give false failures), and most libs need a production
seam added before they can be driven at all.
That put the remaining 84 exempt libs at several days of work, for a
repo of personal automation scripts. User's call today: not worth it.
python_pkg keeps its 100% branch bar, which is already met -- 2101 tests,
100.00%, zero missing statements or branches. The difference is the
instrument: pytest-cov is fast, reliable and parallel; the shell jail is
none of those.
Also tried and rejected, recorded in the file: a middle option where the
suite must MENTION the lib by name, closing the empty-suite hole the
100% bar was reaching for. It newly BLOCKED 68 libs sitting in
directories that already have suites -- 38 in utils/lib alone -- because
those passed the old presence check and so were never allowlisted, and
seed_allowlist refuses to grow by design. Tightening a ratchet with no
way to grandfather the existing tree turns it into a wall.
The jail is not deleted; it is still the tool for measuring a lib on
purpose, and ci_mirror.sh still runs jailed suites.
check_shell_coverage.sh --all: >600s -> 0.31s
BLOCK entries: 3, all pre-existing meta/scripts/lib
coverage-tooling libs
allowlist: unchanged at 84 (--seed correctly
refused to add the 3)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Endurain API keys are upload-only by design: the scope allow-list is
frozenset({"activities:upload"}), enforced in both validate_api_key_scopes
and the create schema, and the activities read route is mounted with
validate_access_token rather than validate_access_token_or_api_key. A key
therefore fails at authentication before any scope check, so the HTTP
dedupe check added in 325d5a8b could never succeed and every pass fell
back to the ledger alone. Verified against v0.19.0; upstream documents no
plan to widen the allow-list.
Read the start times out of postgres instead. The container publishes no
host port, so this goes through docker exec -- no new dependency and no
port opened just to read four rows. The HTTP path is still tried first so
the supported route resumes working on its own if the allow-list ever
grows.
None and [] are kept strictly apart: a dead container, timeout or non-zero
exit means "could not ask" and returns to the ledger, while an empty result
set is a real answer. Conflating them would re-upload everything on any
docker hiccup, which is the bug the dedupe check exists to prevent.
Proven with an empty ledger: the known-duplicate TCX was skipped and the
activity count held at 4, and the same file WAS imported with
ENDURAIN_NO_DB=1, so the check is what blocks it. The duplicate that
negative control created was removed afterwards.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GbYEnfGnf1988cdFdGebot
`git push` took ~130s because ci-mirror re-ran `pre-commit --all-files`
plus every lib/tests suite on every push, regardless of what changed.
The larger problem found while measuring it: ci_mirror.sh invoked
pytest_changed_packages.py with no arguments, and that script returns 0
on empty argv because it is normally a pre-commit hook fed staged paths.
The pre-push python stage has therefore been running ZERO tests and
reporting success. Behind it sat a genuinely failing test, fixed in
ff3ea99a. The stage is now passed the changed paths and actually runs.
Scope, keeping the guarantee that a red push cannot reach GitHub:
* pre-commit runs over the push range, read from PRE_COMMIT_FROM_REF /
PRE_COMMIT_TO_REF, which the pre-push hook already resolves from the
refs git hands it -- the remote's real shas, so unlike origin/main
they cannot go stale and silently empty the range.
* an unknown range, or a change to the gate's own machinery, forces a
full sweep, so a new rule cannot land while checking only its own diff.
* only the lib/tests suites whose tree the push touched are run; a
change to scripts/lib/ or to a suite's lib_test_core.sh fans out to
all of them.
* pre-commit and pytest run concurrently. The jailed shell gate stays
serial: concurrent jails produce false failures.
* an unchanged tree short-circuits on a recorded tree hash.
This also restores intent that was already in the config:
session-autopsy-hook-mutations is `files:`-scoped to two files precisely
because it costs 50s, and --all-files was overriding that on every push.
Measured, against a ~130s baseline:
docs-only push 7.6s
python push 25.3s (includes a 22s stage that never ran)
one shell suite 43.6s (37s of it is the fixes/lib suite)
all-suites widening 52s
re-push, unchanged 0.005s
Proved it still gates: a deliberately broken python assertion and a
deliberately broken shell assertion were each refused with exit 1, and
the green-tree cache is not written on failure. Both probes reverted.
Split into ci_mirror_range.sh and ci_mirror_shell.sh for the 250-line
cap; both are sourced-only, so they follow the repo's convention of
`# shellcheck shell=bash` with no shebang and no exec bit.
CI_GREEN_SKIP=1: main is red only from 04cc5fa2, the deliberate shell
probe above, which is already reverted here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Reverts the temporary broken assertion used to prove the pre-push gate
refuses a red shell suite (it did: exit 1).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
Two adb devices are normally attached (USB phone + a network target), so
the importer correctly refused to guess which one to pull from. Pin
ENDURAIN_ADB_SERIAL in the unit; verified with a real run that now
reports "pulled 5 file(s) from the phone".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GbYEnfGnf1988cdFdGebot
