maestro-flow 0.3.15 → 0.3.17

package/workflows/roadmap.md

@@ -6,35 +6,16 @@ Interactive roadmap creation with iterative refinement. Lightweight path from re
 
 ## Worktree Guard
 
-```
-# Block in worktree
-IF file_exists(".workflow/worktree-scope.json"):
-  ERROR "Cannot run maestro-roadmap inside a worktree. Run from the main worktree."
-  EXIT
-```
+Block if `.workflow/worktree-scope.json` exists — must run from main worktree.
 
 ## Step 1: Session Initialization
 
-```javascript
-const getUtc8ISOString = () => new Date(Date.now() + 8 * 60 * 60 * 1000).toISOString()
-
-// Parse flags
-const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
-const continueMode = $ARGUMENTS.includes('--continue') || $ARGUMENTS.includes('-c')
-const modeMatch = $ARGUMENTS.match(/(?:--mode|-m)\s+(progressive|direct|auto)/)
-const requestedMode = modeMatch ? modeMatch[1] : 'auto'
-const brainstormMatch = $ARGUMENTS.match(/--from-brainstorm\s+(\S+)/)
-
-// Clean requirement text
-const requirement = $ARGUMENTS
-  .replace(/--yes|-y|--continue|-c|--mode\s+\w+|-m\s+\w+|--from-brainstorm\s+\S+/g, '')
-  .trim()
-
-const slug = requirement.toLowerCase()
-  .replace(/[^a-z0-9\u4e00-\u9fa5]+/g, '-')
-  .substring(0, 40)
-const dateStr = getUtc8ISOString().substring(0, 10)
-```
+Parse flags from `$ARGUMENTS`:
+- `--yes` / `-y` → auto mode
+- `--continue` / `-c` → resume from last state
+- `--mode` / `-m` → `progressive|direct|auto` (default: auto)
+- `--from-brainstorm <SESSION-ID>` → import brainstorm session
+- Remaining text → requirement (slugified for directory name)
 
 **Session directory**: `.workflow/.roadmap/RMAP-{slug}-{date}/`
 
@@ -56,23 +37,9 @@ Ensure phases in Step 2 respect architectural constraints.
 
 Read project artifacts to understand what has already been built and what carries forward:
 
