gsd-opencode 1.3.33 → 1.4.2

package/get-shit-done/workflows/map-codebase.md

@@ -1,5 +1,5 @@
 <purpose>
-Orchestrate parallel Explore agents to analyze codebase and produce structured documents in .planning/codebase/
+Orchestrate parallel explore agents to analyze codebase and produce structured documents in .planning/codebase/
 
 Each agent has fresh context and focuses on specific aspects. Output is concise and actionable for planning.
 </purpose>
@@ -69,15 +69,15 @@ Continue to spawn_agents.
 </step>
 
 <step name="spawn_agents">
-Spawn 4 parallel Explore agents to analyze codebase.
+Spawn 4 parallel explore agents to analyze codebase.
 
-Use Task tool with `subagent_type="Explore"` and `run_in_background=true` for parallel execution.
+Use Task tool with `subagent_type="explore"` and `run_in_background=true` for parallel execution.
 
 **Agent 1: Stack + Integrations (Technology Focus)**
 
 Task tool parameters:
 ```
-subagent_type: "Explore"
+subagent_type: "explore"
 run_in_background: true
 task_description: "Analyze codebase technology stack and external integrations"
 ```
@@ -121,7 +121,7 @@ If something is not found, note "Not detected" for that category.
 
 Task tool parameters:
 ```
-subagent_type: "Explore"
+subagent_type: "explore"
 run_in_background: true
 task_description: "Analyze codebase architecture patterns and directory structure"
 ```
@@ -164,7 +164,7 @@ If something is not clear, provide best-guess interpretation based on code struc
 
 Task tool parameters:
 ```
-subagent_type: "Explore"
+subagent_type: "explore"
 run_in_background: true
 task_description: "Analyze coding conventions and test patterns"
 ```
@@ -208,7 +208,7 @@ Look at actual code files to infer conventions if config files are missing.
 
 Task tool parameters:
 ```
-subagent_type: "Explore"
+subagent_type: "explore"
 run_in_background: true
 task_description: "Identify technical debt and areas of concern"
 ```
@@ -405,7 +405,7 @@ Created .planning/codebase/:
 
 `/gsd:new-project`
 
-<sub>`/clear` first → fresh context window</sub>
+*`/clear` first → fresh context window*
 
 ---
 
@@ -424,7 +424,7 @@ End workflow.
 
 <success_criteria>
 - .planning/codebase/ directory created
-- 4 parallel Explore agents spawned with run_in_background=true
+- 4 parallel explore agents spawned with run_in_background=true
 - Agent prompts are specific and actionable
 - TaskOutput used to collect all agent results
 - All 7 codebase documents written using template filling

package/get-shit-done/workflows/plan-phase.md

@@ -30,10 +30,18 @@ Decimal phases enable urgent work insertion without renumbering:
 </required_reading>
 
 <purpose>
-Create an executable phase prompt (PLAN.md). PLAN.md IS the prompt that Claude executes - not a document that gets transformed.
+Create executable phase prompts (PLAN.md files) optimized for parallel execution.
+
+PLAN.md IS the prompt that Claude executes. Plans are grouped into execution waves based on dependencies - independent plans run in parallel, dependent plans wait for predecessors.
 </purpose>
 
 <planning_principles>
+**Parallel by default:** Think in dependency graphs, not sequential lists. Ask "what does this need?" not "what comes next?"
+
+**Vertical slices over horizontal layers:** Group by feature (User: model + API + UI) not by type (all models → all APIs → all UIs).
+
+**Explicit dependencies:** Every plan declares what it needs (`depends_on`) and what it touches (`files_modified`). Empty dependencies = parallel candidate.
+
 **Secure by design:** Assume hostile input on every boundary. Validate, parameterize, authenticate, fail closed.
 
 **Performance by design:** Assume production load, not demo conditions. Plan for efficient data access, appropriate caching, minimal round trips.
@@ -233,7 +241,12 @@ cat .planning/phases/XX-name/${PHASE}-CONTEXT.md 2>/dev/null
 </step>
 
 <step name="break_into_tasks">
-Decompose phase into tasks and identify TDD candidates.
+Decompose phase into tasks. **Think dependencies first, not sequence.**
+
+For each potential task, ask:
+1. **What does this task NEED?** (files, types, APIs that must exist)
+2. **What does this task CREATE?** (files, types, APIs others might need)
+3. **Can this run independently?** (no dependencies = Wave 1 candidate)
 
 **Standard tasks need:**
 - **Type**: auto, checkpoint:human-verify, checkpoint:decision (human-action rarely needed)
