owflow 0.1.10 → 0.3.0

package/dist/__tests__/verify_template.test.js

@@ -1,102 +0,0 @@
-import { expect, test, describe, beforeAll, afterAll } from "bun:test";
-import fs from "node:fs";
-import path from "node:path";
-import { fileURLToPath } from "node:url";
-import { verify_template } from "../tools/verify_template.js";
-const __dirname = path.dirname(fileURLToPath(import.meta.url));
-describe("verify_template tool", () => {
-    const templatesDir = path.join(__dirname, "../templates");
-    const testDir = path.join(__dirname, "test_tmp_dir");
-    const testTemplateName = "test-template.yml";
-    const testTemplatePath = path.join(templatesDir, testTemplateName);
-    beforeAll(() => {
-        // Ensure templates dir exists
-        if (!fs.existsSync(templatesDir)) {
-            fs.mkdirSync(templatesDir, { recursive: true });
-        }
-        // Create a dummy template
-        fs.writeFileSync(testTemplatePath, `
-key1: value1
-key2:
-  subKey1: subValue1
-      `);
-        // Ensure test dir exists
-        if (!fs.existsSync(testDir)) {
-            fs.mkdirSync(testDir, { recursive: true });
-        }
-    });
-    afterAll(() => {
-        // Cleanup
-        if (fs.existsSync(testTemplatePath)) {
-            fs.rmSync(testTemplatePath);
-        }
-        if (fs.existsSync(testDir)) {
-            fs.rmSync(testDir, { recursive: true, force: true });
-        }
-    });
-    test("should return error if file not found", async () => {
-        const result = await verify_template.execute({ filePath: "nonexistent.yml", templateName: testTemplateName }, { directory: testDir });
-        expect(result.output).toContain("File not found at nonexistent.yml");
-    });
-    test("should return error if template not found", async () => {
-        const filePath = "target.yml";
-        fs.writeFileSync(path.join(testDir, filePath), "key1: value");
-        const result = await verify_template.execute({ filePath, templateName: "nonexistent-template.yml" }, { directory: testDir });
-        expect(result.output).toContain("Template 'nonexistent-template.yml' not found");
-    });
-    test("should return error if target file has invalid YAML syntax", async () => {
-        const filePath = "invalid.yml";
-        fs.writeFileSync(path.join(testDir, filePath), "key1: : value\n  invalid");
-        const result = await verify_template.execute({ filePath, templateName: testTemplateName }, { directory: testDir });
-        expect(result.output).toContain("YAML Syntax Error in invalid.yml");
-    });
-    test("should return error if target file is missing keys from template", async () => {
-        const filePath = "missing-keys.yml";
-        // Missing key2
-        fs.writeFileSync(path.join(testDir, filePath), "key1: some-value");
-        const result = await verify_template.execute({ filePath, templateName: testTemplateName }, { directory: testDir });
-        expect(result.output).toContain("YAML Structure Validation Failed");
-        expect(result.output).toContain("- Missing key: key2");
-    });
-    test("should pass if target file matches template structure", async () => {
-        const filePath = "valid.yml";
-        fs.writeFileSync(path.join(testDir, filePath), `
-key1: different_value
-key2:
-  subKey1: different_sub_value
-extraKey: this is fine
-      `);
-        const result = await verify_template.execute({ filePath, templateName: testTemplateName }, { directory: testDir });
-        expect(result.output).toBe("File exists and follows the correct YAML structure.");
-    });
-    test("should pass if template has null or non-object values and target has them too", async () => {
-        const nullTemplateName = "null-template.yml";
-        const nullTemplatePath = path.join(templatesDir, nullTemplateName);
-        fs.writeFileSync(nullTemplatePath, "key: null\nother: 123");
-        const filePath = "valid-null.yml";
-        fs.writeFileSync(path.join(testDir, filePath), "key: something\nother: 456");
-        const result = await verify_template.execute({ filePath, templateName: nullTemplateName }, { directory: testDir });
-        expect(result.output).toBe("File exists and follows the correct YAML structure.");
-        fs.rmSync(nullTemplatePath);
-    });
-    describe("real templates validation", () => {
-        let templateFiles = [];
-        try {
-            const files = fs.readdirSync(templatesDir);
-            templateFiles = files.filter(f => f.endsWith('.yml') || f.endsWith('.yaml') || f.endsWith('.md'));
-            // Filter out our dummy test template
-            templateFiles = templateFiles.filter(f => f !== "test-template.yml" && f !== "null-template.yml");
-        }
-        catch (e) {
-            // templates dir might not exist or be readable in some contexts, though beforeAll ensures it exists
-        }
-        for (const templateName of templateFiles) {
-            test(`should successfully validate a valid instance of ${templateName}`, async () => {
-                // We use the templates directory as the working directory 
-                // and the template name as the filePath, effectively comparing the template to itself to ensure it's structurally valid.
-                const result = await verify_template.execute({ filePath: templateName, templateName }, { directory: templatesDir });
-                expect(result.output).toBe("File exists and follows the correct YAML structure.");
-            });
-        }
-    });
-});

