Summary

Follow-up to #33583 (the gateway run auto-supervise redirect).

Before this fix, the supervised gateway's stdout was swallowed by s6-log into the rotated file at ${HERMES_HOME}/logs/gateways/<profile>/current and never reached docker logs. Operational signal lived in two places, depending on which fd a given log line went to:

Users running docker run … gateway run against the s6 image would see partial output in docker logs (warnings yes, the iconic ⚕ Hermes Gateway Starting banner no), conclude something was broken, and have to docker exec + tail the file to find the missing pieces.

Fix

Add the 1 s6-log action directive before the file destination so each line is forwarded to s6-log's stdout — which propagates up through the s6-supervise pipeline to /init's stdout = container stdout = docker logs. The file destination is preserved as a second destination, so the rotated log (with ISO 8601 timestamps) still exists for hermes logs and for survival across container restarts.

- exec s6-setuidgid hermes s6-log    n10 s1000000 T "$log_dir"
+ exec s6-setuidgid hermes s6-log  1 n10 s1000000 T "$log_dir"

Trade-off: timestamps

T is non-sticky in s6-log — it only prefixes lines for the next action directive. Putting T between 1 and the file (not before 1) means:

• docker logs shows raw lines. Python's logging formatter already has its own timestamps, and docker logs --timestamps adds another layer when desired. No double-stamping in the common reading path.
• The rotated file gets s6-log's ISO 8601 timestamp so even output that lacked a Python-logger timestamp (rich banners, third-party raw prints) is correlatable in current.

Verification

Unit test

New assertion in test_service_manager.py locks the s6-log 1 directive into the rendered run-script. Mutation-tested: reverted the source to the pre-fix script (no 1); the assert caught it cleanly with a clear failure message naming the missing directive.

Docker harness test

New test_supervised_gateway_stdout_reaches_docker_logs (in tests/docker/test_gateway_run_supervised.py):

• Builds the image
• Runs docker run -d <image> gateway run
• Asserts the unique ⚕ banner glyph (or "Hermes Gateway Starting" text) reaches docker logs
• Cross-asserts the same banner is also in the rotated log file (so we haven't lost the file destination)

End-to-end mutation-tested: built a deliberately-broken image without the 1 directive; the test failed exactly as designed, with the diagnostic showing the banner present in current but absent from docker logs.

Regression sweep

• tests/hermes_cli/ — 5,561 tests pass, 0 fail
• tests/docker/ — 27 tests pass (5 existing in test_gateway_run_supervised.py + the new one, plus 21 in the other 7 docker test files), 0 fail

Docs

website/docs/user-guide/docker.md gains a new :::note Where gateway logs go admonition documenting both destinations explicitly (the supervised stdout → docker logs, the rotated file → hermes logs reads it, persisted via volume mount) plus the audit log at ${HERMES_HOME}/logs/container-boot.log. The existing :::tip Gateway runs supervised admonition's claim that "docker logs shows the supervised gateway's output" — which was previously aspirational — is now actually correct.

Files