@pavp/storywright 1.12.2 → 1.13.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pavp/storywright",
-  "version": "1.12.2",
+  "version": "1.13.1",
   "description": "PM Skills pack for Claude Code — turn ambiguous inputs (prompts, screenshots, Figma links) into Jira-ready user stories.",
   "keywords": [
     "claude",

package/skills/_components/acceptance-criteria/SKILL.md

@@ -3,7 +3,7 @@ name: acceptance-criteria
 description: Write acceptance criteria for a user story in Given/When/Then style. Covers happy path, edge cases, and explicit non-goals. Returns only the AC block, never a full story.
 trigger: "internal use by story-* skills"
 intent: Component skill that produces a complete, testable acceptance-criteria block. Pure renderer — does not ask the user questions; relies on context already gathered upstream.
-version: 1.0.0
+version: 1.1.0
 inputs:
   - story-context
   - edge-cases-block
@@ -38,8 +38,8 @@ Invoked by `story-generate` and `story-refine` after the body of the story is dr
    - Then <observable outcome>
    - And <secondary observable outcome>  (optional)
    ```
-6. Number ACs `AC-1`, `AC-2`, …. Stable numbering — never renumber when adding new ones in iterations.
-7. Emit only the AC block. Do NOT include explanations, headers above `## Criterios de Aceptación`, or surrounding prose.
+6. Number ACs `AC-1`, `AC-2`, …. This is the ONLY allowed scheme, in every language — never `CA-01`, `Criterio 1`, `Escenario 1`, or any localized variant. The `AC` label is fixed; translate only the scenario title after it. Stable numbering — never renumber when adding new ones in iterations.
+7. Emit only the AC block. Do NOT include explanations, a section heading above the ACs, or surrounding prose. The host renderer (`[[jira-wiki-formatter]]`) owns the `## Acceptance Criteria` heading.
 
 ## Examples
 

package/skills/_components/jira-wiki-formatter/SKILL.md

@@ -3,7 +3,7 @@ name: jira-wiki-formatter
 description: Render a story into three files: story.standard.md and story.jira-wiki.md (PM-facing, no technical detail) plus story.dev.md (dev-facing, full technical detail).
 trigger: "internal use by story-* skills"
 intent: Component skill that takes a structured story and produces three output files following the templates in story-generate/templates.
-version: 2.0.0
+version: 2.2.0
 inputs:
   - structured-story
 outputs:
@@ -40,6 +40,12 @@ Final step in `story-generate` and `story-refine`. Always last.
 
 ---
 
+**Pre-emit heading guard (apply before writing any section to any file):**
+- `story.standard.md` and `story.dev.md`: title line must use `#`; every section heading must use `##`. If received content uses `###` or `####` for a section, demote it to `##` before emitting.
+- `story.jira-wiki.md`: title line must use `h2.`; every section heading must use `h3.`. If `h1.` or `h2.` appears on any line after the first heading, correct it to `h3.` before emitting.
+
+Apply silently — no log entry needed for heading-level corrections.
+
 1. Render `story.jira-wiki.md` (PM-facing) using Jira's wiki markup:
    - Headings: `h1. `, `h2. `, `h3. `
    - Bold: `*text*`
@@ -108,22 +114,22 @@ h3. Definition of Done
 ### Good — CommonMark
 
 ```
-## Login con Google
+# Login con Google
 
 Permitir a usuarios autenticarse mediante OAuth con Google.
 
-### User Story
+## User Story
 **As a** visitante nuevo
 **I want** iniciar sesión con mi cuenta de Google
 **So that** puedo evitar crear una nueva contraseña.
 
-### Criterios de Aceptación
+## Criterios de Aceptación
 **AC-1: Login exitoso**
 - Given el usuario está en la pantalla de login
 - When toca "Continuar con Google" y autoriza una cuenta válida
 - Then es redirigido al dashboard en <3s
 
-### Definition of Done
+## Definition of Done
 - [ ] Code merged behind feature flag
 - [ ] ACs pass in QA
 ```

package/skills/_components/storywright-base/SKILL.md

@@ -3,7 +3,7 @@ name: storywright-base
 description: Shared base behavior for all storywright top-level skills. Hard rules, canonical output, terminal-only Q, context schema, mechanical deps, V audit, language detect.
 trigger: "internal use by story-* skills"
 intent: Component skill that holds the v2.2 baseline. Top-level skills (story-generate, story-refine, story-split, story-from-figma) compose this and add only their source-specific behavior on top.
-version: 2.3.0
+version: 2.5.0
 inputs:
   - none
 outputs:
@@ -96,6 +96,14 @@ If you are reading this through a top-level skill, treat every rule below as non
 
 12. **Passive-goal downstream prompt (rule G).** If the story's `I want to` verb is observational (`view, see, read, browse, look at, inspect, monitor`) AND the `so that` does not name a follow-up user action — ask once via `AskUserQuestion`: "What does the user do with this?". Strengthen the `so that` accordingly. Skip if `so that` already names a downstream action.
 
+13. **PM section whitelist (rule H).** Only these section names may appear in `story.standard.md` and `story.jira-wiki.md`:
+
+    **ALLOWED:** User Story, Acceptance Criteria, Definition of Done, Contexto, Business Goal, Scope, Out of Scope, Business Rules. (`**Summary:**` is inline text, not a section heading — it is not subject to this list.)
+
+    **BANNED** (move content to `story.dev.md`, never emit in PM files): Edge Cases, Non-Functional Requirements, NFR, Performance, Security, Accessibility, Technical Considerations, Analytics, Risks, Dependencies, Dependencias, Riesgos — and any section whose name does not appear in the ALLOWED list above.
+
+    If you find yourself writing a banned section into a PM file, stop. Move its content to `story.dev.md` instead (use `## Technical Considerations` as the target heading for Accessibility, Performance, and Security content). Do not silently drop it.
+
 ### 4a. Language auto-detect — expanded signals (rule E)
 
 Run cheap detection before asking. Multi-signal weighted decision:
@@ -180,7 +188,7 @@ Mechanical counter. Apply the table — do NOT eyeball:
 - ...
 
 #### Acceptance Criteria
-- **Scenario:** [single-outcome scenario name]
+**AC-1: [single-outcome scenario name]**
 - **Given:** [context — surface nouns here drive dep matrix per rule 10]
 - **and Given:** [context]
 - **When:** [single trigger]
@@ -198,6 +206,10 @@ Mechanical counter. Apply the table — do NOT eyeball:
 
 NOTHING else. No NFR block. No Edge Cases enumeration. No Dependencies prose. No Assumptions block (assumptions get `⚠️ Assumed` inline or are resolved via `AskUserQuestion`). No standalone INVEST section — verdict belongs in the log only.
 
+**Title — no story-number prefix.** The title is the bare story name. NEVER prefix it with a story/sequence number (`Historia 00 —`, `Story 3:`, `HU-01 -`, or any equivalent). Sequence belongs in the ticket ID / filename, not the heading. One title heading, one scheme, every file.
+
+**AC numbering — one scheme only: `AC-N`.** Every acceptance criterion is labelled `**AC-1:**`, `**AC-2:**`, … in ALL output files and ALL languages — never `CA-01`, `Criterio 1`, `Escenario 1`, or any localized variant. The label `AC` is fixed; only the scenario title after it is translated. Numbering is stable: append, never renumber existing ACs across iterations (see `[[acceptance-criteria]]`).
+
 ## Application (step-by-step — every skill follows this skeleton)
 
 0. **Detect companion sources** (image, figma-link, accompanying text). Run conflict detection against the primary input. Run chrome detection using rule 7. Surface conflicts as BLOCKING `AskUserQuestion`.
@@ -222,13 +234,26 @@ NOTHING else. No NFR block. No Edge Cases enumeration. No Dependencies prose. No
 
 8. **Fill the canonical block** (Use Case + AC + Design Ref + INVEST). Preserve original wording where it was already good. NEVER invent NFR/edge-case/deps sections **in the PM story body** — rule 3 still holds for `story.standard.md` / `story.jira-wiki.md`.
 
+   **Summary line (mandatory).** Generate `**Summary:**` immediately after the title — one sentence, value-focused, no heading. This line is MANDATORY in all three output files. Format: `**Summary:** <sentence>` in CommonMark files, `*Summary:* <sentence>` in the Jira wiki file. Never omit it.
+
+   The Summary MUST open with WHAT the deliverable is and WHICH problem it solves, in business language. The rule 3 / rule H ban on technical detail (file paths, imports, component/CLI names) does NOT exempt you from explaining the purpose — "no technical names" means no jargon, NOT "no explanation of what it does." Strip the jargon, keep the purpose.
+
+   **For enabling / infra / platform stories this is mandatory and load-bearing.** When the deliverable is plumbing (publishing packages, provisioning a registry, setting up a pipeline, wiring shared config), describing only the process (publish / setup / install) is INSUFFICIENT — a PM reading it must understand what each artifact is FOR and what breaks downstream without it. State the consumer value, not the mechanics. Example: "publish 2 shared packages to a private registry" → the Summary explains what each package does and what stops working if it is missing, never just the publish/install cycle.
+
+8.5. **PM section self-audit (rule H).** Before calling [[jira-wiki-formatter]], enumerate every section drafted for the PM files. For each section name:
+     - In Rule H ALLOWED list → keep.
+     - In Rule H BANNED list → move its content to `story.dev.md`.
+     - Not in either list → treat as BANNED, move to `story.dev.md`.
+     Log any moves in the Refinement Log: "Moved <Section> to dev (rule H)."
+     Do not proceed to step 8b until the PM draft contains only ALLOWED sections.
+
 8b. **Gather dev-file enrichment** (feeds `story.dev.md` only — see rule 3a). Invoke the enrichment components to populate the technical sections of the dev file:
    - `[[edge-cases]]` → `### Edge Cases` (technical failure axes)
    - `[[risks-and-dependencies]]` → `### Dependencias` + `### Riesgos`
    - `[[analytics-events]]` → `### Analytics / Eventos`
    - `[[definition-of-done]]` → full DoD with CLI commands (PM files get the acceptance-only projection)
    - `[[business-rules]]` → policy invariants (also an *optional* PM section per `[[jira-wiki-formatter]]` when non-empty)
-   None of these may appear in the PM story body except the optional Business Rules section. Skip any component whose output is empty (drop empty sections — rule 3 / jira-wiki-formatter).
+   None of these may appear in the PM story body except the optional Business Rules section (see Rule H for the full PM section whitelist). Skip any component whose output is empty (drop empty sections — rule 3 / jira-wiki-formatter).
 
 9. **Run INVEST** via `[[invest-checklist]]`.
    - `READY` → render.