Refine autonomous task granularity and escalation handling

.agents/skills/documentation-criteria/references/task-template.md

@@ -3,7 +3,7 @@
 Metadata:
 - Dependencies: task-01 -> Deliverable: docs/plans/analysis/research-results.md
 - Provides: docs/plans/analysis/api-spec.md (for research/design tasks)
-- Size: Small (1-2 files)
+- Source Plan Tasks: [P1-T1, P1-T2]
 
 ## Implementation Content
 [What this task will achieve]

.agents/skills/recipe-add-integration-tests/SKILL.md

@@ -142,7 +142,7 @@ Use the executor's `filesModified` as the task write set.
 Spawn integration-test-reviewer with `changedTestFiles: [integration/E2E test paths from filesModified]`, `diffBase`, `skeletonFiles: [layer-specific paths from Step 2]`, and `taskFile`.
 Keep `testsAdded` as reporting metadata only.
 
-**Expected output**: `status` (approved/needs_revision/blocked), `reviewBasis`, `requiredFixes`. Escalate `blocked` or an unrecognized status.
+**Expected output**: `status` (approved/needs_revision/blocked), `reviewBasis`, `requiredFixes`. Apply Orchestrator Escalation Resolution for `blocked` or an unrecognized status.
 
 ### Step 6: Apply Review Fixes
 
@@ -163,7 +163,7 @@ Spawn quality-fixer routed by task filename pattern:
 
 On quality-fixer result:
 - `status: "stub_detected"` -> Return to Step 4 with `stubFindings`
-- `status: "blocked"` -> Escalate to user
+- `status: "blocked"` -> Apply Orchestrator Escalation Resolution
 - `status: "approved"` -> Commit test files
 - MUST commit test files with appropriate message
 ENFORCEMENT: Commits without quality-fixer approval are invalid.

.agents/skills/recipe-build/SKILL.md

@@ -21,7 +21,7 @@ description: "Execute decomposed backend tasks in autonomous execution mode usin
 1. **Spawn agents for all work** -- your role is to invoke sub-agents, pass data between them, and report results
 2. **Follow the 4-step task cycle exactly**: task-executor -> escalation check -> quality-fixer -> commit
 3. **Enter autonomous mode** when user provides execution instruction with existing task files -- this IS the batch approval
-4. **Scope**: Complete when all tasks are committed or escalation occurs
+4. **Scope**: Complete when all tasks are committed or user input is required
 
 **CRITICAL**: MUST run quality-fixer before every commit.
 ENFORCEMENT: Commits without quality-fixer approval are invalid and MUST be reverted.
