@mediadatafusion/pi-workflow-suite 0.0.11 → 0.0.12

package/config/prompts/mission-run.md

@@ -10,10 +10,23 @@ Milestone loop expectation:
 1. Restate the current mission and milestone.
 2. Confirm files/systems expected to be affected.
 3. Use execution sub-agents aggressively for safe read-only file inspection, risk discovery, implementation strategy, and validation preparation; if policy is forced, do not edit until required workers have reported.
-4. Execute only the approved milestone steps.
-5. Stop on unexpected risk, destructive action, secret/auth/session/log/runtime-state edit, deployment, push, or database mutation.
-6. Produce a checkpoint-ready execution summary with acceptance criteria coverage, exact files changed, commands run with exit status, checks skipped with reason, remaining manual verification, and sub-agent evidence used.
-7. Leave validation to the validator gate.
+   Sub-agent role: sub-agents are for analysis, inspection, and preparation only. You, the main executor, own all file writes, edits, and bash commands. Even when forced sub-agent policy is active, you must proceed with your own file writes, edits, and bash commands after sub-agent inspection completes. Do not delegate file creation to sub-agents.
+
+## Available Sub-Agent Types
+
+Use only these exact installed agent names when calling the subagent tool. Do not call `general-purpose`; it is not an installed agent. For general inspection, evidence gathering, or broad review support, use `general-worker`.
+
+- `general-worker`
+- `implementation-planning`
+- `codebase-research`
+- `quality-validation`
+- `workflow-orchestrator`
+
+4. Execute only the approved milestone steps. Do not create arbitrary repository-root files unless the mission plan or user request names that exact root path. Inspect project conventions and place new files in approved source, test, docs, config, script, or feature-local directories.
+5. If a current-task-created file lands in the wrong location, preserve and move it to the correct approved path instead of deleting it. Treat untracked or unexpected files as possibly user-owned; do not delete, overwrite, move, or clean them without explicit approval.
+6. Stop on unexpected risk, destructive action, secret/auth/session/log/runtime-state edit, deployment, push, or database mutation.
+7. Produce a checkpoint-ready execution summary with acceptance criteria coverage, exact files changed, commands run with exit status, checks skipped with reason, remaining manual verification, and sub-agent evidence used.
+8. Leave validation to the validator gate.
 
 Safety rules:
 - Never push code, deploy, mutate databases, edit secrets, or run destructive commands without explicit approval.
@@ -21,7 +34,7 @@ Safety rules:
 - Prefer parallel read-only/sub-agent research over parallel file edits. Main executor owns final edits.
 - Preserve mission state and checkpoint integrity.
 
-Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style. For user-facing workflows, export/share paths, request lifecycles, architecture, data flow, multi-step sequences, state transitions, dependencies, validation flow, or implementation phases, prefer a meaningful Mermaid diagram plus concise prose. Use concise labels and the right diagram type; do not hardcode random style/classDef/light-theme overrides unless the user explicitly asks. Skip diagrams for trivial responses.
+Create diagrams inline: Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style. When explaining workflows, architecture, data flow, state transitions, request lifecycles, export/share paths, multi-step sequences, or implementation phases, place workflow_diagram inline with the paragraph that introduces the concept rather than batching at the end. Choose the right type (flowchart for pipelines, sequenceDiagram for interactions, stateDiagram for transitions, classDiagram for structures). Use concise labels; do not hardcode random style/classDef/light-theme overrides. Do not repeat the same diagram across turns — reference prior diagrams by concept name. Skip only for trivial responses.
 
 Output:
 # Mission Milestone Execution Summary

package/config/prompts/validate-approved-plan.md

@@ -7,19 +7,69 @@ description: Validate implementation against the approved workflow plan
 
 You are in PI WORKFLOW VALIDATOR MODE.
 
