@codyswann/lisa 2.222.3 → 2.223.0

package/package.json

@@ -102,7 +102,7 @@
     "form-data": ">=4.0.6"
   },
   "name": "@codyswann/lisa",
-  "version": "2.222.3",
+  "version": "2.223.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.222.3",
+  "version": "2.223.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.222.3",
+  "version": "2.223.0",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/skills/lisa-github-add-journey/SKILL.md

@@ -83,9 +83,10 @@ Compose the journey with typed `[EVIDENCE: <artifact-type>: <name>]` markers at
 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.
-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.
+5. **Cross-ticket references are non-binding** — If the journey needs to mention another issue's artifact, use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <kebab-name>]` (for example, `[EVIDENCE-REF: #123: cli-output: upstream-contract-pass]`). Do not paste a sibling issue's `[EVIDENCE: ...]` marker into this issue; S14 treats `[EVIDENCE: ...]` as this issue's own manifest and ignores `EVIDENCE-REF`.
+6. **Assertions are measurable** — `Returns 200 with {status: ok}` not "API works correctly".
+7. **Cover happy path AND error path** — At minimum, one success and one failure marker.
+8. **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; `EVIDENCE-REF` never satisfies or extends the manifest.
 
 ### Step 6: Present to User for Approval
 

package/plugins/lisa/.codex-plugin/skills/lisa-github-validate-issue/SKILL.md

@@ -205,9 +205,11 @@ Each marker must satisfy ALL of:
 - `<artifact-type>` is one of the fixed taxonomy: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump`. (The legacy `[SCREENSHOT: name]` form is accepted as `screenshot`.)
 - `<name>` is kebab-case and unique within the issue.
 
+Non-binding cross-references use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <name>]`, where `<tracker-ref>` is the owning issue (`#123`, `owner/repo#123`, or a GitHub issue URL). S14 MUST ignore `EVIDENCE-REF` markers when deriving this issue's manifest, and a valid `EVIDENCE-REF` does not satisfy the "at least one marker" requirement. Agents must use `EVIDENCE-REF` instead of quoting a sibling issue's `[EVIDENCE: ...]` marker in prose.
+
 **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.
 
 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/lisa/.codex-plugin/skills/lisa-jira-add-journey/SKILL.md

@@ -93,9 +93,10 @@ h3. Assertions
 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.
-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.
+5. **Cross-ticket references are non-binding** — If the journey needs to mention another ticket's artifact, use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <kebab-name>]` (for example, `[EVIDENCE-REF: PROJ-123: cli-output: upstream-contract-pass]`). Do not paste a sibling ticket's `[EVIDENCE: ...]` marker into this ticket; S14 treats `[EVIDENCE: ...]` as this ticket's own manifest and ignores `EVIDENCE-REF`.
+6. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly"
+7. **Cover happy path and error path** — At minimum, one success and one failure evidence marker
+8. **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; `EVIDENCE-REF` never satisfies or extends the manifest.
 
 ### Step 6: Present to User for Approval
 

package/plugins/lisa/.codex-plugin/skills/lisa-jira-validate-ticket/SKILL.md

@@ -206,9 +206,11 @@ Each marker must satisfy ALL of:
 - `<artifact-type>` is one of the fixed taxonomy: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump`. (The legacy `[SCREENSHOT: name]` form is accepted as `screenshot`.)
 - `<name>` is kebab-case and unique within the ticket.
 
+Non-binding cross-references use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <name>]`, where `<tracker-ref>` is the owning ticket or issue (`PROJ-123`, `#123`, `owner/repo#123`, or a tracker URL). S14 MUST ignore `EVIDENCE-REF` markers when deriving this ticket's manifest, and a valid `EVIDENCE-REF` does not satisfy the "at least one marker" requirement. Agents must use `EVIDENCE-REF` instead of quoting a sibling ticket's `[EVIDENCE: ...]` marker in prose.
+
 **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.
 
 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/lisa/.codex-plugin/skills/lisa-linear-add-journey/SKILL.md

@@ -83,9 +83,10 @@ Compose the journey with typed `[EVIDENCE: <artifact-type>: <name>]` markers at
 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.
