[finding] /api/v1/health reports a hardcoded version: '1.0.0' — a field that exists and lies, so no consumer can use it for artifact identity #10993

registerBuiltinDomains() in packages/runtime/src/http-dispatcher.ts answers GET /health with:

version: '1.0.0',

It is a literal, unchanged since the domain was lifted out of the dispatch if-chain, and it is served on every runtime — single-env, EE, and every hosted tenant. Nothing derives it from the package version, the build, or anything else, so the field is not "the version": it is the string 1.0.0.

Why this surfaced. objectstack-ai/cloud#1537 needed the SERVING process to name the artifact it is running: cloud's production container served a three-month-old image behind four green deploys (cloud#1534), and boot-freshness alone could not see it. /api/v1/health was the natural home — the payload already has a version slot, and the health endpoint is already probed post-deploy. It could not be used, because the field is a constant, so cloud added a container-stamped response header (x-objectstack-build-sha) on its own side instead.

The shape of the fix, if it is wanted. Something the host can set — e.g. read an env var / an injected build stamp at kernel construction and fall back to the package version — rather than a literal. Nothing about the liveness contract changes (framework#3756's "checks NOTHING beyond 'this process is executing code'" stays true; the payload is not a health signal).

Filed as an observation from cloud#1537, not a request: cloud's need is met without it. The reason to raise it is that a field which looks authoritative and is not is worse than no field — it invites exactly the use that cloud attempted.

Generated by Claude Code