@codyswann/lisa 2.191.14 → 2.192.1

package/plugins/lisa-harper-fabric/skills/harper-resources/SKILL.md

@@ -74,6 +74,41 @@ See [[harper-config-yaml]] for the extension wiring, [[harper-schema-graphql]] f
 how the schema defines the tables resources extend, and [[harper-realtime]] when
 `subscribe`, `publish`, or WebSocket behavior is part of the feature.
 
+## Throwing HTTP status errors
+
+Harper's thrown-error response writer reads **`error.statusCode`** (falling back
+to `500`). A plain `error.status` is **ignored** — throw an error with only
+`status` set and every intended `4xx` is served as a `500`. Verified on
+harperdb 4.7.32.
+
+Always set `statusCode` (keep `status` too only if callers or tests read it):
+
+```javascript
+static async post(target, data, context) {
+  if (!context.user) {
+    const error = new Error('Authentication required');
+    error.statusCode = 401; // NOT `error.status` — Harper reads statusCode
+    throw error;
+  }
+  // ...
+}
+```
+
+A shared helper keeps every throw site correct:
+
+```javascript
+function throwStatus(message, status) {
+  // Set both: `statusCode` is what Harper serves; `status` is kept for
+  // returned-response symmetry and any caller/test that reads it.
+  throw Object.assign(new Error(message), { status, statusCode: status });
+}
+```
+
+The `harper-require-statuscode-on-thrown-error` ast-grep rule flags errors that
+carry `status` without `statusCode`. Pass `context` through to `super` and nested
+table calls so authorization and the request transaction stay aligned — see
+[[harper-rest-queries]] for context propagation and iterator draining.
+
 ## Project conventions (TS is source)
 
 - **Write resources in TypeScript under `src/`. `harper-app/resources.js` is a

package/plugins/lisa-harper-fabric/skills/harper-rest-queries/SKILL.md

@@ -121,6 +121,38 @@ const products = await tables.Products.search({
 });
 ```
 
+## Sort with no conditions crashes the planner
+
+A `search()` that carries a `sort` but an **empty `conditions: []`** array throws
+at runtime — the planner cannot seed the btree scan from the sort attribute. This
+is a latent `500` the first time an unfiltered, sorted collection page is
+requested (verified on harperdb 4.7.32).
+
+```javascript
+// ✗ crashes: sort with nothing to seed the scan
+tables.Advisor.search({
+  conditions: [],
+  sort: { attribute: 'lastName' },
+});
+```
+
+Seed a floor/sentinel condition on the sort attribute so the planner has an index
+range to walk, then apply the sort:
+
+```javascript
+// ✓ floor condition on the sort attribute seeds the scan
+tables.Advisor.search({
+  conditions: [
+    { attribute: 'lastName', comparator: 'greater_than_equal', value: '' },
+  ],
+  sort: { attribute: 'lastName' },
+});
+```
+
+Centralize this in the page helper (`searchPageAndCount`) rather than duplicating
+a sentinel at each call site. The `harper-no-empty-conditions-with-sort` ast-grep
+rule flags the crashing shape.
+
 ## Relationship queries
 
 Relationship attributes can be queried with dot syntax when the relationship is
@@ -200,9 +232,14 @@ Useful query keys:
 | `select` | Projection list. Keep admin-only fields out of public responses. |
 | `explain` | Debug execution order and index usage while tuning. |
 
-`search()` can return an `AsyncIterable`. When iterating manually or stopping
-early, drain it or call the iterator's `return()` in `finally` so Harper can
-release the read transaction:
+`search()` can return an `AsyncIterable`. An early `return`/`break` out of a
+`for await (... of tables.X.search(...))` loop abandons the iterator before the
+scan completes and **leaks the open read transaction** (verified on
+harperdb 4.7.32). When iterating manually or stopping early, drain it or call the
+iterator's `return()` in `finally` so Harper releases the read transaction — or
+bound the query (`search({ ..., limit: 1 })`) when you only need the first row.
+The `harper-no-early-return-in-search-loop` ast-grep rule flags early exits from
+these loops:
 
 ```javascript
 const iterator = tables.Products

package/plugins/lisa-harper-fabric-agy/generated-artifact-globs.txt

@@ -1,4 +1,5 @@
 harper-app/resources.js
 harper-app/resource-*.js