-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.
+5. **Cross-item references are non-binding** — If the journey needs to mention another item's artifact, use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <kebab-name>]` (for example, `[EVIDENCE-REF: ENG-123: cli-output: upstream-contract-pass]`). Do not paste a sibling item's `[EVIDENCE: ...]` marker into this item; S14 treats `[EVIDENCE: ...]` as this item's own manifest and ignores `EVIDENCE-REF`.
+6. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly".
+7. **Cover happy path and error path** — At minimum, one success and one failure evidence marker.
+8. **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; `EVIDENCE-REF` never satisfies or extends the manifest.
 
 ### Step 6: Present to User for Approval
 

package/plugins/lisa/.codex-plugin/skills/lisa-linear-validate-issue/SKILL.md

@@ -209,9 +209,11 @@ Each marker must satisfy ALL of:
 - `<artifact-type>` is one of the fixed taxonomy: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump`. (The legacy `[SCREENSHOT: name]` form is accepted as `screenshot`.)
 - `<name>` is kebab-case and unique within the item.
 
+Non-binding cross-references use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <name>]`, where `<tracker-ref>` is the owning item or issue (`ENG-123`, `PROJ-123`, `#123`, `owner/repo#123`, or a tracker URL). S14 MUST ignore `EVIDENCE-REF` markers when deriving this item's manifest, and a valid `EVIDENCE-REF` does not satisfy the "at least one marker" requirement. Agents must use `EVIDENCE-REF` instead of quoting a sibling item's `[EVIDENCE: ...]` marker in prose.
+
 **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.
 
 This gate depends on S11. It is `N/A` for containers — a **Project** (the Epic equivalent), 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-linear-add-journey`.
 

package/plugins/lisa/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 ticket's artifact without claiming it, use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <name>]`; validators ignore `EVIDENCE-REF` when building the current issue's manifest, 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/lisa/rules/reference/verification.md

@@ -122,6 +122,14 @@ The declaration is not a separate field — it is the set of `[EVIDENCE: <artifa
 - `<artifact-type>` — HOW the proof is captured, from the fixed taxonomy below.
 - `<kebab-case-name>` — WHAT it proves, unique within the ticket.
 
+To reference a sibling or parent artifact without adding it to the current work unit's manifest, use the non-binding cross-reference form:
+
+```text
+[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <kebab-case-name>]
+```
+
+`<tracker-ref>` is the owning ticket or issue (`#123`, `PROJ-123`, `ENG-123`, `owner/repo#123`, or a tracker URL). Validators and journey runners MUST ignore `EVIDENCE-REF` markers when building the current work unit's evidence manifest. Never quote a sibling's `[EVIDENCE: ...]` marker directly in prose; that syntax always belongs to the current work unit.
+
 Example transformation (the failure mode this grammar exists to prevent):
 
 | Assertion label (invalid) | Typed artifact (valid) |

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

@@ -83,9 +83,10 @@ Compose the journey with typed `[EVIDENCE: <artifact-type>: <name>]` markers at
 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.
-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.
+5. **Cross-ticket references are non-binding** — If the journey needs to mention another issue's artifact, use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <kebab-name>]` (for example, `[EVIDENCE-REF: #123: cli-output: upstream-contract-pass]`). Do not paste a sibling issue's `[EVIDENCE: ...]` marker into this issue; S14 treats `[EVIDENCE: ...]` as this issue's own manifest and ignores `EVIDENCE-REF`.
+6. **Assertions are measurable** — `Returns 200 with {status: ok}` not "API works correctly".
+7. **Cover happy path AND error path** — At minimum, one success and one failure marker.
+8. **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; `EVIDENCE-REF` never satisfies or extends the manifest.
 
 ### Step 6: Present to User for Approval
 

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

@@ -205,9 +205,11 @@ Each marker must satisfy ALL of:
 - `<artifact-type>` is one of the fixed taxonomy: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump`. (The legacy `[SCREENSHOT: name]` form is accepted as `screenshot`.)
 - `<name>` is kebab-case and unique within the issue.
 
+Non-binding cross-references use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <name>]`, where `<tracker-ref>` is the owning issue (`#123`, `owner/repo#123`, or a GitHub issue URL). S14 MUST ignore `EVIDENCE-REF` markers when deriving this issue's manifest, and a valid `EVIDENCE-REF` does not satisfy the "at least one marker" requirement. Agents must use `EVIDENCE-REF` instead of quoting a sibling issue's `[EVIDENCE: ...]` marker in prose.
+
 **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.
 
 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/lisa/skills/lisa-jira-add-journey/SKILL.md

@@ -93,9 +93,10 @@ h3. Assertions
 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.
