deployment-specification: gateway self-registration + NOETL_GATEWAY_RUNTIME_REGISTRY noetl/ai-meta#455 P2 — the Gateway kind. Records the new env var (default on), the lease semantics, and that the heartbeat interval is read from the server's ttl_secs rather than configured on both sides. Flags that POST /api/runtime/register is privileged: the auth gate is in shadow mode today, so the call succeeds unauthenticated; an enforce flip needs a service credential or registration starts failing fail-soft.
docs(metrics): the gateway's auth-outcome surface Documents the three metrics added 2026-08-05, including the one that matters most: noetl_gateway_auth_bypass_enabled is 1 when authentication is DISABLED, and is registered in both states so a healthy gateway reads 0 rather than being absent. Records why the SUCCESS outcomes are counted too — a spike in invalid_or_expired means nothing without ok beside it, and an auth backend failing every request looks identical to one nobody is using. Also states plainly that this component cannot be kind-validated today: its images are amd64-only against an arm64 cluster (noetl/ai-meta#245), so these metrics are unit-verified and have never been confirmed against a real scrape. That limitation belongs on the page, not only in an issue. Refs noetl/ai-meta#238, noetl/ai-meta#245
docs(metrics): the gateway DOES expose /metrics — and why that read as 'no' This page said the gateway exposes no Prometheus endpoint. It does, at GET /metrics on the serving port (8090). The reason the opposite was easy to conclude is worth recording: every ingress metric is labelled by subscription, and Registry::gather prunes metric families with no children, so before any delivery has arrived the endpoint returns HTTP 200 with a ZERO-BYTE body. Checking it on a quiet gateway produces exactly the evidence you would expect from 'there is no endpoint'. noetl_gateway_build_info{version} is unconditional and needs no traffic, so the endpoint now always answers with at least the running version — which also separates 'unscraped' from 'wrong port' from 'binary too old', three states an empty body could not distinguish. The no-PodMonitoring half of the original claim is correct and kept, re-verified 2026-08-05: ns gateway has no scrape configuration at all. Adds the metrics table, noting the three ingress counters are absent until the first matching delivery — normal, not a fault. Refs noetl/ai-meta#238
docs: add the gateway deployment specification wiki-maintenance Rule 2a names noetl-gateway as needing one, and it was the only deployed component without it — configuration.md and deployment.md cover the knobs and the roll, but nothing stated the runtime CONTRACT. Measured against prod rather than written from the manifests. Three findings worth having on the page: - The gateway REFUSES TO START without NOETL_EVENT_FEED_ADDR or NOETL_KV_ADDR — an explicit bail with a message naming the writer's SSE face. That is the opposite of the server and worker, whose equivalents fall back to a quiet default, and it is worth knowing which kind of silence you are dealing with. - /health is a liveness check, not a dependency check. A gateway that has lost its events feed stays Ready; the only symptom is the log. - NOETL_EVENT_SOURCE=ehdb is set in prod and does NOTHING. EventSourceMode::from_env_value is called only from its own unit tests and main.rs starts the EHDB listener unconditionally. EHDB-only by construction is correct post-T5; the variable, the enum and its Nats variant are residue, and the enum's doc comment still promises a nats fallback that does not exist. Also records that the gateway has no metrics endpoint and no PodMonitoring — namespace gateway has no scrape configuration at all, so its only signal is the log. Refs noetl/ai-meta#241, noetl/ai-meta#242