The miner CLI already reports some version today — bin/gittensory-miner.js reads require("../package.json").version at startup (:57-59) and wires it to --version/-v/version (:80-87) via printVersion (packages/gittensory-miner/lib/cli.js:1-2: `${packageName}/${packageVersion} (node ${process.version})`). So this issue isn't adding version reporting from nothing — it's adding a build-time-injectable override, because that require() read is only ever correct for a laptop-mode npm install (where package.json really is what got installed). It will not necessarily be correct for the new fleet Docker image (sibling Phase 6 Dockerfile issue), which — like the main service — may get built from a commit/tag ahead of the last npm-published version.
Two real precedents already exist in this repo for two different ways to bake a version in, and this item most likely wants a combination:
packages/gittensory-engine/src/version.ts derives ENGINE_VERSION from its own package.json at compile time via a JSON module import (import ownPackageJson from "../package.json" with { type: "json" }) — shipped 2026-07-08. gittensory-miner has no build/bundle step today (its build script is just node --check over plain ESM files, confirmed in packages/gittensory-miner/package.json:34), so this exact pattern is directly usable without adding a bundler: a small lib/version.js exporting MINER_VERSION the same way.
- The root
Dockerfile instead threads a build-time-supplied value all the way to runtime: ARG GITTENSORY_VERSION → ENV GITTENSORY_VERSION=${GITTENSORY_VERSION} (lines 6, 31-38), read at runtime in src/selfhost/sentry.ts:192 and src/selfhost/otel.ts:62 (env.GITTENSORY_VERSION, falling back to SENTRY_RELEASE) — this is how the main service's image asserts its actual built ref for observability/release tagging, independent of package.json. GITTENSORY_MINER_VERSION doesn't exist anywhere in the repo yet (confirmed by search); this issue is what introduces it, mirroring that same ARG/ENV shape for the new fleet Dockerfile (sibling Phase 6 issue).
Deliverables
References
packages/gittensory-engine/src/version.ts — the compile-time JSON-import pattern to mirror for a MINER_VERSION constant.
Dockerfile (repo root) lines 6, 31-38 — the ARG/ENV GITTENSORY_VERSION threading pattern to mirror for GITTENSORY_MINER_VERSION.
src/selfhost/sentry.ts:192, src/selfhost/otel.ts:62 — where the main service actually reads its env-supplied version at runtime, for the equivalent read-site pattern.
packages/gittensory-miner/bin/gittensory-miner.js:57-59,80-87, packages/gittensory-miner/lib/cli.js:1-2 (printVersion) — the existing (package.json-only) version-reporting code path this issue extends.
packages/gittensory-miner/package.json:34 — confirms no build/bundle step exists yet, so the compile-time JSON-import approach needs no new tooling.
The miner CLI already reports some version today —
bin/gittensory-miner.jsreadsrequire("../package.json").versionat startup (:57-59) and wires it to--version/-v/version(:80-87) viaprintVersion(packages/gittensory-miner/lib/cli.js:1-2:`${packageName}/${packageVersion} (node ${process.version})`). So this issue isn't adding version reporting from nothing — it's adding a build-time-injectable override, because thatrequire()read is only ever correct for a laptop-mode npm install (where package.json really is what got installed). It will not necessarily be correct for the new fleet Docker image (sibling Phase 6 Dockerfile issue), which — like the main service — may get built from a commit/tag ahead of the last npm-published version.Two real precedents already exist in this repo for two different ways to bake a version in, and this item most likely wants a combination:
packages/gittensory-engine/src/version.tsderivesENGINE_VERSIONfrom its ownpackage.jsonat compile time via a JSON module import (import ownPackageJson from "../package.json" with { type: "json" }) — shipped 2026-07-08.gittensory-minerhas no build/bundle step today (itsbuildscript is justnode --checkover plain ESM files, confirmed inpackages/gittensory-miner/package.json:34), so this exact pattern is directly usable without adding a bundler: a smalllib/version.jsexportingMINER_VERSIONthe same way.Dockerfileinstead threads a build-time-supplied value all the way to runtime:ARG GITTENSORY_VERSION→ENV GITTENSORY_VERSION=${GITTENSORY_VERSION}(lines 6, 31-38), read at runtime insrc/selfhost/sentry.ts:192andsrc/selfhost/otel.ts:62(env.GITTENSORY_VERSION, falling back toSENTRY_RELEASE) — this is how the main service's image asserts its actual built ref for observability/release tagging, independent of package.json.GITTENSORY_MINER_VERSIONdoesn't exist anywhere in the repo yet (confirmed by search); this issue is what introduces it, mirroring that sameARG/ENVshape for the new fleet Dockerfile (sibling Phase 6 issue).Deliverables
packages/gittensory-miner/lib/version.js(or similar) exporting aMINER_VERSIONconstant read from the package's ownpackage.jsonat import time, followinggittensory-engine/src/version.ts's JSON-import pattern.GITTENSORY_MINER_VERSIONenvironment-variable override: when set, it wins over the package.json-derived value — this is the piece that lets the fleet Docker image (sibling issue) assert its real build ref viaARG GITTENSORY_MINER_VERSION→ENV, mirroring the root Dockerfile'sGITTENSORY_VERSIONhandling.printVersion's output (packages/gittensory-miner/lib/cli.js) and intogittensory-miner status --jsonif that command reports a version field — so both form factors (laptop npm install, fleet Docker image) report a value that's actually correct for how they were built, not just always the npm package.json.References
packages/gittensory-engine/src/version.ts— the compile-time JSON-import pattern to mirror for aMINER_VERSIONconstant.Dockerfile(repo root) lines 6, 31-38 — theARG/ENVGITTENSORY_VERSIONthreading pattern to mirror forGITTENSORY_MINER_VERSION.src/selfhost/sentry.ts:192,src/selfhost/otel.ts:62— where the main service actually reads its env-supplied version at runtime, for the equivalent read-site pattern.packages/gittensory-miner/bin/gittensory-miner.js:57-59,80-87,packages/gittensory-miner/lib/cli.js:1-2(printVersion) — the existing (package.json-only) version-reporting code path this issue extends.packages/gittensory-miner/package.json:34— confirms no build/bundle step exists yet, so the compile-time JSON-import approach needs no new tooling.