+harper-app/*.js
 harper-app/web/**
 harper-app/lib/**

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

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

package/plugins/lisa-harper-fabric-agy/skills/harper-auth/SKILL.md

@@ -260,6 +260,54 @@ Guidance:
   webhook must bypass Harper auth, verify its signature first and keep its table
   writes narrowly scoped.
 
+## Session cookies are `SameSite=None` — guard state-changing POSTs
+
+Harper hardcodes the session cookie's `SameSite=None` attribute on HTTPS. The
+browser therefore attaches the session cookie to **cross-site** requests, so a
+same-origin app cannot rely on `SameSite` to block CSRF on cookie-authenticated,
+state-changing routes (`POST`/`PUT`/`PATCH`/`DELETE`).
+
+Add an app-side origin check in the resource before mutating. Reject requests
+whose `Origin` (or `Referer` fallback) is not an allowed origin:
+
+```javascript
+const ALLOWED_ORIGINS = new Set([
+  'https://app.example.com',
+]);
+
+function requireSameOrigin(context) {
+  const headers = context.requestContext?.headers ?? context.headers;
+  const origin =
+    headers?.get?.('origin') ??
+    headers?.get?.('referer');
+  const ok =
+    typeof origin === 'string' &&
+    [...ALLOWED_ORIGINS].some((allowed) => origin.startsWith(allowed));
+  if (!ok) {
+    const error = new Error('Cross-origin request rejected');
+    error.statusCode = 403; // Harper reads statusCode, not status
+    throw error;
+  }
+}
+
+export class Watchlists extends tables.Watchlists {
+  static async post(target, data, context) {
+    requireSameOrigin(context);
+    // ...authorization and write
+    return super.post(target, await data, context);
+  }
+}
+```
+
+Guidance:
+
+- Call the check on every cookie-authenticated state-changing route. Read-only
+  `GET` handlers and token/`Authorization: Bearer` APIs (not cookie-driven) do
+  not need it.
+- Prefer an allowlist of exact origins over substring matching that a lookalike
+  host could satisfy.
+- This is defense the app owns; Harper will not add it for you.
+
 ## Verification matrix
 
 Run the local app, create the test users, and check unauthenticated, reader, and

package/plugins/lisa-harper-fabric-agy/skills/harper-build-and-deploy/SKILL.md

@@ -50,15 +50,30 @@ What the build actually does:
 
 Generated Harper deploy artifacts usually include:
 
-- `harper-app/resources.js`
-- `harper-app/resource-*.js`
+- `harper-app/*.js` — every compiled module the build emits to the harper-app
+  root (`resources.js`, `resource-*.js`, and any other output such as a route
+  negotiation module). The single-star does **not** cross a directory separator,
+  so it does not match hand-written shims one level down.
 - `harper-app/web/**`
 - `harper-app/lib/**`
 
+The guard surfaces (`generated-artifact-globs.txt` for the PreToolUse block hook,
+`.gitignore`, `.prettierignore`, the ESLint/oxlint/knip ignores, and
+`tsconfig.eslint.json`) all key off `harper-app/*.js` so a newly-named compiled
+module is protected automatically. **Name compiled resource modules
+`resource-*.ts`** so their JS output is unambiguously generated.
+
+If you keep a *hand-written* `.js` at the harper-app root (e.g. an SEO shell),
+the root-level rule would otherwise treat it as generated: re-include it with a
+`!harper-app/<file>.js` line below the managed gitignore block, and add it to
+`.lisa/harper-generated-artifact-allowlist.txt` so the block hook lets you edit
+it. Hand-written shims nested under `harper-app/<route>/index.js` need no
+exemption — the root-level rule never matches them.
+
 Every lint, format, dead-code, search, or generated-artifact guard must ignore
-those generated paths unless it is explicitly validating the build output itself.
-When a new generated path appears, add it to every relevant ignore surface in the
-same change; partial ignores fail later gates in non-obvious ways.
+generated paths unless it is explicitly validating the build output itself. When
+a new generated *directory* appears, add it to every relevant ignore surface in
+the same change; partial ignores fail later gates in non-obvious ways.
 
 - **TypeScript under `src/` is source.** `bun run build` produces the deployable
   Harper assets from it.

package/plugins/lisa-harper-fabric-agy/skills/harper-resources/SKILL.md

@@ -74,6 +74,41 @@ See [[harper-config-yaml]] for the extension wiring, [[harper-schema-graphql]] f
 how the schema defines the tables resources extend, and [[harper-realtime]] when
 `subscribe`, `publish`, or WebSocket behavior is part of the feature.
 
+## Throwing HTTP status errors
+
+Harper's thrown-error response writer reads **`error.statusCode`** (falling back
+to `500`). A plain `error.status` is **ignored** — throw an error with only
+`status` set and every intended `4xx` is served as a `500`. Verified on
+harperdb 4.7.32.
+
+Always set `statusCode` (keep `status` too only if callers or tests read it):
+
+```javascript
+static async post(target, data, context) {
+  if (!context.user) {
+    const error = new Error('Authentication required');
+    error.statusCode = 401; // NOT `error.status` — Harper reads statusCode
+    throw error;
+  }
+  // ...
+}
+```
+
+A shared helper keeps every throw site correct:
+
+```javascript
+function throwStatus(message, status) {
+  // Set both: `statusCode` is what Harper serves; `status` is kept for
+  // returned-response symmetry and any caller/test that reads it.
+  throw Object.assign(new Error(message), { status, statusCode: status });
+}
+```
+
+The `harper-require-statuscode-on-thrown-error` ast-grep rule flags errors that
+carry `status` without `statusCode`. Pass `context` through to `super` and nested
+table calls so authorization and the request transaction stay aligned — see
+[[harper-rest-queries]] for context propagation and iterator draining.
+
 ## Project conventions (TS is source)
 
 - **Write resources in TypeScript under `src/`. `harper-app/resources.js` is a

package/plugins/lisa-harper-fabric-agy/skills/harper-rest-queries/SKILL.md

@@ -121,6 +121,38 @@ const products = await tables.Products.search({
 });
 ```
 
+## Sort with no conditions crashes the planner
+
+A `search()` that carries a `sort` but an **empty `conditions: []`** array throws
+at runtime — the planner cannot seed the btree scan from the sort attribute. This
+is a latent `500` the first time an unfiltered, sorted collection page is
+requested (verified on harperdb 4.7.32).
+
+```javascript
+// ✗ crashes: sort with nothing to seed the scan
+tables.Advisor.search({
+  conditions: [],
+  sort: { attribute: 'lastName' },
+});
+```
+
+Seed a floor/sentinel condition on the sort attribute so the planner has an index
+range to walk, then apply the sort:
+
+```javascript
+// ✓ floor condition on the sort attribute seeds the scan
+tables.Advisor.search({
+  conditions: [
+    { attribute: 'lastName', comparator: 'greater_than_equal', value: '' },
+  ],
+  sort: { attribute: 'lastName' },
+});
+```
+
+Centralize this in the page helper (`searchPageAndCount`) rather than duplicating
+a sentinel at each call site. The `harper-no-empty-conditions-with-sort` ast-grep
+rule flags the crashing shape.
+
 ## Relationship queries
 
 Relationship attributes can be queried with dot syntax when the relationship is
@@ -200,9 +232,14 @@ Useful query keys:
 | `select` | Projection list. Keep admin-only fields out of public responses. |
 | `explain` | Debug execution order and index usage while tuning. |
 
-`search()` can return an `AsyncIterable`. When iterating manually or stopping
-early, drain it or call the iterator's `return()` in `finally` so Harper can
-release the read transaction:
+`search()` can return an `AsyncIterable`. An early `return`/`break` out of a
+`for await (... of tables.X.search(...))` loop abandons the iterator before the
+scan completes and **leaks the open read transaction** (verified on
+harperdb 4.7.32). When iterating manually or stopping early, drain it or call the
+iterator's `return()` in `finally` so Harper releases the read transaction — or
+bound the query (`search({ ..., limit: 1 })`) when you only need the first row.
+The `harper-no-early-return-in-search-loop` ast-grep rule flags early exits from
+these loops:
 
 ```javascript
 const iterator = tables.Products

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

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

package/plugins/lisa-harper-fabric-copilot/generated-artifact-globs.txt

@@ -1,4 +1,5 @@
 harper-app/resources.js
 harper-app/resource-*.js
+harper-app/*.js
 harper-app/web/**
 harper-app/lib/**

package/plugins/lisa-harper-fabric-copilot/hooks/block-generated-artifact-edits.sh

@@ -33,6 +33,7 @@ matches_glob() {
   local file="$1"
   local glob="$2"
 
+  # Recursive directory globs: "dir/**" matches everything under dir.
   if [ "${glob: -3}" = "/**" ]; then
     local dir="${glob%/**}"
     case "$file" in
@@ -41,6 +42,38 @@ matches_glob() {
     return 1
   fi
 
+  # Single-star globs like "harper-app/*.js": the star must not cross a
+  # directory separator, so a broadened root-level pattern protects compiled
+  # modules emitted straight into harper-app/ (resources.js, resource-*.js, and
+  # any other build output such as detail-shell-negotiation.js) WITHOUT matching
+  # hand-written files nested one level down (e.g. harper-app/<route>/index.js).
+  case "$glob" in
+    */\** | \**)
+      local base_glob="${glob##*/}"
+      local dir_glob=""
+      case "$glob" in
+        */*) dir_glob="${glob%/*}" ;;
+      esac
+      local file_base="${file##*/}"
+      local file_dir=""
+      case "$file" in
+        */*) file_dir="${file%/*}" ;;
+      esac
+      case "$file_base" in
+        $base_glob) ;;
+        *) return 1 ;;
+      esac
+      [ -z "$dir_glob" ] && return 0
+      # Match the directory exactly, or as a suffix so absolute/prefixed paths
+      # (e.g. /repo/harper-app/foo.js) still resolve.
+      case "$file_dir" in
+        $dir_glob | */"$dir_glob") return 0 ;;
+      esac
+      return 1
+      ;;
+  esac
+
+  # Literal (wildcard-free) globs.
   case "$file" in
     $glob | */$glob) return 0 ;;
   esac
