feat(sldd): require draft artifact approval gates

README.md

@@ -133,6 +133,8 @@ Workflow completion is defined by `kind`:
 
 SLDD uses this kind-specific completion rule when filtering active workflows, validating predecessor gates, and resolving `/sldd resume`.
 
+For Markdown-producing steps, saved artifacts are reviewable drafts until the owning step is explicitly approved and marked `complete` in `_spec-journal.json`. Saving a draft is persistence; approval is gate advancement.
+
 For `/sldd resume` without a workflow name, SLDD:
 
 1. Finds all journals under `.sldd/specs/*/_spec-journal.json`.
@@ -169,7 +171,7 @@ Formal gate order is:
 01 -> 99 when needed -> 02 -> 03 -> 04 -> 05 -> 06
 ```
 
-Step 99 is required before Step 02 for existing codebases. It may run during Step 88 when brownfield context is needed, but it satisfies the gate only after `existing-codebase-understanding.md` is approved, saved, current, and marked complete.
+Step 99 is required before Step 02 for existing codebases. It may run during Step 88 when brownfield context is needed, but it satisfies the gate only after the current `existing-codebase-understanding.md` draft is explicitly approved, saved, current, and marked complete. A saved Step 99 draft may exist while the step remains `pending`.
 
 Feature step files:
 
@@ -188,6 +190,8 @@ Feature step files:
 Core feature rules:
 
 - No implementation prompts or code changes before Step 01, Step 02, and Step 03 are approved.
+- Markdown-producing steps save reviewable draft artifacts before approval, but artifact existence never satisfies a gate; only `status: "complete"` does.
+- Revision or rejection updates the draft and keeps the step pending; explicit approval of the current draft marks the step complete and allows routing forward.
 - Step 88 context is conversational and non-binding unless formalized into approved numbered artifacts.
 - Step 04 writes tests first and must stay Red-only.
 - Step 05 makes the minimum production changes needed to pass Step 04 tests and must not modify Step 04 tests.
@@ -230,7 +234,7 @@ Workflow-set parent steps:
 
 Workflow-set parents plan and scaffold children. They do not execute child workflows, approve child Step 01, enforce child implementation gates, or persist child execution progress.
 
-Creating or updating a workflow-set parent requires explicit approval. A new parent journal is created only through `01-workflow-set-plan`. Existing journals without `name` or `kind` are invalid and must be corrected before routing. Existing `kind: "feature"` journals stop the workflow-set path unless the user chooses another workflow-set name or gives explicit direction.
+Creating or updating a workflow-set parent plan starts by saving a reviewable `01-workflow-set-plan.md` draft. For a new workflow-set parent, draft persistence does not create `_spec-journal.json`; the parent journal is created only after explicit approval of the current plan draft, which marks `01-workflow-set-plan` complete. Existing parent journals may keep pending draft links during revision, but artifact existence never approves the plan or authorizes scaffolding. Existing journals without `name` or `kind` are invalid and must be corrected before routing. Existing `kind: "feature"` journals stop the workflow-set path unless the user chooses another workflow-set name or gives explicit direction.
 
 Child scaffolding requires:
 
@@ -283,6 +287,8 @@ Workflow-set parents also use:
 
 Workflow-set Step 03 does not write a separate verification artifact. Scaffolded child workflows write their own `01-product-intent-specification.md` from `templates/01-product-intent-from-workflow-set.md`.
 
+During review, any Markdown artifact above may exist as a draft while its journal step remains `pending`. Draft artifacts are intentionally persisted for review; they are not evidence of gate completion.
+
 Child workflows scaffolded from a workflow-set get their own `.sldd/specs/<child-name>/` directory and journal.
 
 Legacy `docs/specs/<feature-name>/SPEC.md` files are not `_spec-journal.json` files and do not satisfy the current journal contract.
@@ -291,6 +297,8 @@ Legacy `docs/specs/<feature-name>/SPEC.md` files are not `_spec-journal.json` fi
 
 `_spec-journal.json` is journal-only state. It records progress, artifact links, evidence, relationships, workflow kind, reasons, notes, and workflow-set scaffold state. It must not contain numbered artifact body content, command logs, or implementation reports.
 
+A pending Markdown-producing step may include `artifact: "<file>.md"` and `reason: "draft pending explicit approval"` or an equivalent blocker reason. This records a reviewable draft only; the gate remains closed until that step has `status: "complete"`. New workflow-set parent drafts are the exception: `01-workflow-set-plan.md` may be saved before `_spec-journal.json` exists, because parent journal creation itself waits for explicit plan approval.
+
 Required top-level fields in the current schema:
 
 | Field | Contract |
@@ -315,7 +323,7 @@ complete
 requires_rerun
 ```
 
