@codyswann/lisa 2.130.6 → 2.132.0

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

@@ -96,7 +96,14 @@ IF it is a Fix (bug), execute the Reproduce sub-flow FIRST:
    1. Write a simple API client and call the offending API
    2. Start the server on localhost and use the Playwright CLI or Chrome DevTools
 
-Using the general-purpose agent in Team Lead session, determine how you will know that the task is fully complete
+Using the general-purpose agent in Team Lead session, determine how you will know that the task is fully complete. Write this as an **effective completion condition** — one an independent verifier could confirm from observed output alone, not from your assertion that it works. A strong condition has:
+
+- **One measurable end state** — a status code, an exit code, a row count, an observable UI state, an empty queue. Not "it looks right" or "the code is correct".
+- **A stated proof command that surfaces the evidence** — exactly how the running system is exercised so the result is observable (e.g. `curl … returns 200 with {…}`, "the Playwright run reaches the dashboard", "`SELECT … ` returns the new row"). Quality gates (test/typecheck/lint) do NOT count — they are prerequisites.
+- **Constraints that must hold** — anything that must not change on the way there (e.g. "no other endpoint's response changes", "no migration is dropped").
+
+This condition is the contract the Verify flow proves and records in the verification verdict (below); it is what the completion gate checks before the flow may stop.
+
 1. Examples
    1. Direct deploy the changes to dev and then Write a simple API client and call the offending API
    2. Start the server on localhost and then Use the Playwright CLI or Chrome DevTools
@@ -116,8 +123,8 @@ Every task MUST include this JSON metadata block. Do NOT omit `skills` (use `[]`
   "learnings": ["..."],
   "verification": {
     "type": "ui-recording|api-test|cli-test|database-check|manual-check|documentation",
-    "command": "the proof command — must run the actual system (NOT test/typecheck/lint, those are quality gates)",
-    "expected": "what success looks like — observable system behavior"
+    "command": "the proof command — must run the actual system and surface its result in the transcript (NOT test/typecheck/lint, those are quality gates). Phrase it so an independent verifier sees the evidence, e.g. `curl -s localhost:3000/health` not `check that health works`",
+    "expected": "the single measurable end state that proves success — observable system behavior (status code, response body, row count, UI state), not a subjective judgement"
   }
 }
 ```
@@ -131,6 +138,22 @@ 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.
+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:
+
+    ```json
+    {
+      "plan": "<plan-name>",
+      "status": "pass | fail | blocked | in_progress",
+      "criteria": [
+        { "task": "<task id or title>", "criterion": "<the completion condition>", "status": "pass | fail", "evidence": "<the proof command run and the observed result>" }
+      ],
+      "updated_at": "<ISO8601 UTC>"
+    }
+    ```
+
+    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 (a readiness gate failed, a blocker was found, a dependency is unresolved), write the verdict with `status: "blocked"` and the reason: that records the outcome and releases the gate instead of leaving it to spin. Other harnesses fall back to this prose obligation.
 3. Write e2e test encoding the verification
 4. Record Implement usage on the originating work artifact via `lisa:usage-accounting` so the work item (or other implementation-owned artifact) gains a direct `implement` usage entry in the canonical `## Lisa Usage` section. If the parent / child graph is already known, prefer `record_and_rollup` so ancestor totals refresh in the same write; otherwise still write the direct entry, and if runtime usage is unavailable, use `source: unavailable` with nullable token/cost fields instead of skipping the row.
 5. Commit ALL outstanding changes in logical batches on the branch (minus sensitive data/information) — not just changes made by the agent team. This includes pre-existing uncommitted changes that were on the branch before the plan started. Do NOT filter commits to only "task-related" files. If it shows up in git status, it gets committed (unless it contains secrets).
@@ -140,6 +163,6 @@ Before shutting down the team, execute the Verify flow:
 9. Merge the PR
 10. Monitor the deploy action that triggers automatically from the successful merge
 11. If deploy fails, create a task for the agent team to fix the failure, open a new PR and then go back to step 7
