naps62-yoloandClaude Opus 4.8
ff33b43d44
New shared `maestro-names` crate producing `adjective-instrument` session handles drawn from the orchestra pit — musical tempo/dynamics/articulation markings × instruments and forms (e.g. `allegro-cello`, `crescendo-oboe`, `staccato-viola`), tying handles to the app's conductor metaphor. - Pure generation takes an injected RNG; no thread_rng/clock in pure paths, so seeded tests are reproducible (repo invariant). - `generate_unique` prefers the bare name, appending an incrementing numeric suffix (`-2`, `-3`, …) only on collision via an injected `is_taken`. - `generate_thread` is the one impure convenience wrapper for runtime callers. - Wordlists are public so the web UI can mirror them for instant reroll; the Rust generator stays the source of truth. Closes #23. Part of #21 (spawn dialog rework). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
3.1 KiB
Maestro
A unified terminal-session orchestrator. One place — laptop, desktop, or phone — to see and attach to every interactive shell or agent (Claude Code, opencode, plain bash) running across every machine you care about. tmux for persistence, WebSocket for transport, daemon-per-host federated by a small always-on registry.
Where the spec lives
docs/superpowers/specs/2026-05-24-maestro-design.md is the source of truth for architecture, wire protocol, session model, auth, repo layout, and scope boundary. Read it before writing any code in this repo.
Where the work is
Linear project Maestro under team Naps62. Issues NAP-211..218 cover the prototype; each has blockedBy set so the dependency chain is explicit. NAP-211 is the only unblocked starting point.
.claude/linear.json wires /yolo and /work to this project — they pick from "available now" (status backlog/pending, not blocked).
Repo layout
Cargo workspace. NAP-245 unified the per-binary crates behind a single
crates/maestro/ umbrella that ships the maestro binary with feature gates
(cli / daemon / registry, default = all three). The library crates kept
their existing shape; only the per-binary main.rs files were retired.
crates/
├── maestro/ # umbrella binary `maestro` (cli + daemon + registry, feature-gated) (NAP-245)
├── maestro-protocol/ # shared wire types (NAP-211)
├── maestro-config/ # shared on-disk config schema (NAP-233)
├── maestro-names/ # orchestra-themed session-handle generator (#23)
├── maestro-cli/ # `maestro list/spawn/attach/kill/policy` dispatch (NAP-216)
├── maestro-daemon/ # `maestro daemon` — tmux wrapper + WS endpoints (NAP-212, NAP-214)
├── maestro-registry/ # `maestro registry` — phone book + HTTP API (NAP-213, NAP-215)
├── maestro-web/ # standalone `maestro-web` browser UI (NAP-241, NAP-249)
├── maestro-tui/ # `maestro tui` — ratatui session manager (NAP-275 epic)
├── maestro-installer/ # `maestro-install` wizard: cargo install + systemd (NAP-225)
└── maestro-e2e/ # cross-process integration tests (NAP-217)
web/ # browser SPA (NAP-218)
See docs/INSTALL.md for end-user install instructions.
Conventions
- TDD by default. Failing test first, then minimal impl. Commit test + impl together.
- Frequent commits. One logical unit per commit; don't pile work up.
- Conventional commits with
maestroscope. Example:feat(maestro): add Hello message round-trip test. cargo fmt+cargo clippy --all-targets -- -D warningsbefore every commit. (Add to CI as part of NAP-211.)- Integration tests use real
tmuxandgit. Don't mock them. Isolate via temp$HOMEandTMUX_TMPDIR.
Network assumption
Maestro is network-agnostic. The operator chooses bind addresses; the perimeter is whatever VPN (Wireguard, etc.) or private LAN they've set up. Maestro does not terminate TLS itself or police the network. See spec §Auth.
Status
Empty repo. Spec approved and committed. NAP-211 is the natural start.