@trycore/spec-build-harness 0.1.0

package/skills/building-a-slice/references/mcp-map.md

@@ -0,0 +1,29 @@
+# Mapa MCP / LSP por gate
+
+Qué herramienta externa apoya cada fase del pipeline. Los MCP listados abajo son **ejemplos opt-in**:
+el consumidor decide cuáles habilitar en su entorno según el stack declarado en su PRD. No asumas que
+están disponibles; cuando lo estén, se usan **bajo demanda** para no saturar el contexto.
+
+## LSP — navegación semántica (toda fase con código)
+- **TypeScript LSP**: seguir definiciones/referencias con precisión de compilador (mejor ROI que
+  `grep` en TS tipado). Útil para `coherence-three-way` (trazar símbolo→test) y
+  `simple-design-reviewer` (uso real de una función, duplicación).
+
+## MCP por gate (ejemplos opt-in)
+Estos MCP son ejemplos representativos; habilita solo los que apliquen a tu stack. Si tu entorno no
+los expone, el gate se cubre con las alternativas CLI/test indicadas.
+| Fase / agente | MCP (ejemplo, si habilitado) | Para qué |
+|---|---|---|
+| `review` · `ux-krug-reviewer` | **chrome-devtools** | `take_snapshot` (árbol accesible), `lighthouse_audit` (Accessibility/Best-Practices), `take_screenshot`, `list_console_messages` para verificar la UI **corriendo**. |
+| `api` · `api-contract-tester` | — (Newman CLI) | Contratos de endpoints. Newman no es MCP; corre vía Bash. |
+| `data` · `data-consistency-checker` | **postgresql** *(solo si el slice usa Postgres)* | `read_query`/`describe_table` para validar consistencia en BD. Con un almacén embebido/cliente (según el stack declarado en el PRD del consumidor) se valida por tests, sin MCP. |
+| perf (opcional, fuera del DoD) | **k6** | `execute_k6_test` para carga/latencia si una HU de la épica lo exige. |
+
+## Reglas de uso
+- **Opt-in y just-in-time**: habilita el MCP solo si tu entorno lo expone, e invócalo solo en su
+  fase; no lo cargues "por si acaso".
+- **chrome-devtools** (si habilitado) requiere la app levantada; úsalo en fase `active`.
+- Para diagramas de arquitectura del slice, el ecosistema **figma** es otro ejemplo opt-in: si está
+  habilitado puede ayudar, pero es opcional y no forma parte de ningún gate.
+- Datos sintéticos siempre: ningún MCP debe recibir datos sensibles / PII regulados reales (los que
+  el consumidor declara en el bloque de dominio de su CLAUDE.md o su PRD) ni secretos.

package/skills/building-a-slice/references/newman-tests.md

@@ -0,0 +1,47 @@
+# Pruebas de contrato con Newman (endpoints)
+
+Guía que aplica `api-contract-tester` a slices con Route Handlers / Server Actions. Newman es el
+runner CLI de colecciones Postman. (No es un MCP; se ejecuta vía Bash.)
+
+## Estructura de archivos
+```
+tests/postman/
+├── <slice>.postman_collection.json    # requests + aserciones del slice
+└── environment.json                   # baseUrl y variables (sin secretos reales)
+```
+
+## Diseño de la colección (alineada a los AC de las HU de la épica)
+Por cada endpoint del slice, al menos tres requests que reflejen los AC en Given/When/Then:
+- **Happy**: entrada válida → status 2xx + **forma de respuesta** esperada (validar esquema, no solo el status).
+- **Error**: entrada inválida → 4xx con mensaje útil y **sin filtrar datos sensibles / PII regulados** ni detalles internos.
+- **Edge**: límites del dominio (campo obligatorio faltante, respuesta de servicio externo parcial, casos borde del dominio declarados por el consumidor…).
+
+Aserciones recomendadas en cada request (`pm.test`):
+```javascript
+pm.test("status", () => pm.response.to.have.status(200));
+pm.test("shape", () => {
+  const b = pm.response.json();
+  pm.expect(b).to.have.property("resultado");
+  // (sustituir por el contrato del consumidor: las decisiones de alto impacto
+  //  del dominio se declaran en su domain-pack / PRD)
+  pm.expect(b.decision).to.be.oneOf(["DECISION_A","DECISION_B","DECISION_C"]);
+});
+```
+
+## Ejecución
+```bash
+# 1) levantar la app (si aplica), p.ej. en background:
+npm run dev   # o: npm run build && npm run start
+# 2) correr Newman cuando el server esté listo:
+npx --yes newman run tests/postman/<slice>.postman_collection.json \
+  -e tests/postman/environment.json \
+  --reporters cli,json \
+  --reporter-json-export .claude/state/newman-<slice>.json
+```
+
+## Interpretación → gate
+- **100% requests + assertions verdes** → `gates.api: true`.
+- Cualquier fallo → `gates.api: false`, reportando request + aserción + causa.
+- Slice sin endpoints → `gates.api: null` (N/A, no bloquea DoD).
+
+> El entorno usa datos sintéticos. Nunca incluyas datos sensibles / PII regulados reales ni claves de servicios externos declaradas server-side en la colección o el environment versionado.

