@codyswann/lisa 4.60.5 → 4.60.6

package/dist/codex/scripts/block-migration-edits.sh

@@ -1,5 +1,7 @@
 #!/usr/bin/env bash
 # Lisa-managed Codex hook script (PreToolUse Edit|Write|apply_patch).
+# This scopes direct edit tools; it does not verify approval or establish the
+# provenance of files written through other tools.
 # Blocks edits to TypeORM migration files. Use `bun run migration:generate`
 # to regenerate from entity diffs instead — hand-written migrations drift
 # from entity metadata and break the schema/migration contract.
@@ -71,8 +73,8 @@ fi
 # there is no `cd` here — the Claude copy needs one because a PreToolUse hook
 # there establishes none.
 #
-# ONE PROPERTY, so there is no all-or-nothing question here: this hook proves
-# `migration-provenance` and nothing else.
+# A project may supply its own `migration-provenance` check for these edits.
+# The built-in only refuses the scoped Edit/Write/apply_patch calls.
 # ---------------------------------------------------------------------------
 # shellcheck source=/dev/null
 . "${SCRIPT_DIR}/lisa-edit-gate.sh"
@@ -103,8 +105,14 @@ while IFS= read -r FILE_PATH; do
 TypeORM migrations must be regenerated from entity diffs:
   bun run migration:generate -- src/database/migrations/<descriptive-name>
 
-Hand-written migrations drift from entity metadata and break the schema
-contract. Modify the entity, run the generator, then commit the result.
+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. It inspects Edit, Write and
+apply_patch, not Bash writes. Do not switch tools to evade its refusal.
 EOF
       exit 2
       ;;

package/dist/core/nightly-e2e-guard-behavior-certificate.js

@@ -48,9 +48,9 @@ export const NIGHTLY_E2E_GUARD_BEHAVIOR_CERTIFICATES = Object.freeze({
     }),
     f87e6eee47ddb6416f2c639b79b96a68173c9c562999fbad98abe012ac913d28: Object.freeze({
         contractVersion: "1.9.0",
-        packageVersions: Object.freeze(["4.60.5"]),
+        packageVersions: Object.freeze(["4.60.6"]),
         provenances: Object.freeze([
-            "workspace package @codyswann/lisa@4.60.5 (typescript/copy-overwrite/scripts/check-nightly-e2e-health.mjs)",
+            "workspace package @codyswann/lisa@4.60.6 (typescript/copy-overwrite/scripts/check-nightly-e2e-health.mjs)",
         ]),
     }),
 });

package/dist/core/upstream-evidence-manifest.js

@@ -912,7 +912,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/harper-fabric/skills/harper-rest-queries/SKILL.md": "cadccf7c4a3d9ebf9557c2739e65dd0bd8be08e6f65b1e89d416cc85e5183dec",
     "plugins/src/harper-fabric/skills/harper-schema-graphql/SKILL.md": "e60a691b0586d7554ea01ece4a71f9a7a4f1e585b94c46ad64c4edd32327fde6",
     "plugins/src/harper-fabric/skills/harper-testing/SKILL.md": "5a3c91d80ea2ac97df5b085114e2111a2c749ff0ad259a291cf16cb2f96258b8",
-    "plugins/src/nestjs/hooks/block-migration-edits.sh": "9198c36725cfa5254b7f93267f3075e51ca54c65f63537cee5272ff297af3450",
+    "plugins/src/nestjs/hooks/block-migration-edits.sh": "24c6b704ad821576234c4e1cfa7b9a5fee40dca360035d7561ba150444e37c01",
     "plugins/src/nestjs/hooks/lisa-edit-gate.sh": "0a8d9a043f04b15b71bb500ff03cf1e67e4ac292181a5d596ddf078f301e671f",
     "plugins/src/nestjs/skills/nestjs-graphql/SKILL.md": "205b4be76dfe9b2cc4688a7e2cb1754c68aedf67bdc00187af40af0e49ba854a",
     "plugins/src/nestjs/skills/nestjs-graphql/references/advanced-features.md": "57b2c69daa4c91ccd1556db363ea1dd0912ba942222571839ba0e5eca064196f",
