claude/zealous-lovelace-cbc97f

`total: sql<number>` maps PostgreSQL bigint via JS Number

domains/utility/src/utility-contract-overview/utility-contract-overview.queries.ts:526

`count(*) OVER ()` returns a PostgreSQL `bigint`. `.mapWith(Number)` coerces it through JS Number, which loses precision past 2^53. Not a realistic concern at current org contract volumes, but the conventional pattern is `sql<string>` + `parseInt`. Low priority — but worth aligning with the rest of the codebase if other count queries use the string-then-parse pattern.

No upper bound on `limit` at query layer — potential DB pressure

domains/utility/src/utility-contract-overview/utility-contract-overview.queries.ts:530

`listOverviewKeys` accepts `limit` with no cap enforced inside the function. A misbehaving caller passing a very large value forces `count(*) OVER ()` to materialize the full matching result set (window functions enumerate all rows before LIMIT applies), which can be expensive on large orgs. The project's convention is validation at the shell/handler layer, but a `Math.min(input.limit, MAX_KEYS_LIMIT)` guard (e.g. 5000, matching other list endpoints) at the query layer would be defence-in-depth. No immediate bug — add as a follow-up or add a JSDoc note documenting the caller's responsibility.

Org isolation relies on WHERE clause, not RLS — established pattern, not new risk

domains/utility/src/utility-contract-overview/utility-contract-overview.queries.ts

`listOverviewKeys` accepts `DbOrTx` which may be a non-RLS handle. Cross-org isolation relies entirely on `orgId` in the WHERE clause from `buildFullWhere`. This is the established project pattern (shells own `createRLSDb` wrapping) and not a new risk introduced here — but worth noting that any new handler wiring must use an RLS-wrapped db.

Search parameter injection safety inherited from `buildFullWhere` — not a new risk

domains/utility/src/utility-contract-overview/utility-contract-overview.queries.ts

The `search` parameter flows to the existing `buildFullWhere` (already in production via `listOverviewPage`). As long as `buildFullWhere` uses Drizzle's parameterized SQL (not raw string interpolation), there is no injection risk. No action needed — confirmed existing production path.

`matchesNothing` fast-path not tested in isolation

domains/utility/src/utility-contract-overview/__tests__/utility-contract-overview.integration.test.ts

The `matchesNothing` early return (which skips the DB query entirely) is covered only incidentally by the integration test for empty phases. A lightweight unit test asserting `db.select` is never called when `matchesNothing=true` would make the fast-path contract explicit. Low priority — the integration test will catch a regression if the early return is deleted.

Redundant rows.map() — strips `total` that could stay on the row

domains/utility/src/utility-contract-overview/utility-contract-overview.queries.ts:530

The `.map(r => ({ contractPublicId, contractNumber, serviceName }))` call exists only to drop the `total` column. Since Drizzle's `.select({...})` already types each row with the exact fields, the cleaner approach is to extract `total` from `rows[0]?.total` and return `rows` directly as `keys` (they already lack `total` in the mapped type if you name the select fields as `OverviewKey` fields). Minor clarity improvement — not a bug.

`ListOverviewKeysInput` could be `OverviewWhereInput & { limit }` to prevent structural drift

domains/utility/src/utility-contract-overview/utility-contract-overview.queries.ts:103

`ListOverviewKeysInput` manually replicates the same 6 fields as `OverviewWhereInput`. Defining it as `OverviewWhereInput & { readonly limit: number }` would make structural identity explicit — any new filter field added to `OverviewWhereInput` (e.g. a new filter axis) is automatically included in the keys query without a second edit.

`listOverviewPage` docstring could explain why window function was not used there

domains/utility/src/utility-contract-overview/utility-contract-overview.queries.ts

`listOverviewPage` uses two parallel queries (page + count), while `listOverviewKeys` uses `count(*) OVER ()` for snapshot consistency. A brief note on `listOverviewPage` explaining why the window approach was NOT used (window functions force a full scan before LIMIT, hurting pagination performance for large orgs) would prevent a future reader from 'simplifying' it into a window function and regressing performance.