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

Candidate: commit 4c1fee85a (4c1fee85a545d9cd10f835b35c27478b8f68552d), diff from 80ebe2afc 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 4c1fee85a.

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 6 follow-up (28883): answered

design.md:156-158 names the order: `host.lock`, the store path, the rootless check, the leftover rule, then `docker run`. The rootless check it points to is in section 4 (design.md:361-402, the `name=rootless` element rule at :372). The store path bullet now says "right after `host.lock`" (:159).

## The rest of the round

- **Wait by id** (design.md:274-292). After `docker stop -t`, the rule waits until each listed id answers "no such container", bounded by the core stop timeout. Then it runs `rm -f` with the same wait, then exits 1 with the id. That closes the race where `--rm` is still removing and `docker run` hits the name. Tested at rows.md:489-492.
- **Exit codes.** The unit retries exit 1 and doesn't retry exit 3: `RestartPreventExitStatus=2 3 4` at packages/cli/systemd/mosaic-bus.service.in:33, with `Restart=on-failure` and `RestartSec=15` at :31-32. So exit 1 for an engine still removing and exit 3 for a hand-made container match what the unit does. Since the name is a hash of the store path and `host.lock` excludes another host, a name holder without the store's labels can only be hand-made (or a 64-bit hash collision), as design.md:183-186 says.

## Doc-only, follow-up

1. design.md:277-285: the list and `docker stop` are separate calls, so a leftover can be removed between them, and `docker stop` on that id then fails with "no such container". Say that answer from `stop` (or `rm -f`) counts as gone, so I6's builder doesn't turn it into a refusal.
2. design.md:280-285: say whether the bound is per container or for the whole list. With N leftovers waited one at a time, the worst case is about 3 x 45 s per container before `docker run`. That's fine under `Type=simple` with no start timeout (service.in:13), but it bears on `StartLimitBurst=5` in `StartLimitIntervalSec=600` (:9-10). Normally N is at most 1, so this is wording only.

## Not run by me

Nothing executed. This is a read of the diff, the cited design lines and the unit template.

Verdict: **approve**, with follow-ups 1 and 2.