6 Commits

Include renames

Author	SHA1	Message	Date
naps62-yolo	ade0d49096	chore(maestro): retarget installer, e2e harness, and docs at unified maestro binary (NAP-245) ... - Installer: one `cargo install maestro` instead of two; ExecStart becomes `~/.cargo/bin/maestro daemon`; user unit renamed `maestrod.service` → `maestro.service`; configure step is `maestro daemon configure`. - E2E harness: both `Daemon` and `Registry` subprocess wrappers shell out to the unified `maestro` binary with the appropriate subcommand. - State dir: `~/.local/state/maestrod` → `~/.local/state/maestro`. - Docs: CLAUDE.md repo layout, design spec repo layout + "Daemon (`maestro daemon`)" heading, INSTALL.md (full rewrite of CLI references + new thin-builds section).	2026-05-27 10:43:51 +00:00
naps62-yoloandClaude Opus 4.7	53cc008e3b	test(maestro): e2e for broker T2 + allow_inbound enforcement (NAP-247) ... Two scenarios: * broker_t2_attach_through_home_daemon: alpha + beta share perimeter "wg-test"; beta lists alpha in allow_inbound. Test attaches to beta's session via alpha's /api/attach/:id and verifies the PTY echoes back. * broker_rejects_when_target_doesnt_allow_inbound: same setup but beta's allow_inbound is empty; the broker WS handshake succeeds at alpha (which has no reason to refuse) but beta drops the pair JWT, so the proxied stream closes without any PTY bytes flowing. Extends maestro-e2e::Daemon with DaemonOptions and a spawn_at variant that fixes the bind address, so the daemon's advertised private_addr matches the port the broker will dial. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-26 20:32:37 +00:00
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