gsdd-cli 0.19.0 → 0.19.2

package/distilled/workflows/new-project.md

@@ -20,7 +20,7 @@ When `autoAdvance: true`, this workflow runs non-interactively:
 
 5. **Keep quality gates:** All quality checks in `<spec_creation>` and `<roadmap_creation>` still apply. Thoroughness is preserved; only user wait-points are removed.
 
-6. **After completion:** Report what was created and any assumptions inferred from the brief. Do NOT auto-advance to planning — the user or CI system decides when to start planning.
+6. **After completion:** Report what was created and any assumptions inferred from the brief. Do NOT auto-progress into plan, execute, verify, release, or delivery. The user or CI system must start any later lifecycle workflow explicitly.
 
 All other sections (`<detect_mode>`, `<codebase_context>`, `<research>`, `<spec_creation>`, `<roadmap_creation>`, `<success_criteria>`) execute normally. Auto mode bypasses: the `<questioning>` section, both `<approval_gate>` blocks, the user question in `<project_principles>`, and the user question in `<capability_gates>`. All other workflow logic executes normally.
 </auto_mode>
@@ -33,8 +33,8 @@ Before starting, read these files (if they exist):
 4. Project root files: `package.json`, `README.md`, main entry point, `.gitignore`
 5. `.planning/config.json` — The deterministic project settings. Key fields:
    - `researchDepth`: balanced | fast | deep — controls research thoroughness
-   - `parallelization`: true | false � whether to run delegate work in parallel when the platform supports it; when false, run the same delegates sequentially
-   - `workflow.research`: true | false — whether to do SOTA research before spec
+   - `parallelization`: true | false - whether to run delegate work in parallel when the platform supports it; when false, run the same delegates sequentially
+   - `workflow.research`: true | false - whether to do domain research before spec
    - `workflow.planCheck`: true | false — whether plan-check agent runs later
    - `workflow.verifier`: true | false — whether verifier runs after execution
    - `modelProfile`: balanced | quality | budget — model selection hint
@@ -44,7 +44,6 @@ Before starting, read these files (if they exist):
 </load_context>
 
 <project_principles>
-**(SOTA Insight: Derived from Spec-Kit)**
 Before diving into technical specifications, establish the core governing principles of the project.
 If `autoAdvance: true` in `.planning/config.json`, skip this question. Infer core principles
 from the project brief (code quality signals, constraint language, scope decisions) and note
@@ -161,7 +160,7 @@ Before creating a spec, you MUST have clear answers to:
 - **3-5 rounds minimum** for non-trivial projects
 
 ### Categorizing Requirements (Crucial)
-As the user provides answers, you must mentally categorize the features they request using the SOTA framework:
+As the user provides answers, you must mentally categorize the features they request:
 1. **Table Stakes**: Features users absolutely expect. Without them, your product feels broken (e.g., password reset).
 2. **Differentiators**: Features that set this project apart from competitors.
 3. **Out of Scope**: Explicit anti-requirements for v1 to prevent scope creep.
@@ -202,28 +201,27 @@ MANDATORY STEP. After the goal is clarified but BEFORE writing any specs.
 
 **Check config first:** Read `.planning/config.json`.
 - If `workflow.research: false` → skip this section entirely, go to `<spec_creation>`.
-- If `researchDepth: "fast"` � use the same 4 specialists below, then synthesize `SUMMARY.md` inline. Faster and cheaper; acceptable for well-known domains.
-- If `researchDepth: "balanced"` or `"deep"` � use the same 4 specialists below plus the synthesizer (default).
+- If `researchDepth: "fast"` - use the same 4 specialists below, then synthesize `SUMMARY.md` inline. Faster and cheaper; acceptable for well-known domains.
+- If `researchDepth: "balanced"` or `"deep"` - use the same 4 specialists below plus the synthesizer (default).
 
-### Why Parallel Specialists, Not One Generalist
-**(SOTA: Anthropic Agent Teams, OpenAI Multi-Agents — 90.2% performance improvement for complex research tasks)**
+### Why Specialists, Not One Generalist
 
 DO NOT research in this main thread — noisy intermediate output pollutes the context window.
 DO NOT use a single generalist to write all research files — domain switching degrades quality.
 
 Use the same 4 specialized researchers every time. The difference is execution order and synthesis mode.
