@codemcp/workflows 6.5.0 → 6.6.0

package/packages/opencode-plugin/resources/workflows/tdd.yaml

@@ -0,0 +1,170 @@
+# yaml-language-server: $schema=../state-machine-schema.json
+---
+name: 'tdd'
+description: 'Test-Driven Development workflow: Explore → Red → Green → Refactor cycle for quality-focused development'
+initial_state: 'explore'
+
+# Enhanced metadata for better discoverability
+metadata:
+  domain: 'code'
+  complexity: 'medium'
+  bestFor:
+    - 'TDD development'
+    - 'Test-first coding'
+    - 'Quality-focused development'
+    - 'Refactoring existing code'
+  useCases:
+    - 'Adding new features with comprehensive tests'
+    - 'Refactoring legacy code safely'
+    - 'Building robust, well-tested components'
+  examples:
+    - 'Add new API endpoint with full test coverage'
+    - 'Refactor existing function with safety net of tests'
+    - 'Build new feature following TDD principles'
+
+# States with default instructions and transitions
+states:
+  explore:
+    description: 'Research and exploration phase - understanding the problem space and codebase'
+    allowed_file_patterns:
+      - '**/*.md'
+      - '**/*.txt'
+      - '**/*.adoc'
+    default_instructions: |
+      **STEP 1:** Gather context about what needs to be developed. Focus on the WHY and WHAT, not the HOW.
+
+      **STEP 2:** Research the codebase and understand existing patterns.
+      - Ask the user about conventions or rules if uncertain
+      - Read relevant files and documentation
+      - If `$REQUIREMENTS_DOC` exists, understand and document requirements there, otherwise document in your task management system
+
+      **STEP 3:** Document your findings and create tasks as needed.
+      - Don't write code or tests yet
+      - Focus on understanding the problem space
+      - Prepare for the RED phase of the TDD cycle
+    transitions:
+      - trigger: 'exploration_complete'
+        to: 'red'
+        additional_instructions: 'Update task progress as you complete exploration work.'
+        transition_reason: 'Sufficient understanding gained, ready to start TDD cycle with failing test'
+
+  red:
+    description: 'RED phase - Write a failing test that defines the expected behavior'
+    allowed_file_patterns:
+      - '**/*'
+    default_instructions: |
+      Write a failing test that defines the expected behavior for the feature.
+
+      **STEP 1:** Validate test approach with the user before writing.
+      - Determine what type of test is appropriate (unit, integration, acceptance, etc.)
+      - Confirm your test will validate the actual requirements
+      - Ensure alignment with the feature specification
+
+      **STEP 2:** Write a focused, meaningful test.
+      - Clearly define the expected behavior
+      - Will fail initially since functionality doesn't exist yet
+      - Focus on one specific aspect of the functionality
+      - Use appropriate assertions (not meaningless checks like assert(true))
+
+      **STEP 3:** Validate test failure.
+      - Run the test to confirm it fails for the right reason
+      - Document the test and expected failure mode
+      - Update task progress
+    transitions:
+      - trigger: 'test_written_and_failing'
+        to: 'green'
+        additional_instructions: 'Update task progress as you complete test writing work.'
+        transition_reason: 'Failing test successfully written and validated, ready to implement'
+
+      - trigger: 'need_more_exploration'
+        to: 'explore'
+        transition_reason: 'Test writing revealed need for more exploration'
+
+      - trigger: 'abandon_feature'
+        to: 'explore'
+        additional_instructions: 'Clean up any test artifacts and prepare for new tasks.'
+        transition_reason: 'User decided to abandon feature during test phase'
+
+  green:
+    description: 'GREEN phase - Write only the necessary code to make the test pass'
+    allowed_file_patterns:
+      - '**/*'
+    default_instructions: |
+      Implement the necessary code to make the failing test pass with proper functionality.
+
+      **STEP 1:** Write real, working implementation.
+      - Make the test pass with actual logic, not shortcuts
+      - Write only what's necessary (no over-engineering)
+      - Avoid dirty hacks such as hardcoded return values or meaningless assertions
+      - Focus on solving the actual problem
+
+      **STEP 2:** Validate implementation quality.
+      - Run the test to confirm it passes
+      - Verify no shortcuts or copy-paste code without understanding
+      - Ensure the solution actually solves the problem
+      - Check that logic is proper, not a bypass
+
+      **STEP 3:** Document and track progress.
+      - Document your implementation approach
+      - Update task progress
+    transitions:
+      - trigger: 'test_passing'
+        to: 'refactor'
+        additional_instructions: 'Update task progress as you complete implementation work.'
+        transition_reason: 'Test passes with proper implementation, ready for refactoring'
+
+      - trigger: 'need_different_test'
+        to: 'red'
+        transition_reason: 'Implementation work revealed need to revise the test'
+
+      - trigger: 'need_more_exploration'
+        to: 'explore'
+        transition_reason: 'Implementation work revealed need for more exploration'
+
+      - trigger: 'abandon_feature'
+        to: 'explore'
+        additional_instructions: 'Clean up any incomplete code and prepare for new tasks.'
+        transition_reason: 'User decided to abandon feature during implementation'
+
+  refactor:
+    description: 'REFACTOR phase - Improve code quality while keeping tests green (cleanup phase)'
+    allowed_file_patterns:
+      - '**/*'
+    default_instructions: |
+      Improve code quality while keeping all tests green. This is the cleanup phase where you enhance readability and maintainability.
+
+      **STEP 1:** Identify improvement opportunities.
+      - Remove code duplication
+      - Improve variable and function names
+      - Extract methods for better organization
+      - Simplify complex logic
+      - Apply appropriate design patterns
+
+      **STEP 2:** Make incremental improvements safely.
+      - Run tests after each refactoring change
+      - Immediately revert any change that breaks tests
+      - Make small, focused improvements
+      - Stop when code is clean with no obvious improvements remaining
+
+      **STEP 3:** Document and complete.
+      - Document significant refactoring decisions
+      - Update task progress
+    transitions:
+      - trigger: 'refactoring_complete'
+        to: 'red'
+        additional_instructions: 'Update task progress as you complete refactoring work.'
+        transition_reason: 'Code cleanup complete, ready for next TDD cycle'
+
+      - trigger: 'need_different_approach'
+        to: 'green'
+        transition_reason: 'Refactoring revealed need to revise implementation'
+
+      - trigger: 'feature_complete'
+        to: 'explore'
+        additional_instructions: 'Update task progress to reflect feature completion.'
+        transition_reason: 'Feature fully implemented and cleaned up, ready for new tasks'
+
+      - trigger: 'abandon_feature'
+        to: 'explore'
+        additional_instructions: 'Clean up any refactoring work and prepare for new tasks.'
+        transition_reason: 'User decided to abandon feature during refactoring'

