Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/backend/scripts/run-bulldozer-studio.ts`:
- Around line 2038-2046: Reject raw delete requests that target the reserved
root paths by validating pathSegments before running retryTransaction: if
pathSegments is an empty array or exactly ["table"] then return a client error
(400) / throw an appropriate API error and do not call retryTransaction or
tx.$executeRawUnsafe. Add this check immediately after pathSegments is extracted
(the variable named pathSegments in the POST "/api/raw/delete" handler) and
include a clear error message; leave all existing DB deletion logic
(keyPathSqlLiteral, retryTransaction, globalPrismaClient, tx.$executeRawUnsafe)
unchanged otherwise.
- Around line 2022-2046: Both /api/raw/upsert and /api/raw/delete perform direct
mutations on "BulldozerStorageEngine" without acquiring the same advisory lock
used by executeStatements(), allowing interleaved tree edits; update both
request handlers to acquire the same Bulldozer advisory lock before running the
retryTransaction/globalPrismaClient transaction (i.e., call the same lock
acquisition used by executeStatements() at the start of the transaction scope),
then perform the existing tx.$executeRawUnsafe(...) logic (which uses
keyPathSqlLiteral and quoteSqlJsonbLiteral) and release automatically at
transaction end so raw upserts/deletes are serialized with other tree mutations.
- Around line 136-141: The call in executeStatements currently passes the whole
multi-statement script from toExecutableSqlStatements() into
tx.$executeRawUnsafe which fails because Prisma accepts a single statement per
call; change executeStatements to split the script returned by
toExecutableSqlStatements() into individual SQL statements (e.g., by
semicolon-aware parsing or the existing splitter utility) and then run each
statement sequentially inside the retryTransaction using tx.$executeRawUnsafe
for each one (keeping the SET LOCAL jit and SELECT pg_advisory_xact_lock calls
as individual executions); alternatively, route the full script through a driver
that supports multi-statement scripts if present, but prefer per-statement
execution to fix failures when pg_temp.bulldozer_sort_* is involved.

In `@apps/backend/scripts/run-cron-jobs.ts`:
- Line 28: The inline comment for the wait call is misleading: update the
comment next to the await wait(30_000) call in run-cron-jobs.ts so it reflects
the actual delay (e.g., "Wait 30 seconds to make sure the server is fully
started") or, if the intent was a shorter pause, change the numeric literal
(30_000) to the intended duration (e.g., 3_000) and keep the comment consistent;
ensure the comment and the await wait(...) value match.

In `@apps/backend/src/lib/bulldozer/db/bulldozer-sort-helpers-sql.ts`:
- Around line 573-616: bulldozer_sort_bulk_init_from_table currently hard-codes
ORDER BY "rowSortKey" ASC which conflicts with custom comparators; update the
function signature to accept compare_sort_keys_sql and use it in the dynamic
SELECT (instead of the fixed 'ORDER BY "rowSortKey" ASC, "rowIdentifier" ASC')
so ordered_rows respects the provided comparator, or alternatively change the
implementation to build the initial tree by iterating rows and calling
pg_temp.bulldozer_sort_insert for each row (keeping
pg_temp.bulldozer_sort_ensure_group, pg_temp.bulldozer_sort_build_balanced_group
and pg_temp.bulldozer_sort_put_group_metadata interactions intact) so ordering
logic matches bulldozer_sort_insert/bulldozer_sort_delete.

In `@apps/backend/src/lib/bulldozer/db/example-schema.ts`:
- Around line 103-108: The filter used to build accountEntriesWithCounterparty
currently uses the JSON operator -> which leaves JSON null values as a
non-SQL-NULL and lets rows with counterparty: null through; update the predicate
in the declareFilterTable call (accountEntriesWithCounterparty, fromTable
entriesByAccount) to use the text operator ->> instead (e.g.
("rowData"->>'counterparty') IS NOT NULL) so JSON null and missing keys are
treated as SQL NULL and correctly filtered out.

In `@apps/backend/src/lib/bulldozer/db/index.ts`:
- Around line 54-67: In toExecutableSqlStatements, always use the sequential
temp-table execution path (the sequential temp-table approach currently guarded
by requiresSortSequentialExecutor) instead of the sibling-CTE branch; remove the
conditional branch that returns the sibling-CTE string and ensure the function
builds and returns the sequential executor SQL (the temp-table / sequential
execution block that currently lives in the other branch), eliminating
requiresSortSequentialExecutor or making it always true so data-modifying
statements (DELETE/INSERT) execute in order and can observe prior changes;
update any related variables
(requiresSortHelpers/requiresSortSequentialExecutor) and tests accordingly.

In `@apps/backend/src/lib/bulldozer/db/tables/group-by-table.ts`:
- Around line 187-188: The compareGroupKeys() (and the duplicate at lines
~271-283) currently returns a constant 0 causing all groups to be treated equal;
replace the stub with a real SQL JSONB comparator and thread it through
listGroups() by updating singleNullSortKeyRangePredicate() to use the same
documented JSONB default comparator, and similarly implement compareSortKeys()
to perform proper JSONB sort-key comparison; specifically, update the
compareGroupKeys and compareSortKeys functions to emit a sqlExpression that
compares JSONB values deterministically (the same expression used by
singleNullSortKeyRangePredicate/listGroups) so group range queries and
downstream operators get a correct ordering.
- Around line 16-24: The declareGroupByTable signature and implementation are
unsound: NewRD is declared but the function always returns OldRD, fromTable
erases the sort-key type with any, and compareGroupKeys returns 0 making all
groups equal. Fix by changing the generic parameters to clearly separate input
row type (OldRD) and output/group row type (NewRD), remove the any by preserving
fromTable's sort-key generic (e.g., Table<GK, SK, OldRD>), and update
declareGroupByTable to return Table<GK, SK, NewRD> (or appropriate nullability)
while transforming OldRD -> NewRD using the provided groupBy mapper; implement
compareGroupKeys to perform a real comparison based on GK (or delegate to a
provided comparator) and throw or assert if assumptions about key shape fail
instead of silently returning 0. Ensure you update uses of fromTable, groupBy,
and compareGroupKeys to match the new generics and transformation contract.

In `@apps/backend/src/lib/bulldozer/db/tables/l-fold-table.ts`:
- Around line 716-740: listRowsInGroup currently orders results with a
hard-coded "ORDER BY ... rowSortKey ASC" which can disagree with the comparator
used when folding (options.fromTable.compareSortKeys); update listRowsInGroup to
use the same ordering expression that the fold computation uses (or an explicit
persisted ordinal) instead of raw "rowSortKey ASC". Specifically, replace the
ASC ordering in both query branches with the sort expression derived from
options.fromTable.compareSortKeys (or a stored emitted ordinal), ensuring the
sortRangePredicate and ordering use the identical comparator logic; refer to
listRowsInGroup, sortRangePredicate, getGroupRowsPath, groupsPath, rowSortKey
and options.fromTable.compareSortKeys to locate where to apply the change.

In `@apps/backend/src/lib/bulldozer/db/tables/left-join-table.ts`:
- Around line 435-457: The queries in listRowsInGroup lack ORDER BY, causing
non-deterministic row order; update both branches of listRowsInGroup to append
deterministic ORDER BY clauses: for the single-group branch (the branch with
only "row") ORDER BY the computed rowIdentifier (the
("row"."keyPath"[cardinality("row"."keyPath")] #>> '{}') expression), and for
the multi-group branch ORDER BY groupKey then rowIdentifier (groupPath keyPath
expression then ("rows"."keyPath"[cardinality("rows"."keyPath")] #>> '{}') ), so
that compareSortKeys' constant sort key is disambiguated by these stable
tie-breakers. Ensure the ORDER BY uses the same expressions/aliases used in the
SELECT so they remain correct after any refactor.

In `@apps/backend/src/lib/bulldozer/db/tables/limit-table.ts`:
- Around line 118-124: The ranking/read queries in limit-table.ts use raw JSONB
ordering ("rows"."rowSortKey") which ignores the table's declared comparator;
update the ORDER BY clauses (the ones producing "rank" and the subsequent read
queries that reference "rankedRows") to use the table's comparator by invoking
options.fromTable.compareSortKeys(...) (or the equivalent helper that emits the
comparator-aware SQL expression) instead of ordering by the raw JSONB column,
and ensure the tie-breaker "rows"."rowIdentifier" remains; apply the same fix to
the other occurrences noted (the blocks around lines 138-145, 277-283, 376-404)
so that normalizedLimit and rankedRows reflect the comparator-aware ordering.

In `@apps/backend/src/lib/bulldozer/db/tables/sort-table.ts`:
- Around line 312-334: The recursive CTE uses sort-key bounds
(options.fromTable.compareGroupKeys) to prune groups in the all-groups path (the
"groupMetadatas" block), which can incorrectly drop groups or compare the wrong
JSON shape when groupKey is omitted; update the WHERE clauses that inject
start/end comparisons so they skip calling options.fromTable.compareGroupKeys
(use a no-op condition like 1 = 1) when the query is for the all-groups path
(i.e., when groupKey is not present/omitted), and ensure any actual sort-key
filtering is deferred to the existing sortRangePredicate()/sort-range handling
later; refer to "groupMetadatas", "groupPath", "groupMetadata", and
options.fromTable.compareGroupKeys to locate and change the two conditional
SQLExpression injections for start and end.

---

Nitpick comments:
In `@apps/backend/prisma/schema.prisma`:
- Around line 1250-1258: The BulldozerStorageEngine model is missing
createdAt/updatedAt timestamps used elsewhere for observability; add createdAt
DateTime `@default`(now()) and updatedAt DateTime `@updatedAt` fields to the
BulldozerStorageEngine model (referencing the model name and field identifiers)
so new records record creation time and updates auto-update, or if omission is
intentional for performance, add a comment in the model noting that rationale
instead of leaving them out.

In `@apps/backend/src/lib/bulldozer/db/index.ts`:
- Around line 11-36: The Table type is duplicated here; remove the local
duplicate definition and re-export the canonical interface from the existing
declaration in table-type.ts instead. Replace the local type block in this file
with a re-export of the Table symbol from the module that defines it
(table-type.ts) so there is a single source of truth, and update any local
references in this file to use that re-exported Table type (keep function names
like listGroups, listRowsInGroup, compareGroupKeys, compareSortKeys, init,
delete, isInitialized, registerRowChangeTrigger unchanged). Ensure exports
remain the same shape so other modules importing Table from this file keep
working.

In `@apps/backend/src/lib/bulldozer/db/tables/concat-table.ts`:
- Line 32: The function rawExpression currently constructs an SqlExpression<T>
from an arbitrary string and thus bypasses template literal SQL safety; update
the implementation by either renaming rawExpression to unsafeRawExpression to
make the unsafe contract explicit or add a clear inline comment above
rawExpression calling out that callers are responsible for sanitizing inputs to
avoid SQL injection, referencing the SqlExpression type and any callers that use
rawExpression so they can be audited for safety.

In `@apps/backend/src/lib/bulldozer/db/tables/flat-map-table.ts`:
- Around line 213-214: The compareSortKeys assignment uses sqlExpression with an
extra leading space (sqlExpression` 0 `); update the compareSortKeys lambda to
use sqlExpression`0` (no leading/trailing space) so it matches the style used in
concat-table.ts and removes the inconsistent whitespace around the literal;
locate the compareSortKeys definition and replace the template literal
accordingly.
- Around line 29-30: The current createExpandedRowIdentifier builds identifiers
by concatenating sourceRowIdentifier and the ordinality-based flatIndex
(generated via WITH ORDINALITY), which causes identifier churn when mapper
output shifts; change this to produce stable identifiers by deriving a
content-based key instead of using positional index—e.g., compute a
deterministic hash of the mapped element (or use a stable key field provided by
the mapper) and combine that with sourceRowIdentifier; update
createExpandedRowIdentifier to accept a content-based SqlExpression (e.g.,
mappedElement or mappedElementHash) instead of flatIndex and ensure callers that
invoke createExpandedRowIdentifier supply the stable key/hash rather than the
ordinal.

In `@apps/backend/src/lib/bulldozer/db/utilities.ts`:
- Around line 40-42: quoteSqlStringLiteral currently only escapes single quotes
which can miss edge cases like null bytes and problematic Unicode; update it to
normalize and explicitly handle such characters. Modify the
quoteSqlStringLiteral function to: 1) reject or encode null bytes (e.g., throw
on '\0' or replace with an explicit escape sequence) and 2) normalize input
(e.g., NFC) and optionally escape or validate noncharacter code points and
surrogate pairs before building the SqlExpression; ensure the resulting sql
string still uses the existing single-quote doubling logic and that the function
signature (quoteSqlStringLiteral and the returned SqlExpression<string>) remains
unchanged.
- Around line 78-87: Add a docstring to singleNullSortKeyRangePredicate that
explains it computes whether a NULL sort key can satisfy the provided range:
document the options parameters (start, end, startInclusive, endInclusive),
state that when a bound is the literal "start" or "end" it means unbounded, and
explicitly call out the edge case where either bound is exclusive and not
unbounded—this function will return false because NULL cannot satisfy strict >
or < comparisons; also mention the returned SqlExpression<boolean> semantics
(always-true or always-false SQL literal).

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/backend/src/lib/bulldozer/db/tables/limit-table.ts`:
- Line 374: The ORDER BY in listRowsInGroup is using raw JSONB ordering (ORDER
BY rowSortKey ASC) but the WHERE bounds use options.fromTable.compareSortKeys,
causing inconsistent ordering; update the query so ordering uses the same
comparator expression used for bounds—e.g., project the comparator result (or
call the same compareSortKeys expression/function) in the SELECT as an alias and
ORDER BY that alias, or if the comparator matches JSONB semantics, document that
constraint instead; ensure references to rowSortKey and rowIdentifier remain for
stable tie-breaking.

---

Nitpick comments:
In `@apps/backend/src/lib/bulldozer/db/index.ts`:
- Line 13: Add an inline comment next to the inputTables parameter that explains
why Table<any, any, any>[] uses any (e.g., dynamic table schemas, third-party
types, or runtime-validated shapes) and describe how type safety is preserved
(runtime validation, narrowing later in functions like the code that processes
inputTables, or use of discriminated unions). Reference the symbol inputTables
and the Table<any, any, any> type in your comment so reviewers see the
justification and the mitigation strategy.
- Line 93: Validate options.statementTimeout before interpolating into the SQL
string: before the template that builds `${options.statementTimeout ? \`SET
LOCAL statement_timeout = '\${options.statementTimeout}';\` : ""}`, add a
defensive check that options.statementTimeout is a non-empty string matching an
allowed format (for example /^\d+(ms|s|min|h)?$/ or whichever units your DB
accepts) and throw a clear error (e.g., new Error("Invalid statementTimeout
format")) if it fails; keep the rest of the interpolation unchanged so only
validated values are used.