HydraIssues

Context

The kiosk agent has three names in use. This confuses operators.

1. Repo and binary: hydraheadflatscreen. The repo was renamed from hydraheadwindows when macOS support landed.
2. Release-server updater project and CLI brand: hydrahead. releases.experiencenet.com/hydrahead/production/latest.json is live (currently 2.2.2). The cobra root command is Use: "hydrahead" in internal/cli/root.go. The version command prints "hydrahead vX.Y.Z".
3. Legacy compat project: hydraheadwindows. CI dual-publishes to releases.experiencenet.com/hydraheadwindows/ so pre-rename Windows heads keep updating (also at 2.2.2).

releases.experiencenet.com/hydraheadflatscreen/production/latest.json returns 404. That project has never existed. Stale references to it in CLAUDE.md were fixed on 2026-08-18 (commit 7d6dc44 in hydraheadflatscreen).

Every deployed head requests /hydrahead/... through the hydrarelease updater library. The project name is passed in internal/cli/root.go and pkg/client/client.go. A hard rename of the release project would strand the updaters on every deployed head.

Options

Option A: Keep hydrahead permanently

Treat hydrahead as the deliberate short product name for the updater project and the CLI brand. Document this in the repo README and CLAUDE.md: repo is hydraheadflatscreen, product and release project is hydrahead. No fleet risk. No CI change.

Option B: Migrate to hydraheadflatscreen

Use the same compat pattern that already covers hydraheadwindows:

1. CI dual-publishes every release to both hydrahead and hydraheadflatscreen.
2. Wait at least one full fleet update cycle so every head runs a build that exists under both names.
3. Ship a release that switches the updater project constant to hydraheadflatscreen (internal/cli/root.go and pkg/client/client.go).
4. Wait until all heads report the new version.
5. Retire the hydrahead project. Decide the fate of hydraheadwindows at the same time.

Rollback at any step: heads still on the old constant keep updating from hydrahead as long as dual-publish runs.

Status

This issue is a decision record. Do not execute anything until a decision is made. No code, CI, or server changes are part of filing this issue.

Scope widened 2026-08-18: general naming rule, not only hydrahead

The same confusion exists for the kiosk app, which carries six spellings of one product:

Most of the per-platform variation follows each platform's native convention (macOS bundles are CamelCase, Unix binaries lowercase-hyphenated), which is a defensible policy. The gap is that no written rule exists, so every new artifact improvises.

Proposed rule to decide alongside the hydrahead question:

• Repos and Unix binaries: lowercase-hyphenated or flat lowercase, matching the repo name.
• macOS bundles and their artifacts: CamelCase of the same name.
• Release-server projects: flat lowercase, never renamed once heads consume them (the migration cost documented above applies to every project).
• App-ids and service identifiers already deployed to fleets are frozen unless a migration plan ships with the change.

Decision record only. Nothing renames until decided; frozen items above stay frozen regardless.