@@ -92,17 +92,17 @@ Generate tasks from the work plan? (y/n):
 ```
 
 ### 3. Task Decomposition (if approved)
-Spawn task-decomposer agent: "Read work plan at docs/plans/[plan-name].md and decompose into atomic tasks. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable."
+Spawn task-decomposer agent: "Read the approved work plan at docs/plans/[plan-name].md and generate executable task files in docs/plans/tasks/."
 
 ### 4. Verify Generation
-Recompute the Consumed Task Set and verify it is non-empty.
+Check task-decomposer `Status`. Apply Orchestrator Escalation Resolution for `blocked` or an unrecognized status. Only after `completed`, recompute the Consumed Task Set and verify it is non-empty.
 
 ## Pre-execution Checklist
 
 - [ ] Confirmed task files exist in docs/plans/tasks/
 - [ ] Identified task execution order (dependencies)
 - [ ] **Environment check**: Can I execute per-task commit cycle?
-  - If commit capability unavailable -> Escalate before autonomous mode
+  - If commit capability unavailable -> Apply Orchestrator Escalation Resolution before autonomous mode
   - Other environments (tests, quality tools) -> Subagents will escalate
 
 ## Task Execution Cycle (4-Step Cycle)
@@ -115,16 +115,16 @@ For EACH task, YOU MUST:
 1. **Capture diff base**: Record the current revision as `diffBase`.
 2. **Spawn task-executor agent**: "Execute the task implementation for [task-file-path]"
 3. **CHECK task-executor response**:
-   - `status: "escalation_needed"` or `"blocked"` -> STOP and escalate to user
+   - `status: "escalation_needed"` or `"blocked"` -> Apply Orchestrator Escalation Resolution
    - `requiresTestReview` is `true` -> Spawn integration-test-reviewer agent with `changedTestFiles: [integration/E2E paths from filesModified]`, `diffBase`, and `taskFile: [task-file-path]`; when matching integration/E2E skeleton paths are available from acceptance-test-generator output or task/work-plan references, pass only those paths as `skeletonFiles`
      - `needs_revision` -> Apply Review Revision Convergence (`author`: task-executor; `artifact`: changed test files); on `progression`, proceed to step 4
      - `approved` -> Proceed to step 4
-     - `blocked` or unrecognized status -> STOP and escalate to user
+     - `blocked` or unrecognized status -> Apply Orchestrator Escalation Resolution
    - `readyForQualityCheck: true` -> Proceed to step 4
 4. **Spawn quality-fixer agent** with `task_file` and executor `filesModified`.
 5. **CHECK quality-fixer response**:
    - `status: "stub_detected"` -> Return to step 2 with `stubFindings`
-   - `status: "blocked"` -> STOP and escalate to user
+   - `status: "blocked"` -> Apply Orchestrator Escalation Resolution
    - `status: "approved"` -> Proceed to step 6
 6. **COMMIT on approval**: After `status: "approved"` from quality-fixer -> Execute git commit
 
@@ -152,16 +152,16 @@ After all task cycles finish, collect all `filesModified` from every task-execut
 3. Consolidate results:
    - code-verifier passes when `summary.status` is `consistent` or `mostly_consistent`
    - code-verifier fails when `summary.status` is `needs_review` or `inconsistent`
-   - code-verifier `blocked` or unrecognized status -> Escalate to user
+   - code-verifier `blocked` or unrecognized status -> Apply Orchestrator Escalation Resolution
    - security-reviewer passes when `status` is `approved` or `approved_with_notes`
    - security-reviewer fails when `status` is `needs_revision`
-   - security-reviewer `blocked` -> Escalate to user
+   - security-reviewer `blocked` -> Apply Orchestrator Escalation Resolution
 4. If either verifier fails:
    - Create one ephemeral fix task per executor route covering verifier discrepancies and security requiredFixes
    - Pass each exact task path to task-executor and then quality-fixer
    - Re-run both code-verifier and security-reviewer after any fix
    - Delete the ephemeral task files only after both verifiers pass
-   - Maximum retry count is 1 verification fix cycle; if any failed verifier still fails after re-run, escalate to the user
+   - If any verifier still fails after re-run, apply Orchestrator Escalation Resolution
 5. If both verifiers pass -> Proceed to completion report
 
 ## Final Cleanup
@@ -186,7 +186,7 @@ If cleanup fails, report the failed path but do not invalidate completed impleme
 - [ ] All tasks executed through 4-step cycle (task-executor -> check -> quality-fixer -> commit)
 - [ ] System constraint suffix appended to all sub-agent prompts
 - [ ] All quality gates passed
-- [ ] All tasks committed or escalation completed
+- [ ] All tasks committed or user input requested
 
 ## Output Example
 Backend implementation phase completed.

.agents/skills/recipe-front-build/SKILL.md

@@ -21,7 +21,7 @@ description: "Execute frontend tasks in autonomous execution mode using task-exe
 1. **Spawn agents for all work** -- your role is to invoke sub-agents, pass data between them, and report results
 2. **Follow the 4-step task cycle exactly**: task-executor-frontend -> escalation check -> quality-fixer-frontend -> commit
 3. **Enter autonomous mode** when user provides execution instruction with existing task files -- this IS the batch approval
-4. **Scope**: Complete when all tasks are committed or escalation occurs
+4. **Scope**: Complete when all tasks are committed or user input is required
 
 **CRITICAL**: MUST run quality-fixer-frontend before every commit.
 ENFORCEMENT: Commits without quality-fixer-frontend approval are invalid and MUST be reverted.
@@ -92,17 +92,17 @@ Generate tasks from the work plan? (y/n):
 ```
 
 ### 3. Task Decomposition (if approved)
-Spawn task-decomposer agent: "Read work plan at docs/plans/[plan-name].md and decompose into atomic tasks. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable"
+Spawn task-decomposer agent: "Read the approved work plan at docs/plans/[plan-name].md and generate executable task files in docs/plans/tasks/."
 
 ### 4. Verify Generation
-Recompute the Consumed Task Set and verify it is non-empty.
+Check task-decomposer `Status`. Apply Orchestrator Escalation Resolution for `blocked` or an unrecognized status. Only after `completed`, recompute the Consumed Task Set and verify it is non-empty.
 
 ## Pre-execution Checklist
 
 - [ ] Confirmed task files exist in docs/plans/tasks/
 - [ ] Identified task execution order (dependencies)
 - [ ] **Environment check**: Can I execute per-task commit cycle?
-  - If commit capability unavailable -> Escalate before autonomous mode
+  - If commit capability unavailable -> Apply Orchestrator Escalation Resolution before autonomous mode
   - Other environments (tests, quality tools) -> Subagents will escalate
 
 ## Task Execution Cycle (4-Step Cycle) - Frontend Specialized