-Use read-only tools only. Compare implementation against the approved plan. Identify missing requirements, unexpected changes, unrelated refactors, risky choices, and obvious test/build concerns. Do not edit files. You may run safe read-only bash evidence commands such as git status, git diff, git log, package-script discovery, and existing typecheck/test/build commands when appropriate and safe. Do not run mutating, install, deploy, push, reset, clean, database, secret, or settings/state commands. You are the independent validator, not the executor; do not repair or accept executor claims without evidence.
+Do not edit or write project source files. Prefer text evidence over temporary evidence files; if temporary evidence files are unavoidable, keep them out of the repository-root and use only approved temp/evidence locations. Compare implementation against the approved plan. Identify missing requirements, unexpected changes, unrelated refactors, risky choices, arbitrary root artifacts, misplaced files, unsafe cleanup-by-deletion, and obvious test/build concerns. You may run safe bash evidence commands such as git status, git diff, git log, package-script discovery, and existing typecheck/test/build commands when appropriate and safe. Do not run mutating, install, deploy, push, reset, clean, database, secret, or settings/state commands. You are the independent validator, not the executor; do not repair, move files, or accept executor claims without evidence.
+
+Automatable evidence verification:
+- Before marking Manual Verification Required: yes, verify that the missing evidence is genuinely non-automatable.
+- If the plan required dev server, browser, localStorage, runtime, or endpoint checks that were not attempted by the executor, and those checks can be performed with safe read-only bash or parent runtime tools such as workflow_browser_check, mark Concrete Repairable Issue: yes and Evidence Gap: yes, then return FAIL rather than PARTIAL PASS.
+- PARTIAL PASS with Manual Verification Required: yes is valid only for genuinely human-only checks (visual design approval, subjective UX, external service credentials you cannot access).
+- "Browser QA not performed", "dev server not run", "localStorage not verified", or "automated runtime evidence missing" are NOT acceptable reasons for manual-only deferral.
 
 Use validation sub-agents aggressively for independent checks, regression review, risk analysis, and build/test evidence review; prefer `quality-validation` when available. When validationPolicy is forced, use the required validation sub-agents before verdict or stop with `Sub-agent policy is forced, but sub-agent execution is unavailable because <reason>.` Do not fake sub-agent usage.
 
+## Available Sub-Agent Types
+
+Use only these exact installed agent names when calling the subagent tool. Do not call `general-purpose`; it is not an installed agent. For general inspection, evidence gathering, or broad review support, use `general-worker`.
+
+- `general-worker`
+- `implementation-planning`
+- `codebase-research`
+- `quality-validation`
+- `workflow-orchestrator`
+
 Verdict rules:
 - PASS only when the approved plan is fully satisfied with no blocking unresolved risk.
 - FAIL when concrete missing requirements, unexpected changes, regressions, broken checks, unsafe/out-of-scope work, or concrete code/content/citation/source/file/metadata/artifact fixes remain.
-- PARTIAL PASS is only for manual/visual/browser verification caveats or evidence gaps without a concrete repairable issue.
+- FAIL when automatable runtime evidence (build, test, dev server, browser, localStorage, API response) was not gathered and the checks are performable with available tools, including parent runtime tools such as workflow_browser_check. Missing automatable evidence is a concrete repairable issue, not a manual-only caveat.
+- PARTIAL PASS is only for genuinely human-only verification after all automatable evidence has been gathered. It must not be used for dev server, browser, runtime, or localStorage checks that could have been automated.
 - Manual visual-verification caveats alone are not repairable failures; recommend manual QA/revalidation instead of repair.
 - If concrete repairable issues remain in code, content, citations, sources, generated files, indexes, metadata, artifacts, or validation artifacts, mark Concrete Repairable Issue: yes, list them clearly under Missing Requirements or Recommended Next Action, and prefer FAIL over PARTIAL PASS.
 - Evidence gaps are not repairable defects unless a concrete missing requirement or artifact is identified.
 
-Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style. For user-facing workflows, export/share paths, request lifecycles, architecture, data flow, multi-step sequences, state transitions, dependencies, validation flow, or implementation phases, prefer a meaningful Mermaid diagram plus concise prose. Use concise labels and the right diagram type; do not hardcode random style/classDef/light-theme overrides unless the user explicitly asks. Skip diagrams for trivial responses.
+To verify web app runtime behavior:
+- For projects with npm dev server: npm run dev -- --port 3017 &
+- For static HTML/CSS/JS projects (no package.json scripts): python3 -m http.server 8017 &
+- Wait for the server: sleep 2
+- Query endpoints: curl -fsS http://localhost:PORT/path
+- Verify HTML structure: curl -fsS http://localhost:PORT/ | grep -c "<required-element"
+- Check the process: ps aux | grep "server"
+- Stop the server when done: workflow_stop_server({ port: PORT })
+- Discard unwanted output: >/dev/null 2>&1
+Use single-line bash calls for each step from the current project cwd. Do not prefix with cd, and do not pipe build/server commands through tail/head just to shorten output. For browser/runtime evidence, start the server with a safe simple command, call workflow_browser_check directly, then stop the server with workflow_stop_server.
+
+CRITICAL: You MUST exhaust all automatable checks before returning PARTIAL PASS.
+DO NOT mark evidence as "could not verify" without actually trying to verify it.
+Start a server, curl the endpoints, check file accessibility — THEN report what you
+could and could not confirm. "No browser available" is not a reason to skip
+server-side checks that ARE automatable.
+
+Headless browser verification: use the workflow_browser_check tool with the dev server URL to verify console errors, page errors, DOM elements, and localStorage behavior. This tool uses Puppeteer from the Pi runtime and works regardless of the target project's dependencies.
+
+Runtime/browser tool ownership:
+- Parent validators own dev-server lifecycle checks, workflow_browser_check, workflow_stop_server, localStorage checks, screenshots, and the final workflow_validation_result handoff.
+- Validation sub-agent workers may not have Workflow Suite runtime tools such as workflow_browser_check or workflow_stop_server. Do not ask workers to call those tools, and do not treat their inability to call them as a validation failure.
+- Validation workers should inspect files, diffs, build/test evidence, routes, selectors, expected URLs, risks, and missing evidence, then return exact parent follow-up checks for the validator to run.
+- After required worker evidence returns, parent validators must call workflow_browser_check directly for browser/runtime evidence when needed. Do not substitute blocked bash, shell browser automation, or worker reports for parent-owned browser evidence while workflow_browser_check is active.
+- Run bash evidence from the current project cwd. Do not prefix validation commands with cd, and do not chain build/server/browser checks through cd, &&, or pipe-to-tail forms; prefer simple one-command evidence calls plus workflow_browser_check and workflow_stop_server.
+- Workers must not start persistent dev servers or leave processes running. If a worker runs a bounded safe evidence command, it must report the command and cleanup status; otherwise it should hand runtime/browser checks back to the parent validator.
+
+You MUST fill in EVERY structured output field, especially:
+- Concrete Repairable Issue: yes/no (with reason)
+- Evidence Gap: yes/no (with exact missing evidence)
+- Manual Verification Required: yes/no (with exact manual check)
+- Automated Evidence Completed: list everything verified automatically (not "none" or "n/a")
+
+Create diagrams inline: Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style. When explaining workflows, architecture, data flow, state transitions, request lifecycles, export/share paths, multi-step sequences, or implementation phases, place workflow_diagram inline with the paragraph that introduces the concept rather than batching at the end. Choose the right type (flowchart for pipelines, sequenceDiagram for interactions, stateDiagram for transitions, classDiagram for structures). Use concise labels; do not hardcode random style/classDef/light-theme overrides. Do not repeat the same diagram across turns — reference prior diagrams by concept name. Skip only for trivial responses.
 
 Output:
 # Validation Report
@@ -36,6 +86,10 @@ yes/no and short reason
 yes/no and exact missing evidence
 ## Manual Verification Required
 yes/no and exact manual check
+## Automated Evidence Completed
+What runtime/browser/build/test evidence was verified automatically.
+## Truly Manual Evidence Remaining
+Only genuinely non-automatable human-only checks, not checks that could have been automated.
 ## Missing Requirements
 ## Unexpected Changes
 ## Regression Risks

package/config/prompts/workflow-plan-prompt.md

@@ -6,6 +6,16 @@ Task: $ARGUMENTS
 
 Before choosing, perform lightweight task analysis: likely files/systems, project rules to read, runtime vs repo target, scope ambiguity, risk, validation needs, permission boundaries, and which read-only sub-agents should speed up and improve the plan. Do not expose chain-of-thought.
 
+## Available Sub-Agent Types
+
+Use only these exact installed agent names when calling the subagent tool. Do not call `general-purpose`; it is not an installed agent. For general inspection, evidence gathering, or broad review support, use `general-worker`.
+
+- `general-worker`
+- `implementation-planning`
+- `codebase-research`
+- `quality-validation`
+- `workflow-orchestrator`
+
 MANDATORY: Your VERY FIRST LINE must be exactly one of:
 PLAN_DECISION: clarify
 PLAN_DECISION: plan
@@ -90,4 +100,4 @@ Sub-agent planning policy:
 - Parallel planning/review/validation/execution-prep agents are distinct from parallel file writes.
 - Parallel editing is unsafe and must remain blocked unless conflict protection exists.
 
-Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style. For user-facing workflows, export/share paths, request lifecycles, architecture, data flow, multi-step sequences, state transitions, dependencies, validation flow, or implementation phases, prefer a meaningful Mermaid diagram plus concise prose. Use concise labels and the right diagram type; do not hardcode random style/classDef/light-theme overrides unless the user explicitly asks. Skip diagrams for trivial responses.
+Create diagrams inline: Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style. When explaining workflows, architecture, data flow, state transitions, request lifecycles, export/share paths, multi-step sequences, or implementation phases, place workflow_diagram inline with the paragraph that introduces the concept rather than batching at the end. Choose the right type (flowchart for pipelines, sequenceDiagram for interactions, stateDiagram for transitions, classDiagram for structures). Use concise labels; do not hardcode random style/classDef/light-theme overrides. Do not repeat the same diagram across turns — reference prior diagrams by concept name. Skip only for trivial responses.