@@ -50,6 +83,24 @@ matches_glob() {
 
 NORMALIZED_FILE=$(normalize_path "$FILE_PATH")
 
+# Project-owned allowlist of hand-written files that live under harper-app/ and
+# must NOT be treated as generated (e.g. a hand-authored SEO shell, or route
+# index.js shims kept at the harper-app root). The broadened root-level
+# `harper-app/*.js` protection would otherwise block editing them. One glob per
+# line (same syntax as the globs file); blank lines and `#` comments ignored.
+# Prefer naming compiled resource modules `resource-*.ts` so their JS output is
+# unambiguously generated and never needs allowlisting.
+ALLOWLIST_FILE="${CLAUDE_PROJECT_DIR:-.}/.lisa/harper-generated-artifact-allowlist.txt"
+if [ -f "$ALLOWLIST_FILE" ]; then
+  while IFS= read -r allow || [ -n "$allow" ]; do
+    [ -n "$allow" ] || continue
+    case "$allow" in \#*) continue ;; esac
+    if matches_glob "$NORMALIZED_FILE" "$allow"; then
+      exit 0
+    fi
+  done <"$ALLOWLIST_FILE"
+fi
+
 while IFS= read -r glob || [ -n "$glob" ]; do
   [ -n "$glob" ] || continue
   case "$glob" in \#*) continue ;; esac

package/plugins/lisa-harper-fabric-copilot/rules/harper-fabric.md

@@ -13,7 +13,7 @@ These rules apply to Harper/Fabric component apps managed by Lisa.
 - TypeScript under `src/` is the source of truth for Harper resources, browser modules, shared libraries, and operational scripts.
 - `harper-app/config.yaml`, `harper-app/schema.graphql`, HTML, CSS, docs, and research fixtures are source assets.
 - `harper-app/config.yaml` does not merge with Harper defaults. Keep every required top-level extension declared when editing it; the Harper Fabric hook blocks accidental extension drops unless the removal is documented in `.lisa/harper-config-extension-allowlist.json`.
-- `harper-app/resources.js` and `harper-app/web/**/*.js` are generated deploy artifacts. Never edit them directly; change the matching TypeScript and run `bun run build`.
+- Every `.js` at the harper-app root (`harper-app/*.js` — `resources.js`, `resource-*.js`, and any other compiled module) plus `harper-app/web/**/*.js` and `harper-app/lib/**` are generated deploy artifacts. Never edit them directly; change the matching TypeScript and run `bun run build`. Name compiled resource modules `resource-*.ts` so their output is unambiguously generated; a hand-written `.js` kept at the harper-app root must be re-included in `.gitignore` and listed in `.lisa/harper-generated-artifact-allowlist.txt` so the block hook allows editing it.
 - Deployment, bootstrap, smoke, seed, verify, preview, token, crawl, ingest, and extraction commands must run from compiled JavaScript or generated Harper assets, not stale checked-in JavaScript.
 
 ## Harper/Fabric Deploy Surface

package/plugins/lisa-harper-fabric-copilot/skills/harper-auth/SKILL.md

@@ -260,6 +260,54 @@ Guidance:
   webhook must bypass Harper auth, verify its signature first and keep its table
   writes narrowly scoped.
 
+## Session cookies are `SameSite=None` — guard state-changing POSTs
+
+Harper hardcodes the session cookie's `SameSite=None` attribute on HTTPS. The
+browser therefore attaches the session cookie to **cross-site** requests, so a
+same-origin app cannot rely on `SameSite` to block CSRF on cookie-authenticated,
+state-changing routes (`POST`/`PUT`/`PATCH`/`DELETE`).
+
+Add an app-side origin check in the resource before mutating. Reject requests
+whose `Origin` (or `Referer` fallback) is not an allowed origin:
+
+```javascript
+const ALLOWED_ORIGINS = new Set([
+  'https://app.example.com',
+]);
+
+function requireSameOrigin(context) {
+  const headers = context.requestContext?.headers ?? context.headers;
+  const origin =
+    headers?.get?.('origin') ??
+    headers?.get?.('referer');
+  const ok =
+    typeof origin === 'string' &&
+    [...ALLOWED_ORIGINS].some((allowed) => origin.startsWith(allowed));
+  if (!ok) {
+    const error = new Error('Cross-origin request rejected');
+    error.statusCode = 403; // Harper reads statusCode, not status
+    throw error;
+  }
+}
+
+export class Watchlists extends tables.Watchlists {
+  static async post(target, data, context) {
+    requireSameOrigin(context);
+    // ...authorization and write
+    return super.post(target, await data, context);
+  }
+}
+```
+
+Guidance:
+
+- Call the check on every cookie-authenticated state-changing route. Read-only
+  `GET` handlers and token/`Authorization: Bearer` APIs (not cookie-driven) do
+  not need it.
+- Prefer an allowlist of exact origins over substring matching that a lookalike
+  host could satisfy.
+- This is defense the app owns; Harper will not add it for you.
+
 ## Verification matrix
 
 Run the local app, create the test users, and check unauthenticated, reader, and

package/plugins/lisa-harper-fabric-copilot/skills/harper-build-and-deploy/SKILL.md

@@ -50,15 +50,30 @@ What the build actually does:
 
 Generated Harper deploy artifacts usually include:
 
-- `harper-app/resources.js`
-- `harper-app/resource-*.js`
+- `harper-app/*.js` — every compiled module the build emits to the harper-app
+  root (`resources.js`, `resource-*.js`, and any other output such as a route
+  negotiation module). The single-star does **not** cross a directory separator,
+  so it does not match hand-written shims one level down.
 - `harper-app/web/**`
 - `harper-app/lib/**`
 
+The guard surfaces (`generated-artifact-globs.txt` for the PreToolUse block hook,
+`.gitignore`, `.prettierignore`, the ESLint/oxlint/knip ignores, and
+`tsconfig.eslint.json`) all key off `harper-app/*.js` so a newly-named compiled
+module is protected automatically. **Name compiled resource modules
+`resource-*.ts`** so their JS output is unambiguously generated.
+
+If you keep a *hand-written* `.js` at the harper-app root (e.g. an SEO shell),
+the root-level rule would otherwise treat it as generated: re-include it with a
+`!harper-app/<file>.js` line below the managed gitignore block, and add it to
+`.lisa/harper-generated-artifact-allowlist.txt` so the block hook lets you edit
+it. Hand-written shims nested under `harper-app/<route>/index.js` need no
+exemption — the root-level rule never matches them.
+
 Every lint, format, dead-code, search, or generated-artifact guard must ignore
-those generated paths unless it is explicitly validating the build output itself.
-When a new generated path appears, add it to every relevant ignore surface in the
-same change; partial ignores fail later gates in non-obvious ways.
+generated paths unless it is explicitly validating the build output itself. When
+a new generated *directory* appears, add it to every relevant ignore surface in
+the same change; partial ignores fail later gates in non-obvious ways.
 
 - **TypeScript under `src/` is source.** `bun run build` produces the deployable
   Harper assets from it.

package/plugins/lisa-harper-fabric-copilot/skills/harper-resources/SKILL.md

@@ -74,6 +74,41 @@ See [[harper-config-yaml]] for the extension wiring, [[harper-schema-graphql]] f
 how the schema defines the tables resources extend, and [[harper-realtime]] when
 `subscribe`, `publish`, or WebSocket behavior is part of the feature.
 
+## Throwing HTTP status errors
+
+Harper's thrown-error response writer reads **`error.statusCode`** (falling back
+to `500`). A plain `error.status` is **ignored** — throw an error with only
+`status` set and every intended `4xx` is served as a `500`. Verified on
+harperdb 4.7.32.
+
+Always set `statusCode` (keep `status` too only if callers or tests read it):
+
+```javascript
+static async post(target, data, context) {
+  if (!context.user) {
+    const error = new Error('Authentication required');
+    error.statusCode = 401; // NOT `error.status` — Harper reads statusCode
+    throw error;
+  }
+  // ...
+}
+```
+
+A shared helper keeps every throw site correct:
+
+```javascript
+function throwStatus(message, status) {
+  // Set both: `statusCode` is what Harper serves; `status` is kept for
+  // returned-response symmetry and any caller/test that reads it.
+  throw Object.assign(new Error(message), { status, statusCode: status });
+}
+```
+
+The `harper-require-statuscode-on-thrown-error` ast-grep rule flags errors that
+carry `status` without `statusCode`. Pass `context` through to `super` and nested
+table calls so authorization and the request transaction stay aligned — see
+[[harper-rest-queries]] for context propagation and iterator draining.
+
 ## Project conventions (TS is source)
 
 - **Write resources in TypeScript under `src/`. `harper-app/resources.js` is a

