@codyswann/lisa 2.222.3 → 2.223.1

package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.222.3",
+  "version": "2.223.1",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/rules/eager/verification.md

@@ -15,7 +15,7 @@
 - **After verifying empirically, codify it as a regression test** via the `codify-verification` skill — Playwright for UI, integration test for API/DB/auth, benchmark for performance. Codification is mandatory for every verification type except PR/Documentation/Deploy and Investigate-Only spikes. For **frontend work**, codification is dual-runner: a Playwright spec in the project's Playwright test runner AND a Maestro flow in the Maestro test runner whenever the project supports Maestro (`.maestro/` directory, `maestro:test` script, or Maestro CI workflow) — both encoding the same verified journey, neither a substitute for the other.
 - **The codified proof re-runs in CI.** Codified runtime verification lives where the project's e2e/Playwright tests live (`tests/e2e/**`) and runs as a required CI check for types with verification enforced — so the proof re-runs on every PR, not once by hand.
 - **Commit the evidence.** Write a durable artifact to `evidence/<ticket>/` — the acceptance criteria with per-criterion pass/fail + note, the observed state, screenshots/recording, and a `verdict.json`. The transient `.lisa/verification-status.json` is the session gate; `evidence/<ticket>/` is the committed proof.
-- **Evidence markers are typed artifacts, not assertion labels.** A Validation Journey marker is `[EVIDENCE: <artifact-type>: <name>]` where the type (screenshot, recording, http-transcript, cli-output, log-snippet, db-query-output, perf-trace, test-run-log, deploy-log, state-dump) says HOW the proof is captured and the name says WHAT it proves. `[EVIDENCE: works-gracefully]` is a claim, not evidence — write `[EVIDENCE: screenshot: load-failure-error-state]`. Completion requires a captured artifact **of the declared type** per marker.
+- **Evidence markers are typed artifacts, not assertion labels.** A Validation Journey marker is `[EVIDENCE: <artifact-type>: <name>]` where the type (screenshot, recording, http-transcript, cli-output, log-snippet, db-query-output, perf-trace, test-run-log, deploy-log, state-dump) says HOW the proof is captured and the name says WHAT it proves. `[EVIDENCE: works-gracefully]` is a claim, not evidence — write `[EVIDENCE: screenshot: load-failure-error-state]`. Completion requires a captured artifact **of the declared type** per marker. To cite another work item's artifact without claiming it, use `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]`. A reference never enters or satisfies the local S14 manifest; malformed references fail S14, and agents must not quote sibling `[EVIDENCE: ...]` markers directly.
 - **Per-change verification is mandatory.** Every `feat`/`fix` adds or extends a verification (e2e) spec mapped to its acceptance criteria. The only exception is a genuinely non-behavioral change explicitly marked with the **logged** `verification-exempt` label — never a silent skip.
 - **Drive the playthrough with `/lisa:product-walkthrough`** (it walks the live product through a real browser); each project type plugs in its own drive mechanism (e.g. a Phaser game is driven through Playwright + an in-game verification test bridge that seeds RNG, reads state, injects input, and steps frames).
 - **Every PR must include reviewer replay steps** — the exact human steps to use the software and confirm the change works. Not test commands. If a reviewer can't reproduce from the PR description alone, the PR is incomplete.

package/plugins/src/base/rules/reference/verification.md

@@ -149,6 +149,18 @@ Do not invent types inline; if none fits, propose extending this table. The lega
 
 The manifest is the single source of truth for "what evidence is required": authored once in the Validation Journey, enforced at write time, replayed during `tracker-journey` (which captures each artifact **in its declared type**), and checked again before the ticket closes. There is no second list to keep in sync.
 
