@codyswann/lisa 2.222.2 → 2.223.0

package/dist/opencode/plugin-templates/parity-safety-net.sh

@@ -0,0 +1,155 @@
+#!/usr/bin/env bash
+# PreToolUse hook for Bash: a safety net that blocks destructive shell commands
+# before they run. Lisa-native reimplementation of the upstream
+# `safety-net@cc-marketplace` plugin's PreToolUse Bash-guard (parity work, issue
+# #1059). It does NOT port upstream code — it re-expresses the behavior in Lisa's
+# hook conventions, modeled on block-no-verify.sh.
+#
+# It reads the hook stdin JSON, inspects the proposed Bash command, and EXITS
+# NON-ZERO (2) to BLOCK when a known-destructive pattern matches:
+#   - `rm -rf /` (recursive forced delete of a root / home / wildcard path)
+#   - force-pushing a protected branch (main/master/production/release)
+#   - `git reset --hard` while the working tree is dirty (would discard work)
+#   - dropping or truncating a database/schema/table
+# Otherwise it exits 0 and the command proceeds.
+#
+# Operators extend the built-in rules with a project-local rule file — one
+# extended-regex (ERE) per line, blank lines and `#` comments ignored — managed
+# by the parity-safety-net-rules skill. Default location (overridable via
+# SAFETY_NET_RULES_FILE):
+#   ${CLAUDE_PROJECT_DIR:-$PWD}/.claude/safety-net-rules.txt
+set -euo pipefail
+
+input="$(cat)"
+
+tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty')"
+if [ "$tool_name" != "Bash" ]; then
+  exit 0
+fi
+
+command_str="$(printf '%s' "$input" | jq -r '.tool_input.command // empty')"
+if [ -z "$command_str" ]; then
+  exit 0
+fi
+
+# block() prints the reason to stderr (surfaced to the model) and exits 2 so the
+# Bash tool call is denied. $1 = human-readable reason for the block.
+block() {
+  cat >&2 <<EOF
+Blocked by safety-net: $1
+
+This command matched a destructive-operation guard. If it is genuinely safe and
+intentional, ask the user to confirm, then run it manually outside the agent, or
+narrow the command so it no longer matches the guard.
+EOF
+  exit 2
+}
+
+# Heredoc payloads are data only for a deliberately narrow set of GitHub CLI
+# write commands. A companion parser proves that shape before removing payload
+# text from the destructive-command scans below. Unknown executable heredocs
+# remain visible to every built-in and custom rule. Ambiguous or malformed
+# heredocs fail closed instead of guessing which text the shell would execute.
+command_for_guards="$command_str"
+case "$command_str" in
+  *'<<'*)
+    hook_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+    heredoc_parser="$hook_dir/parity-safety-net-heredoc.py"
+    if ! command -v python3 >/dev/null 2>&1 || [ ! -r "$heredoc_parser" ]; then
+      block "cannot safely classify heredoc command because its parser runtime is unavailable"
+    fi
+    if ! printf '%s\n' "$command_str" | /bin/bash -n >/dev/null 2>&1; then
+      block "malformed heredoc command failed shell syntax validation"
+    fi
+
+    parser_status=0
+    if parser_output="$(printf '%s' "$command_str" | python3 "$heredoc_parser" 2>/dev/null)"; then
+      parser_status=0
+    else
+      parser_status=$?
+    fi
+
+    case "$parser_status" in
+      0) command_for_guards="$parser_output" ;;
+      10) command_for_guards="$command_str" ;;
+      20) block "malformed or ambiguous heredoc command cannot be safely classified" ;;
+      *) block "heredoc parser failed; command was denied fail-closed" ;;
+    esac
+    ;;
+esac
+
+# 1. Recursive forced delete (`rm -rf`) of a filesystem root, home, or top-level
+#    wildcard. Two gates ANDed: the command must invoke `rm` with BOTH a
+#    recursive and a force flag, AND name a catastrophic target. Splitting the
+#    flag check from the target check keeps each regex legible and testable.
+if printf '%s' "$command_for_guards" \
+  | grep -Eiq '(^|[^[:alnum:]_./-])rm([[:space:]]+-[[:alnum:]-]+)*[[:space:]]+(-[[:alnum:]]*r[[:alnum:]]*f|-[[:alnum:]]*f[[:alnum:]]*r)([[:space:]]|$)' \
+  || printf '%s' "$command_for_guards" \
+  | grep -Eiq '(^|[^[:alnum:]_./-])rm[[:space:]].*(-r\b.*[[:space:]]-f\b|-f\b.*[[:space:]]-r\b|--recursive\b.*--force\b|--force\b.*--recursive\b)'; then
+  if printf '%s' "$command_for_guards" \
+    | grep -Eq '([[:space:]]|=)(/|/\*|/\.\*?|~|~/\*?|\$HOME\b|\$\{HOME\}|\*)([[:space:]]|/?\*?$)'; then
+    block "recursive forced delete of a root, home, or wildcard path (rm -rf)"
+  fi
+fi
+
+# 2. Force-pushing a protected branch. `--force-with-lease` is the safe,
+#    non-clobbering alternative and is intentionally NOT blocked.
+#
+#    The force flag AND the protected-branch name must appear in the SAME
+#    `git push` statement. Checking them independently over the whole command is
+#    a false-positive magnet: an unrelated `-f` (a `[ -f file ]` test, `rm -f`,
+#    `grep -f`, `tail -f`) plus an unrelated protected name (`--base main`,
+#    `origin/main`, `git fetch origin main`) alongside any feature-branch
+#    `git push` would wrongly block. So split the command into statements
+#    (`;`, `&&`, `||`, `|`, newlines), keep only the `git push` segments, and
+#    inspect each in isolation — a real `git push --force origin main` still
+#    matches, while a feature-branch push next to `[ -f ]`/`--base main` passes.
+# Normalize bash line-continuations (a trailing backslash + newline → space)
+# before segmenting the command. Without this, "git push --force origin
+# \<newline>main" splits into a segment matching --force but not `main`, letting a
+# protected force-push slip past. Uses awk (POSIX) instead of a GNU-only
+# `sed ':a;N;$!ba;…'`, which errors on BSD sed (macOS) and there silently no-ops.
+normalized_command_str="$(printf '%s' "$command_for_guards" \
+  | awk '{ if (sub(/\\$/, "")) printf "%s ", $0; else print }')"
+
+while IFS= read -r push_stmt; do
+  if printf '%s' "$push_stmt" \
+    | grep -Eiq '(--force([[:space:]]|=|$)|[[:space:]]-f([[:space:]]|$))' \
+    && ! printf '%s' "$push_stmt" | grep -Eiq -- '--force-with-lease' \
+    && printf '%s' "$push_stmt" \
+    | grep -Eiq '(^|[^[:alnum:]_/-])(main|master|production|prod|release)([^[:alnum:]_/-]|$)'; then
+    block "force-pushing a protected branch (use --force-with-lease, or push a feature branch)"
+  fi
+done < <(printf '%s' "$normalized_command_str" | tr '&|;' '\n' \
+  | grep -Ei '(^|[^[:alnum:]_-])git[[:space:]]+push\b')
+
+# 3. `git reset --hard` while the working tree has uncommitted changes — this
+#    silently discards them. Only blocks when the tree is actually dirty, so a
+#    clean-tree reset (a legitimate workflow) still passes.
+if printf '%s' "$command_for_guards" | grep -Eiq '(^|[^[:alnum:]_-])git[[:space:]]+reset\b.*--hard\b'; then
+  if git rev-parse --is-inside-work-tree >/dev/null 2>&1 \
+    && [ -n "$(git status --porcelain 2>/dev/null)" ]; then
+    block "git reset --hard on a dirty working tree would discard uncommitted changes (stash or commit first)"
+  fi
+fi
+
+# 4. Dropping or truncating a database / schema / table.
+if printf '%s' "$command_for_guards" \
+  | grep -Eiq '\b(drop[[:space:]]+(database|schema|table)|truncate[[:space:]]+(table[[:space:]]+)?[[:alnum:]_."`]+)\b'; then
+  block "destructive SQL (DROP/TRUNCATE) detected"
+fi
+
+# 5. Project-local custom rules. Each non-comment line is an ERE; a match blocks.
+rules_file="${SAFETY_NET_RULES_FILE:-${CLAUDE_PROJECT_DIR:-$PWD}/.claude/safety-net-rules.txt}"
+if [ -f "$rules_file" ]; then
+  while IFS= read -r rule || [ -n "$rule" ]; do
+    case "$rule" in
+      '' | '#'*) continue ;;
+    esac
+    if printf '%s' "$command_for_guards" | grep -Eiq -- "$rule"; then
+      block "matched a project custom safety rule (${rules_file##*/}): $rule"
+    fi
+  done <"$rules_file"
+fi
+
+exit 0

