* fix(proxy): bump pinned meta-proxy release 0.4.0 -> 0.7.3
`DEFAULT_PROXY_RELEASE` had not moved in six meta-proxy releases, so
`ruflo proxy install` shipped a binary predating every fix since v0.4.0:
- require explicit Cognitum Cloud routing consent (#60) first in v0.7.0
- handle --help before binding (#74/#76) first in v0.7.2
- --help/--version win from any argv position (#85) first in v0.7.3
- reload live daemon config on login/logout (#28) first in v0.4.1
- pin the Linux glibc floor to 2.28 (#66) first in v0.7.1
The consent one matters most: the install disclosure promises cloud
routing is "never enabled by install alone", but the commit that
separated authentication from routing consent landed in v0.7.0 — after
the pinned build.
The --version regression is directly observable on 0.4.0: the binary
starts the daemon, writes the token file and binds 127.0.0.1:11435,
where meta-proxy's own source documents --version as side-effect-free
("no server, no I/O"). Any probe silently leaves a listener running.
Also stop hardcoding the version in proxy.ts's example text. That string
was written as a literal rather than interpolating the constant, so the
advertised version could — and did — drift from the installed one. Both
tests now read the pin from the module for the same reason; asserting a
literal means every bump needs hand-edited test expectations.
Verified on Windows x64: `ruflo proxy install --release 0.7.3 --yes`
installs with signature + checksum verification intact, and `--version`
then prints and exits with no process left running and no port bound.
Test: 9 proxy test files, 56 tests, all passing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(proxy): surface pin drift to already-installed users
Bumping DEFAULT_PROXY_RELEASE only changed what a NEW install receives.
Someone who had already run `proxy install` on 0.4.0 got no signal that
anything moved: `proxy status` reported installation as a boolean, and
`proxy update` required an explicit --release, so reaching a newer binary
meant already knowing its version number. The fixes that motivated the bump
therefore reached only the users who did not yet have the problem.
ProxyStatus now carries `version`, read from the install manifest install.ts
already writes. `proxy status` prints it, the console guidance names the gap
and the command that closes it, and `proxy update` defaults to the pin the
same way `install` does. Updating stays explicit and user-initiated.
The version is read from the manifest, never by executing the binary:
releases before v0.7.2 start the server and bind a port on ANY invocation,
so a `--version` probe against an old build leaves a listener running --
precisely the state this check exists to detect. A missing or malformed
manifest reports "unknown", never "up to date".
Also corrects two stale claims this change makes load-bearing:
- proxy/lifecycle.ts's header asserted as fact that the binary "takes no
CLI flags -- no --version/--help, any invocation just starts the server"
(confirmed 2026-07-16). v0.7.2 handles --help before binding and v0.7.3
makes --help/--version win from any argv position. Left as-is, the next
reader concludes no version handshake is possible.
- ADR-307 still described the pin as v0.4.0 -- a fourth copy of the literal
this PR is de-duplicating, and the one a reviewer reads to decide what
the pin should be. It now names no version at all and points at the
constant, plus records the drift-surfacing behavior.
Test: 9 proxy test files, 64 tests, all passing (was 56).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Dragan Spiridonov