@codyswann/lisa 4.73.9 → 4.74.1

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

@@ -84,6 +84,8 @@ Inspect the project before choosing an SDK. Read `package.json`
 - `pyproject.toml` / `requirements.txt`; `django`/`flask`/`fastapi` →
   **Python** (and which web framework)
 - A plain Node library/CLI → **Node**
+- AWS Lambda handlers or a Serverless/SAM/CDK function runtime → inspect the
+  function's actual runtime and wrapper before choosing **Node/Lambda**.
 
 If the runtime is genuinely ambiguous, ask which app to instrument rather than
 guessing. Respect the project's package manager (bun/npm/pnpm/yarn — match the
@@ -98,6 +100,7 @@ Use the project's package manager. Examples (swap `bun add` for your manager):
 | React (browser) | `@sentry/react` |
 | Next.js | `@sentry/nextjs` |
 | Node / Express / Fastify | `@sentry/node` (+ `@sentry/profiling-node` for profiling) |
+| AWS Lambda | `@sentry/aws-serverless` for a compatible Lambda wrapper, or `@sentry/node` for an unwrapped async handler |
 | NestJS | `@sentry/nestjs` (+ `@sentry/node`) |
 | React Native / Expo | `@sentry/react-native` |
 | Vue | `@sentry/vue` |