-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.
+5. **Cross-ticket references are non-binding** — If the journey needs to mention another ticket's artifact, use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <kebab-name>]` (for example, `[EVIDENCE-REF: PROJ-123: cli-output: upstream-contract-pass]`). Do not paste a sibling ticket's `[EVIDENCE: ...]` marker into this ticket; S14 treats `[EVIDENCE: ...]` as this ticket's own manifest and ignores `EVIDENCE-REF`.
+6. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly"
+7. **Cover happy path and error path** — At minimum, one success and one failure evidence marker
+8. **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; `EVIDENCE-REF` never satisfies or extends the manifest.
 
 ### Step 6: Present to User for Approval
 

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

@@ -206,9 +206,11 @@ Each marker must satisfy ALL of:
 - `<artifact-type>` is one of the fixed taxonomy: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump`. (The legacy `[SCREENSHOT: name]` form is accepted as `screenshot`.)
 - `<name>` is kebab-case and unique within the ticket.
 
+Non-binding cross-references use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <name>]`, where `<tracker-ref>` is the owning ticket or issue (`PROJ-123`, `#123`, `owner/repo#123`, or a tracker URL). S14 MUST ignore `EVIDENCE-REF` markers when deriving this ticket's manifest, and a valid `EVIDENCE-REF` does not satisfy the "at least one marker" requirement. Agents must use `EVIDENCE-REF` instead of quoting a sibling ticket's `[EVIDENCE: ...]` marker in prose.
+
 **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.
 
 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/lisa/skills/lisa-linear-add-journey/SKILL.md

@@ -83,9 +83,10 @@ Compose the journey with typed `[EVIDENCE: <artifact-type>: <name>]` markers at
 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.
-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.
+5. **Cross-item references are non-binding** — If the journey needs to mention another item's artifact, use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <kebab-name>]` (for example, `[EVIDENCE-REF: ENG-123: cli-output: upstream-contract-pass]`). Do not paste a sibling item's `[EVIDENCE: ...]` marker into this item; S14 treats `[EVIDENCE: ...]` as this item's own manifest and ignores `EVIDENCE-REF`.
+6. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly".
+7. **Cover happy path and error path** — At minimum, one success and one failure evidence marker.
+8. **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; `EVIDENCE-REF` never satisfies or extends the manifest.
 
 ### Step 6: Present to User for Approval
 

package/plugins/lisa/skills/lisa-linear-validate-issue/SKILL.md

@@ -209,9 +209,11 @@ Each marker must satisfy ALL of:
 - `<artifact-type>` is one of the fixed taxonomy: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump`. (The legacy `[SCREENSHOT: name]` form is accepted as `screenshot`.)
 - `<name>` is kebab-case and unique within the item.
 
+Non-binding cross-references use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <name>]`, where `<tracker-ref>` is the owning item or issue (`ENG-123`, `PROJ-123`, `#123`, `owner/repo#123`, or a tracker URL). S14 MUST ignore `EVIDENCE-REF` markers when deriving this item's manifest, and a valid `EVIDENCE-REF` does not satisfy the "at least one marker" requirement. Agents must use `EVIDENCE-REF` instead of quoting a sibling item's `[EVIDENCE: ...]` marker in prose.
+
 **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.
 
 This gate depends on S11. It is `N/A` for containers — a **Project** (the Epic equivalent), 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-linear-add-journey`.
 

package/plugins/lisa-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.222.3",
+  "version": "2.223.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

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

@@ -83,9 +83,10 @@ Compose the journey with typed `[EVIDENCE: <artifact-type>: <name>]` markers at
 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.
-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.
+5. **Cross-ticket references are non-binding** — If the journey needs to mention another issue's artifact, use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <kebab-name>]` (for example, `[EVIDENCE-REF: #123: cli-output: upstream-contract-pass]`). Do not paste a sibling issue's `[EVIDENCE: ...]` marker into this issue; S14 treats `[EVIDENCE: ...]` as this issue's own manifest and ignores `EVIDENCE-REF`.
+6. **Assertions are measurable** — `Returns 200 with {status: ok}` not "API works correctly".
+7. **Cover happy path AND error path** — At minimum, one success and one failure marker.
+8. **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; `EVIDENCE-REF` never satisfies or extends the manifest.
 
 ### Step 6: Present to User for Approval
 

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

