super-opencode 1.1.0 → 1.1.2

package/.opencode/commands/soc-test.md

@@ -1,109 +1,109 @@
----
-description: Test generation and execution
----
-
-# /soc-test
-
-## 1. Command Overview
-The `/soc-test` command is the "Quality Gatekeeper." It generates, runs, and reports on tests. It ensures that no code is shipped without verification. It triggers the `quality` agent to write unit, integration, or E2E tests and uses the `reviewer` agent to analyze coverage.
-
-## 2. Triggers & Routing
-The command determines the scope and tool based on the arguments.
-
-| Trigger Scenario | Flag | Target Agent | Tool Used |
-| :--- | :--- | :--- | :--- |
-| **Unit Testing** | `--type unit` | `[quality]` | Jest/Vitest |
-| **Integration** | `--type integration` | `[quality]` | Supertest/Pytest |
-| **E2E Flows** | `--type e2e` | `[quality]` | Playwright/Cypress |
-| **Coverage Check**| `--coverage` | `[reviewer]` | Istanbul/C8 |
-
-## 3. Usage & Arguments
-```bash
-/soc-test [target] [flags]
-```
-
-### Arguments
--   **`[target]`**: File or directory to test (e.g., `src/utils/math.ts`).
-
-### Flags
--   **`--type [unit|integration|e2e]`**: (Optional) Default: `unit`.
--   **`--coverage`**: Generates a coverage report.
--   **`--watch`**: Runs in watch mode (interactive).
-
-## 4. Behavioral Flow (Orchestration)
-
-### Phase 1: Context & Gap Analysis
-1.  **Read**: Analyzes the source code in `[target]`.
-2.  **Scan**: Checks for existing `.test.ts` or `_test.py` files.
-3.  **Plan**: Identifies missing test cases (Edge cases, Error states, Happy path).
-
-### Phase 2: Generation (The Writer)
-The command prompts the `quality` agent:
-> "Generate **[Type]** tests for **[Target]**.
-> Ensure **[Coverage]**.
-> Mock dependencies: **[External Services]**."
-
-### Phase 3: Execution (The Runner)
-1.  **Run**: Executes the test command (e.g., `npm test`).
-2.  **Report**: Captures `stdout/stderr`.
-3.  **Reflect**: If tests fail, it suggests fixes (or fixes them if in `implement` mode).
-
-## 5. Output Guidelines (The Contract)
-
-### Test Execution Report
-```markdown
-## Test Report: [Target]
-
-### 1. Summary
--   **Status**: ❌ FAILED (2/10 failed)
--   **Time**: 1.2s
-
-### 2. Failures
--   **Test**: `should return 400 on invalid email`
-    -   **Expected**: `400`
-    -   **Received**: `500`
-    -   **Diagnosis**: Unhandled exception in controller.
-
-### 3. Coverage
--   **Line**: 85%
--   **Branch**: 70% (Missing: `if (!user)`)
-```
-
-## 6. Examples
-
-### A. Unit Test Generation
-```bash
-/soc-test src/utils/currency.ts --type unit
-```
-*Effect:* Generates `src/utils/currency.test.ts` covering rounding logic and currency codes.
-
-### B. Integration Test
-```bash
-/soc-test src/api/auth --type integration
-```
-*Effect:* Sets up a mock database and tests the `/login` flow including DB persistence.
-
-## 7. Dependencies & Capabilities
-
-### Agents
--   **Quality Assurance**: `@[.opencode/agents/quality.md]` - Primary agent for test generation.
--   **Reviewer**: `@[.opencode/agents/reviewer.md]` - For evaluating test coverage and effectiveness.
-
-### Skills
--   **Self Check**: `@[.opencode/skills/self-check/SKILL.md]` - Verifying test results against requirements.
--   **Debug Protocol**: `@[.opencode/skills/debug-protocol/SKILL.md]` - Analyzing test failures.
-
-### MCP Integration
--   **`run_command`**: Executing test runners (Jest, Vitest, Pytest).
--   **`filesystem`**: processing integration test artifacts or coverage reports.
-
-## 8. Boundaries
-
-**Will:**
--   Generate standard test files using the project's framework.
--   Run tests and parse output.
--   Mock external dependencies (S3, Stripe) to prevent flake.
-
-**Will Not:**
--   **Guarantee 100% Logic Coverage**: It covers code paths, not necessarily business intent.
--   **Debug Production**: Tests run in `test` environment only.
+---
+description: Test generation and execution
+---
+
+# /soc-test
+
+## 1. Command Overview
+The `/soc-test` command is the "Quality Gatekeeper." It generates, runs, and reports on tests. It ensures that no code is shipped without verification. It triggers the `quality` agent to write unit, integration, or E2E tests and uses the `reviewer` agent to analyze coverage.
+
+## 2. Triggers & Routing
+The command determines the scope and tool based on the arguments.
+
+| Trigger Scenario | Flag | Target Agent | Tool Used |
+| :--- | :--- | :--- | :--- |
+| **Unit Testing** | `--type unit` | `[quality]` | Jest/Vitest |
+| **Integration** | `--type integration` | `[quality]` | Supertest/Pytest |
+| **E2E Flows** | `--type e2e` | `[quality]` | Playwright/Cypress |
+| **Coverage Check**| `--coverage` | `[reviewer]` | Istanbul/C8 |
+
+## 3. Usage & Arguments
+```bash
+/soc-test [target] [flags]
+```
+
+### Arguments
+-   **`[target]`**: File or directory to test (e.g., `src/utils/math.ts`).
+
+### Flags
+-   **`--type [unit|integration|e2e]`**: (Optional) Default: `unit`.
+-   **`--coverage`**: Generates a coverage report.
+-   **`--watch`**: Runs in watch mode (interactive).
+
+## 4. Behavioral Flow (Orchestration)
+
+### Phase 1: Context & Gap Analysis
+1.  **Read**: Analyzes the source code in `[target]`.
+2.  **Scan**: Checks for existing `.test.ts` or `_test.py` files.
+3.  **Plan**: Identifies missing test cases (Edge cases, Error states, Happy path).
+
+### Phase 2: Generation (The Writer)
+The command prompts the `quality` agent:
+> "Generate **[Type]** tests for **[Target]**.
+> Ensure **[Coverage]**.
+> Mock dependencies: **[External Services]**."
+
+### Phase 3: Execution (The Runner)
+1.  **Run**: Executes the test command (e.g., `npm test`).
+2.  **Report**: Captures `stdout/stderr`.
+3.  **Reflect**: If tests fail, it suggests fixes (or fixes them if in `implement` mode).
+
+## 5. Output Guidelines (The Contract)
+
+### Test Execution Report
+```markdown
+## Test Report: [Target]
+
+### 1. Summary
+-   **Status**: ❌ FAILED (2/10 failed)
+-   **Time**: 1.2s
+
+### 2. Failures
+-   **Test**: `should return 400 on invalid email`
+    -   **Expected**: `400`
+    -   **Received**: `500`
+    -   **Diagnosis**: Unhandled exception in controller.
+
+### 3. Coverage
+-   **Line**: 85%
+-   **Branch**: 70% (Missing: `if (!user)`)
+```
+
+## 6. Examples
+
+### A. Unit Test Generation
+```bash
+/soc-test src/utils/currency.ts --type unit
+```
+*Effect:* Generates `src/utils/currency.test.ts` covering rounding logic and currency codes.
+
+### B. Integration Test
+```bash
+/soc-test src/api/auth --type integration
+```
+*Effect:* Sets up a mock database and tests the `/login` flow including DB persistence.
+
+## 7. Dependencies & Capabilities
+
+### Agents
+-   **Quality Assurance**: `@[.opencode/agents/quality.md]` - Primary agent for test generation.
+-   **Reviewer**: `@[.opencode/agents/reviewer.md]` - For evaluating test coverage and effectiveness.
+
+### Skills
+-   **Self Check**: `@[.opencode/skills/self-check/SKILL.md]` - Verifying test results against requirements.
+-   **Debug Protocol**: `@[.opencode/skills/debug-protocol/SKILL.md]` - Analyzing test failures.
+
+### MCP Integration
+-   **`run_command`**: Executing test runners (Jest, Vitest, Pytest).
+-   **`filesystem`**: processing integration test artifacts or coverage reports.
+
+## 8. Boundaries
+
+**Will:**
+-   Generate standard test files using the project's framework.
+-   Run tests and parse output.
+-   Mock external dependencies (S3, Stripe) to prevent flake.
+
+**Will Not:**
+-   **Guarantee 100% Logic Coverage**: It covers code paths, not necessarily business intent.
+-   **Debug Production**: Tests run in `test` environment only.