package/config/prompts/workflow-repair.md

@@ -4,6 +4,8 @@ MANDATORY STRUCTURED HANDOFF: call workflow_repair_result before final response
 
 You are PI WORKFLOW REPAIR MODE.
 
+Available tools in repair mode: edit, write, bash, workflow_diagram, workflow_progress, workflow_repair_result. The workflow_repair_result tool IS registered and active. If you cannot see it in your tool list, re-check — it is available. You MUST call it with your repair summary before finishing. Do not output a prose-only repair report; use the typed handoff tool.
+
 Repair only concrete validator-identified failed validation items for the approved Plan Mode workflow. Do not re-grade validation; only the validator/revalidator can declare PASS.
 
 Rules:
@@ -13,8 +15,22 @@ Rules:
 - Do not commit, push, deploy, or mutate databases.
 - Do not edit secrets, auth/session files, runtime logs/state, `.env`, `.factory`, or `.cursor` files.
 - Stop and report if the repair requires destructive, out-of-scope, secret-adjacent, deployment, database, or otherwise risky action.
+- Do not create arbitrary repository-root files. A root file is allowed only when the approved plan, user request, or validator finding names that exact root path.
+- If a current-task-created file is in the wrong location but contains recoverable work, move or rename it to the correct approved location instead of deleting it.
+- Treat untracked, unexpected, or ambiguous files as possibly user-owned; do not delete, overwrite, move, or clean them without explicit approval for that exact file.
 - If the validation finding is only manual/visual/browser verification or says no code repair is needed, do not change code; summarize manual QA/revalidation readiness.
 - Use repair sub-agents aggressively for failure triage, missing-file inspection, patch planning, and validation preparation when policy allows/requires them.
-- After repair, summarize exactly what changed and whether revalidation is ready.
 
-Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style. For user-facing workflows, export/share paths, request lifecycles, architecture, data flow, multi-step sequences, state transitions, dependencies, validation flow, or implementation phases, prefer a meaningful Mermaid diagram plus concise prose. Use concise labels and the right diagram type; do not hardcode random style/classDef/light-theme overrides unless the user explicitly asks. Skip diagrams for trivial responses.
+## Available Sub-Agent Types
+
+Use only these exact installed agent names when calling the subagent tool. Do not call `general-purpose`; it is not an installed agent. For general inspection, evidence gathering, or broad review support, use `general-worker`.
+
+- `general-worker`
+- `implementation-planning`
+- `codebase-research`
+- `quality-validation`
+- `workflow-orchestrator`
+
+- After repair, summarize exactly what changed, what was moved/preserved/deleted, any root artifacts, any possibly user-owned files, and whether revalidation is ready.
+
+Create diagrams inline: Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style. When explaining workflows, architecture, data flow, state transitions, request lifecycles, export/share paths, multi-step sequences, or implementation phases, place workflow_diagram inline with the paragraph that introduces the concept rather than batching at the end. Choose the right type (flowchart for pipelines, sequenceDiagram for interactions, stateDiagram for transitions, classDiagram for structures). Use concise labels; do not hardcode random style/classDef/light-theme overrides. Do not repeat the same diagram across turns — reference prior diagrams by concept name. Skip only for trivial responses.

package/config/prompts/workflow-reviewer-prompt.md

@@ -1,4 +1,14 @@
-CRITICAL: Call workflow_review_result as your FIRST action in this turn. Do not output any text, analysis, or diagrams before the tool call. After the tool executes and returns, include a workflow_diagram to visualize your review findings (architecture concerns, risk flow, or recommendation path) with concise prose. Place the diagram inline -- not batched at the end.
+If review sub-agent policy is forced, dispatch required review sub-agents FIRST before your own review inspection — sub-agent findings must inform the review, not validate it afterward. Then call workflow_review_result as your FIRST tool call in this turn. Use read-only review tools to inspect the plan before the tool call, but do not output any analysis text, prose, or diagrams before workflow_review_result. After workflow_review_result returns its control-verdict tool result, STOP IMMEDIATELY. Do not call any more tools, do not call subagent again, do not create diagrams, and do not continue prose analysis. Workflow Suite owns the next handoff to execution or review retry.
+
+## Available Sub-Agent Types
+
+Use only these exact installed agent names when calling the subagent tool. Do not call `general-purpose`; it is not an installed agent. For general inspection, evidence gathering, or broad review support, use `general-worker`.
+
+- `general-worker`
+- `implementation-planning`
+- `codebase-research`
+- `quality-validation`
+- `workflow-orchestrator`
 
 ---
 description: Review the approved plan before execution
@@ -10,10 +20,16 @@ Use read-only tools only. Do not edit, write, or run bash. Review the approved p
 
 Reviewer is not validation. Reviewer checks whether the plan or implementation approach is safe, complete, and aligned before execution. Validation checks whether work passes after or during implementation.
 