-Step entries may include `artifact`, `evidence`, `reason`, `updated_at`, and `origin`. `origin.type` is currently used for `workflow-set-scaffold`.
+Step entries may include `artifact`, `evidence`, `reason`, `updated_at`, and `origin`. `artifact` may point to either a pending draft or an approved artifact, so gate checks must read `status`, not infer completion from the file. `origin.type` is currently used for `workflow-set-scaffold`.
 
 Workflow-set child entries require `name`, `title`, `kind`, and `scaffold`. Child `kind` is always `feature`. Scaffold state is one of:
 
@@ -356,6 +364,7 @@ Option 1 is an explicit override. Option 2 marks later completed steps in the se
 - Preserve `/sldd resume` active-workflow selection: exclude complete workflows, filter blocked workflows by predecessors, auto-resume exactly one unblocked active workflow, otherwise ask or report blockers.
 - Preserve `/sldd help` as informational and non-mutating.
 - Preserve the Step 88/Step 99 boundary: exploration context is conversational; Step 99 is approved, saved brownfield context.
+- Preserve the draft artifact approval policy: saving a draft is persistence; explicit approval and `status: "complete"` are gate advancement.
 - Preserve the Step 04/Step 05 Red-Green contract.
 - Preserve workflow-set parent sequencing: `01-workflow-set-plan -> 02-scaffold-children -> 03-verify-workflow-set`.
 - Preserve workflow-set parent boundaries: parents do not execute children or persist child progress.

skills/sldd/SKILL.md

@@ -50,6 +50,14 @@ Legacy `docs/specs/<feature-name>/SPEC.md` files are not `_spec-journal.json` fi
 
 Use `_spec-journal.json` as journal-only state. It records the workflow name, progress, artifact links, evidence, relationships, workflow kind, and rerun notes. It must not contain numbered artifact body content, command logs, or implementation reports.
 
+### Draft Artifact Gate Policy
+
+For steps that produce Markdown artifacts, saving the artifact is draft persistence, not gate approval. Save or update the generated Markdown artifact as a reviewable draft before asking for explicit gate approval. When a journal exists or the workflow permits draft journal state, keep the step `pending` in `_spec-journal.json` with the artifact link and a concise reason such as `draft pending explicit approval`.
+
+A Markdown artifact's existence never satisfies a gate. A gate is satisfied only when the relevant journal step has `status: "complete"` and all workflow-specific prerequisites are valid. On revision requests or rejection, update the draft artifact and keep the step `pending`; do not route forward. On explicit approval of the current draft, mark the step `complete` with the same artifact link unless another gate rule, such as an incomplete predecessor, still blocks completion.
+
+Keep `_spec-journal.json` journal-only during draft persistence and approval. Do not store artifact body content, command logs, or reports in the journal. Step 04 and Step 05 remain evidence phases, not mandatory Markdown artifact phases. Step 88 remains non-mutating by default; saving `00-exploration-summary.md` still requires explicit approval and does not satisfy numbered gates.
+
 Every `_spec-journal.json` must include `name` and `kind`. `name` is the workflow/spec name. Journals without `name` or `kind` are invalid and must not be routed, resumed, or treated as `feature`.
 
 Do not use `feature` as a top-level journal field. `feature` remains only the workflow kind value `kind: "feature"` and the feature workflow concept.
@@ -118,6 +126,8 @@ Allowed step statuses:
 - `complete`
 - `requires_rerun`
 
+A `pending` step may include an `artifact` link to a saved draft and a `reason` such as `draft pending explicit approval`; that link is review context only and does not satisfy the gate. New workflow-set parent journals are the exception: draft plan persistence may save `01-workflow-set-plan.md` without creating `_spec-journal.json` until explicit plan approval.
+
 Step 04 (`04-tests-red`) completion requires `evidence: "red_confirmed"`. Step 05 (`05-implementation-green`) completion requires `evidence: "green_confirmed"`. For Step 04 and Step 05, non-complete statuses must omit `evidence` or set it to `null`.
 
 If a journal has `relationships.predecessors`, every listed predecessor journal must exist and have Step 06 complete before this workflow can mark Step 01 complete or route to Step 02+.
@@ -133,7 +143,7 @@ When the journal exists:
 When no journal exists:
 
 1. Detect the initial workflow kind from the user's intent.