-- If `parallelization: true` and your platform supports parallel execution (`run_in_background=true`, async tasks, etc.) � run all 4 simultaneously.
-- If `parallelization: false` or your platform lacks parallel execution � run the same 4 researchers sequentially.
-- If `researchDepth: "fast"` � synthesize inline after the 4 researcher outputs return.
-- If `researchDepth: "balanced"` or `"deep"` � use the synthesizer delegate after the 4 researcher outputs are written.
+- If `parallelization: true` and your platform supports parallel execution (`run_in_background=true`, async tasks, etc.) - run all 4 simultaneously.
+- If `parallelization: false` or your platform lacks parallel execution - run the same 4 researchers sequentially.
+- If `researchDepth: "fast"` - synthesize inline after the 4 researcher outputs return.
+- If `researchDepth: "balanced"` or `"deep"` - use the synthesizer delegate after the 4 researcher outputs are written.
 
 
 ```
-◆ Spawning 4 researchers in parallel...
-  → Stack research        → .planning/research/STACK.md
-  → Features research     → .planning/research/FEATURES.md
-  → Architecture research → .planning/research/ARCHITECTURE.md
-  → Pitfalls research     → .planning/research/PITFALLS.md
+Spawning 4 researchers...
+  -> Stack research        -> .planning/research/STACK.md
+  -> Features research     -> .planning/research/FEATURES.md
+  -> Architecture research -> .planning/research/ARCHITECTURE.md
+  -> Pitfalls research     -> .planning/research/PITFALLS.md
 ```
 
 Ensure `.planning/research/` directory exists before spawning.