@@ -205,9 +205,11 @@ Each marker must satisfy ALL of:
 - `<artifact-type>` is one of the fixed taxonomy: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump`. (The legacy `[SCREENSHOT: name]` form is accepted as `screenshot`.)
 - `<name>` is kebab-case and unique within the issue.
 
+Non-binding cross-references use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <name>]`, where `<tracker-ref>` is the owning issue (`#123`, `owner/repo#123`, or a GitHub issue URL). S14 MUST ignore `EVIDENCE-REF` markers when deriving this issue's manifest, and a valid `EVIDENCE-REF` does not satisfy the "at least one marker" requirement. Agents must use `EVIDENCE-REF` instead of quoting a sibling issue's `[EVIDENCE: ...]` marker in prose.
+
 **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.
 
 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/lisa-agy/skills/lisa-jira-add-journey/SKILL.md

@@ -93,9 +93,10 @@ h3. Assertions
 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.
-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.
+5. **Cross-ticket references are non-binding** — If the journey needs to mention another ticket's artifact, use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <kebab-name>]` (for example, `[EVIDENCE-REF: PROJ-123: cli-output: upstream-contract-pass]`). Do not paste a sibling ticket's `[EVIDENCE: ...]` marker into this ticket; S14 treats `[EVIDENCE: ...]` as this ticket's own manifest and ignores `EVIDENCE-REF`.
+6. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly"
+7. **Cover happy path and error path** — At minimum, one success and one failure evidence marker
+8. **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; `EVIDENCE-REF` never satisfies or extends the manifest.
 
 ### Step 6: Present to User for Approval
 

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

@@ -206,9 +206,11 @@ Each marker must satisfy ALL of:
 - `<artifact-type>` is one of the fixed taxonomy: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump`. (The legacy `[SCREENSHOT: name]` form is accepted as `screenshot`.)
 - `<name>` is kebab-case and unique within the ticket.
 
+Non-binding cross-references use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <name>]`, where `<tracker-ref>` is the owning ticket or issue (`PROJ-123`, `#123`, `owner/repo#123`, or a tracker URL). S14 MUST ignore `EVIDENCE-REF` markers when deriving this ticket's manifest, and a valid `EVIDENCE-REF` does not satisfy the "at least one marker" requirement. Agents must use `EVIDENCE-REF` instead of quoting a sibling ticket's `[EVIDENCE: ...]` marker in prose.
+
 **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.
 
 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/lisa-agy/skills/lisa-linear-add-journey/SKILL.md

@@ -83,9 +83,10 @@ Compose the journey with typed `[EVIDENCE: <artifact-type>: <name>]` markers at
 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.
-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.
+5. **Cross-item references are non-binding** — If the journey needs to mention another item's artifact, use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <kebab-name>]` (for example, `[EVIDENCE-REF: ENG-123: cli-output: upstream-contract-pass]`). Do not paste a sibling item's `[EVIDENCE: ...]` marker into this item; S14 treats `[EVIDENCE: ...]` as this item's own manifest and ignores `EVIDENCE-REF`.
+6. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly".
+7. **Cover happy path and error path** — At minimum, one success and one failure evidence marker.
+8. **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; `EVIDENCE-REF` never satisfies or extends the manifest.
 
 ### Step 6: Present to User for Approval
 

package/plugins/lisa-agy/skills/lisa-linear-validate-issue/SKILL.md

@@ -209,9 +209,11 @@ Each marker must satisfy ALL of:
 - `<artifact-type>` is one of the fixed taxonomy: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump`. (The legacy `[SCREENSHOT: name]` form is accepted as `screenshot`.)
 - `<name>` is kebab-case and unique within the item.
 
+Non-binding cross-references use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <name>]`, where `<tracker-ref>` is the owning item or issue (`ENG-123`, `PROJ-123`, `#123`, `owner/repo#123`, or a tracker URL). S14 MUST ignore `EVIDENCE-REF` markers when deriving this item's manifest, and a valid `EVIDENCE-REF` does not satisfy the "at least one marker" requirement. Agents must use `EVIDENCE-REF` instead of quoting a sibling item's `[EVIDENCE: ...]` marker in prose.
+
 **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.
 
 This gate depends on S11. It is `N/A` for containers — a **Project** (the Epic equivalent), 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-linear-add-journey`.
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.222.3",
+  "version": "2.223.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.222.3",
+  "version": "2.223.0",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.222.3",
+  "version": "2.223.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.222.3",
+  "version": "2.223.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.222.3",
+  "version": "2.223.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.222.3",
+  "version": "2.223.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-copilot/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 ticket's artifact without claiming it, use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <name>]`; validators ignore `EVIDENCE-REF` when building the current issue's manifest, 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/lisa-copilot/rules/reference/verification.md