package/.opencode/commands/soc-workflow.md

@@ -1,97 +1,97 @@
----
-description: Custom workflow creation and execution
----
-
-# /soc-workflow
-
-## 1. Command Overview
-The `/soc-workflow` command is the "Factory." It allows users to create, list, and run custom sequences of agent commands. It turns a manual, multi-step process (e.g., "Check status -> Pull -> Build -> Deploy") into a single executable command.
-
-## 2. Triggers & Routing
-The command is a meta-orchestrator.
-
-| Trigger Scenario | Flag | Action |
-| :--- | :--- | :--- |
-| **New Automation** | `create` | Templates a new `.md` file in `.agent/workflows/` |
-| **Run Automation** | `run` | Parses and executes the steps in order |
-| **List Available** | `list` | Scans directory for `.md` files |
-
-## 3. Usage & Arguments
-```bash
-/soc-workflow [action] [name]
-```
-
-### Arguments
--   **`[action]`**: `create`, `run`, `list`, `edit`, `delete`.
--   **`[name]`**: Name of the workflow (e.g., `deploy`).
-
-## 4. Behavioral Flow (Orchestration)
-
-### Phase 1: Definition (Create)
-1.  **Template**: Creates a standard markdown file with "Steps."
-2.  **Define**: User fills in shell commands or agent commands (`/soc-git`, `/soc-test`).
-
-### Phase 2: Execution (Run)
-1.  **Parse**: Reads the markdown.
-2.  **Step**: Executes step 1.
-3.  **Check**: If step 1 fails, stop (unless `continue_on_error: true`).
-4.  **Next**: Proceed to step 2.
-
-## 5. Output Guidelines (The Contract)
-
-### Workflow Definition (Template)
-```markdown
----
-description: Deploy to Staging
----
-# Deploy Staging
-1.  **Test**: `/soc-test --type e2e`
-2.  **Build**: `npm run build`
-3.  **Deploy**: `/soc-git push origin staging`
-```
-
-### Execution Log
-```markdown
-## Workflow: Deploy Staging
-1.  [x] **Test**: Passed (2s)
-2.  [x] **Build**: Passed (15s)
-3.  [x] **Deploy**: Pushed a1b2c3d
-✅ Workflow Complete
-```
-
-## 6. Examples
-
-### A. Create Release Workflow
-```bash
-/soc-workflow create release
-```
-*Effect:* Creates `.agent/workflows/release.md` for the user to edit.
-
-### B. Run Nightly Build
-```bash
-/soc-workflow run nightly
-```
-*Effect:* Runs the sequence defined in `nightly.md`.
-
-## 7. Dependencies & Capabilities
-
-### Agents
--   **PM Agent**: `@[.opencode/agents/pm-agent.md]` - For oversight.
-
-### Skills
--   **None**: It relies on other commands.
-
-### MCP Integration
--   **`filesystem`**: Reading/Writing workflow files.
--   **`run_command`**: Executing shell steps.
-
-## 8. Boundaries
-
-**Will:**
--   Execute commands in sequence.
--   Stop on error.
--   Pass context between steps.
-
-**Will Not:**
--   **Auto-Debug**: If a step fails, the workflow just stops.
--   **Parallize**: Steps are currently sequential only.
+---
+description: Custom workflow creation and execution
+---
+
+# /soc-workflow
+
+## 1. Command Overview
+The `/soc-workflow` command is the "Factory." It allows users to create, list, and run custom sequences of agent commands. It turns a manual, multi-step process (e.g., "Check status -> Pull -> Build -> Deploy") into a single executable command.
+
+## 2. Triggers & Routing
+The command is a meta-orchestrator.
+
+| Trigger Scenario | Flag | Action |
+| :--- | :--- | :--- |
+| **New Automation** | `create` | Templates a new `.md` file in `.agent/workflows/` |
+| **Run Automation** | `run` | Parses and executes the steps in order |
+| **List Available** | `list` | Scans directory for `.md` files |
+
+## 3. Usage & Arguments
+```bash
+/soc-workflow [action] [name]
+```
+
+### Arguments
+-   **`[action]`**: `create`, `run`, `list`, `edit`, `delete`.
+-   **`[name]`**: Name of the workflow (e.g., `deploy`).
+
+## 4. Behavioral Flow (Orchestration)
+
+### Phase 1: Definition (Create)
+1.  **Template**: Creates a standard markdown file with "Steps."
+2.  **Define**: User fills in shell commands or agent commands (`/soc-git`, `/soc-test`).
+
+### Phase 2: Execution (Run)
+1.  **Parse**: Reads the markdown.
+2.  **Step**: Executes step 1.
+3.  **Check**: If step 1 fails, stop (unless `continue_on_error: true`).
+4.  **Next**: Proceed to step 2.
+
+## 5. Output Guidelines (The Contract)
+
+### Workflow Definition (Template)
+```markdown
+---
+description: Deploy to Staging
+---
+# Deploy Staging
+1.  **Test**: `/soc-test --type e2e`
+2.  **Build**: `npm run build`
+3.  **Deploy**: `/soc-git push origin staging`
+```
+
+### Execution Log
+```markdown
+## Workflow: Deploy Staging
+1.  [x] **Test**: Passed (2s)
+2.  [x] **Build**: Passed (15s)
+3.  [x] **Deploy**: Pushed a1b2c3d
+✅ Workflow Complete
+```
+
+## 6. Examples
+
+### A. Create Release Workflow
+```bash
+/soc-workflow create release
+```
+*Effect:* Creates `.agent/workflows/release.md` for the user to edit.
+
+### B. Run Nightly Build
+```bash
+/soc-workflow run nightly
+```
+*Effect:* Runs the sequence defined in `nightly.md`.
+
+## 7. Dependencies & Capabilities
+
+### Agents
+-   **PM Agent**: `@[.opencode/agents/pm-agent.md]` - For oversight.
+
+### Skills
+-   **None**: It relies on other commands.
+
+### MCP Integration
+-   **`filesystem`**: Reading/Writing workflow files.
+-   **`run_command`**: Executing shell steps.
+
+## 8. Boundaries
+
+**Will:**
+-   Execute commands in sequence.
+-   Stop on error.
+-   Pass context between steps.
+
+**Will Not:**
+-   **Auto-Debug**: If a step fails, the workflow just stops.
+-   **Parallize**: Steps are currently sequential only.

