maestro-flow 0.4.26 → 0.5.0

package/.codex/skills/maestro-roadmap/SKILL.md

@@ -35,7 +35,7 @@ $ARGUMENTS -- requirement/idea text or @file reference, plus optional flags.
 Interview the user relentlessly until shared understanding is reached. Active only in interactive mode; skip when `-y/--yes`, `--revise`, `--review`, `-c`, or input is already specific (clear requirement + mode).
 
 - One decision per turn via request_user_input with 2–4 options + a (Recommended) default. The user controls termination — keep interviewing until convergence; they can interrupt naturally at any time.
-- Search-first when uncertain: before asking, resolve via `state.json`, existing `roadmap.md`, `project.md`, `maestro spec load`, `maestro wiki search`, Glob/Grep/Read, or — for open-ended multi-file scans — `maestro delegate ... --role explore`. Never ask what code or memory can verify; never bounce your own ambiguity back to the user — search first, then ask only what truly needs human judgment.
+- Search-first when uncertain: before asking, resolve via `state.json`, existing `roadmap.md`, `project.md`, `maestro spec load`, `maestro search`, Glob/Grep/Read, or — for open-ended multi-file scans — `maestro delegate ... --role explore`. Never ask what code or memory can verify; never bounce your own ambiguity back to the user — search first, then ask only what truly needs human judgment.
 - Writeback cadence: each settled decision is immediately appended/updated in the `Roadmap Decisions` section at the top of `.workflow/roadmap.md` (create the section if absent). Do NOT batch writeback to the end — partial decisions must already be on disk before the next question.
 - Walk the decision dependency tree strictly: mode → requirement scope → decomposition strategy → phase dependencies/order. Do not open the next branch until the current one is settled.
 - Scope guard: only decide the shape of the roadmap. Do not pre-resolve intra-phase task breakdown — that belongs to `plan`.
@@ -70,7 +70,10 @@ Wave 1: 3 analysis rows (parallel). Wave 2: 1 assembly row.
 2. **CSV is source of truth**: Master tasks.csv holds all state
 3. **Context propagation**: prev_context from master CSV, not memory
 4. **Discovery board append-only**: Never modify/delete discoveries.ndjson
-5. **Graceful degradation**: Wave 1 fails -> Wave 2 proceeds with seed input only
+5. **Graceful degradation**: Wave 1 fails -> Wave 2 proceeds with seed input only. When degradation activates, flag downstream outputs as LOW CONFIDENCE.
+6. **Invariant violation = BLOCK** — violating any invariant above blocks the current operation.
+7. **Requirement mapping completeness** — every Active requirement from project.md MUST be mapped to exactly one phase. No circular dependencies in phase ordering.
+8. **Artifact verification before completion** — .workflow/roadmap.md MUST exist with Milestone > Phase hierarchy and progress table. Artifact MUST be registered in state.json. If missing: DO NOT report completion.
 </invariants>
 
 <state_machine>

package/.codex/skills/maestro-tools-register/SKILL.md

@@ -72,7 +72,7 @@ Parse $ARGUMENTS to determine mode:
 - Analyze improvement points (step splitting, prerequisites, error handling)
 
 **Promote mode** (existing knowhow → tool):