-12. Remote verification: `verification-specialist` verifies in target environment (same checks as local verification, but on remote)
+12. Remote verification: `verification-specialist` verifies in target environment (same checks as local verification, but on remote), and refreshes the verdict (step 2a) to reflect the remote result.
 13. `ops-specialist`: post-deploy health check, monitor for errors in first minutes
-14. If remote verification fails, create a task for the agent team to find out why it failed, fix it and return to step 5 (repeat until you get all the way through)
+14. If remote verification fails, create a task for the agent team to find out why it failed, fix it and return to step 5. **Bound this loop**: after a small number of full fix→deploy→reverify cycles without reaching a passing remote verdict (treat ~3 as the ceiling unless the work item states otherwise), stop retrying — file a build-ready fix ticket, write the verdict with `status: "blocked"` and the diagnosis, and move the work item to blocked rather than looping indefinitely. The completion gate releases on a `blocked` verdict, so the flow ends with a recorded outcome instead of a silent spin or a self-declared success.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.130.6",
+  "version": "2.132.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.130.6",
+  "version": "2.132.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.130.6",
+  "version": "2.132.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.130.6",
+  "version": "2.132.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.130.6",
+  "version": "2.132.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,11 +1,22 @@
 {
   "name": "lisa",
-  "version": "2.130.6",
+  "version": "2.132.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"
   },
   "hooks": {
+    "userPromptSubmitted": [
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/enforce-verification-gate.sh"
+          }
+        ]
+      }
+    ],
     "preToolUse": [
       {
         "matcher": "Bash",
@@ -19,6 +30,26 @@
             "command": "${CLAUDE_PLUGIN_ROOT}/hooks/parity-safety-net.sh"
           }
         ]
+      },
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/enforce-verification-gate.sh"
+          }
+        ]
+      }
+    ],
+    "agentStop": [
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/enforce-verification-gate.sh"
+          }
+        ]
       }
     ],
     "sessionStart": [

package/plugins/lisa-copilot/hooks/block-no-verify.sh

@@ -1,11 +1,20 @@
 #!/usr/bin/env bash
-# PreToolUse hook for Bash: blocks any command containing --no-verify.
-# --no-verify on git commit/push (and equivalents) bypasses pre-commit/pre-push
-# hooks that exist for a reason. The fix is to address the underlying issue,
-# not silence the check. See feedback_never_no_verify in user memory.
+# PreToolUse hook for Bash: blocks commands that bypass git's verification hooks.
+# Bypassing pre-commit/pre-push hooks (which exist for a reason) is blocked in
+# all of its forms; the fix is to address the underlying issue, not silence the
+# check. See feedback_never_no_verify in user memory.
 #
-# Word-boundary match avoids false positives on flags like --no-verify-ssl,
-# --no-verify-host, etc.
+# Blocked bypass vectors:
+#   1. the --no-verify long flag (any subcommand, any position, incl. subshells);
+#   2. HUSKY=0 / HUSKY_SKIP_HOOKS=... — disables husky-managed git hooks;
+#   3. core.hooksPath pointed at /dev/null or set empty — disables ALL git hooks.
+#
+# Word-boundary matching avoids false positives on longer flags (--no-verify-ssl,
+# --no-verify-host) and on a legit custom hooks path (core.hooksPath=.husky).
+#
+# The short `-n` form is intentionally NOT matched (see block-no-verify.agy.sh):
+# grep cannot distinguish a real -n option from -n in commit-message prose or an
+# unrelated piped command, and -n is far more common than --no-verify.
 set -euo pipefail
 
 input="$(cat)"
@@ -20,13 +29,18 @@ if [ -z "$command_str" ]; then
   exit 0
 fi
 
-# Match --no-verify bounded by non-token characters (not alphanumeric, _, or -).
-# This catches all syntactic positions including subshells (e.g. `(git commit --no-verify)`)
-# while excluding longer flags like --no-verify-ssl, --no-verify-host, etc.
-if printf '%s' "$command_str" | grep -Eq '(^|[^[:alnum:]_-])--no-verify($|[^[:alnum:]_-])'; then
+# Each pattern is bounded by non-token characters so longer flags
+# (--no-verify-ssl) and legit values (core.hooksPath=.husky, HUSKY=1) don't match,
+# while every syntactic position is caught (incl. subshells, e.g. `(git commit --no-verify)`).
+if printf '%s' "$command_str" | grep -Eq '(^|[^[:alnum:]_-])--no-verify($|[^[:alnum:]_-])' \
+  || printf '%s' "$command_str" | grep -Eq '(^|[^[:alnum:]_-])HUSKY=0($|[^[:alnum:]])' \
+  || printf '%s' "$command_str" | grep -Eq '(^|[^[:alnum:]_-])HUSKY_SKIP_HOOKS=' \
+  || printf '%s' "$command_str" | grep -Eq 'core\.hooksPath([[:space:]]*=)?[[:space:]]*/dev/null' \
+  || printf '%s' "$command_str" | grep -Eq 'core\.hooksPath[[:space:]]*=[[:space:]]*($|[[:space:];&|"'\''])'; then
   cat >&2 <<'EOF'
