@codyswann/lisa 4.29.8 → 4.29.10

package/dist/migrations/ensure-seeded-gates.d.ts

@@ -19,8 +19,17 @@ import type { Migration, MigrationContext, MigrationResult } from "./migration.i
  * ungoverned — and stays reported by `lisa-gates.mjs unconfigured`, which the
  * pre-push hook and every gated CI job now print. Visible beats declared-away.
  *
+ * WHY AN INSTALL DOES NOT DO IT. This is a migration on `lisa apply`, and the
+ * package-manager install lifecycle runs an apply too — so without a guard the
+ * seeding would happen on `bun install`, which is nobody's request to change
+ * what their repository requires of a push. In `postinstall-safe` mode it
+ * therefore declines and reports what it withheld; see {@link
+ * EnsureSeededGatesMigration.refuse}.
+ *
  * Idempotent: an existing declaration always wins, so a second run seeds
- * nothing. Never removes or rewrites a declaration the project made.
+ * nothing. Never removes or rewrites a declaration the project made, and never
+ * moves one — including `gates.runner`, which is not a gate and is passed
+ * through untouched.
  */
 export declare class EnsureSeededGatesMigration implements Migration {
     readonly name = "ensure-seeded-gates";
@@ -38,10 +47,42 @@ export declare class EnsureSeededGatesMigration implements Migration {
      */
     applies(ctx: MigrationContext): Promise<boolean>;
     /**
-     * Write the seeded declarations into `.lisa.config.json`.
+     * Write the seeded declarations into `.lisa.config.json`, unless this apply
+     * is a package manager's install — in which case report and write nothing.
      * @param ctx - Migration context
      * @returns Result describing the action taken
      */
     apply(ctx: MigrationContext): Promise<MigrationResult>;
+    /**
+     * Decline to seed during a package manager's install, and say what was
+     * declined and how to get it deliberately.
+     *
+     * WHY AN INSTALL MAY NOT DO THIS. What this migration writes is not a
+     * generated file — it is the project's declaration of what its own pushes
+     * and pull requests must prove, checked in and reviewed like any other
+     * contract. Seeding is a legitimate change to make; making it during
+     * `bun install` is not, because nobody typed that command meaning to change
+     * what the repository requires. Measured in a caller repo in the portfolio:
+     * an install added `dependency-vulnerability` at `push` as `required`, the
+     * change appeared only as one modified file in `git status`, four different
+     * agents on four different branches each stashed it as not-theirs, and any
+     * one routine `git add -A` would have committed a CI-contract change nobody
+     * authored (CodySwannGT/lisa#3574).
+     *
+     * The direction observed there was tightening, which is the lucky case. The
+     * same silence would carry a LOOSENED gate identically — one modified JSON
+     * file, nothing in the signal distinguishing the two — so the rule is about
+     * who asked, not about which way the change points.
+     *
+     * WHY IT REPORTS RATHER THAN GOING QUIET. A migration that simply skipped
+     * here would be this codebase's signature defect: work that stops happening
+     * with nothing anywhere saying so. The seeding is still wanted — it is how a
+     * hardcoded fallback gets retired — so the install names every declaration
+     * it withheld and the one command that applies them into a reviewable diff.
+     * @param ctx - Migration context
+     * @param plan - What seeding would have written
+     * @returns A skipped result carrying the operator-readable explanation
+     */
+    private refuse;
 }
 //# sourceMappingURL=ensure-seeded-gates.d.ts.map

package/dist/migrations/ensure-seeded-gates.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"ensure-seeded-gates.d.ts","sourceRoot":"","sources":["../../src/migrations/ensure-seeded-gates.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EACV,SAAS,EACT,gBAAgB,EAChB,eAAe,EAChB,MAAM,0BAA0B,CAAC;AA+DlC;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,qBAAa,0BAA2B,YAAW,SAAS;IAC1D,QAAQ,CAAC,IAAI,yBAAyB;IACtC,QAAQ,CAAC,WAAW,8GACyF;IAE7G;;;;OAIG;YACW,IAAI;IAoClB;;;;OAIG;IACG,OAAO,CAAC,GAAG,EAAE,gBAAgB,GAAG,OAAO,CAAC,OAAO,CAAC;IAItD;;;;OAIG;IACG,KAAK,CAAC,GAAG,EAAE,gBAAgB,GAAG,OAAO,CAAC,eAAe,CAAC;CAyB7D"}
+{"version":3,"file":"ensure-seeded-gates.d.ts","sourceRoot":"","sources":["../../src/migrations/ensure-seeded-gates.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EACV,SAAS,EACT,gBAAgB,EAChB,eAAe,EAChB,MAAM,0BAA0B,CAAC;AAmElC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+BG;AACH,qBAAa,0BAA2B,YAAW,SAAS;IAC1D,QAAQ,CAAC,IAAI,yBAAyB;IACtC,QAAQ,CAAC,WAAW,8GACyF;IAE7G;;;;OAIG;YACW,IAAI;IAgDlB;;;;OAIG;IACG,OAAO,CAAC,GAAG,EAAE,gBAAgB,GAAG,OAAO,CAAC,OAAO,CAAC;IAItD;;;;;OAKG;IACG,KAAK,CAAC,GAAG,EAAE,gBAAgB,GAAG,OAAO,CAAC,eAAe,CAAC;IA2B5D;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA6BG;IACH,OAAO,CAAC,MAAM;CA6Bf"}

package/dist/migrations/ensure-seeded-gates.js

@@ -50,8 +50,17 @@ async function detectRunner(projectDir) {
  * ungoverned — and stays reported by `lisa-gates.mjs unconfigured`, which the
  * pre-push hook and every gated CI job now print. Visible beats declared-away.
  *
+ * WHY AN INSTALL DOES NOT DO IT. This is a migration on `lisa apply`, and the
+ * package-manager install lifecycle runs an apply too — so without a guard the
+ * seeding would happen on `bun install`, which is nobody's request to change
+ * what their repository requires of a push. In `postinstall-safe` mode it
+ * therefore declines and reports what it withheld; see {@link
+ * EnsureSeededGatesMigration.refuse}.
+ *
  * Idempotent: an existing declaration always wins, so a second run seeds
- * nothing. Never removes or rewrites a declaration the project made.
+ * nothing. Never removes or rewrites a declaration the project made, and never
+ * moves one — including `gates.runner`, which is not a gate and is passed
+ * through untouched.
  */
 export class EnsureSeededGatesMigration {
     name = "ensure-seeded-gates";
@@ -76,9 +85,20 @@ export class EnsureSeededGatesMigration {
         const registry = await importGateRegistry();
         if (registry === null)
             return null;
-        const { runner: declaredRunner, ...gates } = config.gates ?? {};
+        // READ `runner`, do not SPLIT IT OUT. The previous form destructured it
+        // (`const { runner, ...gates }`) purely to obtain the declared value, and
+        // the rest-spread that came free with that syntax dropped the key from the
+        // block — so `seedGates` re-appended it at the END, moving a key the
+        // project had placed somewhere else. That is a change to a checked-in file
+        // that says nothing and means nothing, and it landed in consumers as an
+        // unexplained line in `git status`. `seedGates` only ever writes keys that
+        // are gate ids, and `runner` is not one, so passing the block whole is
+        // equally safe and leaves every declared key exactly where its author put
+        // it.
+        const gates = config.gates ?? {};
+        const declaredRunner = gates.runner;
         const result = registry.seedGates({
-            gates: gates,
+            gates,
             scripts: manifest.scripts ?? {},
             runner: typeof declaredRunner === "string"
                 ? declaredRunner
@@ -93,6 +113,7 @@ export class EnsureSeededGatesMigration {
             seeded: result.seeded.map(entry => ({
                 gate: entry.gate,
                 moment: entry.moment,
+                run: entry.run,
             })),
         };
     }
@@ -105,7 +126,8 @@ export class EnsureSeededGatesMigration {
         return (await this.plan(ctx)) !== null;
     }
     /**
-     * Write the seeded declarations into `.lisa.config.json`.
+     * Write the seeded declarations into `.lisa.config.json`, unless this apply
+     * is a package manager's install — in which case report and write nothing.
      * @param ctx - Migration context
      * @returns Result describing the action taken
      */
@@ -113,6 +135,8 @@ export class EnsureSeededGatesMigration {
         const plan = await this.plan(ctx);
         if (plan === null)
             return { name: this.name, action: "noop" };
+        if (ctx.postinstallSafe === true)
+            return this.refuse(ctx, plan);
         const declared = plan.seeded
             .map(entry => `${entry.gate}@${entry.moment}`)
             .join(", ");
@@ -135,5 +159,59 @@ export class EnsureSeededGatesMigration {
             message,
         };
     }
+    /**
+     * Decline to seed during a package manager's install, and say what was
+     * declined and how to get it deliberately.
+     *
+     * WHY AN INSTALL MAY NOT DO THIS. What this migration writes is not a
+     * generated file — it is the project's declaration of what its own pushes
+     * and pull requests must prove, checked in and reviewed like any other
+     * contract. Seeding is a legitimate change to make; making it during
+     * `bun install` is not, because nobody typed that command meaning to change
+     * what the repository requires. Measured in a caller repo in the portfolio:
+     * an install added `dependency-vulnerability` at `push` as `required`, the
+     * change appeared only as one modified file in `git status`, four different
+     * agents on four different branches each stashed it as not-theirs, and any
+     * one routine `git add -A` would have committed a CI-contract change nobody
+     * authored (CodySwannGT/lisa#3574).
+     *
+     * The direction observed there was tightening, which is the lucky case. The
+     * same silence would carry a LOOSENED gate identically — one modified JSON
+     * file, nothing in the signal distinguishing the two — so the rule is about
+     * who asked, not about which way the change points.
+     *
+     * WHY IT REPORTS RATHER THAN GOING QUIET. A migration that simply skipped
+     * here would be this codebase's signature defect: work that stops happening
+     * with nothing anywhere saying so. The seeding is still wanted — it is how a
+     * hardcoded fallback gets retired — so the install names every declaration
+     * it withheld and the one command that applies them into a reviewable diff.
+     * @param ctx - Migration context
+     * @param plan - What seeding would have written
+     * @returns A skipped result carrying the operator-readable explanation
+     */
+    refuse(ctx, plan) {
+        const lines = plan.seeded.map(entry => `    • ${entry.gate} at ${entry.moment} → required${entry.run === null ? "" : ` (runs \`${entry.run}\`)`}`);
+        const message = [
+            `Left ${LISA_CONFIG} unchanged: an install must not change what this repository requires of a push.`,
+            "",
+            `  Lisa would declare ${plan.seeded.length} gate(s) that a Lisa-shipped hook or workflow is already running here:`,
+            "",
+            ...lines,
+            "",
+            "  Nothing is enforced any differently until you apply them — those checks",
+            "  already run. Declaring them is what lets the project control them.",
+            "",
+            "  To apply them deliberately, so the change lands in a commit somebody reviews:",
+            "",
+            "      npx @codyswann/lisa@latest .",
+        ].join("\n");
+        ctx.logger.warn(message);
+        return {
+            name: this.name,
+            action: "skipped",
+            changedFiles: [],
+            message,
+        };
+    }
 }
 //# sourceMappingURL=ensure-seeded-gates.js.map

package/dist/migrations/ensure-seeded-gates.js.map

@@ -1 +1 @@
-{"version":3,"file":"ensure-seeded-gates.js","sourceRoot":"","sources":["../../src/migrations/ensure-seeded-gates.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,IAAI,MAAM,WAAW,CAAC;AAClC,OAAO,KAAK,GAAG,MAAM,UAAU,CAAC;AAChC,OAAO,EAAE,kBAAkB,EAAE,MAAM,gCAAgC,CAAC;AACpE,OAAO,EAAE,cAAc,EAAE,SAAS,EAAE,MAAM,wBAAwB,CAAC;AAOnE,MAAM,WAAW,GAAG,mBAAmB,CAAC;AACxC,MAAM,YAAY,GAAG,cAAc,CAAC;AAkCpC;;;;;;;;;;;;;;;;;GAiBG;AACH,KAAK,UAAU,YAAY,CAAC,UAAkB;IAC5C,MAAM,GAAG,GAAG,KAAK,EAAE,IAAY,EAAoB,EAAE,CACnD,GAAG,CAAC,UAAU,CAAC,IAAI,CAAC,IAAI,CAAC,UAAU,EAAE,IAAI,CAAC,CAAC,CAAC;IAC9C,IAAI,CAAC,MAAM,GAAG,CAAC,WAAW,CAAC,CAAC,IAAI,CAAC,MAAM,GAAG,CAAC,UAAU,CAAC,CAAC;QAAE,OAAO,SAAS,CAAC;IAC1E,IAAI,MAAM,GAAG,CAAC,WAAW,CAAC;QAAE,OAAO,MAAM,CAAC;IAC1C,OAAO,SAAS,CAAC;AACnB,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,MAAM,OAAO,0BAA0B;IAC5B,IAAI,GAAG,qBAAqB,CAAC;IAC7B,WAAW,GAClB,0GAA0G,CAAC;IAE7G;;;;OAIG;IACK,KAAK,CAAC,IAAI,CAAC,GAAqB;QACtC,MAAM,UAAU,GAAG,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC,UAAU,EAAE,WAAW,CAAC,CAAC;QAC1D,MAAM,MAAM,GAAG,MAAM,cAAc,CAAa,UAAU,CAAC,CAAC;QAC5D,2EAA2E;QAC3E,2EAA2E;QAC3E,uEAAuE;QACvE,kBAAkB;QAClB,IAAI,MAAM,KAAK,IAAI;YAAE,OAAO,IAAI,CAAC;QACjC,MAAM,QAAQ,GAAG,MAAM,cAAc,CACnC,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC,UAAU,EAAE,YAAY,CAAC,CACxC,CAAC;QACF,IAAI,QAAQ,KAAK,IAAI;YAAE,OAAO,IAAI,CAAC;QACnC,MAAM,QAAQ,GAAG,MAAM,kBAAkB,EAAsB,CAAC;QAChE,IAAI,QAAQ,KAAK,IAAI;YAAE,OAAO,IAAI,CAAC;QAEnC,MAAM,EAAE,MAAM,EAAE,cAAc,EAAE,GAAG,KAAK,EAAE,GAAG,MAAM,CAAC,KAAK,IAAI,EAAE,CAAC;QAChE,MAAM,MAAM,GAAG,QAAQ,CAAC,SAAS,CAAC;YAChC,KAAK,EAAE,KAAgC;YACvC,OAAO,EAAE,QAAQ,CAAC,OAAO,IAAI,EAAE;YAC/B,MAAM,EACJ,OAAO,cAAc,KAAK,QAAQ;gBAChC,CAAC,CAAC,cAAc;gBAChB,CAAC,CAAC,MAAM,YAAY,CAAC,GAAG,CAAC,UAAU,CAAC;SACzC,CAAC,CAAC;QACH,IAAI,MAAM,CAAC,MAAM,CAAC,MAAM,KAAK,CAAC;YAAE,OAAO,IAAI,CAAC;QAC5C,OAAO;YACL,UAAU;YACV,MAAM;YACN,KAAK,EAAE,MAAM,CAAC,KAAK;YACnB,MAAM,EAAE,MAAM,CAAC,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,EAAE,CAAC,CAAC;gBAClC,IAAI,EAAE,KAAK,CAAC,IAAI;gBAChB,MAAM,EAAE,KAAK,CAAC,MAAM;aACrB,CAAC,CAAC;SACJ,CAAC;IACJ,CAAC;IAED;;;;OAIG;IACH,KAAK,CAAC,OAAO,CAAC,GAAqB;QACjC,OAAO,CAAC,MAAM,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,KAAK,IAAI,CAAC;IACzC,CAAC;IAED;;;;OAIG;IACH,KAAK,CAAC,KAAK,CAAC,GAAqB;QAC/B,MAAM,IAAI,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;QAClC,IAAI,IAAI,KAAK,IAAI;YAAE,OAAO,EAAE,IAAI,EAAE,IAAI,CAAC,IAAI,EAAE,MAAM,EAAE,MAAM,EAAE,CAAC;QAC9D,MAAM,QAAQ,GAAG,IAAI,CAAC,MAAM;aACzB,GAAG,CAAC,KAAK,CAAC,EAAE,CAAC,GAAG,KAAK,CAAC,IAAI,IAAI,KAAK,CAAC,MAAM,EAAE,CAAC;aAC7C,IAAI,CAAC,IAAI,CAAC,CAAC;QACd,MAAM,OAAO,GAAG,YAAY,IAAI,CAAC,MAAM,CAAC,MAAM,eAAe,WAAW,8EAA8E,QAAQ,EAAE,CAAC;QACjK,IAAI,GAAG,CAAC,MAAM,EAAE,CAAC;YACf,GAAG,CAAC,MAAM,CAAC,GAAG,CAAC,cAAc,IAAI,CAAC,MAAM,CAAC,MAAM,sBAAsB,CAAC,CAAC;YACvE,OAAO;gBACL,IAAI,EAAE,IAAI,CAAC,IAAI;gBACf,MAAM,EAAE,SAAS;gBACjB,YAAY,EAAE,CAAC,WAAW,CAAC;gBAC3B,OAAO;aACR,CAAC;QACJ,CAAC;QACD,MAAM,SAAS,CAAC,IAAI,CAAC,UAAU,EAAE,EAAE,GAAG,IAAI,CAAC,MAAM,EAAE,KAAK,EAAE,IAAI,CAAC,KAAK,EAAE,CAAC,CAAC;QACxE,GAAG,CAAC,MAAM,CAAC,OAAO,CAAC,OAAO,CAAC,CAAC;QAC5B,OAAO;YACL,IAAI,EAAE,IAAI,CAAC,IAAI;YACf,MAAM,EAAE,SAAS;YACjB,YAAY,EAAE,CAAC,WAAW,CAAC;YAC3B,OAAO;SACR,CAAC;IACJ,CAAC;CACF"}
+{"version":3,"file":"ensure-seeded-gates.js","sourceRoot":"","sources":["../../src/migrations/ensure-seeded-gates.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,IAAI,MAAM,WAAW,CAAC;AAClC,OAAO,KAAK,GAAG,MAAM,UAAU,CAAC;AAChC,OAAO,EAAE,kBAAkB,EAAE,MAAM,gCAAgC,CAAC;AACpE,OAAO,EAAE,cAAc,EAAE,SAAS,EAAE,MAAM,wBAAwB,CAAC;AAOnE,MAAM,WAAW,GAAG,mBAAmB,CAAC;AACxC,MAAM,YAAY,GAAG,cAAc,CAAC;AAsCpC;;;;;;;;;;;;;;;;;GAiBG;AACH,KAAK,UAAU,YAAY,CAAC,UAAkB;IAC5C,MAAM,GAAG,GAAG,KAAK,EAAE,IAAY,EAAoB,EAAE,CACnD,GAAG,CAAC,UAAU,CAAC,IAAI,CAAC,IAAI,CAAC,UAAU,EAAE,IAAI,CAAC,CAAC,CAAC;IAC9C,IAAI,CAAC,MAAM,GAAG,CAAC,WAAW,CAAC,CAAC,IAAI,CAAC,MAAM,GAAG,CAAC,UAAU,CAAC,CAAC;QAAE,OAAO,SAAS,CAAC;IAC1E,IAAI,MAAM,GAAG,CAAC,WAAW,CAAC;QAAE,OAAO,MAAM,CAAC;IAC1C,OAAO,SAAS,CAAC;AACnB,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+BG;AACH,MAAM,OAAO,0BAA0B;IAC5B,IAAI,GAAG,qBAAqB,CAAC;IAC7B,WAAW,GAClB,0GAA0G,CAAC;IAE7G;;;;OAIG;IACK,KAAK,CAAC,IAAI,CAAC,GAAqB;QACtC,MAAM,UAAU,GAAG,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC,UAAU,EAAE,WAAW,CAAC,CAAC;QAC1D,MAAM,MAAM,GAAG,MAAM,cAAc,CAAa,UAAU,CAAC,CAAC;QAC5D,2EAA2E;QAC3E,2EAA2E;QAC3E,uEAAuE;QACvE,kBAAkB;QAClB,IAAI,MAAM,KAAK,IAAI;YAAE,OAAO,IAAI,CAAC;QACjC,MAAM,QAAQ,GAAG,MAAM,cAAc,CACnC,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC,UAAU,EAAE,YAAY,CAAC,CACxC,CAAC;QACF,IAAI,QAAQ,KAAK,IAAI;YAAE,OAAO,IAAI,CAAC;QACnC,MAAM,QAAQ,GAAG,MAAM,kBAAkB,EAAsB,CAAC;QAChE,IAAI,QAAQ,KAAK,IAAI;YAAE,OAAO,IAAI,CAAC;QAEnC,wEAAwE;QACxE,0EAA0E;QAC1E,2EAA2E;QAC3E,qEAAqE;QACrE,2EAA2E;QAC3E,wEAAwE;QACxE,2EAA2E;QAC3E,uEAAuE;QACvE,0EAA0E;QAC1E,MAAM;QACN,MAAM,KAAK,GAAG,MAAM,CAAC,KAAK,IAAI,EAAE,CAAC;QACjC,MAAM,cAAc,GAAG,KAAK,CAAC,MAAM,CAAC;QACpC,MAAM,MAAM,GAAG,QAAQ,CAAC,SAAS,CAAC;YAChC,KAAK;YACL,OAAO,EAAE,QAAQ,CAAC,OAAO,IAAI,EAAE;YAC/B,MAAM,EACJ,OAAO,cAAc,KAAK,QAAQ;gBAChC,CAAC,CAAC,cAAc;gBAChB,CAAC,CAAC,MAAM,YAAY,CAAC,GAAG,CAAC,UAAU,CAAC;SACzC,CAAC,CAAC;QACH,IAAI,MAAM,CAAC,MAAM,CAAC,MAAM,KAAK,CAAC;YAAE,OAAO,IAAI,CAAC;QAC5C,OAAO;YACL,UAAU;YACV,MAAM;YACN,KAAK,EAAE,MAAM,CAAC,KAAK;YACnB,MAAM,EAAE,MAAM,CAAC,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,EAAE,CAAC,CAAC;gBAClC,IAAI,EAAE,KAAK,CAAC,IAAI;gBAChB,MAAM,EAAE,KAAK,CAAC,MAAM;gBACpB,GAAG,EAAE,KAAK,CAAC,GAAG;aACf,CAAC,CAAC;SACJ,CAAC;IACJ,CAAC;IAED;;;;OAIG;IACH,KAAK,CAAC,OAAO,CAAC,GAAqB;QACjC,OAAO,CAAC,MAAM,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,KAAK,IAAI,CAAC;IACzC,CAAC;IAED;;;;;OAKG;IACH,KAAK,CAAC,KAAK,CAAC,GAAqB;QAC/B,MAAM,IAAI,GAAG,MAAM,IAAI,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;QAClC,IAAI,IAAI,KAAK,IAAI;YAAE,OAAO,EAAE,IAAI,EAAE,IAAI,CAAC,IAAI,EAAE,MAAM,EAAE,MAAM,EAAE,CAAC;QAC9D,IAAI,GAAG,CAAC,eAAe,KAAK,IAAI;YAAE,OAAO,IAAI,CAAC,MAAM,CAAC,GAAG,EAAE,IAAI,CAAC,CAAC;QAChE,MAAM,QAAQ,GAAG,IAAI,CAAC,MAAM;aACzB,GAAG,CAAC,KAAK,CAAC,EAAE,CAAC,GAAG,KAAK,CAAC,IAAI,IAAI,KAAK,CAAC,MAAM,EAAE,CAAC;aAC7C,IAAI,CAAC,IAAI,CAAC,CAAC;QACd,MAAM,OAAO,GAAG,YAAY,IAAI,CAAC,MAAM,CAAC,MAAM,eAAe,WAAW,8EAA8E,QAAQ,EAAE,CAAC;QACjK,IAAI,GAAG,CAAC,MAAM,EAAE,CAAC;YACf,GAAG,CAAC,MAAM,CAAC,GAAG,CAAC,cAAc,IAAI,CAAC,MAAM,CAAC,MAAM,sBAAsB,CAAC,CAAC;YACvE,OAAO;gBACL,IAAI,EAAE,IAAI,CAAC,IAAI;gBACf,MAAM,EAAE,SAAS;gBACjB,YAAY,EAAE,CAAC,WAAW,CAAC;gBAC3B,OAAO;aACR,CAAC;QACJ,CAAC;QACD,MAAM,SAAS,CAAC,IAAI,CAAC,UAAU,EAAE,EAAE,GAAG,IAAI,CAAC,MAAM,EAAE,KAAK,EAAE,IAAI,CAAC,KAAK,EAAE,CAAC,CAAC;QACxE,GAAG,CAAC,MAAM,CAAC,OAAO,CAAC,OAAO,CAAC,CAAC;QAC5B,OAAO;YACL,IAAI,EAAE,IAAI,CAAC,IAAI;YACf,MAAM,EAAE,SAAS;YACjB,YAAY,EAAE,CAAC,WAAW,CAAC;YAC3B,OAAO;SACR,CAAC;IACJ,CAAC;IAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA6BG;IACK,MAAM,CAAC,GAAqB,EAAE,IAAc;QAClD,MAAM,KAAK,GAAG,IAAI,CAAC,MAAM,CAAC,GAAG,CAC3B,KAAK,CAAC,EAAE,CACN,SAAS,KAAK,CAAC,IAAI,OAAO,KAAK,CAAC,MAAM,cACpC,KAAK,CAAC,GAAG,KAAK,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,YAAY,KAAK,CAAC,GAAG,KACjD,EAAE,CACL,CAAC;QACF,MAAM,OAAO,GAAG;YACd,QAAQ,WAAW,iFAAiF;YACpG,EAAE;YACF,wBAAwB,IAAI,CAAC,MAAM,CAAC,MAAM,wEAAwE;YAClH,EAAE;YACF,GAAG,KAAK;YACR,EAAE;YACF,2EAA2E;YAC3E,sEAAsE;YACtE,EAAE;YACF,iFAAiF;YACjF,EAAE;YACF,oCAAoC;SACrC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;QACb,GAAG,CAAC,MAAM,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;QACzB,OAAO;YACL,IAAI,EAAE,IAAI,CAAC,IAAI;YACf,MAAM,EAAE,SAAS;YACjB,YAAY,EAAE,EAAE;YAChB,OAAO;SACR,CAAC;IACJ,CAAC;CACF"}

package/dist/migrations/migration.interface.d.ts

@@ -16,6 +16,24 @@ export interface MigrationContext {
     readonly detectedTypes: readonly ProjectType[];
     /** If true, describe what would change without modifying files */
     readonly dryRun: boolean;
+    /**
+     * True when this apply is the reduced subset a package manager's install
+     * lifecycle runs — the mode `--postinstall-safe` / `LISA_POSTINSTALL=1`
+     * selects (see `core/apply-mode.ts`).
+     *
+     * A migration reads this to answer one question: "did an operator ask for
+     * this, or did a dependency install?" Nobody types `bun install` meaning to
+     * change what their repository requires of a push, so a migration that
+     * rewrites a REVIEWED, checked-in declaration must decline here and report
+     * instead. Migrations that only reconcile generated or ignored files have no
+     * reason to read it.
+     *
+     * Optional, and absent means the full apply an operator invoked. That is the
+     * safe default for the reading above — a context that never learned the
+     * answer behaves as though a human is standing there, which is exactly the
+     * case where writing is legitimate.
+     */
+    readonly postinstallSafe?: boolean;
     /** Logger for user-facing output */
     readonly logger: ILogger;
 }

package/dist/migrations/migration.interface.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"migration.interface.d.ts","sourceRoot":"","sources":["../../src/migrations/migration.interface.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,mBAAmB,CAAC;AACrD,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,qBAAqB,CAAC;AAEnD;;GAEG;AACH,MAAM,MAAM,eAAe,GAAG,SAAS,GAAG,SAAS,GAAG,MAAM,CAAC;AAE7D;;GAEG;AACH,MAAM,WAAW,gBAAgB;IAC/B,oCAAoC;IACpC,QAAQ,CAAC,UAAU,EAAE,MAAM,CAAC;IAE5B,yDAAyD;IACzD,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;IAEzB,yDAAyD;IACzD,QAAQ,CAAC,aAAa,EAAE,SAAS,WAAW,EAAE,CAAC;IAE/C,kEAAkE;IAClE,QAAQ,CAAC,MAAM,EAAE,OAAO,CAAC;IAEzB,oCAAoC;IACpC,QAAQ,CAAC,MAAM,EAAE,OAAO,CAAC;CAC1B;AAED;;GAEG;AACH,MAAM,WAAW,eAAe;IAC9B,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IACtB,QAAQ,CAAC,MAAM,EAAE,eAAe,CAAC;IACjC,QAAQ,CAAC,YAAY,CAAC,EAAE,SAAS,MAAM,EAAE,CAAC;IAC1C,QAAQ,CAAC,OAAO,CAAC,EAAE,MAAM,CAAC;CAC3B;AAED;;GAEG;AACH,MAAM,WAAW,SAAS;IACxB,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IACtB,QAAQ,CAAC,WAAW,EAAE,MAAM,CAAC;IAE7B;;;;;;OAMG;IACH,gBAAgB,CAAC,CAAC,GAAG,EAAE,gBAAgB,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;IAExD;;;OAGG;IACH,OAAO,CAAC,GAAG,EAAE,gBAAgB,GAAG,OAAO,CAAC,OAAO,CAAC,CAAC;IAEjD;;;OAGG;IACH,KAAK,CAAC,GAAG,EAAE,gBAAgB,GAAG,OAAO,CAAC,eAAe,CAAC,CAAC;CACxD"}
+{"version":3,"file":"migration.interface.d.ts","sourceRoot":"","sources":["../../src/migrations/migration.interface.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,mBAAmB,CAAC;AACrD,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,qBAAqB,CAAC;AAEnD;;GAEG;AACH,MAAM,MAAM,eAAe,GAAG,SAAS,GAAG,SAAS,GAAG,MAAM,CAAC;AAE7D;;GAEG;AACH,MAAM,WAAW,gBAAgB;IAC/B,oCAAoC;IACpC,QAAQ,CAAC,UAAU,EAAE,MAAM,CAAC;IAE5B,yDAAyD;IACzD,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;IAEzB,yDAAyD;IACzD,QAAQ,CAAC,aAAa,EAAE,SAAS,WAAW,EAAE,CAAC;IAE/C,kEAAkE;IAClE,QAAQ,CAAC,MAAM,EAAE,OAAO,CAAC;IAEzB;;;;;;;;;;;;;;;;OAgBG;IACH,QAAQ,CAAC,eAAe,CAAC,EAAE,OAAO,CAAC;IAEnC,oCAAoC;IACpC,QAAQ,CAAC,MAAM,EAAE,OAAO,CAAC;CAC1B;AAED;;GAEG;AACH,MAAM,WAAW,eAAe;IAC9B,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IACtB,QAAQ,CAAC,MAAM,EAAE,eAAe,CAAC;IACjC,QAAQ,CAAC,YAAY,CAAC,EAAE,SAAS,MAAM,EAAE,CAAC;IAC1C,QAAQ,CAAC,OAAO,CAAC,EAAE,MAAM,CAAC;CAC3B;AAED;;GAEG;AACH,MAAM,WAAW,SAAS;IACxB,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IACtB,QAAQ,CAAC,WAAW,EAAE,MAAM,CAAC;IAE7B;;;;;;OAMG;IACH,gBAAgB,CAAC,CAAC,GAAG,EAAE,gBAAgB,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;IAExD;;;OAGG;IACH,OAAO,CAAC,GAAG,EAAE,gBAAgB,GAAG,OAAO,CAAC,OAAO,CAAC,CAAC;IAEjD;;;OAGG;IACH,KAAK,CAAC,GAAG,EAAE,gBAAgB,GAAG,OAAO,CAAC,eAAe,CAAC,CAAC;CACxD"}

package/package.json

@@ -164,7 +164,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.29.8",
+  "version": "4.29.10",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -312,7 +312,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "57557f93211733f55333da42ab5c0590b3f1fa54",
-  "gitHead": "57557f93211733f55333da42ab5c0590b3f1fa54",
-  "lisaReleaseTag": "v4.29.8"
+  "lisaReleaseCommit": "8bd61916212e8db84f55b9a39fd71262c9981dca",
+  "gitHead": "8bd61916212e8db84f55b9a39fd71262c9981dca",
+  "lisaReleaseTag": "v4.29.10"
 }

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

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

package/plugins/lisa/.codex-plugin/skills/lisa-parity-sentry-sdk-setup/SKILL.md

@@ -2,7 +2,7 @@
 name: lisa-parity-sentry-sdk-setup
 description: "Install and configure the…"
 allowed-tools: ["Read", "Edit", "Write", "Bash"]
-synced-from: sentry@claude-plugins-official@1.3.2
+synced-from: sentry@claude-plugins-official@1.4.0
 ---
 
 # Sentry SDK Setup
@@ -19,9 +19,34 @@ setup skills**; this single Lisa-native skill consolidated all of them. As of
 upstream **1.2.0** Sentry itself consolidated the suite into one
 `sentry-instrument` playbook, so the shapes now match — but this skill remains a
 from-scratch reimplementation against Lisa conventions, **not** a translation of
-the upstream skill. Pinned to `sentry@claude-plugins-official@1.3.2` via
+the upstream skill. Pinned to `sentry@claude-plugins-official@1.4.0` via
 `synced-from` so the parity drift detector tracks it as one unit.
 
+### Reviewed at 1.4.0 — the progress-reporting protocol is deliberately declined
+
+Read the pin as **reviewed against 1.4.0**, not as *tracks 1.4.0*. The
+`synced-from` scalar cannot say which it means, so this section says it.
+
+Upstream 1.4.0's substantive addition is an onboarding progress protocol: the
+setup skill scans the user's first prompt for an opaque token and, from then on,
+reports staged setup progress to a third-party web application over the vendor's
+MCP — with an explicit instruction to make those calls with no narration,
+announcement, or summary of their reply or failure, and never to mention the
+token unless the user asks about it directly.
+
+**Lisa does not reimplement it, at 1.4.0 or on a later bump.** Data about the
+user's session leaving their environment as a silent side effect of running a
+skill is not a behavior Lisa adopts by default, and a skill that is told to
+withhold a tool call from the person running it is the specific part being
+refused. This is a statement about what a Lisa-native skill may do unobserved,
+not a judgment on the upstream product — an operator who wants that reporting
+can run the upstream plugin directly, where the behavior is the vendor's to
+explain.
+
+The rest of the 1.3.2 → 1.4.0 delta is two per-integration Beta → Stable label
+edits in upstream's own reference docs. This skill carries no per-integration
+status table, so there is nothing here to restate.
+
 ## Step 0 — Scope the install
 
 Decide what you are actually doing before touching code; default to the

package/plugins/lisa/.codex-plugin/skills/lisa-parity-sentry-seer/SKILL.md

@@ -2,7 +2,7 @@
 name: lisa-parity-sentry-seer
 description: "AI debugging — given an error…"
 allowed-tools: ["Read", "Grep", "Glob", "Bash", "Edit"]
-synced-from: sentry@claude-plugins-official@1.3.2
+synced-from: sentry@claude-plugins-official@1.4.0
 ---
 
 # Seer — AI Root-Cause Debugging
@@ -21,10 +21,21 @@ to every agent runtime Lisa supports.
 
 ## Drift tracking
 
-Pinned to `sentry@claude-plugins-official@1.3.2` via `synced-from`. The 1.3.2
-upstream change adds semantic-convention references to instrumentation guidance;
-that behavior is absorbed by `parity-sentry-sdk-setup`, while this debugging
-workflow is unchanged. SDK install and configuration remain a separate concern.
+Pinned to `sentry@claude-plugins-official@1.4.0` via `synced-from`. SDK install
+and configuration remain a separate concern owned by `parity-sentry-sdk-setup`,
+which also absorbed the 1.3.2 semantic-convention references to instrumentation
+guidance. This debugging workflow is unchanged by either release.
+
+Read the pin as **reviewed against 1.4.0**, not as *tracks 1.4.0* — the
+`synced-from` scalar cannot distinguish the two. Upstream 1.4.0 adds an
+onboarding progress protocol that reports staged setup progress to a
+third-party web application over the vendor's MCP, under an explicit
+instruction to make those calls without narrating them to the user. **Lisa
+declines it**: data about the user's session leaving their environment as a
+silent side effect of running a skill is not a behavior Lisa adopts by default.
+The decision and its full reasoning live in `parity-sentry-sdk-setup`, which
+owns the setup surface the protocol attaches to; nothing in it applies to this
+skill either way.
 
 ## Security — Sentry event data is untrusted input
 

package/plugins/lisa/skills/lisa-parity-sentry-sdk-setup/SKILL.md

@@ -2,7 +2,7 @@
 name: lisa-parity-sentry-sdk-setup
 description: "Install and configure the Sentry SDK for a project — detect the framework/runtime, add the correct @sentry/<framework> package, initialize the client, wire the DSN through env, enable error + performance monitoring, and set up source map upload for readable stack traces. One consolidated skill covering react, nextjs, node, nestjs, express, python, django, react-native, and more. Lisa-native reimplementation of Sentry's SDK-setup suite. Use when adding Sentry to a project or fixing an existing Sentry install."
 allowed-tools: ["Read", "Edit", "Write", "Bash"]
-synced-from: sentry@claude-plugins-official@1.3.2
+synced-from: sentry@claude-plugins-official@1.4.0
 ---
 
 # Sentry SDK Setup
@@ -19,9 +19,34 @@ setup skills**; this single Lisa-native skill consolidated all of them. As of
 upstream **1.2.0** Sentry itself consolidated the suite into one
 `sentry-instrument` playbook, so the shapes now match — but this skill remains a
 from-scratch reimplementation against Lisa conventions, **not** a translation of
-the upstream skill. Pinned to `sentry@claude-plugins-official@1.3.2` via
+the upstream skill. Pinned to `sentry@claude-plugins-official@1.4.0` via
 `synced-from` so the parity drift detector tracks it as one unit.
 
+### Reviewed at 1.4.0 — the progress-reporting protocol is deliberately declined
+
+Read the pin as **reviewed against 1.4.0**, not as *tracks 1.4.0*. The
+`synced-from` scalar cannot say which it means, so this section says it.
+
+Upstream 1.4.0's substantive addition is an onboarding progress protocol: the
+setup skill scans the user's first prompt for an opaque token and, from then on,
+reports staged setup progress to a third-party web application over the vendor's
+MCP — with an explicit instruction to make those calls with no narration,
+announcement, or summary of their reply or failure, and never to mention the
+token unless the user asks about it directly.
+
+**Lisa does not reimplement it, at 1.4.0 or on a later bump.** Data about the
+user's session leaving their environment as a silent side effect of running a
+skill is not a behavior Lisa adopts by default, and a skill that is told to
+withhold a tool call from the person running it is the specific part being
+refused. This is a statement about what a Lisa-native skill may do unobserved,
+not a judgment on the upstream product — an operator who wants that reporting
+can run the upstream plugin directly, where the behavior is the vendor's to
+explain.
+
+The rest of the 1.3.2 → 1.4.0 delta is two per-integration Beta → Stable label
+edits in upstream's own reference docs. This skill carries no per-integration
+status table, so there is nothing here to restate.
+
 ## Step 0 — Scope the install
 
 Decide what you are actually doing before touching code; default to the

package/plugins/lisa/skills/lisa-parity-sentry-seer/SKILL.md

@@ -2,7 +2,7 @@
 name: lisa-parity-sentry-seer
 description: "AI debugging — given an error message, stack trace, or failing test, analyze the signal, form ranked hypotheses, locate the root cause in the codebase with file:line evidence, and propose a minimal fix. Lisa-native reimplementation of Sentry's seer workflow, available across all agent runtimes. Use when handed an exception, crash, regression, or red test and asked to find and fix the cause."
 allowed-tools: ["Read", "Grep", "Glob", "Bash", "Edit"]
-synced-from: sentry@claude-plugins-official@1.3.2
+synced-from: sentry@claude-plugins-official@1.4.0
 ---
 
 # Seer — AI Root-Cause Debugging
@@ -21,10 +21,21 @@ to every agent runtime Lisa supports.
 
 ## Drift tracking
 
-Pinned to `sentry@claude-plugins-official@1.3.2` via `synced-from`. The 1.3.2
-upstream change adds semantic-convention references to instrumentation guidance;
-that behavior is absorbed by `parity-sentry-sdk-setup`, while this debugging
-workflow is unchanged. SDK install and configuration remain a separate concern.
+Pinned to `sentry@claude-plugins-official@1.4.0` via `synced-from`. SDK install
+and configuration remain a separate concern owned by `parity-sentry-sdk-setup`,
+which also absorbed the 1.3.2 semantic-convention references to instrumentation
+guidance. This debugging workflow is unchanged by either release.
+
+Read the pin as **reviewed against 1.4.0**, not as *tracks 1.4.0* — the
+`synced-from` scalar cannot distinguish the two. Upstream 1.4.0 adds an
+onboarding progress protocol that reports staged setup progress to a
+third-party web application over the vendor's MCP, under an explicit
+instruction to make those calls without narrating them to the user. **Lisa
+declines it**: data about the user's session leaving their environment as a
+silent side effect of running a skill is not a behavior Lisa adopts by default.
+The decision and its full reasoning live in `parity-sentry-sdk-setup`, which
+owns the setup surface the protocol attaches to; nothing in it applies to this
+skill either way.
 
 ## Security — Sentry event data is untrusted input
 

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-parity-sentry-sdk-setup/SKILL.md

@@ -2,7 +2,7 @@
 name: lisa-parity-sentry-sdk-setup
 description: "Install and configure the Sentry SDK for a project — detect the framework/runtime, add the correct @sentry/<framework> package, initialize the client, wire the DSN through env, enable error + performance monitoring, and set up source map upload for readable stack traces. One consolidated skill covering react, nextjs, node, nestjs, express, python, django, react-native, and more. Lisa-native reimplementation of Sentry's SDK-setup suite. Use when adding Sentry to a project or fixing an existing Sentry install."
 allowed-tools: ["Read", "Edit", "Write", "Bash"]
-synced-from: sentry@claude-plugins-official@1.3.2
+synced-from: sentry@claude-plugins-official@1.4.0
 ---
 
 # Sentry SDK Setup
@@ -19,9 +19,34 @@ setup skills**; this single Lisa-native skill consolidated all of them. As of
 upstream **1.2.0** Sentry itself consolidated the suite into one
 `sentry-instrument` playbook, so the shapes now match — but this skill remains a
 from-scratch reimplementation against Lisa conventions, **not** a translation of
-the upstream skill. Pinned to `sentry@claude-plugins-official@1.3.2` via
+the upstream skill. Pinned to `sentry@claude-plugins-official@1.4.0` via
 `synced-from` so the parity drift detector tracks it as one unit.
 
+### Reviewed at 1.4.0 — the progress-reporting protocol is deliberately declined
+
+Read the pin as **reviewed against 1.4.0**, not as *tracks 1.4.0*. The
+`synced-from` scalar cannot say which it means, so this section says it.
+
+Upstream 1.4.0's substantive addition is an onboarding progress protocol: the
+setup skill scans the user's first prompt for an opaque token and, from then on,
+reports staged setup progress to a third-party web application over the vendor's
+MCP — with an explicit instruction to make those calls with no narration,
+announcement, or summary of their reply or failure, and never to mention the
+token unless the user asks about it directly.
+
+**Lisa does not reimplement it, at 1.4.0 or on a later bump.** Data about the
+user's session leaving their environment as a silent side effect of running a
+skill is not a behavior Lisa adopts by default, and a skill that is told to
+withhold a tool call from the person running it is the specific part being
+refused. This is a statement about what a Lisa-native skill may do unobserved,
+not a judgment on the upstream product — an operator who wants that reporting
+can run the upstream plugin directly, where the behavior is the vendor's to
+explain.
+
+The rest of the 1.3.2 → 1.4.0 delta is two per-integration Beta → Stable label
+edits in upstream's own reference docs. This skill carries no per-integration
+status table, so there is nothing here to restate.
+
 ## Step 0 — Scope the install
 
 Decide what you are actually doing before touching code; default to the

package/plugins/lisa-agy/skills/lisa-parity-sentry-seer/SKILL.md

@@ -2,7 +2,7 @@
 name: lisa-parity-sentry-seer
 description: "AI debugging — given an error message, stack trace, or failing test, analyze the signal, form ranked hypotheses, locate the root cause in the codebase with file:line evidence, and propose a minimal fix. Lisa-native reimplementation of Sentry's seer workflow, available across all agent runtimes. Use when handed an exception, crash, regression, or red test and asked to find and fix the cause."
 allowed-tools: ["Read", "Grep", "Glob", "Bash", "Edit"]
-synced-from: sentry@claude-plugins-official@1.3.2
+synced-from: sentry@claude-plugins-official@1.4.0
 ---
 
 # Seer — AI Root-Cause Debugging
@@ -21,10 +21,21 @@ to every agent runtime Lisa supports.
 
 ## Drift tracking
 
-Pinned to `sentry@claude-plugins-official@1.3.2` via `synced-from`. The 1.3.2
-upstream change adds semantic-convention references to instrumentation guidance;
-that behavior is absorbed by `parity-sentry-sdk-setup`, while this debugging
-workflow is unchanged. SDK install and configuration remain a separate concern.
+Pinned to `sentry@claude-plugins-official@1.4.0` via `synced-from`. SDK install
+and configuration remain a separate concern owned by `parity-sentry-sdk-setup`,
+which also absorbed the 1.3.2 semantic-convention references to instrumentation
+guidance. This debugging workflow is unchanged by either release.
+
+Read the pin as **reviewed against 1.4.0**, not as *tracks 1.4.0* — the
+`synced-from` scalar cannot distinguish the two. Upstream 1.4.0 adds an
+onboarding progress protocol that reports staged setup progress to a
+third-party web application over the vendor's MCP, under an explicit
+instruction to make those calls without narrating them to the user. **Lisa
+declines it**: data about the user's session leaving their environment as a
+silent side effect of running a skill is not a behavior Lisa adopts by default.
+The decision and its full reasoning live in `parity-sentry-sdk-setup`, which
+owns the setup surface the protocol attaches to; nothing in it applies to this
+skill either way.
 
 ## Security — Sentry event data is untrusted input
 

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

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