package/dist/opencode/support-file-resolver.d.ts

@@ -0,0 +1,8 @@
+/**
+ * Resolve an OpenCode support file in source checkouts and built packages.
+ * @param moduleUrl URL of the calling installer module.
+ * @param filename Canonical support-file basename.
+ * @returns Absolute path to the source or bundled copy.
+ */
+export declare function resolveSupportFile(moduleUrl: string, filename: string): string;
+//# sourceMappingURL=support-file-resolver.d.ts.map

package/dist/opencode/support-file-resolver.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"support-file-resolver.d.ts","sourceRoot":"","sources":["../../src/opencode/support-file-resolver.ts"],"names":[],"mappings":"AAGA;;;;;GAKG;AACH,wBAAgB,kBAAkB,CAChC,SAAS,EAAE,MAAM,EACjB,QAAQ,EAAE,MAAM,GACf,MAAM,CAcR"}

package/dist/opencode/support-file-resolver.js

@@ -0,0 +1,16 @@
+import * as path from "node:path";
+import { fileURLToPath } from "node:url";
+/**
+ * Resolve an OpenCode support file in source checkouts and built packages.
+ * @param moduleUrl URL of the calling installer module.
+ * @param filename Canonical support-file basename.
+ * @returns Absolute path to the source or bundled copy.
+ */
+export function resolveSupportFile(moduleUrl, filename) {
+    const moduleDir = path.dirname(fileURLToPath(moduleUrl));
+    const bundled = path.join(moduleDir, "plugin-templates", filename);
+    if (path.basename(path.dirname(moduleDir)) === "dist")
+        return bundled;
+    return path.resolve(moduleDir, "..", "..", "plugins", "src", "base", "hooks", filename);
+}
+//# sourceMappingURL=support-file-resolver.js.map

