legacyver 2.1.4 → 2.1.6

package/.opencode/skills/openspec-verify-change/SKILL.md

@@ -1,168 +0,0 @@
----
-name: openspec-verify-change
-description: Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.1.1"
----
-
-Verify that an implementation matches the change artifacts (specs, tasks, design).
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show changes that have implementation tasks (tasks artifact exists).
-   Include the schema used for each change if available.
-   Mark changes with incomplete tasks as "(In Progress)".
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifacts exist for this change
-
-3. **Get the change directory and load artifacts**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns the change directory and context files. Read all available artifacts from `contextFiles`.
-
-4. **Initialize verification report structure**
-
-   Create a report structure with three dimensions:
-   - **Completeness**: Track tasks and spec coverage
-   - **Correctness**: Track requirement implementation and scenario coverage
-   - **Coherence**: Track design adherence and pattern consistency
-
-   Each dimension can have CRITICAL, WARNING, or SUGGESTION issues.
-
-5. **Verify Completeness**
-
-   **Task Completion**:
-   - If tasks.md exists in contextFiles, read it
-   - Parse checkboxes: `- [ ]` (incomplete) vs `- [x]` (complete)
-   - Count complete vs total tasks
-   - If incomplete tasks exist:
-     - Add CRITICAL issue for each incomplete task
-     - Recommendation: "Complete task: <description>" or "Mark as done if already implemented"
-
-   **Spec Coverage**:
-   - If delta specs exist in `openspec/changes/<name>/specs/`:
-     - Extract all requirements (marked with "### Requirement:")
-     - For each requirement:
-       - Search codebase for keywords related to the requirement
-       - Assess if implementation likely exists
-     - If requirements appear unimplemented:
-       - Add CRITICAL issue: "Requirement not found: <requirement name>"
-       - Recommendation: "Implement requirement X: <description>"
-
-6. **Verify Correctness**
-
-   **Requirement Implementation Mapping**:
-   - For each requirement from delta specs:
-     - Search codebase for implementation evidence
-     - If found, note file paths and line ranges
-     - Assess if implementation matches requirement intent
-     - If divergence detected:
-       - Add WARNING: "Implementation may diverge from spec: <details>"
-       - Recommendation: "Review <file>:<lines> against requirement X"
-
-   **Scenario Coverage**:
-   - For each scenario in delta specs (marked with "#### Scenario:"):
-     - Check if conditions are handled in code
-     - Check if tests exist covering the scenario
-     - If scenario appears uncovered:
-       - Add WARNING: "Scenario not covered: <scenario name>"
-       - Recommendation: "Add test or implementation for scenario: <description>"
-
-7. **Verify Coherence**
-
-   **Design Adherence**:
-   - If design.md exists in contextFiles:
-     - Extract key decisions (look for sections like "Decision:", "Approach:", "Architecture:")
-     - Verify implementation follows those decisions
-     - If contradiction detected:
-       - Add WARNING: "Design decision not followed: <decision>"
-       - Recommendation: "Update implementation or revise design.md to match reality"
-   - If no design.md: Skip design adherence check, note "No design.md to verify against"
-
-   **Code Pattern Consistency**:
-   - Review new code for consistency with project patterns
-   - Check file naming, directory structure, coding style
-   - If significant deviations found:
-     - Add SUGGESTION: "Code pattern deviation: <details>"
-     - Recommendation: "Consider following project pattern: <example>"
-
-8. **Generate Verification Report**
-
-   **Summary Scorecard**:
-   ```
-   ## Verification Report: <change-name>
-
-   ### Summary
-   | Dimension    | Status           |
-   |--------------|------------------|
-   | Completeness | X/Y tasks, N reqs|
-   | Correctness  | M/N reqs covered |
-   | Coherence    | Followed/Issues  |
-   ```
-
-   **Issues by Priority**:
-
-   1. **CRITICAL** (Must fix before archive):
-      - Incomplete tasks
-      - Missing requirement implementations
-      - Each with specific, actionable recommendation
-
-   2. **WARNING** (Should fix):
-      - Spec/design divergences
-      - Missing scenario coverage
-      - Each with specific recommendation
-
-   3. **SUGGESTION** (Nice to fix):
-      - Pattern inconsistencies
-      - Minor improvements
-      - Each with specific recommendation
-
-   **Final Assessment**:
-   - If CRITICAL issues: "X critical issue(s) found. Fix before archiving."
-   - If only warnings: "No critical issues. Y warning(s) to consider. Ready for archive (with noted improvements)."
-   - If all clear: "All checks passed. Ready for archive."
-
-**Verification Heuristics**
-
-- **Completeness**: Focus on objective checklist items (checkboxes, requirements list)
-- **Correctness**: Use keyword search, file path analysis, reasonable inference - don't require perfect certainty
-- **Coherence**: Look for glaring inconsistencies, don't nitpick style
-- **False Positives**: When uncertain, prefer SUGGESTION over WARNING, WARNING over CRITICAL
-- **Actionability**: Every issue must have a specific recommendation with file/line references where applicable
-
-**Graceful Degradation**
-
-- If only tasks.md exists: verify task completion only, skip spec/design checks
-- If tasks + specs exist: verify completeness and correctness, skip design
-- If full artifacts: verify all three dimensions
-- Always note which checks were skipped and why
-
-**Output Format**
-
-Use clear markdown with:
-- Table for summary scorecard
-- Grouped lists for issues (CRITICAL/WARNING/SUGGESTION)
-- Code references in format: `file.ts:123`
-- Specific, actionable recommendations
-- No vague suggestions like "consider reviewing"