package/packages/opencode-plugin/resources/workflows/waterfall.yaml

@@ -0,0 +1,225 @@
+# yaml-language-server: $schema=../state-machine-schema.json
+---
+name: 'waterfall'
+description: 'V-Model: Specification down to test – the historical way. Ideal for larger, design-heavy tasks with well-defined requirements'
+initial_state: 'requirements'
+
+# Enhanced metadata for better discoverability
+metadata:
+  domain: 'code'
+  complexity: 'high'
+  bestFor:
+    - 'Large feature development'
+    - 'Complex system changes'
+    - 'Well-defined requirements'
+    - 'Design-heavy projects'
+  useCases:
+    - 'Building a new module from scratch'
+    - 'Implementing complex business logic'
+    - 'Major architectural changes'
+  examples:
+    - 'Create a new authentication system'
+    - 'Build a reporting dashboard'
+    - 'Implement a payment processing workflow'
+  requiresDocumentation: true
+
+# States with default instructions and transitions
+states:
+  requirements:
+    description: 'Gathering and analyzing requirements'
+    allowed_file_patterns:
+      - '**/*.md'
+      - '**/*.txt'
+      - '**/*.adoc'
+    default_instructions: |
+      Familiarize yourself with the code base and understand project goals, scope, constraints, and success criteria.
+
+      - Who are the key stakeholders? (end users, business owners, technical teams)
+      - Which requirements are must-have vs nice-to-have?
+      - How will you measure success? What are the acceptance criteria?
+      - What are your time, budget, technical, or regulatory constraints?
+      - What existing systems must this integrate with?
+
+      Document all requirements in `$REQUIREMENTS_DOC`. Create actionable tasks referencing those requirements.
+    transitions:
+      - trigger: 'requirements_complete'
+        to: 'design'
+        transition_reason: 'All requirements tasks completed, moving to technical design'
+        review_perspectives:
+          - perspective: 'business_analyst'
+            prompt: 'Review requirements completeness, clarity, and business value. Ensure all stakeholder needs are captured and requirements are testable. Check for missing edge cases or unclear acceptance criteria.'
+          - perspective: 'ux_expert'
+            prompt: 'Evaluate user experience implications and usability requirements. Ensure user needs and workflows are properly defined. Identify potential UX challenges or accessibility concerns.'
+
+  design:
+    description: 'Technical design and architecture planning'
+    allowed_file_patterns:
+      - '**/*.md'
+      - '**/*.txt'
+      - '**/*.adoc'
+    default_instructions: |
+      Review requirements from `$REQUIREMENTS_DOC` and design the technical solution.
+
+      Focus on HOW to implement what's needed including architecture, technologies, data models, API design, and quality goals. Clarify performance expectations and technology preferences if not already obvious from the current analysis.
+
+      Document architectural decisions in `$ARCHITECTURE_DOC` and detailed design in `$DESIGN_DOC`. Create tasks and ensure the approach is solid before implementation.
+    transitions:
+      - trigger: 'need_more_requirements'
+        to: 'requirements'
+        additional_instructions: 'Design work revealed gaps in requirements understanding. Focus on clarifying the specific requirements that are blocking design decisions.'
+        transition_reason: 'Design work revealed need for additional requirements clarification'
+
+      - trigger: 'design_complete'
+        to: 'implementation'
+        transition_reason: 'Technical design is complete, ready for implementation'
+        review_perspectives:
+          - perspective: 'architect'
+            prompt: 'Review technical architecture, design patterns, and system integration. Ensure scalability, maintainability, and alignment with existing systems. Evaluate technology choices and architectural decisions.'
+          - perspective: 'security_expert'
+            prompt: 'Evaluate security considerations, data protection, and potential vulnerabilities in the proposed design. Review authentication, authorization, data handling, and potential attack vectors.'
+
+  implementation:
+    description: 'Building the solution according to design'
+    allowed_file_patterns:
+      - '**/*'
+    default_instructions: |
+      Follow the architecture from `$ARCHITECTURE_DOC` and detailed design from `$DESIGN_DOC` to build the solution.
+
+      Before starting, clarify the approach:
+      - Should this be implemented incrementally or all at once? Any specific order of implementation?
+      - Are there high-risk parts that need extra validation or careful implementation?
+
+      Ensure requirements from `$REQUIREMENTS_DOC` are met. Focus on code structure, error handling, security, and maintainability. Write clean, well-documented code and include basic testing. Update task progress during implementation work.
+    transitions:
+      - trigger: 'need_design_changes'
+        to: 'design'
+        additional_instructions: "Implementation revealed issues with the current design. Consider what you've learned during coding and adjust the design accordingly. Document the changes and reasons."
+        transition_reason: 'Implementation work revealed need to revise the design'
+
+      - trigger: 'need_more_requirements'
+        to: 'requirements'
+        additional_instructions: 'Implementation revealed gaps in requirements understanding. Focus on clarifying the specific requirements that are blocking implementation.'
+        transition_reason: 'Implementation work revealed need for additional requirements'
+
+      - trigger: 'implementation_complete'
+        to: 'qa'
+        transition_reason: 'Core implementation is complete, ready for quality assurance'
+        review_perspectives:
+          - perspective: 'senior_software_developer'
+            prompt: 'Review code quality, best practices, and implementation approach. Ensure clean, maintainable, and efficient code. Check for proper error handling, logging, and code organization.'
+          - perspective: 'performance_engineer'
+            prompt: 'Assess performance implications, resource usage, and potential bottlenecks in the implementation. Review algorithms, data structures, and system resource utilization.'
+
+  qa:
+    description: 'Quality assurance and code review'
+    allowed_file_patterns:
+      - '**/*'
+    default_instructions: |
+      Perform systematic quality checks and code review:
+
+      **STEP 1: Automated Quality Checks**
+      - Run syntax checking tools or validate syntax manually
+      - Build the project to verify it compiles without errors
+      - Execute linting tools to ensure code style consistency
+      - Run existing tests to verify functionality
+
+      **STEP 2: Multi-Perspective Code Review**
+      Conduct code review from security, performance, UX, maintainability, and requirement compliance perspectives. Verify implementation matches `$DESIGN_DOC` specifications and fulfills targeted requirements from `$REQUIREMENTS_DOC`.
+
+      Update task progress and mark completed work during QA review.
+    transitions:
+      - trigger: 'need_implementation_fixes'
+        to: 'implementation'
+        additional_instructions: 'Quality assurance revealed issues that require code changes. Focus on the specific problems identified during QA review.'
+        transition_reason: 'QA found issues requiring implementation fixes'
+
+      - trigger: 'need_design_changes'
+        to: 'design'
+        additional_instructions: 'Quality assurance revealed fundamental design issues. Consider the QA findings and adjust the design accordingly.'
+        transition_reason: 'QA found issues requiring design changes'
+
+      - trigger: 'qa_complete'
+        to: 'testing'
+        transition_reason: 'Quality assurance is complete, ready for comprehensive testing'
+
+  testing:
+    description: 'Comprehensive testing and validation'
+    allowed_file_patterns:
+      - '**/*'
+    default_instructions: |
+      Create and execute comprehensive test plans to validate feature completeness.
+
+      - Write and execute tests with focus on test coverage and edge cases
+      - Conduct integration testing to ensure all components work together
+      - Validate user acceptance and ensure everything works as expected
+    transitions:
+      - trigger: 'need_implementation_fixes'
+        to: 'implementation'
+        additional_instructions: 'Testing revealed bugs or issues that require code changes. Focus on the specific problems identified during testing.'
+        transition_reason: 'Testing found issues requiring implementation fixes'
+
+      - trigger: 'need_qa_review'
+        to: 'qa'
+        additional_instructions: 'Testing revealed quality issues that need additional QA review. Focus on the specific quality concerns identified.'
+        transition_reason: 'Testing found issues requiring additional QA review'
+
+      - trigger: 'testing_complete'
+        to: 'finalize'
+        transition_reason: 'All testing is complete, feature is ready for delivery'
+        review_perspectives:
+          - perspective: 'business_analyst'
+            prompt: 'Verify that all requirements have been met and business objectives are achieved. Ensure the solution delivers the expected business value and meets acceptance criteria.'
+          - perspective: 'ux_expert'
+            prompt: 'Confirm user experience goals are met and the solution is user-friendly and accessible. Validate that user workflows are intuitive and efficient.'
+
+  finalize:
+    description: 'Code cleanup and documentation finalization'
+    allowed_file_patterns:
+      - '**/*'
+    default_instructions: |
+      Complete the feature by cleaning up code and updating documentation.
+
+      **STEP 1: Code Cleanup**
+
+      Remove debug output and temporary code:
+      - Search for and remove all temporary debug output statements used during development
+      - Look for language-specific debug output methods (console logging, print statements, debug output functions)
+
+      Review and address TODO/FIXME comments:
+      - Address each TODO/FIXME comment by either implementing the solution or documenting why it's deferred
+      - Remove completed TODOs
+      - Convert remaining TODOs to proper issue tracking if needed
+
+      Remove debugging code blocks:
+      - Remove temporary debugging code, test code blocks, and commented-out code
+      - Clean up any experimental code that's no longer needed
+      - Ensure proper error handling replaces temporary debug logging
+
+      **STEP 2: Documentation Review**
+
+      Review and update documentation to reflect final implementation:
+      - Update `$REQUIREMENTS_DOC` if requirements changed during development
+      - Update `$ARCHITECTURE_DOC` if architectural decisions evolved
+      - Update `$DESIGN_DOC` if design details were refined or changed
+      - Compare documentation against actual implemented functionality
+      - Only modify documentation sections that have functional changes
+      - Remove references to development iterations, progress notes, and temporary decisions
+      - Ensure documentation describes the final implemented state, not the development process
+      - Ask user to review document updates
+
+      **STEP 3: Final Validation**
+
+      - Run existing tests to ensure cleanup didn't break functionality
+      - Verify documentation accuracy with a final review
+      - Ensure code is ready for production/delivery
+
+      Update task progress and mark completed work as you finalize the feature.
+    transitions:
+      - trigger: 'need_final_changes'
+        to: 'implementation'
+        additional_instructions: 'Finalization revealed issues that require code changes. Focus on the specific problems identified during final review.'
+        transition_reason: 'Final review found issues requiring implementation changes'
+
+      - trigger: 'finalization_complete'
+        to: 'requirements'
+        transition_reason: 'Feature delivery complete, beginning new development cycle'