@@ -277,8 +290,165 @@ See `~/.config/opencode/get-shit-done/references/tdd.md` for TDD plan structure.
 See ~/.config/opencode/get-shit-done/references/checkpoints.md for checkpoint structure.
 </step>
 
+<step name="build_dependency_graph">
+**Map task dependencies explicitly before grouping into plans.**
+
+**1. For each task identified, record:**
+- `needs`: What must exist before this task runs (files, types, prior task outputs)
+- `creates`: What this task produces (files, types, exports)
+- `has_checkpoint`: Does this task require user interaction?
+
+**2. Build the dependency graph:**
+
+```
+Example phase with 6 tasks:
+
+Task A (User model): needs nothing, creates src/models/user.ts
+Task B (Product model): needs nothing, creates src/models/product.ts
+Task C (User API): needs Task A, creates src/api/users.ts
+Task D (Product API): needs Task B, creates src/api/products.ts
+Task E (Dashboard): needs Task C + D, creates src/components/Dashboard.tsx
+Task F (Verify UI): checkpoint:human-verify, needs Task E
+
+Dependency graph:
+  A ──→ C ──┐
+            ├──→ E ──→ F
+  B ──→ D ──┘
+
+Wave analysis:
+  Wave 1: A, B (independent roots)
+  Wave 2: C, D (depend only on Wave 1)
+  Wave 3: E (depends on Wave 2)
+  Wave 4: F (checkpoint, depends on Wave 3)
+```
+
+**3. Identify parallelization opportunities:**
+
+| Pattern | Result |
+|---------|--------|
+| No dependencies | Wave 1 (parallel) |
+| Depends only on Wave 1 | Wave 2 (parallel) |
+| Has checkpoint | Runs in wave, but can pause/resume |
+| Shared file conflict | Must be sequential |
+
+**4. Detect and prefer vertical slices:**
+
+**Sequential (horizontal layers) - AVOID:**
+```
+Plan 01: Create User model, Product model, Order model
+Plan 02: Create User API, Product API, Order API
+Plan 03: Create User UI, Product UI, Order UI
+```
+Result: Fully sequential (02 needs 01, 03 needs 02)
+
+**Parallel (vertical slices) - PREFER:**
+```
+Plan 01: User feature (model + API + UI)
+Plan 02: Product feature (model + API + UI)
+Plan 03: Order feature (model + API + UI)
+```
+Result: All three can run in parallel (Wave 1)
+
+**When vertical slices work:**
+- Features are independent (no shared types/data)
+- Each slice is self-contained
+- No cross-feature dependencies
+
+**When horizontal layers are necessary:**
+- Shared foundation required (auth before protected features)
+- Genuine type dependencies (Order needs User type)
+- Infrastructure setup (database before all features)
+
+**5. Output: Dependency map for each plan**
+
+For each plan, determine:
+- `depends_on: []` - plan IDs this plan requires (empty = parallel candidate)
+- `files_modified: []` - files this plan touches (for conflict detection)
+- `autonomous: true|false` - has checkpoints requiring user interaction?
+</step>
+
+<step name="assign_waves">
+**Compute wave numbers before writing plans.**
+
+Wave assignment algorithm (run in memory before writing any files):
+
+```
+waves = {}  # plan_id -> wave_number
+
+for each plan in plan_order:
+  if plan.depends_on is empty:
+    plan.wave = 1
+  else:
+    # Wave = max wave of dependencies + 1
+    plan.wave = max(waves[dep] for dep in plan.depends_on) + 1
+
+  waves[plan.id] = plan.wave
+```
+
+**Example:**
+
+```
+Plan 01: depends_on: []           → wave: 1
+Plan 02: depends_on: []           → wave: 1
+Plan 03: depends_on: ["01"]       → wave: 2
+Plan 04: depends_on: ["02"]       → wave: 2
+Plan 05: depends_on: ["03", "04"] → wave: 3
+```
+
+Store wave number with each plan in memory. Write to frontmatter in next step.
+</step>
+
+<step name="group_into_plans">
+**Group tasks into plans based on dependency waves and autonomy.**
+
+**Grouping rules:**
+
+1. **Same-wave tasks with no file conflicts → can be in parallel plans**
+2. **Tasks with shared files → must be in same plan or sequential plans**
+3. **Checkpoint tasks → mark plan as `autonomous: false`**
+4. **Each plan: 2-3 tasks max, single concern, ~50% context target**
+
+**Plan assignment algorithm:**
+
+```
+1. Start with Wave 1 tasks (no dependencies)
+2. Group into plans by:
+   - Feature affinity (vertical slice)
+   - File ownership (no conflicts)
+   - Checkpoint presence (group checkpoints with related auto tasks)
+3. Move to Wave 2 tasks, repeat
+4. Continue until all tasks assigned
+```
+
+**Example grouping:**
+
+```
+Tasks identified:
+- A: User model (Wave 1, auto)
+- B: Product model (Wave 1, auto)
+- C: User API (Wave 2, auto)
+- D: Product API (Wave 2, auto)
+- E: Dashboard (Wave 3, auto)
+- F: Verify Dashboard (Wave 3, checkpoint)
+
+Grouping into plans:
+Plan 01: [A, C] - User feature (model + API)
+         depends_on: [], autonomous: true
+
+Plan 02: [B, D] - Product feature (model + API)
+         depends_on: [], autonomous: true
+
+Plan 03: [E, F] - Dashboard (build + verify)
+         depends_on: ["01", "02"], autonomous: false
+
+Wave structure:
+  Wave 1 (parallel): Plan 01, Plan 02
+  Wave 2: Plan 03 (has checkpoint, runs after Wave 1)
+```
+</step>
+
 <step name="estimate_scope">