+### Cross-work-item evidence references are non-claiming
+
+When prose needs to point at evidence declared by another work item, use the dedicated reference form:
+
+```text
+[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]
+```
+
+For example, `[EVIDENCE-REF: CodySwannGT/lisa#1548 | test-run-log: plugin-parity]` or `[EVIDENCE-REF: ENG-123 | screenshot: empty-state]`. The work-item reference must be a native, unambiguous tracker reference; the artifact type and name use the same taxonomy and kebab-case grammar as a manifest marker.
+
+`EVIDENCE-REF` is a pointer only. It never adds an artifact to the current work item's manifest, never satisfies S14, never participates in marker-name uniqueness or duplicate checks, and is never captured or checked by journey, evidence-posting, or completion flows. Only the exact claiming prefix `[EVIDENCE: ...]` declares an obligation on the current work item (with the legacy `[SCREENSHOT: name]` form still treated as a local screenshot obligation). A runtime-changing leaf whose journey contains references but no local claiming marker still fails S14. Writers must use `EVIDENCE-REF` rather than quoting a sibling's `[EVIDENCE: ...]` marker, because quoted or code-formatted claiming markers still belong to the current work item.
+
 ---
 
 ## Local vs Remote Verification

package/plugins/src/base/skills/lisa-github-add-journey/SKILL.md