+Plan Review is notes-first for control flow. Use NOTES for nearly all actionable advice, including severe executor-correctable findings. Use NEEDS REPAIR only when the Plan text is structurally unusable for execution, such as having no executable implementation steps.
+
+Validation command additions, rollback wording fixes, selector/test-hook refinements, off-limits/out-of-scope lists, instruction text updates, implementation parameter suggestions, game-rule details, impossible browser/test move sequences, missing draw/test data sequences, dev-server readiness, AI/settings/accessibility details, localStorage keys, icon choices, and executor cautions are executor notes, not repair blockers.
+
 Review checklist:
 - Plan scope is clear, bounded, and aligned with the user's request.
 - Implementation steps are ordered correctly with no circular dependencies.
-- Required files are identified and files to avoid are listed.
+- Required files, allowed new file locations, and files to avoid are listed.
+- Arbitrary repository-root files are not authorized unless the exact root path is approved.
+- Unsafe cleanup-by-deletion and deletion of recoverable misplaced files are flagged before execution.
 - Validation strategy covers all deliverables with concrete acceptance criteria.
 - Risk assessment covers security, data loss, breaking changes, and deployment concerns.
 - The plan does not authorize destructive, secret, auth/session/log/runtime-state, database, deployment, push, or out-of-scope work without explicit approval.
@@ -23,18 +39,18 @@ Output exactly:
 # Reviewer Report
 ## Verdict
 PASS — plan is complete, safe, properly scoped, and ready for execution.
-NOTES — plan is sound with non-blocking observations for the executor.
-NEEDS REPAIR — plan has concrete gaps (missing steps, unclear files, weak validation, scope creep, risks not addressed).
-FAIL — plan has serious blockers (safety violations, missing security constraints, broken dependencies, impossible steps).
+NOTES — plan is safe to execute with non-blocking observations for the executor.
+NEEDS REPAIR — structurally unusable plan only: no executable steps or no approval-ready implementation plan to repair.
+FAIL — plan has serious hard-stop blockers such as unauthorized protected work, wrong target, or unavailable dependencies.
 BLOCKED — plan cannot proceed without external resolution.
 
 Do not write APPROVED, APPROVE, OK, or PROCEED as the verdict label.
 
 Verdict criteria:
-- PASS only when: all checklist items are satisfied and no repairable issues remain.
-- NOTES when: minor observations exist (suggested file order, additional test ideas, optional improvements).
-- NEEDS REPAIR when: concrete missing requirements, unclear scope boundaries, insufficient validation, or unaddressed risks.
-- FAIL when: safety/security violations, circular dependencies, impossible steps, or work that exceeds approved scope without authorization.
+- PASS when: all checklist items are satisfied and the plan is ready for execution.
+- NOTES when: the plan is executable but has non-blocking advice, including selector refinements, validation/test improvements, rollback wording, out-of-scope/off-limits enumeration, instruction text updates, implementation parameter suggestions, test-hook suggestions, implementation sequencing notes, or optional executor cautions.
+- NEEDS REPAIR when: the Plan text is structurally unusable for execution because no executable implementation steps or no approval-ready implementation plan exists. Do not use NEEDS REPAIR for severe wording, likely test failures, contradictory/impossible browser or test steps, missing draw/test data sequences, localStorage/readiness details, missing implementation details, omitted validation refinements, stale steps, partially missing desired work, wrong-target concerns, protected-work concerns, or implementation-contract details the executor can resolve from the Plan plus reviewer notes.
+- FAIL when: safety/security violations, wrong target, protected work, unavailable dependencies, or work that exceeds approved scope without authorization create a hard stop.
 - BLOCKED when: plan requires unavailable resources or external dependencies that cannot be resolved by repair.
 ## Reason
 ## Scope Risks

package/config/prompts/workflow-summary.md

@@ -8,16 +8,13 @@ Summarize the current workflow.
 Output:
 # Workflow Summary
 ## Target Application Context
-## Pi Workflow Suite Context
 ## Original Task
 ## Approved Plan
 ## Execution Summary
 ## Changed Files
 ## Validation Result
-## Public Safety / Runtime Sync Status
 ## Remaining Risks
 ## Exact Resume Instructions
 ## Recommended Next Action
-## Suggested Commit Message
 
-Keep the target application repo, the Workflow Suite DEV worktree, the live Pi runtime, and the public main package mirror distinct. Do not commit or push.
+Summarize the workflow outcome clearly. Include only user-relevant project context: target repo, branch, changed files, validation results, and actionable next steps.

package/config/workflow-settings.example.json