-After tasks, assess against quality degradation curve.
+After grouping, verify each plan fits context budget.
 
 **Check depth setting:**
 ```bash
@@ -302,8 +472,6 @@ cat .planning/config.json 2>/dev/null | grep depth
 For comprehensive depth:
 - Create MORE plans when the work warrants it, not bigger ones
 - If a phase has 15 tasks, that's 5-8 plans (not 3 plans with 5 tasks each)
-- Don't compress to look efficient—thoroughness is the goal
-- Let small phases stay small—don't pad to hit a number
 - Each plan stays focused: 2-3 tasks, single concern
 
 For quick depth:
@@ -314,14 +482,8 @@ For quick depth:
 
 **ALWAYS split if:** >3 tasks, multiple subsystems, >5 files in any task, complex domains (auth, payments).
 
-**If scope appropriate (2-3 tasks, single subsystem, <5 files/task):** Proceed to confirm_breakdown.
-
-**If large (>3 tasks):** Split by subsystem, dependency, complexity, or autonomous vs interactive.
-
 **Each plan must be:** 2-3 tasks max, ~50% context target, independently committable.
 
-**Autonomous optimization:** No checkpoints → subagent (fresh context). Has checkpoints → main context. Group autonomous work together.
-
 See ~/.config/opencode/get-shit-done/references/scope-estimation.md for complete guidance.
 </step>
 
@@ -331,22 +493,39 @@ Auto-approve and proceed to write_phase_prompt.
 </if>
 
 <if mode="interactive">
-Present breakdown inline:
+Present breakdown with wave structure:
 
 ```
 Phase [X] breakdown:
 
-### Tasks ({phase}-01-PLAN.md)
-1. [Task] - [brief] [type]
-2. [Task] - [brief] [type]
+## Execution Waves
+
+**Wave 1 (parallel):**
+  {phase}-01: [Plan Name] [autonomous]
+    - Task: [brief]
+    - Task: [brief]
+
+  {phase}-02: [Plan Name] [autonomous]
+    - Task: [brief]
+    - Task: [brief]
 
