fix(maestro): drop SHARED_ prefix from [shared] env vars #2

2026-05-26T14:24:49+01:00

naps62-yolo commented

2026-05-26 14:24:49 +01:00

Summary

NAP-233 renamed MAESTRO_TOKEN → MAESTRO_SHARED_TOKEN (and MAESTRO_REGISTRY_URL → MAESTRO_SHARED_REGISTRY_URL) to match the TOML section names. In practice this broke existing deployments — operators (including the one at maestro.n62.casa) have MAESTRO_TOKEN=… baked into their service env, and the new binary silently fell through to the file token instead.

Adjusts the convention: [shared] is the implicit global scope, so its fields use the bare MAESTRO_<FIELD> spelling. Only [daemon] and [registry] sections get section-prefixed env vars.

section	before (NAP-233)	after
`[shared].token`	`MAESTRO_SHARED_TOKEN`	`MAESTRO_TOKEN`
`[shared].registry_url`	`MAESTRO_SHARED_REGISTRY_URL`	`MAESTRO_REGISTRY_URL`
`[daemon].*`	`MAESTRO_DAEMON_*`	unchanged
`[registry].bind_addr`	`MAESTRO_REGISTRY_BIND_ADDR`	unchanged

Internal constants (ENV_SHARED_TOKEN → ENV_TOKEN, etc.) and EnvOverrides field names rename to match.

Test plan

cargo fmt --all -- --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace --lib (97 tests, all green)
CI runs e2e
Reinstall locally + restart maestrod, confirm it authenticates against the real registry at maestro.n62.casa

## Summary NAP-233 renamed `MAESTRO_TOKEN` → `MAESTRO_SHARED_TOKEN` (and `MAESTRO_REGISTRY_URL` → `MAESTRO_SHARED_REGISTRY_URL`) to match the TOML section names. In practice this broke existing deployments — operators (including the one at `maestro.n62.casa`) have `MAESTRO_TOKEN=…` baked into their service env, and the new binary silently fell through to the file token instead. Adjusts the convention: `[shared]` is the implicit global scope, so its fields use the bare `MAESTRO_<FIELD>` spelling. Only `[daemon]` and `[registry]` sections get section-prefixed env vars. | section | before (NAP-233) | after | |---|---|---| | `[shared].token` | `MAESTRO_SHARED_TOKEN` | `MAESTRO_TOKEN` | | `[shared].registry_url` | `MAESTRO_SHARED_REGISTRY_URL` | `MAESTRO_REGISTRY_URL` | | `[daemon].*` | `MAESTRO_DAEMON_*` | unchanged | | `[registry].bind_addr` | `MAESTRO_REGISTRY_BIND_ADDR` | unchanged | Internal constants (`ENV_SHARED_TOKEN` → `ENV_TOKEN`, etc.) and `EnvOverrides` field names rename to match. ## Test plan - [x] `cargo fmt --all -- --check` - [x] `cargo clippy --workspace --all-targets -- -D warnings` - [x] `cargo test --workspace --lib` (97 tests, all green) - [ ] CI runs e2e - [ ] Reinstall locally + restart `maestrod`, confirm it authenticates against the real registry at `maestro.n62.casa`

naps62-yolo added 1 commit 2026-05-26 14:24:49 +01:00

fix(maestro): drop SHARED_ prefix from [shared] env vars

ci / rust (pull_request) Successful in 4m13s

Details

094cd1ffce

The shared section is the implicit global scope, so its fields use
the bare `MAESTRO_<FIELD>` env-var spelling. Only `[daemon]` and
`[registry]` sections get section-prefixed env vars.

Renames:
- MAESTRO_SHARED_TOKEN        → MAESTRO_TOKEN
- MAESTRO_SHARED_REGISTRY_URL → MAESTRO_REGISTRY_URL

`MAESTRO_DAEMON_*` and `MAESTRO_REGISTRY_BIND_ADDR` are unchanged.

This restores the canonical spec name (`MAESTRO_TOKEN`) that operators
already use in their deployment scripts — NAP-233 had renamed it to
`MAESTRO_SHARED_TOKEN`, which silently broke daemon auth against
existing registry deployments still setting `MAESTRO_TOKEN` in env.

Constants renamed alongside: `ENV_SHARED_TOKEN` → `ENV_TOKEN`,
`ENV_SHARED_REGISTRY_URL` → `ENV_REGISTRY_URL`. `EnvOverrides` fields
shed their `shared_` prefix to match.

Touches: daemon/cli/registry crates, e2e harness, design spec.

naps62-yolo merged commit b27ba06391 into main

2026-05-26 14:29:40 +01:00

naps62-yolo deleted branch fix/shared-env-prefix

2026-05-26 14:29:40 +01:00

naps62-yolo referenced this pull request

2026-06-21 21:41:51 +01:00

multi-view: tabs #31

naps62-yolo referenced this pull request

2026-06-21 21:41:51 +01:00

multi-view: sidebar highlights + per-session colour #33

naps62-yolo referenced this pull request

2026-08-24 19:02:08 +01:00