-Blocked: --no-verify bypasses pre-commit/pre-push hooks. Fix the underlying
-issue (lint error, failing test, formatting) or ask the user before bypassing.
+Blocked: this command bypasses pre-commit/pre-push hooks (--no-verify, HUSKY=0,
+or core.hooksPath disabling). Fix the underlying issue (lint error, failing
+test, formatting) or ask the user before bypassing.
 
 If the user has explicitly authorized the bypass for this specific command,
 re-run after they confirm.

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

@@ -0,0 +1,222 @@
+#!/usr/bin/env bash
+# Enforces the /lisa:implement completion gate: the lead session may not stop
+# while an implement flow is active until an independent, machine-readable
+# verification verdict proves every acceptance criterion passed.
+#
+# This carries over the most valuable property of the native `/goal` primitive
+# (Claude Code v2.1.139, Codex 0.128.0): a NON-BYPASSABLE completion gate where
+# the agent doing the work cannot self-certify "done". Unlike `/goal`'s small
+# evaluator model — which only reads the transcript and cannot run tools — this
+# gate is deterministic and judges a structured artifact the
+# verification-specialist writes from REAL tool output, so it is both stronger
+# and not foolable by a prose claim of success.
+#
+# Intentionally Claude-specific (like enforce-team-first.sh). Other harnesses
+# may not fire a Stop hook; they fall back to the prose completion gate in
+# skills/implement/SKILL.md.
+#
+# Triggered on four hook events:
+#   - UserPromptSubmit : arm enforcement when the prompt starts with
+#                        /lisa:implement (or /implement)
+#   - PreToolUse       : arm enforcement when the Skill tool loads lisa:implement
+#                        (covers nested/programmatic invocation, e.g. intake)
+#   - SubagentStart    : mark teammate sessions exempt — teammates inherit the
+#                        lead's flow and must not be gated on their own stop
+#   - Stop             : block the lead stop unless a FRESH terminal verdict
+#                        (status pass|blocked, all criteria pass) exists, bounded
+#                        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":
+#   {
+#     "plan": "<plan-name>",
+#     "status": "pass" | "fail" | "blocked" | "in_progress",
+#     "criteria": [
+#       { "task": "...", "criterion": "...", "status": "pass" | "fail", "evidence": "..." }
+#     ],
+#     "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.
+#
+# 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.
+
+set -uo pipefail
+
+INPUT=$(cat 2>/dev/null || true)
+if [ -z "$INPUT" ]; then
+  exit 0
+fi
+
+HOOK_EVENT=$(printf '%s' "$INPUT" | jq -r '.hook_event_name // empty' 2>/dev/null || true)
+SESSION_ID=$(printf '%s' "$INPUT" | jq -r '.session_id // empty' 2>/dev/null || true)
+
+if [ -z "$SESSION_ID" ]; then
+  exit 0
+fi
+
+STATE_DIR="${TMPDIR:-/tmp}/lisa-verification-gate"
+mkdir -p "$STATE_DIR" 2>/dev/null || exit 0
+
+ARM_FLAG="${STATE_DIR}/${SESSION_ID}.armed"
+SUBAGENT_FLAG="${STATE_DIR}/${SESSION_ID}.subagent"
+COUNT_FILE="${STATE_DIR}/${SESSION_ID}.blocks"
+
+# Best-effort cleanup of stale state files. Errors are ignored.
+find "$STATE_DIR" -maxdepth 1 -type f -mmin +1440 -delete 2>/dev/null || true
+
+# How many consecutive blocks before the gate releases (with escalation) to
+# avoid an infinite stop loop. Mirrors /goal's "or stop after N turns" clause.
+MAX_BLOCKS=8
+
+arm_once() {
+  # Arm without bumping mtime if already armed — the arm time is the freshness
+  # baseline for the verdict, so re-arming on a later prompt must not make an
+  # already-written verdict look stale.
+  [ -f "$ARM_FLAG" ] || touch "$ARM_FLAG" 2>/dev/null || true
+}
+
+case "$HOOK_EVENT" in
+  SubagentStart)
+    touch "$SUBAGENT_FLAG" 2>/dev/null || true
+    exit 0
+    ;;
+
+  UserPromptSubmit)
+    PROMPT=$(printf '%s' "$INPUT" | jq -r '.prompt // empty' 2>/dev/null || true)
+    if [ -n "$PROMPT" ]; then
+      LEADING=$(printf '%s' "$PROMPT" | sed -n '1p' | sed -E 's/^[[:space:]]*//')
+      case "$LEADING" in
+        /lisa:implement*|/implement*)
+          arm_once
+          ;;
+      esac
+    fi
+    exit 0
+    ;;
+
+  PreToolUse)
+    TOOL_NAME=$(printf '%s' "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null || true)
+    if [ "$TOOL_NAME" = "Skill" ]; then
+      SKILL_NAME=$(printf '%s' "$INPUT" | jq -r '.tool_input.skill // empty' 2>/dev/null || true)
+      case "$SKILL_NAME" in
+        lisa:implement|implement)
+          arm_once
+          ;;
+      esac
+    fi
+    exit 0
+    ;;
+
+  Stop)
+    : # fall through to enforcement
+    ;;
+
+  *)
+    exit 0
+    ;;
+esac
+
+# --- Stop enforcement path ---
+
+# Teammates inherit the lead's flow; never gate a subagent stop.
+if [ -f "$SUBAGENT_FLAG" ]; then
+  exit 0
+fi
+
+# No implement flow armed — nothing to gate.
+if [ ! -f "$ARM_FLAG" ]; then
+  exit 0
+fi
+
+PROJECT_DIR="${CLAUDE_PROJECT_DIR:-.}"
+VERDICT_FILE="${PROJECT_DIR}/.lisa/verification-status.json"
+
+# A terminal verdict (pass or blocked) with no failing criterion, written AFTER
+# the flow was armed, releases the gate.
+verdict_is_terminal() {
+  [ -f "$VERDICT_FILE" ] || return 1
+
+  local status fails
+  status=$(jq -r '.status // empty' "$VERDICT_FILE" 2>/dev/null || true)
+  case "$status" in
+    pass|blocked) : ;;
+    *) return 1 ;;
+  esac
+
+  fails=$(jq -r '[.criteria[]? | select((.status // "") == "fail")] | length' "$VERDICT_FILE" 2>/dev/null || echo 1)
+  [ "$fails" = "0" ] || return 1
+
+  # Reject a stale verdict left over from a previous plan in this session.
+  if [ "$VERDICT_FILE" -ot "$ARM_FLAG" ]; then
+    return 1
+  fi
+
+  return 0
+}
+
+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.
+  rm -f "$ARM_FLAG" "$COUNT_FILE" 2>/dev/null || true
+  exit 0
+fi
+
+# Verdict missing, failing, or stale — block, but bound the loop.
+COUNT=$(cat "$COUNT_FILE" 2>/dev/null || echo 0)
+case "$COUNT" in
+  ''|*[!0-9]*) COUNT=0 ;;
+esac
+COUNT=$((COUNT + 1))
+echo "$COUNT" > "$COUNT_FILE" 2>/dev/null || true
+
+if [ "$COUNT" -gt "$MAX_BLOCKS" ]; then
+  rm -f "$ARM_FLAG" "$COUNT_FILE" 2>/dev/null || true
+  cat >&2 <<EOF
+Verification gate: still no passing verdict after ${MAX_BLOCKS} attempts.
+Releasing the stop gate to avoid an infinite loop. The /lisa:implement Verify
+flow did NOT prove completion. Do NOT claim this work is verified — escalate to
+a human, or file a build-ready fix ticket and move the work item to blocked.
+EOF
+  exit 0
+fi
+
+REASON_DETAIL=""
+if [ -f "$VERDICT_FILE" ]; then
+  REASON_DETAIL=$(jq -r '[.criteria[]? | select((.status // "") != "pass") | "  - \(.task // "?"): \(.criterion // "?") [\(.status // "missing")]"] | .[]' "$VERDICT_FILE" 2>/dev/null || true)
+fi
+
+{
+  echo "Blocked: /lisa:implement may not stop until verification is proven."
+  echo
+  if [ ! -f "$VERDICT_FILE" ]; then
+    echo "No verification verdict found at .lisa/verification-status.json."
+    echo "The Verify flow must run the verification-specialist (run the actual"
+    echo "system, observe results) and write a machine-readable verdict — schema"
+    echo "in skills/implement/SKILL.md — with status \"pass\" and every"
+    echo "acceptance criterion proven."
+    echo
+    echo "If you are stopping deliberately because of a blocker (readiness gate"
+    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."
+  else
+    echo "The verification verdict is not terminal-and-passing. Outstanding:"
+    if [ -n "$REASON_DETAIL" ]; then
+      printf '%s\n' "$REASON_DETAIL"
+    else
+      echo "  (status is not pass/blocked, or the verdict is older than this run)"
+    fi
+    echo
+    echo "Fix the failing criteria and re-verify, or — if genuinely blocked —"
+    echo "set status \"blocked\" with the reason."
+  fi
+  echo
+  echo "(Attempt ${COUNT}/${MAX_BLOCKS} — the gate releases after ${MAX_BLOCKS} to avoid a loop.)"
+} >&2
+exit 2

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