-- Locate document: `maestro wiki list --keyword <name>` or by path in `.workflow/knowhow/`
+- Locate document: `maestro search "<name>" --type knowhow` or by path in `.workflow/knowhow/`
 - Read document, verify it contains actionable steps (numbered list or ## Steps section)
 - If no actionable steps, suggest extract mode instead
 - Determine category (Step 3) and summary ("Use when ...")

package/.codex/skills/maestro-ui-codify/SKILL.md

@@ -115,6 +115,9 @@ id,wave,title,description,agent_type,deps
 6. **Idempotent Package**: --overwrite required to replace existing package directory
 7. **Cleanup Temp Files**: Remove wave-{N}.csv after results merged, remove temp workspace after Wave 4
 8. **DO NOT STOP**: Continuous execution until all waves complete
+
+### Artifact Verification
+Before reporting completion, verify: design-tokens.json, layout-templates.json, preview.html, preview.css, knowhow-manifest.json all exist. If any missing: DO NOT report completion.
 </invariants>
 
 <execution>
@@ -392,7 +395,7 @@ Open preview:
   file://{absolute_path}/preview.html
 
 Next steps:
-  maestro wiki list --category coding    # Browse by role
+  maestro search --category coding    # Browse by role
   maestro spec load --keyword {package_name}    # Load related specs
 ```
 

package/.codex/skills/maestro-update/SKILL.md

@@ -1,169 +1,74 @@
 ---
 name: maestro-update
 description: Detect version, preview changes, apply workflow upgrades
-argument-hint: "[--dry-run] [--force]"
+argument-hint: "[--dry-run] [--force] [--setup-only]"
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, request_user_input
 ---
 <purpose>
-Detect the current `.workflow/` schema version, show available migrations, and interactively apply them step-by-step. Uses a migration registry that supports incremental version upgrades (e.g., 1.0 → 2.0 → 3.0).
+Version router — detect current version, run schema migration to latest, then follow the version-specific smart upgrade workflow.
 
-Each migration step is previewed before execution. The user confirms each step in a loop.
+Migration scripts live in two layers:
+- **Schema** (`src/migrations/`): code-level state.json transforms, auto-chained by registry
+- **Workflow** (`~/.maestro/workflows/updates/`): version-specific upgrade guides with environment setup
+
+Schema migrations handle the mechanical version bump. Workflow docs handle the smart part — what the user needs to know, configure, or verify for that version. The router runs schema first, then loads the matching workflow doc.
 </purpose>
 
+<required_reading>
+@~/.maestro/workflows/updates/README.md
+</required_reading>
+
 <context>
 $ARGUMENTS — optional flags.
 
 **Flags:**
 - `--dry-run` -- Preview migration plan without executing
-- `--force` -- Skip confirmation prompts (apply all pending migrations)
-
-**Migration registry:** `src/migrations/`
-- Each migration is a standalone file (e.g., `v1-to-v2.ts`) exporting a `MigrationDef`
-- All migrations are registered via `src/migrations/index.ts`
-- Registry auto-chains: detects current version → walks chain → applies in order
-- To add a new migration: create `src/migrations/v{N}-to-v{N+1}.ts`, register in `index.ts`
-
-**CLI runner:** `src/migrations/run.ts`
-- Executable entrypoint: `npx tsx src/migrations/run.ts [root] [--dry-run] [--force] [--json]`
-- Outputs JSON (with `--json`) or human-readable text
+- `--force` -- Skip confirmation prompts
+- `--setup-only` -- Skip schema migration, run only the setup for current version
 
-**State version source:** `.workflow/state.json` → `version` field
+**Version source:** `.workflow/state.json` → `version` field
 </context>
 
 <execution>
 
-### Step 1: Detect Current State
+### Step 1: Detect Version
 
 ```
-1. Read .workflow/state.json
-2. Extract version field (default "1.0" if missing)
-3. Display:
-
-   === Maestro Workflow Update ===
-   Project:  {project_name}
-   Version:  {version}
-   Location: {.workflow/ path}
+1. Read .workflow/state.json → extract version (default "1.0" if missing)
+2. Display current version
 ```
 
-### Step 2: Dry-Run Preview
+IF `--setup-only`:
+  → Load `~/.maestro/workflows/updates/update-v{version}-setup.md`
+  → IF exists: follow completely, then EXIT
+  → IF not exists: display "No setup script for v{version}" → EXIT
 
-Run the migration CLI in dry-run + JSON mode to get the full plan:
+### Step 2: Check for Updates
 
-```bash
-npx tsx src/migrations/run.ts "$(pwd)" --dry-run --json
 ```
-
-Parse the JSON output. If status is `up-to-date`:
-```
-Already up to date (v{version})
+1. Run: npx tsx src/migrations/run.ts "$(pwd)" --dry-run --json
+2. IF up-to-date → offer setup if available → EXIT
+3. Display target version
 ```
-→ EXIT
 
-Otherwise display the migration plan:
-```
-Pending Migrations ({N} step(s)):
+IF `--dry-run` → EXIT.
 
-  1. [v{from} → v{to}] {name}
-     {description}
+### Step 3: Execute
 
-  2. [v{from} → v{to}] {name}
-     {description}
 ```
-
-If `--dry-run` flag was passed by user → display plan and EXIT.
-
-### Step 3: Interactive Confirmation Loop
-
-For each migration step (unless `--force`):
-
+1. Confirm (unless --force)
+2. Backup state.json
+3. Run schema migration (auto-chains all intermediate steps)
+4. Load update-v{target}-setup.md → follow completely
 ```
-LOOP for step_index = 1 to N:
-
-  Display:
-    --- Step {step_index}/{N}: {name} ---
-    Version: v{from} → v{to}
-
-    Changes:
-      {description, indented}
 
-  IF NOT --force:
-    AskUserQuestion: "Apply this migration?"
-    Options: [yes / skip / abort]
+### Step 4: Summary
 
-    - "yes"   → proceed to Step 4 (execute)
-    - "skip"  → WARN "Skipping may break the migration chain"
-                 continue to next step
-    - "abort" → display summary of what was applied so far → EXIT
-
-  IF --force:
-    → proceed to Step 4 (execute)
-```
-
-### Step 4: Execute Single Migration
-
-```
-1. Create backup:
-   Bash: cp .workflow/state.json .workflow/state.json.backup-v{from}-{timestamp}
-
-2. Run migration:
-   Bash: npx tsx src/migrations/run.ts "$(pwd)" --json
-   
-   NOTE: The runner executes ALL pending migrations. For step-by-step control,
-   read state.json, call the migration function directly, or use the runner
-   which stops on first failure.
-
-3. Parse result JSON and display:
-
-   {status_icon} Step {N} completed: {name}
-   Summary: {summary}
-   Changes:
-     - {change_1}
-     - {change_2}
-     - ...
-
-4. If failed:
-   Display: "Migration failed: {summary}"
-   Display: "Backup available at: {backup_path}"
-   Display: "Restore with: cp {backup_path} .workflow/state.json"
-   → EXIT
-
-5. Continue loop to next step
-```
-
-### Step 5: Summary
-
-After all steps completed (or user aborted):
-
-```
-=== Migration Complete ===
-Applied: {applied_count} / {total_count} migration(s)
-Skipped: {skipped_count}
-Version: v{original} → v{final}
-Backup:  .workflow/state.json.backup-v{original}-{timestamp}
-
-Next steps:
-  /manage-status  -- Verify project state
-  /maestro        -- Continue workflow
-```
+Display version change, backup path, next steps.
 
 </execution>
 
-<error_codes>
-| Code | Severity | Condition | Recovery |
-|------|----------|-----------|----------|
-| E001 | error | .workflow/state.json not found | Run /maestro-init first |
-| E002 | error | state.json parse error | Check file for corruption |
-| E003 | error | Migration function failed | Restore from backup |
-| W001 | warning | Skipped migration may break version chain | Re-run /maestro-update later |
-| W002 | warning | tsx not available | Install tsx: npm i -D tsx |
-</error_codes>
-
 <success_criteria>
-- [ ] Current version detected from state.json
-- [ ] Dry-run preview shows full migration plan without execution
-- [ ] Each step confirmed interactively (unless --force)
-- [ ] Backup created before each migration
-- [ ] Migration executed and result displayed with change list
-- [ ] Abort stops cleanly with partial summary
-- [ ] Summary shows applied/skipped counts and version change
+- [ ] Version detected, schema migration run, setup doc followed
+- [ ] --setup-only, --dry-run, --force flags handled
 </success_criteria>

package/.codex/skills/manage-codebase-rebuild/SKILL.md

@@ -155,7 +155,7 @@ Single wave generates `wave-1.csv`. No `prev_context` needed (all tasks independ
 | `feature-maps/{slug}.md` | Per-feature documentation |
 | `knowledge-graph.json` | Knowledge Graph: nodes, edges, layers, tour (generated by `maestro kg index`) |
 
-**Wiki Integration**: After rebuild, KG nodes are automatically indexed as virtual wiki entries (type: knowhow, virtualKind: kg-node/kg-layer/kg-tour-step) on next `maestro wiki` access. Verify with `maestro wiki list --keyword kg`. Use `maestro kg diff-wiki` for future change impact analysis.
+**Wiki Integration**: After rebuild, KG nodes are automatically indexed as virtual wiki entries (type: knowhow, virtualKind: kg-node/kg-layer/kg-tour-step) on next `maestro wiki` access. Verify with `maestro search "kg" --type knowhow`. Use `maestro kg diff-wiki` for future change impact analysis.
 
 ### Session Structure
 
@@ -354,7 +354,7 @@ Next steps:
   Skill({ skill: "manage-status" })
   Skill({ skill: "manage-codebase-refresh" })
   maestro kg stats           # verify KG
-  maestro wiki list --keyword kg  # verify wiki integration
+  maestro search "kg" --type knowhow  # verify wiki integration
   maestro kg diff-wiki       # future change impact
 ```
 

package/.codex/skills/manage-harvest/SKILL.md

@@ -56,7 +56,7 @@ Follow '~/.maestro/workflows/harvest.md' Stages 1–8 (standard mode) or Stage 9
 3. **Stable fragment IDs** — `HRV-{8 hex}` from `hash(source_id + content_hash)`
 4. **Never modify source artifacts** — purely extractive
 5. **Confidence filtering** — below threshold logged but not routed
-6. **Spec format enforcement** — all spec routing must use `<spec-entry>` closed-tag format with `roles`, `keywords`, `date`, `source="harvest"` attributes
+6. **Spec format enforcement** — all spec routing must use `<spec-entry>` closed-tag format with `title`, `description`, `keywords`, `date`, `source="harvest"` attributes
 
 **Routing rules:**
 - Universal design patterns → `coding` or `arch` category
@@ -66,7 +66,7 @@ Follow '~/.maestro/workflows/harvest.md' Stages 1–8 (standard mode) or Stage 9
 - Spec: `maestro wiki append spec-<file> --body "<content>" --keywords "<kws>"` (unified write path) or `Skill({ skill: "spec-add", args: "<category> <content>" })`
 - Issue: append to `issues.jsonl` matching canonical schema, with `source: "harvest"` field (distinguishes from `manage-issue-discover`, which uses `source: "discover"` — required for cross-skill dedup when both write concurrently)
 
-**Next steps:** `/manage-wiki health`, `maestro wiki list --type note`, `/wiki-connect --fix`, `/wiki-digest`, `/manage-issue list --source harvest`
+**Next steps:** `/manage-wiki health`, `maestro search --type note`, `/wiki-connect --fix`, `/wiki-digest`, `/manage-issue list --source harvest`
 
 **Prune mode** (`--prune`): Classifies artifacts (active/graduated/stale/protected), graduates harvested artifacts to wiki knowhow, archives from `artifacts[]` → `artifact_archive[]`, prunes resolved entries from accumulated_context. Files on disk are never deleted. Always backs up state.json before writing.
 </execution>

package/.codex/skills/manage-knowhow/SKILL.md

@@ -49,7 +49,7 @@ Default to `list` if no arguments. Parse first token as subcommand.
 ### Step 3: Execute Subcommand
 
 **list**: Show entries from both stores (or filtered by `--store`, `--tag`, `--type`).
-- Workflow: use `maestro wiki list --type knowhow --json` or read `.workflow/wiki-index.json`, display ID, type, category, date, tags, title
+- Workflow: use `maestro search --type knowhow --json` or read `.workflow/wiki-index.json`, display ID, type, category, date, tags, title
 - System: list `.md` files in system memory directory
 
 **search `<query>`**: Full-text grep across both stores. Rank by match count.

package/.codex/skills/manage-status/SKILL.md

@@ -53,8 +53,7 @@ Use this decision table to suggest the next action:
 |---------------|------------|
 | No phases planned | `Skill({ skill: "maestro-brainstorm" })` or `Skill({ skill: "maestro-plan" })` |
 | Phase planned, not executed | `Skill({ skill: "maestro-execute", args: "<N>" })` |
-| Phase executed, not verified | `Skill({ skill: "maestro-verify", args: "<N>" })` |
-| Phase verified with gaps | `Skill({ skill: "maestro-plan", args: "<N> --gaps" })` |
+| Phase executed, not reviewed | `Skill({ skill: "quality-review", args: "<N>" })` |
 | Phase reviewed PASS/WARN | `Skill({ skill: "quality-test", args: "<N>" })` |
 | UAT passed | `Skill({ skill: "maestro-milestone-audit" })` |
 | All milestone phases done | `Skill({ skill: "maestro-milestone-audit" })` |

package/.codex/skills/quality-auto-test/SKILL.md

@@ -270,7 +270,7 @@ You MUST call report_agent_job_result EXACTLY ONCE before exiting.
 3. Conditional: traceability.md (spec route), issue creation (code_defect -> issues.jsonl)
 4. Register artifact in state.json (type: test)
 5. Display summary: route, iterations, convergence status, per-layer pass rates, bugs discovered
-6. Route: converged -> maestro-verify; bugs -> quality-debug; >80% -> quality-test; <80% -> quality-debug; single pass all pass -> quality-test
+6. Route: converged -> quality-review; bugs -> quality-debug; >80% -> quality-test; <80% -> quality-debug; single pass all pass -> quality-test
 
 </actions>
 
@@ -314,6 +314,6 @@ Protocol: read before writing tests, append-only, dedup by type+key.
 - [ ] TST artifact registered in state.json
 - [ ] If spec: traceability.md written; if failures: issues auto-created in issues.jsonl
 - [ ] If gap source: validation.json gaps updated (MISSING→COVERED)
-- [ ] Next step routed (converged → verify, bugs → debug, >80% → quality-test, <80% → debug)
+- [ ] Next step routed (converged → quality-review, bugs → debug, >80% → quality-test, <80% → debug)
 </success_criteria>
 </output>

package/.codex/skills/quality-debug/SKILL.md

@@ -207,7 +207,7 @@ mkdir -p {sessionFolder}
 
 2b. **Load codebase + wiki context** (optional, informs hypothesis generation):
    - If `.workflow/codebase/ARCHITECTURE.md` exists: read module boundaries to scope impact analysis
-   - Run `maestro wiki search "<symptom keywords>" --json 2>/dev/null`; if results: check for prior investigations on similar issues
+   - Run `maestro search "<symptom keywords>" --json 2>/dev/null`; if results: check for prior investigations on similar issues
    - Run `maestro spec load --category debug --keyword "<symptom keywords>"`; if tools found: extract known issues, workarounds, and root-cause notes to inform hypotheses
    - All are optional — proceed without if unavailable
 
@@ -415,7 +415,7 @@ CONSTRAINTS:
 | Result | Suggestion |
 |--------|------------|
 | All fixes verified | Run tests: `Skill({ skill: "quality-test", args: "{phase}" })` |
-| Fixes applied, not verified | Re-verify: `Skill({ skill: "maestro-verify", args: "{phase}" })` |
+| Fixes applied, not verified | Re-execute: `Skill({ skill: "maestro-execute", args: "{phase}" })` |
 | Confirmed but no fix | Plan fixes: `Skill({ skill: "maestro-plan", args: "{phase} --gaps" })` |
 | All inconclusive | Resume with more context or manual investigation |
 | From UAT, all diagnosed | `Skill({ skill: "quality-test", args: "{phase} --auto-fix" })` |

package/.codex/skills/quality-refactor/SKILL.md

@@ -123,7 +123,7 @@ Create `.workflow/scratch/refactor-{slug}-{date}/` with `.task/` and `.summaries
 
 ### Step 3: Scope Analysis
 
-Load project specs if available (`maestro spec load --category coding` for conventions, `maestro spec load --category review` for quality standards). Browse wiki: `maestro wiki list --category coding`, load relevant entries.
+Load project specs if available (`maestro spec load --category coding` for conventions, `maestro spec load --category review` for quality standards). Browse wiki: `maestro search --category coding`, load relevant entries.
 
 Analyze scope for tech debt categories:
 

package/.codex/skills/quality-retrospective/SKILL.md

@@ -241,7 +241,7 @@ If `--no-route`: skip this stage.
 For each insight in `synthResult.insights`, route based on `routing` field:
 
 **Spec routing** (`routing: "spec"`):
-Map category (pattern/convention → `coding`, architecture → `arch`, quality → `quality`). Append `<spec-entry>` with category, auto-extracted keywords, date, source="retrospective", title, summary, evidence, phase/lens/INS-id.
+Map category (pattern/convention → `coding`, architecture → `arch`, quality → `quality`). Append `<spec-entry>` with category, auto-extracted keywords, date, title, description, source="retrospective", evidence, phase/lens/INS-id.
 
 **Issue routing** (`routing: "issue"`, severity critical/high):
 Append to `.workflow/issues/issues.jsonl` with `ISS-<date>-<seq>` id, source="retrospective", phase/INS-id context, and history entry.

package/.codex/skills/quality-test/SKILL.md

@@ -247,15 +247,14 @@ CONSTRAINTS:
 
 Max 2 iterations:
 1. `maestro-plan "{phase} --gaps"` (registered -> planning)
-2. `maestro-execute "{phase}"` (planning -> executing)
-3. `maestro-verify "{phase}"` (resolved -> completed, unresolved -> failed)
+2. `maestro-execute "{phase}"` (planning -> executing, resolved -> completed, unresolved -> failed)
 
 ### A_REPORT
 
 1. UAT confidence scoring (4 dims: scenario_coverage, diagnostic_depth, observation_quality, closure_completeness). Readiness gate: block if scenario_coverage < 40% or blocker without diagnosis.
 2. Display summary: smoke results, pass/fail/skip counts, diagnosis stats, auto-fix results
 3. Register artifact in state.json (type: test)
-4. Route: all passed -> milestone-audit; auto-fix succeeded -> maestro-verify; gaps remain -> quality-debug; low coverage -> quality-auto-test
+4. Route: all passed -> milestone-audit; auto-fix succeeded -> maestro-execute; gaps remain -> quality-debug; low coverage -> quality-auto-test
 
 </actions>
 
@@ -265,7 +264,7 @@ Max 2 iterations:
 | Condition | Recovery |
 |-----------|----------|
 | Phase/task target required, no active sessions | Prompt for phase number |
-| No verification.json (phase not verified) | Suggest maestro-verify |
+| No verification.json (phase not verified) | Suggest maestro-execute |
 | Smoke test failed (app won't start) | Suggest quality-debug |
 | Coverage below threshold | Suggest quality-auto-test |
 </error_codes>

package/.codex/skills/spec-add/SKILL.md

@@ -17,7 +17,7 @@ $spec-add "quality All API endpoints must return structured error objects"
 
 **Valid categories**: coding, arch, quality, debug, test, review, learning, tools, bug, pattern, decision, rule, validation.
 
-**CLI alternative**: `maestro spec add <category> "<title>" "<content>" --keywords kw1,kw2 --source <src>`. Used by workflow agents (analyze, plan, execute) for programmatic spec enrichment.
+**CLI alternative**: `maestro spec add <category> "<title>" "<content>" --keywords kw1,kw2 --description "<desc>" --source <src>`. Used by workflow agents (analyze, plan, execute) for programmatic spec enrichment.
 </purpose>
 
 <context>
@@ -73,15 +73,17 @@ Auto-extract 3-5 relevant keywords from the content. Keywords should be:
 Append `<spec-entry>` closed-tag block to target file:
 
 ```markdown
-<spec-entry category="{category}" keywords="{kw1},{kw2},{kw3}" date="{YYYY-MM-DD}">
+<spec-entry category="{category}" keywords="{kw1},{kw2},{kw3}" date="{YYYY-MM-DD}" title="{title}" description="{one-line summary}">
 
-### {title extracted from content}
+### {title}
 
 {content}
 
 </spec-entry>
 ```
 
+`title` and `description` attributes are written on the tag for search indexing. `description` is optional — falls back to content[:240].
+
 ### Step 6: Confirm
 
 Display: category, target file, extracted keywords, and commands for verify (`/spec-load`) and remove (`/spec-remove`).

package/.codex/skills/spec-remove/SKILL.md

@@ -20,9 +20,9 @@ $ARGUMENTS — entry ID to remove (e.g., `spec-learnings-003`)
 **Entry ID format**: `spec-{file-stem}-{NNN}` — sub-node ID from WikiIndexer atomic indexing.
 
 **Discovery**:
-- `maestro wiki list --type spec --json` — list all spec entries
+- `maestro search --type spec --json` — list all spec entries
 - `/spec-load --keyword <term>` — find by keyword
-- `maestro wiki search "<query>"` — BM25 search
+- `maestro search "<query>"` — BM25 search
 
 **Flags:**
 - `--cascade` — When the target spec is a ref-type entry (created via `spec-add --ref` and linked to a knowhow document), also delete the referenced knowhow file. Without this flag, ref-type removal leaves an orphan knowhow file.

package/.codex/skills/team-coordinate/SKILL.md

@@ -65,7 +65,7 @@ $team-coordinate --continue "20260518-team-auth-system"
 ### Pre-load specs (optional)
 
 1. `maestro spec load --category arch` — architecture constraints
-2. `maestro wiki search "<topic>"` — relevant knowhow
+2. `maestro search "<topic>"` — relevant knowhow
 3. Proceed without if unavailable.
 
 ### Specs Reference

package/.codex/skills/wiki-digest/SKILL.md

@@ -8,7 +8,7 @@ allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion
 <purpose>
 Knowledge synthesis that generates actionable digests from the wiki knowledge graph.
 Clusters entries by semantic theme, identifies knowledge gaps, and produces a coverage
-heatmap. Unlike `maestro wiki list` (raw entries), this synthesizes and interprets
+heatmap. Unlike `maestro search` (raw entries), this synthesizes and interprets
 the knowledge base with gap analysis and recommended actions.
 </purpose>
 
@@ -32,7 +32,7 @@ $ARGUMENTS — scope and optional flags.
 <execution>
 
 ### Stage 1: Scope & Load
-Load entries via `maestro wiki list/search`. Run `maestro wiki health` for baseline.
+Load entries via `maestro search`. Run `maestro wiki health` for baseline.
 
 ### Stage 2: Theme Clustering
 Group entries into 3-5 themes via: tag co-occurrence, title BM25 similarity, relationship proximity, type grouping.

package/chains/brainstorm-driven.json

@@ -2,7 +2,7 @@
   "$schema": "./chain-graph.schema.json",
   "id": "brainstorm-driven",
   "name": "Brainstorm-Driven",
-  "description": "Brainstorm -> Init -> Analyze -> Plan -> Execute -> Verify pipeline",
+  "description": "Brainstorm -> Init -> Analyze -> Plan -> Execute pipeline",
   "version": "1.0.0",
   "tags": ["lifecycle", "brainstorm"],
   "entry": "brainstorm",
@@ -47,39 +47,7 @@
       "cmd": "maestro-execute",
       "description": "Run wave-based parallel task execution",
       "args": "{phase}",
-      "next": "verify"
-    },
-    "verify": {
-      "type": "command",
-      "cmd": "maestro-verify",
-      "description": "Goal-backward 3-layer verification",
-      "args": "{phase}",
-      "next": "check_verify",
-      "max_visits": 2
-    },
-    "check_verify": {
-      "type": "decision",
-      "eval": "ctx.result.verification_status",
-      "edges": [
-        { "value": "passed", "target": "done" },
-        { "default": true, "target": "fix_plan" }
-      ]
-    },
-    "fix_plan": {
-      "type": "command",
-      "cmd": "maestro-plan",
-      "description": "Re-plan to address verification gaps",
-      "args": "{phase} --gaps",
-      "auto_flag": "--auto",
-      "next": "fix_execute"
-    },
-    "fix_execute": {
-      "type": "command",
-      "cmd": "maestro-execute",
-      "description": "Re-execute from gap-fix plan",
-      "args": "{phase}",
-      "next": "verify",
-      "max_visits": 2
+      "next": "done"
     },
     "done": {
       "type": "terminal",

package/chains/full-lifecycle.json

@@ -2,7 +2,7 @@
   "$schema": "./chain-graph.schema.json",
   "id": "full-lifecycle",
   "name": "Full Lifecycle",
-  "description": "Plan -> Execute -> Verify -> Review -> Test -> Milestone Audit/Complete with decision points",
+  "description": "Plan -> Execute -> Review -> Test -> Milestone Audit/Complete with decision points",
   "version": "2.0.0",
   "tags": ["lifecycle", "milestone"],
   "entry": "plan",
@@ -25,39 +25,7 @@
       "cmd": "maestro-execute",
       "description": "Run wave-based parallel task execution with atomic commits",
       "args": "{phase}",
-      "next": "verify"
-    },
-    "verify": {
-      "type": "command",
-      "cmd": "maestro-verify",
-      "description": "Goal-backward 3-layer verification with anti-pattern scan",
-      "args": "{phase}",
-      "next": "check_verify",
-      "max_visits": 3
-    },
-    "check_verify": {
-      "type": "decision",
-      "eval": "ctx.result.verification_status",
-      "edges": [
-        { "value": "passed", "target": "review" },
-        { "default": true, "target": "fix_plan" }
-      ]
-    },
-    "fix_plan": {
-      "type": "command",
-      "cmd": "maestro-plan",
-      "description": "Re-plan to address verification gaps and failures",
-      "args": "{phase} --gaps",
-      "auto_flag": "--auto",
-      "next": "fix_execute"
-    },
-    "fix_execute": {
-      "type": "command",
-      "cmd": "maestro-execute",
-      "description": "Re-execute tasks from updated gap-fix plan",
-      "args": "{phase}",
-      "next": "verify",
-      "max_visits": 3
+      "next": "review"
     },
     "review": {
       "type": "command",

package/chains/next-milestone.json

@@ -32,13 +32,6 @@
       "cmd": "maestro-execute",
       "description": "Execute planned tasks with wave-based parallel execution",
       "args": "{phase}",
-      "next": "verify"
-    },
-    "verify": {
-      "type": "command",
-      "cmd": "maestro-verify",
-      "description": "Goal-backward verification of execution results",
-      "args": "{phase}",
       "next": "done"
     },
     "done": {

package/chains/quality-loop.json

@@ -2,10 +2,10 @@
   "$schema": "./chain-graph.schema.json",
   "id": "quality-loop",
   "name": "Quality Loop",
-  "description": "Verify -> Review -> Test -> Debug -> Fix -> re-Verify cycle",
+  "description": "Business Test -> Review -> Test -> Debug -> Fix cycle",
   "version": "1.0.0",
   "tags": ["quality", "loop"],
-  "entry": "verify",
+  "entry": "business_test",
   "inputs": {
     "phase": { "type": "string", "required": true }
   },
@@ -14,22 +14,6 @@
     "analyze": true
   },
   "nodes": {
-    "verify": {
-      "type": "command",
-      "cmd": "maestro-verify",
-      "description": "Goal-backward 3-layer verification with anti-pattern scan",
-      "args": "{phase}",
-      "next": "check_verify",
-      "max_visits": 4
-    },
-    "check_verify": {
-      "type": "decision",
-      "eval": "ctx.result.verification_status",
-      "edges": [
-        { "value": "passed", "target": "business_test", "description": "Verification passed, run business tests" },
-        { "default": true, "target": "plan_gaps", "description": "Verification failed" }
-      ]
-    },
     "business_test": {
       "type": "command",
       "cmd": "quality-business-test",
@@ -97,7 +81,7 @@
       "cmd": "maestro-execute",
       "description": "Re-execute tasks from updated gap-fix plan",
       "args": "{phase}",
-      "next": "verify",
+      "next": "business_test",
       "max_visits": 3
     },
     "done": {