package/skills/building-a-slice/references/simple-design.md

@@ -0,0 +1,33 @@
+# Diseño simple (Kent Beck) + code smells
+
+Guía que aplica `simple-design-reviewer` sobre código **que ya pasa los tests**.
+
+## Las 4 reglas de diseño simple (orden de prioridad de Beck)
+1. **Pasa los tests.** Correcto antes que bonito.
+2. **Revela la intención.** Nombres y estructura cuentan la historia; un lector entiende sin adivinar.
+3. **No tiene duplicación.** DRY de *conocimiento* (no de texto casual). Regla de tres antes de extraer.
+4. **Menos elementos.** Lo mínimo que cumpla 1–3. YAGNI: nada especulativo.
+
+Conflictos: 1 manda siempre; entre 2 y 3, prioriza eliminar duplicación; entre 4 y 2/3, prioriza
+revelar intención y no duplicar (la concisión no justifica oscuridad).
+
+## Smells frecuentes (y su refactor)
+| Smell | Señal | Refactor |
+|---|---|---|
+| Función larga | hace muchas cosas | Extract Function; una responsabilidad |
+| Lista de parámetros larga | 4+ params | Introduce Parameter Object |
+| Números/strings mágicos | literales sueltos | Constante con nombre / config versionada |
+| Duplicación | misma lógica en 2+ sitios | Extraer función/módulo compartido |
+| Feature envy | un módulo usa más datos de otro | Mover el comportamiento a donde viven los datos |
+| Componente "Dios" | UI + estado + lógica de negocio | Separar la capa de decisión del dominio de la vista |
+| `any` / casts | tipos perdidos | Tipar con interfaces/zod |
+| Comentario-muleta | explica código confuso | Renombrar/extraer hasta que sobre el comentario |
+| Código muerto | no se referencia | Borrar |
+
+## Específico del dominio
+- La **capa de decisión determinista del dominio** vive en su propio módulo puro (testeable, sin UI, sin IA): mismas entradas → misma salida, explicable.
+- **Parámetros de decisión** (umbrales, pesos, bandas) = configuración versionada, jamás literales repartidos por el código.
+- La **capa de servicios externos** (el servicio externo/IA de la frontera declarada por el consumidor) queda aislada detrás de una interfaz; el resto del código no la conoce.
+- La salida de cualquier servicio externo/IA se trata como **input no confiable**: validación contra un esquema fijo centralizada (un solo esquema reutilizado) antes de alimentar la capa de decisión.
+
+Clasifica hallazgos en BLOQUEANTE / RECOMENDADO / NIT. Solo los BLOQUEANTES impiden `gates.smell`.

package/skills/building-a-slice/references/state-protocol.md

