Remove the standalone Plan phase

Author: Redwarx008

.agents/skills/act/SKILL.md

@@ -1,42 +1,44 @@
 ---
 name: act
-description: Executes an explicitly authorized workflow Plan, gathers criterion-matched evidence, stops on every unresolved implementation doubt, and launches independent review before completion. Use automatically after the active workflow's Plan records user authorization, or when continuing implementation or closing review findings.
+description: Implements an explicitly authorized Ready Design, keeps a factual execution record, stops on every unresolved implementation doubt, and launches independent review before completion. Use automatically after the active Design records user authorization, or when continuing implementation or closing review findings.
 ---
 
 # Workflow Act
 
-Execute the approved Plan without changing Design intent.
+Implement the approved Design without changing its intent. Choose mechanical execution order from repository facts; do not create a separate implementation Plan.
 
 ## Start
 
-Read active `design.md` and `plan.md` together. Confirm Design is Ready and Plan authorization is Approved. Inspect repository status and preserve unrelated user changes. If any precondition is false, stop.
+Read active `design.md`. Confirm Design is Ready, every coverage dimension is resolved or justified `N/A`, and `Implementation Authorization` is `Approved`. Inspect repository status and preserve unrelated user changes. If any precondition is false, stop.
+
+Create or update `execution.md` from [assets/execution.md](assets/execution.md). It records work already started or completed, evidence, doubts, and deviations; it must not become a speculative task plan.
 
 Read [references/doubt-protocol.md](references/doubt-protocol.md) before editing and use [references/validation-guide.md](references/validation-guide.md) throughout.
 
-## Task loop
+## Execution loop
 
-For each unchecked task in order:
+Until every Design success criterion is evidenced:
 
-1. Re-read its Design anchors, constraints, affected system, and required evidence.
-2. Investigate unclear repository facts read-only.
-3. Before any mutation, confirm every Plan-required validation entrypoint and prerequisite exists and can be invoked. Inspect command/script availability without substituting or weakening the validation. If an entrypoint is unavailable, stop before implementation and apply the doubt protocol.
-4. If uncertainty remains, apply the doubt protocol and wait for the user.
-5. Implement the smallest coherent change uniquely entailed by Design and Plan.
-6. Run the planned validation and record raw results in `plan.md`.
-7. Mark the task complete only after its required evidence exists.
+1. Select an unmet success criterion or required production integration obligation and re-read its Design decisions, constraints, affected system, and required evidence.
+2. Investigate unclear repository facts read-only. Choose the next mechanical execution step from the actual dependency graph; do not ask the user about uniquely determined ordering.
+3. Before mutation, confirm the Design-required validation entrypoint and prerequisites exist and can be invoked. If unavailable, stop before implementation and apply the doubt protocol.
+4. If any implementation choice is not uniquely fixed by Design and repository facts, apply the doubt protocol and wait for the user.
+5. Implement the smallest coherent change uniquely entailed by Design.
+6. Run the applicable validation and append the raw result and production-path evidence to `execution.md`.
+7. Mark a success criterion covered only after its required evidence exists. Record deviations immediately; any deviation that changes Design requires user confirmation before further mutation.
 
 Do not silently add dependencies, change APIs or formats, broaden scope, choose compatibility policy, introduce fallback behavior, skip evidence, or replace validation. Use required domain skills and follow the target project's version-control ownership rules.
 
-Do not add or modify tests unless the user explicitly requested test work. Existing tests may be run when the authorized Plan names them as validation.
+Do not add or modify tests unless the user explicitly requested test work. Existing tests may be run when the approved Design names them as validation.
 
 ## Review and closure
 
 After all tasks and agent-accessible validation finish:
 
-1. Launch an independent subagent with `$agent-workflow-kit:review`, passing only the active record, repository root, and raw validation entrypoints. Do not pass your conclusions or suspected gaps.
+1. Launch an independent subagent with `$agent-workflow-kit:review`, passing only `design.md`, `execution.md`, the repository root, and raw validation entrypoints. Do not pass your conclusions or suspected gaps.
 2. If review returns P0/P1 or an unmet criterion, fix only when the required correction is uniquely determined. Otherwise ask the user before editing.
 3. Ask the reviewer to re-check fixes until it returns `PASS`, or report a genuine `BLOCKED` decision/evidence dependency.