-```
-IF .workflow/project.md exists:
-  Read project.md:
-    - "### Validated" section → already_shipped (completed features, DO NOT re-plan)
-    - "### Active" section → current_scope (features to plan for)
-    - "## Context" section → project_history (milestone summaries, prior work)
-    - "## Key Decisions" section → locked_decisions (constraints on new phases)
-
-IF .workflow/state.json exists:
-  Read state.json.accumulated_context:
-    - deferred[] → candidate_requirements (explicitly pushed to this milestone)
-    - key_decisions[] → architectural_constraints
-    - blockers[] → known_risks
-
-IF .workflow/codebase/ exists (from codebase-rebuild or codebase-refresh):
-  Read available codebase docs for feature inventory
-```
+- `project.md` → already_shipped (Validated), current_scope (Active), project_history (Context), locked_decisions (Key Decisions)
+- `state.json.accumulated_context` → deferred[] (candidate reqs), key_decisions[] (constraints), blockers[] (risks)
+- `.workflow/codebase/` → feature inventory from codebase docs
 
 **Context assembly** — pass to Step 2 as `project_context`:
 ```json
@@ -119,42 +86,14 @@ IF .workflow/codebase/ exists (from codebase-rebuild or codebase-refresh):
 
    **Trigger**: Technology keywords detected in requirement or codebase exploration found external dependencies. Auto-trigger in auto mode (`-y`). Skip if requirement is purely organizational.
 
-   ```
-   // Extract technology keywords from requirement + codebase exploration
-   researchTopics = extract named technologies, APIs, frameworks, protocols
-
-   IF researchTopics is not empty:
-     Agent(
-       subagent_type="workflow-external-researcher",
-       prompt="""
-   <objective>
-   Research API details and technology specifics for: {requirement}
-   Mode: API Research
-   </objective>
-
-   <context>
-   Technologies identified: {researchTopics}
-   Codebase tech stack: {codebase_exploration.tech_stack or "none"}
-   </context>
-
-   <task>
-   For each identified technology/API:
-   1. Current stable version and key capabilities
-   2. Core API surface: key endpoints/methods, auth model
-   3. Integration patterns and recommended setup
-   4. Known limitations, breaking changes, or deprecations
-   5. Effort estimation signals (simple wrapper vs complex integration)
-
-   Focus on details that affect phase decomposition and dependency ordering.
-   Be prescriptive. Return structured markdown only — do NOT write files.
-   </task>
-       """,
-       run_in_background=false
-     )
-     apiResearchContext = agent_output
-   ELSE:
-     apiResearchContext = null
-   ```
+   Extract named technologies/APIs/frameworks/protocols from requirement + codebase exploration.
+
+   If topics found → spawn `workflow-external-researcher` agent for API research:
+   - Per technology: stable version, core API surface, auth model, integration patterns, limitations, effort signals
+   - Focus on details affecting phase decomposition and dependency ordering
+   - Output → `apiResearchContext` (in-memory)
+
+   If no topics or research fails → `apiResearchContext = null`, continue.
 
    `apiResearchContext` is passed into:
    - Step 3 (Decomposition): technology complexity informs phase sizing and ordering
@@ -163,12 +102,8 @@ IF .workflow/codebase/ exists (from codebase-rebuild or codebase-refresh):
    If research fails: `apiResearchContext = null`, continue without external context.
 
 4. **Assess Uncertainty**
-   ```
-   Factors: scope_clarity, technical_risk, dependency_unknown,
-            domain_familiarity, requirement_stability
-   Each: low | medium | high
-   ≥3 high → progressive, ≥3 low → direct, else → ask
-   ```
+   - Factors: scope_clarity, technical_risk, dependency_unknown, domain_familiarity, requirement_stability (each: low/medium/high)
+   - >=3 high → progressive, >=3 low → direct, else → ask
 
 5. **Strategy Selection** (skip if `-m` specified or `-y`)
    - Present uncertainty assessment
@@ -321,15 +256,100 @@ Phase directories use `{NN}-{slug}` format (e.g., `01-auth`, `02-api`).
 
 Display summary and offer next steps:
 
-```
-=== ROADMAP CREATED ===
-Strategy: {progressive|direct}
-Phases:   {phase_count} across {milestone_count} milestones
-Roadmap:  .workflow/roadmap.md
-
-Next steps:
-  Skill({ skill: "maestro-init" })                    -- Set up project (if not yet initialized)
-  Skill({ skill: "maestro-plan", args: "1" })         -- Plan first phase
-  Skill({ skill: "maestro-brainstorm", args: "1" })   -- Explore first phase ideas
-  Skill({ skill: "manage-status" })                    -- View project dashboard
-```
+Display summary (strategy, phase count, milestones, roadmap path) and offer next steps:
+- `maestro-init` — set up project (if not yet initialized)
+- `maestro-plan 1` — plan first phase
+- `maestro-brainstorm 1` — explore first phase ideas
+- `manage-status` — view project dashboard
+
+---
+
+## Mode: Revise (`--revise [instructions]`)
+
+Revise an existing roadmap while preserving completed phase progress.
+
+**Pre-conditions:**
+- `.workflow/roadmap.md` exists
+- `.workflow/state.json` exists (for progress tracking)
+
+**Execution flow:**
+
+1. **Load current state**
+   - Read `.workflow/roadmap.md` — parse milestones, phases, dependencies, progress markers
+   - Read `.workflow/state.json` — get artifact registry, current milestone
+   - Identify completed vs in-progress vs pending phases
+
+2. **Obtain revision instructions**
+   - If `--revise "instructions text"` provided → use directly as change directive
+   - If `--revise` without instructions → use AskUserQuestion to ask user what to change
+     - Show current roadmap summary with phase statuses
+     - Present options: add/remove/reorder phases, modify scope/criteria/deps, move between milestones
+     - Capture change instructions from response
+
+3. **Impact analysis**
+   - For each proposed change, assess impact on:
+     - Phase dependency chain (re-validate no circular deps)
+     - Requirement coverage (every Active requirement still mapped)
+     - Completed phases (warn if change invalidates completed work)
+     - Existing plan artifacts (warn if plan exists for affected phase)
+   - Present impact summary for confirmation
+
+4. **Apply revisions**
+   - Update `.workflow/roadmap.md` preserving:
+     - Completed phase progress markers (checkmarks, completion dates)
+     - Phase numbering for completed phases (renumber only pending phases)
+     - Cross-references from state.json artifacts
+   - Update `state.json` if milestone structure changed
+   - Add revision log entry to roadmap.md metadata section
+
+5. **Post-revision validation**
+   - Re-check dependency integrity (no circular deps)
+   - Re-check requirement coverage (every Active req mapped)
+   - Verify completed phases unaffected
+
+**Next-step routing on completion:**
+- Phases changed, need re-analysis → `/maestro-analyze {phase}`
+- Phases changed, ready to plan → `/maestro-plan {phase}`
+- Only pending phases adjusted → `/maestro-plan` (continue from where left off)
+
+---
+
+## Mode: Review (`--review`)
+
+Read-only health assessment of the current roadmap.
+
+**Pre-conditions:**
+- `.workflow/roadmap.md` exists
+
+**Execution flow:**
+
+1. **Load roadmap + execution history**
+   - Read `.workflow/roadmap.md` — full structure
+   - Read `.workflow/state.json` — artifact registry, milestone progress
+   - Cross-reference: for each phase, check ANL/PLN/EXC/VRF artifact status
+
+2. **Assessment dimensions**
+   - **Progress tracking**: Actual vs planned per phase, milestone velocity
+   - **Drift detection**: Completed phases deviating from original scope (via verify/audit findings)
+   - **Relevance check**: Pending phases still aligned with current project goals (from project.md)
+   - **Dependency health**: Pending phase dependencies still valid given completed work
+   - **Risk assessment**: Identify phases at risk (blocked, scope creep, dependency failures)
+
+3. **Produce review report**
+   - Write to `.workflow/scratch/{YYYYMMDD}-roadmap-review.md`
+   - Format:
+     ```
+     === ROADMAP REVIEW ===
+     Milestone: {current}
+     Progress: {completed}/{total} phases ({percentage}%)
+     Drift: {none|minor|significant} | Risk: {low|medium|high}
+
+     Phase Assessment:
+       [done] Phase 1: {name} — completed, on-scope
+       [~]    Phase 2: {name} — in-progress, {notes}
+       [ ]    Phase 3: {name} — pending, {risk/notes}
+
+     Suggested: /maestro-roadmap --revise | /maestro-plan {phase} | /manage-status
+     ```
+
+**No state modifications.** Pure assessment + recommendations.

package/workflows/spec-generate.md

@@ -4,58 +4,21 @@ Specification document chain producing a complete specification package (Product
 
 ## Worktree Guard
 
-```
-# Block in worktree
-IF file_exists(".workflow/worktree-scope.json"):
-  ERROR "Cannot run maestro-spec-generate inside a worktree. Run from the main worktree."
-  EXIT
-```
+Block if `.workflow/worktree-scope.json` exists — must run from main worktree.
 
 ## Pipeline Position
 
 ```