@@ -0,0 +1,48 @@
+# Protocolo del archivo de estado (`build-state.json`)
+
+El estado es **cómo se comunican los agentes** en el modelo secuencial: cada uno lee antes de
+actuar y escribe su resultado, dejando el testigo al siguiente. Esquema y reglas base viven en
+`.claude/state/README.md` y `.claude/state/build-state.schema.json`; aquí va el uso operativo.
+
+## Lectura
+```bash
+python3 -c 'import json;print(json.dumps(json.load(open(".claude/state/build-state.json")),indent=2,ensure_ascii=False))'
+```
+- `active_slice == null` → no hay slice; solo `dor` puede abrir uno.
+- Si no es null → identifica el **primer gate en `false`**: ahí se reanuda.
+
+## Escritura (una transición = una escritura)
+Patrón seguro (lee-modifica-escribe) con timestamp UTC:
+```bash
+python3 - <<'PY'
+import json,datetime
+p=".claude/state/build-state.json"; d=json.load(open(p))
+s=d["active_slice"]
+s["gates"]["journey_smoke"]=True  # el gate que cierras (inner loop)
+s["phase"]="smoke"               # la nueva fase
+s["updated_at"]=datetime.datetime.now(datetime.timezone.utc).isoformat()
+s["updated_by"]="build-orchestrator"  # quién escribe
+json.dump(d,open(p,"w"),indent=2,ensure_ascii=False)
+PY
+```
+
+## Inner loop vs releases[]
+- **Inner loop (por slice)**: gates `dor`, `tdd`, `journey_smoke`, `coherence_link`, `data`, `api`,
+  `dod` en `active_slice.gates`. Los escribe el flujo de `building-a-slice` / `build-orchestrator`.
+- **Outer loop (por release)**: los gates pesados (`security`, `smell`, `ux`, `coherence`,
+  `stack_arch`, `integration`) **no** viven en el slice — viven en una entrada de `releases[]` que
+  escribe la skill `releasing-a-version`. Una release = una línea de release del Story Map.
+
+## Reglas
+1. **No saltes gates**: no cierres `dod` con gates abiertos.
+2. **Retroceso permitido**: si una revisión posterior falla, pon su gate en `false` y retrocede `phase`.
+3. **`ux`/`api` = `null`** cuando no aplican (no cuentan como abiertos para DoD).
+4. **Archivar**: mueve `active_slice` a `history[]` con `phase:"archived"`, deja `active_slice:null`.
+5. **Valida tras escribir**:
+   ```bash
+   python3 -c "import jsonschema,json; jsonschema.Draft202012Validator(json.load(open('.claude/state/build-state.schema.json'))).validate(json.load(open('.claude/state/build-state.json'))); print('OK')"
+   ```
+
+## Tabla de responsabilidad (quién cierra cada gate)
+Ver `.claude/state/README.md` § "Quién escribe qué". El `build-orchestrator` es el único que
+transiciona `phase` y archiva; los reviewers solo tocan su propio gate.

package/skills/openspec-apply-change/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: openspec-apply-change
+description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.0.2"
+---
+
+Implement tasks from an OpenSpec change.
+
+**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. **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 use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <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")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read the files listed in `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   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
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**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! Ready to archive this change.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- 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
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly

package/skills/openspec-archive-change/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: openspec-archive-change
+description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.0.2"
+---
+
+Archive a completed change in the experimental workflow.
+
+**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 only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run `openspec status --change "<name>" --json` to check artifact completion.
+
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used
+   - `artifacts`: List of artifacts with their status (`done` or other)
+
+   **If any artifacts are not `done`:**
+   - Display warning listing incomplete artifacts
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+   **If delta specs exist:**
+   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Determine what changes would be applied (adds, modifications, removals, renames)
+   - Show a combined summary before prompting
+
+   **Prompt options:**
+   - If changes needed: "Sync now (recommended)", "Archive without syncing"
+   - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+   If user chooses sync, execute /opsx:sync logic (use the openspec-sync-specs skill). Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   ```bash
+   mkdir -p openspec/changes/archive
+   ```
+
+   Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   ```bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Whether specs were synced (if applicable)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
+
+All artifacts complete. All tasks complete.
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use openspec-sync-specs approach (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting

package/skills/openspec-bulk-archive-change/SKILL.md

@@ -0,0 +1,246 @@
+---
+name: openspec-bulk-archive-change
+description: Archive multiple completed changes at once. Use when archiving several parallel changes.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.0.2"
+---
+
+Archive multiple completed changes in a single operation.
+
+This skill allows you to batch-archive changes, handling spec conflicts intelligently by checking the codebase to determine what's actually implemented.
+
+**Input**: None required (prompts for selection)
+
+**Steps**
+
+1. **Get active changes**
+
+   Run `openspec list --json` to get all active changes.
+
+   If no active changes exist, inform user and stop.
+
+2. **Prompt for change selection**
+
+   Use **AskUserQuestion tool** with multi-select to let user choose changes:
+   - Show each change with its schema
+   - Include an option for "All changes"
+   - Allow any number of selections (1+ works, 2+ is the typical use case)
+
+   **IMPORTANT**: Do NOT auto-select. Always let the user choose.
+
+3. **Batch validation - gather status for all selected changes**
+
+   For each selected change, collect:
+
+   a. **Artifact status** - Run `openspec status --change "<name>" --json`
+      - Parse `schemaName` and `artifacts` list
+      - Note which artifacts are `done` vs other states
+
+   b. **Task completion** - Read `openspec/changes/<name>/tasks.md`
+      - Count `- [ ]` (incomplete) vs `- [x]` (complete)
+      - If no tasks file exists, note as "No tasks"
+
+   c. **Delta specs** - Check `openspec/changes/<name>/specs/` directory
+      - List which capability specs exist
+      - For each, extract requirement names (lines matching `### Requirement: <name>`)
+
+4. **Detect spec conflicts**
+
+   Build a map of `capability -> [changes that touch it]`:
+
+   ```
+   auth -> [change-a, change-b]  <- CONFLICT (2+ changes)
+   api  -> [change-c]            <- OK (only 1 change)
+   ```
+
+   A conflict exists when 2+ selected changes have delta specs for the same capability.
+
+5. **Resolve conflicts agentically**
+
+   **For each conflict**, investigate the codebase:
+
+   a. **Read the delta specs** from each conflicting change to understand what each claims to add/modify
+
+   b. **Search the codebase** for implementation evidence:
+      - Look for code implementing requirements from each delta spec
+      - Check for related files, functions, or tests
+
+   c. **Determine resolution**:
+      - If only one change is actually implemented -> sync that one's specs
+      - If both implemented -> apply in chronological order (older first, newer overwrites)
+      - If neither implemented -> skip spec sync, warn user
+
+   d. **Record resolution** for each conflict:
+      - Which change's specs to apply
+      - In what order (if both)
+      - Rationale (what was found in codebase)
+
+6. **Show consolidated status table**
+
+   Display a table summarizing all changes:
+
+   ```
+   | Change               | Artifacts | Tasks | Specs   | Conflicts | Status |
+   |---------------------|-----------|-------|---------|-----------|--------|
+   | schema-management   | Done      | 5/5   | 2 delta | None      | Ready  |
+   | project-config      | Done      | 3/3   | 1 delta | None      | Ready  |
+   | add-oauth           | Done      | 4/4   | 1 delta | auth (!)  | Ready* |
+   | add-verify-skill    | 1 left    | 2/5   | None    | None      | Warn   |
+   ```
+
+   For conflicts, show the resolution:
+   ```
+   * Conflict resolution:
+     - auth spec: Will apply add-oauth then add-jwt (both implemented, chronological order)
+   ```
+
+   For incomplete changes, show warnings:
+   ```
+   Warnings:
+   - add-verify-skill: 1 incomplete artifact, 3 incomplete tasks
+   ```
+
+7. **Confirm batch operation**
+
+   Use **AskUserQuestion tool** with a single confirmation:
+
+   - "Archive N changes?" with options based on status
+   - Options might include:
+     - "Archive all N changes"
+     - "Archive only N ready changes (skip incomplete)"
+     - "Cancel"
+
+   If there are incomplete changes, make clear they'll be archived with warnings.
+
+8. **Execute archive for each confirmed change**
+
+   Process changes in the determined order (respecting conflict resolution):
+
+   a. **Sync specs** if delta specs exist:
+      - Use the openspec-sync-specs approach (agent-driven intelligent merge)
+      - For conflicts, apply in resolved order
+      - Track if sync was done
+
+   b. **Perform the archive**:
+      ```bash
+      mkdir -p openspec/changes/archive
+      mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+      ```
+
+   c. **Track outcome** for each change:
+      - Success: archived successfully
+      - Failed: error during archive (record error)
+      - Skipped: user chose not to archive (if applicable)
+
+9. **Display summary**
+
+   Show final results:
+
+   ```
+   ## Bulk Archive Complete
+
+   Archived 3 changes:
+   - schema-management-cli -> archive/2026-01-19-schema-management-cli/
+   - project-config -> archive/2026-01-19-project-config/
+   - add-oauth -> archive/2026-01-19-add-oauth/
+
+   Skipped 1 change:
+   - add-verify-skill (user chose not to archive incomplete)
+
+   Spec sync summary:
+   - 4 delta specs synced to main specs
+   - 1 conflict resolved (auth: applied both in chronological order)
+   ```
+
+   If any failures:
+   ```
+   Failed 1 change:
+   - some-change: Archive directory already exists
+   ```
+
+**Conflict Resolution Examples**
+
+Example 1: Only one implemented
+```
+Conflict: specs/auth/spec.md touched by [add-oauth, add-jwt]
+
+Checking add-oauth:
+- Delta adds "OAuth Provider Integration" requirement
+- Searching codebase... found src/auth/oauth.ts implementing OAuth flow
+
+Checking add-jwt:
+- Delta adds "JWT Token Handling" requirement
+- Searching codebase... no JWT implementation found
+
+Resolution: Only add-oauth is implemented. Will sync add-oauth specs only.
+```
+
+Example 2: Both implemented
+```
+Conflict: specs/api/spec.md touched by [add-rest-api, add-graphql]
+
+Checking add-rest-api (created 2026-01-10):
+- Delta adds "REST Endpoints" requirement
+- Searching codebase... found src/api/rest.ts
+
+Checking add-graphql (created 2026-01-15):
+- Delta adds "GraphQL Schema" requirement
+- Searching codebase... found src/api/graphql.ts
+
+Resolution: Both implemented. Will apply add-rest-api specs first,
+then add-graphql specs (chronological order, newer takes precedence).
+```
+
+**Output On Success**
+
+```
+## Bulk Archive Complete
+
+Archived N changes:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+- <change-2> -> archive/YYYY-MM-DD-<change-2>/
+
+Spec sync summary:
+- N delta specs synced to main specs
+- No conflicts (or: M conflicts resolved)
+```
+
+**Output On Partial Success**
+
+```
+## Bulk Archive Complete (partial)
+
+Archived N changes:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+
+Skipped M changes:
+- <change-2> (user chose not to archive incomplete)
+
+Failed K changes:
+- <change-3>: Archive directory already exists
+```
+
+**Output When No Changes**
+
+```
+## No Changes to Archive
+
+No active changes found. Use `/opsx:new` to create a new change.
+```
+
+**Guardrails**
+- Allow any number of changes (1+ is fine, 2+ is the typical use case)
+- Always prompt for selection, never auto-select
+- Detect spec conflicts early and resolve by checking codebase
+- When both changes are implemented, apply specs in chronological order
+- Skip spec sync only when implementation is missing (warn user)
+- Show clear per-change status before confirming
+- Use single confirmation for entire batch
+- Track and report all outcomes (success/skip/fail)
+- Preserve .openspec.yaml when moving to archive
+- Archive directory target uses current date: YYYY-MM-DD-<name>
+- If archive target exists, fail that change but continue with others