@@ -96,7 +96,14 @@ IF it is a Fix (bug), execute the Reproduce sub-flow FIRST:
    1. Write a simple API client and call the offending API
    2. Start the server on localhost and use the Playwright CLI or Chrome DevTools
 
-Using the general-purpose agent in Team Lead session, determine how you will know that the task is fully complete
+Using the general-purpose agent in Team Lead session, determine how you will know that the task is fully complete. Write this as an **effective completion condition** — one an independent verifier could confirm from observed output alone, not from your assertion that it works. A strong condition has:
+
+- **One measurable end state** — a status code, an exit code, a row count, an observable UI state, an empty queue. Not "it looks right" or "the code is correct".
+- **A stated proof command that surfaces the evidence** — exactly how the running system is exercised so the result is observable (e.g. `curl … returns 200 with {…}`, "the Playwright run reaches the dashboard", "`SELECT … ` returns the new row"). Quality gates (test/typecheck/lint) do NOT count — they are prerequisites.
+- **Constraints that must hold** — anything that must not change on the way there (e.g. "no other endpoint's response changes", "no migration is dropped").
+
+This condition is the contract the Verify flow proves and records in the verification verdict (below); it is what the completion gate checks before the flow may stop.
+
 1. Examples
    1. Direct deploy the changes to dev and then Write a simple API client and call the offending API
    2. Start the server on localhost and then Use the Playwright CLI or Chrome DevTools
