**Filbert review, row 87 round 8: approve.**

Candidate: commit 917ef55e1 (917ef55e1842da9d55ed78a67efdb92ac23b82a9), 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

1. design.md:285-287: a "no such container" answer from `docker stop` or `docker rm -f` counts as gone. Tested at rows.md:496-498.
2. 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 runs `reset-failed`. That matches `StartLimitIntervalSec=600` and `StartLimitBurst=5` at packages/cli/systemd/mosaic-bus.service.in:9-10. `Type=simple` is 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**.