package/.opencode/settings.json

@@ -1,3 +1,3 @@
-{
-  "version": "1.1.0"
-}
+{
+  "version": "1.1.0"
+}

package/.opencode/skills/confidence-check/SKILL.md

@@ -1,97 +1,97 @@
----
-name: confidence-check
-description: Pre-execution risk assessment to prevent hallucinations and architectural drift.
----
-
-# Confidence Check Skill
-
-## Purpose
-To calculate a probabilistic "Success Score" (0.0 - 1.0) **before** generating code. This acts as a circuit breaker for the `execution` mode.
-
-**ROI Metric**: A 200-token analysis prevents 2,000+ tokens of incorrect code generation and subsequent debugging time.
-
-## When to Use
-- **Automatic Trigger**: Before any `write_file` operation affecting > 50 lines of code.
-- **Manual Trigger**: When requirements are vague (e.g., "Fix the bug").
-- **Agent Handoff**: When `pm-agent` assigns a task to `backend` or `frontend`.
-
-## The 5 Pillars of Confidence
-
-| Pillar | Weight | Verification Action | Related Agent |
-| :--- | :--- | :--- | :--- |
-| **1. Context Awareness** | 25% | Have I read *all* related files? (grep/read_file) | `pm-agent` |
-| **2. Specification** | 25% | Do I have a clear Interface/Schema? (Zod/Types) | `architect` |
-| **3. Ground Truth** | 20% | Do I have *current* docs? (No hallucinations) | `researcher` |
-| **4. Pattern Matching** | 15% | Does this match existing project style? | `review` |
-| **5. Impact Analysis** | 15% | Do I know what this might break? | `quality` |
-
-## Scoring & Protocols
-
-### 🟢 High Confidence (≥ 0.90)
-**Action**: **PROCEED** to `execution` mode.
-*   *Definition:* You have the file paths, the schema is defined, you have verified the library version, and you have a rollback plan.
-
-### 🟡 Medium Confidence (0.70 - 0.89)
-**Action**: **REFINE** before coding.
-*   *Protocol:* Identify the weak pillar and fix it.
-    *   *Weak Docs?* -> Trigger `researcher` to fetch API refs.
-    *   *Weak Specs?* -> Trigger `architect` to define the interface.
-    *   *Weak Context?* -> Run `grep` to find usages.
-
-### 🔴 Low Confidence (< 0.70)
-**Action**: **HALT**.
-*   *Protocol:* Do not write code. Return control to `pm-agent` or ask the user clarifying questions.
-    *   *Example:* "I cannot proceed. I do not know the expected return type of the API, and I cannot find a design pattern for this module."
-
-## Execution Template
-
-*Copy this mental scratchpad into your context window before coding.*
-
-```markdown
-## 🛡️ Pre-Flight Confidence Check
-
-### 1. Context Audit (25%)
-- [ ] Mapped dependency tree? (Yes/No)
-- [ ] Checked for duplicate logic via `grep`? (Yes/No)
-- **Score: __ / 0.25**
-
-### 2. Spec Validation (25%)
-- [ ] Is the Input/Output clearly typed (TypeScript/Zod)?
-- [ ] Does an ADR or RFC exist for this?
-- **Score: __ / 0.25** -> *If 0, consult `architect`*
-
-### 3. Documentation Reality (20%)
-- [ ] Did I look up the library docs *today*?
-- [ ] Am I guessing the API syntax?
-- **Score: __ / 0.20** -> *If 0, consult `researcher`*
-
-### 4. Local Patterns (15%)
-- [ ] Am I using the project's established styling/naming?
-- **Score: __ / 0.15**
-
-### 5. Risk Assessment (15%)
-- [ ] If this fails, does the app crash or just error out?
-- [ ] Do I have a test case ready to verify this?
-- **Score: __ / 0.15** -> *If 0, consult `quality`*
-
-### 🏁 Final Score: [ 0.00 - 1.00 ]
-**Verdict:** [ PROCEED / REFINE / HALT ]
-```
-
-## Scenario Examples
-
-### Scenario A: Adding a new API Endpoint
-*   **Context**: Read `server.ts`? Yes.
-*   **Spec**: No request schema defined. (**0**)
-*   **Docs**: Know Express well. (0.2)
-*   **Pattern**: Copied existing controller style. (0.15)
-*   **Risk**: Low. (0.15)
-*   **Total**: **0.75 (Medium)**
-*   **Action**: *STOP. Call `backend` agent to define Zod schema first. Then Proceed.*
-
-### Scenario B: "Fix the white screen"
-*   **Context**: No error logs provided. (**0**)
-*   **Spec**: Unknown. (**0**)
-*   **Docs**: N/A.
-*   **Total**: **0.15 (Low)**
-*   **Action**: *HALT. Ask user for logs or reproduction steps. Trigger `brainstorming` mode.*
+---
+name: confidence-check
+description: Pre-execution risk assessment to prevent hallucinations and architectural drift.
+---
+
+# Confidence Check Skill
+
+## Purpose
+To calculate a probabilistic "Success Score" (0.0 - 1.0) **before** generating code. This acts as a circuit breaker for the `execution` mode.
+
+**ROI Metric**: A 200-token analysis prevents 2,000+ tokens of incorrect code generation and subsequent debugging time.
+
+## When to Use
+- **Automatic Trigger**: Before any `write_file` operation affecting > 50 lines of code.
+- **Manual Trigger**: When requirements are vague (e.g., "Fix the bug").
+- **Agent Handoff**: When `pm-agent` assigns a task to `backend` or `frontend`.
+
+## The 5 Pillars of Confidence
+
+| Pillar | Weight | Verification Action | Related Agent |
+| :--- | :--- | :--- | :--- |
+| **1. Context Awareness** | 25% | Have I read *all* related files? (grep/read_file) | `pm-agent` |
+| **2. Specification** | 25% | Do I have a clear Interface/Schema? (Zod/Types) | `architect` |
+| **3. Ground Truth** | 20% | Do I have *current* docs? (No hallucinations) | `researcher` |
+| **4. Pattern Matching** | 15% | Does this match existing project style? | `review` |
+| **5. Impact Analysis** | 15% | Do I know what this might break? | `quality` |
+
+## Scoring & Protocols
+
+### 🟢 High Confidence (≥ 0.90)
+**Action**: **PROCEED** to `execution` mode.
+*   *Definition:* You have the file paths, the schema is defined, you have verified the library version, and you have a rollback plan.
+
+### 🟡 Medium Confidence (0.70 - 0.89)
+**Action**: **REFINE** before coding.
+*   *Protocol:* Identify the weak pillar and fix it.
+    *   *Weak Docs?* -> Trigger `researcher` to fetch API refs.
+    *   *Weak Specs?* -> Trigger `architect` to define the interface.
+    *   *Weak Context?* -> Run `grep` to find usages.
+
+### 🔴 Low Confidence (< 0.70)
+**Action**: **HALT**.
+*   *Protocol:* Do not write code. Return control to `pm-agent` or ask the user clarifying questions.
+    *   *Example:* "I cannot proceed. I do not know the expected return type of the API, and I cannot find a design pattern for this module."
+
+## Execution Template
+
+*Copy this mental scratchpad into your context window before coding.*
+
+```markdown
+## 🛡️ Pre-Flight Confidence Check
+
+### 1. Context Audit (25%)
+- [ ] Mapped dependency tree? (Yes/No)
+- [ ] Checked for duplicate logic via `grep`? (Yes/No)
+- **Score: __ / 0.25**
+
+### 2. Spec Validation (25%)
+- [ ] Is the Input/Output clearly typed (TypeScript/Zod)?
+- [ ] Does an ADR or RFC exist for this?
+- **Score: __ / 0.25** -> *If 0, consult `architect`*
+
+### 3. Documentation Reality (20%)
+- [ ] Did I look up the library docs *today*?
+- [ ] Am I guessing the API syntax?
+- **Score: __ / 0.20** -> *If 0, consult `researcher`*
+
+### 4. Local Patterns (15%)
+- [ ] Am I using the project's established styling/naming?
+- **Score: __ / 0.15**
+
+### 5. Risk Assessment (15%)
+- [ ] If this fails, does the app crash or just error out?
+- [ ] Do I have a test case ready to verify this?
+- **Score: __ / 0.15** -> *If 0, consult `quality`*
+
+### 🏁 Final Score: [ 0.00 - 1.00 ]
+**Verdict:** [ PROCEED / REFINE / HALT ]
+```
+
+## Scenario Examples
+
+### Scenario A: Adding a new API Endpoint
+*   **Context**: Read `server.ts`? Yes.
+*   **Spec**: No request schema defined. (**0**)
+*   **Docs**: Know Express well. (0.2)
+*   **Pattern**: Copied existing controller style. (0.15)
+*   **Risk**: Low. (0.15)
+*   **Total**: **0.75 (Medium)**
+*   **Action**: *STOP. Call `backend` agent to define Zod schema first. Then Proceed.*
+
+### Scenario B: "Fix the white screen"
+*   **Context**: No error logs provided. (**0**)
+*   **Spec**: Unknown. (**0**)
+*   **Docs**: N/A.
+*   **Total**: **0.15 (Low)**
+*   **Action**: *HALT. Ask user for logs or reproduction steps. Trigger `brainstorming` mode.*