@josstei/maestro 1.6.4-rc.1 → 1.6.4-rc.2

package/docs/architecture.md

@@ -80,7 +80,7 @@ Each runtime (`src/platforms/*/runtime-config.js`) declares:
 | `agentNaming` | `snake_case` | `kebab-case` | `kebab-case` | `snake_case` |
 | `delegation.pattern` | `{{agent}}(query: "...")` | `Agent(subagent_type: "maestro:{{agent}}", prompt: "...")` | `spawn_agent(...)` | `{{agent}}(query: "...")` |
 | `env.extensionPath` | `extensionPath` | `CLAUDE_PLUGIN_ROOT` | `.` (relative) | `extensionPath` |
-| `env.workspacePath` | `workspacePath` | `CLAUDE_PROJECT_DIR` | `MAESTRO_WORKSPACE_PATH` | `workspacePath` |
+| `env.workspacePath` | `null` (manifest injects `MAESTRO_WORKSPACE_PATH=${workspacePath}`) | `CLAUDE_PROJECT_DIR` | `MAESTRO_WORKSPACE_PATH` | `workspacePath` |
 
 ### Entry-Point Registry
 
@@ -97,7 +97,7 @@ Plus 3 core commands (orchestrate, execute, resume) maintained separately in `sr
 
 ## MCP Server Architecture
 
-The MCP server is authored directly in modular source under `src/mcp/`. Gemini and Claude runtime roots expose thin public wrappers at `mcp/maestro-server.js` that resolve into the nearest generator-owned `src/mcp/maestro-server.js` payload. Codex has no in-plugin wrapper — it spawns the server via `npx` against the versioned `@josstei/maestro` npm package and the `maestro-mcp-server` bin (`bin/maestro-mcp-server.js`) declared in `package.json`.
+The MCP server is authored directly in modular source under `src/mcp/`. Gemini and Qwen share the repo-root public wrapper at `mcp/maestro-server.js`; their manifests set `MAESTRO_RUNTIME` to select the runtime config. Claude exposes its own thin wrapper at `claude/mcp/maestro-server.js` so detached plugin installs can fall back to `claude/src/`. Codex has no in-plugin wrapper — it spawns the server via `npx` against the versioned `@josstei/maestro` npm package and the `maestro-mcp-server` bin (`bin/maestro-mcp-server.js`) declared in `package.json`.
 
 ### Module Structure
 
@@ -145,7 +145,7 @@ The content tools (`get_agent`, `get_skill_content`) are filesystem-only in ever
 - Codex: `primary=filesystem`, `fallback=none`
 - Qwen: `primary=filesystem`, `fallback=none`
 
-Gemini's and Claude's thin entrypoints at `mcp/maestro-server.js` use direct `require()` calls to resolve `src/mcp/maestro-server.js`. Gemini's entrypoint sets `MAESTRO_RUNTIME=gemini` and requires `../src/mcp/maestro-server` directly. Claude uses dual-resolution: it prefers the repo-level `src/mcp/maestro-server.js` via `fs.existsSync()` and falls back to the bundled detached payload (`claude/src/mcp/maestro-server.js`) when running outside the repo. Codex spawns `bin/maestro-mcp-server.js` via a release-versioned `npx -p @josstei/maestro@<version> maestro-mcp-server` invocation (declared in `plugins/maestro/.mcp.json`); the bin sets `MAESTRO_RUNTIME=codex` and `MAESTRO_EXTENSION_PATH`, then requires `../src/mcp/maestro-server`.
+Gemini and Qwen use the shared repo-root entrypoint at `mcp/maestro-server.js`, which requires `../src/mcp/maestro-server` directly. Their generated manifests set `MAESTRO_RUNTIME=gemini` or `MAESTRO_RUNTIME=qwen` before launch. Claude uses dual-resolution: it prefers the repo-level `src/mcp/maestro-server.js` via `fs.existsSync()` and falls back to the bundled detached payload (`claude/src/mcp/maestro-server.js`) when running outside the repo. Codex spawns `bin/maestro-mcp-server.js` via a release-versioned `npx -p @josstei/maestro@<version> maestro-mcp-server` invocation (declared in `plugins/maestro/.mcp.json`); the bin sets `MAESTRO_RUNTIME=codex` and `MAESTRO_EXTENSION_PATH`, then requires `../src/mcp/maestro-server`.
 
 This makes one architectural rule explicit:
 
@@ -156,9 +156,10 @@ This makes one architectural rule explicit:
 
 ### MCP Server Packaging
 
-Gemini and Claude keep a public entrypoint at `mcp/maestro-server.js`; Codex invokes the server via `npx` against a published bin. All three are thin wrappers around `src/mcp/maestro-server.js`:
+Gemini and Qwen share the repo-root public entrypoint at `mcp/maestro-server.js`, Claude keeps a runtime-local public entrypoint at `claude/mcp/maestro-server.js`, and Codex invokes the server via `npx` against a published bin. All are thin wrappers around `src/mcp/maestro-server.js`:
 
-- **Gemini** (`mcp/maestro-server.js`): sets `MAESTRO_RUNTIME=gemini`, directly requires `../src/mcp/maestro-server` and calls `.main()`
+- **Gemini** (`mcp/maestro-server.js`): launched with `MAESTRO_RUNTIME=gemini`, directly requires `../src/mcp/maestro-server` and calls `.main()`
+- **Qwen** (`mcp/maestro-server.js`): launched with `MAESTRO_RUNTIME=qwen` from `qwen-extension.json`, using the same shared entrypoint as Gemini
 - **Claude** (`claude/mcp/maestro-server.js`): sets `MAESTRO_RUNTIME=claude`, uses `fs.existsSync()` to prefer repo `../../src/mcp/maestro-server.js` with fallback to bundled `../src/mcp/maestro-server.js`
 - **Codex** (`bin/maestro-mcp-server.js` invoked via `npx -y -p @josstei/maestro@<version> maestro-mcp-server` per `plugins/maestro/.mcp.json`): sets `MAESTRO_RUNTIME=codex` and `MAESTRO_EXTENSION_PATH`, then requires `../src/mcp/maestro-server` and calls `.main()`
 
@@ -258,11 +259,23 @@ Uses matchers to filter by tool type. Timeout: 10s (5s for policy-enforcer). Con
 
 ### Policy Enforcement
 
-Both runtimes block the same destructive commands (`rm -rf`, `git reset --hard`, `git clean`, heredocs) and require confirmation for redirects (`>`, `>>`, `tee`):
+Gemini, Qwen, and Claude block the same destructive commands (`rm -rf`, `git reset --hard`, `git clean`, heredocs) and require confirmation for redirects (`>`, `>>`, `tee`):
 
 - **Gemini**: TOML policy rules in `policies/maestro.toml`
+- **Qwen**: TOML policy rules in `policies/maestro.toml`
 - **Claude**: JavaScript policy-enforcer hook triggered on Bash tool use
 
+### Qwen Hooks
+
+| Event | Script | Purpose |
+|-------|--------|---------|
+| `SessionStart` | session-start.js | Initialize hook state, prune stale sessions |
+| `SubagentStart` | before-agent.js | Detect agent, inject session context |
+| `SubagentStop` | after-agent.js | Validate handoff report format |
+| `SessionEnd` | session-end.js | Clean up hook state |
+
+Qwen uses its own hook registration file at `qwen/hooks.json`, while reusing the repo-root hook runner and logic modules.
+
 ### Hook State
 
 Ephemeral state stored in `/tmp/maestro-hooks-<uid>/`:
@@ -287,15 +300,15 @@ Ephemeral state stored in `/tmp/maestro-hooks-<uid>/`:
 
 ## CI and Testing
 
-For detailed documentation of all six GitHub Actions workflows, the release pipeline chain, and Mermaid flow diagrams, see [docs/cicd.md](cicd.md).
+For detailed documentation of all seven GitHub Actions workflows, the release pipeline chain, and Mermaid flow diagrams, see [docs/cicd.md](cicd.md).
 
 ### Test Suite
 
-54 test files with 851 tests using Node.js built-in `node:test`:
+86 test files using Node.js built-in `node:test`:
 
-- 30 unit tests (`tests/unit/`)
-- 13 transform tests (`tests/transforms/`)
-- 11 integration tests (`tests/integration/`)
+- 53 unit test files (`tests/unit/`)
+- 13 transform test files (`tests/transforms/`)
+- 20 integration test files (`tests/integration/`)
 
 The justfile's `just test` target uses glob expansion
 (`tests/unit/*.test.js`, `tests/transforms/*.test.js`, `tests/integration/*.test.js`),

package/docs/cicd.md

@@ -34,7 +34,7 @@ The six source-of-truth workflows share a common validation core: generate runti
 
 ### Purpose
 
-The foundational CI gate. Enforces that all generated runtime adapters (Gemini, Claude Code, Codex) are in sync with canonical source in `src/`, and that the full test suite passes. Runs on every push and pull request targeting `main`.
+The foundational CI gate. Enforces that all generated runtime adapters (Gemini CLI, Claude Code, Codex, and Qwen Code) are in sync with canonical source in `src/`, and that the full test suite passes. Runs on every push and pull request targeting `main`.
 
 ### Trigger
 
@@ -371,7 +371,7 @@ graph TD
 
 | Item | Type | Purpose |
 |------|------|---------|
-| `RELEASE_TOKEN` | Secret | Personal access token with write permissions; used for checkout, branch push, PR creation, and auto-merge. Required because the default `GITHUB_TOKEN` cannot trigger downstream workflows. |
+| `RELEASE_TOKEN` | Secret | Personal access token with write permissions; used for checkout, branch push, PR creation, and PR labeling. Required because the default `GITHUB_TOKEN` cannot trigger downstream workflows. |
 
 **Permissions**: `contents: write`, `pull-requests: write`
 

package/docs/flow.md

@@ -16,9 +16,10 @@ The orchestration workflow is defined by 41 steps (numbered 0 through 40) in `sr
                         ▼
 ┌─────────────────────────────────────────────────┐
 │               CLASSIFICATION                    │
-│  Turn 2: Load architecture reference            │
+│  Turn 2: Pre-load pre-execution skills          │
 │          Classify: simple / medium / complex     │
-│          Route: simple → Express, else → Design │
+│          Route: simple → Express, else          │
+│          finalize session_id + enter gate       │
 └───────────────────────┬─────────────────────────┘
                         ▼
 ┌─────────────────────────────────────────────────┐
@@ -26,7 +27,7 @@ The orchestration workflow is defined by 41 steps (numbered 0 through 40) in `sr
 │  Load design-dialogue skill                     │
 │  Structured conversation (depth: quick/std/deep)│
 │  Present sections one-at-a-time for approval    │
-│  Write design document to state_dir/plans/      │
+│  Exit Plan Mode, then record design approval    │
 └───────────────────────┬─────────────────────────┘
                         ▼
 ┌─────────────────────────────────────────────────┐
@@ -46,8 +47,10 @@ The orchestration workflow is defined by 41 steps (numbered 0 through 40) in `sr
 │  For each phase:                                │
 │    → get_agent for methodology                  │
 │    → Delegate with protocols + context chain    │
+│    → Resolve Blockers before phase transition   │
 │    → Parse Task Report + Downstream Context     │
 │    → transition_phase (HARD-GATE per phase)     │
+│    → reconcile empty payloads when required     │
 └───────────────────────┬─────────────────────────┘
                         ▼
 ┌─────────────────────────────────────────────────┐
@@ -150,9 +153,11 @@ Orchestrator                          Agent
     │                                   ├── ... (task work) ...
     │                                   ├── Run validation
     │                                   │
+    │◄── ## Blockers (if any) ─────────┤
     │◄── ## Task Report ───────────────┤
     │◄── ## Downstream Context ────────┤
     │                                   │
+    ├── Resolve blockers if present     │
     ├── Parse handoff                   │
     ├── transition_phase()              │
     └── Feed context to next phase      │
@@ -212,11 +217,17 @@ Non-negotiable checkpoints that block progression:
 | Gate | Location | Condition |
 |------|----------|-----------|
 | Tech recommendations | Step 11 | Must recommend vanilla HTML/CSS/JS for static delivery unless framework explicitly required |
+| Session ID | Step 9a | One finalized session ID must be reused for design approval, session creation, transitions, reconciliation, and archive |
+| Design gate | Steps 9a/14a/21 | Standard workflow cannot create a session until approved design is recorded for the same session ID |
 | Design sections | Step 12 | Each section presented individually and approved |
+| Design approval variant | Step 14a | Use content variant for Gemini; use path variant for Codex/Claude direct writes; never provide both |
 | validate_plan | Step 16 | Plan must pass validation before user sees it |
+| Implementation plan variant | Step 21 | Use content variant for Gemini Plan Mode outputs; use path variant for direct workspace writes; never provide both |
 | Execution mode | Step 19 | Must present only Parallel and Sequential options |
 | Agent dispatch | Step 23 | Must dispatch by agent's registered tool directly |
+| Blockers | Step 24 | Non-empty `## Blockers` must be answered and re-delegated before `transition_phase` |
 | transition_phase | Step 25 | Must be called individually for EVERY completed phase |
+| Reconciliation | Step 25 | Empty file manifests plus empty downstream context require `scan_phase_changes` → user confirmation → `reconcile_phase` |
 | Code review | Step 28 | Critical/Major findings block completion |
 | Express 1-phase | Step 31 | Express sessions must have exactly one phase |
 | Express questions | Step 32 | Each question must use user prompt tool |

package/docs/maestro-cheatsheet.md

@@ -142,6 +142,7 @@ Common paths:
 
 - Command entry point: `/maestro:*`
 - Same command surface as Gemini CLI
+- Uses `qwen/agents/` and `qwen/hooks.json`; commands, policies, MCP, and hook runner are shared from the repository root
 
 ## 7. Hook Reference
 
@@ -163,6 +164,13 @@ Common paths:
 
 - No runtime hooks
 
+### Qwen Code
+
+- `SessionStart`
+- `SubagentStart`
+- `SubagentStop`
+- `SessionEnd`
+
 ## 8. Common Notes
 
 ### Codex CLI

package/docs/overview.md

@@ -33,7 +33,7 @@ Simple tasks use an **Express workflow** (1 agent, 1 phase), while medium/comple
 | Entry-point commands | 9 (+ 3 core) |
 | Runtime targets | 4 |
 | Source transforms | 6 |
-| Test cases | see `just test` output (70+ files across unit, transforms, integration) |
+| Test files | 86 files across unit, transforms, and integration |
 
 ## Project Structure
 
@@ -57,7 +57,7 @@ maestro-orchestrate/
 │   └── manifest.js               # Declarative file mapping rules
 ├── scripts/
 │   └── generate.js               # Generator (manifest → output)
-├── tests/                        # 71 test files, 980 tests (see `just test` output)
+├── tests/                        # 86 test files across unit, transforms, and integration
 │
 ├── agents/                       # [generated] Gemini agent stubs
 ├── commands/maestro/             # [generated] Gemini TOML commands

package/docs/runtime-codex.md

@@ -183,15 +183,15 @@ plugins/maestro/
 
 The runtime server is invoked via `npx` rather than a local wrapper file, so the plugin ships no local `mcp/` directory under `plugins/maestro/`. The bin entrypoint lives in the repo root `bin/maestro-mcp-server.js`; `node scripts/generate.js` derives `plugins/maestro/.mcp.json` from `package.json` so the plugin manifest and MCP package spec stay on the same version.
 
-## Differences from Gemini and Claude
-
-| Aspect | Gemini | Claude | Codex |
-|--------|--------|--------|-------|
-| Agent names | snake_case | kebab-case | kebab-case |
-| Delegation | Direct function call | Agent subagent | spawn_agent |
-| Hooks | 4 events, no matchers | SessionStart, SessionEnd, PreToolUse + matchers | None |
-| Policies | TOML rules | JS hook enforcer | None |
-| Skill surface | N/A (commands) | 19 skills | plugin namespace `$maestro:*` |
-| Path style | Variable passthrough | Env var refs | `npx` bin |
-| Extra files | TOML policy rules | policy-enforcer | runtime guide |
-| Runtime payload | thin entrypoint only | thin entrypoint + detached `src/` payload | npx bin + detached `src/` payload |
+## Differences from Other Runtimes
+
+| Aspect | Gemini | Claude | Qwen | Codex |
+|--------|--------|--------|------|-------|
+| Agent names | snake_case | kebab-case | snake_case | kebab-case |
+| Delegation | Direct function call | Agent subagent | Direct function call | spawn_agent |
+| Hooks | 4 events, no matchers | SessionStart, SessionEnd, PreToolUse + matchers | 4 events in `qwen/hooks.json` | None |
+| Policies | TOML rules | JS hook enforcer | TOML rules | None |
+| Skill surface | N/A (commands) | 19 skills | N/A (Gemini-compatible commands) | plugin namespace `$maestro:*` |
+| Path style | Variable passthrough | Env var refs | Variable passthrough | `npx` bin |
+| Extra files | TOML policy rules | policy-enforcer | Qwen manifest, context, agents, hooks config | runtime guide |
+| Runtime payload | thin entrypoint only | thin entrypoint + detached `src/` payload | shared root entrypoint + `qwen/` stubs | npx bin + detached `src/` payload |

package/docs/runtime-gemini.md

@@ -15,11 +15,14 @@ The Gemini CLI extension lives at the repository root. It is the primary runtime
   "command": "node",
   "args": ["${extensionPath}/mcp/maestro-server.js"],
   "cwd": "${extensionPath}",
-  "env": { "MAESTRO_WORKSPACE_PATH": "${workspacePath}" }
+  "env": {
+    "MAESTRO_RUNTIME": "gemini",
+    "MAESTRO_WORKSPACE_PATH": "${workspacePath}"
+  }
 }
 ```
 
-The public server at `mcp/maestro-server.js` is a thin adapter. It sets `MAESTRO_RUNTIME=gemini`, requires canonical `src/mcp/maestro-server.js` directly, and runs the Gemini runtime against shared source in `src/`. Gemini declares `primary: filesystem` and `fallback: none`.
+The public server at `mcp/maestro-server.js` is a thin adapter. The manifest launches it with `MAESTRO_RUNTIME=gemini`; the adapter also defaults to Gemini if that env var is absent. It requires canonical `src/mcp/maestro-server.js` directly and runs the Gemini runtime against shared source in `src/`. Gemini declares `primary: filesystem` and `fallback: none`.
 
 ## Agent Naming
 

package/docs/runtime-qwen.md

@@ -15,11 +15,14 @@ The Qwen Code extension lives in `qwen/` (the output directory declared in `src/
   "command": "node",
   "args": ["${extensionPath}/mcp/maestro-server.js"],
   "cwd": "${extensionPath}",
-  "env": { "MAESTRO_WORKSPACE_PATH": "${workspacePath}" }
+  "env": {
+    "MAESTRO_RUNTIME": "qwen",
+    "MAESTRO_WORKSPACE_PATH": "${workspacePath}"
+  }
 }
 ```
 
-The public server at `mcp/maestro-server.js` is a thin adapter. It sets `MAESTRO_RUNTIME=qwen`, requires canonical `src/mcp/maestro-server.js` directly, and runs the Qwen runtime against shared source in `src/`. Qwen declares `primary: filesystem` and `fallback: none`.
+Qwen reuses the repo-root public server at `mcp/maestro-server.js`. The Qwen manifest launches that shared adapter with `MAESTRO_RUNTIME=qwen`; without that env var the adapter defaults to Gemini. The adapter requires canonical `src/mcp/maestro-server.js` directly and runs the Qwen runtime against shared source in `src/`. Qwen declares `primary: filesystem` and `fallback: none`.
 
 ## Agent Naming
 
@@ -42,16 +45,16 @@ The Qwen runtime does not emit its own TOML command files. `src/generator/entry-
 
 ## Hooks
 
-4 hook events (same lifecycle shape as Gemini):
+4 hook events in `qwen/hooks.json`:
 
 | Event | Script | Purpose |
 |-------|--------|---------|
 | `SessionStart` | `hooks/hook-runner.js qwen session-start` | Initialize hook state, prune stale sessions |
-| `BeforeAgent` | `hooks/hook-runner.js qwen before-agent` | Detect agent, inject session context |
-| `AfterAgent` | `hooks/hook-runner.js qwen after-agent` | Validate Task Report + Downstream Context |
+| `SubagentStart` | `hooks/hook-runner.js qwen before-agent` | Detect agent, inject session context |
+| `SubagentStop` | `hooks/hook-runner.js qwen after-agent` | Validate Task Report + Downstream Context |
 | `SessionEnd` | `hooks/hook-runner.js qwen session-end` | Clean up hook state |
 
-### AfterAgent Validation
+### SubagentStop Validation
 
 Qwen uses the same post-delegation validation as Gemini:
 

package/docs/usage.md

@@ -11,7 +11,7 @@ node scripts/generate.js
 # Generate runtime adapters using package scripts
 npm run build
 
-# Run all 980 tests across 71 files
+# Run all tests across unit, transform, and integration suites
 node --test tests/unit/*.test.js tests/transforms/*.test.js tests/integration/*.test.js
 
 # Show unified diff of changes
@@ -29,13 +29,13 @@ just test-transforms
 # Run only integration tests
 just test-integration
 
-# Generate + verify zero drift (CI equivalent)
+# Generate + verify zero drift in a clean worktree/CI checkout
 just check
 
-# Full CI equivalent (check + test)
+# Full CI equivalent in a clean worktree/CI checkout (check + check-layers + test)
 just ci
 
-# Verify lib/ import-boundary rules (enforced by check target)
+# Verify lib/ import-boundary rules
 just check-layers
 
 # Delete local branches whose remotes are gone
@@ -44,11 +44,12 @@ just cleanup-branches
 
 ## Editing Workflow
 
-1. Edit canonical source in `src/`. Maintain root docs (`README.md`, `EXAMPLES.md`, `USAGE.md`, `OVERVIEW.md`, `ARCHITECTURE.md`) directly, and do not edit generated `claude/`, `plugins/maestro/`, or `qwen/` output.
+1. Edit canonical source in `src/`. Maintain hand-authored root docs (`README.md`, `EXAMPLES.md`, `USAGE.md`, `OVERVIEW.md`, `ARCHITECTURE.md`, `CONTRIBUTING.md`, `SECURITY.md`) directly. Do not edit generated runtime stubs, command files, hook adapters, detached payloads, or generated skill copies directly.
 2. Run `node scripts/generate.js` or `npm run build` to regenerate runtime adapters
-3. Run `node --test tests/unit/*.test.js tests/transforms/*.test.js tests/integration/*.test.js` (or `just test`) before committing
-4. Commit canonical source, directly owned root docs, and generated adapter output together
-5. CI will fail if runtime adapters drift from canonical `src/`
+3. Run `node scripts/generate.js --diff` to confirm the generator has no additional pending output
+4. Run `node --test tests/unit/*.test.js tests/transforms/*.test.js tests/integration/*.test.js` (or `just test`) before committing
+5. Commit canonical source, directly owned root docs, and generated adapter output together
+6. CI will fail if runtime adapters drift from canonical `src/`; `just check` and `just ci` are designed for clean worktrees because they end with `git diff --exit-code`
 
 ## Configuration
 
@@ -72,6 +73,8 @@ All settings are resolved with precedence: environment variable > workspace `.en
 |----------|---------|---------|
 | `MAESTRO_EXTENSION_PATH` | Gemini | Override extension root path |
 | `MAESTRO_WORKSPACE_PATH` | Gemini | Workspace root (set by Gemini CLI) |
+| `MAESTRO_EXTENSION_PATH` | Qwen | Override extension root path |
+| `MAESTRO_WORKSPACE_PATH` | Qwen | Workspace root (set by Qwen Code) |
 | `MAESTRO_WORKSPACE_PATH` | Codex | Optional workspace root override; otherwise Codex uses MCP `roots/list` |
 | `CLAUDE_PLUGIN_ROOT` | Claude | Plugin root (set by Claude Code) |
 | `CLAUDE_PROJECT_DIR` | Claude | Project directory (set by Claude Code) |

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "maestro",
-  "version": "1.6.4-rc.1",
+  "version": "1.6.4-rc.2",
   "description": "Multi-agent development orchestration platform — 39 specialists, 4-phase orchestration, native parallel subagents, persistent sessions, and standalone review/debug/security/perf/seo/a11y/compliance commands",
   "contextFileName": "GEMINI.md",
   "settings": [
@@ -48,6 +48,7 @@
       ],
       "cwd": "${extensionPath}",
       "env": {
+        "MAESTRO_RUNTIME": "gemini",
         "MAESTRO_WORKSPACE_PATH": "${workspacePath}"
       }
     }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@josstei/maestro",
-  "version": "1.6.4-rc.1",
+  "version": "1.6.4-rc.2",
   "description": "Multi-agent development orchestration platform — 39 specialists, 4-phase workflows, 4 runtime targets (Gemini CLI, Claude Code, OpenAI Codex, Qwen Code)",
   "license": "Apache-2.0",
   "author": {

package/plugins/maestro/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "maestro",
-  "version": "1.6.4-rc.1",
+  "version": "1.6.4-rc.2",
   "description": "Generated Codex runtime for Maestro's multi-agent design, planning, execution, and review workflows.",
   "author": {
     "name": "josstei",

package/plugins/maestro/.mcp.json

@@ -5,7 +5,7 @@
       "args": [
         "-y",
         "-p",
-        "@josstei/maestro@1.6.4-rc.1",
+        "@josstei/maestro@1.6.4-rc.2",
         "maestro-mcp-server"
       ],
       "env": {

package/plugins/maestro/README.md

@@ -22,7 +22,7 @@ codex plugin marketplace add /absolute/path/to/maestro-orchestrate
 
 ## Architecture
 
-Codex shares the same canonical `src/` source tree as the Gemini CLI and Claude Code outputs:
+Codex shares the same canonical `src/` source tree as the Gemini CLI, Claude Code, and Qwen Code outputs:
 - shared methodology, references, templates, hooks, and MCP server logic are authored only in `src/`
 - this plugin contains public entry skills, manifests, thin adapters, and a generated `./src/` runtime payload derived from canonical `src/`
 - Codex-specific behavior is isolated to this plugin's runtime guide and public entry skills, exposed under the plugin namespace as `$maestro:<skill>`
@@ -54,4 +54,4 @@ Codex shares the same canonical `src/` source tree as the Gemini CLI and Claude
 
 ## Alignment goal
 
-Codex is treated as a third generated runtime, not a separate implementation. If behavior changes, update shared `src/` first and regenerate.
+Codex is treated as one of four generated runtimes, not a separate implementation. If behavior changes, update shared `src/` first and regenerate.

package/plugins/maestro/src/platforms/shared/agent-names.js

@@ -1,10 +1,15 @@
 module.exports = {
   agentNames: [
     'accessibility-specialist', 'analytics-engineer', 'api-designer', 'architect',
-    'code-reviewer', 'coder', 'compliance-reviewer', 'content-strategist',
-    'copywriter', 'data-engineer', 'debugger', 'design-system-engineer',
-    'devops-engineer', 'i18n-specialist', 'performance-engineer', 'product-manager',
-    'refactor', 'security-engineer', 'seo-specialist', 'technical-writer',
-    'tester', 'ux-designer',
+    'cloud-architect', 'cobol-engineer', 'code-reviewer', 'coder',
+    'compliance-reviewer', 'content-strategist', 'copywriter', 'data-engineer',
+    'database-administrator', 'db2-dba', 'debugger', 'design-system-engineer',
+    'devops-engineer', 'hlasm-assembler-specialist', 'i18n-specialist',
+    'ibm-i-specialist', 'integration-engineer', 'ml-engineer', 'mlops-engineer',
+    'mobile-engineer', 'observability-engineer', 'performance-engineer',
+    'platform-engineer', 'product-manager', 'prompt-engineer', 'refactor',
+    'release-manager', 'security-engineer', 'seo-specialist',
+    'site-reliability-engineer', 'solutions-architect', 'technical-writer',
+    'tester', 'ux-designer', 'zos-sysprog',
   ],
 };

package/plugins/maestro/src/skills/shared/delegation/SKILL.md

@@ -130,17 +130,26 @@ Explicitly state what the agent must NOT do:
 | Task Domain | Agent | Key Capability |
 |-------------|-------|---------------|
 | System architecture, component design | `architect` | Read-only analysis, architecture patterns |
+| Cloud architecture, multi-region topology | `cloud-architect` | Read-only cloud/IaC architecture |
+| Enterprise integration architecture | `solutions-architect` | Read-only cross-team architecture |
 | API contracts, endpoint design | `api-designer` | Read-only, REST/GraphQL expertise |
 | Feature implementation, coding | `coder` | Full read/write/shell access |
 | Code quality assessment | `code-reviewer` | Read-only, verified findings |
 | Database schema, queries, ETL | `data-engineer` | Full read/write/shell access |
+| RDBMS tuning, indexes, migration safety | `database-administrator` | Read + shell for database analysis |
+| DB2 operations and tuning | `db2-dba` | Read + shell for DB2-specific work |
 | Bug investigation, root cause | `debugger` | Read + shell for investigation |
 | CI/CD, infrastructure, deployment | `devops-engineer` | Full read/write/shell access |
+| Internal platforms, paved paths | `platform-engineer` | Full platform implementation access |
+| B2B APIs, ETL, message brokers | `integration-engineer` | Full integration implementation access |
+| SLOs, runbooks, reliability | `site-reliability-engineer` | Read + shell reliability analysis |
+| Metrics, logs, traces, dashboards | `observability-engineer` | Full observability implementation access |
 | Performance analysis, profiling | `performance-engineer` | Read + shell for profiling |
 | Code restructuring, modernization | `refactor` | Read/write/shell, skill activation |
 | Security assessment, vulnerability | `security-engineer` | Read + shell for scanning |
 | Test creation, TDD, coverage | `tester` | Full read/write/shell access |
 | Documentation, READMEs, guides | `technical-writer` | Read/write, no shell |
+| Release notes, changelogs, rollout | `release-manager` | Read/write for release artifacts |
 | Technical SEO auditing | `seo-specialist` | Read + shell + web search/fetch |
 | Marketing copy, content writing | `copywriter` | Read/write |
 | Content planning, strategy | `content-strategist` | Read + web search/fetch |
@@ -151,6 +160,14 @@ Explicitly state what the agent must NOT do:
 | Internationalization | `i18n-specialist` | Full read/write/shell access |
 | Design tokens, theming | `design-system-engineer` | Full read/write/shell access |
 | Legal, regulatory compliance | `compliance-reviewer` | Read + web search/fetch |
+| Mobile platform work | `mobile-engineer` | Full mobile implementation access |
+| Model training and inference integration | `ml-engineer` | Full ML implementation access |
+| Model operations and model CI/CD | `mlops-engineer` | Full MLOps implementation access |
+| Prompt design, few-shot, RAG tuning | `prompt-engineer` | Read/write prompt and eval design |
+| Mainframe COBOL, JCL, CICS/IMS | `cobol-engineer` | Full mainframe implementation access |
+| IBM HLASM for z/OS | `hlasm-assembler-specialist` | Full assembly implementation access |
+| IBM i RPG/CL, DB2 for i | `ibm-i-specialist` | Full IBM i implementation access |
+| z/OS systems programming, JCL, RACF | `zos-sysprog` | Read + shell for z/OS system work |
 
 ## Agent Tool Dispatch Contract
 
@@ -269,7 +286,7 @@ Before each agent dispatch, a hook tracks which agent is currently executing:
 - Preferred signal: the required `Agent: <agent_name>` header in the delegation prompt
 - Legacy fallbacks: `MAESTRO_CURRENT_AGENT` from the environment, then regex-based detection of patterns like `delegate to <agent>` or `@<agent>`
 
-The detected agent name is persisted to `/tmp/maestro-hooks/<session-id>/active-agent` and cleared by the post-delegation hook on every allowed response (both successful validation and retry allow-through). On deny (malformed output), the active agent is preserved to enable re-validation on retry.
+The detected agent name is persisted to `${MAESTRO_HOOKS_DIR:-<os.tmpdir()>/maestro-hooks-<uid>}/<session-id>/active-agent` and cleared by the post-delegation hook on every allowed response (both successful validation and retry allow-through). On deny (malformed output), the active agent is preserved to enable re-validation on retry.
 
 ### Session Context Injection
 

package/plugins/maestro/src/skills/shared/design-dialogue/SKILL.md

@@ -257,7 +257,7 @@ Apply depth-gated reasoning enrichment to design section content during the conv
 
 The write path depends on whether your runtime provides a Plan Mode surface (check `get_runtime_context`, loaded at session start, step 0):
 
-- **Plan Mode active**: Some runtimes restrict writes to a temporary staging directory during Plan Mode. Write the design document there. After `exit_plan_mode` approval in Phase 2, copy it to the permanent location.
+- **Plan Mode active**: Some runtimes restrict writes to a temporary staging directory during Plan Mode. Write the design document there first, then exit Plan Mode and complete the design approval handoff. When the runtime's Plan Mode path is not visible to the MCP server, use the `record_design_approval` content variant so the server materializes the canonical copy under `<state_dir>/plans/`.
 - **Plan Mode not active or not available**: Write directly to the permanent location. If your runtime does not provide Plan Mode, track design progress using the plan-update mechanism from runtime context and use the user-prompt tool from runtime context for section approvals and final signoff.
 
 Permanent location: `<state_dir>/plans/YYYY-MM-DD-<topic-slug>-design.md` (where `<state_dir>` resolves from `MAESTRO_STATE_DIR`, default `docs/maestro`).

package/plugins/maestro/src/skills/shared/execution/SKILL.md

@@ -121,7 +121,7 @@ Hooks fire automatically at agent boundaries. The orchestrator does not invoke t
 
 The hooks system tracks which agent is currently executing. Before each agent dispatch, a hook resolves the active agent identity from the required `Agent:` header first, then falls back to legacy env/regex detection, and injects compact session context. After completion, a hook validates that the response contains both `Task Report` and `Downstream Context`; it requests one retry on the first malformed response.
 
-The hook state directory under `/tmp/maestro-hooks/<session-id>/` is transient and separate from orchestration state.
+The hook state directory under `${MAESTRO_HOOKS_DIR:-<os.tmpdir()>/maestro-hooks-<uid>}/<session-id>/` is transient and separate from orchestration state.
 
 ## Sequential Execution Protocol