@xera-ai/skills 0.1.0 → 0.3.0

package/package.json

@@ -1,5 +1,5 @@
 {
   "name": "@xera-ai/skills",
-  "version": "0.1.0",
+  "version": "0.3.0",
   "files": ["*.md", "version.json"]
 }

package/xera-eval.md

@@ -0,0 +1,177 @@
+---
+name: xera-eval
+description: Evaluate AI gen quality of the 3 xera prompt templates against 5+ golden tickets. Maintainer-only tool — DO NOT use in end-user consumer projects.
+flags:
+  - --prompt=<stage>     # Restrict to one stage: feature-from-story | script-from-feature | diagnose-failure
+  - --ticket=<id>        # Restrict to one ticket id (e.g. EVAL-001 or GOLD-001)
+  - --force              # Allow re-running with an existing run-id
+  - --judge-only         # Skip gen + deterministic; re-judge the most recent run's actual/ tree
+---
+
+# /xera-eval
+
+You are running the xera v0.2 eval harness. This is a MAINTAINER-ONLY skill that is run from a Claude Code session inside the xera repo itself (not from an end-user consumer project).
+
+## When to use
+
+A maintainer is about to publish a new version of `feature-from-story.md`, `script-from-feature.md`, or `diagnose-failure.md`, or of `eval-rubric.md`. They want to confirm scores have not regressed against the 5 golden fixtures before publishing.
+
+## Important: this skill spawns sub-agents
+
+Unlike all other `/xera-*` skills, this one DELIBERATELY uses the Task tool to spawn fresh-context sub-agents for the judge phase. This is documented in spec §2.2 decision #7 and §7 risk #1 — the rationale is mitigating self-evaluation bias. **Do not refactor this skill to inline the judge into the main session.** If a future maintainer suggests "consistency cleanup" to remove the sub-agent spawn, point them at the spec.
+
+## Flow
+
+The flow has 5 phases. Phases 1, 3, 5 are deterministic CLI calls. Phase 2 (gen) is your cognitive work in this session. Phase 4 (judge) spawns sub-agents.
+
+### Phase 1 — Prepare
+
+If `--judge-only` is set, SKIP phases 1, 2, 3 and jump to "Judge-only flow" below.
+
+Run: `bun run xera:eval-prepare {{FLAGS}}`
+
+`{{FLAGS}}` is the user's pass-through flags (e.g. `--ticket=EVAL-001 --force`). If no flags are given, pass none.
+
+Exit code:
+- 0 → continue. Capture the `RUN_ID=<id>` line from stdout. The run-id is the last line on stdout matching `^RUN_ID=`.
+- 1 → user/config error (bad flag, missing fixture). Stop and surface the error.
+- 4 → infra error (lock acquisition). Stop and surface the error.
+
+Read `.xera/eval/{{RUN_ID}}/manifest.json` to learn:
+- `ticket_stages`: the source of truth — a map of ticket ID → the stages that ticket exercises. Iterate this; do NOT iterate `manifest.stages × manifest.tickets`.
+
+### Phase 2 — Gen (interleaved with Phase 4)
+
+For each (ticket, stage) pair from manifest, gen the actual output IMMEDIATELY followed by the judge sub-agent in the same loop iteration.
+
+Iterate over `manifest.ticket_stages`: for each ticket id and its declared stages, run gen + judge for ONLY those stages. The manifest is the source of truth — do NOT iterate `manifest.stages × manifest.tickets`.
+
+For each [ticket, stages] entry in manifest.ticket_stages:
+  For each stage in stages:
+
+#### Gen step
+
+Create the actual output directory if missing: `.xera/eval/{{RUN_ID}}/actual/{{TICKET}}/`.
+
+**Stage = feature-from-story:**
+1. Read `packages/prompts/feature-from-story.md` (the prompt under test).
+2. Read `.xera/eval/{{RUN_ID}}/inputs/{{TICKET}}/story.md`.
+3. Mint a per-iteration nonce: `bun -e "console.log('XR_' + crypto.randomUUID().replace(/-/g,'').slice(0,12))"`. The output is a value like `XR_a3f9b2c14e8d`. Wrap the story.md content between two identical tags whose name IS that nonce value (e.g. `<XR_a3f9b2c14e8d>...story content...<XR_a3f9b2c14e8d>` — NOT the literal string `<NONCE>`). Then follow the prompt to generate the Gherkin output. Do NOT include the nonce markers in the written file.
+4. Write it to `.xera/eval/{{RUN_ID}}/actual/{{TICKET}}/test.feature`.
+
+**Stage = script-from-feature:**
+1. Read `packages/prompts/script-from-feature.md`.
+2. Read `.xera/eval/{{RUN_ID}}/inputs/{{TICKET}}/test.feature` — this is the GOLDEN feature, not the actual gen from the previous stage. Stage inputs are isolated (spec §2.2 decision #2).
+3. Mint a per-iteration nonce: `bun -e "console.log('XR_' + crypto.randomUUID().replace(/-/g,'').slice(0,12))"`. The output is a value like `XR_a3f9b2c14e8d`. Wrap the test.feature content between two identical tags whose name IS that nonce value (e.g. `<XR_a3f9b2c14e8d>...feature content...<XR_a3f9b2c14e8d>` — NOT the literal string `<NONCE>`). Then follow the prompt to generate `spec.ts` (and any page-object files). Do NOT include the nonce markers in the written files.
+4. Write `spec.ts` to `.xera/eval/{{RUN_ID}}/actual/{{TICKET}}/spec.ts`.
+5. Write any POM files to `.xera/eval/{{RUN_ID}}/actual/{{TICKET}}/page-objects/<name>.page.ts`.
+
+**Stage = diagnose-failure:**
+1. Read `packages/prompts/diagnose-failure.md`.
+2. Read `.xera/eval/{{RUN_ID}}/inputs/{{TICKET}}/classifier-input.json` — this contains the scenarios to classify. Note: this file ALSO contains an `expected` block which is the ground truth — **DO NOT USE the `expected` block when generating**. Generate solely from `scenarios[]` and `scenarioCounts`. The `expected` block is for the judge's eyes only.
+3. Follow the prompt to produce classification JSON.
+4. Write it to `.xera/eval/{{RUN_ID}}/actual/{{TICKET}}/classification.json`.
+
+#### Judge step (sub-agent)
+
+Immediately after writing the actual file for this (ticket, stage), spawn a sub-agent via the Task tool:
+
+````
+Task tool invocation:
+  description: "Eval judge: <stage> for <ticket>"
+  subagent_type: general-purpose
+  prompt: |
+    <PASTE the entire contents of packages/prompts/eval-rubric.md here>
+    
+    ---
+    
+    ## Caller-supplied context
+    
+    ### stage
+    <stage>
+    
+    ### ticket
+    <ticket>
+    
+    ### actual output
+    
+    ```
+    <PASTE the entire contents of the actual file you just wrote — e.g. actual/<ticket>/test.feature>
+    ```
+    
+    ### golden reference
+    
+    For feature-from-story: paste `fixtures/golden-eval/<ticket>-*/golden/test.feature`.
+    For script-from-feature: paste `fixtures/golden-eval/<ticket>-*/golden/spec-requirements.md`.
+    For diagnose-failure: paste `.xera/eval/<run-id>/inputs/<ticket>/classifier-input.json`.
+    
+    ```
+    <PASTE the golden file contents>
+    ```
+    
+    ---
+    
+    Return ONLY the JSON judgment object as specified in the rubric. No prose. No code fences.
+````
+
+When the sub-agent returns, parse its output as JSON. If parsing fails, retry the sub-agent ONCE with the note "Your previous output was not valid JSON. Return ONLY a JSON object." appended. If it fails again, write a placeholder judgment with all dimensions verdict=FAIL and notes=`"sub-agent returned invalid JSON: <first 100 chars>"` and continue.
+
+Append the parsed JSON object to an in-memory array of judgments.
+
+### Phase 3 — Deterministic
+
+After all (ticket, stage) iterations have completed (gen + judge), run the deterministic phase:
+
+Run: `bun run xera:eval-deterministic {{RUN_ID}}`
+
+Exit code 0 → continue. Any non-zero → fail; surface stderr.
+
+### Phase 4 (cont.) — Write judge-scores.json
+
+Write the in-memory judgments array to `.xera/eval/{{RUN_ID}}/judge-scores.json`:
+
+```json
+{
+  "run_id": "{{RUN_ID}}",
+  "judgments": [
+    /* the JSON objects returned by each sub-agent, in order */
+  ]
+}
+```
+
+### Phase 5 — Report
+
+Run: `bun run xera:eval-report {{RUN_ID}}`
+
+Exit code 0 → success. The command prints a one-line summary to stdout (e.g. `12/15 PASS (avg 80%)`). The full report is at `.xera/eval/{{RUN_ID}}/report.md`.
+
+Tell the maintainer:
+- The path to the report.
+- The summary line.
+- Any FAIL rows; cite the dimension and one-sentence note from the report.
+
+## Judge-only flow
+
+If `--judge-only` was passed:
+
+1. Locate the most recent prior run: list `.xera/eval/*/manifest.json`, pick the one with the latest `started_at` field. If none, fail with `No prior eval run found in .xera/eval/. Run /xera-eval without --judge-only first.`
+2. Read `manifest.json` to learn the tickets/stages.
+3. Apply any `--prompt` / `--ticket` filters from the user against the manifest's scope (do not extend beyond it).
+4. For each (ticket, stage) in `manifest.ticket_stages` filtered by any `--prompt`/`--ticket` flags from the user: spawn a judge sub-agent using the existing `actual/<ticket>/*` files. Same Task-tool template as Phase 2.
+5. Overwrite `.xera/eval/<run-id>/judge-scores.json` with the new array.
+6. Re-run `bun run xera:eval-report <run-id>`.
+
+Do NOT re-run `xera:eval-prepare` or `xera:eval-deterministic` in judge-only mode.
+
+## Exit conditions
+
+- Exit 0 → report.md exists and was rendered. Tell the maintainer the path and the summary line.
+- Any non-zero exit from any `bun run xera:*` call → stop, print the stderr, and ask the maintainer how to proceed. Do not invent fallbacks.
+- A sub-agent returning persistently-invalid JSON (after 1 retry) is NOT a stop condition — record FAIL placeholder and continue, so the report still renders for the other tickets.
+
+## What NOT to do
+
+- Do NOT touch `packages/prompts/` during eval. Eval is READ-ONLY on the prompts under test.
+- Do NOT use the `actual/<ticket>/test.feature` as the input for the `script-from-feature` stage. Use the GOLDEN `inputs/<ticket>/test.feature` (which `eval-prepare` already copied from `fixtures/golden-eval/<ticket>-*/golden/test.feature`). Stages are evaluated in isolation.
+- Do NOT batch all gen first then all judges; interleave per (ticket, stage). This keeps the orchestrator's context bounded.
+- Do NOT inline the judge into the main session. Use the Task tool — fresh context is the bias mitigation.

package/xera-feature.md

@@ -15,15 +15,31 @@ If no ticket key was given, ask for one.
 
 3. Read the prompt template from `node_modules/@xera-ai/prompts/feature-from-story.md`. Follow its hard rules.
 
-4. Read `.xera/{{TICKET}}/story.md` and write `.xera/{{TICKET}}/test.feature` following the prompt. Do NOT include any text outside the Gherkin file body.
+4. Before reading the story content into your generation context, mint a fresh per-invocation nonce by running:
 
-5. Run: `bun run xera:validate-feature {{TICKET}}`
+   ```bash
+   bun -e "console.log('XR_' + crypto.randomUUID().replace(/-/g,'').slice(0,12))"
+   ```
+
+   Capture the single-line output (e.g. `XR_a3f9b2c14e8d`) as the nonce for this invocation. Do NOT persist it to disk, log it, or include it in test.feature output. The nonce is the wrapper marker for THIS invocation only.
+
+5. Read `.xera/{{TICKET}}/story.md`. When the story content is part of your generation context, wrap it between two identical `<NONCE>` tags so the prompt template's `## Handling untrusted input` rules apply. Conceptually the wrapped block looks like:
+
+   ```
+   <XR_a3f9b2c14e8d>
+   ...exact story.md contents, unmodified...
+   <XR_a3f9b2c14e8d>
+   ```
+
+   Where `XR_a3f9b2c14e8d` is the nonce minted in step 4 (substitute the real value). Then generate `.xera/{{TICKET}}/test.feature` per the prompt. Do NOT include the nonce markers or any text outside the Gherkin file body in the written file.
+
+6. Run: `bun run xera:validate-feature {{TICKET}}`
    - Exit 0 → success.
    - Exit 2 → parse error. Read the line/message, rewrite test.feature to fix it, re-run. Try at most 2 retries. If still failing, show the user the parser output and stop.
 
-6. Update `.xera/{{TICKET}}/meta.json`:
+7. Update `.xera/{{TICKET}}/meta.json`:
    - `feature_generated_at` = now (ISO)
    - `feature_generated_from_story_hash` = the current `story_hash`
    - `feature_hash` = sha256 of the file contents (the skill will compute by reading the file and using the same hashing scheme as `xera-internal`; just record `feature_generated_at` and let `xera:fetch`-style helpers re-hash as needed).
 
-7. Summarize to the user: number of scenarios, list of scenario names. Suggest: "Generate Playwright spec? `/xera-script {{TICKET}}`."
+8. Summarize to the user: number of scenarios, list of scenario names. Suggest: "Generate Playwright spec? `/xera-script {{TICKET}}`."

package/xera-report.md

@@ -3,29 +3,128 @@ name: xera-report
 description: Classify the latest run, draft a Jira comment, and post it. Use after `/xera-exec` when QA wants the diagnosis and Jira update.
 ---
 
-The user invoked `/xera-report <TICKET>`. If no key, ask.
+You are running `/xera-report <TICKET>` (or `/xera-report --no-heal <TICKET>` to skip the heal sub-flow described in step 4a; or you were dispatched to this step by `/xera-run`). If no ticket key is provided, ask the user.
 
-1. Verify `.xera/{{TICKET}}/runs/` has at least one run directory. If not: "Run the test first with `/xera-exec {{TICKET}}`." STOP.
+## Important — this skill does AI work
 
-2. Run: `bun run xera:normalize {{TICKET}}`
+Step 4 below is *cognitive work that YOU, the session, must do*. It is not a shell command. Do not skip it. Do not call `bun run xera:report` until **you have personally written the file `.xera/{{TICKET}}/classifier-input.json`** by reasoning over the run artifacts. The CLI helper consumes that JSON; it does not produce it.
+
+## Steps
+
+1. **Verify** `.xera/{{TICKET}}/runs/` has at least one run directory. If not, tell the user: "Run the test first with `/xera-exec {{TICKET}}`." then STOP.
+
+2. **Normalize the trace.** Run: `bun run xera:normalize {{TICKET}}`
    - Exit 0 → continue.
-   - Otherwise show stderr, STOP.
+   - Otherwise show stderr to the user and STOP.
 
-3. Read the latest `.xera/{{TICKET}}/runs/<latest>/normalized.json`. Also read:
+3. **Read** the latest `.xera/{{TICKET}}/runs/<latest>/normalized.json`. Also read every file below before proceeding to step 4:
    - `.xera/{{TICKET}}/test.feature`
    - `.xera/{{TICKET}}/story.md`
    - `.xera/{{TICKET}}/spec.ts`
-   - `.xera/{{TICKET}}/status.json` (may not exist on first run)
+   - `.xera/{{TICKET}}/status.json` (may not exist on the first run — that's fine)
    - `.xera/{{TICKET}}/meta.json`
+   - `node_modules/@xera-ai/prompts/diagnose-failure.md` (the prompt template — read it in full; the rest of step 4 follows ITS rules)
+
+4. **Classify (YOUR job, no CLI shortcut here).** Follow `diagnose-failure.md`'s decision algorithm scenario-by-scenario. For each scenario in `normalized.json`, decide:
+   - `class`: one of `PASS`, `REAL_BUG`, `SELECTOR_DRIFT`, `FLAKY`, `TEST_BUG`
+   - `confidence`: `low`, `medium`, or `high`
+   - `rationale`: 1–3 sentences in English citing concrete evidence (URL, HTTP status, element name, prior run timestamps, hash drift, etc.)
+
+   Then write a JSON file to `.xera/{{TICKET}}/classifier-input.json` with this exact shape:
+
+   ```json
+   {
+     "runId": "<runId from normalized.json>",
+     "scenarios": [
+       {
+         "name": "<scenario name>",
+         "outcome": "PASS" | "FAIL" | "SKIPPED",
+         "class": "PASS" | "REAL_BUG" | "SELECTOR_DRIFT" | "FLAKY" | "TEST_BUG",
+         "confidence": "low" | "medium" | "high",
+         "rationale": "..."
+       }
+     ],
+     "scenarioCounts": { "total": N, "passed": N, "failed": N, "skipped": N }
+   }
+   ```
+
+   **Do not skip this step.** If you find yourself about to call `bun run xera:report` without having written this file, stop and write the file first.
+
+4a. **Heal sub-flow (only if SELECTOR_DRIFT present).** If the user passed `--no-heal` in the invocation, skip this entire sub-flow and proceed directly to step 5.
+
+Otherwise: read `.xera/{{TICKET}}/classifier-input.json` (which you just wrote in step 4) and check whether any scenario has `class: "SELECTOR_DRIFT"`. If none, skip this entire sub-flow and proceed directly to step 5 (Aggregate + draft).
+
+If at least one scenario is SELECTOR_DRIFT, take the FIRST such scenario (by array order — the single-heal guard) and execute Phases A–C below. Subsequent SELECTOR_DRIFT scenarios are NOT auto-healed in the same `/xera-report` invocation; list them in the report output as "additional drifts: re-run /xera-report after applying the first heal."
+
+   **Phase A — Prepare.** Determine the runId from the most recent run directory under `.xera/{{TICKET}}/runs/` (sorted descending — the latest folder name is the runId).
+
+   **Sentinel check (single-heal enforcement):** Check whether `.xera/{{TICKET}}/runs/{{RUN_ID}}/.heal-attempted` exists. If yes, the heal sub-flow has already been attempted for this run; skip the entire heal sub-flow and proceed to step 5. (This prevents re-heal loops if the user accidentally invokes `/xera-report` twice on the same run.) If it does not exist, create it by writing an empty file via `bash -c 'touch .xera/{{TICKET}}/runs/{{RUN_ID}}/.heal-attempted'` BEFORE proceeding to the heal-prepare invocation.
+
+   Then run:
+
+   ```bash
+   bun packages/core/bin/internal.ts heal-prepare {{TICKET}} {{RUN_ID}} "{{SCENARIO_NAME}}"
+   ```
+
+   Substitute the real runId and scenario name. The scenario name may contain spaces; quote it. Exit code 0 on success (a `heal-input.json` is written into the run dir at `.xera/{{TICKET}}/runs/{{RUN_ID}}/heal-input.json`). Exit 1 on prepare failure — surface the stderr message to the user and STOP the heal sub-flow (do NOT block the rest of /xera-report; proceed to step 5 with no heal applied).
+
+   **Phase B — LLM heal proposal.**
+
+   1. Mint a per-invocation nonce by running:
+
+      ```bash
+      bun -e "console.log('XR_' + crypto.randomUUID().replace(/-/g,'').slice(0,12))"
+      ```
+
+      Capture the single-line output (e.g. `XR_a3f9b2c14e8d`) as the nonce for this invocation. Do NOT persist or log it.
+
+   2. Read `node_modules/@xera-ai/prompts/heal-locator.md` (the prompt template). Follow its rules.
+
+   3. Read `.xera/{{TICKET}}/runs/{{RUN_ID}}/heal-input.json` (the prepared payload).
+
+   4. When the heal-input.json's `domSnapshotAtFailure` field content is part of your generation context, wrap it between two identical tags whose name IS the nonce value. Conceptually:
+
+      ```
+      <XR_a3f9b2c14e8d>
+      ...exact domSnapshotAtFailure content...
+      <XR_a3f9b2c14e8d>
+      ```
+
+      Use the real nonce value from step 1, not the literal placeholder. NOT the literal string `<NONCE>`.
+
+   5. Follow `heal-locator.md`'s rules and emit the strict JSON output. Write it to `.xera/{{TICKET}}/runs/{{RUN_ID}}/heal-output.json`. The file must contain ONLY the JSON object — no surrounding prose, no markdown fences.
+
+   **Phase C — Apply + verify.**
+
+   1. Read `.xera/{{TICKET}}/runs/{{RUN_ID}}/heal-output.json`. Parse it.
+
+   2. If the JSON is malformed OR the schema doesn't match (missing required fields, invalid enum values like a `decision` other than `"apply"`/`"refuse"`, invalid `confidence` value, invalid `refusalCategory`), report the parse error to the user as a refusal-equivalent and STOP the heal sub-flow. Proceed to step 5 with no heal applied.
+
+   3. **Low-confidence downgrade:** if `decision === "apply"` AND `confidence === "low"`, treat the output as `decision: "refuse"`, `refusalCategory: "low-confidence"` regardless of what the LLM emitted. Write the downgraded shape back to `heal-output.json` so the audit trail is honest.
+
+   4. If `decision === "refuse"`: report to the user the refusal `refusalCategory` and `reason`. STOP the heal sub-flow.
+
+   5. If `decision === "apply"`:
+
+      - Read `heal-input.json` to get `pomFile` and `pomLineContent`.
+      - Read the current `pomFile` text. If it does NOT contain `pomLineContent` verbatim → STOP with the message: "POM line drifted since heal was proposed; please re-run /xera-report." Do NOT write any changes.
+      - Count the number of `pomLineContent` occurrences in `pomFile`. If MORE THAN ONE → STOP with the message: "POM contains duplicate line matching the heal target; cannot apply ambiguously. Please disambiguate manually and re-run /xera-report." Do NOT write any changes.
+      - Otherwise (exactly one occurrence): replace it with `newPomLine` from heal-output.json. Write the file back.
+      - Tell the user: "Re-running test to verify heal — this typically takes 1-5 minutes..."
+      - Run: `bun run xera:exec {{TICKET}}`. Capture exit code:
+        - **exit 0:** Run `git add {{POM_FILE}}`. Tell user: "Heal verified ✓ — POM change is staged. Review with `git diff --staged` and commit when ready."
+        - **exit 3:** Run `git checkout HEAD -- {{POM_FILE}}` to revert. Read the latest run dir's classifier output (which now reflects the post-heal failure). Tell user: "Heal proposed `{{NEW_LOCATOR}}` but the test still failed. POM reverted. New failure: {{NEW_ERROR_SUMMARY}}. Investigate manually." STOP.
+        - **exit 4 (or any non-0/3 code):** Run `git checkout HEAD -- {{POM_FILE}}` to revert. Tell user: "Heal verification crashed (exit code {{EXIT}}). POM reverted. Investigate manually." STOP.
 
-4. Read `node_modules/@xera-ai/prompts/diagnose-failure.md`. Follow its decision algorithm. Produce `classifier-input.json` matching the exact shape described. Save to `.xera/{{TICKET}}/classifier-input.json`.
+After the heal sub-flow finishes (whether it applied, refused, or errored), continue to step 5 below to aggregate + draft the report. The Jira comment in step 5 reflects the run as it was originally classified — heal results are a separate concern not (in v0.5) folded into the Jira comment.
 
-5. Run: `bun run xera:report {{TICKET}} -- --input=.xera/{{TICKET}}/classifier-input.json`
+5. **Aggregate + draft.** Run: `bun run xera:report {{TICKET}} -- --input=.xera/{{TICKET}}/classifier-input.json`
+   This CLI: aggregates per-scenario classifications into an overall verdict, updates `status.json` with history, and writes `jira-comment.draft.md`. If exit code is non-zero, surface the error to the user; do not proceed to post.
 
-6. Read the drafted Jira comment at `.xera/{{TICKET}}/jira-comment.draft.md`. Show it to the user. Ask: "Post to Jira? (Y/n)"
+6. **Show the draft.** Read `.xera/{{TICKET}}/jira-comment.draft.md`. Display its content to the user verbatim. Ask: "Post to Jira? (Y/n)" (default: Y, unless `meta.json.source === "local"` for SAMPLE tickets — then never post).
 
-7. If yes:
-   - If Atlassian MCP is available, use `addCommentToJiraIssue` with the draft as the body. Capture the comment id.
-   - Else: run `bun run xera:post {{TICKET}}` (will use REST creds from .env).
+7. **Post.** If user says yes (or `xera-run` is in auto mode with `postToJira: true`):
+   - If an Atlassian MCP tool is available in this session (e.g., `mcp__atlassian__addCommentToJiraIssue` or `mcp__plugin_engineering_atlassian__addCommentToJiraIssue`), call it with `{{TICKET}}` and the draft contents. Capture the comment id.
+   - Else run `bun run xera:post {{TICKET}}` (uses REST credentials from `.env`).
 
-8. Summarize result and link to the Jira comment (if MCP returned a URL).
+8. **Summarize** to the user: overall classification, scenario pass/fail counts, the reproduce command (`bunx xera-internal exec {{TICKET}} --replay=<runId>`), and the Jira comment URL if available.

package/xera-script.md

@@ -14,16 +14,33 @@ The user invoked `/xera-script <TICKET>`. If no key, ask.
 
 4. Read `node_modules/@xera-ai/prompts/script-from-feature.md`. Follow its hard rules.
 
-5. Read `.xera/{{TICKET}}/test.feature` and `.xera/{{TICKET}}/story.md`. Generate:
+5. Before reading the test.feature + story.md content into your generation context, mint a fresh per-invocation nonce by running:
+
+   ```bash
+   bun -e "console.log('XR_' + crypto.randomUUID().replace(/-/g,'').slice(0,12))"
+   ```
+
+   Capture the single-line output (e.g. `XR_a3f9b2c14e8d`) as the nonce for this invocation. Do NOT persist it to disk, log it, or include it in spec.ts output.
+
+6. Read `.xera/{{TICKET}}/test.feature` and `.xera/{{TICKET}}/story.md`. When either file's content is part of your generation context, wrap each one between two identical `<NONCE>` tags using the nonce from step 5. Conceptually each wrapped block looks like:
+
+   ```
+   <XR_a3f9b2c14e8d>
+   ...exact file contents, unmodified...
+   <XR_a3f9b2c14e8d>
+   ```
+
+   Then generate:
    - `.xera/{{TICKET}}/spec.ts`
    - `.xera/{{TICKET}}/page-objects/<ClassName>.ts` for each new POM
-   Do not modify anything under `shared/`.
 
-6. Run quality gates:
+   Do not modify anything under `shared/`. Do NOT include the nonce markers or any text outside the file bodies in the written files.
+
+7. Run quality gates:
    - `bun run xera:typecheck {{TICKET}}` — if exit 2, read errors, fix in the generated files, retry up to 2 times.
    - `bun run xera:lint {{TICKET}}` — same retry policy. If a CSS selector is truly necessary, add `// xera-allow-css: <reason>` on the line above it.
 
-7. Update meta.json: `script_generated_at`, `script_generated_from_feature_hash`.
+8. Update meta.json: `script_generated_at`, `script_generated_from_feature_hash`.
 
-8. Summarize: list of files written, count of new POMs, mention any POM that *looked* reusable but didn't quite fit (suggest the user might want `/xera-promote` later).
+9. Summarize: list of files written, count of new POMs, mention any POM that *looked* reusable but didn't quite fit (suggest the user might want `/xera-promote` later).
    Suggest: "Run the test now with `/xera-exec {{TICKET}}`, or do the whole pipeline with `/xera-run {{TICKET}}`."