-2. Persist the detected `kind` in the new journal after the required workflow approval path allows journal creation.
+2. Persist the detected `kind` in the new journal when the selected workflow's draft or approval path allows journal creation.
 3. Load exactly one workflow file:
    - `workflows/feature.md` for `kind: "feature"`
    - `workflows/workflow-set.md` for `kind: "workflow-set"`
@@ -170,6 +180,8 @@ Slash commands are convenience syntax only. Always enforce the same gates, journ
 5. Load exactly one step file from the selected workflow's `steps/<kind>/` step map.
 6. Load a template only when that step produces or updates the matching Markdown artifact.
 
+When a loaded step produces a Markdown artifact, apply the Draft Artifact Gate Policy: save or update the reviewable draft, keep the step `pending`, request explicit approval, and advance only after the journal step becomes `complete`.
+
 For `/sldd run step <step-id>`, stop before loading a completed step and ask whether to:
 
 1. Run it again only.

skills/sldd/steps/feature/00-navigation.md

@@ -25,7 +25,7 @@ Expected new-workflow artifacts:
 - `05-implementation-green` completion in `_spec-journal.json` with `evidence: "green_confirmed"`
 - `06-verification-and-feedback-report.md`
 
-Approved numbered artifacts take precedence over `00-exploration-summary.md`.
+Approved numbered artifacts take precedence over `00-exploration-summary.md`. A numbered Markdown artifact may exist as a pending draft; only the journal step `status: "complete"` makes it approved for routing.
 
 ## Start/Resume Flow
 