package/plugins/lisa-harper-fabric-copilot/skills/harper-rest-queries/SKILL.md

@@ -121,6 +121,38 @@ const products = await tables.Products.search({
 });
 ```
 
+## Sort with no conditions crashes the planner
+
+A `search()` that carries a `sort` but an **empty `conditions: []`** array throws
+at runtime — the planner cannot seed the btree scan from the sort attribute. This
+is a latent `500` the first time an unfiltered, sorted collection page is
+requested (verified on harperdb 4.7.32).
+
+```javascript
+// ✗ crashes: sort with nothing to seed the scan
+tables.Advisor.search({
+  conditions: [],
+  sort: { attribute: 'lastName' },
+});
+```
+
+Seed a floor/sentinel condition on the sort attribute so the planner has an index
+range to walk, then apply the sort:
+
+```javascript
+// ✓ floor condition on the sort attribute seeds the scan
+tables.Advisor.search({
+  conditions: [
+    { attribute: 'lastName', comparator: 'greater_than_equal', value: '' },
+  ],
+  sort: { attribute: 'lastName' },
+});
+```
+
+Centralize this in the page helper (`searchPageAndCount`) rather than duplicating
+a sentinel at each call site. The `harper-no-empty-conditions-with-sort` ast-grep
+rule flags the crashing shape.
+
 ## Relationship queries
 
 Relationship attributes can be queried with dot syntax when the relationship is
@@ -200,9 +232,14 @@ Useful query keys:
 | `select` | Projection list. Keep admin-only fields out of public responses. |
 | `explain` | Debug execution order and index usage while tuning. |
 
-`search()` can return an `AsyncIterable`. When iterating manually or stopping
-early, drain it or call the iterator's `return()` in `finally` so Harper can
-release the read transaction:
+`search()` can return an `AsyncIterable`. An early `return`/`break` out of a
+`for await (... of tables.X.search(...))` loop abandons the iterator before the
+scan completes and **leaks the open read transaction** (verified on
+harperdb 4.7.32). When iterating manually or stopping early, drain it or call the
+iterator's `return()` in `finally` so Harper releases the read transaction — or
+bound the query (`search({ ..., limit: 1 })`) when you only need the first row.
+The `harper-no-early-return-in-search-loop` ast-grep rule flags early exits from
+these loops:
 
 ```javascript
 const iterator = tables.Products

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

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

package/plugins/lisa-harper-fabric-cursor/generated-artifact-globs.txt

@@ -1,4 +1,5 @@
 harper-app/resources.js
 harper-app/resource-*.js
+harper-app/*.js
 harper-app/web/**
 harper-app/lib/**