[contextablemark]

What this changes

With the supervisor on a shared network (Compose), ensure hands the server http://<container name>:4100. Docker's embedded DNS answers only for names of up to 63 characters (one DNS label). Longer names are listed in the endpoint's DNSNames but never resolve. An isolated Bot's container name, <namespace>-computer-bot-agent_<uuid>, is exactly 63 characters with the default openbot namespace, so any longer COMPUTER_NAMESPACE (or a long person id) gives a computer that starts and reports healthy while every server request to it fails with ENOTFOUND. The Bot then reports that its computer isn't running.

This adds networkHostFor(container, shortId) to names.ts: the container name if it is 63 characters or fewer, otherwise the container's 12-character short id, which Docker registers on every user-defined network too. inspectOwned now also returns the short id. Names that fit, including every name derived with the default namespace, are used exactly as before.

A short id changes when the container is replaced. That's fine here: the server takes the address from every ensure, and a stale one resolves to nothing rather than to a different computer.

Where it runs

• New state that outlives a request? None. Read from docker inspect on each ensure.
• What happens on the second replica? Server replicas receive the address from the supervisor on each ensure; a supervisor gives the same answer for the same container.
• Anything serialised? No.
• Anything fanned out to a browser? No.
• New listener, port, or schedule? No. Same port, different name for the same container.

Boundary and audit

• Every acting call still goes through the gateway: resolve, decide, audit, then act.
• New refusals and new failures each write a row. (None added.)
• Nothing new is trusted from the client that the server can resolve itself. The short id comes from docker inspect of a container inspectOwned has already confirmed is this supervisor's.

Changelog

• A line in CHANGELOG.md under Unreleased.

Proof

Docker DNS limit, on Docker Engine 29.9.2 (Docker Desktop, arm64), resolving from the Debian server image on a throwaway user-defined network:

17 chars, probe_under_score: resolves
63 chars, probe-000…000: resolves
64 chars, probe-0000…000: NOT-FOUND

In a local staging of c396a5f with COMPUTER_NAMESPACE=albert-openbot, an isolated Bot's computer albert-openbot-computer-bot-agent_3e08c0e4-… (70 characters) was healthy, but getent hosts and dns.resolve4 both returned not-found from the server container, while its short id resolved. Every browser action failed. With this change built into the supervisor image, the same isolated Bot completed browser tasks on its own computer (the person computer had no browser running).

bun test in supervisor/: 46 pass, 1 skip (the opt-in Docker lifecycle suite), 0 fail, including three new cases in names.test.ts: a 63-character name is kept, longer names fall back to the short id, and with no short id the name is kept. tsc --noEmit in supervisor/ is clean, and biome format and lint are clean.

🤖 Generated with Claude Code