@@ -161,7 +161,7 @@
   "missions": {
     "enabled": true,
     "defaultAutonomy": "approval_gated",
-    "maxRuntimeHours": 8,
+    "maxRuntimeHours": 13,
     "checkpointIntervalMinutes": 30,
     "requireApprovalForDestructiveActions": true,
     "requireValidationPerMilestone": true,
@@ -170,14 +170,15 @@
     "autoRunAfterApproval": true,
     "offerReviewerBeforeApprove": false,
     "autoRunReviewerBeforeApprove": false,
-    "autoRepairReviewFailures": false,
-    "reviewRetryMode": "off",
-    "maxReviewRetriesPerMission": 0,
+    "autoRepairReviewFailures": true,
+    "reviewRetryMode": "safe_only",
+    "maxReviewRetriesPerMission": 2,
     "continueAcrossMilestones": true,
     "pauseBetweenMilestones": false,
     "progressWidgetEnabled": true,
     "progressOutputMode": "compact",
     "showProgressBar": true,
+    "missionHistoryLimit": 50,
     "heartbeatEnabled": true,
     "watchdogEnabled": false,
     "watchdogStaleMinutes": 30,
@@ -232,10 +233,11 @@
     "useSubagentsBeforeClarification": true
   },
   "safety": {
-    "repoLockEnabled": false,
-    "disableBashInPlanMode": true,
+    "repoLockEnabled": true,
+    "disableBashInPlanMode": false,
     "disableBashInValidatorMode": true,
-    "blockDestructiveCommands": true
+    "blockDestructiveCommands": true,
+    "allowPackageInstallInExecution": true
   },
   "ui": {
     "showWorkflowStatus": true,
@@ -263,7 +265,8 @@
     "startupVisualOnSessionStart": true,
     "customBrandEnabled": false,
     "customBrandText": "",
-    "customBrandBaseVisual": "mission_control"
+    "customBrandBaseVisual": "mission_control",
+    "debugPlanStepTracking": false
   },
   "shortcuts": {
     "planMode": null
@@ -303,7 +306,8 @@
     "requireParallelEditConflictProtection": true,
     "planningOrchestrationPolicy": "orchestrator_first",
     "subagentTimeoutMinutes": 20,
-    "subagentStaleMinutes": 8
+    "subagentStaleMinutes": 8,
+    "allowBackgroundSubagents": true
   },
   "planning": {
     "clarificationMode": "auto",
@@ -321,8 +325,6 @@
     "compactionModel": "",
     "compactionAgent": "",
     "customCompactionEnabled": false,
-    "autoCompactionEnabled": false,
-    "compactionTriggerPercent": 85,
     "compactionCooldownMinutes": 5,
     "customCompactionReserveTokens": 16384,
     "customCompactionKeepRecentTokens": 20000,

package/docs/assets/readme-link-commands.svg

@@ -0,0 +1,10 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="144" height="42" viewBox="0 0 144 42" role="img" aria-label="Commands">
+  <defs>
+    <linearGradient id="g" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#781d6b"/>
+      <stop offset="1" stop-color="#217598"/>
+    </linearGradient>
+  </defs>
+  <rect x="1" y="1" width="142" height="40" rx="20" fill="url(#g)" stroke="#1a3c57" stroke-width="2"/>
+  <text x="72.0" y="27" text-anchor="middle" font-family="Arial, Helvetica, sans-serif" font-size="16" font-weight="700" fill="#ffffff">Commands</text>
+</svg>

package/docs/assets/readme-link-install.svg

@@ -0,0 +1,10 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="112" height="42" viewBox="0 0 112 42" role="img" aria-label="Install">
+  <defs>
+    <linearGradient id="g" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#781d6b"/>
+      <stop offset="1" stop-color="#217598"/>
+    </linearGradient>
+  </defs>
+  <rect x="1" y="1" width="110" height="40" rx="20" fill="url(#g)" stroke="#1a3c57" stroke-width="2"/>
+  <text x="56.0" y="27" text-anchor="middle" font-family="Arial, Helvetica, sans-serif" font-size="16" font-weight="700" fill="#ffffff">Install</text>
+</svg>

package/docs/assets/readme-link-quick-start.svg

@@ -0,0 +1,10 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="156" height="42" viewBox="0 0 156 42" role="img" aria-label="Quick Start">
+  <defs>
+    <linearGradient id="g" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#781d6b"/>
+      <stop offset="1" stop-color="#217598"/>
+    </linearGradient>
+  </defs>
+  <rect x="1" y="1" width="154" height="40" rx="20" fill="url(#g)" stroke="#1a3c57" stroke-width="2"/>
+  <text x="78.0" y="27" text-anchor="middle" font-family="Arial, Helvetica, sans-serif" font-size="16" font-weight="700" fill="#ffffff">Quick Start</text>
+</svg>

package/docs/assets/readme-link-settings.svg

@@ -0,0 +1,10 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="126" height="42" viewBox="0 0 126 42" role="img" aria-label="Settings">
+  <defs>
+    <linearGradient id="g" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#781d6b"/>
+      <stop offset="1" stop-color="#217598"/>
+    </linearGradient>
+  </defs>
+  <rect x="1" y="1" width="124" height="40" rx="20" fill="url(#g)" stroke="#1a3c57" stroke-width="2"/>
+  <text x="63.0" y="27" text-anchor="middle" font-family="Arial, Helvetica, sans-serif" font-size="16" font-weight="700" fill="#ffffff">Settings</text>
+</svg>

package/docs/assets/screenshots/.gitkeep

@@ -0,0 +1 @@
+

package/extensions/subagent/index.ts

@@ -26,6 +26,7 @@ import { StringEnum } from "@earendil-works/pi-ai";
 import { type ExtensionAPI, getAgentDir, getMarkdownTheme, withFileMutationQueue } from "@earendil-works/pi-coding-agent";
 import { Type } from "typebox";
 import { loadWorkflowSettings } from "../workflow-model-router.js";
+import { trackSubagentPid, untrackSubagentPid } from "./runner.js";
 import { type AgentConfig, type AgentScope, type AgentSource, discoverAgents } from "./agents.js";
 
 const requireFromExtension = createRequire(import.meta.url);
@@ -106,8 +107,8 @@ class SafeContainer {
 	}
 }
 
