HydraIssues

Found while fixing the fleet after the hydracluster admin token rotation (2026-08-31).

OBSERVED: the previous hydracluster admin token appears as a literal string inside published hydrastreamingmonitor release binaries on the mirror, in at least v0.4.36, v0.4.37, v0.4.38, v0.4.39 and v0.5.0, for both linux-amd64 and linux-arm64. Those binaries are served publicly through releases.experiencenet.com and the district mirrors.

WHY IT MATTERS: this is not a stale-artifact problem, it is a build problem. The token was current when those builds were made, so the pattern is live: the next release built today would embed the NEW token the same way. I verified the current token is not in any published binary yet, so there is no live exposure right now, but that is timing rather than design.

The credential belongs in config at runtime (hydrastreamingmonitor already reads cluster_token from /srv/scales/hydrastreamingmonitor/config.yaml on the node), never compiled in. Likely cause is a default or example config embedded into the binary with a real value in it rather than a placeholder.

ASK:

1. Find where the token enters the build (embedded default config, ldflags, or a committed config file) and replace the real value with an empty placeholder.
2. Add a CI check that fails the build if a 64-hex-character credential appears in the output binary.
3. Consider purging the affected versions from the mirror, or accept them as historical given the token is now invalid.

RELATED, same rotation sweep: the old token was also pasted into the descriptions of issues #245 and #188 on this tracker, which are readable. Same class of problem, different channel. Worth a convention that credentials are never pasted into issue text.

Already fixed as part of the rotation: hydraneck cluster.token plus the service configs on all three Pis (hydrastreamingmonitor, hydrabodystatus, hydraexperiencelibrary, hydravenues, linuxrunner, linuxpipeline) now carry the current token and all report healthy.