-maestro-brainstorm (optional upstream)
-        ↓ guidance-specification.md
-maestro-init (REQUIRED first step — project setup)
-        ↓ project.md, state.json, config.json
-maestro-spec-generate ← THIS (heavy path)
-        ↓ spec package + roadmap.md → .workflow/roadmap.md
-maestro-plan → maestro-execute → maestro-verify
-
-Alternative light path (skip spec-generate):
-maestro-init → maestro-roadmap → roadmap.md directly
-
-Note: maestro-init MUST run before spec-generate.
+brainstorm (optional) → init (REQUIRED) → spec-generate → plan → execute → verify
+Alternative light path: init → roadmap → plan (skip spec-generate)
 ```
 
 ## Architecture
 
 ```
-Phase 0:   Specification Study (read specs + templates)
-           |
-Phase 1:   Discovery               → spec-config.json + discovery-context.json
-           |                           (includes spec_type selection)
-Phase 1.5: Req Expansion           → refined-requirements.json
-           |                           (-y: auto-expansion, skip interaction)
-Phase 2:   Product Brief            → product-brief.md + glossary.json
-           |                           (multi-CLI parallel analysis)
-Phase 3:   Requirements (PRD)      → requirements/ (_index.md + REQ-*.md + NFR-*.md)
-           |                           (RFC 2119, data model definitions)
-Phase 4:   Architecture            → architecture/ (_index.md + ADR-*.md)
-           |                           (state machine, config model, error handling, observability)
-Phase 5:   Epics & Stories         → epics/ (_index.md + EPIC-*.md)
-           |
-Phase 6:   Readiness Check         → readiness-report.md + spec-summary.md
-           |                           (terminology + scope consistency validation)
-           ├── Pass (>=80%): Proceed to Phase 7
-           ├── Review (60-79%): Proceed with caveats
-           └── Fail (<60%): Phase 6.5 Auto-Fix (max 2 iterations)
-                 |
-Phase 6.5: Auto-Fix               → Updated Phase 2-5 documents
-                 └── Re-run Phase 6 validation
-           |
-Phase 7:   Roadmap Generation      → roadmap.md + .workflow/roadmap.md
-                                       (Epic→Phase mapping, interactive refinement)
+P0: Spec Study → P1: Discovery → P1.5: Req Expansion → P2: Product Brief → P3: PRD → P4: Architecture → P5: Epics → P6: Readiness Check → P7: Roadmap
+
+P6 gate: Pass (>=80%) → P7 | Review (60-79%) → P7 w/caveats | Fail (<60%) → P6.5 Auto-Fix (max 2 iter) → re-check
 ```
 
 ## Arguments
@@ -116,20 +79,8 @@ Used in Phase 3 (architecture doc) and Phase 6 (epic decomposition) for constrai
 These inform validation and output formatting for all subsequent phases.
 
 **Load project history (if `.workflow/` exists):**
-```
-IF .workflow/project.md exists:
-  Read project.md:
-    - "### Validated" → already_shipped (DO NOT re-specify)
-    - "### Active" → current_scope
-    - "## Context" → project_history (milestone summaries)
-    - "## Key Decisions" → locked_decisions
-
-IF .workflow/state.json exists:
-  Read state.json.accumulated_context:
-    - deferred[] → candidate_requirements (high priority for this iteration)
-    - key_decisions[] → architectural_constraints
-
-```
+- `project.md` → already_shipped (Validated), current_scope (Active), project_history (Context), locked_decisions (Key Decisions)
+- `state.json.accumulated_context` → deferred[] (high priority candidates), key_decisions[] (architectural constraints)
 
 **Rules**:
 - Features in `already_shipped` are EXCLUDED from spec generation scope — they are done
@@ -176,49 +127,14 @@ Spawn `workflow-external-researcher` agent to gather concrete API details, libra
 
 **Trigger**: When seed analysis identifies specific technologies, APIs, or external services. Auto-trigger in auto mode (`-y`). Skip if topic is purely conceptual with no technology keywords.
 
-```
-// Step 2.5.1: Build research queries from seed analysis
-researchTopics = extract from seed_analysis:
-  - Named technologies/frameworks (e.g., "OAuth 2.0", "WebSocket", "PostgreSQL")
-  - External APIs/services mentioned (e.g., "Stripe API", "SendGrid")
-  - Domain-specific protocols or standards
-
-IF researchTopics is empty: skip to Step 2.6, set apiResearchContext = null
-
-// Step 2.5.2: Spawn external researcher
-Agent(
-  subagent_type="workflow-external-researcher",
-  prompt="""
-<objective>
-Research API details and technology specifics for: {seed_analysis.problem_statement}
-Mode: API Research
-</objective>
-
-<context>
-Technologies identified: {researchTopics}
-Domain: {seed_analysis.domain}
-Spec type: {spec_type or "TBD"}
-Codebase tech stack: {discovery_context.tech_stack or "none"}
-</context>
-
-<task>
-For each identified technology/API:
-1. Current stable version and key capabilities
-2. API surface: core endpoints/methods, authentication model, rate limits
-3. Integration patterns: recommended setup, configuration, common middleware
-4. Data models: key entities, request/response shapes
-5. Known limitations, deprecations, or migration paths
-
-Focus on CONCRETE details — versions, method signatures, config options.
-Be prescriptive. Return structured markdown only — do NOT write files.
-</task>
-  """,
-  run_in_background=false
-)
-
-// Step 2.5.3: Store as apiResearchContext (in-memory)
-apiResearchContext = agent_output
-```
+Extract named technologies/APIs/frameworks/protocols from seed analysis and codebase exploration.
+
+If topics found → spawn `workflow-external-researcher` agent for API research:
+- Per technology: stable version, API surface (endpoints, auth, rate limits), integration patterns, data models, limitations/deprecations
+- Focus on concrete details (versions, method signatures, config options)
+- Output → `apiResearchContext` (in-memory)
+
+If no topics → `apiResearchContext = null`, skip to Step 2.6.
 
 `apiResearchContext` is passed into:
 - Step 4 (Product Brief): technology feasibility assessment
@@ -538,24 +454,12 @@ Phase = synchronization barrier (full plan→execute→verify cycle). Minimize p
 
 ```
 == spec-generate complete ==
