@codyswann/lisa 4.74.9 → 4.75.1

package/plugins/lisa-harper-fabric-devin/skills/harper-testing/SKILL.md

@@ -0,0 +1,254 @@
+---
+name: harper-testing
+description: This skill should be used when adding, repairing, or designing tests for a Harper (HarperDB/Fabric) component app — Vitest unit tests for pure functions and Resource methods, local Harper integration tests that boot/symlink/seed/assert real endpoints, Playwright e2e tests against REST/GraphQL routes, and schema/verify-script coupling. Use it when a Harper app needs its first test suite, endpoint coverage, seed isolation, or a local smoke/verify path. Pairs with harper-build-and-deploy, harper-schema-graphql, and e2e-coverage-gaps.
+---
+
+# Harper Testing
+
+## Overview
+
+Test Harper apps at the layer that proves the risk:
+
+1. **Pure unit tests** for TypeScript helpers and data transforms.
+2. **Resource unit tests** for `Resource` methods with mocked Harper runtime globals.
+3. **Integration tests** against a running local Harper component with real schema,
+   resources, seed data, and REST/GraphQL responses.
+4. **Playwright e2e tests** against the same HTTP surface a user or client calls.
+
+Harper application source lives in TypeScript under `src/`; deployable
+`harper-app/resources.js`, `harper-app/resource-*.js`, and `harper-app/web/**` are
+generated. Build before integration or e2e tests so the runtime loads the code you
+just changed. See [[harper-build-and-deploy]].
+
+## Test pyramid
+
+| Layer | Tool | Use when | Avoid |
+| --- | --- | --- | --- |
+| Pure unit | Vitest | Validating transforms, validators, serializers, query builders, and other code with no Harper runtime dependency. | Mocking HTTP or tables for logic that can stay pure. |
+| Resource unit | Vitest | Exercising `get`, `post`, `search`, `patch`, or permission/error logic in a resource class without booting Harper. | Treating mocked tables as proof that `config.yaml`, `schema.graphql`, or REST exposure works. |
+| Integration | Vitest or shell smoke | Proving Harper boots, schema loads, `jsResource` registers code, data seeds, and endpoints respond. | Replacing this with resource mocks after config, schema, or generated artifact changes. |
+| E2E | Playwright | Verifying client-observable REST/GraphQL behavior, auth states, error paths, and browser workflows. | Re-testing every pure branch through the browser. |
+
+Use [[e2e-coverage-gaps]] after a suite exists to find missing routes and
+non-happy paths. Use this skill when creating or repairing the test patterns
+themselves.
+
+## Pure unit tests
+
+Keep business transforms importable without Harper globals:
+
+```typescript
+import { describe, expect, it } from 'vitest';
+import { normalizePetName } from '../src/pets/normalize';
+
+describe('normalizePetName', () => {
+  it('trims and title-cases names', () => {
+    expect(normalizePetName('  ada LOVELACE ')).toBe('Ada Lovelace');
+  });
+});
+```
+
+If a resource method contains complex transformation logic, extract the pure part
+and test it directly. Leave a thinner resource test for runtime wiring,
+authorization, and persistence behavior.
+
+## Resource unit tests
+
+Harper injects runtime globals such as `Resource` and `tables` when it loads
+`resources.js`. Unit tests do not get those globals automatically. Test resource
+methods by importing code through a seam that accepts mocks, or by setting the
+minimal globals before importing the resource module.
+
+Prefer dependency injection for new code:
+
+```typescript
+import { describe, expect, it, vi } from 'vitest';
+import { createPetsResource } from '../src/resources/pets';
+
+describe('PetsResource.get', () => {
+  it('adds adoption status from the table record', async () => {
+    const table = {
+      get: vi.fn(async () => ({ id: 'pet-1', name: 'Mina', adoptedAt: null })),
+    };
+    const Pets = createPetsResource({ Resource: class {}, table });
+
+    await expect(Pets.get({ id: 'pet-1' })).resolves.toMatchObject({
+      id: 'pet-1',
+      name: 'Mina',
+      adoptionStatus: 'available',
+    });
+    expect(table.get).toHaveBeenCalledWith({ id: 'pet-1' });
+  });
+});
+```
+
+When existing code must extend `tables.X` directly, isolate the runtime globals in
+a test helper and import the module after setup:
+
+```typescript
+import { beforeEach, describe, expect, it, vi } from 'vitest';
+
+describe('Pets resource', () => {
+  beforeEach(() => {
+    vi.resetModules();
+    vi.stubGlobal('Resource', class {});
+    vi.stubGlobal('tables', {
+      Pets: class {
+        static async get(target: { id: string }) {
+          return { id: target.id, name: 'Mina' };
+        }
+      },
+    });
+  });
+
+  it('wraps the runtime table', async () => {
+    const { Pets } = await import('../src/resources/pets');
+    await expect(Pets.get({ id: 'pet-1' })).resolves.toMatchObject({
+      id: 'pet-1',
+      name: 'Mina',
+    });
+  });
+});
+```
+
+Keep mocks narrow. Mock only the table methods, `Resource` base behavior,
+`server.resources`, or external fetch calls the method actually uses. If the test
+starts recreating Harper's schema, REST routing, or auth behavior, move it to an
+integration test.
+
+## Integration tests with local Harper
+
+Use integration tests to prove the component runs as Harper will load it:
+
+1. Install dependencies and build TypeScript: `bun install --frozen-lockfile`
+   when needed, then `bun run build`.
+2. Start a local Harper process against the component, usually
+   `harper dev harper-app` for watch mode or `harper run harper-app` for a
+   one-shot test process. Use the project's wrapper command when present.
+3. If the test lives outside the app repo, symlink the built component into
+   Harper's component directory rather than copying generated artifacts by hand.
+   Clean the symlink in teardown.
+4. Seed data through `dataLoader` fixtures when the project owns static fixtures,
+   or through REST/Operations API calls when each test needs dynamic setup.
+5. Assert the real REST/GraphQL endpoint and response body.
+6. Stop Harper and remove test data, temp components, and symlinks.
+
+Shell smoke tests are acceptable when the project already has that convention.
+Keep them strict: exit non-zero on boot failure, seed failure, missing endpoint,
+wrong status, or wrong response shape.
+
+Example integration skeleton:
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+bun run build
+
+HARPER_APP_DIR="${PWD}/harper-app"
+HARPER_HOME="${HARPER_HOME:-${PWD}/.harper-test}"
+BASE_URL="${BASE_URL:-http://127.0.0.1:9926}"
+
+mkdir -p "$HARPER_HOME/components"
+ln -sfn "$HARPER_APP_DIR" "$HARPER_HOME/components/pets"
+
+HARPER_HOME="$HARPER_HOME" harper run "$HARPER_APP_DIR" > /tmp/harper-test.log 2>&1 &
+HARPER_PID=$!
+trap 'kill "$HARPER_PID" 2>/dev/null || true; rm -f "$HARPER_HOME/components/pets"' EXIT
+
+for _ in {1..30}; do
+  curl -fsS "$BASE_URL/health" >/dev/null && break
+  sleep 1
+done
+
+curl -fsS -X POST "$BASE_URL/Pets" \
+  -H 'content-type: application/json' \
+  --data '{"id":"pet-it-1","name":"Mina"}' >/dev/null
+
+curl -fsS "$BASE_URL/Pets/pet-it-1" | jq -e '.name == "Mina"'
+```
+
+Adjust the health path, component name, port, and endpoint names to the project.
+Do not commit local `HARPER_HOME`, logs, generated component copies, or secrets.
+
+## Seeding and isolation
+
+Use deterministic test data that cannot collide with developer or CI data:
+
+- Prefix IDs with the test name and a run ID, for example
+  `pet-${process.env.GITHUB_RUN_ID ?? Date.now()}`.
+- Prefer per-test setup/teardown through REST or Operations API when tests mutate
+  records.
+- Prefer `dataLoader` fixtures for stable baseline data that every local boot
+  should have.
+- Make teardown idempotent; deleting a record that is already gone should not fail
+  the suite.
+- Keep seed fixtures aligned with [[harper-schema-graphql]]. A field or type rename
+  must update fixtures, resource tests, verify scripts, and Playwright assertions in
+  the same PR.
+
+`dataLoader` is good for fast, declarative baseline rows. REST seeding is better
+when the test must exercise validation, defaults, auth, or generated IDs exactly as
+clients see them.
+
+## Playwright endpoint tests
+
+Use Playwright for HTTP behavior that needs browser tooling, request contexts,
+storage state, tracing, or cross-browser/project coverage. A first endpoint spec
+should cover one happy path and one non-happy path:
+
+```typescript
+import { expect, test } from '@playwright/test';
+
+test.describe('Pets REST endpoint', () => {
+  test('creates and reads a pet', async ({ request }) => {
+    const id = `pet-pw-${Date.now()}`;
+
+    const create = await request.post('/Pets', {
+      data: { id, name: 'Mina' },
+    });
+    expect(create.ok()).toBe(true);
+
+    const read = await request.get(`/Pets/${id}`);
+    expect(read.status()).toBe(200);
+    await expect(read).toHaveJSON(expect.objectContaining({ id, name: 'Mina' }));
+  });
+
+  test('rejects invalid payloads', async ({ request }) => {
+    const response = await request.post('/Pets', {
+      data: { name: '' },
+    });
+
+    expect(response.status()).toBeGreaterThanOrEqual(400);
+    await expect(response).toHaveJSON(
+      expect.objectContaining({
+        error: expect.any(String),
+      }),
+    );
+  });
+});
+```
+
+If the project uses custom auth, set `storageState`, headers, or a request fixture
+in Playwright config instead of embedding credentials in specs. Never commit
+tokens or local `.env` values.
+
+## Schema and verify coupling
+
+A schema rename or resource route change is a breaking change for every verify
+path that names that table, field, endpoint, fixture, or response shape.
+
+In the same PR as a schema/resource change:
+
+- Update `schema.graphql`, TypeScript resources, fixtures, and data loaders.
+- Update Vitest resource tests and Playwright endpoint specs.
+- Update shell smoke or `scripts/verify*` paths that assert row counts, joins, or
+  response keys.
+- Run `bun run build`, `bun run typecheck`, and the smallest relevant test command.
+- For deploy-affecting changes, boot local Harper or run the project smoke command
+  against the deployed endpoint. See [[harper-build-and-deploy]].
+
+Do not report a Harper test change done only because mocks pass. At least one
+verify path must prove the generated app still boots and exposes the expected
+surface whenever config, schema, resources, generated artifacts, or endpoints are
+part of the change.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.74.9",
+  "version": "4.75.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.74.9",
+  "version": "4.75.1",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.74.9",
+  "version": "4.75.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.74.9",
+  "version": "4.75.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.74.9",
+  "version": "4.75.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -0,0 +1,11 @@
+{
+  "name": "lisa-nestjs",
+  "version": "4.75.1",
+  "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
+  "author": {
+    "name": "Cody Swann"
+  },
+  "dependencies": [
+    "lisa-typescript"
+  ]
+}

package/plugins/lisa-nestjs-devin/.devin-plugin/plugin.json

@@ -0,0 +1,8 @@
+{
+  "name": "lisa-nestjs",
+  "version": "4.75.1",
+  "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
+  "author": {
+    "name": "Cody Swann"
+  }
+}

package/plugins/lisa-nestjs-devin/hooks/block-migration-edits.sh

@@ -0,0 +1,125 @@
+#!/bin/bash
+# This file is managed by Lisa.
+# Do not edit directly — changes will be overwritten on the next `lisa` run.
+
+# PreToolUse hook: block Write/Edit on TypeORM migration files by default.
+# This scopes direct edit tools; it does not verify approval or establish the
+# provenance of files written through other tools.
+# NestJS projects must use `bun run migration:generate` to create migrations
+# from entity diffs. Hand-written migrations drift from entity metadata and
+# break the schema/migration contract.
+# Reference: https://docs.claude.com/en/docs/claude-code/hooks
+# Exit code 2 blocks the tool call and surfaces stderr to Claude.
+#
+# WHAT A REFUSAL HOOK OWES THAT AN ON-EDIT HOOK DOES NOT. The five PostToolUse
+# scripts may bail out when they cannot run: the write has already happened and
+# a skipped lint is a missed report. This one decides whether the write happens
+# at all, so a bail-out is a PERMIT — it lets through exactly the edit it exists
+# to stop, while reporting success. Every exit below is therefore one of three
+# things and never a fourth: out of scope (nothing to judge), judged by the
+# project's declared task, or judged by the built-in. "Could not judge" refuses.
+
+JSON_INPUT=$(cat)
+
+# Project rule (host rules, .agents/rules/): never parse JSON in shell with
+# grep/sed/cut/awk — always use jq.
+#
+# FAIL CLOSED, reversed from the `exit 0` this shipped with. Without jq the
+# payload cannot be read at all, so the hook cannot tell a migration edit from
+# any other write — and it said so on stderr while permitting the edit anyway,
+# which is a guard announcing that it did not check and then waving the write
+# through. The refusal is unscoped for the same reason: with no parse there is
+# no path to scope it to.
+if ! command -v jq >/dev/null 2>&1; then
+  cat >&2 <<'MSG'
+❌ Blocked: block-migration-edits cannot inspect this write.
+
+`jq` is not installed, so the tool payload cannot be parsed — this hook cannot
+tell whether the write targets a TypeORM migration. It refuses rather than
+permitting an edit it was unable to check.
+
+Install jq (`brew install jq`, `apt-get install jq`), or declare the
+`migration-provenance` gate at `pre-tool` in .lisa.config.json to have your own
+check decide instead.
+MSG
+  exit 2
+fi
+
+FILE_PATH=$(printf '%s' "$JSON_INPUT" | jq -r '.tool_input.file_path // empty')
+
+if [ -z "$FILE_PATH" ]; then
+  exit 0
+fi
+
+# Scope. Outside a migration path this hook does nothing at all, so there is
+# nothing here for a declaration to take over — the same reason the sibling
+# on-edit hook filters by file type and source directory BEFORE it consults.
+case "$FILE_PATH" in
+  */migrations/*.ts | */migrations/*.js) ;;
+  *) exit 0 ;;
+esac
+
+# Where this script lives, resolved BEFORE any `cd`. `$0` is the path the
+# harness invoked, and the façade helper ships beside it.
+LISA_HOOK_DIR="$(cd "$(dirname "$0")" 2>/dev/null && pwd)"
+
+# ---------------------------------------------------------------------------
+# Gate façade. The project's declaration decides BEFORE the built-in refuses.
+# Full contract, and why an undeclared project sees no change at all, in
+# lisa-edit-gate.sh beside this file.
+#
+# THE WORKING DIRECTORY IS PART OF THE WIRING HERE, which is why this hook was
+# left out of the change that wired the five on-edit ones. Those hooks already
+# `cd "$CLAUDE_PROJECT_DIR"` to run a tool against the tree; this one acts on
+# the payload and never establishes a directory at all. The helper resolves
+# .lisa.config.json and the gate registry RELATIVE to the current directory, so
+# without the `cd` it would read whatever directory the harness happened to
+# launch in and report "nothing declared" for a project that had declared.
+#
+# The `cd` is safe for the built-in below because the built-in reads only the
+# path out of the payload — nothing it does depends on the working directory.
+# That is what keeps an undeclared project on exactly the command, and exactly
+# the exit status, it had before.
+#
+# A project may supply its own `migration-provenance` check for these edits.
+# The built-in only refuses the scoped Write/Edit calls.
+# ---------------------------------------------------------------------------
+if [ -n "${CLAUDE_PROJECT_DIR:-}" ] &&
+  [ -f "$LISA_HOOK_DIR/lisa-edit-gate.sh" ] &&
+  cd "$CLAUDE_PROJECT_DIR" 2>/dev/null; then
+  # shellcheck source=/dev/null
+  . "$LISA_HOOK_DIR/lisa-edit-gate.sh"
+  if LISA_GATE_COMMANDS="$(lisa_edit_gate_tasks pre-tool migration-provenance)"; then
+    # The declared task's own exit status decides the write: non-zero refuses,
+    # exactly as the built-in's outright refusal does. A project that declares
+    # this gate is saying its own check knows which migrations came from the
+    # model, which is the judgement the built-in makes by refusing them all.
+    lisa_edit_gate_run "$FILE_PATH" "$LISA_GATE_COMMANDS"
+    exit $?
+  fi
+fi
+
+cat >&2 <<EOF
+❌ Blocked: This default hook refuses Write/Edit on TypeORM migration files.
+
+File: $FILE_PATH
+
+Entity files (src/database/entities/*.ts) are the single source of
+truth for the database schema in this project. Migrations are a derived
+artifact — generate them from entity diffs:
+
+  1. Edit the entity to express the desired schema.
+  2. Run: bun run migration:generate --name=<DescriptiveName>
+  3. Review the generated migration; commit entity + migration together.
+
+Out-of-band migrations (backfills, seed data, maintenance) cannot always
+come from entity diffs. A project that supports these edits can declare a
+\`migration-provenance\` check at \`pre-tool\` in .lisa.config.json. The hook
+runs that check and uses its result to permit or refuse the edit.
+
+Document the migration's rationale and verification in its class comment.
+This default hook cannot verify human approval and does not inspect Bash
+writes. Do not switch tools to evade its refusal. See the nestjs-rules skill
+for the supported project-check path.
+EOF
+exit 2

package/plugins/lisa-nestjs-devin/hooks/devin-tool-name-shim.sh

@@ -0,0 +1,30 @@
+#!/bin/sh
+# Generated by scripts/generate-devin-plugin-artifacts.mjs — do not edit.
+#
+# Devin CLI names its tools in lowercase (exec, write, edit, read, ...) while
+# Lisa's guards test Claude's names (Bash, Write, Edit, Read, ...). The field
+# names inside tool_input already match, so translating tool_name is enough
+# for an unchanged guard to evaluate a Devin tool call (CodySwannGT/lisa#4426).
+#
+# Usage: devin-tool-name-shim.sh <hook command> [args...]
+payload=$(cat)
+normalized=$payload
+if command -v jq >/dev/null 2>&1; then
+  mapped=$(printf '%s' "$payload" | jq -c '
+    if (.tool_name | type) == "string" then
+      .tool_name |= ({
+        "exec": "Bash",
+        "write": "Write",
+        "edit": "Edit",
+        "read": "Read",
+        "notebook_edit": "NotebookEdit",
+        "grep": "Grep",
+        "glob": "Glob",
+        "webfetch": "WebFetch",
+        "run_subagent": "Task",
+        "skill": "Skill",
+        "todo_write": "TodoWrite"
+      }[.] // .)
+    else . end' 2>/dev/null) && [ -n "$mapped" ] && normalized=$mapped
+fi
+printf '%s' "$normalized" | "$@"

package/plugins/lisa-nestjs-devin/hooks/lisa-edit-gate.sh

@@ -0,0 +1,152 @@
+#!/bin/bash
+# This file is managed by Lisa.
+# Do not edit directly — changes will be overwritten on the next `lisa` run.
+# =============================================================================
+# Edit-time gate façade
+# =============================================================================
+# Sourced by every on-edit hook. Answers one question before the hook runs
+# anything: has the project declared what proves this property at this moment,
+# and if so what should run instead of Lisa's written-in tool?
+#
+# WHY THIS EXISTS. Edit time is the highest-frequency enforcement surface Lisa
+# owns and was the one surface with no configurability at all. The scripts
+# resolved a RUNNER (`./node_modules/.bin/oxlint`, else `bunx`/`npx`) and
+# hardcoded the TOOL, which is the inversion the gate registry exists to fix.
+# Worse, they exit 2 — refusing the edit — when the written-in binary or config
+# filename is absent, so a project that lints correctly with something else had
+# every agent write refused until it installed Lisa's choice.
+#
+# THE CONTRACT, and the two halves that matter equally:
+#
+#   declared   -> the project's task runs and the hook's written-in tool is
+#                 never consulted, so a missing binary cannot refuse the edit.
+#   undeclared -> NOTHING changes. The resolver is not even invoked when no
+#                 registry is installed, and the hook falls through to exactly
+#                 the command it ran before. That is the overwhelming majority
+#                 of projects, and it is the case a façade silently breaks.
+#
+# ALL OR NOTHING FOR A MULTI-PROPERTY SCRIPT. `lisa_edit_gate_tasks` takes every
+# property its caller proves and resolves only when EVERY one is declared. The
+# Rails hook runs `rubocop -a` and then a second pass for unfixable errors — its
+# own header calls it both formatter and linter — so standing down on `code-style`
+# alone would silently stop proving `format-conformance`. Same shape as
+# `lisa_gate_covers test-correctness coverage-adequacy` in the pre-push hook.
+#
+# HOW THE DECLARED TASK LEARNS WHICH FILE WAS EDITED. It does not take an
+# argument: `<runner> <task>` with no arguments is the invocation every other
+# Lisa façade uses, and adding a positional here would make the declaration
+# mean something different at this moment than at every other one. The path is
+# exported as LISA_EDITED_FILE instead, so a project that wants a per-file run
+# can scope its own task and one that does not gets a whole-project run.
+# =============================================================================
+
+# Where the gate registry may be installed, in resolution order.
+lisa_edit_gate_registry() {
+    for _lisa_candidate in \
+        "node_modules/@codyswann/lisa/all/copy-overwrite/scripts/lisa-gates.mjs" \
+        "scripts/lisa-gates.mjs" \
+        "all/copy-overwrite/scripts/lisa-gates.mjs"
+    do
+        if [ -f "$_lisa_candidate" ]; then
+            printf '%s' "$_lisa_candidate"
+            unset _lisa_candidate
+            return 0
+        fi
+    done
+    unset _lisa_candidate
+    return 1
+}
+
+# lisa_edit_gate_tasks <moment> <gate-id>...
+#
+# Prints one `<runner> <task>` line per DISTINCT declared task and returns 0,
+# but only when every named gate resolves to a runnable task at <moment>.
+# Returns 1 and prints nothing otherwise — including when no registry is
+# installed, when node is unavailable, and when the resolver itself fails.
+#
+# Fail-safe in the direction that keeps proving things: any doubt returns 1 and
+# the caller runs its built-in. A resolver that could not answer must never read
+# as "the project has this covered".
+lisa_edit_gate_tasks() {
+    _lisa_moment="$1"
+    shift
+    [ -n "$_lisa_moment" ] || { unset _lisa_moment; return 1; }
+    [ "$#" -gt 0 ] || { unset _lisa_moment; return 1; }
+    # NO SETTINGS FILE, NO SPAWN. Checked before anything else because this is
+    # the path essentially every project is on, and it runs on EVERY agent
+    # edit: asking the resolver would cost a node process per keystroke-sized
+    # write to answer "nothing is declared", which the absent file already
+    # answers. The equivalence control compares which COMMAND runs and would
+    # not have caught the cost.
+    [ -f .lisa.config.json ] || { unset _lisa_moment; return 1; }
+    command -v node >/dev/null 2>&1 || { unset _lisa_moment; return 1; }
+
+    _lisa_registry="$(lisa_edit_gate_registry)" || {
+        unset _lisa_moment _lisa_registry
+        return 1
+    }
+
+    # EXPORTED, not prefixed. An assignment prefix reaches only the FIRST
+    # command of a pipeline, and the filter that reads it is the second — so
+    # the prefixed form resolved an empty want-list and every script fell
+    # silently back to its built-in, which is a façade that looks wired and is
+    # not.
+    LISA_GATE_IDS="$*"
+    export LISA_GATE_IDS
+    _lisa_out="$(
+        node "$_lisa_registry" list \
+            --moment="$_lisa_moment" --json 2>/dev/null | node -e '
+let raw = "";
+process.stdin.on("data", chunk => { raw += chunk }).on("end", () => {
+  let resolved;
+  try { resolved = JSON.parse(raw || "[]"); } catch { process.exit(1); }
+  const wanted = (process.env.LISA_GATE_IDS || "").split(" ").filter(Boolean);
+  const commands = [];
+  for (const id of wanted) {
+    const hit = resolved.find(gate => gate.id === id);
+    // `run` mode with a task is the only shape that PROVES anything here. An
+    // awaited gate proves nothing at edit time and an intercepted one is
+    // Lisa running it elsewhere; both must leave the built-in in charge.
+    if (!hit || hit.mode !== "run" || !hit.command) process.exit(1);
+    if (!commands.includes(hit.command)) commands.push(hit.command);
+  }
+  if (commands.length === 0) process.exit(1);
+  process.stdout.write(commands.join("\n"));
+});
+'
+    )" || {
+        unset _lisa_moment _lisa_registry _lisa_out
+        return 1
+    }
+
+    [ -n "$_lisa_out" ] || {
+        unset _lisa_moment _lisa_registry _lisa_out
+        return 1
+    }
+    printf '%s' "$_lisa_out"
+    unset _lisa_moment _lisa_registry _lisa_out
+    return 0
+}
+
+# lisa_edit_gate_run <edited-file> <commands>
+#
+# Runs each resolved command with LISA_EDITED_FILE exported. Exits 2 on the
+# first failure, which is the same refusal the built-in path uses, so a
+# declared task that finds a real problem still stops the agent.
+lisa_edit_gate_run() {
+    _lisa_file="$1"
+    shift
+    LISA_EDITED_FILE="$_lisa_file"
+    export LISA_EDITED_FILE
+    printf '%s\n' "$*" | while IFS= read -r _lisa_command; do
+        [ -n "$_lisa_command" ] || continue
+        echo "Running declared gate task: $_lisa_command"
+        # Deliberate word split: the resolver validated both halves as plain
+        # words, so no shell metacharacter reaches argv.
+        # shellcheck disable=SC2086
+        $_lisa_command || exit 2
+    done
+    _lisa_status=$?
+    unset _lisa_file _lisa_command
+    return $_lisa_status
+}

package/plugins/lisa-nestjs-devin/hooks.json

@@ -0,0 +1,15 @@
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "^(write|apply_patch|edit)$",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/devin-tool-name-shim.sh ${CLAUDE_PLUGIN_ROOT}/hooks/block-migration-edits.sh"
+          }
+        ]
+      }
+    ]
+  }
+}