@@ -920,7 +920,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/nestjs/skills/nestjs-graphql/references/quick-start.md": "58ab79368768540c7e9da17af7e2bbc8a703f879806443f117f79b61a3aff18f",
     "plugins/src/nestjs/skills/nestjs-graphql/references/resolvers-mutations.md": "76135d5b1466ba3fa01b01d5e0e4d6675af8bda1c163ba64b5931cdfe2b718dd",
     "plugins/src/nestjs/skills/nestjs-graphql/references/types-scalars.md": "28c10e5c297928438c3ef72407c20e587cb9bb15173d9aa3fd4e661822def311",
-    "plugins/src/nestjs/skills/nestjs-rules/SKILL.md": "1268c530c921a6c65b4539e93b599d46ff2dd7eb591f414e857072f7587d6a72",
+    "plugins/src/nestjs/skills/nestjs-rules/SKILL.md": "0539c464cc0ce04340bb8a5b716a3b3919cc5adaa22ad3776d1e8400d8a63313",
     "plugins/src/nestjs/skills/typeorm-patterns/SKILL.md": "319707f8e61845e84a72d478ecb7a6e327f9e9a8b3822de7746d17a418afa34f",
     "plugins/src/nestjs/skills/typeorm-patterns/references/configuration-patterns.md": "0c5db577e4ad72f80f00ed12ad095cd5aa59536bff45cde20b26146754994aa5",
     "plugins/src/nestjs/skills/typeorm-patterns/references/entity-patterns.md": "350376367c7521944b20b2df4f9a9c34ad5446d0f814d4ea01c5c487ebae9d8e",

package/dist/opencode/plugin-templates/lisa-block-migration-edits.ts

@@ -10,6 +10,9 @@
  * straight from `output.args.filePath`. Throwing in `tool.execute.before`
  * cancels the tool call and surfaces the message to the agent (verified-by-run
  * on opencode 1.16.2).
+ * This adapter does not delegate to a project's migration-provenance check;
+ * unlike the Claude and Codex adapters, it cannot permit those exceptions.
+ * It neither verifies human approval nor inspects Bash writes.
  *
  * NOTE: This file is a template Lisa copies verbatim into a host project's
  * `.opencode/plugin/`. It is intentionally excluded from this repo's tsconfig
@@ -35,8 +38,13 @@ const LisaBlockMigrationEdits = async () => {
           "TypeORM migrations must be regenerated from entity diffs:",
           "  bun run migration:generate -- src/database/migrations/<descriptive-name>",
           "",
-          "Hand-written migrations drift from entity metadata and break the",
-          "schema contract. Modify the entity, run the generator, then commit.",
+          "Out-of-band migrations (backfills, seed data, maintenance) cannot",
+          "always come from entity diffs. Document their rationale and verification.",
+          "",
+          "This OpenCode adapter only inspects edit/write and cannot verify",
+          "human approval. It does not yet support the project migration-provenance",
+          "exception check available in the Claude and Codex adapters, so it keeps",
+          "refusing this edit. Do not switch tools to evade the refusal.",
         ].join("\n")
       );
     },

package/package.json

@@ -187,7 +187,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -336,7 +336,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "0a6db7b0b7d219f3496e4c43e715c260a7b15c3e",
-  "gitHead": "0a6db7b0b7d219f3496e4c43e715c260a7b15c3e",
-  "lisaReleaseTag": "v4.60.5"
+  "lisaReleaseCommit": "29a6f62c71498e13d34089873ed85f043c51fd4a",
+  "gitHead": "29a6f62c71498e13d34089873ed85f043c51fd4a",
+  "lisaReleaseTag": "v4.60.6"
 }

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

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

package/plugins/lisa-agy/plugin.json

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

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "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.60.5",
+  "version": "4.60.6",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.codex-plugin/skills/nestjs-rules/SKILL.md

@@ -51,11 +51,9 @@ In this project, **entity files (`src/database/entities/*.ts`) are the single so
 2. Run `bun run migration:generate --name=<DescriptiveName>` to produce the migration from the diff.
 3. Review the generated migration, then commit both the entity change and the migration together.
 
-If a schema change cannot be expressed via the entity model, the entity model is wrong — fix the entity, do not hand-write the migration.
+### Generate Schema Migrations
 
