@aurorajs.dev/catalyst-cli 1.0.2 → 2.0.0

package/dist/templates/monorepo/.claude/skills/harness-rules-guard/references/enforcement.md

@@ -3,7 +3,8 @@
 How Harness Rules are put in front of the agent and the developer. Unlike
 Business Rules (framed as post-implementation **memory**), HR are **constraints**
 activated at the moment they matter. For the rule-file format, see `format.md`.
-For the catalog conventions and rationale, see `docs/harness-rules/README.md`.
+For the orientation map (what the catalog is, file table, commands), see
+`docs/harness-rules/README.md`.
 
 ---
 
@@ -16,7 +17,7 @@ nature of HR (constraints, not crystallized invariants).
               PROMPT-TIME                PROPOSE-TIME              WRITE-TIME
           (UserPromptSubmit)            (/opsx:propose)            (PreToolUse)
                   │                          │                         │
-       inject-rules-context.ts      openspec/config.yaml      architecture-checkpoint.ts
+       inject-prompt-context.ts      openspec/config.yaml      architecture-checkpoint.ts
        (loads HR index, top-N,      (HR guidance folded into  (existing structural gate —
         SEPARATE block, framed       context: + rules —        on block, APPENDS governing
         as CONSTRAINTS)              "Harness rules            HR-IDs to the message)
@@ -29,7 +30,7 @@ nature of HR (constraints, not crystallized invariants).
 
 ### Layer 1 — Prompt-time injection (`UserPromptSubmit`)
 
-`.claude/hooks/inject-rules-context.ts` loads `cliter/harness-rules-index.json`
+`.claude/hooks/inject-prompt-context.ts` loads `cliter/harness-rules-index.json`
 in addition to the BR index, scores active HR rules (primarily by bilingual
 keyword), and injects the most relevant ones as a **SEPARATE labeled block** with
 **CONSTRAINT framing** — distinct from the BR footer that frames rules as
@@ -97,8 +98,8 @@ HR are NOT enforced uniformly. A rule's enforcement level is decided by its
 
 | Level               | Which rules                                                              | How enforced                                                          |
 | ------------------- | ------------------------------------------------------------------------ | --------------------------------------------------------------------- |
-| **Content-blocked** | Rules with a `detect` field. **Today: `HR-ACL-001` only** (`as unknown as`) | The content-guard BLOCKS the write (exit 2). A hard VIOLATE.          |
-| **Advisory**        | The other five: `HR-MODULES-001`, `HR-BRIDGES-001`, `HR-PORTS-001`, `HR-CODEGEN-001`, `HR-MODES-001` | Surfaced via the skill, prompt injection, propose detection, and checkpoint messaging. The agent applies judgment. **Never auto-blocked.** |
+| **Content-blocked** | Every rule that declares a `detect` field. The authority is the index — `byId[<id>].detect` in `cliter/harness-rules-index.json` — not a list in prose; today `HR-ACL-001` (`as unknown as`) and `HR-DOCS-001` (rule-format content in the `docs/` orientation maps) | The content-guard BLOCKS the write (exit 2). A hard VIOLATE.          |
+| **Advisory**        | Every rule WITHOUT a `detect` field (`HR-MODULES-001`, `HR-BRIDGES-001`, `HR-PORTS-001`, `HR-CODEGEN-001`, `HR-MODES-001`, …) | Surfaced via the skill, prompt injection, propose detection, and checkpoint messaging. The agent applies judgment. **Never auto-blocked.** |
 
 ### Why the semantic rules are advisory, not blocked by path
 
@@ -165,6 +166,6 @@ create new) and run `pnpm hr:generate && pnpm hr:validate`.
   degrade to pure BR behavior: prompt injection emits only the BR block, the
   checkpoint emits only its structural message, the content-guard finds no
   patterns and blocks nothing.
-- Extending the shared hooks (`inject-rules-context.ts`,
+- Extending the shared hooks (`inject-prompt-context.ts`,
   `architecture-checkpoint.ts`) preserves 100% of the observable BR behavior —
   this is a verified invariant of the change.

package/dist/templates/monorepo/.claude/skills/harness-rules-guard/references/format.md

@@ -1,8 +1,9 @@
 # Format reference — Harness Rules Catalog
 
-Exact, mandatory format of an HR rule file. For rationale, scope semantics, and
-the HR-vs-BR differences, see `docs/harness-rules/README.md` (the canonical
-convention doc). For how activation works, see `enforcement.md`.
+Exact, mandatory format of an HR rule file — frontmatter, scope semantics,
+language mix, state/severity, the canonical section template, and how to
+create/derogate/modify a rule. For the orientation map, see
+`docs/harness-rules/README.md`. For how activation works, see `enforcement.md`.
 
 ---
 
@@ -70,13 +71,47 @@ detect:
 - `message` es el texto exacto que el content-guard emite cuando bloquea — debe
   citar el id y explicar la alternativa correcta.
 - Se propaga al índice como `byId[id].detect` vía `pnpm hr:generate`.
-- **Hoy la única regla con `detect` es `HR-ACL-001`** (`as unknown as`). Las
-  otras cinco lo omiten y son advisory.
+- **Qué reglas son content-blocked se lee del índice** (`byId[<id>].detect` en
+  `cliter/harness-rules-index.json`), nunca de una lista escrita en prosa: hoy lo
+  declaran `HR-ACL-001` (`as unknown as`) y `HR-DOCS-001` (plantilla de regla en
+  los README de orientación de `docs/`). Toda regla sin `detect` es advisory.
 - Añadir una regla mecánica nueva = añadir `detect` a su `.md` (catalog-driven);
   el content-guard NO hardcodea reglas.
 
 ---
 
+## Scope (semántica)
+
+`scope` gobierna dónde aplica la regla y cuándo aparece en el índice:
+
+| `scope`    | `bounded_contexts`        | Aparece en el índice cuando…                                 |
+| ---------- | ------------------------- | -------------------------------------------------------------- |
+| `project`  | `[]` (vacío, obligatorio) | Siempre. Regla core/global, sin anclaje a BC.                  |
+| `bc-bound` | exactamente un BC          | El BC declarado está instalado (`cliter/<bc>/` existe).        |
+| `multi-bc` | dos o más BCs              | **TODOS** los BCs declarados están instalados.                 |
+
+La regla **multi-bc "ALL declared BCs installed"** es deliberada: si la integración no es
+físicamente posible por presencia parcial de BCs, citar la regla sería ruido y produciría reglas
+zombi por diseño.
+
+---
+
+## Mezcla deliberada de idiomas
+
+Idéntica a la de BR. Es una decisión de diseño **explícita**:
+
+| Elemento                                | Idioma                          |
+| --------------------------------------- | -------------------------------- |
+| Prosa (enunciados, glosarios, matrices) | **Español**                     |
+| Identificadores (IDs, frontmatter keys) | **Inglés**                      |
+| Rutas, paths, JSON keys, citaciones     | **Inglés**                      |
+| Keywords                                | **Bilingüe** (español + inglés) |
+
+> **CRÍTICO — DO NOT HARMONIZE**: ningún agente, script ni dev debe "armonizar" la mezcla a un solo
+> idioma. Si ves "español + inglés" en una regla, es a propósito.
+
+---
+
 ## Encabezado humano
 
 Bajo el frontmatter, antes de las reglas:
@@ -183,8 +218,9 @@ Cada regla sigue este orden:
 | `scope`                 | No existe.                         | Obligatorio (`project \| bc-bound \| multi-bc`).    |
 | `bounded_contexts`      | ≥1 obligatorio.                    | `minItems: 0` (vacío para `project`).               |
 | `aggregates`            | Obligatorio.                       | **Opcional.**                                       |
-| `detect`                | No existe.                         | **Opcional** (content-blocked rules; hoy HR-ACL-001). |
+| `detect`                | No existe.                         | **Opcional**; declararlo hace la regla content-blocked (quiénes lo declaran, en el índice). |
 | `### Implementa`        | Obligatorio.                       | **Opcional.**                                       |
+| `### Tests`             | Opcional.                          | Opcional (igual).                                   |
 | `### Anchor patterns`   | No existe.                         | **Añadido** (globs/heurísticas para el guard).      |
 | `### Casos exhaustivos` | Rangos input/output → resultado.   | **Decision matrix**: situación → ¿permitido? → acción. |
 | `### Diagrama de cascada` | Disponible.                      | No aplica.                                          |
@@ -216,6 +252,104 @@ propose: solo un VIOLATE de una regla `blocking` detiene `/opsx:propose`.
 
 ---
 
+## Origen — procedencia del enunciado
+
+La tercera fila de la tabla de metadata NO es decorativa: `Origen` **debe citar
+una fuente verificada** de la que sale el enunciado. Una HR se escribe cuando la
+convención **ya existe y está validada en el código**; las reglas no se inventan
+por adelantado.
+
+| Fuente admisible                             | Ejemplo                                                            |
+| -------------------------------------------- | ------------------------------------------------------------------ |
+| Memo de auto-memoria (`feedback_*.md`)       | `feedback_shadow_module_antipattern.md` (para `HR-MODULES-001`)    |
+| Spec OpenSpec existente                      | `openspec/specs/cross-bc-ports/spec.md` (para `HR-BRIDGES-001`)    |
+| Decisión arquitectónica ya registrada        | change `atomic-update-payload-diff`, design D2/D7 (para `HR-PERSISTENCE-001`) |
+
+Si no puedes citar ninguna, la convención aún no está validada y no hay regla
+que escribir todavía.
+
+---
+
+## Cómo crear, derogar y modificar reglas
+
+A diferencia de BR, **HR no tiene `promote` ni `document`**: no se cristalizan por cambio archivado
+ni se bootstrappean desde el código de un agregado. Una HR es una **restricción arquitectónica** y su
+catálogo se opera a mano, por decisión deliberada. Hay tres rutas de interacción con el catálogo:
+
+| Ruta                               | Cuándo aplica                                                                                  | Qué haces                                                                          |
+| ----------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ |
+| **Consultar antes/durante codear** | Vas a tocar un path que gobierna una HR activa, o un write fue bloqueado citando un `HR-*` id  | Busca en `harness-rules-index.json` (`byPath` / `byKeyword` / `byId`), lee, COMPLY |
+| **Declarar en `/opsx:propose`**    | El cambio toca paths gobernados; registras `## Harness rules applicable` en `proposal.md`      | Por cada regla que gobierna: **COMPLY** / **VIOLATE** / **DEROGATE**               |
+| **Editar el catálogo**             | Una convención cambió de verdad y la regla debe retirarse o reemplazarse                       | Derogar + crear nueva con ID nuevo; `pnpm hr:generate && pnpm hr:validate`         |
+
+> **Crear, editar o borrar una HR es siempre la tercera ruta (edición directa).** No busques un
+> `/harness-rules:promote` ni un `/harness-rules:document`: no existen por diseño. Como crear o retirar
+> una HR cambia una convención del proyecto, **envuélvelo idealmente en su propio cambio OpenSpec**.
+
+### Crear una regla nueva
+
+Editar a mano el `.md` del topic correspondiente:
+
+1. Elige el archivo por **topic**, no por agregado: `cliter/harness-rules/<topic>.md` (core) o
+   `cliter/<bc>/harness-rules/<topic>.md` (bc-bound / multi-bc).
+2. Asigna un ID nuevo `HR-<TOPIC>-<NNN>` (secuencial dentro del prefijo de topic; no reusar
+   derogados). Recuerda el **EM-DASH** `—` (U+2014) en el heading: `## HR-... — <título>`.
+3. Completa las secciones obligatorias: tabla de metadata (Estado/Severidad/Origen), `### Enunciado`,
+   `### Casos exhaustivos` (decision matrix, **mínimo 2 casos con al menos uno negativo**),
+   `### Anchor patterns`. `### Implementa` y `### Tests` son opcionales.
+4. **Si la regla es mecánicamente detectable por contenido**, añade el bloque `detect: { pattern,
+   message }` al frontmatter para hacerla _content-blocked_ (un content-guard `PreToolUse` bloquea
+   writes que casen el patrón; qué reglas lo declaran hoy se consulta en el índice,
+   `byId[<id>].detect`). Si no, omítelo: la regla es _advisory_ y
+   su enforcement es el criterio del agente + la skill + la inyección en prompt/propose.
+5. `pnpm hr:generate && pnpm hr:validate` (o lo hace la pre-commit hook al commitear).
+
+### Derogar una regla (= "borrar")
+
+Las reglas **no se borran ni se editan en su semántica**. Para retirar o reemplazar una:
+
+1. Localízala: `pnpm hr:check HR-MODULES-001`.
+2. En su `.md`, cambia la fila `Estado` de la tabla de metadata a `derogated` y anota en `Origen` la
+   regla sustituta.
+3. Añade una sección `### Derogación` al final del cuerpo (fecha + razón en una frase).
+4. Si hay sustituta, créala con un **ID nuevo** (no reuses el derogado) y enlázalas en
+   `### Reglas relacionadas`.
+5. `pnpm hr:generate && pnpm hr:validate`.
+
+> Derogar una HR es **raro** y es en sí una decisión arquitectónica — no un efecto colateral de un
+> proposal ordinario. La regla derogada permanece visible para que las citas `HR-*` históricas en
+> código y PRs sigan siendo unívocas.
+
+### Modificar una regla (= derogar + crear)
+
+Cambiar la semántica equivale a derogar la antigua y crear una nueva con ID nuevo. Sigue "Derogar" +
+"Crear".
+
+**Edits permitidos en sitio sin derogar** (no son cambios semánticos):
+
+- Corregir typos, gramática, formato; reformular sin alterar significado.
+- Arreglar paths rotos en `### Implementa` / `### Tests`.
+- Refrescar `last_updated`.
+
+**Cambios que exigen derogación**: cambiar el resultado de un caso ya enumerado, el significado del
+`### Enunciado`, o la severidad (`blocking` ↔ `informational`).
+
+### COMPLY / VIOLATE / DEROGATE (vocabulario de propose, NO `mantiene`/`deroga`/`extiende`)
+
+En la sección `## Harness rules applicable` de un `proposal.md`, cada regla que gobierna un path
+tocado se resuelve con exactamente UNA de:
+
+- **COMPLY** — el enfoque honra la regla. Es el default y el resultado deseado.
+- **VIOLATE** — el enfoque la rompe. Para una regla `blocking` esto **detiene** `/opsx:propose` y
+  exige decisión del usuario; para `informational` se reporta sin detener.
+- **DEROGATE** — decisión deliberada de retirar/reemplazar la regla (su propio cambio arquitectónico).
+
+> **No hay subsección "Nuevas" en un proposal de HR.** Un proposal **registra compliance con el
+> catálogo EXISTENTE**; no declara HR a crear después (eso es vocabulario de BR). Si ninguna regla
+> activa gobierna los paths tocados, escribe `None`.
+
+---
+
 ## Errores comunes y cómo evitarlos
 
 | Error                                                   | Síntoma                                          | Solución                                                  |

package/dist/templates/monorepo/.claude/skills/judgment-day/SKILL.md

@@ -1,10 +1,18 @@
 ---
 name: judgment-day
-description: "Trigger: judgment day, dual review, adversarial review, juzgar. Run blind dual review, fix confirmed issues, then re-judge."
+description: "Trigger: judgment day, dual review, adversarial review, juzgar. Run blind judges, verify every severe finding against the code, fix, then re-judge the fixed hunks."
 license: Apache-2.0
 metadata:
   author: gentleman-programming
-  version: "1.4"
+  version: "1.5"
+  triggers:
+    - judgment day
+    - dual review
+    - adversarial review
+    - juzgar
+    - que lo juzguen
+    - revisión adversarial
+    - doble revisión
 ---
 
 ## Activation Contract
@@ -14,11 +22,15 @@ Load this skill only when the user explicitly asks for Judgment Day, dual/advers
 ## Hard Rules
 
 - Resolve project skills before launching agents: read skill registry, match skill paths by target files/task, and inject the same `Skills to load before work` block into both judge prompts and fix prompts.
-- Launch **two blind judges in parallel** with identical target and criteria; never review the code yourself.
-- Wait for both judges before synthesis; never accept a partial verdict.
+- Launch blind judges in parallel with identical target and criteria; never review the code yourself.
+- Judge count: two blind judges for a Complex change; ONE for a Medium change, unless the target touches an authorization boundary (guards, `@Auth`, `@TenantConstraint`/`@TenantPolicy`, `dTenants`/`dPermissions`, provisioning guards) or a data boundary (migrations, pivot semantics, cross-BC writes) — then two.
+- Wait for all launched judges before synthesis; never accept a partial verdict.
 - Classify warnings as `WARNING (real)` only if normal intended use can trigger them; otherwise downgrade to INFO as `WARNING (theoretical)`.
-- Ask before fixing Round 1 confirmed issues.
-- After any fix agent runs, immediately re-launch both judges in parallel before commit/push/done/session summary.
+- Every CRITICAL/BLOCKER and every `WARNING (real)` is VERIFIED BY THE ORCHESTRATOR against the code before any fix, whether one judge or two reported it. Agreement between judges is neither required nor sufficient. A finding whose `evidence_class` is `static-analysis` is measured (run the test, the lint, or read the exact path) before acting.
+- Verification outcomes: `verified` (fix it), `refuted` (record why, INFO), `unverifiable` (report as suspect; never auto-fix).
+- Ask before fixing Round 1 verified issues.
+- After any fix agent runs, immediately re-judge before commit/push/done/session summary: ONE judge scoped to the changed hunks plus the frozen ledger; relaunch two only when the fix touched an authorization or data boundary — the same two triggers as the round-1 judge-count rule.
+- Judges receive the task's acceptance criteria (or the change's delta-spec requirements) as review criteria. Naming/conventions are NOT a judge criterion (lint owns them).
 - Terminal states are only `JUDGMENT: APPROVED` or `JUDGMENT: ESCALATED`.
 - After 2 fix iterations with remaining issues, ask the user whether to continue.
 
@@ -27,25 +39,24 @@ Load this skill only when the user explicitly asks for Judgment Day, dual/advers
 | Condition | Action |
 |---|---|
 | Target unclear | Ask for scope; do not launch judges. |
-| No skill registry | Warn, proceed with generic criteria, and record `Skill Resolution: none`. |
-| Both judges find same CRITICAL/real WARNING | Confirmed; ask/fix according to round rules. |
-| One judge finds issue | Suspect; report and triage, do not auto-fix. |
-| Judges contradict | Escalate for manual decision. |
+| No skill registry | Warn, proceed with generic criteria, and report `skill_resolution: none`. |
+| Severe finding reported (by one or two judges) | Orchestrator verifies against the code; verified → ask/fix per round rules; refuted → INFO with reason; unverifiable → suspect, report. |
+| Judges contradict | Verify both claims; if still contradictory, escalate. |
 | Round 2+ has only theoretical warnings/suggestions | Report as INFO; do not re-judge. |
 
 ## Execution Steps
 
 1. Confirm target and optional custom criteria.
 2. Resolve exact skill paths from registry or warn if missing.
-3. Start Judge A and Judge B concurrently via delegation.
-4. Synthesize findings into confirmed, suspect, contradiction, and INFO buckets.
-5. Ask before Round 1 fixes; delegate a separate fix agent for confirmed approved fixes only.
-6. Re-judge in parallel after fixes; repeat until approved, escalated, or user asks to stop.
+3. Launch judges per the judge-count rule (one or two) via delegation.
+4. Synthesize findings and VERIFY every severe finding against the code (verified / refuted / unverifiable); bucket theoretical warnings and suggestions as INFO.
+5. Ask before Round 1 fixes; delegate a separate fix agent for verified, approved fixes only.
+6. Re-judge with a single judge scoped to the changed hunks plus the frozen ledger (two only if the fix touched an authorization or data boundary); repeat until approved, escalated, or user asks to stop.
 7. Before any terminal action, verify every active Judgment Day has a terminal state.
 
 ## Output Contract
 
-Return `## Judgment Day — {target}` with round number, verdict table, confirmed/suspect/contradiction counts, fixes applied, re-judgment result, `Skill Resolution`, and final `JUDGMENT: APPROVED ✅` or `JUDGMENT: ESCALATED ⚠️`.
+Return `## Judgment Day — {target}` with round number, verdict table, verified/refuted/unverifiable counts, fixes applied, re-judgment result, each judge's `skill_resolution:` and `status:` lines, and final `JUDGMENT: APPROVED ✅` or `JUDGMENT: ESCALATED ⚠️`.
 
 ## References
 

package/dist/templates/monorepo/.claude/skills/judgment-day/references/prompts-and-formats.md

@@ -11,63 +11,88 @@ You are an adversarial code reviewer. Your ONLY job is to find problems.
 ## Skills to load before work
 {matching SKILL.md paths, if available}
 
+## Acceptance criteria to judge against
+{task acceptance criteria or delta-spec requirements}
+
 ## Review Criteria
 - Correctness: logical errors and behavior mismatches
 - Edge cases: missing states, inputs, or platform constraints
 - Error handling: propagation, logging, recovery
 - Performance: N+1, wasteful loops, excessive allocations
 - Security: injection, secrets, auth boundaries
-- Naming/conventions: project standards and local patterns
+- TEST QUALITY (mandatory): for each new test, would it FAIL if the logic it covers were broken?
 {custom criteria, if provided}
 
+## Evidence discipline
+- You have no shell. State per finding whether it is `deterministic` (you read the exact code path that proves it) or `static-analysis` (reasoning, not executed).
+- Never cite a code comment as proof of runtime behavior.
+- Do not report what a linter, type checker, or Prettier already catches.
+- Do not report pre-existing issues on untouched lines unless the diff activates them — if it does, say so explicitly.
+
 ## Return Format
-Findings only. No praise.
+Findings only. No praise. ONE format — the JSON object from your agent definition, no markdown fields block alongside it:
 
-Each finding:
-- Severity: CRITICAL | WARNING (real) | WARNING (theoretical) | SUGGESTION
-- File: path/to/file.ext (line N if applicable)
-- Description: what is wrong and why it matters
-- Suggested fix: one-line intent
+- `findings[]`, each with:
+  - `location`: `path:line`
+  - `severity`: `BLOCKER | CRITICAL | WARNING | SUGGESTION`
+  - `claim`: the observable incorrect behavior — for a `WARNING`, the text starts with `(real)` or `(theoretical)`
+  - `evidence_class`: `deterministic | static-analysis`
+  - `causal_disposition`: introduced | behavior-activated | worsened | pre-existing | base-only | unknown
+  - `proof_refs[]`: concrete proof
+- `evidence[]`: what was inspected
 
-WARNING rule: normal intended use can trigger it → `WARNING (real)`; contrived/malicious/impossible path → `WARNING (theoretical)`.
+WARNING rule: normal intended use can trigger it → claim starts with `(real)`; contrived/malicious/impossible path → claim starts with `(theoretical)`.
 
-If clean: `VERDICT: CLEAN — No issues found.`
+If clean: `{"findings":[],"evidence":["what was inspected"]}`.
 
-Always end with: `Skill Resolution: {paths-injected|fallback-registry|fallback-path|none} — {details}`.
+AFTER the JSON, on two separate lines, the two contract lines `skill_resolution:` and `status:` required by `.claude/skills/catalyst-delegation/SKILL.md`.
 ```
 
+## Re-judgment prompt
+
+Variant of the Judge Prompt above, used after a fix round:
+
+- One judge only (two if the fix touched an authorization or data boundary — the same two triggers as the round-1 judge-count rule).
+- Target = the frozen ledger from the prior round PLUS the fix delta only — not the whole file/feature again.
+- May record NEW fix-caused defects (a fix that introduces its own bug), in addition to confirming the ledger's items are resolved.
+
 ## Fix Agent Prompt
 
 ```markdown
-You are a surgical fix agent. Apply ONLY the confirmed issues listed below.
+You are a surgical fix agent. Apply ONLY the verified issues listed below.
 
-## Confirmed Issues to Fix
-{confirmed findings table}
+## Verified Issues to Fix
+{verified findings table}
 
 ## Skills to load before work
 {matching SKILL.md paths, if available}
 
 ## Instructions
-- Fix only confirmed issues.
+- Fix only verified issues.
 - Do not refactor beyond the required fix.
 - Do not change unflagged code.
 - If fixing a repeated pattern in touched files, fix all occurrences of that same pattern.
 - Return changed file, line, and fix summary.
 
-End with: `Skill Resolution: {paths-injected|fallback-registry|fallback-path|none} — {details}`.
+End with the two contract lines:
+
+skill_resolution: <paths-injected | fallback-registry | fallback-footer | none>
+status: <completed | needs-guidance>
 ```
 
 ## Verdict Table
 
 ```markdown
-| Finding | Judge A | Judge B | Severity | Status |
-|---------|---------|---------|----------|--------|
-| Missing null check in auth.go:42 | ✅ | ✅ | CRITICAL | Confirmed |
-| Windows volume root edge case | ❌ | ✅ | WARNING (theoretical) | INFO |
-| Naming mismatch | ✅ | ❌ | SUGGESTION | Suspect |
+| Finding | Reported by | Severity | Verification |
+|---------|-------------|----------|--------------|
+| Missing null check in auth.go:42 | A+B | CRITICAL | verified |
+| (theoretical) Windows volume root edge case | B | WARNING | refuted |
+| Naming mismatch | A | SUGGESTION | unverifiable |
 ```
 
-Approved criteria after Round 1: zero confirmed CRITICALs and zero confirmed real WARNINGs. Theoretical warnings and suggestions may remain.
+`Reported by` records who raised the finding — `A`, `B`, or `A+B` — and is informational only; it never substitutes for orchestrator verification. `Verification` is one of `verified | refuted | unverifiable`, set by the orchestrator against the code, never by judge agreement alone.
+
+Approval criteria after Round 1: zero VERIFIED CRITICAL/BLOCKER and zero VERIFIED real WARNINGs. Theoretical warnings, suggestions, refuted findings, and unverifiable findings do not block approval on their own.
 
 ## Language Snippets
 

package/dist/templates/monorepo/.claude/skills/openspec-apply-change/SKILL.md

@@ -1,17 +1,20 @@
 ---
 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.
+allowed-tools: Bash(openspec:*)
 license: MIT
 compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.4.1"
+  generatedBy: "1.11.0"
 ---
 
 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.
+**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
+
+**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 **Steps**
 
@@ -20,7 +23,7 @@ Implement tasks from an OpenSpec 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
+   - 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., `/opsx:apply <other>`).
 
@@ -44,13 +47,28 @@ Implement tasks from an OpenSpec change.
    - Progress (total, complete, remaining)
    - Task list with status
    - Dynamic instruction based on current state
+   - Optional `context`: current required project instruction input from the selected root
+   - Optional `operationGuidance`: current advisory guidance for apply
 
    **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
+   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue` (if it is not installed, run `openspec status --change "<name>" --json` to see the next artifact and `openspec instructions <artifact-id> --change "<name>" --json` for how to create it)
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
-   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
+   Treat `context` as a required prompt-level input. Read and consider it, and
+   apply relevant project facts, conventions, and constraints while implementing.
+   Treat `operationGuidance` as optional additive advice. Read and consider every
+   entry, and follow entries that are applicable and compatible with the built-in
+   workflow.
+
+   Keep both fields separate from CLI-returned state, missing artifacts, tasks,
+   progress, `contextFiles`, and the built-in `instruction`. They are not
+   evidence of task completion, do not replace the built-in instruction, and do
+   not permit bypassing a blocked state. If context conflicts with the built-in
+   instruction, an explicit user choice, or a CLI-controlled value, report the
+   conflict and preserve the controlling value. If guidance is inapplicable or
+   conflicts with those controlling inputs, do not follow it and explain why.
+   These are prompt-level behavior contracts, not enforceable checks.
 
 4. **Read context files**
 
@@ -59,6 +77,9 @@ Implement tasks from an OpenSpec change.
    - **spec-driven**: proposal, specs, design, tasks
    - Other schemas: follow the contextFiles from CLI output
 
+   Do not copy `context` or `operationGuidance` verbatim into implementation
+   files or planning artifacts unless the user separately asks for that content.
+
 5. **Show current progress**
 
    Display:
@@ -79,6 +100,7 @@ Implement tasks from an OpenSpec change.
    **Pause if:**
    - Task is unclear → ask for clarification
    - Implementation reveals a design issue → suggest updating artifacts
+   - A task needs work beyond what the spec and tasks describe, or you are tempted to drop, narrow, defer, or accept exceptions to specified behavior to make it fit → surface the added scope and ask; do not absorb it silently
    - Error or blocker encountered → report and wait for guidance
    - User interrupts
 
@@ -118,7 +140,7 @@ Working on task 4/7: <task description>
 - [x] Task 2
 ...
 
-All tasks complete! Ready to archive this change.
+All tasks complete! You can archive this change with `/opsx:archive`.
 ```
 
 **Output On Pause (Issue Encountered)**
@@ -149,7 +171,14 @@ What would you like to do?
 - 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
+- When a task needs work beyond what the spec describes, surface the added scope and pause - never silently narrow, defer, or simplify away specified behavior
+- Only mark a task `- [x]` when its specified behavior is fully implemented, not when it is partially done or deferred
 - Use contextFiles from CLI output, don't assume specific file names
+- Do not use context or operation guidance as proof that a task is complete
+- Apply relevant project context; report conflicts with controlling workflow inputs
+- Consider every guidance entry; explain any inapplicable or conflicting advice
+- Do not copy runtime context or operation guidance into implementation files or planning artifacts
+- Preserve CLI-controlled blocked/ready/all-done behavior and completion criteria
 
 **Fluid Workflow Integration**