@@ -116,8 +123,8 @@ Every task MUST include this JSON metadata block. Do NOT omit `skills` (use `[]`
   "learnings": ["..."],
   "verification": {
     "type": "ui-recording|api-test|cli-test|database-check|manual-check|documentation",
-    "command": "the proof command — must run the actual system (NOT test/typecheck/lint, those are quality gates)",
-    "expected": "what success looks like — observable system behavior"
+    "command": "the proof command — must run the actual system and surface its result in the transcript (NOT test/typecheck/lint, those are quality gates). Phrase it so an independent verifier sees the evidence, e.g. `curl -s localhost:3000/health` not `check that health works`",
+    "expected": "the single measurable end state that proves success — observable system behavior (status code, response body, row count, UI state), not a subjective judgement"
   }
 }
 ```
@@ -131,6 +138,22 @@ 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.
+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:
+
+    ```json
+    {
+      "plan": "<plan-name>",
+      "status": "pass | fail | blocked | in_progress",
+      "criteria": [
+        { "task": "<task id or title>", "criterion": "<the completion condition>", "status": "pass | fail", "evidence": "<the proof command run and the observed result>" }
+      ],
+      "updated_at": "<ISO8601 UTC>"
+    }
+    ```
+
+    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 (a readiness gate failed, a blocker was found, a dependency is unresolved), write the verdict with `status: "blocked"` and the reason: that records the outcome and releases the gate instead of leaving it to spin. Other harnesses fall back to this prose obligation.
 3. Write e2e test encoding the verification
 4. Record Implement usage on the originating work artifact via `lisa:usage-accounting` so the work item (or other implementation-owned artifact) gains a direct `implement` usage entry in the canonical `## Lisa Usage` section. If the parent / child graph is already known, prefer `record_and_rollup` so ancestor totals refresh in the same write; otherwise still write the direct entry, and if runtime usage is unavailable, use `source: unavailable` with nullable token/cost fields instead of skipping the row.
 5. Commit ALL outstanding changes in logical batches on the branch (minus sensitive data/information) — not just changes made by the agent team. This includes pre-existing uncommitted changes that were on the branch before the plan started. Do NOT filter commits to only "task-related" files. If it shows up in git status, it gets committed (unless it contains secrets).
