bridgebench 3.1.0-alpha.1 → 3.1.0-alpha.2

package/tasks/generation/public/spec-conformance-slug-normalizer.yaml

@@ -0,0 +1,177 @@
+id: spec-conformance-slug-normalizer
+version: 1.0.0
+category: generation
+cluster: spec-conformance
+difficulty: expert
+title: normalizeSlug — Which Of Five Submissions Conforms To Every Clause
+summary: A frozen specification defines normalizeSlug(input) as a strict seven-clause pipeline. Five candidate implementations are under review; exactly one matches the spec on every input while each of the other four violates one specific, citable clause. Classify all five and name the distinguishing input for each near-miss.
+prompt: |
+  Answer each deliverable using ONLY the supplied artifacts (normalizer-spec, test-vectors,
+  candidates-a, candidates-b, reviewer-thread, submission-manifest). Cite the artifact id(s)
+  for every claim. Do not invent requirements the spec does not state, and do not overlook a
+  clause it does state. The verdict vocabulary is exactly: conforms / violates.
+
+  The spec (normalizer-spec) declares clauses C1..C7 and is the complete contract. The
+  submission-manifest declares that candidate-1..candidate-5 are the entire set under review
+  and that exactly one is to be accepted.
+
+  1. Classify each of candidate-1, candidate-2, candidate-3, candidate-4, candidate-5 as
+     `conforms` or `violates` against normalizer-spec.
+
+  2. For every candidate you mark `violates`, name the single clause (one of C1..C7) it breaks
+     and give one concrete input string on which its output differs from the spec-correct
+     output. State both the spec-correct output and the candidate's output for that input.
+
+  3. Exactly one candidate `conforms`. Identify it, and state the output it produces for the
+     test-vectors input "café_düsseldorf".
+
+  4. In reviewer-thread, reviewer @ravi argues candidate-2 conforms because "it lowercases,
+     collapses separator runs to a single hyphen, trims, truncates to 40 with a trailing-hyphen
+     removal, and falls back to 'n-a' — every clause is represented." State candidate-2's verdict
+     and cite the one clause that refutes @ravi, with a discriminating input and both outputs.
+
+  5. reviewer-thread references BUG-88: one submission returns an empty string ("") instead of
+     "n-a" when the input is entirely punctuation (e.g. "@@@"). Name the single candidate BUG-88
+     belongs to and the clause it breaks. Confirm no other candidate has this defect.
+artifacts:
+  - id: normalizer-spec
+    type: spec
+    label: normalizeSlug specification (frozen, complete)
+    content: |
+      normalizeSlug(input: string): string
+
+      A pure, deterministic transform applied as an ORDERED pipeline. The clauses below are the
+      COMPLETE contract for this function; there are no other requirements. An implementation
+      conforms only if it produces the specified output for EVERY input, not merely if each clause
+      is "present" in some form.
+
+      C1  LOWERCASE. Map every character in the ASCII range U+0041..U+005A (A..Z) to its lowercase
+          form. Leave every other character unchanged. (No locale-specific casing; ASCII only.)
+
+      C2  SEPARATOR SET. After C1, a "separator" is any character NOT in the set [a-z0-9] (i.e. not
+          a lowercase ASCII letter and not an ASCII digit 0-9). Underscore '_', whitespace, all
+          punctuation, and every non-ASCII code point (e.g. 'é', 'ü', '—') are separators.
+
+      C3  COLLAPSE. Replace each maximal run of one-or-more separators with exactly one U+002D
+          hyphen-minus '-'. Two adjacent separators must not yield two hyphens.
+
+      C4  TRIM. Remove all leading and trailing '-' characters from the collapsed string.
+
+      C5  TRUNCATE. If the string's length exceeds 40, keep only the first 40 characters, then
+          remove a single trailing '-' if the 40th character is a hyphen. (Maximum length is 40;
+          truncation must never leave a trailing hyphen.)
+
+      C6  FALLBACK. If the string is now empty (length 0), return the literal "n-a". Otherwise
+          return the string. This clause is unconditional and does not depend on whether an
+          empty result is "expected" for a given input.
+
+      C7  DIGITS. ASCII digits 0-9 are preserved verbatim and are never treated as separators.
+
+      This is the entire specification. No other clause exists.
+  - id: test-vectors
+    type: table
+    label: authoritative input/output vectors (spec-correct)
+    content: |
+      These are the authoritative expected outputs computed from normalizer-spec. A conforming
+      implementation must reproduce every row exactly.
+
+      #  input                                            expected output
+      -- ------------------------------------------------ ---------------------------------------
+      1  "Hello, World!"                                  "hello-world"
+      2  "Node.js  ROCKS!!!"    (two spaces)              "node-js-rocks"
+      3  "café_düsseldorf"                                "caf-d-sseldorf"
+      4  "___"                                            "n-a"
+      5  "alpha beta gamma delta epsilon zeta eta theta"  "alpha-beta-gamma-delta-epsilon-zeta-eta"
+      6  "foo_bar"                                        "foo-bar"
+
+      Worked notes:
+        - Row 3: 'é', '_', 'ü' are all separators (C2). "café_" -> "caf" + one hyphen (the run
+          "é_" collapses per C3); "ü" -> one hyphen. Result "caf-d-sseldorf".
+        - Row 5: the collapsed slug is 45 chars ("alpha-beta-gamma-delta-epsilon-zeta-eta-theta").
+          The first 40 chars end in a hyphen ("...zeta-eta-"), which C5 removes, giving 39 chars.
+        - Row 6: '_' is a separator (C2), so "foo_bar" -> "foo-bar".
+  - id: candidates-a
+    type: code
+    label: submissions candidate-1, candidate-2, candidate-3
+    content: |
+      // Each function is a complete, standalone implementation of normalizeSlug.
+
+      // ---- candidate-1 ----
+      function candidate1(input: string): string {
+        let s = input.replace(/[A-Z]/g, (c) => c.toLowerCase());  // C1
+        s = s.replace(/[^a-z0-9]+/g, '-');                        // C2 + C3
+        s = s.replace(/^-+/, '').replace(/-+$/, '');              // C4
+        if (s.length > 40) s = s.slice(0, 40).replace(/-$/, '');  // C5
+        return s.length === 0 ? 'n-a' : s;                        // C6
+      }
+
+      // ---- candidate-2 ----
+      function candidate2(input: string): string {
+        let s = input.replace(/[A-Z]/g, (c) => c.toLowerCase());
+        s = s.replace(/[^\w]+/g, '-');   // \w is [A-Za-z0-9_]
+        s = s.replace(/^-+/, '').replace(/-+$/, '');
+        if (s.length > 40) s = s.slice(0, 40).replace(/-$/, '');
+        return s.length === 0 ? 'n-a' : s;
+      }
+
+      // ---- candidate-3 ----
+      function candidate3(input: string): string {
+        let s = input.replace(/[A-Z]/g, (c) => c.toLowerCase());
+        s = s.replace(/[^a-z0-9]+/g, '-');
+        s = s.replace(/^-+/, '').replace(/-+$/, '');
+        if (s.length > 40) s = s.slice(0, 40);   // truncates; no trailing-hyphen removal
+        return s.length === 0 ? 'n-a' : s;
+      }
+  - id: candidates-b
+    type: code
+    label: submissions candidate-4, candidate-5
+    content: |
+      // ---- candidate-4 ----
+      function candidate4(input: string): string {
+        let s = input.replace(/[A-Z]/g, (c) => c.toLowerCase());
+        s = s.replace(/[^a-z0-9]+/g, '-');
+        s = s.replace(/^-+/, '').replace(/-+$/, '');
+        if (s.length > 40) s = s.slice(0, 40).replace(/-$/, '');
+        return s;    // returns s directly, including '' when the result is empty
+      }
+
+      // ---- candidate-5 ----
+      function candidate5(input: string): string {
+        let s = input.replace(/[A-Z]/g, (c) => c.toLowerCase());
+        s = s.replace(/[^a-z0-9]/g, '-');   // no '+': each separator char becomes its own hyphen
+        s = s.replace(/^-+/, '').replace(/-+$/, '');
+        if (s.length > 40) s = s.slice(0, 40).replace(/-$/, '');
+        return s.length === 0 ? 'n-a' : s;
+      }
+  - id: reviewer-thread
+    type: note
+    label: code-review discussion on PR #4471
+    content: |
+      Review thread for the five normalizeSlug submissions (PR #4471).
+
+      @ravi: "I stepped candidate-2 through the spec. It lowercases (C1), it collapses separator
+      runs to a single hyphen (C2/C3 — note the '+' in the regex), it trims the ends (C4), it
+      truncates to 40 and strips a trailing hyphen (C5), and it falls back to 'n-a' on empty (C6).
+      Every clause is represented, so I lean toward approving candidate-2."
+
+      @lena: "The bar is not 'every clause is represented somewhere' — it is 'matches the spec on
+      every input.' Compare the exact character classes and the exact order of operations before
+      approving anything."
+
+      BUG-88 (filed by QA, not yet triaged to a specific candidate): "One of the five submissions
+      returns an empty response body instead of 'n-a' when the input string is entirely
+      punctuation (repro input: \"@@@\")." Note: C6 is unconditional and applies regardless of
+      whether an all-punctuation input is considered 'realistic'.
+  - id: submission-manifest
+    type: note
+    label: submission manifest and acceptance rule
+    content: |
+      Submissions under review for normalizeSlug: candidate-1, candidate-2, candidate-3,
+      candidate-4, candidate-5. This is the COMPLETE set — there is no candidate-6 and no other
+      implementation is being considered.
+
+      Acceptance rule: exactly one submission is to be accepted. A submission is accepted only if
+      it conforms to normalizer-spec on every input (it reproduces all six rows of test-vectors and
+      obeys clauses C1..C7 generally). At most one of the five satisfies this; the acceptance
+      process assumes precisely one conformer exists in the set.
+tags: [generation, spec-conformance, string-processing, code-review]

package/tasks/refactoring/public/api-migration-http-retry-client.yaml

@@ -0,0 +1,208 @@
+id: api-migration-http-retry-client
+version: 1.0.0
+category: refactoring
+cluster: api-migration
+difficulty: expert
+title: Migrating retryFetch call sites to the http.send client at Kelvin Freight
+summary: Six call sites are being moved from the legacy retryFetch helper to the new http.send client. The two APIs look alike but differ in attempt counting, body serialization, return shape, and error type. Classify each migrated call site as behavior-preserving or changes-behavior, citing the exact mismatch.
+prompt: |
+  The platform team at Kelvin Freight is retiring the legacy `retryFetch` helper in favor
+  of the new `http.send` client. A junior engineer has proposed six migrated call sites
+  (proposed-migrations M1..M6), each replacing an original in call-sites (C1..C6).
+
+  Answer each deliverable using ONLY the supplied artifacts (legacy-api, new-api,
+  mapping-note, call-sites, proposed-migrations). Cite the artifact id(s) for every claim.
+
+  For each migrated call site below, classify it as exactly one of:
+    - behavior-preserving  (the rewrite produces the same observable behavior as the original)
+    - changes-behavior     (the rewrite alters observable behavior; name the single defect)
+
+  "Observable behavior" includes the value/type returned to callers, the bytes and headers
+  sent on the wire, the number of network attempts made, which status codes trigger a retry,
+  and which catch branch fires. Assume the servers behave identically for both clients.
+
+  1. Classify M1 (the migration of C1).
+  2. Classify M2 (the migration of C2).
+  3. Classify M3 (the migration of C3).
+  4. Classify M4 (the migration of C4).
+  5. Classify M5 (the migration of C5).
+  6. Classify M6 (the migration of C6).
+
+  Exactly one classification is defensible per deliverable; it is fully determined by the
+  artifacts. For every changes-behavior verdict, state the single citable defect and, where
+  relevant, a concrete input or condition that witnesses the difference.
+artifacts:
+  - id: legacy-api
+    type: spec
+    label: legacy retryFetch helper — signature, defaults, semantics
+    content: |
+      // http/legacy.ts — the retryFetch helper being retired.
+      // This is the COMPLETE set of options retryFetch accepts; there are no others.
+
+      function retryFetch<T>(url: string, opts?: {
+        method?: string;                 // default 'GET'
+        headers?: Record<string, string>;// default {}  (NO header is ever added implicitly)
+        body?: string;                   // RAW request body, sent verbatim. retryFetch does
+                                         // NOT serialize and does NOT set Content-Type. If the
+                                         // caller wants JSON, the caller must JSON.stringify AND
+                                         // set the Content-Type header itself.
+        retries?: number;                // number of ADDITIONAL attempts after the first.
+                                         // default 2. Total attempts made = 1 + retries.
+        timeoutMs?: number;              // per-attempt timeout. default 5000
+        retryOn?: number[];              // status codes that trigger a retry. default [502,503,504]
+      }): Promise<T>;
+
+      // Return / error semantics:
+      //  - On a 2xx response, retryFetch parses the body as JSON and RETURNS the parsed value (T).
+      //  - On a non-2xx whose status is in retryOn, it retries (up to `retries` more attempts).
+      //    After attempts are exhausted it throws LegacyHttpError with a numeric `.status` field.
+      //  - On a non-2xx NOT in retryOn, it throws LegacyHttpError immediately (no retry).
+      //  - LegacyHttpError exposes the failing HTTP status on the property `.status`.
+  - id: new-api
+    type: spec
+    label: new http.send client — signature, defaults, semantics
+    content: |
+      // http/client.ts — the replacement client. This is the COMPLETE option set for http.send.
+
+      http.send<T>(req: {
+        url: string;
+        method?: string;                 // default 'GET'
+        headers?: Record<string, string>;// default {}
+        json?: unknown;                  // when present, http.send JSON.stringifies this value AND
+                                         // sets the header Content-Type: application/json. Mutually
+                                         // exclusive with `body`.
+        body?: string;                   // raw body, sent verbatim, NO header added. Use this (not
+                                         // json) for any payload that is not application/json.
+        maxAttempts?: number;            // TOTAL attempts including the first. default 3.
+        timeoutMs?: number;              // per-attempt timeout. default 5000
+        retryStatuses?: number[];        // status codes that trigger a retry. default [502,503,504]
+      }): Promise<{ data: T; status: number }>;
+
+      // Return / error semantics:
+      //  - On a 2xx response, http.send RESOLVES to an envelope { data, status } where `data` is
+      //    the parsed JSON body and `status` is the numeric HTTP status. Callers must read `.data`.
+      //  - On a non-2xx whose status is in retryStatuses, it retries up to maxAttempts total, then
+      //    throws SendError. On a non-2xx not in retryStatuses it throws SendError immediately.
+      //  - SendError exposes the failing HTTP status on the property `.statusCode` (NOT `.status`).
+  - id: mapping-note
+    type: note
+    label: intended migration rules (platform team)
+    content: |
+      How to move a retryFetch call to http.send without changing behavior. These rules are
+      exhaustive for the differences between the two APIs.
+
+      1. RETURN SHAPE. retryFetch returns the parsed body directly; http.send returns
+         { data, status }. Every migrated call must read `.data` (e.g. destructure
+         `const { data } = await http.send(...)`) to recover the old return value.
+
+      2. ATTEMPT COUNT. retryFetch `retries: N` means N attempts AFTER the first, i.e. 1 + N
+         total. http.send `maxAttempts: M` is the TOTAL. So the faithful mapping is
+         maxAttempts = retries + 1. Copying the number across (maxAttempts = retries) drops one
+         attempt.
+
+      3. BODY. Use http.send `json:` ONLY when the original set Content-Type: application/json and
+         passed body: JSON.stringify(x); replace both with `json: x`. For ANY other body (raw text,
+         csv, form data, or a body sent without a Content-Type header) keep `body:` verbatim and
+         carry the original headers, because `json:` both re-serializes the value and forces
+         Content-Type: application/json.
+
+      4. DEFAULTS ALIGN. method ('GET'), timeoutMs (5000), and the retry status set ([502,503,504])
+         have identical defaults in both APIs, and http.send's default maxAttempts (3) equals
+         retryFetch's default total attempts (1 + default retries 2 = 3). Omitting all of these on
+         both sides is behavior-preserving. Only change a default if the original set it explicitly.
+
+      5. ERRORS. A catch block that read `LegacyHttpError.status` must read `SendError.statusCode`
+         after the switch; the property was renamed.
+  - id: call-sites
+    type: code
+    label: original retryFetch call sites (C1..C6)
+    content: |
+      // C1 — read a user, render its email
+      const u1 = await retryFetch<User>('/users/1');
+      renderCard(u1.email);
+
+      // C2 — read a user, render its email
+      const u2 = await retryFetch<User>('/users/2');
+      renderCard(u2.email);
+
+      // C3 — create an order; JSON body with explicit Content-Type; 5 extra retries
+      await retryFetch('/orders', {
+        method: 'POST',
+        headers: { 'Content-Type': 'application/json' },
+        body: JSON.stringify(order),
+        retries: 5,
+      });
+
+      // C4 — emit an event; JSON body; 2 extra retries; 8s timeout; retry only on 503
+      await retryFetch('/events', {
+        method: 'POST',
+        headers: { 'Content-Type': 'application/json' },
+        body: JSON.stringify(evt),
+        retries: 2,
+        timeoutMs: 8000,
+        retryOn: [503],
+      });
+
+      // C5 — ingest a CSV export; raw text body with a text/csv Content-Type
+      await retryFetch('/ingest', {
+        method: 'POST',
+        headers: { 'Content-Type': 'text/csv' },
+        body: csvRows,           // csvRows is already a CSV string
+      });
+
+      // C6 — charge a card; on HTTP 402 show the payment-required screen, else rethrow
+      try {
+        await retryFetch('/charge', {
+          method: 'POST',
+          headers: { 'Content-Type': 'application/json' },
+          body: JSON.stringify(chg),
+        });
+      } catch (e) {
+        if (e instanceof LegacyHttpError && e.status === 402) showPaymentRequired();
+        else throw e;
+      }
+  - id: proposed-migrations
+    type: code
+    label: proposed http.send rewrites (M1..M6)
+    content: |
+      // M1 — migration of C1
+      const { data: u1 } = await http.send<User>({ url: '/users/1' });
+      renderCard(u1.email);
+
+      // M2 — migration of C2
+      const u2 = await http.send<User>({ url: '/users/2' });
+      renderCard(u2.email);
+
+      // M3 — migration of C3
+      await http.send({
+        url: '/orders',
+        method: 'POST',
+        json: order,
+        maxAttempts: 5,
+      });
+
+      // M4 — migration of C4
+      await http.send({
+        url: '/events',
+        method: 'POST',
+        json: evt,
+        maxAttempts: 3,
+        timeoutMs: 8000,
+        retryStatuses: [503],
+      });
+
+      // M5 — migration of C5
+      await http.send({
+        url: '/ingest',
+        method: 'POST',
+        json: csvRows,
+      });
+
+      // M6 — migration of C6
+      try {
+        await http.send({ url: '/charge', method: 'POST', json: chg });
+      } catch (e) {
+        if (e instanceof SendError && e.status === 402) showPaymentRequired();
+        else throw e;
+      }
+tags: [api-migration, refactoring, http-client, behavior-preservation]

package/tasks/refactoring/public/api-migration-orm-query-builder.yaml

@@ -0,0 +1,187 @@
+id: api-migration-orm-query-builder
+version: 1.0.0
+category: refactoring
+cluster: api-migration
+difficulty: expert
+title: Migrating findAll queries to repo.query at Larkspur Analytics
+summary: Six data-access call sites are moving from the legacy findAll query builder to the new repo.query builder. Null handling, sort-direction casing, pagination argument names, and soft-delete flags differ between the two. Classify each migrated query as behavior-preserving or changes-behavior, citing the exact mismatch.
+prompt: |
+  Larkspur Analytics is replacing its legacy `db.findAll` query builder with the new
+  `repo.query` builder. A migration PR rewrites six queries (proposed-queries Q1..Q6), each
+  replacing an original in legacy-queries (Q1..Q6).
+
+  Answer each deliverable using ONLY the supplied artifacts (legacy-builder, new-builder,
+  mapping-note, legacy-queries, proposed-queries). Cite the artifact id(s) for every claim.
+
+  For each migrated query below, classify it as exactly one of:
+    - behavior-preserving  (the rewrite selects the same rows in the same order as the original)
+    - changes-behavior     (the rewrite alters the result set or ordering; name the single defect)
+
+  "Same behavior" means the same rows (same filter, same soft-delete inclusion), the same page
+  (same limit/offset window), and the same ordering. Assume identical table contents for both
+  builders.
+
+  1. Classify Q1.
+  2. Classify Q2.
+  3. Classify Q3.
+  4. Classify Q4.
+  5. Classify Q5.
+  6. Classify Q6.
+
+  Exactly one classification is defensible per deliverable; it is fully determined by the
+  artifacts. For every changes-behavior verdict, name the single citable defect and, where
+  relevant, the rows or ordering that differ.
+artifacts:
+  - id: legacy-builder
+    type: spec
+    label: legacy db.findAll query builder — options and semantics
+    content: |
+      // orm/legacy.ts — the findAll builder being retired.
+      // This is the COMPLETE option set findAll accepts; there are no others.
+
+      db.findAll(model, {
+        where?: Record<string, unknown>; // field -> value equality. A value of null generates
+                                         // "field IS NULL". Omitting a field adds no constraint.
+        limit?: number;                  // max rows returned. default: no limit
+        offset?: number;                 // rows skipped before the window. default 0
+        order?: [string, 'ASC' | 'DESC'][]; // e.g. [['createdAt','DESC']]. default []: the
+                                         // database's natural (unspecified) order.
+        include?: string[];              // relations to eager-load. default []
+        paranoid?: boolean;              // default TRUE. When true, findAll AUTOMATICALLY adds
+                                         // "deletedAt IS NULL", i.e. soft-deleted rows are excluded.
+                                         // false -> soft-deleted rows are included.
+      }): Promise<Row[]>
+  - id: new-builder
+    type: spec
+    label: new repo.query builder — options and semantics
+    content: |
+      // orm/repo.ts — the replacement builder. This is the COMPLETE option set for repo.query.
+
+      repo.query({
+        model: Model;
+        filter?: Record<string, unknown>;// field -> value equality. IMPORTANT: a value of null is
+                                         // IGNORED (treated as "no constraint on this field"). To
+                                         // match SQL NULL you must write { field: { is: null } }.
+        take?: number;                   // max rows returned. default: no limit
+        skip?: number;                   // rows skipped before the window. default 0
+        sort?: Record<string, 'asc' | 'desc'>; // directions are LOWERCASE only. An unrecognized
+                                         // value (including 'ASC'/'DESC') is treated as 'asc'.
+                                         // default {}: natural order.
+        with?: string[];                 // relations to eager-load. default []
+        withDeleted?: boolean;           // default FALSE -> soft-deleted rows excluded
+                                         // ("deletedAt IS NULL" added automatically). true ->
+                                         // soft-deleted rows included.
+      }): Promise<Row[]>
+  - id: mapping-note
+    type: note
+    label: intended migration rules (data platform team)
+    content: |
+      How to move a findAll query to repo.query without changing the result set. These rules are
+      exhaustive for the differences between the two builders.
+
+      1. WHERE / FILTER NULLS. `where` and `filter` are the same for non-null values. But
+         where: { f: null } means "f IS NULL", while filter: { f: null } is IGNORED and matches
+         every row. Translate any null in `where` to `filter: { f: { is: null } }`.
+
+      2. PAGINATION. limit -> take, offset -> skip (identical meaning). Keep the numbers with their
+         keys; do not swap take and skip.
+
+      3. SORT. order [['f','DESC']] -> sort { f: 'desc' } (and 'ASC' -> 'asc'). The direction MUST
+         be lowercased: repo.query treats 'DESC'/'ASC' as unrecognized and silently falls back to
+         'asc'. A single order tuple becomes a single sort key.
+
+      4. SOFT DELETE. findAll paranoid: true (the default) == repo.query withDeleted: false (the
+         default): both exclude soft-deleted rows. paranoid: false == withDeleted: true (include
+         soft-deleted). If the original set paranoid: false, the migration MUST set
+         withDeleted: true; omitting it flips soft-deleted rows back out of the result set.
+
+      5. RELATIONS. include -> with (identical). Default [] on both sides; omitting is safe.
+  - id: legacy-queries
+    type: code
+    label: original findAll queries (Q1..Q6)
+    content: |
+      // Q1 — active members of org 5, newest first, page 3 (20 per page), with profile
+      db.findAll(Member, {
+        where: { orgId: 5 },
+        limit: 20,
+        offset: 40,
+        order: [['createdAt', 'DESC']],
+        include: ['profile'],
+      });
+
+      // Q2 — sessions that have NOT been revoked (revokedAt is null)
+      db.findAll(Session, {
+        where: { revokedAt: null },
+      });
+
+      // Q3 — posts newest first
+      db.findAll(Post, {
+        order: [['publishedAt', 'DESC']],
+      });
+
+      // Q4 — audit accounts for owner 9, INCLUDING soft-deleted ones
+      db.findAll(Account, {
+        where: { ownerId: 9 },
+        paranoid: false,
+      });
+
+      // Q5 — tokens for user 3 that never expire (expiresAt is null), including revoked/deleted,
+      //      oldest id first
+      db.findAll(Token, {
+        where: { userId: 3, expiresAt: null },
+        paranoid: false,
+        order: [['id', 'ASC']],
+      });
+
+      // Q6 — a page of logs: 10 rows starting after the first 100
+      db.findAll(Log, {
+        limit: 10,
+        offset: 100,
+      });
+  - id: proposed-queries
+    type: code
+    label: proposed repo.query rewrites (Q1..Q6)
+    content: |
+      // Q1
+      repo.query({
+        model: Member,
+        filter: { orgId: 5 },
+        take: 20,
+        skip: 40,
+        sort: { createdAt: 'desc' },
+        with: ['profile'],
+      });
+
+      // Q2
+      repo.query({
+        model: Session,
+        filter: { revokedAt: null },
+      });
+
+      // Q3
+      repo.query({
+        model: Post,
+        sort: { publishedAt: 'DESC' },
+      });
+
+      // Q4
+      repo.query({
+        model: Account,
+        filter: { ownerId: 9 },
+      });
+
+      // Q5
+      repo.query({
+        model: Token,
+        filter: { userId: 3, expiresAt: { is: null } },
+        withDeleted: true,
+        sort: { id: 'asc' },
+      });
+
+      // Q6
+      repo.query({
+        model: Log,
+        take: 100,
+        skip: 10,
+      });
+tags: [api-migration, refactoring, orm, query-builder, behavior-preservation]