@olhapi/maestro-darwin-x64 0.1.3 → 0.1.5-rc.10
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +15 -3
- package/lib/maestro +0 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -6,6 +6,8 @@ Website: [maestro.olhapi.com](https://maestro.olhapi.com/)
|
|
|
6
6
|
Repository: [github.com/olhapi/maestro](https://github.com/olhapi/maestro)
|
|
7
7
|
Docs: [maestro.olhapi.com/docs](https://maestro.olhapi.com/docs)
|
|
8
8
|
|
|
9
|
+
This project is inspired by [openai/symphony](https://github.com/openai/symphony).
|
|
10
|
+
|
|
9
11
|
It combines a SQLite-backed tracker, an orchestrator that reads `WORKFLOW.md`, a private MCP daemon bridged by `maestro mcp`, and an HTTP server that serves the embedded dashboard plus JSON/WebSocket APIs.
|
|
10
12
|
|
|
11
13
|
Maestro stays local-first. External work is translated into Maestro projects and issues through the CLI, the embedded dashboard, or MCP prompts, then supervised through the same local queue, runtime state, MCP tools, and dashboard surfaces.
|
|
@@ -81,6 +83,9 @@ For local development or unsupported platforms:
|
|
|
81
83
|
go build -o maestro ./cmd/maestro
|
|
82
84
|
```
|
|
83
85
|
|
|
86
|
+
This build path is pure Go. You do not need a C compiler or a system SQLite
|
|
87
|
+
development package for the standard `make build` / `make test` flow.
|
|
88
|
+
|
|
84
89
|
Local contributor Docker build:
|
|
85
90
|
|
|
86
91
|
```bash
|
|
@@ -289,13 +294,17 @@ Fresh `maestro workflow init --defaults` output currently defaults to:
|
|
|
289
294
|
- `agent.mode: app_server`
|
|
290
295
|
- `agent.dispatch_mode: parallel`
|
|
291
296
|
- `codex.command: codex app-server`
|
|
292
|
-
- `codex.expected_version: 0.
|
|
297
|
+
- `codex.expected_version: 0.116.0`
|
|
293
298
|
- `codex.approval_policy: never`
|
|
294
299
|
- `codex.initial_collaboration_mode: default` for fresh `app_server` threads
|
|
300
|
+
- `phases.review.enabled: true`
|
|
301
|
+
- `phases.done.enabled: true`
|
|
295
302
|
- runtime permission profiles now live in the DB per project/issue instead of `WORKFLOW.md`
|
|
296
303
|
|
|
297
304
|
`initial_collaboration_mode: default` keeps unattended runs execution-first for a fresh `app_server` thread. Use `plan` only when you explicitly want a plan-gated startup mode. Interactive approvals and `requestUserInput` prompts still depend on using a non-`never` approval policy, and those prompts are queued through the dashboard's global interrupt panel. Resumed threads and `stdio` runs do not use that startup-mode path.
|
|
298
305
|
|
|
306
|
+
Interactive `maestro workflow init` now walks through `workspace.root`, `codex.command`, `agent.mode`, `agent.dispatch_mode`, `agent.max_concurrent_agents`, `agent.max_turns`, and `agent.max_automatic_retries`, then asks for `codex.approval_policy` and `codex.initial_collaboration_mode` only for `app_server`. Those extra tuning knobs remain interactive-only; `--defaults` stays the stable scripted path, and the existing flags still override only the workspace root, Codex command, and agent mode.
|
|
307
|
+
|
|
299
308
|
Supported prompt-template variables are:
|
|
300
309
|
|
|
301
310
|
- `{{ issue.identifier }}`
|
|
@@ -309,13 +318,13 @@ Supported prompt-template variables are:
|
|
|
309
318
|
- `{{ attempt }}`
|
|
310
319
|
|
|
311
320
|
When a project has a description, Maestro's default implementation, review, and done prompts include it automatically under a `Project context:` section. Custom workflows can place `{{ project.description }}` wherever they want.
|
|
312
|
-
The default done prompt now focuses on merge-back, PR readiness, and blocker reporting instead of asking for a preview artifact.
|
|
321
|
+
The default done prompt now focuses on merge-back, worktree cleanup, PR readiness, and blocker reporting instead of asking for a preview artifact.
|
|
313
322
|
|
|
314
323
|
The checked-in [`WORKFLOW.md`](WORKFLOW.md) is this repository's own workflow example. It is not guaranteed to match fresh `workflow init` defaults exactly.
|
|
315
324
|
|
|
316
325
|
Missing-file behavior differs by command:
|
|
317
326
|
|
|
318
|
-
- `maestro workflow init` creates `WORKFLOW.md` explicitly
|
|
327
|
+
- `maestro workflow init` creates `WORKFLOW.md` explicitly; `maestro init` is a root-level alias for the same command
|
|
319
328
|
- `maestro run` bootstraps a missing file automatically
|
|
320
329
|
- `maestro verify` checks readiness and returns remediation guidance
|
|
321
330
|
- `maestro doctor` runs the same readiness checks with different presentation
|
|
@@ -359,6 +368,9 @@ pnpm run website:dev
|
|
|
359
368
|
pnpm run website:check
|
|
360
369
|
```
|
|
361
370
|
|
|
371
|
+
The standard Go build/test path is now toolchain-light. The remaining
|
|
372
|
+
`sqlite3` CLI usage lives in a few optional shell scripts under `scripts/`.
|
|
373
|
+
|
|
362
374
|
Repo-managed Git hooks stay targeted:
|
|
363
375
|
|
|
364
376
|
- staged Go changes run package-scoped Go tests
|
package/lib/maestro
CHANGED
|
Binary file
|