@@ -30,7 +30,7 @@ Extract: title, body, type (from `type:` label), components (from `component:` l
 
 ### Step 2: Check for Existing Journey
 
-Parse the body for an existing `## Validation Journey` heading. If present and the section contains at least one `[EVIDENCE: <name>]` marker, the issue already has a journey — report this to the user and stop.
+Parse the body for an existing `## Validation Journey` heading. It counts as complete only when the section contains at least one local typed `[EVIDENCE: <artifact-type>: <name>]` marker. An `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]` is a non-claiming pointer and does not count; if references are present without a local claiming marker, continue drafting the missing local journey evidence instead of stopping.
 
 ### Step 3: Analyze the Change Type
 
@@ -82,30 +82,32 @@ Compose the journey with typed `[EVIDENCE: <artifact-type>: <name>]` markers at
 1. **2–5 evidence markers** — Focus on proving the change works and handles errors.
 2. **Concrete, runnable steps** — `Run \`curl -s localhost:3000/health | jq .status\`` not "Check the endpoint".
 3. **Include environment setup** — Database connection, running services, env vars.
-4. **Markers are typed artifacts, not assertion labels** — `[EVIDENCE: <artifact-type>: <kebab-name>]`. `[EVIDENCE: load-failure-handled-gracefully]` names a claim with nothing to capture; write `[EVIDENCE: screenshot: load-failure-error-state]` or `[EVIDENCE: perf-trace: pipeline-load-tti]`. Names are kebab-case and unique within the ticket.
+4. **Markers are typed artifacts, not assertion labels** — `[EVIDENCE: <artifact-type>: <kebab-case-name>]`. `[EVIDENCE: load-failure-handled-gracefully]` names a claim with nothing to capture; write `[EVIDENCE: screenshot: load-failure-error-state]` or `[EVIDENCE: perf-trace: pipeline-load-tti]`. Names are kebab-case and unique within the ticket.
 5. **Assertions are measurable** — `Returns 200 with {status: ok}` not "API works correctly".
 6. **Cover happy path AND error path** — At minimum, one success and one failure marker.
 7. **On a leaf work unit, the markers are binding** — For a Bug / Task / Sub-task / Improvement, every typed `[EVIDENCE: <artifact-type>: <name>]` here is the issue's evidence manifest: validation gate S14 requires at least one, and the issue cannot be closed until each named artifact is captured **in its declared type** and attached (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Name only evidence you intend to capture — and name all of it.
+8. **Reference sibling evidence without claiming it** — Use only `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]` when prose points to an artifact declared by another issue. Never paste, quote, or code-format the sibling's `[EVIDENCE: ...]` marker: that exact prefix creates a local obligation. `EVIDENCE-REF` never satisfies this issue's S14 minimum, uniqueness check, capture list, or completion gate; a runtime-changing leaf still needs at least one local `[EVIDENCE: ...]` marker.
 
 ### Step 6: Present to User for Approval
 
-Display the drafted Validation Journey and ask for confirmation before appending it to the issue body. (If invoked from a parent skill running unattended — e.g., `lisa-github-write-issue` Phase 6 step 5 — proceed without the prompt.)
+Display the drafted Validation Journey change and ask for confirmation before updating the issue body. (If invoked from a parent skill running unattended — e.g., `lisa-github-write-issue` Phase 6 step 5 — proceed without the prompt.)
 
-### Step 7: Append to Issue Body
+### Step 7: Merge into Issue Body
 
 After approval:
 
 ```bash
 current_body=$(gh issue view <number> --repo <org>/<repo> --json body --jq '.body')
-# Compose new body: existing + "\n\n## Validation Journey\n..." (or replace if present)
+# If no journey exists, append one section. If one exists without a local marker,
+# merge the missing local steps/markers inside that section.
 gh issue edit <number> --repo <org>/<repo> --body-file /tmp/updated-body.md
 ```
 
-Preserve every other section verbatim — never re-render the body from parsed fields, since the issue may carry `extra_sections` we don't recognize.
+When repairing a reference-only journey, preserve all of its existing prose and `EVIDENCE-REF` pointers and append only the missing local steps/markers inside the existing section. Never create a second `## Validation Journey` heading. Preserve every other section verbatim — never re-render the body from parsed fields, since the issue may carry `extra_sections` we don't recognize.
 
 ### Step 8: Verify
 
-Re-read the issue and confirm the `## Validation Journey` section is present and includes at least one `[EVIDENCE: <name>]` marker.
+Re-read the issue and confirm the `## Validation Journey` section is present and includes at least one local `[EVIDENCE: <artifact-type>: <name>]` marker. An `EVIDENCE-REF` alone does not count.
 
 ## When to Use This Skill
 

package/plugins/src/base/skills/lisa-github-create/SKILL.md

@@ -36,6 +36,8 @@ Analyze the provided file(s) and plan a GitHub Issue hierarchy. **This skill pla
 
 Issues that change runtime behavior should include a `## Validation Journey` section. This section is consumed by `lisa-github-journey` to automate verification. Use `lisa-github-add-journey` to draft + append the section after creation.
 
+When the issue needs to point at evidence owned by another work item, pass the exact non-claiming form `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]` to the writer. Never quote the sibling's `[EVIDENCE: ...]` marker. A reference is informational only and does not replace the runtime-changing leaf's own S14 evidence marker.
+
 ## Source Artifacts
 
 If `$ARGUMENTS` references any external artifact — PRD, design doc, Figma URL, Lovable prototype, Loom walkthrough, screenshot, example payload — those references MUST be preserved as `## Links` and `## Source Artifacts` sections on the created issues. Silent artifact loss is the single most common quality failure in this pipeline.

package/plugins/src/base/skills/lisa-github-journey/SKILL.md

@@ -64,6 +64,8 @@ At each typed `[EVIDENCE: <artifact-type>: <name>]` marker, capture an artifact
 
 A prose claim ("the error state rendered gracefully") satisfies no marker. Legacy untyped markers: infer the type from the step's action, capture accordingly, and note the inference. Write each artifact to a numbered file:
 
+Treat only exact `[EVIDENCE: ...]` markers (plus the legacy local `[SCREENSHOT: ...]` form) as capture instructions. `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]` points to another work item's artifact: preserve it as explanatory text, but do not capture it, assign it a sequence number, include it in duplicate-name checks, or count it as a local manifest entry. If a runtime-changing leaf has references but no local claiming marker, stop because S14 is unsatisfied.
+
 #### Evidence Naming Convention
 
 `{NN}-{evidence-name}.txt` (or `.json` for structured data):

package/plugins/src/base/skills/lisa-github-validate-issue/SKILL.md

@@ -207,7 +207,9 @@ Each marker must satisfy ALL of:
 
 **A marker names an artifact, not an assertion.** An untyped marker (`[EVIDENCE: load-failure-handled-gracefully]`) is an assertion label with nothing to capture and must FAIL, with a remediation that shows the typed transformation (e.g. → `[EVIDENCE: screenshot: load-failure-error-state]`, `[EVIDENCE: perf-trace: pipeline-load-tti]`).
 
-FAIL when the Validation Journey is present but declares zero markers, when any marker is untyped or uses a type outside the taxonomy, or when any name is empty, duplicated, or not kebab-case. A behavior-changing work unit SHOULD declare both a success marker and an error/edge marker; a journey with only one marker passes but the remediation should recommend adding the error/edge case.
+FAIL when the Validation Journey is present but declares zero binding `[EVIDENCE: ...]` markers, when any binding marker is untyped or uses a type outside the taxonomy, or when any binding name is empty, duplicated, or not kebab-case. A behavior-changing work unit SHOULD declare both a success marker and an error/edge marker; a journey with only one binding marker passes but the remediation should recommend adding the error/edge case.
+
+Parse claiming markers by the exact `[EVIDENCE:` prefix. A cross-work-item pointer in the exact form `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]` is non-claiming: exclude it from the manifest, S14's minimum-marker count, local marker type/name validation, and duplicate-name checks. Independently validate every `EVIDENCE-REF`: the native work-item reference must be non-empty and unambiguous, the artifact type must use the fixed taxonomy, and the name must be non-empty kebab-case. A malformed reference FAILs S14 as an invalid pointer but never becomes a local evidence obligation. A valid reference may point to a sibling's artifact, but it never satisfies S14 for this issue. Therefore a runtime-changing leaf whose journey contains only `EVIDENCE-REF` entries FAILs S14. Quoting or code-formatting another issue's `[EVIDENCE: ...]` marker does not make it a reference; writers must convert it to `EVIDENCE-REF`.
 
 This gate depends on S11. It is `N/A` for containers — an **Epic**, or any item with open child work (coordination containers, not work units) — and for leaf units with `runtime_behavior_change = false` (doc-only / config-only / type-only). If S11 fails because the Validation Journey is absent, S14 also FAILs (there is no manifest to bind) with remediation pointing back to `lisa-github-add-journey`.
 

package/plugins/src/base/skills/lisa-github-write-issue/SKILL.md

@@ -126,7 +126,9 @@ Scenario: <name>
 
 ## Validation Journey
 [Delegate to /github-add-journey if the issue changes runtime behavior.
- Skip only for doc-only, config-only, or type-only issues.]
+ Skip only for doc-only, config-only, or type-only issues. Cross-work-item
+ evidence pointers use `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]`;
+ they never replace this issue's local S14 marker.]
 ```
 
 Rules:

package/plugins/src/base/skills/lisa-jira-add-journey/SKILL.md

@@ -38,7 +38,7 @@ Run the parser to see if a Validation Journey already exists:
 python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID> 2>&1
 ```
 
-If the parser succeeds and returns steps, the ticket already has a journey. Report this to the user and stop.
+If the parser succeeds and returns steps, inspect the journey source for at least one local typed `[EVIDENCE: <artifact-type>: <name>]` marker. Stop only when that local marker exists. An `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]` is a non-claiming pointer and does not count; if the journey has references but no local claiming marker, continue drafting the missing local journey evidence.
 
 ### Step 3: Analyze the Change Type
 
@@ -92,18 +92,19 @@ h3. Assertions
 1. **2-5 evidence markers** — Focus on proving the change works and handles errors
 2. **Concrete, runnable steps** — "Run `curl -s localhost:3000/health | jq .status`" not "Check the endpoint"
 3. **Include environment setup** — Database connection, running services, env vars
-4. **Markers are typed artifacts, not assertion labels** — `[EVIDENCE: <artifact-type>: <kebab-name>]`. `[EVIDENCE: load-failure-handled-gracefully]` names a claim with nothing to capture; write `[EVIDENCE: screenshot: load-failure-error-state]` or `[EVIDENCE: perf-trace: pipeline-load-tti]`. Names are kebab-case and unique within the ticket.
+4. **Markers are typed artifacts, not assertion labels** — `[EVIDENCE: <artifact-type>: <kebab-case-name>]`. `[EVIDENCE: load-failure-handled-gracefully]` names a claim with nothing to capture; write `[EVIDENCE: screenshot: load-failure-error-state]` or `[EVIDENCE: perf-trace: pipeline-load-tti]`. Names are kebab-case and unique within the ticket.
 5. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly"
 6. **Cover happy path and error path** — At minimum, one success and one failure evidence marker
 7. **On a leaf work unit, the markers are binding** — For a Bug / Task / Sub-task / Improvement, every typed `[EVIDENCE: <artifact-type>: <name>]` here is the ticket's evidence manifest: validation gate S14 requires at least one, and the ticket cannot be closed until each named artifact is captured **in its declared type** and attached (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Name only evidence you intend to capture — and name all of it.
+8. **Reference sibling evidence without claiming it** — Use only `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]` when prose points to an artifact declared by another ticket. Never paste, quote, or code-format the sibling's `[EVIDENCE: ...]` marker: that exact prefix creates a local obligation. `EVIDENCE-REF` never satisfies this ticket's S14 minimum, uniqueness check, capture list, or completion gate; a runtime-changing leaf still needs at least one local `[EVIDENCE: ...]` marker.
 
 ### Step 6: Present to User for Approval
 
-Display the drafted Validation Journey to the user and ask for confirmation before appending it to the ticket.
+Display the drafted Validation Journey change to the user and ask for confirmation before updating the ticket.
 
-### Step 7: Append to Ticket Description
+### Step 7: Merge into Ticket Description
 
-After user approval, use the JIRA REST API to append the Validation Journey to the existing ticket description.
+After user approval, use the JIRA REST API to update the ticket description. If no journey exists, append one section. If a reference-only journey exists, preserve all existing prose and `EVIDENCE-REF` pointers and append only the missing local steps/markers inside that existing section. Never create a second `Validation Journey` heading; the parser selects the existing section and duplicate headings make S14 evaluation ambiguous.
 
 ### Step 8: Verify
 
@@ -113,6 +114,8 @@ Run the parser again to confirm the journey was added correctly:
 python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID>
 ```
 
+Confirm the journey has at least one local `[EVIDENCE: <artifact-type>: <name>]` marker. An `EVIDENCE-REF` alone does not count.
+
 ## When to Use This Skill
 
 - Ticket was created before the Validation Journey convention was established

package/plugins/src/base/skills/lisa-jira-create/SKILL.md

@@ -83,6 +83,7 @@ h3. Assertions
 
 1. **Steps must be concrete and verifiable** — "Run `curl -s localhost:3000/health`" not "Check the API"
 2. **Evidence markers at verification points** — Place typed `[EVIDENCE: <artifact-type>: <name>]` at states that prove the change works. The type names HOW the proof is captured, the kebab-case name WHAT it proves (e.g., `[EVIDENCE: http-transcript: api-response-200]`, `[EVIDENCE: screenshot: error-state-rendered]`). An untyped assertion label like `[EVIDENCE: works-gracefully]` fails validation gate S14
+   - To point at evidence owned by another work item, use exactly `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]`. It is non-claiming and cannot satisfy S14; never paste or quote the sibling's `[EVIDENCE: ...]` marker into this ticket.
 3. **Include 2-5 evidence markers** — Enough to prove the change works across happy path and error cases
 4. **Assertions are testable statements** — "Health check returns 200 with status ok" not "API works"
 5. **Prerequisites include environment setup** — Database connection, env vars, running services

package/plugins/src/base/skills/lisa-jira-journey/SKILL.md

@@ -70,6 +70,8 @@ At each typed `[EVIDENCE: <artifact-type>: <name>]` marker, capture an artifact
 
 A prose claim ("the error state rendered gracefully") satisfies no marker. Legacy untyped markers: infer the type from the step's action, capture accordingly, and note the inference. Write each artifact to a numbered file:
 
+Treat only exact `[EVIDENCE: ...]` markers (plus the legacy local `[SCREENSHOT: ...]` form) as capture instructions. `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]` points to another work item's artifact: preserve it as explanatory text, but do not capture it, assign it a sequence number, include it in duplicate-name checks, or count it as a local manifest entry. If a runtime-changing leaf has references but no local claiming marker, stop because S14 is unsatisfied.
+
 #### Evidence Naming Convention
 
 Evidence files are named: `{NN}-{evidence-name}.{ext}` — extension matches the declared artifact type (`.png`/`.webm` for screenshot/recording, `.txt` for transcripts/logs/output, `.json` for structured state)

package/plugins/src/base/skills/lisa-jira-journey/scripts/generate-templates.py

@@ -21,6 +21,12 @@ import sys
 from pathlib import Path
 
 
+# Strip local capture claims from rendered step prose. EVIDENCE-REF is a
+# cross-work-item pointer, so it must remain visible in both JIRA and GitHub
+# evidence comments.
+LOCAL_EVIDENCE_PATTERN = re.compile(r'\s*\[(SCREENSHOT|EVIDENCE):\s*[^\]]+\]')
+
+
 def get_jira_server():
     """Read JIRA server URL from jira-cli config."""
     config_path = Path.home() / ".config" / ".jira" / ".config.yml"
@@ -115,7 +121,7 @@ def generate_jira_wiki(ticket_id, pr_number, branch, evidence_files, journey, gh
         lines.append("")
         for step in journey["steps"]:
             text = step["text"]
-            clean_text = re.sub(r'\s*\[(SCREENSHOT|EVIDENCE):\s*[^\]]+\]', '', text).strip()
+            clean_text = LOCAL_EVIDENCE_PATTERN.sub('', text).strip()
             lines.append(f"# {clean_text}")
         lines.append("")
 
@@ -175,7 +181,7 @@ def generate_github_md(ticket_id, pr_number, branch, evidence_files, journey, gh
         lines.append("")
         for step in journey["steps"]:
             text = step["text"]
-            clean_text = re.sub(r'\s*\[(SCREENSHOT|EVIDENCE):\s*[^\]]+\]', '', text).strip()
+            clean_text = LOCAL_EVIDENCE_PATTERN.sub('', text).strip()
             lines.append(f"{step['number']}. {clean_text}")
         lines.append("")
 

package/plugins/src/base/skills/lisa-jira-journey/scripts/parse-plan.py

@@ -35,6 +35,12 @@ from base64 import b64encode
 from pathlib import Path
 
 
+# Intentionally matches the exact local-claim prefixes only. EVIDENCE-REF is a
+# cross-work-item pointer and must remain visible in step prose without becoming
+# a capture obligation.
+LOCAL_EVIDENCE_PATTERN = re.compile(r'\[(SCREENSHOT|EVIDENCE):\s*([^\]]+)\]')
+
+
 def get_jira_config():
     """Read JIRA server and login from jira-cli config."""
     config_path = Path.home() / ".config" / ".jira" / ".config.yml"
@@ -153,7 +159,7 @@ def parse_prerequisites(nodes):
 def clean_step_text(text, screenshot_name):
     """Remove [SCREENSHOT: ...] or [EVIDENCE: ...] marker from step text and deduplicate."""
     # Remove the marker itself
-    cleaned = re.sub(r'\[(SCREENSHOT|EVIDENCE):\s*[^\]]+\]\s*', '', text).strip()
+    cleaned = LOCAL_EVIDENCE_PATTERN.sub('', text).strip()
 
     # Deduplicate: if the same phrase appears twice consecutively, keep one
     # This handles ADF text node concatenation artifacts
@@ -177,7 +183,7 @@ def parse_steps(nodes):
                 text = extract_text_from_adf(item).strip()
 
                 screenshot = None
-                match = re.search(r'\[(SCREENSHOT|EVIDENCE):\s*([^\]]+)\]', text)
+                match = LOCAL_EVIDENCE_PATTERN.search(text)
                 if match:
                     screenshot = match.group(2).strip()
 
@@ -193,7 +199,7 @@ def parse_steps(nodes):
             if text and re.match(r'^\d+\.?\s', text):
                 step_number += 1
                 screenshot = None
-                match = re.search(r'\[(SCREENSHOT|EVIDENCE):\s*([^\]]+)\]', text)
+                match = LOCAL_EVIDENCE_PATTERN.search(text)
                 if match:
                     screenshot = match.group(2).strip()
 

package/plugins/src/base/skills/lisa-jira-validate-ticket/SKILL.md

@@ -208,7 +208,9 @@ Each marker must satisfy ALL of:
 
 **A marker names an artifact, not an assertion.** An untyped marker (`[EVIDENCE: load-failure-handled-gracefully]`) is an assertion label with nothing to capture and must FAIL, with a remediation that shows the typed transformation (e.g. → `[EVIDENCE: screenshot: load-failure-error-state]`, `[EVIDENCE: perf-trace: pipeline-load-tti]`).
 
-FAIL when the Validation Journey is present but declares zero markers, when any marker is untyped or uses a type outside the taxonomy, or when any name is empty, duplicated, or not kebab-case. A behavior-changing work unit SHOULD declare both a success marker and an error/edge marker; a journey with only one marker passes but the remediation should recommend adding the error/edge case.
+FAIL when the Validation Journey is present but declares zero binding `[EVIDENCE: ...]` markers, when any binding marker is untyped or uses a type outside the taxonomy, or when any binding name is empty, duplicated, or not kebab-case. A behavior-changing work unit SHOULD declare both a success marker and an error/edge marker; a journey with only one binding marker passes but the remediation should recommend adding the error/edge case.
+
+Parse claiming markers by the exact `[EVIDENCE:` prefix. A cross-work-item pointer in the exact form `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]` is non-claiming: exclude it from the manifest, S14's minimum-marker count, local marker type/name validation, and duplicate-name checks. Independently validate every `EVIDENCE-REF`: the native work-item reference must be non-empty and unambiguous, the artifact type must use the fixed taxonomy, and the name must be non-empty kebab-case. A malformed reference FAILs S14 as an invalid pointer but never becomes a local evidence obligation. A valid reference may point to a sibling's artifact, but it never satisfies S14 for this ticket. Therefore a runtime-changing leaf whose journey contains only `EVIDENCE-REF` entries FAILs S14. Quoting or code-formatting another ticket's `[EVIDENCE: ...]` marker does not make it a reference; writers must convert it to `EVIDENCE-REF`.
 
 This gate depends on S11. It is `N/A` for containers — an **Epic**, or any item with open child work (coordination containers, not work units) — and for leaf units with `runtime_behavior_change = false` (doc-only / config-only / type-only). If S11 fails because the Validation Journey is absent, S14 also FAILs (there is no manifest to bind) with remediation pointing back to `lisa-jira-add-journey`.
 

package/plugins/src/base/skills/lisa-jira-write-ticket/SKILL.md

@@ -104,7 +104,9 @@ list multiple repos.]
 
 h2. Validation Journey
 [Delegate to /jira-add-journey if the ticket changes runtime behavior.
- Skip only for doc-only, config-only, or type-only tickets.]
+ Skip only for doc-only, config-only, or type-only tickets. Cross-work-item
+ evidence pointers use `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]`;
+ they never replace this ticket's local S14 marker.]
 ```
 
 Rules:

