@codyswann/lisa 2.261.0 → 2.262.0

package/package.json

@@ -105,7 +105,7 @@
     "form-data": ">=4.0.6"
   },
   "name": "@codyswann/lisa",
-  "version": "2.261.0",
+  "version": "2.262.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.261.0",
+  "version": "2.262.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.261.0",
+  "version": "2.262.0",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/skills/lisa-implement/SKILL.md

@@ -228,22 +228,52 @@ Before shutting down the team, execute the Verify flow:
 
 1. Run quality gates: lint, typecheck, tests — all must pass. These are prerequisites, NOT verification.
 2. `verification-specialist`: verify locally by running the actual system and observing results (empirical proof that the change works). This is the real verification step. For UI-surface bugs, the proof must observe the UI surface with browser/device automation against the target environment whenever such a harness exists; unit-level or API-only proof cannot satisfy the empirical verification contract for a UI-surface defect.
-2a. **Record the verification verdict** — the independent, machine-readable proof that gates completion. The `verification-specialist` writes `${CLAUDE_PROJECT_DIR:-.}/.lisa/verification-status.json` with one entry per acceptance criterion, each carrying the proof command's observed evidence:
+2a. **Record the verification verdict** — the independent, machine-readable proof that gates completion. The `verification-specialist` writes `${CLAUDE_PROJECT_DIR:-.}/.lisa/verification-status.json` in **schema v2**, which binds every claim to the *boundary* it asserts and to the evidence *kinds* that reach that boundary, per the `claim-evidence-mapping` rule:
 
     ```json
     {
+      "schema_version": 2,
       "plan": "<plan-name>",
-      "status": "pass | fail | blocked | in_progress",
+      "artifact": {
+        "repository": "<owner/repo>", "base_sha": "<sha>", "head_sha": "<sha of what will ship>",
+        "build_id": "<build/run id>", "environment": "<where it was observed>", "observed_at": "<ISO8601 UTC>"
+      },
+      "claims": [
+        {
+          "claim_id": "AC-1",
+          "statement": "<the claim, in the operator's language>",
+          "boundary": "code-unit | browser | http-api | cli | data | deploy-health | performance | standards-compat",
+          "required_for_gate": true,
+          "required_evidence_kinds": ["<kinds that reach this boundary, e.g. screenshot, recording>"],
+          "status": "established | not-established",
+          "evidence_refs": ["EV-1"],
+          "not_established": ["<what this claim does NOT cover>"]
+        }
+      ],
+      "evidence": [
+        {
+          "evidence_id": "EV-1",
+          "kind": "screenshot | recording | http-transcript | cli-output | log-snippet | db-query-output | perf-trace | test-run-log | deploy-log | state-dump",
+          "locator": "evidence/<ticket>/<file>", "sha256": "<hash>",
+          "captured_at": "<ISO8601 UTC>", "artifact_head_sha": "<sha the artifact was captured at>"
+        }
+      ],
+      "not_established_reviewed": true,
       "criteria": [
         { "task": "<task id or title>", "criterion": "<the completion condition>", "status": "pass | fail | blocked", "evidence": "<the proof command run and the observed result; for a blocked criterion, the blocker diagnosis (e.g. the missing access and the probe that must pass)>" }
       ],
+      "status": "pass | fail | blocked | in_progress",
       "updated_at": "<ISO8601 UTC>"
     }
     ```
 
+    Rules for v2: a claim is established **only** by evidence whose `kind` reaches its `boundary` — a unit `test-run-log` reaches only `code-unit` and can never establish a `browser`, `http-api`, or `deploy-health` claim. `not_established_reviewed` must always be present (the `not_established` list may be empty, but the flag may never be omitted). `artifact.head_sha` names what will ship, and each evidence entry's `artifact_head_sha` must match it. The legacy `criteria[]` array is retained and still read, but under v2 it is **display-only** — it can never establish a v2 claim.
+
+    **v1 is still accepted during the compatibility window.** A verdict that omits `schema_version` (or sets it to `1`) carries only `plan` / `status` / `criteria[]` / `updated_at` and is judged exactly as before: terminal `status` plus no failing criterion plus freshness. Write v2 for new work; nothing in flight breaks.
+
     Set `status: "pass"` only when every criterion is `pass` with real evidence (output from running the system, not a claim). The verdict must be judged by an agent that did NOT implement the change (the `verification-specialist`), never self-certified by the implementer. This is runtime scratch — it is gitignored and MUST NOT be committed (treat it like the secrets exclusion in the commit step).
 
