@codyswann/lisa 2.222.3 → 2.223.0

package/plugins/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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`.