@codewalla_india/openspec 1.3.2 → 1.3.4

package/dist/core/templates/workflows/modify-change.js

@@ -3,163 +3,163 @@ export function getModifyChangeSkillTemplate() {
     return {
         name: 'openspec-modify-change',
         description: "Modify planning artifacts before implementation starts. Use when the user wants to revise artifacts after they've been created but before implementation begins.",
-        instructions: `Modify planning artifacts before implementation starts.
-
-${STORE_SELECTION_GUIDANCE}
-
-**Input**: Specify a change name and the artifact to modify (e.g., \`/openspec-modify-change modify-command proposal\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes and artifacts.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run \`openspec list --json\` to get available changes and ask the user to select one
-
-   Always announce: "Using change: <name>" and how to override (e.g., \`/openspec-modify-change <other>\`).
-
-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")
-   - \`planningHome\`, \`changeRoot\`, and \`actionContext\`: planning scope and edit constraints
-   - Which artifacts exist and their completion status
-
-3. **Validate pre-apply conditions**
-
-   Check if implementation has started by examining the tasks file:
-   - If any tasks are marked as complete (\`- [x]\`), modification is blocked
-   - Explain that modification is only allowed before \`/opsx:apply\` begins
-   - If blocked, suggest creating a new change or using \`/opsx:continue-change\` for artifact updates
-
-4. **Select the artifact to modify**
-
-   If the user specified an artifact, use it. Otherwise:
-   - Show available artifacts from the status output
-   - Ask the user which artifact to modify
-   - Explain that modifying an artifact will also update its dependents
-
-5. **Get modify instructions**
-
-   \`\`\`bash
-   openspec instructions modify --change "<name>" --artifact "<artifact-id>" --json
-   \`\`\`
-
-   This returns:
-   - \`artifactsToUpdate\`: list of artifacts that will be updated (direct and propagated)
-   - \`conflicts\`: any conflicts with manual edits (if present, modification is blocked)
-   - Success/failure status
-
-   **Handle states:**
-   - If \`success: false\` with conflicts: show conflicts, explain resolution options
-   - If \`success: false\` with pre-apply error: explain why modification is blocked
-   - If \`success: true\`: proceed with modification
-
-6. **Make the requested changes**
-
-   - Open the artifact file in the editor (if \`--editor\` flag is used)
-   - Make the requested modifications
-   - Save the file
-
-   **Important:** The modify command calculates which artifacts need updating based on the artifact graph. The system will handle:
-   - Direct modification of the specified artifact
-   - Propagation to dependent artifacts (in reverse topological order)
-   - Conflict detection with manual edits
-   - History tracking in the change marker
-
-7. **Verify the changes**
-
-   - Review the modified artifact
-   - If dependents were updated, review those as well
-   - Ensure changes align with the intended modification
-
-8. **Show summary**
-
-   Display:
-   - Artifact modified
-   - Dependent artifacts updated (if any)
-   - Modification history recorded
-   - Next steps (e.g., continue with other artifacts or proceed to apply)
-
-**Output During Modification**
-
-\`\`\`
-## Modifying: <change-name>
-
-**Artifact:** <artifact-id>
-**Dependents to update:** <list of dependent artifacts>
-
-[...modification happening...]
-✓ Modification complete
-\`\`\`
-
-**Output On Success**
-
-\`\`\`
-## Modification Complete
-
-**Change:** <change-name>
-**Artifact modified:** <artifact-id>
-**Dependents updated:** <list>
-
-### History Recorded
-- Timestamp: <timestamp>
-- Modified artifacts: <list>
-- Intent: <user's intent>
-
-**Next steps:**
-- Modify additional artifacts, or
-- Proceed with implementation: \`/opsx:apply-change\`
-\`\`\`
-
-**Output On Block (Pre-apply Validation Failed)**
-
-\`\`\`
-## Modification Blocked
-
-**Change:** <change-name>
-**Reason:** Implementation has started (tasks have been completed)
-
-**Options:**
-1. Use \`/opsx:continue-change\` to update artifacts during implementation
-2. Create a new change for the revision
-3. Proceed with current implementation and address changes in a follow-up
-
-What would you like to do?
-\`\`\`
-
-**Output On Block (Conflicts Detected)**
-
-\`\`\`
-## Modification Blocked
-
-**Change:** <change-name>
-**Artifact:** <artifact-id>
-**Reason:** Conflicts with manual edits
-
-### Conflicts
-- <artifact-id>: <affected sections>
-
-**Options:**
-1. Resolve conflicts manually and retry
-2. Accept manual edits and skip propagation
-3. Revert manual edits and allow propagation
-
-What would you like to do?
-\`\`\`
-
-**Guardrails**
-- Only allow modification before implementation starts (no completed tasks)
-- Always check for conflicts before modifying
-- Show which dependents will be updated
-- Record modification history in the change marker
-- Preserve manual edits when possible (conflict detection)
-- Explain blocking conditions clearly
-- Do not modify artifacts after implementation has begun
+        instructions: `Modify planning artifacts before implementation starts.
+
+${STORE_SELECTION_GUIDANCE}
+
+**Input**: Specify a change name and the artifact to modify (e.g., \`/openspec-modify-change modify-command proposal\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes and artifacts.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run \`openspec list --json\` to get available changes and ask the user to select one
+
+   Always announce: "Using change: <name>" and how to override (e.g., \`/openspec-modify-change <other>\`).
+
+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")
+   - \`planningHome\`, \`changeRoot\`, and \`actionContext\`: planning scope and edit constraints
+   - Which artifacts exist and their completion status
+
+3. **Validate pre-apply conditions**
+
+   Check if implementation has started by examining the tasks file:
+   - If any tasks are marked as complete (\`- [x]\`), modification is blocked
+   - Explain that modification is only allowed before \`/opsx:apply\` begins
+   - If blocked, suggest creating a new change or using \`/opsx:continue-change\` for artifact updates
+
+4. **Select the artifact to modify**
+
+   If the user specified an artifact, use it. Otherwise:
+   - Show available artifacts from the status output
+   - Ask the user which artifact to modify
+   - Explain that modifying an artifact will also update its dependents
+
+5. **Get modify instructions**
+
+   \`\`\`bash
+   openspec instructions modify --change "<name>" --artifact "<artifact-id>" --json
+   \`\`\`
+
+   This returns:
+   - \`artifactsToUpdate\`: list of artifacts that will be updated (direct and propagated)
+   - \`conflicts\`: any conflicts with manual edits (if present, modification is blocked)
+   - Success/failure status
+
+   **Handle states:**
+   - If \`success: false\` with conflicts: show conflicts, explain resolution options
+   - If \`success: false\` with pre-apply error: explain why modification is blocked
+   - If \`success: true\`: proceed with modification
+
+6. **Make the requested changes**
+
+   - Open the artifact file in the editor (if \`--editor\` flag is used)
+   - Make the requested modifications
+   - Save the file
+
+   **Important:** The modify command calculates which artifacts need updating based on the artifact graph. The system will handle:
+   - Direct modification of the specified artifact
+   - Propagation to dependent artifacts (in reverse topological order)
+   - Conflict detection with manual edits
+   - History tracking in the change marker
+
+7. **Verify the changes**
+
+   - Review the modified artifact
+   - If dependents were updated, review those as well
+   - Ensure changes align with the intended modification
+
+8. **Show summary**
+
+   Display:
+   - Artifact modified
+   - Dependent artifacts updated (if any)
+   - Modification history recorded
+   - Next steps (e.g., continue with other artifacts or proceed to apply)
+
+**Output During Modification**
+
+\`\`\`
+## Modifying: <change-name>
+
+**Artifact:** <artifact-id>
+**Dependents to update:** <list of dependent artifacts>
+
+[...modification happening...]
+✓ Modification complete
+\`\`\`
+
+**Output On Success**
+
+\`\`\`
+## Modification Complete
+
+**Change:** <change-name>
+**Artifact modified:** <artifact-id>
+**Dependents updated:** <list>
+
+### History Recorded
+- Timestamp: <timestamp>
+- Modified artifacts: <list>
+- Intent: <user's intent>
+
+**Next steps:**
+- Modify additional artifacts, or
+- Proceed with implementation: \`/opsx:apply-change\`
+\`\`\`
+
+**Output On Block (Pre-apply Validation Failed)**
+
+\`\`\`
+## Modification Blocked
+
+**Change:** <change-name>
+**Reason:** Implementation has started (tasks have been completed)
+
+**Options:**
+1. Use \`/opsx:continue-change\` to update artifacts during implementation
+2. Create a new change for the revision
+3. Proceed with current implementation and address changes in a follow-up
+
+What would you like to do?
+\`\`\`
+
+**Output On Block (Conflicts Detected)**
+
+\`\`\`
+## Modification Blocked
+
+**Change:** <change-name>
+**Artifact:** <artifact-id>
+**Reason:** Conflicts with manual edits
+
+### Conflicts
+- <artifact-id>: <affected sections>
+
+**Options:**
+1. Resolve conflicts manually and retry
+2. Accept manual edits and skip propagation
+3. Revert manual edits and allow propagation
+
+What would you like to do?
+\`\`\`
+
+**Guardrails**
+- Only allow modification before implementation starts (no completed tasks)
+- Always check for conflicts before modifying
+- Show which dependents will be updated
+- Record modification history in the change marker
+- Preserve manual edits when possible (conflict detection)
+- Explain blocking conditions clearly
+- Do not modify artifacts after implementation has begun
 `,
         license: 'MIT',
         compatibility: 'Requires openspec CLI.',
@@ -172,82 +172,82 @@ export function getOpsxModifyCommandTemplate() {
         description: "Modify a planning artifact before implementation starts - with dependency propagation and conflict detection (Experimental)",
         category: 'Workflow',
         tags: ['workflow', 'artifacts', 'experimental'],
-        content: `Modify a planning artifact before implementation starts. Only works before implementation begins.
-
-${STORE_SELECTION_GUIDANCE}
-
-**Input**: Specify a change name and artifact to modify (e.g., \`/opsx:modify <change-name> --artifact <artifact-id>\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes and artifacts.
-
-\`/opsx:continue\` is an expanded-profile workflow and may not be installed. Before suggesting it anywhere below, verify that it is available. If it is unavailable, \`openspec status --change "<name>" --json\` shows the next artifact and \`openspec instructions "<artifact-id>" --change "<name>" --json\` explains how to create it.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run \`openspec list --json\` to get available changes sorted by most recently modified, and ask the user to select one
-
-   When prompting, present the top 3-4 most recently modified changes as options, showing:
-   - Change name
-   - Schema (from \`schema\` field if present, otherwise "spec-driven")
-   - Status (e.g., "0/5 tasks", "complete", "no tasks")
-   - How recently it was modified (from \`lastModified\` field)
-
-   Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to modify.
-
-   Always announce: "Using change: <name>" and how to override (e.g., \`/opsx:modify <other>\`).
-
-2. **Check pre-apply conditions**
-
-   \`\`\`bash
-   openspec instructions modify --change "<name>" --artifact "<artifact-id>" --json
-   \`\`\`
-
-   This validates that implementation hasn't started by checking tasks.md for completed tasks. If blocked, the command returns an error with the reason.
-
-3. **Review update scope**
-
-   The command returns a list of artifacts that will be updated in reverse topological order (deepest dependents first). Review this list to understand the impact.
-
-4. **Check for conflicts**
-
-   The command returns any conflicts with manual edits in downstream artifacts. If conflicts exist, modification is blocked and you must resolve them first.
-
-5. **Make the modification**
-
-   - Open the artifact file for editing
-   - Make the requested changes
-   - Save the file
-
-   The modify command will:
-   - Calculate affected artifacts using the artifact graph
-   - Propagate changes to dependents automatically
-   - Record modification history in the change marker
-   - Emit telemetry events
-
-6. **Verify the changes**
-
-   - Review the modified artifact
-   - Review any propagated changes to dependents
-   - Ensure changes align with the intended modification
-
-**Output**
-
-After modification, show:
-- Artifact modified
-- Dependent artifacts updated (if any)
-- Modification history recorded
-- Next steps (e.g., modify additional artifacts or proceed to apply)
-
-**Guardrails**
-- Modification is blocked if implementation has started (any completed tasks)
-- Modification is blocked if conflicts with manual edits exist
-- Do not modify artifacts after implementation begins
-- Always check for conflicts before modifying
-- Use the artifact ids and paths reported by \`openspec status\`; never branch on hardcoded artifact names
-- The modify command handles dependency propagation automatically - do not manually update dependents
+        content: `Modify a planning artifact before implementation starts. Only works before implementation begins.
+
+${STORE_SELECTION_GUIDANCE}
+
+**Input**: Specify a change name and artifact to modify (e.g., \`/opsx:modify <change-name> --artifact <artifact-id>\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes and artifacts.
+
+\`/opsx:continue\` is an expanded-profile workflow and may not be installed. Before suggesting it anywhere below, verify that it is available. If it is unavailable, \`openspec status --change "<name>" --json\` shows the next artifact and \`openspec instructions "<artifact-id>" --change "<name>" --json\` explains how to create it.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run \`openspec list --json\` to get available changes sorted by most recently modified, and ask the user to select one
+
+   When prompting, present the top 3-4 most recently modified changes as options, showing:
+   - Change name
+   - Schema (from \`schema\` field if present, otherwise "spec-driven")
+   - Status (e.g., "0/5 tasks", "complete", "no tasks")
+   - How recently it was modified (from \`lastModified\` field)
+
+   Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to modify.
+
+   Always announce: "Using change: <name>" and how to override (e.g., \`/opsx:modify <other>\`).
+
+2. **Check pre-apply conditions**
+
+   \`\`\`bash
+   openspec instructions modify --change "<name>" --artifact "<artifact-id>" --json
+   \`\`\`
+
+   This validates that implementation hasn't started by checking tasks.md for completed tasks. If blocked, the command returns an error with the reason.
+
+3. **Review update scope**
+
+   The command returns a list of artifacts that will be updated in reverse topological order (deepest dependents first). Review this list to understand the impact.
+
+4. **Check for conflicts**
+
+   The command returns any conflicts with manual edits in downstream artifacts. If conflicts exist, modification is blocked and you must resolve them first.
+
+5. **Make the modification**
+
+   - Open the artifact file for editing
+   - Make the requested changes
+   - Save the file
+
+   The modify command will:
+   - Calculate affected artifacts using the artifact graph
+   - Propagate changes to dependents automatically
+   - Record modification history in the change marker
+   - Emit telemetry events
+
+6. **Verify the changes**
+
+   - Review the modified artifact
+   - Review any propagated changes to dependents
+   - Ensure changes align with the intended modification
+
+**Output**
+
+After modification, show:
+- Artifact modified
+- Dependent artifacts updated (if any)
+- Modification history recorded
+- Next steps (e.g., modify additional artifacts or proceed to apply)
+
+**Guardrails**
+- Modification is blocked if implementation has started (any completed tasks)
+- Modification is blocked if conflicts with manual edits exist
+- Do not modify artifacts after implementation begins
+- Always check for conflicts before modifying
+- Use the artifact ids and paths reported by \`openspec status\`; never branch on hardcoded artifact names
+- The modify command handles dependency propagation automatically - do not manually update dependents
 `,
     };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codewalla_india/openspec",
-  "version": "1.3.2",
+  "version": "1.3.4",
   "description": "AI-native system for spec-driven development",
   "keywords": [
     "openspec",

package/schemas/spec-driven/templates/plan-template.md

@@ -1,91 +1,91 @@
-## Code Map
-
-<!-- List all files that will be created, modified, or deleted for this change -->
-
-### Files to Create
-<!-- List new files to be created with brief descriptions -->
-<!-- Example:
-- `src/core/new-feature.ts` - Core implementation of new feature
-- `src/core/new-feature.test.ts` - Unit tests for new feature
--->
-
-### Files to Modify
-<!-- List existing files that will be modified with brief descriptions -->
-<!-- Example:
-- `src/core/index.ts` - Export new feature module
-- `src/cli/commands.ts` - Add CLI command for new feature
--->
-
-### Files to Delete
-<!-- List files that will be removed (if any) -->
-<!-- Example:
-- `src/legacy/old-feature.ts` - Remove deprecated feature
--->
-
-## Implementation Order
-
-<!-- Sequence the implementation work at file/module level -->
-<!-- Use numbered steps with file references in parentheses -->
-<!-- Example:
-
-1. **Core Implementation** (new-feature.ts)
-   - Implement primary data structures
-   - Add main function logic
-   - Handle edge cases
-
-2. **CLI Integration** (commands.ts)
-   - Add command registration
-   - Implement command handler
-   - Add help text
-
-3. **Testing** (new-feature.test.ts)
-   - Write unit tests
-   - Add integration tests
-   - Verify coverage
--->
-
-## Test Plan
-
-<!-- Describe how to verify the change -->
-<!-- Include test types: unit, integration, e2e, manual -->
-<!-- Example:
-
-### Unit Tests
-- Test core function with valid inputs
-- Test error handling for invalid inputs
-- Test edge cases
-
-### Integration Tests
-- Test CLI command with real filesystem
-- Test integration with existing modules
-
-### Manual Tests
-- Verify CLI command works as expected
-- Check error messages are clear
--->
-
-## Risks
-
-<!-- Identify known risks with mitigations -->
-<!-- Format: [Risk] → Mitigation -->
-<!-- Example:
-
-**Breaking Change Risk**
-- [Risk] Existing users may rely on old behavior
-- [Mitigation] Provide migration guide, add deprecation warning
-
-**Performance Risk**
-- [Risk] New feature may slow down existing operations
-- [Mitigation] Add performance tests, optimize hot paths
--->
-
-## Done Definition
-
-<!-- Define objective criteria for completion -->
-<!-- Example:
-- All unit tests passing
-- All integration tests passing
-- Documentation updated
-- Error messages are clear and actionable
-- Performance requirements met
--->
+## Code Map
+
+<!-- List all files that will be created, modified, or deleted for this change -->
+
+### Files to Create
+<!-- List new files to be created with brief descriptions -->
+<!-- Example:
+- `src/core/new-feature.ts` - Core implementation of new feature
+- `src/core/new-feature.test.ts` - Unit tests for new feature
+-->
+
+### Files to Modify
+<!-- List existing files that will be modified with brief descriptions -->
+<!-- Example:
+- `src/core/index.ts` - Export new feature module
+- `src/cli/commands.ts` - Add CLI command for new feature
+-->
+
+### Files to Delete
+<!-- List files that will be removed (if any) -->
+<!-- Example:
+- `src/legacy/old-feature.ts` - Remove deprecated feature
+-->
+
+## Implementation Order
+
+<!-- Sequence the implementation work at file/module level -->
+<!-- Use numbered steps with file references in parentheses -->
+<!-- Example:
+
+1. **Core Implementation** (new-feature.ts)
+   - Implement primary data structures
+   - Add main function logic
+   - Handle edge cases
+
+2. **CLI Integration** (commands.ts)
+   - Add command registration
+   - Implement command handler
+   - Add help text
+
+3. **Testing** (new-feature.test.ts)
+   - Write unit tests
+   - Add integration tests
+   - Verify coverage
+-->
+
+## Test Plan
+
+<!-- Describe how to verify the change -->
+<!-- Include test types: unit, integration, e2e, manual -->
+<!-- Example:
+
+### Unit Tests
+- Test core function with valid inputs
+- Test error handling for invalid inputs
+- Test edge cases
+
+### Integration Tests
+- Test CLI command with real filesystem
+- Test integration with existing modules
+
+### Manual Tests
+- Verify CLI command works as expected
+- Check error messages are clear
+-->
+
+## Risks
+
+<!-- Identify known risks with mitigations -->
+<!-- Format: [Risk] → Mitigation -->
+<!-- Example:
+
+**Breaking Change Risk**
+- [Risk] Existing users may rely on old behavior
+- [Mitigation] Provide migration guide, add deprecation warning
+
+**Performance Risk**
+- [Risk] New feature may slow down existing operations
+- [Mitigation] Add performance tests, optimize hot paths
+-->
+
+## Done Definition
+
+<!-- Define objective criteria for completion -->
+<!-- Example:
+- All unit tests passing
+- All integration tests passing
+- Documentation updated
+- Error messages are clear and actionable
+- Performance requirements met
+-->