legacyver 2.1.3 → 2.1.5

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,30 +0,0 @@
-## Overview
-This is a JavaScript module that exports a single function `loadConfig`, which loads configuration from a file and merges with CLI flags.
-
-## Functions
-### `loadConfig`
-
-#### Description:
-Load configuration from file and merge with CLI flags.
-CLI flags always win over file config.
-
-#### Params Table:
-
-| Name | Type |
-| --- | --- |
-| `cliFlags` | Object |
-
-#### Return Value:
-Object
-
-```javascript
-function loadConfig(cliFlags = {}) {
-  // ...
-}
-```
-
-## Dependencies
-* `cosmiconfig: cosmiconfigSync`
-
-## Usage Example
-No clear pattern is visible in the code to demonstrate usage.

package/legacyver-docs/errors.md

@@ -1,74 +0,0 @@
-## Overview
-This file exports five custom error classes for use in a Legacyver application.
-
-## Functions
-
-### `LegacyverError`
-#### Description
-A base class for all custom errors in Legacyver.
-#### Parameters
-| Name | Type | Default Value |
-| --- | --- | --- |
-| message | string |  |
-| code | string | 'LEGACYVER_ERROR' |
-
-#### Return Value
-None.
-
-### `NoApiKeyError`
-#### Description
-Raised when no API key is found for a provider.
-#### Parameters
-| Name | Type | Required | Default Value |
-| --- | --- | --- | --- |
-| provider | string |  |  |
-
-#### Return Value
-None.
-
-#### Detected Patterns:
-- The error message includes a suggestion to set the `OPENROUTER_API_KEY` environment variable or run `legacyver init`.
-- The error message includes a link to obtain an API key at https://openrouter.ai/keys.
-
-### `RateLimitError`
-#### Description
-Raised when the rate limit is exceeded for a provider.
-#### Parameters
-| Name | Type | Required | Default Value |
-| --- | --- | --- | --- |
-| provider | string |  |  |
-| retryAfter | number |  | 1000 |
-
-#### Return Value
-None.
-
-#### Detected Patterns:
-- The error message includes a suggestion to retry.
-- The error message indicates the amount of time that must pass before retrying (1000ms by default).
-
-### `ParseError`
-#### Description
-Raised when there is an issue parsing a file.
-#### Parameters
-| Name | Type | Required | Default Value |
-| --- | --- | --- | --- |
-| filePath | string |  |  |
-| originalError | Error |  |  |
-
-#### Return Value
-None.
-
-### `RenderError`
-#### Description
-Raised when there is an issue rendering a format.
-#### Parameters
-| Name | Type | Required | Default Value |
-| --- | --- | --- | --- |
-| format | string |  |  |
-| originalError | Error |  |  |
-
-#### Return Value
-None.
-
-## Dependencies
-* `Error`

package/legacyver-docs/logger.md

@@ -1,83 +0,0 @@
-## Overview
-This module provides a logging system with configurable log levels and colorful output.
-
-## Functions
-
-### `setLevel(level)`
-#### Params | Description
-----------|-------------
-`level`    | The desired log level
-
-#### Returns
-None
-
-Sets the current log level to the specified `level`.
-
-### `setCI(val)`
-#### Params | Description
-----------|-------------
-`val`      | A boolean indicating whether CI mode is enabled
-
-#### Returns
-None
-
-Toggles the CI mode on or off.
-
-### `shouldLog(level)`
-#### Params | Description
-----------|-------------
-`level`    | The log level to check for
-
-#### Returns
-Boolean
-Determines whether the current log level allows logging at the specified `level`.
-
-### `debug(...args)`
-#### Params | Description
-----------|-------------
-`...args`  | Variable number of arguments to be logged as debug output
-
-#### Returns
-None
-Logs the provided `args` to the console with a gray '[debug]' prefix if the current log level allows it.
-
-### `info(...args)`
-#### Params | Description
-----------|-------------
-`...args`  | Variable number of arguments to be logged as info output
-
-#### Returns
-None
-Logs the provided `args` to the console with a cyan '[info]' prefix if the current log level allows it.
-
-### `warn(...args)`
-#### Params | Description
-----------|-------------
-`...args`  | Variable number of arguments to be logged as warn output
-
-#### Returns
-None
-Logs the provided `args` to the console with a yellow '[warn]' prefix if the current log level allows it.
-
-### `error(...args)`
-#### Params | Description
-----------|-------------
-`...args`  | Variable number of arguments to be logged as error output
-
-#### Returns
-None
-Logs the provided `args` to the console with a red '[error]' prefix if the current log level allows it.
-
-## Dependencies
-* picocolors (`pc`)
-
-## Usage Example
-```javascript
-const logger = require('./logger');
-
-logger.debug('This is a debug message');
-logger.info('This is an info message');
-logger.warn('This is a warn message');
-logger.error('This is an error message');
-```
-Note: This example demonstrates the usage of the `debug`, `info`, `warn`, and `error` functions, which are exported from the logger module.

package/nul

@@ -1,2 +0,0 @@
-dir: cannot access '/b': No such file or directory
-dir: cannot access '/s': No such file or directory