-4. Reconcile the Completion Record, final Design behavior, validation results, deviations, and review verdict.
+4. Reconcile `execution.md`, final Design behavior, validation results, deviations, and review verdict.
 5. Apply required session log/ADR/architecture/feature updates. Move the entire change folder from `workflow/active/` to `workflow/completed/` only after `PASS`.
 
 Never claim completion before independent `PASS`.

.agents/skills/act/agents/openai.yaml

@@ -1,7 +1,7 @@
 interface:
   display_name: "Workflow Act"
-  short_description: "Execute an authorized plan and stop on unresolved doubt"
-  default_prompt: "Use $act to execute the authorized plan with evidence and stop-on-doubt discipline."
+  short_description: "Implement an authorized Design and record real evidence"
+  default_prompt: "Use $act to implement the authorized Design, record execution evidence, and stop on unresolved doubt."
 
 policy:
   allow_implicit_invocation: true

.agents/skills/act/assets/execution.md

@@ -0,0 +1,23 @@
+# <change-name> Execution Record
+
+**Status:** Active
+
+## Design Success Criteria Coverage
+
+| Success criterion | Production path / change | Evidence | Result |
+| --- | --- | --- | --- |
+
+## Activity Log
+
+<!-- Record work when it starts or completes. Do not pre-populate future tasks. -->
+
+## Validation Evidence
+
+## Doubts and User Decisions During Act
+
+## Deviations from Design
+
+<!-- Write "None" only when implementation is complete and no deviation occurred. -->
+
+## Independent Review
+

.agents/skills/act/references/doubt-protocol.md

@@ -6,7 +6,7 @@ Use read-only inspection to resolve discoverable facts: repository code and docs
 
 ## Stop when uncertainty remains
 
-Stop before further mutation whenever there are multiple reasonable implementations or uncertainty about Design/Plan conflict, scope, API/format, compatibility, persistence, dependency choice, fallback behavior, validation substitution, failure handling, task ordering, or a reviewer finding.
+Stop before further mutation whenever there are multiple reasonable implementations or uncertainty about a Design conflict or omission, scope, API/format, compatibility, persistence, dependency choice, fallback behavior, validation substitution, failure handling, non-mechanical task ordering, or a reviewer finding.
 
 Tell the user:
 
@@ -17,4 +17,4 @@ Tell the user:
 
 Wait for the response. Until then, continue only safe read-only investigation. Do not implement the recommendation first.
 
-Mechanical details may proceed only when Design, Plan, and existing project patterns admit one safe interpretation. If you doubt uniqueness, stop.
+Mechanical details may proceed only when Design and existing project patterns admit one safe interpretation. If you doubt uniqueness, stop.

.agents/skills/act/references/validation-guide.md

@@ -6,6 +6,6 @@
 - Editor/UI interaction: existing deterministic checks where useful, plus explicit manual interaction/appearance checks; create test coverage only when explicitly requested.
 - Resource/version-control changes: follow the target project's ownership rules and record the relevant revision/signature.
 
-If planned evidence cannot be obtained, do not silently substitute a weaker check. Stop and ask the user.
+If Design-required evidence cannot be obtained, do not silently substitute a weaker check. Stop and ask the user.
 
-Before modifying implementation files, verify that every Plan-required validation command, script, tool, fixture, and required external input is present and invocable. This availability preflight does not replace the post-change validation. If availability cannot be established, stop before mutation.
+Before modifying implementation files, verify that every Design-required validation command, script, tool, fixture, and required external input is present and invocable. This availability preflight does not replace the post-change validation. If availability cannot be established, stop before mutation.