-Autonomous: [yes/no]
+**Wave 2 (parallel):**
+  {phase}-03: [Plan Name] (depends: 01, 02) [autonomous]
+    - Task: [brief]
+
+**Wave 3:**
+  {phase}-04: [Plan Name] (depends: 03) [has checkpoint]
+    - Task: [brief]
+    - Checkpoint: [type]
+
+---
+Total: [N] plans in [M] waves
+Parallel plans: [X]
+Sequential plans: [Y]
 
 Does this look right? (yes / adjust / start over)
 ```
 
-For multiple plans, show each plan with its tasks.
-
 Wait for confirmation. If "adjust": revise. If "start over": return to gather_phase_context.
 </if>
 </step>
@@ -359,16 +538,33 @@ Use template from `~/.config/opencode/get-shit-done/templates/phase-prompt.md`.
 **Multiple plans:** Write separate files ({phase}-01-PLAN.md, {phase}-02-PLAN.md, etc.)
 
 Each plan follows template structure with:
-- Frontmatter (phase, plan, type, domain)
+- Frontmatter (phase, plan, type, depends_on, files_modified, autonomous, domain)
 - Objective (plan-specific goal, purpose, output)
-- Execution context (execute-phase.md, summary template, checkpoints.md if needed)
-- Context (@references to PROJECT, ROADMAP, STATE, codebase docs, RESEARCH/DISCOVERY/CONTEXT if exist, prior summaries, source files, prior decisions, deferred issues, concerns)
+- Execution context (execute-plan.md, summary template, checkpoints.md if needed)
+- Context (@references to PROJECT, ROADMAP, STATE, codebase docs, RESEARCH/DISCOVERY/CONTEXT if exist, prior summaries, source files)
 - Tasks (XML format with types)
 - Verification, Success criteria, Output specification
 
-**Context section population from frontmatter analysis:**
+**Plan frontmatter:**
+
+```yaml
+---
+phase: XX-name
+plan: NN
+type: execute
+wave: N                     # Execution wave (1, 2, 3...). Computed at plan time.
+depends_on: []              # Plan IDs this plan requires.
+files_modified: []          # Files this plan touches.
+autonomous: true            # false if plan has checkpoints requiring user interaction
+domain: [optional]
+---
+```
+
+**Wave is pre-computed:** Wave numbers are assigned during planning (see `assign_waves` step). `/gsd:execute-phase` reads `wave` directly from frontmatter and groups plans by wave number. No runtime dependency analysis needed.
 
-Inject automatically-assembled context package from read_project_history step:
+**Context section - parallel-aware:**
+
+Only include prior plan SUMMARY references if this plan genuinely needs decisions/outputs:
 
 ```markdown
 <context>
@@ -376,27 +572,30 @@ Inject automatically-assembled context package from read_project_history step:
 @.planning/ROADMAP.md
 @.planning/STATE.md
 
-# Auto-selected based on dependency graph (from frontmatter):
-@.planning/phases/XX-name/YY-ZZ-SUMMARY.md
-@.planning/phases/AA-name/BB-CC-SUMMARY.md
-
-# Key files from frontmatter (relevant to this phase):
-@path/to/important/file.ts
-@path/to/another/file.ts
-
-**Tech stack available:** [extracted from frontmatter tech-stack.added]
-**Established patterns:** [extracted from frontmatter patterns-established]
-**Constraining decisions:**
-- [Phase X]: [decision from frontmatter]
-- [Phase Y]: [decision from frontmatter]
+# Only reference prior plans if genuinely needed:
+# - This plan uses types/exports from prior plan
+# - This plan continues work from prior plan
+# - Prior plan made decision that affects this plan
+#
+# Do NOT reflexively chain: Plan 02 refs 01, Plan 03 refs 02...
+# Independent plans need no prior SUMMARY references.
 
-**Issues being addressed:** [If any from ISSUES.md]
+@path/to/relevant/source.ts
 </context>
 ```
 
-This ensures every PLAN.md gets optimal context automatically assembled via dependency graph, making execution as informed as possible.
+**For plans with checkpoints:**
 
-For multi-plan phases: each plan has focused scope, references previous plan summaries (via frontmatter selection), last plan's success criteria includes "Phase X complete".
+Include checkpoint reference in execution_context:
+```markdown
+<execution_context>
+@~/.config/opencode/get-shit-done/workflows/execute-plan.md
+@~/.config/opencode/get-shit-done/templates/summary.md
+@~/.config/opencode/get-shit-done/references/checkpoints.md
+</execution_context>
+```
+
+Checkpoint plans can still run in parallel waves. When they hit a checkpoint, they pause and return to the orchestrator. User responds, orchestrator resumes the agent.
 </step>
 
 <step name="git_commit">
@@ -413,8 +612,8 @@ git commit -m "$(cat <<'EOF'
 docs(${PHASE}): create phase plan
 
 Phase ${PHASE}: ${PHASE_NAME}
-- [N] plan(s) created
-- [X] total tasks defined
+- [N] plan(s) in [M] wave(s)
+- [X] parallel, [Y] sequential
 - Ready for execution
 EOF
 )"
@@ -425,24 +624,35 @@ Confirm: "Committed: docs(${PHASE}): create phase plan"
 
 <step name="offer_next">
 ```