@@ -140,6 +163,6 @@ Before shutting down the team, execute the Verify flow:
 9. Merge the PR
 10. Monitor the deploy action that triggers automatically from the successful merge
 11. If deploy fails, create a task for the agent team to fix the failure, open a new PR and then go back to step 7
-12. Remote verification: `verification-specialist` verifies in target environment (same checks as local verification, but on remote)
+12. Remote verification: `verification-specialist` verifies in target environment (same checks as local verification, but on remote), and refreshes the verdict (step 2a) to reflect the remote result.
 13. `ops-specialist`: post-deploy health check, monitor for errors in first minutes
-14. If remote verification fails, create a task for the agent team to find out why it failed, fix it and return to step 5 (repeat until you get all the way through)
+14. If remote verification fails, create a task for the agent team to find out why it failed, fix it and return to step 5. **Bound this loop**: after a small number of full fix→deploy→reverify cycles without reaching a passing remote verdict (treat ~3 as the ceiling unless the work item states otherwise), stop retrying — file a build-ready fix ticket, write the verdict with `status: "blocked"` and the diagnosis, and move the work item to blocked rather than looping indefinitely. The completion gate releases on a `blocked` verdict, so the flow ends with a recorded outcome instead of a silent spin or a self-declared success.

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

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

package/plugins/lisa-cursor/hooks/block-no-verify.sh