package/dist/commands/quick-bugfix.md

@@ -1,37 +0,0 @@
----
-name: quick-bugfix
-description: Quick bug fix with TDD red/green gates and complexity escalation
-argument-hint: "[bug description]"
-generated-from-skill: true
----
-
-CRITICAL INSTRUCTION: You MUST invoke the quick-bugfix skill immediately as your FIRST action.
-
-Use the Skill tool with these exact parameters:
-name: "quick-bugfix"
-prompt: "$ARGUMENTS"
-
-DO NOT:
-
-- Analyze the task before invoking the skill
-- Decide the task is "straightforward" and skip the skill
-- Substitute your own approach or workflow
-- Execute any part of the workflow yourself
-
-WHY: The user explicitly chose this workflow by using /quick-bugfix.
-Invoke the skill now and let it orchestrate the complete workflow.
-
----
-
-## About This Workflow
-
-Quick bug fix with TDD red/green gates and complexity escalation
-
-The skill handles:
-
-- Task directory creation and state management
-- Phase execution with interactive gates
-- Subagent delegation for specialized work
-- Pause/resume capability
-
-See `skills/quick-bugfix/SKILL.md` for complete workflow documentation.

package/dist/commands/quick-dev.md

@@ -1,182 +0,0 @@
----
-name: quick-dev
-description: Implement task directly with AI SDLC standards awareness (no planning mode)
----
-
-# Quick Development with Standards Awareness
-
-Implement a task directly without entering planning mode, while still applying project standards from `.owflow/docs/`.
-
-## Usage
-
-```bash
-/quick-dev [task description]
-```
-
-## Examples
-
-```bash
-/quick-dev "Add a logout button to the navbar"
-/quick-dev "Fix the typo in the error message"
-/quick-dev "Update the API endpoint to accept JSON"
-```
-
----
-
-## When to Use
-
-**Use `/quick-dev` when:**
-
-- Task is clear and well-defined
-- You know what needs to be done
-- No architectural decisions needed
-- Quick fixes, small features, or straightforward changes
-
-**Use `/quick-plan` instead when:**
-
-- Task scope is uncertain
-- Multiple implementation approaches possible
-- Architectural decisions required
-- You want user approval before coding
-
----
-
-## Workflow
-
-### Step 1: Parse Input
-
-**Get the task description:**
-
-- If provided as argument, use it directly
-- If not provided, use question to prompt:
-  ```
-  "What would you like to implement? Please describe the task."
-  ```
-
-### Step 1b: Create Task Directory
-
-**Create a lightweight task directory for artifact anchoring.**
-
-1. Generate a task name from the task description:
-   - Extract 3–5 key words, convert to lowercase kebab-case
-   - Prepend today's date: `YYYY-MM-DD-kebab-name`
-   - Examples: "Add a logout button to the navbar" → `2026-05-28-add-navbar-logout-button`, "Update the API endpoint to accept JSON" → `2026-05-28-update-api-accept-json`
-2. Create directory: `.owflow/tasks/quick-dev/YYYY-MM-DD-task-name/`
-3. Write `task.yml` with initial state using the template [src/templates/quick-dev-task.yml](../templates/quick-dev-task.yml).
-4. **CRITICAL**: Use the `verify_template` tool immediately after creation to check YAML validity against `quick-dev-task.yml`.
-
-### Step 2: Discover Standards
-
-**Check if `.owflow/docs/INDEX.md` exists:**
-
-**If exists:**
-
-1. Read INDEX.md to discover available documentation and standards
-2. Identify which standards are relevant based on:
-   - The categories and files listed in INDEX.md
-   - The nature of the task
-   - Keywords in the task description
-3. **READ the applicable standard files** (see Standards Reading Enforcement below)
-4. **Update `task.yml`**: Add paths of standards read to `standards_applied` list
-
-**If not exists:**
-
-- Note that no standards are available
-- Suggest running `/flow-init` in completion message
-
-### Standards Reading Enforcement (MANDATORY)
-
-**BLOCKING**: Reading INDEX.md alone is NOT sufficient. You MUST read actual standard files.
-
-**Enforcement Process**:
-
-1. Read INDEX.md to discover available standards
-2. Identify which standards apply based on task description
-3. **READ each applicable standard file** using Read tool (not just note it exists)
-4. Apply standards during implementation
-5. List applied standards in completion summary
-
-**Examples of standard discovery**:
-
-- Task mentions "upload" → Read file-handling standards
-- Task mentions "form" → Read validation and accessibility standards
-- Task mentions "API" → Read api and error-handling standards
-
-### Step 3: Implement with Standards
-
-**MANDATORY**: During implementation:
-
-1. Explore the codebase to understand context (using Glob, Grep, Read)
-2. **Apply discovered standards** - Reference the standard files you read
-3. For each code change, verify it follows applicable standards
-4. If you encounter new areas while coding (e.g., auth, database), read applicable standards before proceeding
-5. Make the necessary code changes
-6. Run relevant tests if applicable
-
-### Step 4: Verify Standards Compliance
-
-**After implementation, verify:**
-
-1. Review changes against applicable standards
-2. Confirm key guidelines were followed
-3. Note any standards that were applied
-
-### Step 5: Summary
-
-**Write `summary.md`** in the task directory:
-
-```markdown
-# Task Summary
-
-**Command**: quick-dev
-**Date**: YYYY-MM-DD
-**Status**: completed
-
-## What Was Done
-[What was implemented]
-
-## Files Modified
-- `path/to/file`
-
-## Standards Applied
-- [standard]: [guideline]
-
-## Tests
-- [test file] — [result]
-
-## Commit Suggestion
-[conventional commit message]
-```
-
-**Update `task.yml`**: set `status: completed`, `updated: [now]`.
-
-**Provide completion summary to user:**
-
-- What was implemented
-- Which standards from INDEX.md were applied
-- Any tests run and their results
-- Suggestions for follow-up (if any)
-
----
-
-## What This Does
-
-1. **Parses** task description from user input
-2. **Creates** lightweight task directory with `task.yml` for artifact anchoring
-3. **Discovers** applicable standards from `.owflow/docs/INDEX.md`
-4. **READS** actual standard files (MANDATORY - not just INDEX.md)
-5. **Implements** directly without planning mode approval
-6. **Verifies** standards were followed
-7. **Writes** `summary.md` in task directory and updates `task.yml` to `completed`
-8. **Summarizes** what was done and which standards were read and applied
-
-## Graceful Fallback
-
-**If `.owflow/docs/` does not exist:**
-
-Proceed with implementation normally, then note:
-
-```
-"No AI SDLC standards found. Consider running `/flow-init` to initialize
-project documentation and coding standards for better consistency."
-```