package/plugins/src/base/skills/lisa-linear-add-journey/SKILL.md

@@ -26,7 +26,7 @@ Fetch via `lisa-linear-access operation: get-issue` and extract: title, descript
 
 ### Step 2: Check for Existing Journey
 
-If the description already contains a `## Validation Journey` section, report and stop — never overwrite an existing journey without explicit instruction.
+If the description contains a `## Validation Journey` section, inspect that section for at least one local typed `[EVIDENCE: <artifact-type>: <name>]` marker. Stop only when that local marker exists. An `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]` is a non-claiming pointer and does not count; if the journey has references but no local claiming marker, continue drafting the missing local journey evidence. Preserve the existing journey prose and references when appending the local evidence rather than overwriting them.
 
 ### Step 3: Analyze the Change Type
 
@@ -82,22 +82,23 @@ Compose the journey with typed `[EVIDENCE: <artifact-type>: <name>]` markers at
 1. **2–5 evidence markers** — Focus on proving the change works and handles errors.
 2. **Concrete, runnable steps** — `Run \`curl -s localhost:3000/health | jq .status\`` not "Check the endpoint".
 3. **Include environment setup** — Database connection, running services, env vars.
-4. **Markers are typed artifacts, not assertion labels** — `[EVIDENCE: <artifact-type>: <kebab-name>]`. `[EVIDENCE: load-failure-handled-gracefully]` names a claim with nothing to capture; write `[EVIDENCE: screenshot: load-failure-error-state]` or `[EVIDENCE: perf-trace: pipeline-load-tti]`. Names are kebab-case and unique within the ticket.
+4. **Markers are typed artifacts, not assertion labels** — `[EVIDENCE: <artifact-type>: <kebab-case-name>]`. `[EVIDENCE: load-failure-handled-gracefully]` names a claim with nothing to capture; write `[EVIDENCE: screenshot: load-failure-error-state]` or `[EVIDENCE: perf-trace: pipeline-load-tti]`. Names are kebab-case and unique within the ticket.
 5. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly".
 6. **Cover happy path and error path** — At minimum, one success and one failure evidence marker.
 7. **On a leaf work unit, the markers are binding** — For a Bug / Task / Sub-task / Improvement, every typed `[EVIDENCE: <artifact-type>: <name>]` here is the item's evidence manifest: validation gate S14 requires at least one, and the item cannot be closed until each named artifact is captured **in its declared type** and attached (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Name only evidence you intend to capture — and name all of it.
