fix: the datagram gateway is its own application, release and image

[Taure]

Closes #513.

Why a role could never do this

The two-role split was a switch read inside asobi_app:start/2. OTP starts an application's dependencies before its start callback runs, so by the time ASOBI_ROLE was read, the container parsing packets from the internet had already:

• opened a pool with the tenant credentials (kura, via kura_app:start/2 → ensure_pools())
• run schema migrations and started job workers, cron and pruner against the shared database (shigoto)
• bound an HTTP port with no auth subsystem behind it (nova)

None of that can be undone from inside start/2. Only a release that never listed those applications can avoid it.

What this is

asobi_dgram_gw is an OTP application holding the thirteen modules that face the internet plus the codec both roles share. Its dependency list is kernel, stdlib, crypto, telemetry, seki. asobi depends on it; the reverse dependency does not exist, which is what lets the gateway ship without the engine.

Two relx releases follow, and docker build --target gateway produces an image whose entire lib directory is:

asobi_dgram_gw  crypto  kernel  sasl  seki  stdlib  telemetry

Verified by booting it, not by reading the release spec:

started: [asobi_dgram_gw,crypto,seki,telemetry]
kura/nova/shigoto loaded: {false,false,false}
gateway tree: [asobi_dgram_canary,asobi_dgram_link_server,asobi_dgram_rx_sup,
               asobi_dgram_sender,asobi_dgram_table]
canary ready: true

That last line is the one that matters: the readiness canary sends itself a real datagram and waits for it to come back, so the receive loop, the sender, the shards and the binding table all work with no engine anywhere.

Three things the split needed beyond moving files

Telemetry. asobi_dgram_telemetry (in the new app) owns every [asobi, dgram, *] event, because a module in the asobi application is not reachable from a release that does not contain it. asobi_telemetry:events/0 folds that list in, so an operator still attaches to one list and every event still has exactly one definition — link_up is emitted by both roles and defined once. The coverage test now derives the emitted set from both modules, and the drift script scans both trees.

A log formatter. nova_jsonlogger lives inside the nova application; pulling nova in for a formatter would bring cowboy, ranch, erlydtl and routing_tree with it and undo the whole thing. asobi_dgram_gw_logger is the same contract in the smallest form that honours it — one JSON object per line, carrying the fields the observability guide tells operators to query on, encoded with OTP's json. It is total on report contents, because a formatter that raises takes the handler down and the node goes quiet.

Its own sys.config. Four lines. A gateway container must not be handed ${ASOBI_DB_*} just to render a config file it never reads.

Compatibility

• ASOBI_ROLE=dgram_gw on the engine image still starts the gateway and only the gateway. It still carries the flaw above; the guides now say so plainly instead of claiming an isolation the code could not provide.
• rebar3 as prod release now needs -n asobi or -n asobi_gw — relx refuses to guess once a project declares more than one release. The Dockerfile is updated; the only other mention in the repo is a snippet about a consumer's own release.
• The {asobi, [{dgram, ...}]} configuration keys are unchanged, deliberately. asobi_dgram_env moved into the gateway app but still reads and writes the asobi application's env, because those keys are the documented surface and every existing sys.config spells them that way. ELP flags the cross-app read (W0011); it is the same pattern asobi_lua_env already has, and the moduledoc explains it.

For whoever publishes images

This adds a second build target. The guides name it ghcr.io/widgrensit/asobi-dgram. Nothing in this repository publishes either image, so that tag needs building wherever ghcr.io/widgrensit/asobi is built — until it exists, self-hosters can build it themselves with docker build --target gateway, which the guides say.

Checks

fmt --check / xref / dialyzer / elp eqwalize (new modules clean; the 2 in asobi_sup and 1 in asobi_telemetry are pre-existing) / elp lint / eunit 2147, 0 failures / ct 388, 0 failures / ex_doc (2 pre-existing warnings) / all three drift scripts.

[github-actions]

🟡 Code Coverage — 76.2%

8591 of 11280 lines covered.

---

🟡 ELP Lint — 192 warnings

210 diagnostics found. See job logs for details.