-Session:  SPEC-{slug}-{date}
-Output:   .workflow/.spec/{session_id}/
-Quality:  {score}% ({gate})
-Phases:   {completed_count}/7
-
-Files:
-  spec-config.json          — Session state
-  product-brief.md          — Product brief
-  requirements/             — PRD ({req_count} REQs + {nfr_count} NFRs)
-  architecture/             — Architecture ({adr_count} ADRs)
-  epics/                    — Epics & Stories ({epic_count} Epics)
-  readiness-report.md       — Quality validation
-  spec-summary.md           — Executive summary
-  roadmap.md                — Project roadmap ({phase_count} phases, {milestone_count} milestones)
-
-Next:
-  Skill({ skill: "maestro-init" })                                    — Set up project
-  Skill({ skill: "maestro-plan", args: "1" })                         — Plan first phase
+Session: SPEC-{slug}-{date} | Quality: {score}% ({gate}) | Phases: {completed_count}/7
+Output: .workflow/.spec/{session_id}/
+  spec-config.json, product-brief.md, requirements/, architecture/, epics/,
+  readiness-report.md, spec-summary.md, roadmap.md
+
+Next: maestro-init (setup) | maestro-plan 1 (plan first phase)
 ```
 
 ---

package/workflows/specs-add.md

@@ -32,18 +32,9 @@ content  -- free-text description of the entry
 ### Step 1: Parse Arguments
 
 ```
