feat(observability): say what this process can do, once, at boot #548

Merged

coilyco-ops merged 1 commit from coilyco-ops/say-what-this-process-can-do into main

2026-08-13 15:44:44 +00:00

AGit

coilyco-ops commented

2026-08-13 15:41:11 +00:00

Member

closes #539 - a capability that was never switched on is indistinguishable from inside the process from one that was never built, and nothing reported the difference.

coilyco-ops added 1 commit

2026-08-13 15:41:11 +00:00

feat(observability): say what this process can do, once, at boot

ci / image-build (pull_request) Successful in 25s

Details

ci / test (pull_request) Successful in 36s

Details

ci / publish-echo-image (pull_request) Has been skipped

Details

ci / publish-observed (pull_request) Has been skipped

Details

5b28fad38b

Three capabilities were found built and inert today, each independently, each
by reading the harness and the deployment together: the content gate, the
durable job store, and Echo's scratchpad.

The cause is a property worth keeping. An unset variable offers no tools rather
than tools that fail, so absence is inert rather than broken. The cost is that
a capability which was never switched on looks, from inside the process,
exactly like one that was never built, and nothing said which.

discord.ready logs identity, channel and build revision. Nothing anywhere said
what the process could do.

Run now emits one capabilities line before the gateway opens, naming the
content gate, the job store kind, jobs, the scratchpad, fetch, the issue
tracker, the three Discord surfaces, and the roster size.

Presence, never values. It does not say where the scratchpad is mounted, which
hosts fetch may reach, or which channel is served. A line naming those grows
into an identifier surface, which this service guards against elsewhere, and
an operator asking whether something is on does not need them. The roster is a
count for the same reason, and a test asserts a configured path and host do not
appear in the line.

The job store is a string rather than a bool, because the durable store and the
one that drops every in-flight job on a roll are both "a job store" to a reader
who only learns that one exists.

It reports and does not judge. Nothing fails a startup. The runtime cannot tell
whether an inert capability is a mistake, since a profile that legitimately has
no scratchpad and one that was meant to have it are the same process. Only
deployment knows, so the runtime states the fact.

One note on the tests: the first version captured through telemetryOrNoop,
which writes to io.Discard, so the leak assertions passed against an empty
string. They build a real handler now and fail loudly if nothing is captured.

closes #539

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-13 15:41:12 +00:00

coilyco-ops referenced this pull request

2026-08-13 15:41:31 +00:00

Three capabilities are built and inert, and nothing says so at boot or anywhere else #539

coilyco-ops merged commit 5d4b6397df into main

2026-08-13 15:44:44 +00:00

coilyco-ops referenced this pull request from a commit

2026-08-13 15:44:46 +00:00

Merge pull request 'feat(observability): say what this process can do, once, at boot' (#548) from coilyco-ops/say-what-this-process-can-do into main

coilyco-ops referenced this pull request

2026-08-13 15:46:37 +00:00