-### Never Create Migration Files Manually
-
-Never create or modify a TypeORM migration file directly. Use `migration:generate` from `package.json`:
+Use `migration:generate` from `package.json` for changes represented by entity metadata:
 
 ```bash
 bun run migration:generate --name=<DescriptiveName>
@@ -69,18 +67,15 @@ Some changes genuinely cannot be derived from entity diffs:
 - **Data backfills** (populating a new column from existing rows)
 - **Data transformations** (splitting a column, normalizing values)
 - **One-off cleanup** (deleting orphaned rows before a constraint is added)
+- **Database maintenance** (refreshing planner statistics with `ANALYZE`)
 
-These are legitimate cases for a hand-written migration, but they are **out-of-band** — they bypass the entity-as-source-of-truth contract. When you encounter one:
-
-1. **Stop and tell the user.** Explain what change is needed and why it cannot be expressed via the entity model.
-2. **Get explicit approval** before writing the migration by hand.
-3. Document the rationale in the migration's class comment so future readers understand why this one was not generated.
+Use the project's established migration process for these cases. Document the rationale and verification in the migration's class comment so future readers understand why it was not generated. Apply the authorization already given for the work; the default edit hook does not record or verify human approval.
 
-Do not silently hand-write a migration for a backfill or seed-data change. The user must know that the entity-as-source-of-truth contract is being intentionally bypassed for this case.
+A project that supports direct migration edits can declare its own `migration-provenance` check at `pre-tool` in `.lisa.config.json`. The Claude and Codex hooks run that check for the targeted migration and permit the edit only when it passes. The check must validate the project's migration policy; an unconditional success command proves nothing. Without a declared check, the built-in still refuses the edit. OpenCode's migration adapter currently does not support this exception path and continues to refuse it.
 
 ### Enforcement
 
-The `lisa-nestjs` plugin ships a `PreToolUse` hook (`block-migration-edits.sh`) that blocks `Write`/`Edit` on any path matching `**/migrations/*.ts` or `**/migrations/*.js`. The block surfaces this rule's guidance to remind you to either (a) edit the entity instead, or (b) ask the user before proceeding with an out-of-band migration.
+The `lisa-nestjs` plugin's default `PreToolUse` hook (`block-migration-edits.sh`) refuses `Write`/`Edit` on paths matching `**/migrations/*.ts` or `**/migrations/*.js`. Codex also inspects `apply_patch`; its migration matcher and OpenCode's matcher cover numbered TypeScript migration filenames. These are direct-edit checks, not an audit of migration authorship: they do not inspect Bash writes. Do not switch tools to evade a refusal. Use the supported project check where available.
 
 ### Why Auto-Generation
 

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

@@ -2,7 +2,9 @@
 # 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.
+# 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.
@@ -79,8 +81,8 @@ LISA_HOOK_DIR="$(cd "$(dirname "$0")" 2>/dev/null && pwd)"
 # That is what keeps an undeclared project on exactly the command, and exactly
 # the exit status, it had before.
 #
-# ONE PROPERTY, so there is no all-or-nothing question here: this hook proves
-# `migration-provenance` and nothing else.
+# 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" ] &&
@@ -98,7 +100,7 @@ if [ -n "${CLAUDE_PROJECT_DIR:-}" ] &&
 fi
 
 cat >&2 <<EOF
-❌ Blocked: Direct edits to TypeORM migration files are not allowed.
+❌ Blocked: This default hook refuses Write/Edit on TypeORM migration files.
 
 File: $FILE_PATH
 
@@ -110,20 +112,14 @@ artifact — generate them from entity diffs:
   2. Run: bun run migration:generate --name=<DescriptiveName>
   3. Review the generated migration; commit entity + migration together.
 
-If a schema change cannot be expressed via the entity model, the entity
-model is wrong — fix the entity, do not hand-write the migration.
+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.
 
-OUT-OF-BAND MIGRATIONS (seed data, backfills, data transformations,
-one-off cleanup): these genuinely cannot come from entity diffs. They
-are legitimate but they bypass the entity-as-source-of-truth contract.
-
-If you believe this edit is an out-of-band migration:
-  1. STOP and tell the user what change is needed and why it cannot
-     be expressed via the entity model.
-  2. Get explicit approval before proceeding.
-  3. Document the rationale in the migration's class comment.
-
-Do NOT silently hand-write a migration. See the nestjs-rules skill
-for the full rationale.
+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/skills/nestjs-rules/SKILL.md

@@ -51,11 +51,9 @@ In this project, **entity files (`src/database/entities/*.ts`) are the single so
 2. Run `bun run migration:generate --name=<DescriptiveName>` to produce the migration from the diff.
 3. Review the generated migration, then commit both the entity change and the migration together.
 
-If a schema change cannot be expressed via the entity model, the entity model is wrong — fix the entity, do not hand-write the migration.
+### Generate Schema Migrations
 
-### Never Create Migration Files Manually
-
-Never create or modify a TypeORM migration file directly. Use `migration:generate` from `package.json`:
+Use `migration:generate` from `package.json` for changes represented by entity metadata:
 
 ```bash
 bun run migration:generate --name=<DescriptiveName>
@@ -69,18 +67,15 @@ Some changes genuinely cannot be derived from entity diffs:
 - **Data backfills** (populating a new column from existing rows)
 - **Data transformations** (splitting a column, normalizing values)
 - **One-off cleanup** (deleting orphaned rows before a constraint is added)
+- **Database maintenance** (refreshing planner statistics with `ANALYZE`)
 
-These are legitimate cases for a hand-written migration, but they are **out-of-band** — they bypass the entity-as-source-of-truth contract. When you encounter one:
-
-1. **Stop and tell the user.** Explain what change is needed and why it cannot be expressed via the entity model.
-2. **Get explicit approval** before writing the migration by hand.
-3. Document the rationale in the migration's class comment so future readers understand why this one was not generated.
+Use the project's established migration process for these cases. Document the rationale and verification in the migration's class comment so future readers understand why it was not generated. Apply the authorization already given for the work; the default edit hook does not record or verify human approval.
 
-Do not silently hand-write a migration for a backfill or seed-data change. The user must know that the entity-as-source-of-truth contract is being intentionally bypassed for this case.
+A project that supports direct migration edits can declare its own `migration-provenance` check at `pre-tool` in `.lisa.config.json`. The Claude and Codex hooks run that check for the targeted migration and permit the edit only when it passes. The check must validate the project's migration policy; an unconditional success command proves nothing. Without a declared check, the built-in still refuses the edit. OpenCode's migration adapter currently does not support this exception path and continues to refuse it.
 
 ### Enforcement
 
-The `lisa-nestjs` plugin ships a `PreToolUse` hook (`block-migration-edits.sh`) that blocks `Write`/`Edit` on any path matching `**/migrations/*.ts` or `**/migrations/*.js`. The block surfaces this rule's guidance to remind you to either (a) edit the entity instead, or (b) ask the user before proceeding with an out-of-band migration.
+The `lisa-nestjs` plugin's default `PreToolUse` hook (`block-migration-edits.sh`) refuses `Write`/`Edit` on paths matching `**/migrations/*.ts` or `**/migrations/*.js`. Codex also inspects `apply_patch`; its migration matcher and OpenCode's matcher cover numbered TypeScript migration filenames. These are direct-edit checks, not an audit of migration authorship: they do not inspect Bash writes. Do not switch tools to evade a refusal. Use the supported project check where available.
 
 ### Why Auto-Generation
 

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

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

package/plugins/lisa-nestjs-agy/skills/nestjs-rules/SKILL.md

@@ -51,11 +51,9 @@ In this project, **entity files (`src/database/entities/*.ts`) are the single so
 2. Run `bun run migration:generate --name=<DescriptiveName>` to produce the migration from the diff.
 3. Review the generated migration, then commit both the entity change and the migration together.
 
-If a schema change cannot be expressed via the entity model, the entity model is wrong — fix the entity, do not hand-write the migration.
+### Generate Schema Migrations
 
-### Never Create Migration Files Manually
-
-Never create or modify a TypeORM migration file directly. Use `migration:generate` from `package.json`:
+Use `migration:generate` from `package.json` for changes represented by entity metadata:
 
 ```bash
 bun run migration:generate --name=<DescriptiveName>
@@ -69,18 +67,15 @@ Some changes genuinely cannot be derived from entity diffs:
 - **Data backfills** (populating a new column from existing rows)
 - **Data transformations** (splitting a column, normalizing values)
 - **One-off cleanup** (deleting orphaned rows before a constraint is added)
+- **Database maintenance** (refreshing planner statistics with `ANALYZE`)
 
-These are legitimate cases for a hand-written migration, but they are **out-of-band** — they bypass the entity-as-source-of-truth contract. When you encounter one:
-
-1. **Stop and tell the user.** Explain what change is needed and why it cannot be expressed via the entity model.
-2. **Get explicit approval** before writing the migration by hand.
-3. Document the rationale in the migration's class comment so future readers understand why this one was not generated.
+Use the project's established migration process for these cases. Document the rationale and verification in the migration's class comment so future readers understand why it was not generated. Apply the authorization already given for the work; the default edit hook does not record or verify human approval.
 
-Do not silently hand-write a migration for a backfill or seed-data change. The user must know that the entity-as-source-of-truth contract is being intentionally bypassed for this case.
+A project that supports direct migration edits can declare its own `migration-provenance` check at `pre-tool` in `.lisa.config.json`. The Claude and Codex hooks run that check for the targeted migration and permit the edit only when it passes. The check must validate the project's migration policy; an unconditional success command proves nothing. Without a declared check, the built-in still refuses the edit. OpenCode's migration adapter currently does not support this exception path and continues to refuse it.
 
 ### Enforcement
 
-The `lisa-nestjs` plugin ships a `PreToolUse` hook (`block-migration-edits.sh`) that blocks `Write`/`Edit` on any path matching `**/migrations/*.ts` or `**/migrations/*.js`. The block surfaces this rule's guidance to remind you to either (a) edit the entity instead, or (b) ask the user before proceeding with an out-of-band migration.
+The `lisa-nestjs` plugin's default `PreToolUse` hook (`block-migration-edits.sh`) refuses `Write`/`Edit` on paths matching `**/migrations/*.ts` or `**/migrations/*.js`. Codex also inspects `apply_patch`; its migration matcher and OpenCode's matcher cover numbered TypeScript migration filenames. These are direct-edit checks, not an audit of migration authorship: they do not inspect Bash writes. Do not switch tools to evade a refusal. Use the supported project check where available.
 
 ### Why Auto-Generation
 

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

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

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

@@ -2,7 +2,9 @@
 # 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.
+# 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.
@@ -79,8 +81,8 @@ LISA_HOOK_DIR="$(cd "$(dirname "$0")" 2>/dev/null && pwd)"
 # That is what keeps an undeclared project on exactly the command, and exactly
 # the exit status, it had before.
 #
-# ONE PROPERTY, so there is no all-or-nothing question here: this hook proves
-# `migration-provenance` and nothing else.
+# 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" ] &&
@@ -98,7 +100,7 @@ if [ -n "${CLAUDE_PROJECT_DIR:-}" ] &&
 fi
 
 cat >&2 <<EOF
-❌ Blocked: Direct edits to TypeORM migration files are not allowed.
+❌ Blocked: This default hook refuses Write/Edit on TypeORM migration files.
 
 File: $FILE_PATH
 
@@ -110,20 +112,14 @@ artifact — generate them from entity diffs:
   2. Run: bun run migration:generate --name=<DescriptiveName>
   3. Review the generated migration; commit entity + migration together.
 
-If a schema change cannot be expressed via the entity model, the entity
-model is wrong — fix the entity, do not hand-write the migration.
+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.
 
-OUT-OF-BAND MIGRATIONS (seed data, backfills, data transformations,
-one-off cleanup): these genuinely cannot come from entity diffs. They
-are legitimate but they bypass the entity-as-source-of-truth contract.
-
-If you believe this edit is an out-of-band migration:
-  1. STOP and tell the user what change is needed and why it cannot
-     be expressed via the entity model.
-  2. Get explicit approval before proceeding.
-  3. Document the rationale in the migration's class comment.
-
-Do NOT silently hand-write a migration. See the nestjs-rules skill
-for the full rationale.
+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-copilot/skills/nestjs-rules/SKILL.md

@@ -51,11 +51,9 @@ In this project, **entity files (`src/database/entities/*.ts`) are the single so
 2. Run `bun run migration:generate --name=<DescriptiveName>` to produce the migration from the diff.
 3. Review the generated migration, then commit both the entity change and the migration together.
 
-If a schema change cannot be expressed via the entity model, the entity model is wrong — fix the entity, do not hand-write the migration.
+### Generate Schema Migrations
 
-### Never Create Migration Files Manually
-
-Never create or modify a TypeORM migration file directly. Use `migration:generate` from `package.json`:
+Use `migration:generate` from `package.json` for changes represented by entity metadata:
 
 ```bash
 bun run migration:generate --name=<DescriptiveName>
@@ -69,18 +67,15 @@ Some changes genuinely cannot be derived from entity diffs:
 - **Data backfills** (populating a new column from existing rows)
 - **Data transformations** (splitting a column, normalizing values)
 - **One-off cleanup** (deleting orphaned rows before a constraint is added)
+- **Database maintenance** (refreshing planner statistics with `ANALYZE`)
 
-These are legitimate cases for a hand-written migration, but they are **out-of-band** — they bypass the entity-as-source-of-truth contract. When you encounter one:
-
-1. **Stop and tell the user.** Explain what change is needed and why it cannot be expressed via the entity model.
-2. **Get explicit approval** before writing the migration by hand.
-3. Document the rationale in the migration's class comment so future readers understand why this one was not generated.
+Use the project's established migration process for these cases. Document the rationale and verification in the migration's class comment so future readers understand why it was not generated. Apply the authorization already given for the work; the default edit hook does not record or verify human approval.
 
-Do not silently hand-write a migration for a backfill or seed-data change. The user must know that the entity-as-source-of-truth contract is being intentionally bypassed for this case.
+A project that supports direct migration edits can declare its own `migration-provenance` check at `pre-tool` in `.lisa.config.json`. The Claude and Codex hooks run that check for the targeted migration and permit the edit only when it passes. The check must validate the project's migration policy; an unconditional success command proves nothing. Without a declared check, the built-in still refuses the edit. OpenCode's migration adapter currently does not support this exception path and continues to refuse it.
 
 ### Enforcement
 
-The `lisa-nestjs` plugin ships a `PreToolUse` hook (`block-migration-edits.sh`) that blocks `Write`/`Edit` on any path matching `**/migrations/*.ts` or `**/migrations/*.js`. The block surfaces this rule's guidance to remind you to either (a) edit the entity instead, or (b) ask the user before proceeding with an out-of-band migration.
+The `lisa-nestjs` plugin's default `PreToolUse` hook (`block-migration-edits.sh`) refuses `Write`/`Edit` on paths matching `**/migrations/*.ts` or `**/migrations/*.js`. Codex also inspects `apply_patch`; its migration matcher and OpenCode's matcher cover numbered TypeScript migration filenames. These are direct-edit checks, not an audit of migration authorship: they do not inspect Bash writes. Do not switch tools to evade a refusal. Use the supported project check where available.
 
 ### Why Auto-Generation
 

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

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

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

@@ -2,7 +2,9 @@
 # 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.
+# 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.
@@ -79,8 +81,8 @@ LISA_HOOK_DIR="$(cd "$(dirname "$0")" 2>/dev/null && pwd)"
 # That is what keeps an undeclared project on exactly the command, and exactly
 # the exit status, it had before.
 #
-# ONE PROPERTY, so there is no all-or-nothing question here: this hook proves
-# `migration-provenance` and nothing else.
+# 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" ] &&
@@ -98,7 +100,7 @@ if [ -n "${CLAUDE_PROJECT_DIR:-}" ] &&
 fi
 
 cat >&2 <<EOF
-❌ Blocked: Direct edits to TypeORM migration files are not allowed.
+❌ Blocked: This default hook refuses Write/Edit on TypeORM migration files.
 
 File: $FILE_PATH
 
@@ -110,20 +112,14 @@ artifact — generate them from entity diffs:
   2. Run: bun run migration:generate --name=<DescriptiveName>
   3. Review the generated migration; commit entity + migration together.
 
-If a schema change cannot be expressed via the entity model, the entity
-model is wrong — fix the entity, do not hand-write the migration.
+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.
 
-OUT-OF-BAND MIGRATIONS (seed data, backfills, data transformations,
-one-off cleanup): these genuinely cannot come from entity diffs. They
-are legitimate but they bypass the entity-as-source-of-truth contract.
-
-If you believe this edit is an out-of-band migration:
-  1. STOP and tell the user what change is needed and why it cannot
-     be expressed via the entity model.
-  2. Get explicit approval before proceeding.
-  3. Document the rationale in the migration's class comment.
-
-Do NOT silently hand-write a migration. See the nestjs-rules skill
-for the full rationale.
+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-cursor/skills/nestjs-rules/SKILL.md

@@ -51,11 +51,9 @@ In this project, **entity files (`src/database/entities/*.ts`) are the single so
 2. Run `bun run migration:generate --name=<DescriptiveName>` to produce the migration from the diff.
 3. Review the generated migration, then commit both the entity change and the migration together.
 
-If a schema change cannot be expressed via the entity model, the entity model is wrong — fix the entity, do not hand-write the migration.
+### Generate Schema Migrations
 
-### Never Create Migration Files Manually
-
-Never create or modify a TypeORM migration file directly. Use `migration:generate` from `package.json`:
+Use `migration:generate` from `package.json` for changes represented by entity metadata:
 
 ```bash
 bun run migration:generate --name=<DescriptiveName>
@@ -69,18 +67,15 @@ Some changes genuinely cannot be derived from entity diffs:
 - **Data backfills** (populating a new column from existing rows)
 - **Data transformations** (splitting a column, normalizing values)
 - **One-off cleanup** (deleting orphaned rows before a constraint is added)
+- **Database maintenance** (refreshing planner statistics with `ANALYZE`)
 
-These are legitimate cases for a hand-written migration, but they are **out-of-band** — they bypass the entity-as-source-of-truth contract. When you encounter one:
-
-1. **Stop and tell the user.** Explain what change is needed and why it cannot be expressed via the entity model.
-2. **Get explicit approval** before writing the migration by hand.
-3. Document the rationale in the migration's class comment so future readers understand why this one was not generated.
+Use the project's established migration process for these cases. Document the rationale and verification in the migration's class comment so future readers understand why it was not generated. Apply the authorization already given for the work; the default edit hook does not record or verify human approval.
 
-Do not silently hand-write a migration for a backfill or seed-data change. The user must know that the entity-as-source-of-truth contract is being intentionally bypassed for this case.
+A project that supports direct migration edits can declare its own `migration-provenance` check at `pre-tool` in `.lisa.config.json`. The Claude and Codex hooks run that check for the targeted migration and permit the edit only when it passes. The check must validate the project's migration policy; an unconditional success command proves nothing. Without a declared check, the built-in still refuses the edit. OpenCode's migration adapter currently does not support this exception path and continues to refuse it.
 
 ### Enforcement
 
-The `lisa-nestjs` plugin ships a `PreToolUse` hook (`block-migration-edits.sh`) that blocks `Write`/`Edit` on any path matching `**/migrations/*.ts` or `**/migrations/*.js`. The block surfaces this rule's guidance to remind you to either (a) edit the entity instead, or (b) ask the user before proceeding with an out-of-band migration.
+The `lisa-nestjs` plugin's default `PreToolUse` hook (`block-migration-edits.sh`) refuses `Write`/`Edit` on paths matching `**/migrations/*.ts` or `**/migrations/*.js`. Codex also inspects `apply_patch`; its migration matcher and OpenCode's matcher cover numbered TypeScript migration filenames. These are direct-edit checks, not an audit of migration authorship: they do not inspect Bash writes. Do not switch tools to evade a refusal. Use the supported project check where available.
 
 ### Why Auto-Generation
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.60.5",
+  "version": "4.60.6",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/nestjs/hooks/block-migration-edits.sh

@@ -2,7 +2,9 @@
 # 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.
+# 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.
@@ -79,8 +81,8 @@ LISA_HOOK_DIR="$(cd "$(dirname "$0")" 2>/dev/null && pwd)"
 # That is what keeps an undeclared project on exactly the command, and exactly
 # the exit status, it had before.
 #
-# ONE PROPERTY, so there is no all-or-nothing question here: this hook proves
-# `migration-provenance` and nothing else.
+# 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" ] &&
@@ -98,7 +100,7 @@ if [ -n "${CLAUDE_PROJECT_DIR:-}" ] &&
 fi
 
 cat >&2 <<EOF
-❌ Blocked: Direct edits to TypeORM migration files are not allowed.
+❌ Blocked: This default hook refuses Write/Edit on TypeORM migration files.
 
 File: $FILE_PATH
 
@@ -110,20 +112,14 @@ artifact — generate them from entity diffs:
   2. Run: bun run migration:generate --name=<DescriptiveName>
   3. Review the generated migration; commit entity + migration together.
 
-If a schema change cannot be expressed via the entity model, the entity
-model is wrong — fix the entity, do not hand-write the migration.
+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.
 
-OUT-OF-BAND MIGRATIONS (seed data, backfills, data transformations,
-one-off cleanup): these genuinely cannot come from entity diffs. They
-are legitimate but they bypass the entity-as-source-of-truth contract.
-
-If you believe this edit is an out-of-band migration:
-  1. STOP and tell the user what change is needed and why it cannot
-     be expressed via the entity model.
-  2. Get explicit approval before proceeding.
-  3. Document the rationale in the migration's class comment.
-
-Do NOT silently hand-write a migration. See the nestjs-rules skill
-for the full rationale.
+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/src/nestjs/skills/nestjs-rules/SKILL.md

@@ -51,11 +51,9 @@ In this project, **entity files (`src/database/entities/*.ts`) are the single so
 2. Run `bun run migration:generate --name=<DescriptiveName>` to produce the migration from the diff.
 3. Review the generated migration, then commit both the entity change and the migration together.
 
-If a schema change cannot be expressed via the entity model, the entity model is wrong — fix the entity, do not hand-write the migration.
+### Generate Schema Migrations
 
-### Never Create Migration Files Manually
-
-Never create or modify a TypeORM migration file directly. Use `migration:generate` from `package.json`:
+Use `migration:generate` from `package.json` for changes represented by entity metadata:
 
 ```bash
 bun run migration:generate --name=<DescriptiveName>
@@ -69,18 +67,15 @@ Some changes genuinely cannot be derived from entity diffs:
 - **Data backfills** (populating a new column from existing rows)
 - **Data transformations** (splitting a column, normalizing values)
 - **One-off cleanup** (deleting orphaned rows before a constraint is added)
+- **Database maintenance** (refreshing planner statistics with `ANALYZE`)
 
-These are legitimate cases for a hand-written migration, but they are **out-of-band** — they bypass the entity-as-source-of-truth contract. When you encounter one:
-
-1. **Stop and tell the user.** Explain what change is needed and why it cannot be expressed via the entity model.
-2. **Get explicit approval** before writing the migration by hand.
-3. Document the rationale in the migration's class comment so future readers understand why this one was not generated.
+Use the project's established migration process for these cases. Document the rationale and verification in the migration's class comment so future readers understand why it was not generated. Apply the authorization already given for the work; the default edit hook does not record or verify human approval.
 
-Do not silently hand-write a migration for a backfill or seed-data change. The user must know that the entity-as-source-of-truth contract is being intentionally bypassed for this case.
+A project that supports direct migration edits can declare its own `migration-provenance` check at `pre-tool` in `.lisa.config.json`. The Claude and Codex hooks run that check for the targeted migration and permit the edit only when it passes. The check must validate the project's migration policy; an unconditional success command proves nothing. Without a declared check, the built-in still refuses the edit. OpenCode's migration adapter currently does not support this exception path and continues to refuse it.
 
 ### Enforcement
 
-The `lisa-nestjs` plugin ships a `PreToolUse` hook (`block-migration-edits.sh`) that blocks `Write`/`Edit` on any path matching `**/migrations/*.ts` or `**/migrations/*.js`. The block surfaces this rule's guidance to remind you to either (a) edit the entity instead, or (b) ask the user before proceeding with an out-of-band migration.
+The `lisa-nestjs` plugin's default `PreToolUse` hook (`block-migration-edits.sh`) refuses `Write`/`Edit` on paths matching `**/migrations/*.ts` or `**/migrations/*.js`. Codex also inspects `apply_patch`; its migration matcher and OpenCode's matcher cover numbered TypeScript migration filenames. These are direct-edit checks, not an audit of migration authorship: they do not inspect Bash writes. Do not switch tools to evade a refusal. Use the supported project check where available.
 
 ### Why Auto-Generation