-Split $ARGUMENTS into:
-  category = first word
-  content  = remaining text
-
-Validate:
-  - category must be one of: coding, arch, quality, debug, test, review, learning
-  - content must not be empty
-
-On validation failure:
-  - Display usage: `/spec-add <category> <content>`
-  - List valid categories
-  - Exit
+Parse: category = first word, content = remaining text
+Validate: category ∈ {coding, arch, quality, debug, test, review, learning}, content non-empty
+On failure: show usage `/spec-add <category> <content>` with valid categories, exit
 ```
 
 ### Step 2: Resolve Target File
@@ -65,16 +56,11 @@ Auto-extract 3-5 relevant keywords from the content:
 ### Step 4: Format Entry
 
 ```
-Generate timestamp: YYYY-MM-DD (local date)
-Generate title from first meaningful phrase of content.
+Entry format (closed-tag), date = YYYY-MM-DD, title = first meaningful phrase:
 
-Entry format (closed-tag):
 <spec-entry category="{category}" keywords="{kw1},{kw2},{kw3}" date="{YYYY-MM-DD}">
-
 ### {title}
-
 {content}
-
 </spec-entry>
 ```
 
@@ -84,13 +70,7 @@ Read target file. Append the formatted `<spec-entry>` block at the end. Write fi
 
 ### Step 6: Confirm
 
-```
-== spec-add complete ==
-Category: <category>
-Added to: .workflow/specs/<target_file>
-Keywords: <kw1>, <kw2>, <kw3>
-Verify: /spec-load --keyword <kw1>
-```
+Display: category, target file, keywords, and verify command (`/spec-load --keyword <kw1>`).
 
 ## Output
 

package/workflows/specs-load.md

@@ -31,11 +31,7 @@ Each category loads exactly one file. Same mapping as spec-add.
 
 ### Step 1: Parse Arguments
 
-```
-Parse $ARGUMENTS:
-  --category <type>  -> category filter
-  remaining text     -> keyword for grep filtering
-```
+Extract `--category <type>` (filter) and remaining text (keyword for grep).
 
 ### Step 2: Load Specs via CLI
 

package/workflows/specs-remove.md

@@ -102,14 +102,3 @@ To verify:  maestro wiki list --type spec --category {category}
 To re-add:  /spec-add {category} {content}
 ```
 