-Phase plan created: .planning/phases/XX-name/{phase}-01-PLAN.md
-[X] tasks defined.
+Phase {X} planned: {N} plan(s) in {M} wave(s)
+
+## Wave Structure
+Wave 1 (parallel): {plan-01}, {plan-02}
+Wave 2: {plan-03}
+...
 
 ---
 
 ## Next Up
 
+[If 1 plan created:]
 **{phase}-01: [Plan Name]** - [objective summary]
 
 `/gsd:execute-plan .planning/phases/XX-name/{phase}-01-PLAN.md`
 
-<sub>`/clear` first - fresh context window</sub>
+[If 2+ plans created:]
+**Phase {X}: [Phase Name]** - {N} plans in {M} waves
+
+`/gsd:execute-phase {X}`
+
+*`/clear` first - fresh context window*
 
 ---
 
 **Also available:**
-- Review/adjust tasks before executing
-[If multiple plans: - View all plans: `ls .planning/phases/XX-name/*-PLAN.md`]
+- Review/adjust plans before executing
+[If 2+ plans: - `/gsd:execute-plan {phase}-01-PLAN.md` - run plans one at a time]
+[If 2+ plans: - View all plans: `ls .planning/phases/XX-name/*-PLAN.md`]
 
 ---
 ```
@@ -468,6 +678,7 @@ If you can't specify Files + Action + Verify + Done, the task is too vague.
 - No team assignments
 - No acceptance criteria committees
 - No sub-sub-sub tasks
+- **No reflexive sequential chaining** (Plan 02 depends on 01 "just because")
 Tasks are instructions for Claude, not Jira tickets.
 </anti_patterns>
 
@@ -476,13 +687,15 @@ Phase planning complete when:
 - [ ] STATE.md read, project history absorbed
 - [ ] Mandatory discovery completed (Level 0-3)
 - [ ] Prior decisions, issues, concerns synthesized
+- [ ] Dependency graph built (needs/creates for each task)
+- [ ] Tasks grouped into plans by wave, not by sequence
 - [ ] PLAN file(s) exist with XML structure
+- [ ] Each plan: depends_on, files_modified, autonomous in frontmatter
 - [ ] Each plan: Objective, context, tasks, verification, success criteria, output
-- [ ] @context references included (STATE, RESEARCH/DISCOVERY if exist, relevant summaries)
 - [ ] Each plan: 2-3 tasks (~50% context)
 - [ ] Each task: Type, Files (if auto), Action, Verify, Done
 - [ ] Checkpoints properly structured
-- [ ] If RESEARCH.md exists: "don't hand-roll" items NOT being custom-built
+- [ ] Wave structure maximizes parallelism
 - [ ] PLAN file(s) committed to git
-- [ ] User knows next steps
+- [ ] User knows next steps and wave structure
 </success_criteria>

package/get-shit-done/workflows/resume-project.md

@@ -69,6 +69,12 @@ for plan in .planning/phases/*/*-PLAN.md; do
   summary="${plan/PLAN/SUMMARY}"
   [ ! -f "$summary" ] && echo "Incomplete: $plan"
 done 2>/dev/null
+
+# Check for interrupted agents
+if [ -f .planning/current-agent-id.txt ] && [ -s .planning/current-agent-id.txt ]; then
+  AGENT_ID=$(cat .planning/current-agent-id.txt | tr -d '\n')
+  echo "Interrupted agent: $AGENT_ID"
+fi
 ```
 
 **If .continue-here file exists:**
@@ -81,6 +87,12 @@ done 2>/dev/null
 
 - Execution was started but not completed
 - Flag: "Found incomplete plan execution"
+
+**If interrupted agent found:**
+
+- Subagent was spawned but session ended before completion
+- Read agent-history.json for task details
+- Flag: "Found interrupted agent"
   </step>
 
 <step name="present_status">
@@ -103,6 +115,14 @@ Present complete project status to user:
 ⚠️  Incomplete work detected:
     - [.continue-here file or incomplete plan]
 
+[If interrupted agent found:]
+⚠️  Interrupted agent detected:
+    Agent ID: [id]
+    Task: [task description from agent-history.json]
+    Interrupted: [timestamp]
+
+    Resume with: /gsd:resume-task
+
 [If deferred issues exist:]
 📋 [N] deferred issues awaiting attention
 