-    On Claude, the `enforce-verification-gate.sh` Stop hook reads this file and **will not let the flow stop** until it shows a terminal, all-`pass` verdict — carrying over the non-bypassable completion gate of the `/goal` primitive, but checked deterministically against real evidence rather than by a transcript-only evaluator model. If you must stop before completion, write the verdict with `status: "blocked"` and the reason — marking each criterion whose proof is blocked as `status: "blocked"` with the blocker diagnosis as its `evidence`, while unaffected criteria keep their real `pass`/`fail` result — that records the outcome and releases the gate instead of leaving it to spin. But a `blocked` verdict is a last resort, not a shortcut around fillable work: **first resolve every gap you can resolve yourself.** If the work item is thin — missing its Validation Journey, acceptance criteria, or other derivable detail — enrich it: derive the missing detail from the ticket context and the codebase, write it back, and proceed. Do **not** block on a gap you could have filled. Only a blocker that survives that attempt is real, and it is one of two kinds:
+    On Claude, the `enforce-verification-gate.sh` Stop hook reads this file — both v1 and v2 — and **will not let the flow stop** until it shows a terminal, all-`pass` verdict. The v2 claim/evidence checks are **advisory-first**: a boundary or identity violation is reported to stderr but does not block until `verification.gate.enforceBoundaries` is set to `true` in `.lisa.config.json` (default `false`, promoted via the threshold ratchet). Treat an advisory warning as a defect to fix now, not a warning to ignore — it becomes blocking on the ratchet. The gate — carrying over the non-bypassable completion gate of the `/goal` primitive, but checked deterministically against real evidence rather than by a transcript-only evaluator model. If you must stop before completion, write the verdict with `status: "blocked"` and the reason — marking each criterion whose proof is blocked as `status: "blocked"` with the blocker diagnosis as its `evidence`, while unaffected criteria keep their real `pass`/`fail` result — that records the outcome and releases the gate instead of leaving it to spin. But a `blocked` verdict is a last resort, not a shortcut around fillable work: **first resolve every gap you can resolve yourself.** If the work item is thin — missing its Validation Journey, acceptance criteria, or other derivable detail — enrich it: derive the missing detail from the ticket context and the codebase, write it back, and proceed. Do **not** block on a gap you could have filled. Only a blocker that survives that attempt is real, and it is one of two kinds:
 
     - **Actionable blocker** — an unresolved dependency or fixable technical gap that some team or repository could build (a missing or changed schema field, an unbuilt sibling work item, a required upstream fix), **including cross-repo dependencies**. Before writing the blocked verdict you MUST (1) file a build-ready fix/dependency ticket capturing the diagnosis — in the dependency's own repository/tracker when it is cross-repo (e.g. a `[<repo>] …` ticket in the shared project, or the sibling tracker) — and (2) link the current work item to it as `is blocked by`. Only then write the verdict. This is the same discipline as the regression-spec blocker and the remote-verification-fail exits above, and it is what makes the block machine-recoverable: `repair-intake` re-dispatches a blocked item once its linked `is blocked by` dependency closes, but it cannot act on a prose-only comment. Recommending the ticket "as a human follow-up" without filing and linking it is **not** a permitted exit.
     - **Human-only blocker** — an input the agent genuinely cannot obtain or produce no matter what it does: credentials, secrets, or **tool access** it does not have (AWS/CloudWatch, Figma, Jam, Sentry, SonarCloud, a database, a protected deploy target, …), or a product/design decision only a human can make. For missing tool access, follow the `tool-access-gate` rule's break-out protocol: post the "Access Needed" comment naming the exact credential/role/env var to grant and the probe that must pass — never work around the gap by substituting weaker verification, mocking the inaccessible system, or narrowing scope. Record the blocked verdict, mark it `human_needed` (the marker `repair-intake` recognizes, so it won't churn re-dispatching it), and surface or reassign to a human; do **not** fabricate a build-ready ticket, because there is no build-ready work.

package/plugins/lisa/hooks/enforce-verification-gate.sh

@@ -27,7 +27,33 @@
 #                        by a per-session block counter so a genuinely-stuck flow
 #                        ESCALATES instead of looping forever.
 #
