plans: row 87 round 8 counts a stop's no-such-container as gone, bounds each wait per container and gives I6 the unit comment (#1581)

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/plans/2026-10-18_containerized-install-design.md

@@ -11,7 +11,8 @@ answers Darkwing's round 4 review (28877) and Filbert's doc-only
 follow-up on the stop timeout (28876). Round 6 answers Darkwing's round
 5 review (28880) and Filbert's doc-only follow-ups (28881). Round 7
 answers Darkwing's round 6 review (28884) and Filbert's doc-only
-follow-up on the start order (28883).
+follow-up on the start order (28883). Round 8 answers Darkwing's round
+7 review (28890) and Filbert's doc-only follow-ups (28889).
 
 This doc turns decisions 105 to 108 into interfaces. It doesn't reopen
 them. Every claim about container behavior cites a spike in
@@ -281,11 +282,22 @@ that by putting each fork's events on the channel.
   during that removal errors instead of waiting, so the rule then waits
   until each listed container is gone, by id, bounded by the core stop
   timeout. Gone means the endpoint answers "no such container" for that
-  id. A container still there at the bound gets `docker rm -f` and the
-  same bounded wait. One still there after that makes bus start refuse
-  with exit 1, `leftover core container <id> not removed`, which the
-  unit retries after `RestartSec`, since an engine still removing is a
-  passing state. Each step goes to the host log. `docker run` starts
+  id. The same answer from `docker stop` or `docker rm -f` also counts
+  as gone, so a leftover the engine removed between the list and the
+  stop isn't a refusal. A container still there at the bound gets
+  `docker rm -f` and the same bounded wait. One still there after that
+  makes bus start refuse with exit 1, `leftover core container <id> not
+  removed`. That is the one refusal that exits 1, not 3: the unit
+  retries it after `RestartSec` (`mosaic-bus.service.in:31-33`), since
+  an engine still removing is a passing state. I6 updates the unit's
+  `ExecStart` comment, which today says refusals exit 3. Each bound is
+  per container: the stop, the wait and the wait after `rm -f` each get
+  one core stop timeout, so one leftover costs at most three, 135 s at
+  today's value. The unit is `Type=simple` with no start timeout. Five
+  exit-1 starts within 600 s reach `StartLimitBurst=5`
+  (`mosaic-bus.service.in:9-10`), and systemd then stops retrying until
+  a human runs `systemctl --user reset-failed`. The host log names the
+  leftover's id each time. Each step goes to the host log. `docker run` starts
   only once every listed container is gone. `host.lock` is held, so no
   live host owns a leftover. A
   leftover that stopped on SIGTERM has removed `writer.lock`. One that

docs/plans/2026-10-18_containerized-install-rows.md

@@ -408,6 +408,9 @@ and no document states the limits in design section 10.
   start and `hostStatus`, and the `bus status`
   lines in `packages/cli/src/cli.mjs` (design section 3, "The core
   container's lifecycle").
+- `packages/cli/systemd/mosaic-bus.service.in`, the `ExecStart` comment
+  only: the leftover refusal exits 1 and the unit retries it, and every
+  other refusal still exits 3.
 - `compose.yaml`, `scripts/run-task.sh` and the worker adapter files it
   uses.
 - The scripts listed in I2's problem, moved to `scripts/lib/docker.sh`.
@@ -490,6 +493,9 @@ and no document states the limits in design section 10.
       conflict: the rule waits until the stopped container is gone;
     - a leftover that is never removed in the bound makes bus start
       refuse with exit 1 and log its id;
+    - a leftover removed between the list and `docker stop`: the "no
+      such container" answer counts as gone, and the core container
+      boots;
     - a container that already holds the core name but not the store's
       labels makes bus start refuse with exit 3 and the message naming
       the name and the client's exit code; `host.lock` is given back,