Source
RedTeam gate on PR #185 (issue #76), 2026-06-25 — GO with one MED + one LOW finding.
MED — the chunk-audit guard is file-granular; the docs oversell it
tests/lib/chunk-audit.test.ts exempts an entire file from the input-scaled-placeholder check if that file contains any chunked( call. So a NEW un-chunked IN (... ids.map(() => '?') ...) added to a file that already routes some other query through chunked() (e.g. memory.ts, dump.ts, aging.ts, dedup.ts — the exact bulk-SQL files most likely to grow a sibling bulk-IN) is not caught.
- Reproduced: planting an un-chunked
DELETE … IN (…) in memory.ts (which already calls chunked()) → guard PASSES (false negative). Planting it in a fresh file with no chunked( → guard correctly FAILS.
- The
AGENTS.md Key-Conventions entry and the chunk.ts audit note state the guard "fails when a new input-scaled placeholder list appears outside the allowlist" — accurate wording is "…appears in a file that doesn't already route through chunked()."
Fix options
- Tighten the guard to per-statement/per-line granularity (strip lines already on a
chunked( call, scan the remainder), or
- Cheaper + honest: soften the
AGENTS.md + audit-note wording to state the file-granular limitation explicitly.
LOW — no >cap integration test for the bumpAccess chunking
bump-access.test.ts exercises only small sets (limit 2/10); the >500-id multi-chunk path bumpAccess now takes has no direct assertion. Correctness composes from chunked()'s own property tests, so this is a coverage nicety, not a defect — add a >cap case asserting all ids are bumped across chunk boundaries within the single transaction.
risk:low — guard-coverage + docs accuracy; the shipped bumpAccess fix itself is correct (verified in-transaction, all-or-nothing).
Source
RedTeam gate on PR #185 (issue #76), 2026-06-25 — GO with one MED + one LOW finding.
MED — the chunk-audit guard is file-granular; the docs oversell it
tests/lib/chunk-audit.test.tsexempts an entire file from the input-scaled-placeholder check if that file contains anychunked(call. So a NEW un-chunkedIN (... ids.map(() => '?') ...)added to a file that already routes some other query throughchunked()(e.g.memory.ts,dump.ts,aging.ts,dedup.ts— the exact bulk-SQL files most likely to grow a sibling bulk-IN) is not caught.DELETE … IN (…)inmemory.ts(which already callschunked()) → guard PASSES (false negative). Planting it in a fresh file with nochunked(→ guard correctly FAILS.AGENTS.mdKey-Conventions entry and thechunk.tsaudit note state the guard "fails when a new input-scaled placeholder list appears outside the allowlist" — accurate wording is "…appears in a file that doesn't already route throughchunked()."Fix options
chunked(call, scan the remainder), orAGENTS.md+ audit-note wording to state the file-granular limitation explicitly.LOW — no >cap integration test for the bumpAccess chunking
bump-access.test.tsexercises only small sets (limit 2/10); the >500-id multi-chunk path bumpAccess now takes has no direct assertion. Correctness composes fromchunked()'s own property tests, so this is a coverage nicety, not a defect — add a >cap case asserting all ids are bumped across chunk boundaries within the single transaction.risk:low — guard-coverage + docs accuracy; the shipped bumpAccess fix itself is correct (verified in-transaction, all-or-nothing).