package/legacyver-docs/config.md

@@ -1,21 +0,0 @@
-## Overview
-The provided JavaScript file, `config.js`, contains a function for loading configuration from a file and merging it with command-line interface (CLI) flags. The function, `loadConfig`, utilizes the `cosmiconfig` library to search for configuration files in specific locations.
-
-## Functions
-### loadConfig
-#### Description
-Loads configuration from a file and merges it with CLI flags, with CLI flags taking precedence over file configuration.
-
-#### Parameters
-| Name | Type | Description |
-| --- | --- | --- |
-| cliFlags | Object | Command-line interface flags to merge with file configuration |
-
-#### Return Value
-An object containing the merged configuration, with defaults applied where necessary.
-
-## Dependencies
-* `cosmiconfig`: a library for searching and loading configuration files
-
-## Usage Example
-Although a specific usage example is not provided in the code, the `loadConfig` function can be used by passing an object containing CLI flags, like so: `loadConfig({ provider: 'customProvider' })`. This would load the configuration from a file, merge it with the provided CLI flags, and return the resulting configuration object.

package/legacyver-docs/errors.md

@@ -1,63 +0,0 @@
-## Overview
-The errors.js file contains custom error classes for Legacyver, a set of classes that extend the built-in Error class to provide more specific error handling. These classes include LegacyverError, NoApiKeyError, RateLimitError, ParseError, and RenderError.
-
-## Functions
-### LegacyverError
-#### Description
-The LegacyverError class is the base class for all custom error classes in Legacyver. It extends the built-in Error class and adds a code property.
-#### Parameters
-| Parameter | Type | Description |
-| --- | --- | --- |
-| message | string | The error message |
-| code | string | The error code (default: 'LEGACYVER_ERROR') |
-#### Return Value
-An instance of the LegacyverError class
-
-### NoApiKeyError
-#### Description
-The NoApiKeyError class extends LegacyverError and is thrown when no API key is found for a provider.
-#### Parameters
-| Parameter | Type | Description |
-| --- | --- | --- |
-| provider | string | The provider for which no API key was found |
-#### Return Value
-An instance of the NoApiKeyError class
-
-### RateLimitError
-#### Description
-The RateLimitError class extends LegacyverError and is thrown when the rate limit is exceeded for a provider.
-#### Parameters
-| Parameter | Type | Description |
-| --- | --- | --- |
-| provider | string | The provider for which the rate limit was exceeded |
-| retryAfter | number | The time to wait before retrying (default: 1000) |
-#### Return Value
-An instance of the RateLimitError class
-
-### ParseError
-#### Description
-The ParseError class extends LegacyverError and is thrown when a file cannot be parsed.
-#### Parameters
-| Parameter | Type | Description |
-| --- | --- | --- |
-| filePath | string | The path to the file that could not be parsed |
-| originalError | Error | The original error that occurred during parsing |
-#### Return Value
-An instance of the ParseError class
-
-### RenderError
-#### Description
-The RenderError class extends LegacyverError and is thrown when rendering fails for a format.
-#### Parameters
-| Parameter | Type | Description |
-| --- | --- | --- |
-| format | string | The format for which rendering failed |
-| originalError | Error | The original error that occurred during rendering |
-#### Return Value
-An instance of the RenderError class
-
-## Dependencies
-* None (built-in Error class)
-
-## Usage Example
-No clear usage pattern is visible in the provided code. These error classes are likely used throughout the Legacyver application to handle specific error cases.

package/legacyver-docs/logger.md

@@ -1,71 +0,0 @@
-## Overview
-This module provides a simple logging system with adjustable log levels and colorized output. It exports functions for logging at different levels, as well as setting the current log level and CI environment.
-
-## Functions
-### setLevel
-Description: Sets the current log level.
-Parameters:
-| Param | Description |
-| --- | --- |
-| level | The new log level (one of 'debug', 'info', 'warn', 'error') |
-Return Value: None
-
-### setCI
-Description: Sets whether the logger is running in a CI environment.
-Parameters:
-| Param | Description |
-| --- | --- |
-| val | A boolean indicating whether the logger is in a CI environment |
-Return Value: None
-
-### shouldLog
-Description: Checks whether a log message of a given level should be logged.
-Parameters:
-| Param | Description |
-| --- | --- |
-| level | The log level to check |
-Return Value: A boolean indicating whether the log message should be logged
-
-### debug
-Description: Logs a debug message if the current log level is debug or lower.
-Parameters:
-| Param | Description |
-| --- | --- |
-| ...args | The message to log |
-Return Value: None
-
-### info
-Description: Logs an info message if the current log level is info or lower.
-Parameters:
-| Param | Description |
-| --- | --- |
-| ...args | The message to log |
-Return Value: None
-
-### warn
-Description: Logs a warning message if the current log level is warn or lower.
-Parameters:
-| Param | Description |
-| --- | --- |
-| ...args | The message to log |
-Return Value: None
-
-### error
-Description: Logs an error message if the current log level is error or lower.
-Parameters:
-| Param | Description |
-| --- | --- |
-| ...args | The message to log |
-Return Value: None
-
-## Dependencies
-* picocolors (as pc)
-
-## Usage Example
-No specific usage example is visible in the provided code, but the exported functions can be used as follows:
-```javascript
-const logger = require('./logger');
-logger.setLevel('debug');
-logger.debug('This is a debug message');
-logger.info('This is an info message');
-```