@@ -120,6 +140,10 @@ Present complete project status to user:
 <step name="determine_next_action">
 Based on project state, determine the most logical next action:
 
+**If interrupted agent exists:**
+→ Primary: Resume interrupted agent (/gsd:resume-task)
+→ Option: Start fresh (abandon agent work)
+
 **If .continue-here file exists:**
 → Primary: Resume from checkpoint
 → Option: Start fresh on current plan
@@ -154,6 +178,8 @@ Present contextual options based on project state:
 What would you like to do?
 
 [Primary action based on state - e.g.:]
+1. Resume interrupted agent (/gsd:resume-task) [if interrupted agent found]
+   OR
 1. Resume from checkpoint (/gsd:execute-plan .planning/phases/XX-name/.continue-here-02-01.md)
    OR
 1. Execute next plan (/gsd:execute-plan .planning/phases/XX-name/02-02-PLAN.md)
@@ -193,7 +219,7 @@ Based on user selection, route to appropriate workflow:
 
   `/gsd:execute-plan [path]`
 
-  <sub>`/clear` first → fresh context window</sub>
+  *`/clear` first → fresh context window*
 
   ---
   ```
@@ -207,7 +233,7 @@ Based on user selection, route to appropriate workflow:
 
   `/gsd:plan-phase [phase-number]`
 
-  <sub>`/clear` first → fresh context window</sub>
+  *`/clear` first → fresh context window*
 
   ---
 

package/get-shit-done/workflows/transition.md

@@ -449,7 +449,7 @@ Next: Phase [X+1] — [Name]
 ⚡ Auto-continuing: Plan Phase [X+1] in detail
 ```
 
-Exit skill and invoke SlashCommand("/gsd:plan-phase [X+1]")
+Exit skill and invoke [removed - use /command syntax]("/gsd:plan-phase [X+1]")
 
 </if>
 
@@ -466,7 +466,7 @@ Exit skill and invoke SlashCommand("/gsd:plan-phase [X+1]")
 
 `/gsd:plan-phase [X+1]`
 
-<sub>`/clear` first → fresh context window</sub>
+*`/clear` first → fresh context window*
 
 ---
 
@@ -494,7 +494,7 @@ Phase {X} marked complete.
 ⚡ Auto-continuing: Complete milestone and archive
 ```
 
-Exit skill and invoke SlashCommand("/gsd:complete-milestone {version}")
+Exit skill and invoke [removed - use /command syntax]("/gsd:complete-milestone {version}")
 
 </if>
 
@@ -513,7 +513,7 @@ Exit skill and invoke SlashCommand("/gsd:complete-milestone {version}")
 
 `/gsd:complete-milestone {version}`
 
-<sub>`/clear` first → fresh context window</sub>
+*`/clear` first → fresh context window*
 
 ---
 

package/get-shit-done/workflows/verify-work.md

@@ -81,7 +81,7 @@ Present this checklist to user.
 <step name="guide">
 **Guide user through each test:**
 
-For each test item, use AskUserQuestion:
+For each test item, use question:
 - header: "[Feature name]"
 - question: "[Test description] - Did this work as expected?"
 - options:
@@ -93,7 +93,7 @@ For each test item, use AskUserQuestion:
 **If Pass:** Move to next test
 
 **If Fail or Partial:**
-Follow up with AskUserQuestion:
+Follow up with question:
 - header: "Issue details"
 - question: "What went wrong?"
 - options:
@@ -172,7 +172,7 @@ If any issues found:
 <step name="offer">
 **Offer next actions based on results:**
 
-Use AskUserQuestion:
+Use question:
 - header: "Next"
 - question: "What would you like to do?"
 - options (based on results):
@@ -194,7 +194,7 @@ If issues found:
 <success_criteria>
 - [ ] Test scope identified from SUMMARY.md
 - [ ] Checklist generated based on deliverables
-- [ ] User guided through each test via AskUserQuestion
+- [ ] User guided through each test via question
 - [ ] All test results captured (pass/fail/partial/skip)
 - [ ] Any issues logged to phase-scoped ISSUES.md
 - [ ] Summary presented with verdict

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gsd-opencode",
-  "version": "1.3.33",
+  "version": "1.4.2",
   "description": "A meta-prompting, context engineering and spec-driven development system for OpenCode by TÂCHES.",
   "keywords": [
     "opencode",