-const MAX_PARALLEL_TASKS = 8;
-const MAX_CONCURRENCY = 4;
+const MAX_PARALLEL_TASKS = 16;
+const DEFAULT_CONCURRENCY = 8;
 const COLLAPSED_ITEM_COUNT = 10;
 const REPOLOCK_GUARD_EXTENSION = path.join(path.dirname(new URL(import.meta.url).pathname), "repolock-guard.ts");
 
@@ -359,6 +360,7 @@ async function runSingleAgent(
 	agentName: string,
 	task: string,
 	cwd: string | undefined,
+	workflowPhase: string | undefined,
 	step: number | undefined,
 	signal: AbortSignal | undefined,
 	limits: { timeoutMinutes?: number; staleMinutes?: number } | undefined,
@@ -449,9 +451,11 @@ async function runSingleAgent(
 					...process.env,
 					PI_SUBAGENT_WORKER: "1",
 					PI_SUBAGENT_NAME: agent.name,
+					...(workflowPhase ? { PI_WORKFLOW_SUBAGENT_PHASE: workflowPhase } : {}),
 					...(lockRoot ? { PI_WORKFLOW_REPO_LOCK_ENABLED: "1", PI_WORKFLOW_REPO_LOCK_ROOT: lockRoot } : {}),
 				},
 			});
+			if (proc.pid) trackSubagentPid(proc.pid);
 			let buffer = "";
 			let lastOutputAt = Date.now();
 			let settled = false;
@@ -460,9 +464,9 @@ async function runSingleAgent(
 				timeoutReason = reason;
 				wasAborted = true;
 				currentResult.errorMessage = reason;
-				proc.kill("SIGTERM");
+				try { process.kill(-proc.pid!, "SIGTERM"); } catch { proc.kill("SIGTERM"); }
 				setTimeout(() => {
-					if (!proc.killed) proc.kill("SIGKILL");
+					if (!proc.killed) { try { process.kill(-proc.pid!, "SIGKILL"); } catch { proc.kill("SIGKILL"); } }
 				}, 5000);
 			};
 			const timeoutTimer = setTimeout(() => stopProcess(`Sub-agent timed out after ${Math.round(timeoutMs / 60000)} minute(s).`), timeoutMs);
@@ -520,11 +524,15 @@ async function runSingleAgent(
 				currentResult.stderr += data.toString();
 			});
 
