oh-my-opencode-lite 0.1.2 → 0.1.3

package/dist/index.js

@@ -17755,19 +17755,74 @@ Routing tiebreakers:
 </delegation-failure>
 
 <sdd>
+## HARD GATE
+- Every SDD phase that produces an artifact MUST be dispatched to a WRITE-CAPABLE agent (@deep or @quick) with the corresponding skill loaded.
+- Oracle is READ-ONLY. NEVER use oracle to execute SDD artifact phases (propose, spec, design, tasks, apply). Oracle is ONLY for plan-review.
+- NEVER skip artifact creation. Each phase MUST produce its persistent artifact before the next phase begins.
+- NEVER jump from requirements-interview directly to implementation. The approved SDD route MUST be followed phase by phase.
+
+## Entry
 - Non-trivial work starts with requirements-interview. Skip it only for truly trivial, unambiguous work.
-- Use its result to choose direct implementation, accelerated SDD, or full SDD.
-- If persistence includes openspec and openspec/ is missing, run sdd-init first.
-- Phase order: propose -> spec -> design -> tasks -> [plan-review] -> apply -> verify -> archive.
-- Keep orchestration lean: sub-agents execute phases; you own sequencing, user gates, and progress.
+- Use its result to choose: direct implementation, accelerated SDD, or full SDD.
+- If persistence mode includes openspec and openspec/ is missing, dispatch sdd-init first.
+
+## Pipeline: Accelerated SDD (propose -> tasks)
+1. Dispatch @deep with skill \`sdd-propose\`. Wait for result. Verify artifact was persisted.
+2. Dispatch @deep with skill \`sdd-tasks\`. Wait for result. Verify artifact was persisted.
+3. Plan-review gate (see "Plan Review Gate" below).
+4. Proceed to execution: dispatch @deep or @quick with skill \`sdd-apply\` per task.
+
+## Pipeline: Full SDD (propose -> spec -> design -> tasks)
+1. Dispatch @deep with skill \`sdd-propose\`. Wait for result. Verify artifact was persisted.
+2. Dispatch @deep with skill \`sdd-spec\`. Wait for result. Verify artifact was persisted.
+3. Dispatch @deep with skill \`sdd-design\`. Wait for result. Verify artifact was persisted.
+4. Dispatch @deep with skill \`sdd-tasks\`. Wait for result. Verify artifact was persisted.
+5. Plan-review gate (see "Plan Review Gate" below).
+6. Proceed to execution: dispatch @deep or @quick with skill \`sdd-apply\` per task.
+
+## Plan Review Gate
+After tasks are generated, use \`question\` to ask the user:
+- "Review plan with @oracle before executing (Recommended)" \u2014 thorough review for correctness
+- "Proceed to execution" \u2014 skip review and start implementing
+
+If the user chooses review:
+1. Dispatch @oracle with skill \`plan-reviewer\`.
+2. If [OKAY]: proceed to execution.
+3. If [REJECT]: dispatch @deep to fix the blocking issues listed by oracle, then re-dispatch @oracle for another review.
+4. Repeat the review loop until @oracle returns [OKAY]. Do NOT proceed to execution while the plan is [REJECT].
+
+## Post-execution
+- After all tasks complete: dispatch @deep with skill \`sdd-verify\`.
+- After verification passes: dispatch @deep with skill \`sdd-archive\`.
+
+## Artifact Verification
+After each SDD phase dispatch returns, verify the artifact exists:
+- If mode includes openspec: confirm the sub-agent reported the file path.
+- If mode includes thoth-mem: confirm the sub-agent reported the topic_key.
+- If verification fails, retry the phase once. If it fails again, report to user via question.
 </sdd>
 
 <sdd-dispatch>
-When dispatching an SDD phase, include:
-1. Load skill \`sdd-{phase}\` and follow it exactly.
-2. Persistence mode: thoth-mem / openspec / hybrid / none.
-3. Change name.
-Sub-agents own phase execution. You own sequencing and progress.
+When dispatching an SDD phase, the prompt to the sub-agent MUST include ALL of:
+1. "Load skill \`sdd-{phase}\` and follow it exactly."
+2. "Persistence mode: {mode}" (one of: thoth-mem / openspec / hybrid / none).
+3. "Pipeline type: {type}" (one of: accelerated / full).
+4. "Change name: {change-name}"
+5. "Project: {project-name}" (for thoth-mem persistence).
+6. Any prior artifact context the phase needs (e.g., proposal content for spec phase).
+
+Dispatch target by phase:
+- sdd-init: @deep or @quick (write-capable, creates openspec/ structure)
+- sdd-propose: @deep (write-capable, creates proposal artifact)
+- sdd-spec: @deep (write-capable, creates spec artifact)
+- sdd-design: @deep (write-capable, needs codebase analysis + file creation)
+- sdd-tasks: @deep (write-capable, creates tasks artifact)
+- plan-reviewer: @oracle (read-only, reviews plan \u2014 the ONLY phase that uses oracle)
+- sdd-apply: @deep or @quick (write-capable, implements code changes)
+- sdd-verify: @deep (write-capable, runs verification)
+- sdd-archive: @deep (write-capable, archives change)
+
+Sub-agents own phase execution and artifact persistence. You own sequencing, progress tracking, and user gates.
 </sdd-dispatch>
 
 <progress>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oh-my-opencode-lite",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Delegate-first OpenCode plugin with seven agents, thoth-mem persistence, and bundled SDD skills.",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/src/skills/_shared/openspec-convention.md

@@ -71,10 +71,11 @@ thoth-mem.
 ## Artifact Content Rules
 
 - `proposal.md` explains why the change exists.
-- `spec.md` uses RFC 2119 keywords and Given/When/Then scenarios.
-- `design.md` explains how the change will be implemented.
+- `spec.md` uses RFC 2119 keywords and Given/When/Then scenarios (full pipeline only).
+- `design.md` explains how the change will be implemented (full pipeline only).
 - `tasks.md` is phase-based and uses Markdown checkboxes.
-- `verify-report.md` maps spec scenarios to executed evidence.
+- `verify-report.md` maps acceptance criteria to executed evidence: spec
+  scenarios in full pipeline, proposal success criteria in accelerated pipeline.
 
 ## `config.yaml` Shape
 

package/src/skills/_shared/persistence-contract.md

@@ -115,6 +115,23 @@ Always complete the 3-layer recall before using content as source material.
 - `sdd-archive` persists `sdd/{change-name}/archive-report`
 - `state` persists `sdd/{change-name}/state`
 
+## Pipeline Type Impact on Prerequisites
+
+The orchestrator passes `pipeline-type` (`accelerated` or `full`) alongside the
+persistence mode. This affects which artifacts each skill requires:
+
+| Artifact | Full pipeline | Accelerated pipeline |
+| --- | --- | --- |
+| Proposal | Required by all phases | Required by all phases (serves as acceptance reference) |
+| Spec | Required by design, tasks, apply, verify, archive | Not produced; not required |
+| Design | Required by tasks, apply, verify, archive | Not produced; not required |
+| Tasks | Required by apply, verify, archive | Required by apply, verify, archive |
+| Verify report | Required by archive | Required by archive |
+
+In accelerated pipeline, the proposal serves as the acceptance reference where
+specs would normally be used. Skills must adapt their retrieval, compliance
+checks, and archive behavior accordingly.
+
 ## Recovery Notes
 
 - Prefer exact topic-key queries over fuzzy natural-language search.

package/src/skills/_shared/thoth-mem-convention.md

@@ -51,10 +51,11 @@ transition to enable recovery:
 change: {change-name}
 phase: {last-completed-phase}
 mode: {thoth-mem|openspec|hybrid|none}
+pipeline: {accelerated|full}
 artifacts:
   proposal: true
-  spec: false
-  design: false
+  spec: false       # always false in accelerated pipeline
+  design: false     # always false in accelerated pipeline
   tasks: false
   apply-progress: false
   verify-report: false

package/src/skills/plan-reviewer/SKILL.md

@@ -19,15 +19,23 @@ to hand to implementation.
 
 ## Purpose
 
-Review `openspec/changes/{change-name}/tasks.md` for true execution blockers.
+Review the tasks artifact for true execution blockers. Retrieve it according to
+the persistence mode: read `openspec/changes/{change-name}/tasks.md` for
+openspec/hybrid modes, use thoth-mem 3-layer recall for thoth-mem/hybrid modes,
+or read from inline context for none mode.
+
 Focus on whether the plan can be executed as written, not whether you would have
 designed it differently.
 
 ## Inputs
 
 - `change-name`
-- `openspec/changes/{change-name}/tasks.md`
-- Related proposal, spec, and design artifacts when needed for dependency checks
+- `pipeline-type` (`accelerated` or `full`)
+- `persistence-mode` (`thoth-mem`, `openspec`, `hybrid`, or `none`)
+- Tasks artifact (retrieved per persistence mode: filesystem for openspec/hybrid,
+  thoth-mem for thoth-mem/hybrid, inline for none)
+- **Full pipeline**: related spec and design artifacts when needed for dependency checks
+- **Accelerated pipeline**: proposal artifact when needed for dependency checks
 
 ## Task State Awareness
 

package/src/skills/requirements-interview/SKILL.md

@@ -161,7 +161,12 @@ verify that `openspec/` is initialized. If it is not, recommend running
 `~/.config/opencode/skills/sdd-init/SKILL.md`
 
 Once route, persistence mode, and initialization are confirmed, hand off to the
-corresponding SDD pipeline phase:
+corresponding SDD pipeline phase. The handoff MUST include:
+- `pipeline-type`: `accelerated` or `full` (matching the confirmed route)
+- `persistence-mode`: the user's chosen artifact store mode
+- `change-name`: derived from the approved scope
+
+Hand off to:
 
 - **Propose**: `~/.config/opencode/skills/sdd-propose/SKILL.md`
 - **Spec** (full SDD only): `~/.config/opencode/skills/sdd-spec/SKILL.md`

package/src/skills/sdd-apply/SKILL.md

@@ -36,14 +36,20 @@ rules per mode.
 ## Prerequisites
 
 - `change-name`
+- `pipeline-type` (`accelerated` or `full`)
 - Assigned task numbers or phase range
-- Spec, design, and task artifacts
+- Task artifact
+- Spec and design artifacts (full pipeline only)
+- Proposal artifact (accelerated pipeline — used as the acceptance reference)
 
 ## Workflow
 
 1. Read the shared conventions.
-2. Recover `spec`, `design`, and `tasks` with the retrieval protocol in
-   `~/.config/opencode/skills/_shared/persistence-contract.md`.
+2. Recover artifacts with the retrieval protocol in
+   `~/.config/opencode/skills/_shared/persistence-contract.md`:
+   - **Always**: recover `tasks`
+   - **Full pipeline**: recover `spec` and `design`
+   - **Accelerated pipeline**: recover `proposal` (used as the acceptance reference)
 3. Read the affected code before editing anything.
 4. Execute only the assigned checklist items.
 5. In modes that include thoth-mem, persist an implementation progress report
@@ -81,11 +87,12 @@ via the `executing-plans` skill. Do not update task checkboxes yourself.
 
 ## Rules
 
-- Read specs before implementing; they are the acceptance contract.
+- Read the acceptance contract before implementing: specs in full pipeline,
+  proposal in accelerated pipeline.
 - Follow the design unless you explicitly report a justified deviation.
 - Update only the tasks assigned in the current batch.
 - Persist the progress artifact whenever the selected mode includes thoth-mem.
 - Retrieve every SDD dependency with the mode-aware protocol in
   `~/.config/opencode/skills/_shared/persistence-contract.md`.
 - Return structured execution evidence to the orchestrator so it can manage task
-  state correctly.
+  state correctly.

package/src/skills/sdd-archive/SKILL.md

@@ -35,22 +35,27 @@ rules per mode.
 ## Prerequisites
 
 - `change-name`
-- Spec artifact
-- Design artifact
+- `pipeline-type` (`accelerated` or `full`)
 - Tasks artifact
 - Verify report artifact
+- Spec artifact (full pipeline only)
+- Design artifact (full pipeline only)
+- Proposal artifact (always — used for audit trail)
 
 ## Workflow
 
 1. Read the shared conventions.
-2. Recover `spec`, `design`, `tasks`, and `verify-report` through the
-   retrieval protocol in
-   `~/.config/opencode/skills/_shared/persistence-contract.md`.
+2. Recover artifacts through the retrieval protocol in
+   `~/.config/opencode/skills/_shared/persistence-contract.md`:
+   - **Always**: recover `proposal`, `tasks`, and `verify-report`
+   - **Full pipeline only**: recover `spec` and `design`
 3. Refuse to archive if the verification report still contains unresolved
    critical failures.
-4. If the selected mode includes OpenSpec, merge every change spec from
+4. If the selected mode includes OpenSpec and the pipeline is full, merge
+   every change spec from
    `openspec/changes/{change-name}/specs/{domain}/spec.md` into
-   `openspec/specs/{domain}/spec.md`.
+   `openspec/specs/{domain}/spec.md`. In accelerated pipeline, skip the
+   spec merge (no delta specs exist).
 5. If the selected mode includes OpenSpec, move the completed change directory
    to `openspec/changes/archive/YYYY-MM-DD-{change-name}/`.
 6. Create an audit trail report summarizing merged domains, archive location,
@@ -84,7 +89,8 @@ Return:
 ## Rules
 
 - Archive only after verification is acceptable.
-- Merge delta specs before moving the change folder.
+- In full pipeline, merge delta specs before moving the change folder.
+  In accelerated pipeline, skip the spec merge (no delta specs exist).
 - Preserve canonical spec structure and untouched requirements.
 - Persist the final audit trail through thoth-mem when the selected mode
   includes it.

package/src/skills/sdd-propose/SKILL.md

@@ -87,7 +87,7 @@ Return a short report with:
 - `Artifact`: `openspec/changes/{change-name}/proposal.md`
 - `Topic Key`: `sdd/{change-name}/proposal`
 - `Summary`: 2-4 bullets covering intent, scope, and major risks
-- `Next Step`: usually `sdd-spec` or `sdd-design`
+- `Next Step`: `sdd-spec` (full pipeline) or `sdd-tasks` (accelerated pipeline)
 
 ## Rules
 

package/src/skills/sdd-tasks/SKILL.md

@@ -28,21 +28,26 @@ rules per mode.
 
 ## When to Use
 
-- Proposal, spec, and design are ready for execution planning
-- A task plan must be refreshed after design or scope changes
+- **Full pipeline**: proposal, spec, and design are ready for execution planning
+- **Accelerated pipeline**: proposal is ready and spec/design are intentionally skipped
+- A task plan must be refreshed after scope changes
 
 ## Prerequisites
 
 - `change-name`
+- `pipeline-type` (`accelerated` or `full`)
 - Proposal artifact
-- Spec artifact
-- Design artifact
+- Spec artifact (full pipeline only)
+- Design artifact (full pipeline only)
 
 ## Workflow
 
 1. Read the shared conventions.
-2. Recover `proposal`, `spec`, and `design` via the retrieval protocol in
-   `~/.config/opencode/skills/_shared/persistence-contract.md`.
+2. Recover artifacts via the retrieval protocol in
+   `~/.config/opencode/skills/_shared/persistence-contract.md`:
+   - **Always**: recover `proposal`
+   - **Full pipeline only**: recover `spec` and `design`
+   - In accelerated pipeline, derive task structure directly from the proposal.
 3. If a task plan already exists, recover `sdd/{change-name}/tasks` with the
    same mode-aware retrieval rules before rewriting it.
 4. Build a phased checklist for `openspec/changes/{change-name}/tasks.md`. In

package/src/skills/sdd-verify/SKILL.md

@@ -35,16 +35,21 @@ rules per mode.
 ## Prerequisites
 
 - `change-name`
-- Spec artifact
-- Design artifact
 - Tasks artifact
+- `pipeline-type` (`accelerated` or `full`)
+- Spec artifact (full pipeline only)
+- Design artifact (full pipeline only)
+- Proposal artifact (accelerated pipeline — used as the verification reference)
 - Ability to run the relevant checks or tests
 
 ## Workflow
 
 1. Read the shared conventions.
-2. Recover `spec`, `design`, and `tasks` with the retrieval protocol in
-   `~/.config/opencode/skills/_shared/persistence-contract.md`.
+2. Recover artifacts with the retrieval protocol in
+   `~/.config/opencode/skills/_shared/persistence-contract.md`:
+   - **Always**: recover `tasks`
+   - **Full pipeline**: recover `spec` and `design`
+   - **Accelerated pipeline**: recover `proposal` (used as the verification reference)
 3. Optionally recover `apply-progress` with the same mode-aware rules if it
    exists and helps explain task coverage.
 4. Read the changed code and run the required verification commands.
@@ -54,19 +59,22 @@ rules per mode.
    In `thoth-mem` mode, produce the same report content without creating the
    file:
 
-   ```md
-   # Verification Report: {Change Title}
-
-   ## Completeness
-   ## Build and Test Evidence
-   ## Spec Compliance Matrix
-   ## Design Coherence
-   ## Issues Found
-   ## Verdict
-   ```
-
-6. Build a compliance matrix that maps each Given/When/Then scenario to the test
-   or execution evidence that proved it.
+    ```md
+    # Verification Report: {Change Title}
+
+    ## Completeness
+    ## Build and Test Evidence
+    ## Compliance Matrix
+    <!-- Full pipeline: map Given/When/Then scenarios from spec -->
+    <!-- Accelerated pipeline: map success criteria from proposal -->
+    ## Design Coherence (full pipeline only)
+    ## Issues Found
+    ## Verdict
+    ```
+
+6. Build a compliance matrix: in full pipeline, map each Given/When/Then
+   scenario to evidence; in accelerated pipeline, map each proposal success
+   criterion to evidence.
 7. If the selected mode includes thoth-mem, persist the report with:
 
    ```text
@@ -94,7 +102,8 @@ Return:
 ## Rules
 
 - Verification requires real evidence, not only static inspection.
-- Every spec scenario must appear in the compliance matrix.
+- Every acceptance criterion must appear in the compliance matrix: spec
+  scenarios in full pipeline, proposal success criteria in accelerated pipeline.
 - Distinguish blockers from warnings clearly.
 - Do not fix issues inside this phase; report them.
 - Recover full artifacts with the protocol in