-# The verdict artifact lives at "$CLAUDE_PROJECT_DIR/.lisa/verification-status.json":
+# The verdict artifact lives at "$CLAUDE_PROJECT_DIR/.lisa/verification-status.json".
+#
+# SCHEMA v2 (current) binds every claim to a boundary and to the evidence kinds
+# that reach it, per the claim-evidence-mapping contract:
+#   {
+#     "schema_version": 2,
+#     "plan": "<plan-name>",
+#     "artifact": { "repository": "owner/repo", "base_sha": "...", "head_sha": "...",
+#                   "build_id": "...", "environment": "...", "observed_at": "<ISO8601 UTC>" },
+#     "claims": [
+#       { "claim_id": "AC-1", "statement": "...", "boundary": "browser",
+#         "required_for_gate": true, "required_evidence_kinds": ["screenshot","recording"],
+#         "status": "established" | "not-established", "evidence_refs": ["EV-1"],
+#         "not_established": ["<what this claim does NOT cover>"] }
+#     ],
+#     "evidence": [
+#       { "evidence_id": "EV-1", "kind": "screenshot", "locator": "evidence/1836/x.png",
+#         "sha256": "...", "captured_at": "<ISO8601 UTC>", "artifact_head_sha": "..." }
+#     ],
+#     "not_established_reviewed": true,
+#     "criteria": [ ... legacy, display-only ... ],
+#     "status": "pass" | "fail" | "blocked" | "in_progress",
+#     "updated_at": "<ISO8601 UTC>"
+#   }
+#
+# SCHEMA v1 (legacy, still accepted during the compatibility window) omits
+# "schema_version" or sets it to 1, and carries only:
 #   {
 #     "plan": "<plan-name>",
 #     "status": "pass" | "fail" | "blocked" | "in_progress",
@@ -36,15 +62,39 @@
 #     ],
 #     "updated_at": "<ISO8601 UTC>"
 #   }
-# status "pass" (all criteria pass) or "blocked" (flow recorded a blocker and is
-# stopping deliberately) are terminal and release the gate. "fail"/"in_progress"
-# or a missing/stale file keep it closed.
+#
+# In BOTH schemas, status "pass" (all criteria pass) or "blocked" (flow recorded
+# a blocker and is stopping deliberately) are terminal and release the gate.
+# "fail"/"in_progress" or a missing/stale file keep it closed.
+#
+# Compatibility window: the gate branches on "schema_version". Absent or 1 takes
+# the v1 path unchanged — byte-for-byte the pre-v2 decision. 2 takes the v1 path
+# PLUS the claim->evidence checks below. Legacy "criteria" is display-only under
+# v2 and can never establish a v2 claim.
+#
+# v2 claim checks (only ever applied to an overall "pass"; a deliberate
+# "blocked" stop is terminal on the v1 conditions alone):
+#   - every claim with "required_for_gate": true is "status": "established"
+#   - each such claim's "evidence_refs" resolve to "evidence[]" entries, at
+#     least one of whose "kind" is in the claim's "required_evidence_kinds"
+#   - "not_established_reviewed": true is present (the list may be empty, but
+#     the flag may never be omitted)
+#   - "artifact.head_sha" exists and no evidence entry declares a different
+#     "artifact_head_sha" (reconciliation with the MERGED head is BCE-4)
+#
+# ADVISORY-FIRST: those v2 checks report to stderr but do NOT block unless
+# "verification.gate.enforceBoundaries" is true in .lisa.config.json (default
+# false at ship, promoted via the threshold ratchet). While it is false, a v2
+# verdict releases on exactly the v1-equivalent conditions.
 #
 # Per-session state lives under "$STATE_DIR" as flag files keyed by session_id.
 # Stale state (>24h) is cleaned on each invocation.
 #
-# Fail-open: any unexpected jq parse failure or missing field exits 0 rather
-# than blocking. A broken gate must never brick a session.
+# Fail-open: any unexpected jq parse failure or missing field degrades to the
+# LESS strict outcome rather than inventing a new hard failure, and the
+# MAX_BLOCKS escalation below guarantees the gate always releases eventually. A
+# broken gate must never brick a session. In particular, a v2 verdict whose
+# claim structure cannot be evaluated is judged on the v1 conditions alone.
 
 set -uo pipefail
 
@@ -137,9 +187,14 @@ fi
 PROJECT_DIR="${CLAUDE_PROJECT_DIR:-.}"
 VERDICT_FILE="${PROJECT_DIR}/.lisa/verification-status.json"
 
+# Set by the v2 path when a claim/evidence violation is what closed the gate,
+# so the block message can state the real reason instead of the v1 fallback.
+V2_BLOCK_REASON=""
+
 # A terminal verdict (pass or blocked) with no failing criterion, written AFTER