@@ -1,11 +1,20 @@
 #!/usr/bin/env bash
-# PreToolUse hook for Bash: blocks any command containing --no-verify.
-# --no-verify on git commit/push (and equivalents) bypasses pre-commit/pre-push
-# hooks that exist for a reason. The fix is to address the underlying issue,
-# not silence the check. See feedback_never_no_verify in user memory.
+# PreToolUse hook for Bash: blocks commands that bypass git's verification hooks.
+# Bypassing pre-commit/pre-push hooks (which exist for a reason) is blocked in
+# all of its forms; the fix is to address the underlying issue, not silence the
+# check. See feedback_never_no_verify in user memory.
 #
-# Word-boundary match avoids false positives on flags like --no-verify-ssl,
-# --no-verify-host, etc.
+# Blocked bypass vectors:
+#   1. the --no-verify long flag (any subcommand, any position, incl. subshells);
+#   2. HUSKY=0 / HUSKY_SKIP_HOOKS=... — disables husky-managed git hooks;
+#   3. core.hooksPath pointed at /dev/null or set empty — disables ALL git hooks.
+#
+# Word-boundary matching avoids false positives on longer flags (--no-verify-ssl,
+# --no-verify-host) and on a legit custom hooks path (core.hooksPath=.husky).
+#
+# The short `-n` form is intentionally NOT matched (see block-no-verify.agy.sh):
+# grep cannot distinguish a real -n option from -n in commit-message prose or an
+# unrelated piped command, and -n is far more common than --no-verify.
 set -euo pipefail
 
 input="$(cat)"
@@ -20,13 +29,18 @@ if [ -z "$command_str" ]; then
   exit 0
 fi
 
-# Match --no-verify bounded by non-token characters (not alphanumeric, _, or -).
-# This catches all syntactic positions including subshells (e.g. `(git commit --no-verify)`)
-# while excluding longer flags like --no-verify-ssl, --no-verify-host, etc.
-if printf '%s' "$command_str" | grep -Eq '(^|[^[:alnum:]_-])--no-verify($|[^[:alnum:]_-])'; then
+# Each pattern is bounded by non-token characters so longer flags
+# (--no-verify-ssl) and legit values (core.hooksPath=.husky, HUSKY=1) don't match,
+# while every syntactic position is caught (incl. subshells, e.g. `(git commit --no-verify)`).
+if printf '%s' "$command_str" | grep -Eq '(^|[^[:alnum:]_-])--no-verify($|[^[:alnum:]_-])' \
+  || printf '%s' "$command_str" | grep -Eq '(^|[^[:alnum:]_-])HUSKY=0($|[^[:alnum:]])' \
+  || printf '%s' "$command_str" | grep -Eq '(^|[^[:alnum:]_-])HUSKY_SKIP_HOOKS=' \
+  || printf '%s' "$command_str" | grep -Eq 'core\.hooksPath([[:space:]]*=)?[[:space:]]*/dev/null' \
+  || printf '%s' "$command_str" | grep -Eq 'core\.hooksPath[[:space:]]*=[[:space:]]*($|[[:space:];&|"'\''])'; then
   cat >&2 <<'EOF'
-Blocked: --no-verify bypasses pre-commit/pre-push hooks. Fix the underlying
-issue (lint error, failing test, formatting) or ask the user before bypassing.
+Blocked: this command bypasses pre-commit/pre-push hooks (--no-verify, HUSKY=0,
+or core.hooksPath disabling). Fix the underlying issue (lint error, failing
+test, formatting) or ask the user before bypassing.
 
 If the user has explicitly authorized the bypass for this specific command,
 re-run after they confirm.