Archived

This repository has been archived on 2026-10-08. You can view files and clone it. You cannot open issues or pull requests or push a commit.

Files

T

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

3.0 KiB

Raw Blame History

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-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-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 maestro scope. Example: feat(maestro): add Hello message round-trip test.
cargo fmt + cargo clippy --all-targets -- -D warnings before every commit. (Add to CI as part of NAP-211.)
Integration tests use real tmux and git. Don't mock them. Isolate via temp $HOME and TMUX_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.

3.0 KiB Raw Blame History