-# the flow was armed, releases the gate.
-verdict_is_terminal() {
+# the flow was armed, releases the gate. This is the v1 decision, unchanged, and
+# it remains the floor for v2 as well.
+verdict_is_terminal_v1() {
   [ -f "$VERDICT_FILE" ] || return 1
 
   local status fails
@@ -160,6 +215,101 @@ verdict_is_terminal() {
   return 0
 }
 
+# True when the project has ratcheted the v2 claim checks from advisory to
+# blocking. Default false: a missing/unreadable config is advisory-only.
+boundary_enforcement_enabled() {
+  local config_file value
+  config_file="${PROJECT_DIR}/.lisa.config.json"
+  [ -f "$config_file" ] || return 1
+  value=$(jq -r '.verification.gate.enforceBoundaries // false' "$config_file" 2>/dev/null || printf 'false')
+  [ "$value" = "true" ]
+}
+
+# Emits one line per v2 claim->evidence contract violation. Empty output means
+# the verdict satisfies the contract (or could not be evaluated, which degrades
+# to the v1 decision rather than to a new hard failure).
+v2_contract_violations() {
+  jq -r '
+    . as $v
+    | ($v.evidence // []) as $ev
+    | (($v.artifact // {}).head_sha // "") as $head
+    | [
+        (if ($v.not_established_reviewed == true) then empty
+         else "not_established_reviewed is absent or not true - the flag may never be omitted" end),
+        (if ($head | length) > 0 then empty
+         else "artifact.head_sha is missing - required for a v2 pass" end),
+        ( $ev[]
+          | select(($head | length) > 0)
+          | select(((.artifact_head_sha // "") | length) > 0)
+          | select(.artifact_head_sha != $head)
+          | "evidence \(.evidence_id // "?") was captured at \(.artifact_head_sha) but artifact.head_sha is \($head)" ),
+        ( ($v.claims // [])[]
+          | select((.required_for_gate // false) == true)
+          | . as $c
+          | ($c.claim_id // "?") as $cid
+          | ($c.boundary // "?") as $bnd
+          | ($c.required_evidence_kinds // []) as $req
+          | ($req | join(", ")) as $reqs
+          | ([ ($c.evidence_refs // [])[] as $r | $ev[] | select((.evidence_id // "") == $r) ]) as $res
+          | (
+              (if (($c.status // "") == "established") then empty
+               else "claim \($cid) [boundary \($bnd)] is not established (status: \($c.status // "missing"); required kinds: \($reqs))" end),
+              (if ($res | length) == 0
+               then "claim \($cid) [boundary \($bnd)] cites no resolvable evidence (required kinds: \($reqs))"
+               elif ([ $res[].kind // "" ] | map(select(. as $k | $req | index($k))) | length) == 0
+               then "claim \($cid) [boundary \($bnd)] cited evidence kinds [\([$res[].kind // "?"] | join(", "))] do not reach the boundary (required kinds: \($reqs))"
+               else empty end)
+            )
+        )
+      ]
+    | .[]
+  ' "$VERDICT_FILE" 2>/dev/null || true
+}
+
+# v2 = the v1 decision PLUS the claim->evidence contract, the latter advisory
+# until verification.gate.enforceBoundaries is ratcheted on.
+verdict_is_terminal_v2() {
+  verdict_is_terminal_v1 || return 1
+
+  # Only a "pass" asserts that claims are established. A deliberate "blocked"
+  # stop records an outcome and is terminal on the v1 conditions alone.
+  local status violations
+  status=$(jq -r '.status // empty' "$VERDICT_FILE" 2>/dev/null || true)
+  [ "$status" = "pass" ] || return 0
+
+  violations=$(v2_contract_violations)
+  [ -n "$violations" ] || return 0
+
+  if boundary_enforcement_enabled; then
+    # Hand the diagnosis to the block message below so the operator reads one
+    # coherent reason instead of this plus a generic v1-shaped fallback.
+    V2_BLOCK_REASON=$(printf '%s\n' "$violations" | sed 's/^/  - /')
+    return 1
+  fi
+
+  {
+    echo "Verification gate (advisory): the v2 claim/evidence contract is not"
+    echo "satisfied. Releasing anyway because verification.gate.enforceBoundaries"
+    echo "is false. These become blocking when the flag is ratcheted on:"
+    printf '%s\n' "$violations" | sed 's/^/  - /'
+  } >&2
+  return 0
+}
+
+# Compatibility window: branch on schema_version. Absent or 1 -> the v1 decision
+# unchanged; 2 -> v1 plus the claim->evidence contract. An unrecognized or
+# unparseable value degrades to v1 rather than to a new failure mode.
+verdict_is_terminal() {
+  [ -f "$VERDICT_FILE" ] || return 1
+
+  local schema_version
+  schema_version=$(jq -r '.schema_version // empty' "$VERDICT_FILE" 2>/dev/null || true)
+  case "$schema_version" in
+    2) verdict_is_terminal_v2 ;;
+    *) verdict_is_terminal_v1 ;;
+  esac
+}
+
 if verdict_is_terminal; then
   # Gate satisfied — disarm so a follow-up stop in the same session is not
   # re-gated against the now-consumed verdict, and allow the stop.
@@ -205,6 +355,16 @@ fi
     echo "failed, base branch missing, unresolved dependency), write the verdict"
     echo "with status \"blocked\" and the reason instead. That records the"
     echo "outcome and releases this gate."
+  elif [ -n "$V2_BLOCK_REASON" ]; then
+    echo "The verdict claims to pass, but its evidence does not establish every"
+    echo "claim the gate requires:"
+    printf '%s\n' "$V2_BLOCK_REASON"
+    echo
+    echo "A claim counts only when the evidence cited for it is of a kind that"
+    echo "reaches that claim's boundary — a unit test log does not prove a"
+    echo "button works in a browser. Capture the reaching evidence and"
+    echo "re-verify, or — if genuinely blocked — set status \"blocked\" with the"
+    echo "reason."
   else
     echo "The verification verdict is not terminal-and-passing. Outstanding:"
     if [ -n "$REASON_DETAIL" ]; then

package/plugins/lisa/skills/lisa-implement/SKILL.md

@@ -228,22 +228,52 @@ Before shutting down the team, execute the Verify flow:
 
 1. Run quality gates: lint, typecheck, tests — all must pass. These are prerequisites, NOT verification.
 2. `verification-specialist`: verify locally by running the actual system and observing results (empirical proof that the change works). This is the real verification step. For UI-surface bugs, the proof must observe the UI surface with browser/device automation against the target environment whenever such a harness exists; unit-level or API-only proof cannot satisfy the empirical verification contract for a UI-surface defect.
-2a. **Record the verification verdict** — the independent, machine-readable proof that gates completion. The `verification-specialist` writes `${CLAUDE_PROJECT_DIR:-.}/.lisa/verification-status.json` with one entry per acceptance criterion, each carrying the proof command's observed evidence:
+2a. **Record the verification verdict** — the independent, machine-readable proof that gates completion. The `verification-specialist` writes `${CLAUDE_PROJECT_DIR:-.}/.lisa/verification-status.json` in **schema v2**, which binds every claim to the *boundary* it asserts and to the evidence *kinds* that reach that boundary, per the `claim-evidence-mapping` rule:
 
     ```json
     {
+      "schema_version": 2,
       "plan": "<plan-name>",
-      "status": "pass | fail | blocked | in_progress",
+      "artifact": {
+        "repository": "<owner/repo>", "base_sha": "<sha>", "head_sha": "<sha of what will ship>",
+        "build_id": "<build/run id>", "environment": "<where it was observed>", "observed_at": "<ISO8601 UTC>"
+      },
+      "claims": [
+        {
+          "claim_id": "AC-1",
+          "statement": "<the claim, in the operator's language>",
+          "boundary": "code-unit | browser | http-api | cli | data | deploy-health | performance | standards-compat",
+          "required_for_gate": true,
+          "required_evidence_kinds": ["<kinds that reach this boundary, e.g. screenshot, recording>"],
+          "status": "established | not-established",
+          "evidence_refs": ["EV-1"],
+          "not_established": ["<what this claim does NOT cover>"]
+        }
+      ],
+      "evidence": [
+        {
+          "evidence_id": "EV-1",
+          "kind": "screenshot | recording | http-transcript | cli-output | log-snippet | db-query-output | perf-trace | test-run-log | deploy-log | state-dump",
+          "locator": "evidence/<ticket>/<file>", "sha256": "<hash>",
+          "captured_at": "<ISO8601 UTC>", "artifact_head_sha": "<sha the artifact was captured at>"
+        }
+      ],
+      "not_established_reviewed": true,
       "criteria": [
         { "task": "<task id or title>", "criterion": "<the completion condition>", "status": "pass | fail | blocked", "evidence": "<the proof command run and the observed result; for a blocked criterion, the blocker diagnosis (e.g. the missing access and the probe that must pass)>" }
       ],
+      "status": "pass | fail | blocked | in_progress",
       "updated_at": "<ISO8601 UTC>"
     }
     ```
 
+    Rules for v2: a claim is established **only** by evidence whose `kind` reaches its `boundary` — a unit `test-run-log` reaches only `code-unit` and can never establish a `browser`, `http-api`, or `deploy-health` claim. `not_established_reviewed` must always be present (the `not_established` list may be empty, but the flag may never be omitted). `artifact.head_sha` names what will ship, and each evidence entry's `artifact_head_sha` must match it. The legacy `criteria[]` array is retained and still read, but under v2 it is **display-only** — it can never establish a v2 claim.
+
+    **v1 is still accepted during the compatibility window.** A verdict that omits `schema_version` (or sets it to `1`) carries only `plan` / `status` / `criteria[]` / `updated_at` and is judged exactly as before: terminal `status` plus no failing criterion plus freshness. Write v2 for new work; nothing in flight breaks.
+
     Set `status: "pass"` only when every criterion is `pass` with real evidence (output from running the system, not a claim). The verdict must be judged by an agent that did NOT implement the change (the `verification-specialist`), never self-certified by the implementer. This is runtime scratch — it is gitignored and MUST NOT be committed (treat it like the secrets exclusion in the commit step).
 
-    On Claude, the `enforce-verification-gate.sh` Stop hook reads this file and **will not let the flow stop** until it shows a terminal, all-`pass` verdict — carrying over the non-bypassable completion gate of the `/goal` primitive, but checked deterministically against real evidence rather than by a transcript-only evaluator model. If you must stop before completion, write the verdict with `status: "blocked"` and the reason — marking each criterion whose proof is blocked as `status: "blocked"` with the blocker diagnosis as its `evidence`, while unaffected criteria keep their real `pass`/`fail` result — that records the outcome and releases the gate instead of leaving it to spin. But a `blocked` verdict is a last resort, not a shortcut around fillable work: **first resolve every gap you can resolve yourself.** If the work item is thin — missing its Validation Journey, acceptance criteria, or other derivable detail — enrich it: derive the missing detail from the ticket context and the codebase, write it back, and proceed. Do **not** block on a gap you could have filled. Only a blocker that survives that attempt is real, and it is one of two kinds:
+    On Claude, the `enforce-verification-gate.sh` Stop hook reads this file — both v1 and v2 — and **will not let the flow stop** until it shows a terminal, all-`pass` verdict. The v2 claim/evidence checks are **advisory-first**: a boundary or identity violation is reported to stderr but does not block until `verification.gate.enforceBoundaries` is set to `true` in `.lisa.config.json` (default `false`, promoted via the threshold ratchet). Treat an advisory warning as a defect to fix now, not a warning to ignore — it becomes blocking on the ratchet. The gate — carrying over the non-bypassable completion gate of the `/goal` primitive, but checked deterministically against real evidence rather than by a transcript-only evaluator model. If you must stop before completion, write the verdict with `status: "blocked"` and the reason — marking each criterion whose proof is blocked as `status: "blocked"` with the blocker diagnosis as its `evidence`, while unaffected criteria keep their real `pass`/`fail` result — that records the outcome and releases the gate instead of leaving it to spin. But a `blocked` verdict is a last resort, not a shortcut around fillable work: **first resolve every gap you can resolve yourself.** If the work item is thin — missing its Validation Journey, acceptance criteria, or other derivable detail — enrich it: derive the missing detail from the ticket context and the codebase, write it back, and proceed. Do **not** block on a gap you could have filled. Only a blocker that survives that attempt is real, and it is one of two kinds:
 
     - **Actionable blocker** — an unresolved dependency or fixable technical gap that some team or repository could build (a missing or changed schema field, an unbuilt sibling work item, a required upstream fix), **including cross-repo dependencies**. Before writing the blocked verdict you MUST (1) file a build-ready fix/dependency ticket capturing the diagnosis — in the dependency's own repository/tracker when it is cross-repo (e.g. a `[<repo>] …` ticket in the shared project, or the sibling tracker) — and (2) link the current work item to it as `is blocked by`. Only then write the verdict. This is the same discipline as the regression-spec blocker and the remote-verification-fail exits above, and it is what makes the block machine-recoverable: `repair-intake` re-dispatches a blocked item once its linked `is blocked by` dependency closes, but it cannot act on a prose-only comment. Recommending the ticket "as a human follow-up" without filing and linking it is **not** a permitted exit.
     - **Human-only blocker** — an input the agent genuinely cannot obtain or produce no matter what it does: credentials, secrets, or **tool access** it does not have (AWS/CloudWatch, Figma, Jam, Sentry, SonarCloud, a database, a protected deploy target, …), or a product/design decision only a human can make. For missing tool access, follow the `tool-access-gate` rule's break-out protocol: post the "Access Needed" comment naming the exact credential/role/env var to grant and the probe that must pass — never work around the gap by substituting weaker verification, mocking the inaccessible system, or narrowing scope. Record the blocked verdict, mark it `human_needed` (the marker `repair-intake` recognizes, so it won't churn re-dispatching it), and surface or reassign to a human; do **not** fabricate a build-ready ticket, because there is no build-ready work.

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-implement/SKILL.md

@@ -228,22 +228,52 @@ Before shutting down the team, execute the Verify flow:
 
 1. Run quality gates: lint, typecheck, tests — all must pass. These are prerequisites, NOT verification.
 2. `verification-specialist`: verify locally by running the actual system and observing results (empirical proof that the change works). This is the real verification step. For UI-surface bugs, the proof must observe the UI surface with browser/device automation against the target environment whenever such a harness exists; unit-level or API-only proof cannot satisfy the empirical verification contract for a UI-surface defect.
-2a. **Record the verification verdict** — the independent, machine-readable proof that gates completion. The `verification-specialist` writes `${CLAUDE_PROJECT_DIR:-.}/.lisa/verification-status.json` with one entry per acceptance criterion, each carrying the proof command's observed evidence:
+2a. **Record the verification verdict** — the independent, machine-readable proof that gates completion. The `verification-specialist` writes `${CLAUDE_PROJECT_DIR:-.}/.lisa/verification-status.json` in **schema v2**, which binds every claim to the *boundary* it asserts and to the evidence *kinds* that reach that boundary, per the `claim-evidence-mapping` rule:
 
     ```json
     {
+      "schema_version": 2,
       "plan": "<plan-name>",
-      "status": "pass | fail | blocked | in_progress",
+      "artifact": {
+        "repository": "<owner/repo>", "base_sha": "<sha>", "head_sha": "<sha of what will ship>",
+        "build_id": "<build/run id>", "environment": "<where it was observed>", "observed_at": "<ISO8601 UTC>"
+      },
+      "claims": [
+        {
+          "claim_id": "AC-1",
+          "statement": "<the claim, in the operator's language>",
+          "boundary": "code-unit | browser | http-api | cli | data | deploy-health | performance | standards-compat",
+          "required_for_gate": true,
+          "required_evidence_kinds": ["<kinds that reach this boundary, e.g. screenshot, recording>"],
+          "status": "established | not-established",
+          "evidence_refs": ["EV-1"],
+          "not_established": ["<what this claim does NOT cover>"]
+        }
+      ],
+      "evidence": [
+        {
+          "evidence_id": "EV-1",
+          "kind": "screenshot | recording | http-transcript | cli-output | log-snippet | db-query-output | perf-trace | test-run-log | deploy-log | state-dump",
+          "locator": "evidence/<ticket>/<file>", "sha256": "<hash>",
+          "captured_at": "<ISO8601 UTC>", "artifact_head_sha": "<sha the artifact was captured at>"
+        }
+      ],
+      "not_established_reviewed": true,
       "criteria": [
         { "task": "<task id or title>", "criterion": "<the completion condition>", "status": "pass | fail | blocked", "evidence": "<the proof command run and the observed result; for a blocked criterion, the blocker diagnosis (e.g. the missing access and the probe that must pass)>" }
       ],
+      "status": "pass | fail | blocked | in_progress",
       "updated_at": "<ISO8601 UTC>"
     }
     ```
 
+    Rules for v2: a claim is established **only** by evidence whose `kind` reaches its `boundary` — a unit `test-run-log` reaches only `code-unit` and can never establish a `browser`, `http-api`, or `deploy-health` claim. `not_established_reviewed` must always be present (the `not_established` list may be empty, but the flag may never be omitted). `artifact.head_sha` names what will ship, and each evidence entry's `artifact_head_sha` must match it. The legacy `criteria[]` array is retained and still read, but under v2 it is **display-only** — it can never establish a v2 claim.
+
+    **v1 is still accepted during the compatibility window.** A verdict that omits `schema_version` (or sets it to `1`) carries only `plan` / `status` / `criteria[]` / `updated_at` and is judged exactly as before: terminal `status` plus no failing criterion plus freshness. Write v2 for new work; nothing in flight breaks.
+
     Set `status: "pass"` only when every criterion is `pass` with real evidence (output from running the system, not a claim). The verdict must be judged by an agent that did NOT implement the change (the `verification-specialist`), never self-certified by the implementer. This is runtime scratch — it is gitignored and MUST NOT be committed (treat it like the secrets exclusion in the commit step).
 
-    On Claude, the `enforce-verification-gate.sh` Stop hook reads this file and **will not let the flow stop** until it shows a terminal, all-`pass` verdict — carrying over the non-bypassable completion gate of the `/goal` primitive, but checked deterministically against real evidence rather than by a transcript-only evaluator model. If you must stop before completion, write the verdict with `status: "blocked"` and the reason — marking each criterion whose proof is blocked as `status: "blocked"` with the blocker diagnosis as its `evidence`, while unaffected criteria keep their real `pass`/`fail` result — that records the outcome and releases the gate instead of leaving it to spin. But a `blocked` verdict is a last resort, not a shortcut around fillable work: **first resolve every gap you can resolve yourself.** If the work item is thin — missing its Validation Journey, acceptance criteria, or other derivable detail — enrich it: derive the missing detail from the ticket context and the codebase, write it back, and proceed. Do **not** block on a gap you could have filled. Only a blocker that survives that attempt is real, and it is one of two kinds:
+    On Claude, the `enforce-verification-gate.sh` Stop hook reads this file — both v1 and v2 — and **will not let the flow stop** until it shows a terminal, all-`pass` verdict. The v2 claim/evidence checks are **advisory-first**: a boundary or identity violation is reported to stderr but does not block until `verification.gate.enforceBoundaries` is set to `true` in `.lisa.config.json` (default `false`, promoted via the threshold ratchet). Treat an advisory warning as a defect to fix now, not a warning to ignore — it becomes blocking on the ratchet. The gate — carrying over the non-bypassable completion gate of the `/goal` primitive, but checked deterministically against real evidence rather than by a transcript-only evaluator model. If you must stop before completion, write the verdict with `status: "blocked"` and the reason — marking each criterion whose proof is blocked as `status: "blocked"` with the blocker diagnosis as its `evidence`, while unaffected criteria keep their real `pass`/`fail` result — that records the outcome and releases the gate instead of leaving it to spin. But a `blocked` verdict is a last resort, not a shortcut around fillable work: **first resolve every gap you can resolve yourself.** If the work item is thin — missing its Validation Journey, acceptance criteria, or other derivable detail — enrich it: derive the missing detail from the ticket context and the codebase, write it back, and proceed. Do **not** block on a gap you could have filled. Only a blocker that survives that attempt is real, and it is one of two kinds:
 
     - **Actionable blocker** — an unresolved dependency or fixable technical gap that some team or repository could build (a missing or changed schema field, an unbuilt sibling work item, a required upstream fix), **including cross-repo dependencies**. Before writing the blocked verdict you MUST (1) file a build-ready fix/dependency ticket capturing the diagnosis — in the dependency's own repository/tracker when it is cross-repo (e.g. a `[<repo>] …` ticket in the shared project, or the sibling tracker) — and (2) link the current work item to it as `is blocked by`. Only then write the verdict. This is the same discipline as the regression-spec blocker and the remote-verification-fail exits above, and it is what makes the block machine-recoverable: `repair-intake` re-dispatches a blocked item once its linked `is blocked by` dependency closes, but it cannot act on a prose-only comment. Recommending the ticket "as a human follow-up" without filing and linking it is **not** a permitted exit.
     - **Human-only blocker** — an input the agent genuinely cannot obtain or produce no matter what it does: credentials, secrets, or **tool access** it does not have (AWS/CloudWatch, Figma, Jam, Sentry, SonarCloud, a database, a protected deploy target, …), or a product/design decision only a human can make. For missing tool access, follow the `tool-access-gate` rule's break-out protocol: post the "Access Needed" comment naming the exact credential/role/env var to grant and the probe that must pass — never work around the gap by substituting weaker verification, mocking the inaccessible system, or narrowing scope. Record the blocked verdict, mark it `human_needed` (the marker `repair-intake` recognizes, so it won't churn re-dispatching it), and surface or reassign to a human; do **not** fabricate a build-ready ticket, because there is no build-ready work.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.261.0",
+  "version": "2.262.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.261.0",
+  "version": "2.262.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.261.0",
+  "version": "2.262.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.261.0",
+  "version": "2.262.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.261.0",
+  "version": "2.262.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.261.0",
+  "version": "2.262.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"