plans: row 87 follow-ups on the start limit, and decisions 147 (B1) and 148 (B2) (#1581)

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

docs/plans/2026-09-26_lead-decisions.md

@@ -3322,3 +3322,39 @@ which stay with him. Each item names who decided it and what happened.
       main stays out of scope.
     - This replaces the "waits for your ready" line under Needs Jason in
       my 2026-10-15 AM standup. Nothing goes to Jason for it now.
+
+147. **B1: in containerized mode the Console binds 0.0.0.0 inside its own
+    network namespace, with the publish on host 127.0.0.1 (2026-10-18,
+    Mos mos-0674, recorded after row 87 round 8 was approved by Darkwing
+    28893 and Filbert 28894).** This is the decision 107 enforcement
+    change in design section 8
+    (`docs/plans/2026-10-18_containerized-install-design.md`).
+    `startServer` refuses a non-loopback bind
+    (`packages/webui/src/serve.mjs:252-253`). Docker forwards a
+    published port to the container's own interface, so the container's
+    127.0.0.1 can't be reached through `-p`.
+    - Only in containerized mode, only inside the Console container's
+      network namespace, and the publish stays on host `127.0.0.1`. The
+      in-container port equals the published port. Local mode keeps the
+      loopback refusal.
+    - I4's tests are the evidence. Nothing new reaches the Console beyond
+      what decisions 105 and 106 already allow, so it stays in Q167 and
+      doesn't go to Jason. The other-uid reach of the port is P19 333,
+      under Needs Jason, with the default "documented limit" (mos-0657).
+
+148. **B2: the host channel is the core container's stdin and stdout
+    (2026-10-18, Mos mos-0674, recorded with decision 147).** Design
+    section 3. The bus host starts the core container with `docker run
+    -i` as its own child. `packages/cli/src/core-entry.mjs` forks
+    `process.mjs` and the notifier with IPC unchanged and relays tagged
+    JSON lines over the client's stdin and stdout.
+    - The channel adds no authentication of its own. Anything that holds
+      the engine endpoint can attach to stdin, but it can already exec
+      into the container. Decision 106 limits the endpoint to host
+      processes, and decision 105 accepts the Jason-uid routes.
+    - Replies carry caps, so the core container runs with `--log-driver
+      none`. The entry exits on stdin EOF and the container runs with
+      `--rm`, so the bus host's exit stops the container.
+    - I6 carries Mos's two checks: when the bus host exits, the core
+      container stops too, and the container's Docker logs hold no
+      capability token.

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

@@ -295,9 +295,14 @@ that by putting each fork's events on the channel.
   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
+  (`mosaic-bus.service.in:9-10`), and systemd then stops retrying. Only
+  fast failures can trip it: a refusal that waits out all three bounds
+  takes 135 s plus `RestartSec`, so five of them don't fit in 600 s, and
+  I6's docs don't promise that a stuck leftover ends in the start limit.
+  Once it trips, `systemctl --user reset-failed` clears the limit but
+  doesn't start the unit, so a human starts it again after that, or
+  once the 600 s window has passed. Each step goes to the host log,
+  with the leftover's id. `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