The previous brief pointed at kcd2_dice_solver; those four files and twelve
more are done, so it was stale. The new one reflects what the user asked for
after seeing the stopping report: write the missing tests instead of stopping
at the coverage wall, change the source-text tests where a split needs it, and
delete the Flutter Windows scaffolding rather than working around it.
Also spells out the deployed-copy blocker in plain terms, since the previous
brief's phrasing did not land: install_leechblock.sh is copied to
/usr/local/share/digital_wellbeing/ and pacman_wrapper.sh:831 runs THAT copy on
every pacman invocation, so an entry+lib/ split breaks pacman on the live
machine. Verified the root-owned copy is still there.
Records the billsplit/windows/ deletion as a four-part job, not a git rm --
.gitignore carries two un-ignore rules for it and analysis_options.yaml
excludes it -- and flags macos/ and ios/ as the same question to ask rather
than assume.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011w2Pj4Ek3ZNMQVYcFHgXDY
The shell-installer seam is close to exhausted: of the four candidates probed
last session, one was blocked by a deployed single-file copy, one was
unverifiable (239 of 336 lines never execute under trace), and one configured a
feature that had been dead for months. What is left there is expensive.
kcd2_dice_solver has four files over the cap and a far stronger verifier than
anything the shell harness produces: 288 vitest tests in ~4s, 100% branch
coverage enforced by config thresholds, and tsc+eslint. Verified all three
green at 5dce82f before writing this.
The brief front-loads the two things most likely to go wrong: that the project
has NO CI and is not in pre-commit, so the gate is local-only and a broken
split would push clean; and that splits should re-export from the original file
rather than rewrite imports, so the test files stay untouched and the
verification stays honest.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011w2Pj4Ek3ZNMQVYcFHgXDY
Probing found a blocker the trace structurally cannot see: a script that some
OTHER script copies elsewhere and runs from there cannot take an entry+lib/
shape, because the deployed entry's SCRIPT_DIR has no lib/ and dies on its
first source under set -e. The trace stays green because it runs the repo copy.
install_leechblock.sh is blocked on exactly this, and it is live, not
theoretical: install_pacman_wrapper.sh cp's it to
/usr/local/share/digital_wellbeing/, pacman_wrapper.sh:831 PREFERS that copy,
and auto_install_leechblock runs on every pacman invocation. It is otherwise
the best-conditioned target left (exit 0, 93 files, all hashes stable), which
is exactly why it needed the check rather than the trace.
setup_thorium_startup.sh is mechanically splittable — exit 0, all 8 steps
covered, no deployed copy — but should not be split, because what it configures
is dead. Thorium was removed in favour of chromium/librewolf;
/usr/local/bin/thorium-browser is now a leftover symlink to
browser-preexec-wrapper, which cannot resolve /usr/bin/thorium-browser and so
treats the URL as the binary. The enabled thorium-fitatu-startup.service has
been failing at every boot while reporting status=0/SUCCESS:
thorium-browser: line 33: /https://www.fitatu.com/app/planner: No such file
Also recorded: process spawning escapes --prefix the same way pkill does.
setup_thorium_startup.sh launches a browser mid-run; check ps after tracing
anything that starts a program.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011w2Pj4Ek3ZNMQVYcFHgXDY
Probed the two remaining candidates at HEAD instead of guessing:
nvidia_troubleshoot.sh is ruled OUT. Its trace dies at step 3 because
backup_file writes /etc/profile.backup.<stamp>, a new SIBLING in unbound /etc
— a file bind cannot cover siblings and bare /etc is refused. 239 of its 336
lines never execute, so keeping the unproven ones in the entry (the rule the
pacman split established) leaves the entry at ~265, still over the cap. The
file cannot satisfy both the rule and the goal.
install_leechblock.sh is the best-conditioned target left: exit 0, 93 files
written, and all 93 hashes byte-identical across two consecutive runs. Only
the echoed prefix path and curl's progress meter vary.
But it fires an unstubbed `pkill` at every Chromium-family browser. pkill is
not in the stub set and --prefix cannot contain it, because signals are not
filesystem writes. Two probe runs fired it, harmless only because no browser
happened to be open. That is now documented as its own trap, and the brief
tells the next session to pass --stub pkill and check for a live victim first.
Also recorded: for a target embedding $(date), diff the written files' CONTENTS
with the date normalized rather than falling back to comparing sizes — that
still catches a dropped line, which a size comparison does not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011w2Pj4Ek3ZNMQVYcFHgXDY
`--bind-abs /usr/bin` overlays the directory bwrap needs to exec anything, so
the run dies with `execvp bash: No such file or directory` before the script
starts. A target whose last act replaces a binary there traces fine with every
other path bound and stops at that line with exit 1 on EPERM — usable as a
baseline (it is deterministic across runs), but blind to statements at or
after the failure, which is a constraint on where the seams can go.
Also noted: the absolute-path scanner misses a literal `ln -sf` target,
because it follows variables into `cat >`/`cp`.
The brief now targets install_pacman_wrapper.sh (316) with its baseline
already captured: 16 file hashes, one stubbed call, exit 1 at line 304.
Checked ahead of time that its source.sha256 drift manifest hashes only the
seven copied source files, not the installer, so a split leaves it stable.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011w2Pj4Ek3ZNMQVYcFHgXDY
Last session landed the --prefix harness but split nothing, by design. This
points the next one at install_usage_monitoring.sh (290, over by 40) with the
facts needed to do it rather than rediscover them: the section-by-section seam
map, the five globals that cross those seams, and the 30-line reference trace
with the content hashes the split must reproduce.
Three hazards are file-specific and each was measured, not guessed:
- linux_configuration/tests/test_usage_monitoring_installer_efficiency.sh
greps the installer's SOURCE TEXT for the pmon heredoc. Moving that heredoc
into a lib breaks the test, and it is not in the pre-commit set, so nothing
reports it.
- REPO_DIR walks up five levels from $0 and is interpolated into the generated
catch-up script, so recomputing it at a different depth silently points the
generated file at the wrong repo while the trace still exits 0.
- Line 222 is an unquoted heredoc whose internal escaping is load-bearing.
The brief's own verification procedure had to be corrected: tracing the
baseline from a detached worktree makes REPO_DIR resolve to the worktree, which
changes the generated file's content and produces a convincing 2-line diff out
of nothing. Normalising the trace text does not help, because the path is
inside the hashed content. The baseline is captured in place instead, and that
workflow is verified to diff empty pre-split.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011w2Pj4Ek3ZNMQVYcFHgXDY
Six remaining over-cap files write to /etc, $HOME/.local/bin and systemd
unit dirs by shell redirection, which no PATH stub can intercept -- so
they currently cannot be verified at all, only inspected. That blocks
most of what is left, including several of the named blockers.
The brief scopes one tooling job (a prefix redirect in
trace_shell_split.sh), states the constraints that must not be violated,
and records what was measured today: destinations are mostly $HOME-rooted
variables, so a HOME redirect covers a large share without touching the
scripts. Two cases that a bare HOME redirect will NOT catch are named
explicitly -- setup_thorium_startup.sh writes through `sudo -u mkdir -p`,
which the existing sudo stub swallows, and install_leechblock.sh uses
`rsync --delete`, which is destructive against a wrong root.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011w2Pj4Ek3ZNMQVYcFHgXDY
