Opsx Apply

Implement tasks from an OpenSpec change.

**Input**: `$ARGUMENTS` — optionally specify a change name (e.g., `/opsx-apply add-auth`). If omitted, infer from conversation context or prompt.

**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` and ask the user to select

   Always announce: "Using change: <name>" and how to override.

2. **Pre-flight git checks** (mandatory per `.claude/docs/git-workflow.md`)

   ```bash
   git status --porcelain
   git branch --show-current

• If on the wrong branch AND working directory is clean: git switch -c feature-<name>
• If on the wrong branch AND dirty: STOP immediately and ask the user for guidance

3. Check status to understand the schema

   openspec status --change "<name>" --json
   

   Parse schemaName and identify which artifact contains the tasks.

4. Get apply instructions

   openspec instructions apply --change "<name>" --json
   

   Handle states:

   • state: "blocked" (missing artifacts): show message and complete missing artifacts first
   • state: "all_done": congratulate, suggest /opsx-archive
   • Otherwise: proceed to implementation

5. Read context files

   Read all files listed in contextFiles from the apply instructions output.

   Also read the mandatory architecture docs before writing any code:

   • .claude/docs/onion-architecture.md — layer rules and New File Checklist (Section 7), violation codes V-1…V-12
   • .claude/docs/Feature-Driven-Structure.md — vertical slices layout, New Folder/Feature Checklist (Section 4), S-1…S-4
   • .claude/docs/CQRS-and-Data-Flow.md — pipeline rules, New File Checklist (Section 4), F-1…F-4
   • .claude/docs/DI-and-IoC.md — registration rules, DI Modification Checklist (Section 5), D-1…D-3

   Run the checklists from these docs before creating any .cs file. If a violation is unavoidable due to the Plan, STOP and report — do NOT implement the violation silently.

6. Show current progress

   Display: schema, progress (N/M tasks complete), remaining tasks overview.

7. Implement tasks (loop until done or blocked)

   Use the TodoWrite tool to track task progress.

   For each pending task:

   • Show which task is being worked on
   • Make the code changes required
   • Keep changes minimal and focused
   • Mark task complete in the tasks file: - [ ] → - [x]
   • Continue to next task

   Pause if:

   • Task is unclear → ask for clarification
   • Implementation reveals a design issue → suggest updating artifacts
   • Error or blocker encountered → report and wait for guidance

   Before marking all tasks complete, validate:

   dotnet build TextAdaptor.sln -c Release -v minimal
   dotnet test TextAdaptor.sln -c Release --no-build --logger "trx;LogFileName=TestResults.trx" -v minimal
   

8. On completion or pause, show status

   Display tasks completed this session, overall progress, and next steps.

Output On Completion

## Implementation Complete

**Change:** <change-name>
**Schema:** <schema-name>
**Progress:** 7/7 tasks complete

### Completed This Session
- [x] Task 1
- [x] Task 2
...

All tasks complete! Run `/opsx-review` to start the code review.

Output On Pause (Issue Encountered)

## Implementation Paused

**Change:** <change-name>
**Progress:** 4/7 tasks complete

### Issue Encountered
<description>

**Options:**
1. <option 1>
2. <option 2>

Guardrails

• Keep going through tasks until done or blocked
• Always read context files before starting
• If task is ambiguous, pause and ask before implementing
• Keep code changes minimal and scoped to each task
• Update task checkbox immediately after completing each task
• Pause on errors, blockers, or unclear requirements — don't guess
• Do NOT commit or push — the user commits manually