+8. **Reference sibling evidence without claiming it** — Use only `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]` when prose points to an artifact declared by another item. Never paste, quote, or code-format the sibling's `[EVIDENCE: ...]` marker: that exact prefix creates a local obligation. `EVIDENCE-REF` never satisfies this item's S14 minimum, uniqueness check, capture list, or completion gate; a runtime-changing leaf still needs at least one local `[EVIDENCE: ...]` marker.
 
 ### Step 6: Present to User for Approval
 
-Display the drafted journey and ask for confirmation before appending.
+Display the drafted journey change and ask for confirmation before updating the issue.
 
-### Step 7: Append to Issue Description
+### Step 7: Merge into Issue Description
 
-After approval, fetch the current description, append the new Validation Journey section, and update via `lisa-linear-access operation: save-issue({id, description: <new-description>})`. Preserve all existing description content — never overwrite.
+After approval, fetch the current description and update via `lisa-linear-access operation: save-issue({id, description: <new-description>})`. If no journey exists, append one section. If a reference-only journey exists, preserve all existing prose and `EVIDENCE-REF` pointers and append only the missing local steps/markers inside that existing section. Never create a second `## Validation Journey` heading. Preserve all other description content — never overwrite or re-render it.
 
 ### Step 8: Verify
 
-Re-fetch the issue and confirm the section is present.
+Re-fetch the issue and confirm the section is present with at least one local `[EVIDENCE: <artifact-type>: <name>]` marker. An `EVIDENCE-REF` alone does not count.
 
 ## When to Use This Skill
 

package/plugins/src/base/skills/lisa-linear-create/SKILL.md

@@ -60,6 +60,8 @@ Items that change runtime behavior should include a `## Validation Journey` sect
 
 Design the journey based on the **change type**. Place typed `[EVIDENCE: <artifact-type>: <name>]` markers at key verification points (types: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump` — see the `verification` rule).
 
+To point at evidence owned by another work item, use exactly `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]`. It is non-claiming and cannot satisfy S14; never paste or quote the sibling's `[EVIDENCE: ...]` marker into this item.
+
 ```markdown
 ## Validation Journey