@@ -122,6 +122,14 @@ The declaration is not a separate field — it is the set of `[EVIDENCE: <artifa
 - `<artifact-type>` — HOW the proof is captured, from the fixed taxonomy below.
 - `<kebab-case-name>` — WHAT it proves, unique within the ticket.
 
+To reference a sibling or parent artifact without adding it to the current work unit's manifest, use the non-binding cross-reference form:
+
+```text
+[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <kebab-case-name>]
+```
+
+`<tracker-ref>` is the owning ticket or issue (`#123`, `PROJ-123`, `ENG-123`, `owner/repo#123`, or a tracker URL). Validators and journey runners MUST ignore `EVIDENCE-REF` markers when building the current work unit's evidence manifest. Never quote a sibling's `[EVIDENCE: ...]` marker directly in prose; that syntax always belongs to the current work unit.
+
 Example transformation (the failure mode this grammar exists to prevent):
 
 | Assertion label (invalid) | Typed artifact (valid) |

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

@@ -83,9 +83,10 @@ Compose the journey with typed `[EVIDENCE: <artifact-type>: <name>]` markers at
 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.
-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.
+5. **Cross-ticket references are non-binding** — If the journey needs to mention another issue's artifact, use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <kebab-name>]` (for example, `[EVIDENCE-REF: #123: cli-output: upstream-contract-pass]`). Do not paste a sibling issue's `[EVIDENCE: ...]` marker into this issue; S14 treats `[EVIDENCE: ...]` as this issue's own manifest and ignores `EVIDENCE-REF`.
+6. **Assertions are measurable** — `Returns 200 with {status: ok}` not "API works correctly".
+7. **Cover happy path AND error path** — At minimum, one success and one failure marker.
+8. **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; `EVIDENCE-REF` never satisfies or extends the manifest.
 
 ### Step 6: Present to User for Approval
 

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

@@ -205,9 +205,11 @@ Each marker must satisfy ALL of:
 - `<artifact-type>` is one of the fixed taxonomy: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump`. (The legacy `[SCREENSHOT: name]` form is accepted as `screenshot`.)
 - `<name>` is kebab-case and unique within the issue.
 
+Non-binding cross-references use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <name>]`, where `<tracker-ref>` is the owning issue (`#123`, `owner/repo#123`, or a GitHub issue URL). S14 MUST ignore `EVIDENCE-REF` markers when deriving this issue's manifest, and a valid `EVIDENCE-REF` does not satisfy the "at least one marker" requirement. Agents must use `EVIDENCE-REF` instead of quoting a sibling issue's `[EVIDENCE: ...]` marker in prose.
+
 **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.
 
 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/lisa-copilot/skills/lisa-jira-add-journey/SKILL.md

@@ -93,9 +93,10 @@ h3. Assertions
 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.
-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.
+5. **Cross-ticket references are non-binding** — If the journey needs to mention another ticket's artifact, use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <kebab-name>]` (for example, `[EVIDENCE-REF: PROJ-123: cli-output: upstream-contract-pass]`). Do not paste a sibling ticket's `[EVIDENCE: ...]` marker into this ticket; S14 treats `[EVIDENCE: ...]` as this ticket's own manifest and ignores `EVIDENCE-REF`.
+6. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly"
+7. **Cover happy path and error path** — At minimum, one success and one failure evidence marker
+8. **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; `EVIDENCE-REF` never satisfies or extends the manifest.
 
 ### Step 6: Present to User for Approval
 

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

@@ -206,9 +206,11 @@ Each marker must satisfy ALL of:
 - `<artifact-type>` is one of the fixed taxonomy: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump`. (The legacy `[SCREENSHOT: name]` form is accepted as `screenshot`.)
 - `<name>` is kebab-case and unique within the ticket.
 
+Non-binding cross-references use `[EVIDENCE-REF: <tracker-ref>: <artifact-type>: <name>]`, where `<tracker-ref>` is the owning ticket or issue (`PROJ-123`, `#123`, `owner/repo#123`, or a tracker URL). S14 MUST ignore `EVIDENCE-REF` markers when deriving this ticket's manifest, and a valid `EVIDENCE-REF` does not satisfy the "at least one marker" requirement. Agents must use `EVIDENCE-REF` instead of quoting a sibling ticket's `[EVIDENCE: ...]` marker in prose.
+
 **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.
 
 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`.