@@ -66,7 +66,7 @@ This is chat output, not a file. Nothing here is written to the plan.
 
 ## Layout
 
-```
+```markdown
 # Plan: {plan.name}
 
 Path: {plan.path}
@@ -108,14 +108,14 @@ explicit `None.` confirms nothing is pending.
 
 When `assumptions` is empty:
 
-```
+```markdown
 ## Assumptions
 - None.
 ```
 
 When `open_questions` is absent:
 
-```
+```markdown
 ## Open questions
 - None.
 ```
@@ -132,7 +132,7 @@ When `open_questions` is absent:
 
 ## Example
 
-```
+```markdown
 # Plan: red-sce-banner
 
 Path: context/plans/red-sce-banner.md
 
@@ -13,11 +13,10 @@ This phase owns the planning process:
 - Decide task boundaries, dependencies, and ordering.
 - Write or revise exactly one `context/plans/{plan_name}.md`.
 
-`references/plan-template.md` is the sole owner of the persisted plan schema and
-generic document-authoring rules: acceptance-criteria format and validation
-semantics, task fields and atomic slicing, the no-validation-task rule, completion
-records, and existing-plan update preservation. Read it before authoring or
-revising and apply those rules rather than restating them here.
+`references/plan-template.md` is the sole owner of the persisted plan schema.
+Read its `Acceptance criteria rules`, `Task rules` and `No validation task` rules,
+and `Updating an existing plan` rules before authoring or revising. Apply those
+rules rather than restating them here.
 
 The workflow renders this phase's result as the summary defined in
 `references/output.md`.
@@ -162,8 +161,7 @@ semantics and placement.
 
 Slice and order the plan-specific work after the acceptance criteria, applying the
 `Task rules` and `No validation task` rules in `references/plan-template.md`.
-The template owns the task field shape, atomic-commit constraint, dependency-order
-rule, acceptance-coverage rule, and generic task exclusions.
+Do not restate those generic task rules here.
 
 A finished stack always leaves at least one incomplete task, so the workflow can
 always hand off to `/next-task`. When the request resolves to a plan but produces
 
@@ -10,7 +10,7 @@ description: >
 
 Write exactly one architecture decision record for one decision already qualified
 by successful task context synchronization. Return a deterministic internal
-handoff to the invoking synchronization phase. Do not render an independent
+result to the invoking synchronization phase. Do not render an independent
 user-visible response.
 
 ## Input
@@ -25,7 +25,7 @@ synchronization. It must identify:
 - Related current-state context and existing ADR paths.
 - An optional requested status.
 
-Do not accept raw workflow arguments, ordinary phase state, multiple decisions,
+Do not accept raw workflow arguments, ordinary phase result, multiple decisions,
 or direct user invocation. Do not reconstruct missing material facts.
 
 ## Qualification handoff
@@ -101,9 +101,9 @@ the filename, status, sections, and references satisfy this contract; every
 referenced repository path exists when practical to check; and no accepted ADR
 was modified.
 
-### 6. Return internal state
+### 6. Return the result
 
-Return exactly one internal handoff:
+Return exactly one internal result:
 
 - `written`: include `status`, `adr_path`, `decision`, `decision_status`,
   `created` (`true` for a new ADR and `false` for reuse), `supersedes`, and
@@ -115,7 +115,7 @@ Return exactly one internal handoff:
   `required_action`. Use this only when decision writing cannot proceed safely.
 
 Use stable field names and repository-relative paths. Return no prose before or
-after the handoff. The invoking synchronization phase owns all user-visible
+after the result. The invoking synchronization phase owns all user-visible
 reporting.
 
 ## Boundaries
 
@@ -5,8 +5,8 @@ Run this phase for step 3 of the workflow, and only when task execution returned
 session inherits what this task established. It never touches code, tests, or
 plan state.
 
-Input: either the complete `complete` result from the task execution phase
-(same-session), passed verbatim, or the plan path and task ID a plan-review
+Input: either the task execution result with `status: complete`
+(same-session), passed unchanged, or the plan path and task ID a plan-review
 recovery step resolved for a completed task with unresolved context synchronization, together with that task's own
 completed record — read directly from the plan — and its persisted `Context
 synchronization blocker` when present (cross-session retry). Whichever was
@@ -331,4 +331,4 @@ Do not:
   except `sce-decision`, or invoke `sce-decision` outside the decision gate in
   successful context synchronization.
 - Delete a context file that has uncommitted changes.
-- Return an execution-style internal state.
+- Return a task-execution internal result.
@@ -48,7 +48,7 @@ be synchronized before continuing.
 
 {completed-tasks} of {total-tasks} tasks complete.
 
-Next up:
+Next step:
 
 {next-task-id} — {next-task-title}
 
 
@@ -109,14 +109,14 @@ Set internal status `blocked` when a missing decision materially affects:
 
 ## 1.5 Return the result
 
-Set exactly one internal state:
+Return one internal result with one of these statuses:
 
 - `ready`
 - `blocked`
 - `plan_complete`
 - `sync_debt`
 
-Record only the internal state. Do not add explanatory prose before or after it.
+Return only the internal result. Do not add explanatory prose before or after it.
 
 A `ready` result must identify:
 
 
@@ -194,11 +194,11 @@ that decision after context synchronization.
 Before returning a `complete` result, verify that it satisfies the authoritative
 handoff contract above.
 
-## 2.9 Return internal state
+## 2.9 Return the result
 
-After the phase reaches a terminal state, set exactly one internal state.
+After the phase reaches a terminal state, return exactly one internal result.
 
-Record only the internal state. Do not add explanatory prose before or after it.
+Return only the internal result. Do not add explanatory prose before or after it.
 
 A `complete` result is the authoritative handoff into step 3. Pass it unchanged;
 step 3 must consume it instead of reconstructing its fields.
 
@@ -67,6 +67,6 @@ After repairs, rerun:
 - When status is `failed`, always include **Retry** with the exact
   `/validate {plan path}` command. Omit **Retry** when status is `validated`.
 - Keep evidence concise and factual. Do not narrate the whole implementation
-  history or add execution-policy claims absent from the validation result.
+  history or add execution-policy claims absent from the validation report.
 - When a previous `## Validation Report` already exists, replace it with the new
   one rather than stacking duplicates.
@@ -14,11 +14,11 @@ This phase owns:
   check.
 - Writing the Validation Report into the plan.
 - Marking acceptance criteria against the evidence.
-- Returning one Markdown validation result.
+- Returning one Markdown validation report.
 
 Return a result matching:
 
-the **Validation Result** section below in this file
+the **Validation report** section below in this file
 
 Write plan-file evidence matching:
 
@@ -109,7 +109,7 @@ Return exactly one Markdown report:
   passed, and the Validation Report was written.
 - `failed` when evidence was captured but required checks or criteria remain
   unsatisfied. Shape it as a session handoff per
-  the **Validation Result** section below in this file, ending recommended work with
+  the **Validation report** section below in this file, ending recommended work with
   `/validate {plan path}`.
 - `blocked` when validation cannot proceed safely.
 
@@ -140,7 +140,7 @@ The phase is complete after:
 - One plan was resolved, or resolution failed and was reported.
 - Implementation completeness was checked.
 - Validation ran to a terminal state, or a blocker prevented it.
-- One valid Markdown report matching the **Validation Result** section below in this file was
+- One valid Markdown report matching the **Validation report** section below in this file was
   returned.