4 Commits

Include renames

Author	SHA1	Message	Date
naps62-yolo	094cd1ffce	fix(maestro): drop SHARED_ prefix from [shared] env vars ... 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.	2026-05-26 13:24:29 +00:00
naps62-yolo	ed5743cd50	feat(maestro): wire maestro-registry to unified config (NAP-233) ... Registry now reads `[shared].token` and `[registry].bind_addr` from the unified file via maestro-config. First-run token generation does a read-modify-write so `[shared]` / `[cli]` / `[daemon]` sections that already exist on a co-located host stay intact. Env-var renames: - MAESTRO_TOKEN → MAESTRO_SHARED_TOKEN - MAESTRO_REGISTRY_CONFIG → MAESTRO_CONFIG `MAESTRO_REGISTRY_BIND_ADDR` is unchanged. The startup banner now points the operator at `MAESTRO_SHARED_TOKEN` when announcing a freshly generated token. e2e harness updated to use the new env var; auth.rs doc-comment updated to reflect the new env-var name.	2026-05-26 09:34:13 +00:00
naps62-yolo	90127e0ed3	feat(maestro): wire maestro-daemon to unified config (NAP-233) ... Daemon now loads `[shared].registry_url`, `[shared].token`, and the `[daemon]` section from the unified file via maestro-config. The registry-WS endpoint is derived from `[shared].registry_url` (scheme swap + `/daemon`), so operators configure a single base URL instead of duplicating the daemon-specific endpoint. Env-var renames (all per the new `MAESTRO_<SECTION>_<FIELD>` convention): - MAESTROD_REGISTRY_URL → MAESTRO_SHARED_REGISTRY_URL (and the value is now an http(s) base, not the ws daemon endpoint) - MAESTROD_DAEMON_URL → MAESTRO_DAEMON_URL - MAESTROD_DAEMON_ID → MAESTRO_DAEMON_ID - MAESTROD_BIND_ADDR → MAESTRO_DAEMON_BIND_ADDR - MAESTROD_CONFIG → MAESTRO_CONFIG - MAESTRO_TOKEN → MAESTRO_SHARED_TOKEN `maestrod configure` now writes the unified file with read-modify-write so any existing `[cli]` / `[registry]` sections on the same host are preserved. The interactive prompts reflect the new shape: registry URL is asked for as a base URL, and the token prompt names the new env var. Missing-file behaviour is hard cutover: if the config doesn't exist and not every required field comes from env, the daemon errors with a message pointing at `maestrod configure` and explicitly noting that the legacy paths (~/.config/maestrod/config.toml) are no longer read. e2e harness updated to match: `Daemon::spawn` takes the registry's HTTP base, and the spawned subprocess sees the renamed env vars.	2026-05-26 09:31:15 +00:00
naps62-yolo	91f252b4e2	feat(maestro): add maestro-e2e cross-process test harness (NAP-217) ... New `crates/maestro-e2e` exercises the full headless stack — registry, two daemons, real HTTP+WS — as actual subprocesses. Harness pieces: - `Registry::spawn` and `Daemon::spawn` launch the real built binaries with `env_clear()` plus an isolated `$HOME`, `XDG_CONFIG_HOME`, `XDG_STATE_HOME`, and (for daemons) `TMUX_TMPDIR`. Drop guards kill the child and clean the temp dirs. - `Daemon::stop` + `Daemon::restart` swap the process without losing the state dirs, so the recovery test exercises a real tmux re-adoption. - A `build::workspace_target_bin` helper re-invokes cargo from the test process to build `maestrod` / `maestro-registry` on demand (cargo only ships libs as path-dep of e2e by default). - `TestClient` wraps reqwest + tokio-tungstenite for the public HTTP+WS surface — list/spawn/kill/connect-info/attach + events WS. Scenarios covered (`tests/e2e.rs`): - list sessions from two daemons through one registry - multi-attach: two WS clients see the same PTY output - worktree with `cleanup_on_kill: true` is removed after kill - daemon restart: catalog drops then repopulates from `recover()` - concurrent spawns all get distinct ids All five pass in ~0.7s in parallel; cleanup confirmed (no leftover processes or temp dirs).	2026-05-26 07:38:19 +00:00