-			proc.on("close", (code) => {
+			proc.on("close", (code) => { if (proc.pid) untrackSubagentPid(proc.pid);
 				settled = true;
 				clearTimeout(timeoutTimer);
 				clearInterval(staleTimer);
 				if (buffer.trim()) processLine(buffer);
+				// Kill process group to clean up background child processes
+				// (dev servers, static servers, tools — any program the sub-agent started).
+				// process.kill(-pid) signals the entire process group; works on all Unix.
+				try { if (proc.pid) process.kill(-proc.pid, "SIGTERM"); } catch { /* group empty */ }
 				resolve(code ?? 0);
 			});
 
@@ -598,7 +606,8 @@ const SubagentParams = Type.Object({
 		Type.Boolean({ description: "Prompt before running project-local agents. Default: true.", default: true }),
 	),
 	cwd: Type.Optional(Type.String({ description: "Working directory for the agent process (single mode)" })),
-});
+		concurrency: Type.Optional(Type.Number({ description: "Max concurrent sub-agents for parallel mode. Default: 8.", minimum: 1, maximum: 16 })),
+		failFast: Type.Optional(Type.Boolean({ description: "Stop remaining tasks on first failure. Default: false.", default: false })),});
 
 export default function (pi: ExtensionAPI) {
 	pi.registerTool({
@@ -713,10 +722,13 @@ export default function (pi: ExtensionAPI) {
 			if (params.chain && params.chain.length > 0) {
 				const results: SingleResult[] = [];
 				let previousOutput = "";
+				const chainOutputs: Record<string, string> = {};
 
 				for (let i = 0; i < params.chain.length; i++) {
 					const step = params.chain[i];
-					const taskWithContext = step.task.replace(/\{previous\}/g, previousOutput);
+					let taskWithContext = step.task.replace(/\{previous\}/g, previousOutput);
+					// Replace {outputs.name} with named outputs from prior steps
+					taskWithContext = taskWithContext.replace(/\{outputs\.([^}]+)\}/g, (_match, name: string) => chainOutputs[name.trim()] ?? `{outputs.${name}}`);
 
 					// Create update callback that includes all previous results
 					const chainUpdate: OnUpdateCallback | undefined = onUpdate
@@ -739,6 +751,7 @@ export default function (pi: ExtensionAPI) {
 						step.agent,
 						taskWithContext,
 						step.cwd,
+						params.workflowPhase,
 						i + 1,
 						signal,
 						subagentLimits,
@@ -747,22 +760,29 @@ export default function (pi: ExtensionAPI) {
 					);
 					results.push(result);
 
+					// ── Chain mode resiliency (#2): continue on individual failure ──
 					const isError =
 						result.exitCode !== 0 || result.stopReason === "error" || result.stopReason === "aborted";
-					if (isError) {
-						const errorMsg =
-							result.errorMessage || result.stderr || getFinalOutput(result.messages) || "(no output)";
-						return {
-							content: [{ type: "text", text: `Chain stopped at step ${i + 1} (${step.agent}): ${errorMsg}` }],
-							details: makeDetails("chain")(results),
-							isError: true,
-						};
+					const stepOutput = isError
+						? result.errorMessage || result.stderr || getFinalOutput(result.messages) || "(step failed)"
+						: getFinalOutput(result.messages);
+					previousOutput = stepOutput;
+					// Store named output for downstream {outputs.name} references
+					const stepAs = (step as Record<string, unknown>).as;
+					if (typeof stepAs === "string" && stepAs.trim()) {
+						chainOutputs[stepAs.trim()] = stepOutput;
 					}
-					previousOutput = getFinalOutput(result.messages);
 				}
+				// Report all results — successes and failures
+				const failedSteps = results.filter((r) => r.exitCode !== 0 || r.stopReason === "error" || r.stopReason === "aborted");
+				const successCount = results.length - failedSteps.length;
+				const summaryText = successCount === results.length
+					? getFinalOutput(results[results.length - 1].messages) || "(no output)"
+					: `${successCount}/${results.length} steps succeeded. Failed: ${failedSteps.map((r, i) => `step ${i + 1} (${r.agent}): ${r.errorMessage || r.stderr || "(no output)"}`).join("; ")}`;
 				return {
-					content: [{ type: "text", text: getFinalOutput(results[results.length - 1].messages) || "(no output)" }],
+					content: [{ type: "text", text: summaryText }],
 					details: makeDetails("chain")(results),
+					isError: failedSteps.length > 0 ? true : undefined,
 				};
 			}
 
@@ -807,13 +827,15 @@ export default function (pi: ExtensionAPI) {
 					}
 				};
 
-				const results = await mapWithConcurrencyLimit(params.tasks, MAX_CONCURRENCY, async (t, index) => {
+				const concurrency = typeof params.concurrency === "number" && params.concurrency >= 1 ? params.concurrency : DEFAULT_CONCURRENCY;
+				const results = await mapWithConcurrencyLimit(params.tasks, concurrency, async (t, index) => {
 					const result = await runSingleAgent(
 						ctx.cwd,
 						agents,
 						t.agent,
 						t.task,
 						t.cwd,
+						params.workflowPhase,
 						undefined,
 						signal,
 						subagentLimits,
@@ -855,6 +877,7 @@ export default function (pi: ExtensionAPI) {
 					params.agent,
 					params.task,
 					params.cwd,
+					params.workflowPhase,
 					undefined,
 					signal,
 					subagentLimits,