When update or install.sh fails and there's a terminal, ask whether to
send its log to the CoreDesktop team, with the option of reading exactly
what would be sent first. Nothing is sent without a yes, and nothing is
asked without a terminal. The new report command sends a log later
(report, report FILE) or shows what would be sent (report --view).
Before sending, the log is cleaned of terminal codes, and the home
folder, user name, host name, email addresses, IPv4 addresses and
Tailscale names are replaced. CoreDesktop's version, the kernel's, the
failed steps and sibling versions go along with it. The request format
the receiver on federated.sh implements is described at the top of
report.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each run's output now goes to ~/.local/state/coredesktop/logs/, so what
failed can be read after the terminal is gone. In a terminal, update runs
itself under script(1), so everything it runs still sees a terminal, then
strips color codes and progress redraws from the log; otherwise it uses
tee. install.sh, usually piped into bash, uses tee, and runs configure
straight on the terminal, outside the log. Both name the log when
something fails. 95-cleanup.sh keeps the newest 10 update logs and 3
install logs.
The sudo keepalive loops no longer share the logged output, so their
sleep can't hold the log open after the run ends.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
013acac's update (in use 2026-08-14 to 2026-10-19) copies the new update
over itself with sudo cp while bash is still reading it, so bash reads on
from byte 1484 of the new file: today, the middle of the logo, and the
update dies with a syntax error. Put a line at exactly that byte that
execs the new update, in a here-document a normal run skips. Found by
30-upgrade-from-baseline at ca658dc; the test replays 013acac's update.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Since a65f07c ran each hook in a subshell, a hook that does its work as
it's sourced (12-migrations, 15-services, 20-aur, 30-flatpak and others)
had its failure lost: the run_update check after source left the
subshell's status at 0, so update said "Done." and exited 0. The smoketest's
40-failing-migration caught it. update now exits the subshell with the
sourced hook's status.
Also, the smoketest scenarios that check whether a migration ran look for
"Running migration " so install.sh's "Running migrations..." heading
doesn't match (11-refresh failed on it).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`sibling` asks for a git URL, clones the repo into
~/.local/share/siblings/<name>, runs its install.sh and confirms the
install. `sibling list` and `sibling remove` manage installed siblings.
updates.d/71-siblings.sh pulls every sibling during `update` and runs
its update.sh, reporting failures in the update summary.
Document the sibling contract in skills/sibling-project-format.md and
update the custom-hook guide to match.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
davidandClaude Opus 5.5