.agents/skills/design/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: design
-description: Explores a change against the real repository and maintains a living, decision-complete Design before implementation planning. Use only when the user explicitly invokes $agent-workflow-kit:design; never start the workflow automatically from task complexity, risk, or ambiguity.
+description: Explores a change against the real repository and maintains a living, decision-complete Design before authorized implementation. Use only when the user explicitly invokes $agent-workflow-kit:design; never start the workflow automatically from task complexity, risk, or ambiguity.
 ---
 
 # Workflow Design
 
-Turn an emerging change into a Ready Design through repository-grounded discussion. Do not plan implementation tasks or modify product code in this phase.
+Turn an emerging change into a Ready Design through repository-grounded discussion. Do not create an implementation task sequence or modify product code in this phase.
 
 ## Start
 
@@ -26,7 +26,7 @@ Work through the unresolved Design Coverage dimensions in dependency order. Do n
 4. Ask only for the remaining choice, one question at a time. A technical recommendation is not permission to choose for the user.
 5. Immediately update the affected Design section, `Decisions`, `Open Questions`, and Design Coverage status after each material resolution.
 
-Design-level implementation mechanics include algorithms, state transitions, ownership, dependencies, integration points, and how existing production paths will consume the change. Decide these before Plan; leave file-by-file task sequencing and command execution to Plan.
+Design-level implementation mechanics include algorithms, state transitions, ownership, dependencies, integration points, and how existing production paths will consume the change. Decide these before Act. Do not prescribe a file-by-file task sequence; Act may choose mechanical execution order from the current repository.
 
 Reject unrelated refactors and speculative requirements. If a question is inherently visual, follow [references/visual-companion.md](references/visual-companion.md). Offer the companion just in time and start it only after explicit consent.
 
@@ -38,6 +38,7 @@ When the gate passes:
 
 1. Set Design status to `Ready` and write `Open Questions: None`.
 2. Briefly tell the user why discussion is complete.
-3. Invoke `$agent-workflow-kit:plan` directly. There is no separate Design approval gate.
+3. Ask for explicit implementation authorization. Do not modify product code while waiting.
+4. After the user authorizes implementation, set `Implementation Authorization: Approved` in `design.md` and invoke `$agent-workflow-kit:act` directly.
 
-The only terminal state is transition to Workflow Plan.
+The only terminal state is transition to Workflow Act after explicit authorization.

.agents/skills/design/agents/openai.yaml

@@ -1,7 +1,7 @@
 interface:
   display_name: "Workflow Design"
   short_description: "Explore and record a decision-complete change design"
-  default_prompt: "Use $design to explore this change and maintain its living Design before planning."
+  default_prompt: "Use $design to explore this change and maintain its living Design before authorized implementation."
 
 policy:
   allow_implicit_invocation: false

.agents/skills/design/assets/design.md

@@ -1,6 +1,7 @@
 # <change-name> Design
 
 **Status:** Exploring
+**Implementation Authorization:** Pending
 
 ## Summary
 

.agents/skills/design/references/design-contract.md

@@ -19,7 +19,7 @@ Design is Ready only when all are true:
 - Relevant current implementation and references have been inspected.
 - Every Design Coverage row is `Resolved` or a justified `N/A`; none is merely inferred from a filled heading.
 - Architecture boundaries, components and responsibilities, interfaces/contracts, data ownership and flow, implementation mechanics and integration points, failure/edge/compatibility behavior, and validation are defined or explicitly not applicable.
-- The implementation approach fixes the mechanisms and production integration path strongly enough that Plan does not need to invent architecture, ownership, contracts, algorithms, or compatibility policy. Plan may still choose task decomposition and execution order.
+- The implementation approach fixes the mechanisms and production integration path strongly enough that Act does not need to invent architecture, ownership, contracts, algorithms, or compatibility policy. Act may choose only mechanical execution order from repository facts.
 - Every design choice with multiple viable approaches records the compared approaches, causal tradeoffs, recommendation, and user decision. Do not manufacture alternatives when repository evidence leaves only one valid approach.
 - Success criteria are observable and testable with the chosen evidence type.
 - Every implementation-shaping decision is recorded and no such question remains open.