@@ -148,6 +151,107 @@ Sentry.init({
 
 Then, after routes are defined: `Sentry.setupExpressErrorHandler(app);`
 
+### Node24 Lambda completion
+
+Review the actual function runtime and installed SDK before migrating. Node24
+LTS is Lisa's default for new TypeScript hosts; an existing host's explicit
+engine and create-only workflows remain host-owned. On AWS Lambda `nodejs24.x`,
+callback-style handlers and legacy context completion APIs, including
+`callbackWaitsForEmptyEventLoop`, are removed. Do not assign those properties,
+including to frozen/non-extensible context objects. Supported async handlers,
+synchronous returns and response streaming are distinct forms; follow the
+[AWS handler contract](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html).
+
+Earlier non-streaming async handlers already returned without waiting for
+unresolved background promises. Node24 aligns streaming completion with that
+behavior; await work that must finish before returning or ending the stream.
+Do not claim all Node20/22 async handlers drained arbitrary background work.
+For streaming, flush at the appropriate point before `responseStream.end()` or
+inside the awaited streaming pipeline, rather than after the stream is ended.
+[AWS's Node24 migration explanation](https://aws.amazon.com/blogs/compute/node-js-24-runtime-now-available-in-aws-lambda/)
+is the runtime authority; ordinary local Node process behavior is not deployed
+Lambda evidence.
+
+For an **unwrapped async** scheduled, queue or Cognito handler, initialize Sentry
+once at module startup with the DSN from the environment. Await a finite positive
+flush budget on both success and original-error paths. A false flush result or
+rejection must not turn successful queue work into a retry or replace its real
+error. Keep diagnostics local and non-throwing, and preserve the client for warm
+invocations: `close()` disables it. The following helper wraps the host's existing
+business operation; it neither mutates context nor adds a Lambda callback.
+
+<!-- lisa-node24-unwrapped-example:start -->
+```ts
+import * as Sentry from "@sentry/node";
+
+// Initialize early, once outside the handler, with DSN from the environment.
+function reportFlushProblem(message: string): void {
+  try {
+    console.warn(message);
+  } catch {
+    // Telemetry diagnostics must preserve the business outcome too.
+  }
+}
+
+export async function withSentryFlush<T>(
+  work: () => Promise<T>,
+  timeoutMs = 2000
+): Promise<T> {
+  if (!Number.isFinite(timeoutMs) || timeoutMs <= 0) {
+    throw new RangeError("Choose a finite positive Sentry flush budget");
+  }
+  try {
+    return await work();
+  } catch (originalError) {
+    try {
+      Sentry.captureException(originalError);
+    } catch {
+      // Preserve the original handler error even if capture fails.
+    }
+    throw originalError;
+  } finally {
+    try {
+      if (!(await Sentry.flush(timeoutMs))) {
+        reportFlushProblem("Sentry flush did not finish in time");
+      }
+    } catch {
+      reportFlushProblem("Sentry flush rejected");
+    }
+  }
+}
+```
+<!-- lisa-node24-unwrapped-example:end -->
+
+In the existing async handler, return
+`withSentryFlush(() => performBusinessWork(event, context))`; use the host's
+actual business operation and preserve its return/error contract. Select a
+positive budget that fits remaining invocation time with a safety margin.
+Do not omit the timeout or use zero as a finite cap. The SDK's timeout argument
+does not cancel every custom transport or guarantee completion before Lambda's
+hard timeout, and a drained local queue does not prove tenant ingestion.
+[Sentry API semantics](https://docs.sentry.io/platforms/javascript/guides/aws-lambda/configuration/apis.md)
+describe `flush()` and `close()`.
+
+For a **compatible `Sentry.wrapHandler`**, its documented default flush is up
+to2000ms, configurable through `flushTimeout`; avoid a redundant manual flush
+when that wrapper already handles completion. Check the installed version's
+context behavior, too: `@sentry/aws-serverless`11.6.0 unconditionally assigns
+`context.callbackWaitsForEmptyEventLoop` before invoking the business handler.
+It throws on a non-extensible context lacking that removed property. Changing
+the option does not remove the assignment. Use the unwrapped form when this
+incompatibility applies; do not clone/unfreeze context or pre-add an obsolete
+property to claim compatibility. See the [wrapper documentation](https://docs.sentry.io/platforms/javascript/guides/aws-lambda/configuration/lambda-wrapper.md)
+and [versioned implementation](https://github.com/getsentry/sentry-javascript/blob/11.6.0/packages/aws-serverless/src/sdk.ts).
+
+Treat Node types and optional native profiling as migration checks. Examples
+using `Array.at` need an ES2022-or-later TypeScript `lib`; keep a host's business
+compiler target deliberate. Confirm optional profiling prebuilds against the
+actual Node ABI (Node24 uses137) only when profiling is in use; do not install an
+unused profiling package. Verify the helper with the real installed SDK and
+local transport, including success/error, timeout/false, rejected flush and a
+second warm invocation. Label local observations honestly; actual Lambda
+deployment and Sentry event ingestion require their own provider proof.
+
 **NestJS** — import `./instrument` first in `main.ts`, then add Sentry's module:
 
 ```ts

package/plugins/lisa-agy/skills/lisa-setup-workstation/scripts/workstation.mjs

@@ -63,7 +63,9 @@ import {
 export function locate(name, exec = boundedChildOutput) {
   try {
     return String(
-      exec("command", ["-v", name], { encoding: "utf8", shell: true })
+      exec("sh", ["-c", 'command -v -- "$1"', "lisa-locate", name], {
+        encoding: "utf8",
+      })
     ).trim();
   } catch {
     // probe-direction: fail-closed — null means "not proven present", and the

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

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

package/plugins/lisa-copilot/rules/reference/bdd-e2e-coverage.md

@@ -22,8 +22,9 @@ Default locations (a project that already has an equivalent contract keeps its o
 |---|---|---|
 | Scenarios | `bdd/features/*.feature` | Gherkin, the product-level behavior contract |
 | Coverage map | `bdd/coverage-map.json` | scenario → runner/platform/file/evidence mappings, plus waivers, per-runner test-discovery roots, and exclusions |
-| Generated matrix | `docs/bdd-scenario-matrix.md` | regenerated, never hand-edited |
-| Burndown | `docs/e2e-bdd-coverage.md` | current coverage per platform |
+| Generated matrix | `docs/bdd-scenario-matrix/` | per-source-file leaves, regenerated, never hand-edited; static navigation at `docs/bdd-scenario-matrix.md` |
+| Burndown | `docs/e2e-bdd-coverage/` | per-source-file mapping gaps and waivers; static navigation at `docs/e2e-bdd-coverage.md` |
+| Feature JSON | `bdd/reports/v1/features/` | versioned local declarations/evidence; full aggregate remains in runtime `--report` and CI |
 
 ## Scenario shape
 
@@ -180,9 +181,10 @@ exclusion whose file is gone, whose title was renamed, or that no discovery root
 
 Two commands, wired into the project's script surface and into CI:
 
-1. **Regenerate** — recompute coverage from features + map, rewrite the generated matrix
-   (`docs/bdd-scenario-matrix.md`) and the burndown (`docs/e2e-bdd-coverage.md`), and refresh the
-   machine-readable report. Low coverage is reported honestly and does **not** fail this command.
+1. **Regenerate** — recompute coverage from features + map and write the feature-local matrix,
+   burndown and JSON under `docs/bdd-scenario-matrix/`, `docs/e2e-bdd-coverage/` and
+   `bdd/reports/v1/features/`. Shared entry points contain static guidance. Reportable coverage
+   defects still produce paperwork; the coverage CLI keeps its original failing exit.
 2. **Check** — the CI gate. It fails on contract defects, not on ambition:
    - a duplicate or malformed scenario ID;
    - a scenario declaring a platform with no configured runner;
@@ -197,7 +199,7 @@ Two commands, wired into the project's script surface and into CI:
    - coverage given back: an obligation mapped at the base revision that nothing maps here;
    - new behavior nobody mapped or waived.
 
-   Regeneration is never blocked by the check: `--write` rewrites the report and burndown whenever a
+   Regeneration is never blocked by a reportable coverage defect: `--write` rewrites feature reports whenever a
    report can be built at all, so a stale evidence string can never hold hostage the paperwork that
    documents it.
 
@@ -277,7 +279,7 @@ A repo with no contract yet, taking its first frontend work item:
    Pre-existing tests that align to no product behavior are recorded as `exclusions` with reasons
    during this step, never left undisclosed.
 3. **Write only this item's scenarios.** The first item is not a backfill project. Pre-existing
-   uncovered behavior becomes burndown in `docs/e2e-bdd-coverage.md`, and the floor starts where the
+   uncovered behavior becomes feature-local burndown under `docs/e2e-bdd-coverage/`, and the floor starts where the
    repo actually is. That is a one-time act, not a recurring one: from here on the floor stays put
    and what protects each new obligation is the per-obligation check, not the number.
 4. **Seal this item's obligations** and commit the regenerated matrix and burndown with the change.

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

@@ -84,6 +84,8 @@ Inspect the project before choosing an SDK. Read `package.json`
 - `pyproject.toml` / `requirements.txt`; `django`/`flask`/`fastapi` →
   **Python** (and which web framework)
 - A plain Node library/CLI → **Node**
+- AWS Lambda handlers or a Serverless/SAM/CDK function runtime → inspect the
+  function's actual runtime and wrapper before choosing **Node/Lambda**.
 
 If the runtime is genuinely ambiguous, ask which app to instrument rather than
 guessing. Respect the project's package manager (bun/npm/pnpm/yarn — match the
@@ -98,6 +100,7 @@ Use the project's package manager. Examples (swap `bun add` for your manager):
 | React (browser) | `@sentry/react` |
 | Next.js | `@sentry/nextjs` |
 | Node / Express / Fastify | `@sentry/node` (+ `@sentry/profiling-node` for profiling) |
+| AWS Lambda | `@sentry/aws-serverless` for a compatible Lambda wrapper, or `@sentry/node` for an unwrapped async handler |
 | NestJS | `@sentry/nestjs` (+ `@sentry/node`) |
 | React Native / Expo | `@sentry/react-native` |
 | Vue | `@sentry/vue` |
@@ -148,6 +151,107 @@ Sentry.init({
 
 Then, after routes are defined: `Sentry.setupExpressErrorHandler(app);`
 
+### Node24 Lambda completion
+
+Review the actual function runtime and installed SDK before migrating. Node24
+LTS is Lisa's default for new TypeScript hosts; an existing host's explicit
+engine and create-only workflows remain host-owned. On AWS Lambda `nodejs24.x`,
+callback-style handlers and legacy context completion APIs, including
+`callbackWaitsForEmptyEventLoop`, are removed. Do not assign those properties,
+including to frozen/non-extensible context objects. Supported async handlers,
+synchronous returns and response streaming are distinct forms; follow the
+[AWS handler contract](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html).
+
+Earlier non-streaming async handlers already returned without waiting for
+unresolved background promises. Node24 aligns streaming completion with that
+behavior; await work that must finish before returning or ending the stream.
+Do not claim all Node20/22 async handlers drained arbitrary background work.
+For streaming, flush at the appropriate point before `responseStream.end()` or
+inside the awaited streaming pipeline, rather than after the stream is ended.
+[AWS's Node24 migration explanation](https://aws.amazon.com/blogs/compute/node-js-24-runtime-now-available-in-aws-lambda/)
+is the runtime authority; ordinary local Node process behavior is not deployed
+Lambda evidence.
+
+For an **unwrapped async** scheduled, queue or Cognito handler, initialize Sentry
+once at module startup with the DSN from the environment. Await a finite positive
+flush budget on both success and original-error paths. A false flush result or
+rejection must not turn successful queue work into a retry or replace its real
+error. Keep diagnostics local and non-throwing, and preserve the client for warm
+invocations: `close()` disables it. The following helper wraps the host's existing
+business operation; it neither mutates context nor adds a Lambda callback.
+
+<!-- lisa-node24-unwrapped-example:start -->
+```ts
+import * as Sentry from "@sentry/node";
+
+// Initialize early, once outside the handler, with DSN from the environment.
+function reportFlushProblem(message: string): void {
+  try {
+    console.warn(message);
+  } catch {
+    // Telemetry diagnostics must preserve the business outcome too.
+  }
+}
+
+export async function withSentryFlush<T>(
+  work: () => Promise<T>,
+  timeoutMs = 2000
+): Promise<T> {
+  if (!Number.isFinite(timeoutMs) || timeoutMs <= 0) {
+    throw new RangeError("Choose a finite positive Sentry flush budget");
+  }
+  try {
+    return await work();
+  } catch (originalError) {
+    try {
+      Sentry.captureException(originalError);
+    } catch {
+      // Preserve the original handler error even if capture fails.
+    }
+    throw originalError;
+  } finally {
+    try {
+      if (!(await Sentry.flush(timeoutMs))) {
+        reportFlushProblem("Sentry flush did not finish in time");
+      }
+    } catch {
+      reportFlushProblem("Sentry flush rejected");
+    }
+  }
+}
+```
+<!-- lisa-node24-unwrapped-example:end -->
+
+In the existing async handler, return
+`withSentryFlush(() => performBusinessWork(event, context))`; use the host's
+actual business operation and preserve its return/error contract. Select a
+positive budget that fits remaining invocation time with a safety margin.
+Do not omit the timeout or use zero as a finite cap. The SDK's timeout argument
+does not cancel every custom transport or guarantee completion before Lambda's
+hard timeout, and a drained local queue does not prove tenant ingestion.
+[Sentry API semantics](https://docs.sentry.io/platforms/javascript/guides/aws-lambda/configuration/apis.md)
+describe `flush()` and `close()`.
+
+For a **compatible `Sentry.wrapHandler`**, its documented default flush is up
+to2000ms, configurable through `flushTimeout`; avoid a redundant manual flush
+when that wrapper already handles completion. Check the installed version's
+context behavior, too: `@sentry/aws-serverless`11.6.0 unconditionally assigns
+`context.callbackWaitsForEmptyEventLoop` before invoking the business handler.
+It throws on a non-extensible context lacking that removed property. Changing
+the option does not remove the assignment. Use the unwrapped form when this
+incompatibility applies; do not clone/unfreeze context or pre-add an obsolete
+property to claim compatibility. See the [wrapper documentation](https://docs.sentry.io/platforms/javascript/guides/aws-lambda/configuration/lambda-wrapper.md)
+and [versioned implementation](https://github.com/getsentry/sentry-javascript/blob/11.6.0/packages/aws-serverless/src/sdk.ts).
+
+Treat Node types and optional native profiling as migration checks. Examples
+using `Array.at` need an ES2022-or-later TypeScript `lib`; keep a host's business
+compiler target deliberate. Confirm optional profiling prebuilds against the
+actual Node ABI (Node24 uses137) only when profiling is in use; do not install an
+unused profiling package. Verify the helper with the real installed SDK and
+local transport, including success/error, timeout/false, rejected flush and a
+second warm invocation. Label local observations honestly; actual Lambda
+deployment and Sentry event ingestion require their own provider proof.
+
 **NestJS** — import `./instrument` first in `main.ts`, then add Sentry's module:
 
 ```ts

package/plugins/lisa-copilot/skills/lisa-setup-workstation/scripts/workstation.mjs

@@ -63,7 +63,9 @@ import {
 export function locate(name, exec = boundedChildOutput) {
   try {
     return String(
-      exec("command", ["-v", name], { encoding: "utf8", shell: true })
+      exec("sh", ["-c", 'command -v -- "$1"', "lisa-locate", name], {
+        encoding: "utf8",
+      })
     ).trim();
   } catch {
     // probe-direction: fail-closed — null means "not proven present", and the

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

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

package/plugins/lisa-cursor/rules/bdd-e2e-coverage-reference.mdc

@@ -27,8 +27,9 @@ Default locations (a project that already has an equivalent contract keeps its o
 |---|---|---|
 | Scenarios | `bdd/features/*.feature` | Gherkin, the product-level behavior contract |
 | Coverage map | `bdd/coverage-map.json` | scenario → runner/platform/file/evidence mappings, plus waivers, per-runner test-discovery roots, and exclusions |
-| Generated matrix | `docs/bdd-scenario-matrix.md` | regenerated, never hand-edited |
-| Burndown | `docs/e2e-bdd-coverage.md` | current coverage per platform |
+| Generated matrix | `docs/bdd-scenario-matrix/` | per-source-file leaves, regenerated, never hand-edited; static navigation at `docs/bdd-scenario-matrix.md` |
+| Burndown | `docs/e2e-bdd-coverage/` | per-source-file mapping gaps and waivers; static navigation at `docs/e2e-bdd-coverage.md` |
+| Feature JSON | `bdd/reports/v1/features/` | versioned local declarations/evidence; full aggregate remains in runtime `--report` and CI |
 
 ## Scenario shape
 
@@ -185,9 +186,10 @@ exclusion whose file is gone, whose title was renamed, or that no discovery root
 
 Two commands, wired into the project's script surface and into CI:
 
-1. **Regenerate** — recompute coverage from features + map, rewrite the generated matrix
-   (`docs/bdd-scenario-matrix.md`) and the burndown (`docs/e2e-bdd-coverage.md`), and refresh the
-   machine-readable report. Low coverage is reported honestly and does **not** fail this command.
+1. **Regenerate** — recompute coverage from features + map and write the feature-local matrix,
+   burndown and JSON under `docs/bdd-scenario-matrix/`, `docs/e2e-bdd-coverage/` and
+   `bdd/reports/v1/features/`. Shared entry points contain static guidance. Reportable coverage
+   defects still produce paperwork; the coverage CLI keeps its original failing exit.
 2. **Check** — the CI gate. It fails on contract defects, not on ambition:
    - a duplicate or malformed scenario ID;
    - a scenario declaring a platform with no configured runner;
@@ -202,7 +204,7 @@ Two commands, wired into the project's script surface and into CI:
    - coverage given back: an obligation mapped at the base revision that nothing maps here;
    - new behavior nobody mapped or waived.
 
-   Regeneration is never blocked by the check: `--write` rewrites the report and burndown whenever a
+   Regeneration is never blocked by a reportable coverage defect: `--write` rewrites feature reports whenever a
    report can be built at all, so a stale evidence string can never hold hostage the paperwork that
    documents it.
 
@@ -282,7 +284,7 @@ A repo with no contract yet, taking its first frontend work item:
    Pre-existing tests that align to no product behavior are recorded as `exclusions` with reasons
    during this step, never left undisclosed.
 3. **Write only this item's scenarios.** The first item is not a backfill project. Pre-existing
-   uncovered behavior becomes burndown in `docs/e2e-bdd-coverage.md`, and the floor starts where the
+   uncovered behavior becomes feature-local burndown under `docs/e2e-bdd-coverage/`, and the floor starts where the
    repo actually is. That is a one-time act, not a recurring one: from here on the floor stays put
    and what protects each new obligation is the per-obligation check, not the number.
 4. **Seal this item's obligations** and commit the regenerated matrix and burndown with the change.

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

@@ -84,6 +84,8 @@ Inspect the project before choosing an SDK. Read `package.json`
 - `pyproject.toml` / `requirements.txt`; `django`/`flask`/`fastapi` →
   **Python** (and which web framework)
 - A plain Node library/CLI → **Node**
+- AWS Lambda handlers or a Serverless/SAM/CDK function runtime → inspect the
+  function's actual runtime and wrapper before choosing **Node/Lambda**.
 
 If the runtime is genuinely ambiguous, ask which app to instrument rather than
 guessing. Respect the project's package manager (bun/npm/pnpm/yarn — match the
@@ -98,6 +100,7 @@ Use the project's package manager. Examples (swap `bun add` for your manager):
 | React (browser) | `@sentry/react` |
 | Next.js | `@sentry/nextjs` |
 | Node / Express / Fastify | `@sentry/node` (+ `@sentry/profiling-node` for profiling) |
+| AWS Lambda | `@sentry/aws-serverless` for a compatible Lambda wrapper, or `@sentry/node` for an unwrapped async handler |
 | NestJS | `@sentry/nestjs` (+ `@sentry/node`) |
 | React Native / Expo | `@sentry/react-native` |
 | Vue | `@sentry/vue` |
@@ -148,6 +151,107 @@ Sentry.init({
 
 Then, after routes are defined: `Sentry.setupExpressErrorHandler(app);`
 
+### Node24 Lambda completion
+
+Review the actual function runtime and installed SDK before migrating. Node24
+LTS is Lisa's default for new TypeScript hosts; an existing host's explicit
+engine and create-only workflows remain host-owned. On AWS Lambda `nodejs24.x`,
+callback-style handlers and legacy context completion APIs, including
+`callbackWaitsForEmptyEventLoop`, are removed. Do not assign those properties,
+including to frozen/non-extensible context objects. Supported async handlers,
+synchronous returns and response streaming are distinct forms; follow the
+[AWS handler contract](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html).
+
+Earlier non-streaming async handlers already returned without waiting for
+unresolved background promises. Node24 aligns streaming completion with that
+behavior; await work that must finish before returning or ending the stream.
+Do not claim all Node20/22 async handlers drained arbitrary background work.
+For streaming, flush at the appropriate point before `responseStream.end()` or
+inside the awaited streaming pipeline, rather than after the stream is ended.
+[AWS's Node24 migration explanation](https://aws.amazon.com/blogs/compute/node-js-24-runtime-now-available-in-aws-lambda/)
+is the runtime authority; ordinary local Node process behavior is not deployed
+Lambda evidence.
+
+For an **unwrapped async** scheduled, queue or Cognito handler, initialize Sentry
+once at module startup with the DSN from the environment. Await a finite positive
+flush budget on both success and original-error paths. A false flush result or
+rejection must not turn successful queue work into a retry or replace its real
+error. Keep diagnostics local and non-throwing, and preserve the client for warm
+invocations: `close()` disables it. The following helper wraps the host's existing
+business operation; it neither mutates context nor adds a Lambda callback.
+
+<!-- lisa-node24-unwrapped-example:start -->
+```ts
+import * as Sentry from "@sentry/node";
+
+// Initialize early, once outside the handler, with DSN from the environment.
+function reportFlushProblem(message: string): void {
+  try {
+    console.warn(message);
+  } catch {
+    // Telemetry diagnostics must preserve the business outcome too.
+  }
+}
+
+export async function withSentryFlush<T>(
+  work: () => Promise<T>,
+  timeoutMs = 2000
+): Promise<T> {
+  if (!Number.isFinite(timeoutMs) || timeoutMs <= 0) {
+    throw new RangeError("Choose a finite positive Sentry flush budget");
+  }
+  try {
+    return await work();
+  } catch (originalError) {
+    try {
+      Sentry.captureException(originalError);
+    } catch {
+      // Preserve the original handler error even if capture fails.
+    }
+    throw originalError;
+  } finally {
+    try {
+      if (!(await Sentry.flush(timeoutMs))) {
+        reportFlushProblem("Sentry flush did not finish in time");
+      }
+    } catch {
+      reportFlushProblem("Sentry flush rejected");
+    }
+  }
+}
+```
+<!-- lisa-node24-unwrapped-example:end -->
+
+In the existing async handler, return
+`withSentryFlush(() => performBusinessWork(event, context))`; use the host's
+actual business operation and preserve its return/error contract. Select a
+positive budget that fits remaining invocation time with a safety margin.
+Do not omit the timeout or use zero as a finite cap. The SDK's timeout argument
+does not cancel every custom transport or guarantee completion before Lambda's
+hard timeout, and a drained local queue does not prove tenant ingestion.
+[Sentry API semantics](https://docs.sentry.io/platforms/javascript/guides/aws-lambda/configuration/apis.md)
+describe `flush()` and `close()`.
+
+For a **compatible `Sentry.wrapHandler`**, its documented default flush is up
+to2000ms, configurable through `flushTimeout`; avoid a redundant manual flush
+when that wrapper already handles completion. Check the installed version's
+context behavior, too: `@sentry/aws-serverless`11.6.0 unconditionally assigns
+`context.callbackWaitsForEmptyEventLoop` before invoking the business handler.
+It throws on a non-extensible context lacking that removed property. Changing
+the option does not remove the assignment. Use the unwrapped form when this
+incompatibility applies; do not clone/unfreeze context or pre-add an obsolete
+property to claim compatibility. See the [wrapper documentation](https://docs.sentry.io/platforms/javascript/guides/aws-lambda/configuration/lambda-wrapper.md)
+and [versioned implementation](https://github.com/getsentry/sentry-javascript/blob/11.6.0/packages/aws-serverless/src/sdk.ts).
+
+Treat Node types and optional native profiling as migration checks. Examples
+using `Array.at` need an ES2022-or-later TypeScript `lib`; keep a host's business
+compiler target deliberate. Confirm optional profiling prebuilds against the
+actual Node ABI (Node24 uses137) only when profiling is in use; do not install an
+unused profiling package. Verify the helper with the real installed SDK and
+local transport, including success/error, timeout/false, rejected flush and a
+second warm invocation. Label local observations honestly; actual Lambda
+deployment and Sentry event ingestion require their own provider proof.
+
 **NestJS** — import `./instrument` first in `main.ts`, then add Sentry's module:
 
 ```ts

package/plugins/lisa-cursor/skills/lisa-setup-workstation/scripts/workstation.mjs

@@ -63,7 +63,9 @@ import {
 export function locate(name, exec = boundedChildOutput) {
   try {
     return String(
-      exec("command", ["-v", name], { encoding: "utf8", shell: true })
+      exec("sh", ["-c", 'command -v -- "$1"', "lisa-locate", name], {
+        encoding: "utf8",
+      })
     ).trim();
   } catch {
     // probe-direction: fail-closed — null means "not proven present", and the

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.73.9",
+  "version": "4.74.1",
   "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.73.9",
+  "version": "4.74.1",
   "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.73.9",
+  "version": "4.74.1",
   "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.73.9",
+  "version": "4.74.1",
   "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.73.9",
+  "version": "4.74.1",
   "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.73.9",
+  "version": "4.74.1",
   "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.73.9",
+  "version": "4.74.1",
   "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.73.9",
+  "version": "4.74.1",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"