@@ -82,7 +82,7 @@ When the command is `/sldd run step <step-id> <feature>`, `/sldd run step <step-
 9. If prerequisite artifacts, predecessor completion, journal order, Step 99 freshness, Step 04 evidence, or Step 05 evidence conflict, stop and report the conflict instead of loading the requested step.
 10. If prerequisites are missing or stale, route to the missing prerequisite instead of loading the requested step.
 11. If the target step is `pending`, load the requested step file only when its gates are satisfied.
-12. If the target step is `requires_rerun`, load the requested step file only when its gates are satisfied. After it completes through its normal approval or confirmation flow, mark later completed steps in gate order as `requires_rerun`.
+12. If the target step is `requires_rerun`, load the requested step file only when its gates are satisfied. After it completes through its normal draft and approval or confirmation flow, mark later completed steps in gate order as `requires_rerun`.
 
 If the target step is already `complete`, stop before loading the step and ask:
 
@@ -100,7 +100,7 @@ Step <step-id> is already complete.
 After the user chooses:
 
 1. For option 1, run the step only after explicit confirmation. Do not automatically invalidate later completed steps. If the target step artifact, files, or journal entry changes, add a journal-only note: `Step <step-id> was run again without downstream invalidation by explicit user choice.`
-2. For option 2, run the step only after explicit confirmation. After the target step completes through its normal approval or confirmation flow, mark later completed steps in gate order as `requires_rerun`.
+2. For option 2, run the step only after explicit confirmation. After the target step completes through its normal draft and approval or confirmation flow, mark later completed steps in gate order as `requires_rerun`.
 3. For each invalidated later step, set `reason` to `Step <step-id> was run again; this later step must be reviewed again.`
 4. When invalidating Step 04 or Step 05, clear `evidence`; keep any existing `artifact` link as a historical reference.
 5. For option 3, do not load the step, write artifacts, run commands, or update the journal.

skills/sldd/steps/feature/01-product-intent.md

@@ -23,26 +23,36 @@ For a child workflow scaffolded from a workflow-set, use the existing Step 01 dr
 
 If any predecessor is missing or incomplete, Step 01 may be drafted, saved, reviewed, or revised, but it must remain `pending` with a `reason` explaining the predecessor gate. Do not route to Step 02+.
 
-Wait for approval.
+Save the draft for review, keep the step pending, then wait for explicit approval.
 
 ## Approval Protocol
 
-- Save or update artifacts only after explicit approval.
-- On rejection, requested changes, hold, or ambiguous approval, do not persist progress; clarify or wait.
+- Save or update the Step 01 artifact as a reviewable draft before gate approval.
+- Draft persistence must keep `01-product-intent` as `pending` in `_spec-journal.json`, preserve the artifact link, and set `reason` to `draft pending explicit approval` or a more specific blocking reason.
+- The existence of `01-product-intent-specification.md` does not satisfy the Step 01 gate.
+- On rejection, requested changes, hold, or ambiguous approval, update the draft when needed, keep the step pending, and do not route to Step 02+.
+- Only explicit approval of the current draft may mark Step 01 complete, and predecessor gates may still keep it pending.
 - If writes are unavailable, stop and report the limitation.
 
-## Save Flow After Approval
+## Draft Save Flow
 
 1. Save only Step 01 content to the resolved workflow directory as `01-product-intent-specification.md`; for new workflows, this is `.sldd/specs/<feature-name>/01-product-intent-specification.md`.
+2. Create or update journal-only `_spec-journal.json` with required top-level fields (`schema_version`, `name`, `workflow: "sldd"`, `kind: "feature"`) when needed.
+3. Set `steps["01-product-intent"].status: "pending"`, preserve the artifact link, and set `reason` to `draft pending explicit approval` unless a predecessor gate requires a more specific reason.
+4. Ask for explicit approval, revision requests, or hold.
+
+## Gate Approval Flow
+
+1. On explicit approval of the current draft, verify predecessor gates again.
 2. If `relationships.predecessors` exists and any predecessor is missing or incomplete, keep `01-product-intent` as `pending`, preserve the artifact link, set `reason` to the predecessor-gate explanation, and route to the incomplete predecessor instead of continuing.
 3. Otherwise, mark `01-product-intent` as `complete` in journal-only `_spec-journal.json` with the artifact link.
 4. Ask whether to continue to the next step or hold.
 
-For legacy or user-provided workflow paths, save and update progress in the resolved directory instead.
+For legacy or user-provided workflow paths, save the draft and update progress in the resolved directory instead.
 
 ## Response Format
 
 1. Gate and resume check result
-2. Draft summary with required Step 01 headings
-3. Approval request
-4. Continue/hold prompt
+2. Saved draft summary with required Step 01 headings
+3. Pending journal update and explicit approval request
+4. Continue/hold prompt after approval, or revision/hold prompt while pending

skills/sldd/steps/feature/02-high-level-design.md

@@ -22,25 +22,33 @@ If Step 99 was completed before Step 01, verify that its saved context still fit
 
 Trace approved Step 01 requirements, including formalized exploration outcomes, into architecture, responsibilities, data flow, security/observability, trade-offs, and high-level test scenarios.
 
-Wait for approval.
+Save the draft for review, keep the step pending, then wait for explicit approval.
 
 ## Approval Protocol
 
-- Save or update artifacts only after explicit approval.
-- On rejection, requested changes, hold, or ambiguous approval, do not persist progress; clarify or wait.
+- Save or update the Step 02 artifact as a reviewable draft before gate approval.
+- Draft persistence must keep `02-high-level-design` as `pending` in `_spec-journal.json`, preserve the artifact link, and set `reason` to `draft pending explicit approval` or an equivalent review reason.
+- The existence of `02-high-level-technical-design.md` does not satisfy the Step 02 gate.
+- On rejection, requested changes, hold, or ambiguous approval, update the draft when needed, keep the step pending, and do not route to Step 03+.
+- Only explicit approval of the current draft may mark Step 02 complete.
 - If writes are unavailable, stop and report the limitation.
 
-## Save Flow After Approval
+## Draft Save Flow
 
 1. Save only Step 02 content to the resolved workflow directory as `02-high-level-technical-design.md`; for new workflows, this is `.sldd/specs/<feature-name>/02-high-level-technical-design.md`.
-2. Mark `02-high-level-design` as `complete` in journal-only `_spec-journal.json` with the artifact link.
-3. Ask whether to continue to the next step or hold.
+2. Update journal-only `_spec-journal.json` with `steps["02-high-level-design"].status: "pending"`, the artifact link, and `reason: "draft pending explicit approval"`.
+3. Ask for explicit approval, revision requests, or hold.
 
-For legacy or user-provided workflow paths, save and update progress in the resolved directory instead.
+## Gate Approval Flow
+
+1. On explicit approval of the current draft, mark `02-high-level-design` as `complete` in journal-only `_spec-journal.json` with the artifact link.
+2. Ask whether to continue to the next step or hold.
+
+For legacy or user-provided workflow paths, save the draft and update progress in the resolved directory instead.
 
 ## Response Format
 
 1. Gate and resume check result
-2. Draft summary with required Step 02 headings
-3. Approval request
-4. Continue/hold prompt
+2. Saved draft summary with required Step 02 headings
+3. Pending journal update and explicit approval request
+4. Continue/hold prompt after approval, or revision/hold prompt while pending