package/dist/commands/quick-plan.md

@@ -1,167 +0,0 @@
----
-name: quick-plan
-description: Enter planning mode with AI SDLC standards awareness
----
-
-# Planning Mode with Standards Awareness
-
-Enter OpenCode's planning mode for a task, with automatic discovery of project standards from `.owflow/docs/`.
-
-## Usage
-
-```bash
-/quick-plan [task description]
-```
-
-## Examples
-
-```bash
-/quick-plan "Add user authentication with email/password"
-/quick-plan "Refactor the payment processing module"
-/quick-plan
-```
-
----
-
-## Workflow
-
-### Step 1: Parse Input
-
-**Get the task description:**
-
-- If provided as argument, use it directly
-- If not provided, use question to prompt:
-  ```
-  "What would you like to plan? Please describe the task or feature."
-  ```
-
-### Step 1b: Create Task Directory
-
-**Create a lightweight task directory for artifact anchoring.**
-
-1. Generate a task name from the task description:
-   - Extract 3–5 key words, convert to lowercase kebab-case
-   - Prepend today's date: `YYYY-MM-DD-kebab-name`
-   - Examples: "Add retry logic to API client" → `2026-05-28-add-api-retry-logic`, "Refactor the payment processing module" → `2026-05-28-refactor-payment-module`
-2. Create directory: `.owflow/tasks/quick-plan/YYYY-MM-DD-task-name/`
-3. Create `analysis/` subdirectory inside it
-4. Write `task.yml` with initial state using the template [src/templates/quick-plan-task.yml](../templates/quick-plan-task.yml).
-5. **CRITICAL**: Use the `verify_template` tool immediately after creation to check YAML validity against `quick-plan-task.yml`.
-
-### Step 2: Discover and Read Standards (BEFORE Plan Mode)
-
-**CRITICAL: This step MUST complete before calling Plan Agent.**
-
-1. **Check if `.owflow/docs/INDEX.md` exists**
-   - **If not exists**: Note that no standards are available, skip to Step 3
-   - **If exists**: Continue with discovery below
-
-2. **Read INDEX.md** to understand available standards and documentation
-
-3. **Identify applicable standards** based on:
-   - The categories and files listed in INDEX.md
-   - The nature of the task being planned
-   - Keywords and patterns in the task description (e.g., "API" → api standards, "form" → validation standards, "upload" → file-handling standards)
-
-4. **READ the actual standard files** using the Read tool — reading INDEX.md alone is NOT sufficient
-
-5. **Summarize key guidelines** from each standard file read — these will carry into plan mode as context
-6. **Update `task.yml`**: Add paths of standards read to `standards_applied` list
-
-### Step 2b: Write Findings
-
-**After standards discovery, write `analysis/findings.md`** in the task directory:
-
-```markdown
-# Task Analysis
-
-## Context
-[What was analyzed to inform the plan — codebase areas explored, existing patterns found]
-
-## Key Decisions
-[Architectural or implementation decisions made during planning]
-
-## Standards Referenced
-- [standard file]: [key guideline applied]
-```
-
-### Step 3: Enter Planning Mode
-
-**Use the `Plan agent` to trigger OpenCode's builtin planning mode.**
-
-**Standards context from Step 2 MUST actively inform all plan mode phases:**
-
-- **Phase 1 (Explore)**: When launching Explore agents, include in the prompt: "The following project standards apply to this task: [list standard files and key guidelines from Step 2]. Verify how the existing codebase follows these standards."
-- **Phase 2 (Plan)**: When launching Plan agents, include in the prompt: "Apply these project standards in your implementation plan: [list standard files and key guidelines from Step 2]. Each implementation step must conform to these standards."
-- **Phase 4 (Final Plan)**: The plan file must incorporate standards into the implementation steps themselves, not just list them in a separate section.
-
-The planning mode will:
-
-1. Launch Explore agents to understand the codebase (with standards context)
-2. Launch Plan agents to design implementation approach (with standards constraints)
-3. Review and verify alignment with user intent
-4. Write final plan to plan file (with standards woven into steps)
-5. Ask for user approval (gated on mandatory standards sections)
-
-### Approval question gate: Mandatory Standards Sections
-
-**BLOCKING: Do NOT call ask user for approval until the plan file contains these sections:**
-
-1. **"## Applicable Standards"** — list each standard file that was read, with key guidelines extracted from each. If no standards exist, state: "No AI SDLC standards found. Consider running `/flow-init`."
-
-2. **"## Standards Compliance Checklist"** — checkboxes for each applicable standard guideline that implementation must follow. Example:
-   ```markdown
-   - [ ] API endpoints follow REST naming conventions (from `standards/backend/api.md`)
-   - [ ] Error responses use standard error format (from `standards/backend/api.md`)
-   - [ ] New components use TypeScript strict mode (from `standards/frontend/components.md`)
-   ```
-
-If these sections are missing from the plan file, add them before asking user for approval.
-
-### Graceful Fallback
-
-**If `.owflow/docs/` does not exist:**
-
-Continue with planning mode normally. The "Applicable Standards" section in the plan should note:
-
-```
-No AI SDLC standards found. Consider running `/flow-init` to initialize
-project documentation and coding standards for better consistency.
-```
-
-## What This Does
-
-1. **Parses** task description from user input
-2. **Creates** lightweight task directory with `task.yml` for artifact anchoring
-3. **Discovers and READS** applicable standard files from `.owflow/docs/` (BEFORE plan mode)
-4. **Writes** `analysis/findings.md` with task context and key decisions
-5. **Enters** OpenCode's builtin planning mode via delegating to `Plan Agent` with standards already loaded
-6. **Produces** a plan file with implementation approach, applicable standards, and compliance checklist
-7. **Gates** Approval question on mandatory standards sections in the plan file
-8. **Updates** `task.yml` with `status: completed` and `plan_path` after plan approval
-
-## Benefits Over Manual Planning
-
-- Automatic standards discovery and integration
-- Standards read BEFORE planning begins (not as an afterthought)
-- Plan file for review before implementation
-- Standards compliance checklist built into the plan
-
-## After Planning
-
-Once the plan is approved:
-
-- **Update `task.yml`**: set `status: completed`, `plan_path: [path to plan file]`, `updated: [now]`
-- Implementation begins based on the plan
-- Standards are applied during coding
-
-## Post-Implementation Verification
-
-After implementation is complete, verify standards compliance using the checklist from the plan:
-
-1. **Review the "Standards Compliance Checklist"** in the plan file
-2. **For each checklist item**: verify implementation follows the guideline
-3. **Document verification results** (pass/fail for each item)
-4. **Address any violations** before marking task complete
-
-This ensures the discovered standards are actually enforced, not just documented.