@@ -123,16 +123,16 @@ For EACH task, YOU MUST:
 1. **Capture diff base**: Record the current revision as `diffBase`.
 2. **Spawn task-executor-frontend agent**: "Task file: docs/plans/tasks/[filename].md Execute frontend implementation"
 3. **CHECK task-executor-frontend response**:
-   - `status: "escalation_needed"` or `"blocked"` -> STOP and escalate to user
+   - `status: "escalation_needed"` or `"blocked"` -> Apply Orchestrator Escalation Resolution
    - `requiresTestReview` is `true` -> Spawn integration-test-reviewer with `changedTestFiles: [integration/E2E paths from filesModified]`, `diffBase`, and `taskFile`; when matching integration/E2E skeleton paths are available from acceptance-test-generator output or task/work-plan references, pass only those paths as `skeletonFiles`
      - `needs_revision` -> Apply Review Revision Convergence (`author`: task-executor-frontend; `artifact`: changed test files); on `progression`, proceed to step 4
      - `approved` -> Proceed to step 4
-     - `blocked` or unrecognized status -> STOP and escalate to user
+     - `blocked` or unrecognized status -> Apply Orchestrator Escalation Resolution
    - `readyForQualityCheck: true` -> Proceed to step 4
 4. **Spawn quality-fixer-frontend agent** with `task_file` and executor `filesModified`.
 5. **CHECK quality-fixer-frontend response**:
    - `status: "stub_detected"` -> Return to step 2 with `stubFindings`
-   - `status: "blocked"` -> STOP and escalate to user
+   - `status: "blocked"` -> Apply Orchestrator Escalation Resolution
    - `status: "approved"` -> Proceed to step 6
 6. **COMMIT on approval**: After `status: "approved"` from quality-fixer-frontend -> Execute git commit. Use `changeSummary` for commit message.
 
@@ -160,16 +160,16 @@ After all task cycles finish, collect all `filesModified` from every task-execut
 3. Consolidate results:
    - code-verifier passes when `summary.status` is `consistent` or `mostly_consistent`
    - code-verifier fails when `summary.status` is `needs_review` or `inconsistent`
-   - code-verifier `blocked` or unrecognized status -> Escalate to user
+   - code-verifier `blocked` or unrecognized status -> Apply Orchestrator Escalation Resolution
    - security-reviewer passes when `status` is `approved` or `approved_with_notes`
    - security-reviewer fails when `status` is `needs_revision`
-   - security-reviewer `blocked` -> Escalate to user
+   - security-reviewer `blocked` -> Apply Orchestrator Escalation Resolution
 4. If either verifier fails:
    - Create one ephemeral frontend fix task covering verifier discrepancies and security requiredFixes
    - Pass its exact path to task-executor-frontend and then quality-fixer-frontend
    - Re-run both code-verifier and security-reviewer after any fix
    - Delete the ephemeral task file only after both verifiers pass
-   - Maximum retry count is 1 verification fix cycle; if any failed verifier still fails after re-run, escalate to the user
+   - If any verifier still fails after re-run, apply Orchestrator Escalation Resolution
 5. If both verifiers pass -> Proceed to completion report
 
 ## Final Cleanup
@@ -194,7 +194,7 @@ If cleanup fails, report the failed path but do not invalidate completed impleme
 - [ ] All tasks executed through 4-step cycle (task-executor-frontend -> check -> quality-fixer-frontend -> commit)
 - [ ] System constraint suffix appended to all sub-agent prompts
 - [ ] All quality gates passed
-- [ ] All tasks committed or escalation completed
+- [ ] All tasks committed or user input requested
 
 ## Output Example
 Frontend implementation phase completed.

.agents/skills/recipe-fullstack-build/SKILL.md

@@ -31,7 +31,7 @@ ENFORCEMENT: Proceeding without reading monorepo-flow.md invalidates the entire
    - `*-frontend-task-*` -> task-executor-frontend + quality-fixer-frontend
 3. **Follow the 4-step task cycle exactly**: executor -> escalation check -> quality-fixer -> commit
 4. **Enter autonomous mode** when user provides execution instruction with existing task files -- this IS the batch approval
-5. **Scope**: Complete when all tasks are committed or escalation occurs
+5. **Scope**: Complete when all tasks are committed or user input is required
 
 **CRITICAL**: MUST run layer-appropriate quality-fixer before every commit.
 ENFORCEMENT: Commits without quality-fixer approval are invalid and MUST be reverted.