package/packages/opencode-tui-plugin/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codemcp/workflows-opencode-tui",
-  "version": "6.5.0",
+  "version": "6.6.0",
   "description": "OpenCode TUI sidebar plugin that displays the current responsible-vibe workflow phase and name",
   "main": "workflows-phase.tsx",
   "exports": {

package/packages/visualizer/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codemcp/workflows-visualizer",
-  "version": "6.5.0",
+  "version": "6.6.0",
   "type": "module",
   "main": "dist/index.ts",
   "module": "dist/index.ts",

package/packages/opencode-plugin/dist/index.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,OAAO,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAC9C,cAAc,YAAY,CAAC;AAE3B,4CAA4C;AAC5C,OAAO,EAAE,OAAO,EAAE,MAAM,aAAa,CAAC"}

package/packages/opencode-plugin/dist/opencode-logger.d.ts

@@ -1,21 +0,0 @@
-import { type LoggerFactory } from '@codemcp/workflows-core';
-import type { PluginInput } from './types.js';
-/**
- * Logger interface for structured logging
- */
-export interface Logger {
-    debug: (message: string, extra?: Record<string, unknown>) => void;
-    info: (message: string, extra?: Record<string, unknown>) => void;
-    warn: (message: string, extra?: Record<string, unknown>) => void;
-    error: (message: string, extra?: Record<string, unknown>) => void;
-}
-/**
- * Create a logger factory that creates loggers which send output to OpenCode SDK.
- * This factory can be passed to ServerContext so handlers use OpenCode logging.
- */
-export declare function createOpenCodeLoggerFactory(client: PluginInput['client']): LoggerFactory;
-/**
- * Create a logger backed by core's createLogger + a LogSink that delegates
- * log output to the OpenCode SDK client.app.log() API.
- */
-export declare function createOpenCodeLogger(client: PluginInput['client']): Logger;

package/packages/opencode-plugin/dist/opencode-logger.js

@@ -1,104 +0,0 @@
-import { createLogger as coreCreateLogger, registerLogSink, } from '@codemcp/workflows-core';
-/**
- * Create a logger factory that creates loggers which send output to OpenCode SDK.
- * This factory can be passed to ServerContext so handlers use OpenCode logging.
- */
-export function createOpenCodeLoggerFactory(client) {
-    const openCodeClient = client;
-    return (component) => {
-        return {
-            debug: (message, context) => {
-                openCodeClient.app
-                    .log({
-                    body: {
-                        service: component,
-                        level: 'debug',
-                        message,
-                        extra: context,
-                    },
-                })
-                    .catch(() => { });
-            },
-            info: (message, context) => {
-                openCodeClient.app
-                    .log({
-                    body: {
-                        service: component,
-                        level: 'info',
-                        message,
-                        extra: context,
-                    },
-                })
-                    .catch(() => { });
-            },
-            warn: (message, context) => {
-                openCodeClient.app
-                    .log({
-                    body: {
-                        service: component,
-                        level: 'warn',
-                        message,
-                        extra: context,
-                    },
-                })
-                    .catch(() => { });
-            },
-            error: (message, error, context) => {
-                const errorContext = error
-                    ? { ...context, error: error.message, stack: error.stack }
-                    : context;
-                openCodeClient.app
-                    .log({
-                    body: {
-                        service: component,
-                        level: 'error',
-                        message,
-                        extra: errorContext,
-                    },
-                })
-                    .catch(() => { });
-            },
-        };
-    };
-}
-/**
- * Create a logger backed by core's createLogger + a LogSink that delegates
- * log output to the OpenCode SDK client.app.log() API.
- */
-export function createOpenCodeLogger(client) {
-    const openCodeClient = client;
-    const service = 'plugin.workflows';
-    // Register a LogSink that forwards core log events to the OpenCode SDK.
-    // The core LogSink interface uses 'warning' for warn-level; we map that
-    // back to 'warn' for the OpenCode SDK which expects the shorter form.
-    const sink = {
-        log: (level, _logger, message, context) => {
-            const sdkLevel = level === 'warning' ? 'warn' : level;
-            try {
-                return openCodeClient.app.log({
-                    body: {
-                        service,
-                        level: sdkLevel,
-                        message,
-                        extra: context,
-                    },
-                });
-            }
-            catch {
-                return Promise.resolve();
-            }
-        },
-    };
-    registerLogSink(sink);
-    // Return a Logger that delegates to the core logger.
-    // The core error() method has signature (message, error?, context?) so we
-    // wrap it to match our simpler (message, extra?) interface.
-    const coreLogger = coreCreateLogger('plugin.workflows');
-    return {
-        debug: (message, extra) => coreLogger.debug(message, extra),
-        info: (message, extra) => coreLogger.info(message, extra),
-        warn: (message, extra) => coreLogger.warn(message, extra),
-        error: (message, extra) => coreLogger.error(message, undefined, extra),
-    };
-}
-//# sourceMappingURL=opencode-logger.js.map

package/packages/opencode-plugin/dist/opencode-logger.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"opencode-logger.js","sourceRoot":"","sources":["../src/opencode-logger.ts"],"names":[],"mappings":"AAAA,OAAO,EACL,YAAY,IAAI,gBAAgB,EAChC,eAAe,GAKhB,MAAM,yBAAyB,CAAC;AA6BjC;;;GAGG;AACH,MAAM,UAAU,2BAA2B,CACzC,MAA6B;IAE7B,MAAM,cAAc,GAAG,MAAwB,CAAC;IAEhD,OAAO,CAAC,SAAiB,EAAW,EAAE;QACpC,OAAO;YACL,KAAK,EAAE,CAAC,OAAe,EAAE,OAAoB,EAAE,EAAE;gBAC/C,cAAc,CAAC,GAAG;qBACf,GAAG,CAAC;oBACH,IAAI,EAAE;wBACJ,OAAO,EAAE,SAAS;wBAClB,KAAK,EAAE,OAAO;wBACd,OAAO;wBACP,KAAK,EAAE,OAA8C;qBACtD;iBACF,CAAC;qBACD,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;YACrB,CAAC;YACD,IAAI,EAAE,CAAC,OAAe,EAAE,OAAoB,EAAE,EAAE;gBAC9C,cAAc,CAAC,GAAG;qBACf,GAAG,CAAC;oBACH,IAAI,EAAE;wBACJ,OAAO,EAAE,SAAS;wBAClB,KAAK,EAAE,MAAM;wBACb,OAAO;wBACP,KAAK,EAAE,OAA8C;qBACtD;iBACF,CAAC;qBACD,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;YACrB,CAAC;YACD,IAAI,EAAE,CAAC,OAAe,EAAE,OAAoB,EAAE,EAAE;gBAC9C,cAAc,CAAC,GAAG;qBACf,GAAG,CAAC;oBACH,IAAI,EAAE;wBACJ,OAAO,EAAE,SAAS;wBAClB,KAAK,EAAE,MAAM;wBACb,OAAO;wBACP,KAAK,EAAE,OAA8C;qBACtD;iBACF,CAAC;qBACD,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;YACrB,CAAC;YACD,KAAK,EAAE,CAAC,OAAe,EAAE,KAAa,EAAE,OAAoB,EAAE,EAAE;gBAC9D,MAAM,YAAY,GAAG,KAAK;oBACxB,CAAC,CAAC,EAAE,GAAG,OAAO,EAAE,KAAK,EAAE,KAAK,CAAC,OAAO,EAAE,KAAK,EAAE,KAAK,CAAC,KAAK,EAAE;oBAC1D,CAAC,CAAC,OAAO,CAAC;gBACZ,cAAc,CAAC,GAAG;qBACf,GAAG,CAAC;oBACH,IAAI,EAAE;wBACJ,OAAO,EAAE,SAAS;wBAClB,KAAK,EAAE,OAAO;wBACd,OAAO;wBACP,KAAK,EAAE,YAAmD;qBAC3D;iBACF,CAAC;qBACD,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;YACrB,CAAC;SACF,CAAC;IACJ,CAAC,CAAC;AACJ,CAAC;AAED;;;GAGG;AACH,MAAM,UAAU,oBAAoB,CAAC,MAA6B;IAChE,MAAM,cAAc,GAAG,MAAwB,CAAC;IAChD,MAAM,OAAO,GAAG,kBAAkB,CAAC;IAEnC,wEAAwE;IACxE,wEAAwE;IACxE,sEAAsE;IACtE,MAAM,IAAI,GAAY;QACpB,GAAG,EAAE,CACH,KAA6C,EAC7C,OAAe,EACf,OAAe,EACf,OAAoB,EACL,EAAE;YACjB,MAAM,QAAQ,GAAG,KAAK,KAAK,SAAS,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,KAAK,CAAC;YACtD,IAAI,CAAC;gBACH,OAAO,cAAc,CAAC,GAAG,CAAC,GAAG,CAAC;oBAC5B,IAAI,EAAE;wBACJ,OAAO;wBACP,KAAK,EAAE,QAA+C;wBACtD,OAAO;wBACP,KAAK,EAAE,OAA8C;qBACtD;iBACF,CAAC,CAAC;YACL,CAAC;YAAC,MAAM,CAAC;gBACP,OAAO,OAAO,CAAC,OAAO,EAAE,CAAC;YAC3B,CAAC;QACH,CAAC;KACF,CAAC;IACF,eAAe,CAAC,IAAI,CAAC,CAAC;IAEtB,qDAAqD;IACrD,0EAA0E;IAC1E,4DAA4D;IAC5D,MAAM,UAAU,GAAG,gBAAgB,CAAC,kBAAkB,CAAC,CAAC;IACxD,OAAO;QACL,KAAK,EAAE,CAAC,OAAO,EAAE,KAAK,EAAE,EAAE,CAAC,UAAU,CAAC,KAAK,CAAC,OAAO,EAAE,KAAmB,CAAC;QACzE,IAAI,EAAE,CAAC,OAAO,EAAE,KAAK,EAAE,EAAE,CAAC,UAAU,CAAC,IAAI,CAAC,OAAO,EAAE,KAAmB,CAAC;QACvE,IAAI,EAAE,CAAC,OAAO,EAAE,KAAK,EAAE,EAAE,CAAC,UAAU,CAAC,IAAI,CAAC,OAAO,EAAE,KAAmB,CAAC;QACvE,KAAK,EAAE,CAAC,OAAO,EAAE,KAAK,EAAE,EAAE,CACxB,UAAU,CAAC,KAAK,CAAC,OAAO,EAAE,SAAS,EAAE,KAAmB,CAAC;KAC5D,CAAC;AACJ,CAAC"}

package/packages/opencode-plugin/dist/plugin.d.ts

@@ -1,23 +0,0 @@
-/**
- * OpenCode Workflows Plugin
- *
- * Integrates workflows-core state management with OpenCode hooks to provide
- * phase-aware development guidance and file edit restrictions.
- *
- * Hooks implemented:
- * 1. chat.message - Add synthetic part with phase instructions after each user message
- * 2. tool.execute.before - Block editing of certain files based on phase
- * 3. experimental.session.compacting - Inject workflow state into compaction context
- *
- * Logs are sent via OpenCode SDK's client.app.log() API
- */
-import type { Plugin } from './types.js';
-/**
- * Main plugin export
- */
-export declare const WorkflowsPlugin: Plugin;
-declare const _default: {
-    id: string;
-    server: Plugin;
-};
-export default _default;