@@ -234,7 +232,7 @@ Parallel: (use parallelization value from .planning/config.json)
 Context: Project goal: [user's stated goal]. Milestone context: [greenfield|subsequent]. DO NOT share conversation history.
 Instruction: Read `.planning/templates/delegates/researcher-stack.md` for full task instructions. Apply the project goal and milestone context provided above.
 Output: `.planning/research/STACK.md`
-Return: 3-5 sentence summary to Orchestrator.
+Return: 3-5 sentence summary to Orchestrator; full findings stay in the output artifact.
 Guardrails: Max Agent Hops = 3.
 </delegate>
 
@@ -244,7 +242,7 @@ Parallel: (use parallelization value from .planning/config.json)
 Context: Project goal: [user's stated goal]. Milestone context: [greenfield|subsequent]. DO NOT share conversation history.
 Instruction: Read `.planning/templates/delegates/researcher-features.md` for full task instructions. Apply the project goal and milestone context provided above.
 Output: `.planning/research/FEATURES.md`
-Return: 3-5 sentence summary to Orchestrator.
+Return: 3-5 sentence summary to Orchestrator; full findings stay in the output artifact.
 Guardrails: Max Agent Hops = 3.
 </delegate>
 
@@ -254,7 +252,7 @@ Parallel: (use parallelization value from .planning/config.json)
 Context: Project goal: [user's stated goal]. Milestone context: [greenfield|subsequent]. DO NOT share conversation history.
 Instruction: Read `.planning/templates/delegates/researcher-architecture.md` for full task instructions. Apply the project goal and milestone context provided above.
 Output: `.planning/research/ARCHITECTURE.md`
-Return: 3-5 sentence summary to Orchestrator.
+Return: 3-5 sentence summary to Orchestrator; full findings stay in the output artifact.
 Guardrails: Max Agent Hops = 3.
 </delegate>
 
@@ -264,14 +262,14 @@ Parallel: (use parallelization value from .planning/config.json)
 Context: Project goal: [user's stated goal]. Milestone context: [greenfield|subsequent]. DO NOT share conversation history.
 Instruction: Read `.planning/templates/delegates/researcher-pitfalls.md` for full task instructions. Apply the project goal and milestone context provided above.
 Output: `.planning/research/PITFALLS.md`
-Return: 3-5 sentence summary to Orchestrator.
+Return: 3-5 sentence summary to Orchestrator; full findings stay in the output artifact.
 Guardrails: Max Agent Hops = 3.
 </delegate>
 
 **After all 4 researchers complete**, synthesize based on `researchDepth`:
 
 **If `researchDepth: "fast"`:** Synthesize inline.
-You hold 4 × 3-5 sentence summaries. Write `.planning/research/SUMMARY.md` directly using `.planning/templates/research/summary.md`. Cross-reference the summaries. Do NOT spawn another agent.
+You hold 4 x 3-5 sentence summaries. Write `.planning/research/SUMMARY.md` directly using `.planning/templates/research/summary.md`. Cross-reference the summaries. Do NOT spawn another agent.
 
 **If `researchDepth: "balanced"` or `"deep"`:** Spawn synthesizer to read the full research files.
 
@@ -281,7 +279,7 @@ Parallel: false
 Context: Researcher summaries returned above. DO NOT share conversation history.
 Instruction: Read `.planning/templates/delegates/researcher-synthesizer.md` for full task instructions.
 Output: `.planning/research/SUMMARY.md`
-Return: 5-7 bullet key findings to Orchestrator.
+Return: 5-7 bullet key findings to Orchestrator; full synthesis stays in the output artifact.
 Guardrails: Max Agent Hops = 2. Do not do new research — synthesize only.
 </delegate>
 
@@ -293,7 +291,7 @@ Display key findings before moving to spec creation.
 - [ ] All 4 specialist files written to `.planning/research/`
 - [ ] SUMMARY.md written with "Implications for Roadmap" section populated
 - [ ] Negative claims verified with current web docs (not training data)
-- [ ] Confidence levels assigned: ✅ verified, ⚠️ likely, ❓ uncertain
+- [ ] Confidence levels assigned: verified | likely | uncertain
 
 **Commit**: `docs: add domain research`
 </research>
@@ -301,7 +299,7 @@ Display key findings before moving to spec creation.
 **STOP. Research is complete. Do NOT write any application code. Proceed to spec creation below. Your job now is to produce SPEC.md and ROADMAP.md — not to build the project.**
 
 <data_schema_definition>
-Before writing SPEC.md, define core Data Models/Typed Schemas *(SOTA: GitHub Blog — "Multi-agent workflows often fail")*. Multi-agent systems require typed schemas to pass reliable state. These schemas MUST be included in SPEC.md (see item 7 in `<spec_creation>` below). Also define Done-When verification criteria for every requirement (see item 8). *SPEC.md defines WHAT, not HOW — do not include implementation tasks.*
+Before writing SPEC.md, define core Data Models/Typed Schemas. Multi-agent handoffs require typed schemas to pass reliable state. These schemas MUST be included in SPEC.md (see item 7 in `<spec_creation>` below). Also define Done-When verification criteria for every requirement (see item 8). *SPEC.md defines WHAT, not HOW - do not include implementation tasks.*
 </data_schema_definition>
 
 <spec_creation>
@@ -312,15 +310,14 @@ After the subagent research completes, synthesize EVERYTHING into `SPEC.md`:
 3. **Requirements have IDs**: `AUTH-01`, `DATA-02`, `UI-03`
 4. **Requirements are ordered** by priority within each category
 5. **Out of Scope is populated** — includes things the developer explicitly said "not now" AND anti-features found in Research.
-6. **Key Decisions are logged** — any choices made during questioning or dictated by the SOTA research.
-7. **Typed Data Schemas** *(SOTA: GitHub Blog — "Multi-agent workflows often fail")*: explicitly define the core Data Models/Typed Schemas the project will use (e.g., `type UserProfile = { id: number; plan: 'free' | 'pro' }`). Multi-agent systems require typed schemas to pass reliable state; natural language instructions fail across agent handoffs. *SPEC.md defines WHAT, not HOW — do not include implementation tasks.*
-8. **Done-When Verification Chain** *(SOTA: Cyanluna)*: For EVERY requirement in the "Must Have (v1)" section, define a clear, verifiable `[Done-When: ...]` criterion. "User can log in" must become "User can log in [Done-When: Login form submits, JWT is received, and User is redirected to Dashboard]". No exceptions.
+6. **Key Decisions are logged** — any choices made during questioning or dictated by the research.
+7. **Typed Data Schemas**: explicitly define the core Data Models/Typed Schemas the project will use (e.g., `type UserProfile = { id: number; plan: 'free' | 'pro' }`). Multi-agent handoffs require typed schemas to pass reliable state; natural language instructions fail across agent handoffs. *SPEC.md defines WHAT, not HOW - do not include implementation tasks.*
+8. **Done-When Verification Chain**: For EVERY requirement in the "Must Have (v1)" section, define a clear, verifiable `[Done-When: ...]` criterion. "User can log in" must become "User can log in [Done-When: Login form submits, JWT is received, and User is redirected to Dashboard]". No exceptions.
 9. **Capability & Security Gates**: Handle per the `<capability_gates>` section at the end of this `<spec_creation>` block.
 10. **Authorization Matrix (optional)**: For projects with multiple user roles or protected resources, create `.planning/AUTH_MATRIX.md` using the template at `.planning/templates/auth-matrix.md`. The integration checker will use this matrix for systematic auth verification during milestone audits.
 11. **ROADMAP phase status is initialized** with Phase 1 marked `[ ]` / not started using the roadmap template's phase-status language.
 
 <capability_gates>
-**(SOTA Insight: Derived from OpenFang - "16 Security Systems & Capability Gates")**
 Before finishing SPEC.md, explicitly define what the agents are NOT allowed to do automatically without human approval.
 If `autoAdvance: true`, skip this question. Add a deferred placeholder to SPEC.md:
 "## Capability & Security Gates\n_Deferred — auto mode cannot elicit gate preferences; requires explicit review before production deployment._"
@@ -410,7 +407,7 @@ Init is DONE when ALL of these are true:
 
 - [ ] Codebase audit completed (brownfield) OR greenfield confirmed
 - [ ] Developer was questioned in depth (3+ rounds for non-trivial projects) — [interactive only; skip when autoAdvance: true]
-- [ ] Research subagent spawned and SOTA patterns retrieved
+- [ ] Research subagent spawned and domain patterns retrieved
 - [ ] `SPEC.md` exists with testable requirements, out-of-scope, and current state
 - [ ] SPEC.md was reviewed and approved by the developer — [interactive only; skip when autoAdvance: true]
 - [ ] ROADMAP.md exists with phases, success criteria, and requirement mapping

package/distilled/workflows/plan.md

@@ -22,6 +22,14 @@ Identify the target phase: the first phase with status `[ ]` or `[-]` in `ROADMA
 All `node .planning/bin/gsdd.mjs ...` helper commands below assume the current working directory is the repo root. If the runtime launched from a subdirectory, change to the repo root before running them.
 </repo_root_helper_contract>
 
+<lifecycle_preflight>
+Before writing or rewriting phase planning artifacts, run:
+
+- `node .planning/bin/gsdd.mjs lifecycle-preflight plan {phase_num}`
+
+If the preflight result is `blocked`, STOP and report the blocker instead of inferring planning eligibility from workflow-local prose. Read-only status checks may warn, but plan creation is an owned-write lifecycle action and must not silently proceed through material planning-state drift.
+</lifecycle_preflight>
+
 <integration_surface_check>
 Before planning roadmap work, inspect the live integration surface separately from checkpoint or planning artifacts:
 - current branch name
@@ -411,18 +419,15 @@ notes: [What the checker actually validated or why it was skipped]
 
 <approach_exploration>
 ### When This Runs
-
 Check `.planning/config.json` for `workflow.discuss`:
 - If `workflow.discuss: false` (or key missing): skip this section, go to `<goal_backward_planning>`. Note `reduced_alignment` in the orchestration summary.
 - If `workflow.discuss: true`: mandatory before planning.
 
 ### Check for Existing APPROACH.md
-
 Check if `{phase_dir}/{padded_phase}-APPROACH.md` exists.
-
 **If exists:**
 Offer the user a choice:
-- "Use existing" — load decisions from APPROACH.md, skip to `<goal_backward_planning>`
+- "Use existing" — load decisions from APPROACH.md, validate the alignment proof below, then continue to `<goal_backward_planning>` only if the proof is valid
 - "Update it" — run the approach explorer to revise decisions
 - "View it" — display APPROACH.md contents, then offer "Use existing" / "Update"
 
@@ -430,9 +435,7 @@ Offer the user a choice:
 Run the approach explorer.
 
 ### Running the Approach Explorer
-
 **Primary path — inline conversation with research subagents:**
-
 The conversation with the user runs inline in the main context. For each technical gray area, a read-only research subagent is spawned to isolate heavy codebase and documentation reads, returning only compressed summaries.
 
 1. Load context: read ONLY locked decisions from `.planning/SPEC.md` and the target phase goal/requirements from `.planning/ROADMAP.md`.
@@ -458,7 +461,7 @@ The conversation with the user runs inline in the main context. For each technic
 **Native agent optimization:**
 
 If your runtime provides an interactive `gsdd-approach-explorer` agent:
-- Invoke it with: target phase goal, requirement IDs, locked decisions, phase research (if exists), relevant codebase files
+- Invoke it with: target phase goal, requirement IDs, project config from `.planning/config.json` (especially `workflow.discuss`), locked decisions, phase research (if exists), relevant codebase files
 - The native agent runs the full exploration in its own context window
 - This is an optimization — the output (APPROACH.md) is identical to the primary path
 
@@ -471,8 +474,8 @@ If neither the primary path nor native agent is available (e.g., the runtime can
 - Explicitly report `reduced_alignment` — the user did not get full research-backed exploration
 
 ### Using APPROACH.md Decisions
-
 After approach exploration completes (or existing APPROACH.md is loaded):
+- If `workflow.discuss: true`, validate that APPROACH.md records `alignment_status: user_confirmed` or `alignment_status: approved_skip` with the canonical fields `alignment_method`, `user_confirmed_at`, `explicit_skip_approved`, `skip_scope`, `skip_rationale`, and `confirmed_decisions` before goal-backward planning begins. Stop and update the APPROACH artifact if proof is missing, unknown, agent-discretion-only, or based only on agent "No questions needed" judgment.
 - Treat decisions from APPROACH.md as locked constraints, same priority as `.planning/SPEC.md` decisions
 - "Agent's Discretion" items from APPROACH.md give the planner flexibility — do not treat them as locked
 - Thread the APPROACH.md file path to both the planner prompt and the plan-checker prompt
@@ -485,11 +488,9 @@ The approach explorer's full role contract is at `.planning/templates/roles/appr
 
 <plan_check_orchestration>
 ### How Plan Checking Works
-
 After the planner produces a draft plan, an independent checker reviews it in fresh context. The checker does not inherit the planner's hidden reasoning; it treats the plan as an untrusted draft.
 
 ### What The Checker Verifies
-
 1. `requirement_coverage` - every phase requirement is covered by at least one concrete task
 2. `task_completeness` - every task has files, action, verify, and done fields; verify quality sub-checks ensure at least one runnable command per task, flag slow or watch-mode verification, and check test file ordering
 3. `dependency_correctness` - ordering, dependencies, and plan structure are coherent
@@ -503,20 +504,21 @@ After the planner produces a draft plan, an independent checker reviews it in fr
 11. `escalation_integrity` - stop-and-challenge triggers and approval gates are present where side effects or ambiguity warrant them
 12. `closure_honesty` - closure claim limit prevents the plan from overclaiming what verification can prove
 13. `high_leverage_review` - high-leverage surfaces and second-pass obligations are recorded honestly
-14. `approach_alignment` - when APPROACH.md exists, plans implement the chosen approaches, not alternatives. Blocker if plan contradicts an explicit user choice. Warning if plan drifts from recommendation without justification. Skipped when no APPROACH.md is provided.
+14. `approach_alignment` - when APPROACH.md exists, plans implement the chosen approaches, not alternatives. Blocker if plan contradicts an explicit user choice. Warning if plan drifts from recommendation without justification. When `workflow.discuss: true`, missing, proofless, agent-discretion-only, or invalid APPROACH.md is a blocker before a plan can be accepted.
 ### Invoking the Checker
-1. If `.planning/config.json` has `workflow.planCheck: false`, skip the independent checker. Perform the planner self-check below and report `reduced_assurance`.
+1. If `.planning/config.json` has `workflow.planCheck: false`, skip the independent checker. Perform the planner self-check below and report `reduced_assurance`. This does not skip the earlier alignment-proof gate when `workflow.discuss: true`.
 2. If plan checking is enabled, check if your runtime provides a `gsdd-plan-checker` agent.
 3. If a native checker agent is available, invoke it in a fresh context with only these explicit inputs:
    - target phase goal and requirement IDs
    - relevant locked decisions / deferred items from `.planning/SPEC.md`
+   - project config from `.planning/config.json`, especially `workflow.discuss` and `workflow.planCheck`
    - approach decisions from `.planning/phases/*-APPROACH.md` (if exists)
    - relevant phase research file(s)
    - produced `.planning/phases/*-PLAN.md` file(s)
 4. Require the checker to return a single JSON object:
    ```json
    {
-     "status": "passed",
+     "status": "issues_found",
      "summary": "One sentence overall assessment",
      "issues": [
        {
@@ -530,10 +532,10 @@ After the planner produces a draft plan, an independent checker reviews it in fr
      ]
    }
    ```
-   Status must be either "passed" or "issues_found".
+   Status must be either "passed" or "issues_found". Use "passed" only when "issues": []; any blocker or warning must use "issues_found".
 5. If the checker returns `passed`, finish and summarize.
 6. If the checker returns `issues_found`, revise the existing plan files only where needed, then invoke the checker again.
-7. Maximum 3 checker cycles total. If blockers remain after cycle 3, stop and escalate to the user instead of pretending the plan is ready.
+7. Maximum 3 checker cycles total. If any blockers or warnings remain after cycle 3, stop and escalate to the user instead of pretending the plan is ready.
 8. If no native checker agent is available in your runtime, perform the planner self-check below and explicitly report `reduced_assurance` rather than claiming an independent checker ran.
 When the checker outcome is finalized, write the result into the plan artifact:
 - checker ran in same runtime or planner self-check only -> set frontmatter `assurance: self_checked`
@@ -553,7 +555,7 @@ The checker returns structured JSON feedback with specific issues, severities, a
 
 ### When To Escalate
 
-If blockers remain after 3 checker cycles, the orchestrator stops and escalates to the user. It does not pretend the plan is ready.
+If any blockers or warnings remain after 3 checker cycles, the orchestrator stops and escalates to the user. It does not pretend the plan is ready.
 </plan_check_orchestration>
 
 <plan_self_check>

package/distilled/workflows/quick.md

@@ -169,9 +169,9 @@ Read `.planning/config.json`.
 If the checker returns `issues_found` with blockers and this is the first cycle:
 1. Send the issue list back to the planner for targeted revision of the plan file.
 2. Re-run the checker once more.
-3. If blockers remain after 1 revision cycle, store `$CHECKER_ISSUES` for display in the plan preview. Do NOT block — the user decides in Step 3.7.
+3. If blockers remain after 1 revision cycle, store `$CHECKER_ISSUES` for display in the plan preview and set `$RISK_ACCEPTANCE_REQUIRED=true`. Do not execute from default Enter; the user must explicitly accept the known risk in Step 3.7.
 
-If the checker returns `passed`, or `workflow.planCheck` is false, `$CHECKER_ISSUES` is empty.
+If the checker returns `passed`, or `workflow.planCheck` is false, `$CHECKER_ISSUES` is empty and `$RISK_ACCEPTANCE_REQUIRED=false`.
 
 ---
 
@@ -222,14 +222,18 @@ If `$CHECKER_ISSUES` is non-empty, append:
 Plan check issues: {$CHECKER_ISSUES}
 ```
 
-Present options (default-yes — pressing Enter proceeds):
-- If `$SCOPE_WARNING` is empty: `[Enter to proceed / edit description / abort]`
-- If `$SCOPE_WARNING` contains `/gsdd-new-project`: `[Enter to proceed / switch to /gsdd-new-project / edit description / abort]`
+Present options:
+- If `$CHECKER_ISSUES` is non-empty: `[type "proceed despite issues" to execute / edit description / abort]`
+- Otherwise if `$SCOPE_WARNING` is empty: `[Enter to proceed / edit description / abort]`
+- Otherwise if `$SCOPE_WARNING` contains `/gsdd-new-project`: `[Enter to proceed / switch to /gsdd-new-project / edit description / abort]`
 - Otherwise if `$SCOPE_WARNING` contains `/gsdd-map-codebase`: `[Enter to proceed / switch to /gsdd-map-codebase / edit description / abort]`
 - Otherwise if `$SCOPE_WARNING` is non-empty: `[Enter to proceed / switch to /gsdd-plan / edit description / abort]`
 
+Default-yes applies only when `$CHECKER_ISSUES` is empty. When unresolved checker blockers remain, pressing Enter must not execute; repeat the issues and ask for `proceed despite issues`, `edit description`, or `abort`.
+
 Handle response:
-- **Enter (or "yes"):** proceed to Step 4.
+- **Enter (or "yes") when `$CHECKER_ISSUES` is empty:** proceed to Step 4.
+- **"proceed despite issues" when `$CHECKER_ISSUES` is non-empty:** proceed to Step 4 and record the explicit risk acceptance in the quick summary.
 - **"edit description":** clean up the task directory, then return to Step 1 with `$DESCRIPTION` pre-filled as the starting point.
 - **"switch to /gsdd-new-project":** clean up the task directory, then stop quick workflow and report: "Use `/gsdd-new-project` to define or intentionally widen the work into full lifecycle planning. Task description: {$DESCRIPTION}"
 - **"switch to /gsdd-map-codebase":** clean up the task directory, then stop quick workflow and report: "Use `/gsdd-map-codebase` for a deeper brownfield baseline before quick work. Task description: {$DESCRIPTION}"

package/distilled/workflows/verify.md

@@ -117,12 +117,12 @@ Apply the shared `verify` matrix:
 | delivery_posture     | required evidence | recommended evidence       | cannot carry closure alone |
 | -------------------- | ----------------- | -------------------------- | -------------------------- |
 | `repo_only`          | `code`            | `test`                     | `human`, `delivery`        |
-| `delivery_sensitive` | `code`, `runtime` | `test`, `delivery`, `human` | `code`, `human`            |
+| `delivery_sensitive` | `code`, `runtime`, `delivery` | `test`, `human` | `code`, `human`            |
 
 Rules:
 - repo-only work must not invent `runtime` or `delivery` proof just to satisfy a template
-- delivery-sensitive closure must not pass on prose, `code`-only inspection, or `human` confirmation without the required `runtime` evidence
-- `human` evidence supports ambiguous or visual outcomes; it does not replace required `code` or `runtime` evidence
+- delivery-sensitive closure must not pass on prose, `code`-only inspection, or `human` confirmation without the required `runtime` and `delivery` evidence
+- `human` evidence supports ambiguous or visual outcomes; it does not replace required `code`, `runtime`, or `delivery` evidence
 - if a required evidence kind cannot be collected, record it in `missing_evidence`; route purely human-observable follow-up to `human_verification` only when the blocking runtime/delivery requirement is already satisfied
 
 Note: this step does NOT replace levels 1–3. An artifact can satisfy the evidence-kind requirement and still fail Level 2 (substantive) or Level 3 (wired). Both checks must run.
@@ -247,10 +247,10 @@ status: gaps_found
 score: 2/3 must-haves verified
 delivery_posture: delivery_sensitive
 evidence_contract:
-  required_kinds: [code, runtime]
-  recommended_kinds: [test, delivery, human]
+  required_kinds: [code, runtime, delivery]
+  recommended_kinds: [test, human]
   observed_kinds: [code]
-  missing_kinds: [runtime]
+  missing_kinds: [runtime, delivery]
 re_verification:
   previous_status: gaps_found
   previous_score: 1/3
@@ -262,9 +262,9 @@ re_verification:
 gaps:
   - truth: "Users can create a user from the page"
     status: failed
-    required_evidence: [code, runtime]
+    required_evidence: [code, runtime, delivery]
     observed_evidence: [code]
-    missing_evidence: [runtime]
+    missing_evidence: [runtime, delivery]
     severity: blocker # blocker = required proof absent; warning = artifact missing but proof exists via other means
     reason: "Form submits, but route returns placeholder data"
     artifacts:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gsdd-cli",
-  "version": "0.19.0",
+  "version": "0.19.2",
   "description": "Workspine — a repo-native delivery spine for long-horizon AI-assisted work, with directly validated support for Claude Code, Codex CLI, and OpenCode, published as gsdd-cli.",
   "type": "module",
   "bin": {