Unclaimed files left in the canonical checkout. Inventory: canonical-cleanup-inventory.md (commit-as-evidence groups). detect-secrets scan clean on 2026-11-02: hits are sha256 pins, git object ids, test sentinels already in tracked tests and unit-file lines.
1.7 KiB
Filbert review, row 87 round 8: approve.
Candidate: commit 917ef55e1 (917ef55e18), diff from 4c1fee85a on the design docs/plans/2026-10-18_containerized-install-design.md and the rows docs/plans/2026-10-18_containerized-install-rows.md. Line numbers are at 917ef55e1.
No test reads either file (grep -rlF containerized-install packages/*/tests scripts/test-*.sh finds nothing), so under decision 137 nothing here blocks.
My round 7 follow-ups (28889): both answered
- design.md:285-287: a "no such container" answer from
docker stopordocker rm -fcounts as gone. Tested at rows.md:496-498. - design.md:293-299: each bound is per container, three core stop timeouts at most, 135 s today. Five exit-1 starts within 600 s reach
StartLimitBurst=5, and then a human runsreset-failed. That matchesStartLimitIntervalSec=600andStartLimitBurst=5at packages/cli/systemd/mosaic-bus.service.in:9-10.Type=simpleis at :13.
Darkwing's V
design.md:289-293 makes the leftover refusal the one exit-1 refusal. rows.md:411-413 gives I6 the unit's ExecStart comment only. That is the right file: today's comment at service.in:25-29 says "refusals exit 3".
Note, not a change
A leftover that takes most of its 135 s means each failed start plus RestartSec=15 lasts up to about 150 s. Five such starts can't fit inside 600 s, so the limit trips only on fast failures. "Five exit-1 starts within 600 s" is accurate as worded. I mention it only so I6's docs don't promise that a stuck leftover always ends in reset-failed.
Not run by me
Nothing executed. I read the diff, the cited lines and the unit template.
Verdict: approve.