@@ -102,17 +102,17 @@ Generate tasks from the work plan? (y/n):
 ```
 
 ### 3. Task Decomposition (if approved)
-Spawn task-decomposer agent: "Read work plan at docs/plans/[plan-name].md and decompose into atomic tasks. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable. Use layer-aware naming: {plan}-backend-task-{n}.md, {plan}-frontend-task-{n}.md based on target file paths."
+Spawn task-decomposer agent: "Read the approved work plan at docs/plans/[plan-name].md and generate executable task files in docs/plans/tasks/. Use layer-aware naming: {plan}-backend-task-{n}.md, {plan}-frontend-task-{n}.md based on target file paths."
 
 ### 4. Verify Generation
-Recompute the Consumed Task Set and verify it is non-empty.
+Check task-decomposer `Status`. Apply Orchestrator Escalation Resolution for `blocked` or an unrecognized status. Only after `completed`, recompute the Consumed Task Set and verify it is non-empty.
 
 ## Pre-execution Checklist
 
 - [ ] Confirmed task files exist in docs/plans/tasks/
 - [ ] Identified task execution order (dependencies)
 - [ ] **Environment check**: Can I execute per-task commit cycle?
-  - If commit capability unavailable -> Escalate before autonomous mode
+  - If commit capability unavailable -> Apply Orchestrator Escalation Resolution before autonomous mode
   - Other environments (tests, quality tools) -> Subagents will escalate
 
 ## Agent Routing Table
@@ -133,16 +133,16 @@ For EACH task, YOU MUST:
 1. **Capture diff base**: Record the current revision as `diffBase`.
 2. **Spawn task-executor or task-executor-frontend agent** (per routing table): "Execute the task implementation for [task-file-path]"
 3. **CHECK executor response**:
-   - `status: "escalation_needed"` or `"blocked"` -> STOP and escalate to user
+   - `status: "escalation_needed"` or `"blocked"` -> Apply Orchestrator Escalation Resolution
    - `requiresTestReview` is `true` -> Spawn integration-test-reviewer with `changedTestFiles: [integration/E2E paths from filesModified]`, `diffBase`, and `taskFile`; when matching integration/E2E skeleton paths are available from acceptance-test-generator output or task/work-plan references, pass only those paths as `skeletonFiles`
      - `needs_revision` -> Apply Review Revision Convergence (`author`: layer-appropriate executor; `artifact`: changed test files); on `progression`, proceed to step 4
      - `approved` -> Proceed to step 4
-     - `blocked` or unrecognized status -> STOP and escalate to user
+     - `blocked` or unrecognized status -> Apply Orchestrator Escalation Resolution
    - `readyForQualityCheck: true` -> Proceed to step 4
 4. **Spawn quality-fixer agent** (layer-appropriate per routing table) with `task_file` and executor `filesModified`.
 5. **CHECK quality-fixer response**:
    - `status: "stub_detected"` -> Return to step 2 with `stubFindings`
-   - `status: "blocked"` -> STOP and escalate to user
+   - `status: "blocked"` -> Apply Orchestrator Escalation Resolution
    - `status: "approved"` -> Proceed to step 6
 6. **COMMIT on approval**: After `status: "approved"` from quality-fixer -> Execute git commit
 
@@ -170,16 +170,16 @@ After all task cycles finish, collect all `filesModified` from every task-execut
 3. Consolidate results:
    - each code-verifier run passes when `summary.status` is `consistent` or `mostly_consistent`
    - a code-verifier run fails when `summary.status` is `needs_review` or `inconsistent`
-   - code-verifier `blocked` or unrecognized status -> Escalate to user
+   - code-verifier `blocked` or unrecognized status -> Apply Orchestrator Escalation Resolution
    - security-reviewer passes when `status` is `approved` or `approved_with_notes`
    - security-reviewer fails when `status` is `needs_revision`
-   - security-reviewer `blocked` -> Escalate to user
+   - security-reviewer `blocked` -> Apply Orchestrator Escalation Resolution
 4. If any verifier fails:
    - Create one ephemeral fix task per executor route covering verifier discrepancies and security requiredFixes
    - Pass each exact task path to the layer-appropriate task-executor and then quality-fixer
    - Re-run all code-verifier runs and security-reviewer after any fix
    - Delete the ephemeral task files only after all verifiers pass
-   - Maximum retry count is 1 verification fix cycle; if any failed verifier still fails after re-run, escalate to the user
+   - If any verifier still fails after re-run, apply Orchestrator Escalation Resolution
 5. If all verifiers pass -> Proceed to completion report
 
 ## Final Cleanup
@@ -206,7 +206,7 @@ If cleanup fails, report the failed path but do not invalidate completed impleme
 - [ ] All tasks executed through 4-step cycle (executor -> check -> quality-fixer -> commit)
 - [ ] System constraint suffix appended to all sub-agent prompts
 - [ ] All quality gates passed
-- [ ] All tasks committed or escalation completed
+- [ ] All tasks committed or user input requested
 
 ## Output Example
 Fullstack implementation phase completed.