package/dist/opencode/support-file-resolver.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"support-file-resolver.js","sourceRoot":"","sources":["../../src/opencode/support-file-resolver.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,IAAI,MAAM,WAAW,CAAC;AAClC,OAAO,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AAEzC;;;;;GAKG;AACH,MAAM,UAAU,kBAAkB,CAChC,SAAiB,EACjB,QAAgB;IAEhB,MAAM,SAAS,GAAG,IAAI,CAAC,OAAO,CAAC,aAAa,CAAC,SAAS,CAAC,CAAC,CAAC;IACzD,MAAM,OAAO,GAAG,IAAI,CAAC,IAAI,CAAC,SAAS,EAAE,kBAAkB,EAAE,QAAQ,CAAC,CAAC;IACnE,IAAI,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC,KAAK,MAAM;QAAE,OAAO,OAAO,CAAC;IACtE,OAAO,IAAI,CAAC,OAAO,CACjB,SAAS,EACT,IAAI,EACJ,IAAI,EACJ,SAAS,EACT,KAAK,EACL,MAAM,EACN,OAAO,EACP,QAAQ,CACT,CAAC;AACJ,CAAC"}

package/package.json

@@ -102,7 +102,7 @@
     "form-data": ">=4.0.6"
   },
   "name": "@codyswann/lisa",
-  "version": "2.222.2",
+  "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.2",
+  "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.2",
+  "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`.