----
-
-## Error Codes
-
-| Code | Severity | Condition | Recovery |
-|------|----------|-----------|----------|
-| E001 | fatal | Entry ID required | Usage: `/spec-remove <entry-id>` |
-| E002 | fatal | `.workflow/specs/` not initialized | Run `/spec-setup` first |
-| E003 | fatal | Entry ID not found in wiki index | Check ID with `maestro wiki list --type spec` |
-| E004 | fatal | Entry is not a spec sub-node | Only `<spec-entry>` sub-nodes can be removed this way |
-| W001 | warning | Container file empty after removal | File kept but has no entries |

package/workflows/specs-setup.md

@@ -16,40 +16,18 @@ System specs initialization -- scan project structure, detect tech stack, genera
 
 ### Step 1: Ensure Directory Structure
 
-```
-Create directories if not present:
-  .workflow/
-  .workflow/specs/
-```
+Ensure `.workflow/` and `.workflow/specs/` exist (create if missing).
 
 ### Step 2: Scan Project Structure
 
-Scan the project root for tech stack indicators:
+Scan project root for tech stack indicators:
 
 ```
-Detection targets:
-  package.json        --> Node.js ecosystem (read dependencies for framework detection)
-  tsconfig.json       --> TypeScript
-  pyproject.toml      --> Python (modern)
-  requirements.txt    --> Python (legacy)
-  go.mod              --> Go
-  Cargo.toml          --> Rust
-  pom.xml             --> Java (Maven)
-  build.gradle        --> Java/Kotlin (Gradle)
-  composer.json        --> PHP
-  Gemfile             --> Ruby
-  .csproj / .sln      --> .NET/C#
-  Dockerfile          --> Container deployment
-  docker-compose.yml  --> Multi-container orchestration
-
-Framework detection (from dependency files):
-  react / next        --> React / Next.js
-  vue                 --> Vue.js
-  angular             --> Angular
-  express / fastify   --> Node.js server
-  django / flask      --> Python web
-  gin / echo          --> Go web
-  spring              --> Java Spring
+Manifest files → runtime: package.json (Node), tsconfig.json (TS), pyproject.toml/requirements.txt (Python),
+  go.mod (Go), Cargo.toml (Rust), pom.xml (Maven), build.gradle (Gradle), composer.json (PHP),
+  Gemfile (Ruby), .csproj/.sln (.NET), Dockerfile/docker-compose.yml (containers)
+
+Dependency analysis → frameworks: react/next, vue, angular, express/fastify, django/flask, gin/echo, spring
 ```
 
 ### Step 3: Detect Code Patterns
@@ -57,11 +35,9 @@ Framework detection (from dependency files):
 Scan source files for coding conventions:
 
 ```
-Indentation:  Count leading spaces/tabs in first 20 source files
-Naming:       Scan exports for camelCase / PascalCase / snake_case patterns
-Imports:      Check import style (named vs default, path aliases, barrel exports)
-Formatting:   Check for .prettierrc, .editorconfig, eslint config
-File naming:  kebab-case vs camelCase vs PascalCase for source files
+Detect from first 20 source files: indentation style, naming conventions (camelCase/PascalCase/snake_case),
+import style (named/default, aliases, barrels), formatter configs (.prettierrc, .editorconfig, eslint),
+file naming pattern (kebab/camel/Pascal)
 ```
 
 ### Step 4: Generate Core Files (always created)
@@ -210,19 +186,7 @@ These are NOT created during setup. They are created on demand when `spec-add de
 
 ### Step 6: Summary
 
-Display what was created:
-```
-Specs initialized:
-  .workflow/specs/coding-conventions.md          (category: coding)
-  .workflow/specs/architecture-constraints.md    (category: arch)
-  .workflow/specs/learnings.md                   (category: learning)
-  {if created:}
-  .workflow/specs/quality-rules.md               (category: quality)
-  .workflow/specs/test-conventions.md            (category: test)
-
-Categories: coding, arch, quality, debug, test, review, learning
-  debug-notes.md and review-standards.md created on demand via /spec-add
-```
+Display list of created files with categories. Note that `debug-notes.md` and `review-standards.md` are created on demand via `/spec-add`.
 
 ## Output