build(deps): bump modernc.org/sqlite from 1.52.0 to 1.53.0

[dependabot]

Bumps modernc.org/sqlite from 1.52.0 to 1.53.0.

Changelog

Sourced from modernc.org/sqlite's changelog.

Changelog

• 2026-06-25 v1.54.0:

  • Under the opt-in _texttotime DSN parameter, best-effort parse date-shaped TEXT values from columns SQLite reports with an empty declared type — aggregates and expressions over a date column (MAX(d), COALESCE(d, ...), upper(d), d || ''), subqueries, and typeless real columns (CREATE TABLE t(x)) — into time.Time, instead of delivering them as a raw string that Scan cannot store into a *time.Time. The existing declared DATE/DATETIME/TIME/TIMESTAMP path is unchanged; this only adds the empty-decltype case. The conversion is strictly best-effort: a value that does not parse as a time falls through to the original string, so no Scan that worked before can newly fail. ColumnTypeScanType continues to report string for empty-decltype columns, since the declared type cannot prove the column is temporal. Without _texttotime the behavior is byte-for-byte unchanged. Resolves [GitLab issue #248](https://gitlab.com/cznic/sqlite/-/issues/248).
  • See [GitLab merge request #133](https://gitlab.com/cznic/sqlite/-/merge_requests/133), thanks Ian Chechin!

• 2026-06-21 v1.53.0:

  • Add experimental netbsd/amd64 support, resolving the long-standing build break in [GitLab issue #246](https://gitlab.com/cznic/sqlite/-/issues/246). This target is intentionally not yet listed among the supported platforms in the package documentation: the port had been broken for years and is only now revived, and there is as yet no real-world experience running it under production workloads. Green CI is not the same as battle-tested — so while the full test suite (including the pcache and vec packages and the -race concurrency test) passes on NetBSD 10.1 / Go 1.26.3, and the entire upstream toolchain (libc, cc, ccgo, libz, libtcl8.6, libsqlite3, libsqlite_vec) is green on the NetBSD CI builder, the target is offered for evaluation only. If you run NetBSD, please exercise it with your own workloads and report back via #246; the intent is to promote it to a fully supported platform after a period of broader real-world testing (on the order of a month) elapses without surprises.
  • Implementation notes: the previously shipped lib/sqlite_netbsd_amd64.go was a stale old-generator transpile that no longer compiled (the mu.enter/mu.leave break in #246); it is replaced by a fresh new-generator transpile consistent with every other platform, and modernc.org/sqlite/vec (sqlite-vec) is vendored and auto-registers on netbsd. Correct operation requires the matching pinned modernc.org/libc, which carries two NetBSD-specific fixes found during this work: the mmap(2) PAD-argument ABI (without it, concurrent WAL access faults with SIGBUS in the WAL-index shared memory) and a working abort(3) (the prior stub left SQLite's crash-recovery writecrash test unable to terminate by signal). As usual, downstream modules must pin the exact modernc.org/libc version this module's go.mod pins.
  • See [GitLab merge request #82](https://gitlab.com/cznic/sqlite/-/merge_requests/82), thanks Leonardo Taccari (@​iamleot) and Thomas Klausner (@wiz)!
  • Add experimental freebsd/386 and freebsd/arm support. As with the netbsd/amd64 target above, these two 32-bit FreeBSD ports are intentionally not yet listed among the supported platforms in the package documentation: freebsd/386 previously shipped a stale, effectively untested SQLite 3.41 transpile, and freebsd/arm is entirely new, so neither has real-world production mileage yet. Both are now freshly transpiled at SQLite 3.53.2 consistent with every other platform, build cleanly, and pass the full test suite (core, WAL/concurrency, and the vec package) on the FreeBSD CI builders; they are offered for evaluation only. If you run 32-bit FreeBSD, please exercise these targets with your own workloads and report back — the intent is to promote freebsd/386, freebsd/arm, and netbsd/amd64 to fully supported platforms in a future release cycle, once a period of broader real-world testing elapses without surprises.
  • Implementation notes: correct operation on freebsd/arm requires the matching pinned modernc.org/libc (v1.73.4), which fixes the per-arch mmap(2) off_t encoding for 32-bit FreeBSD; without it the WAL shared-memory mapping faults with SIGBUS under concurrent access, the same class of bug found on the netbsd port. As usual, downstream modules must pin the exact modernc.org/libc version this module's go.mod pins.
  • See [GitLab merge request #119](https://gitlab.com/cznic/sqlite/-/merge_requests/119), thanks Olivier Cochard-Labbé (@​ocochard)!
  • Add a Go-facing wrapper for SQLITE_CONFIG_PCACHE2. PageCache is the factory and Cache the per-database instance, both idiomatic Go interfaces; Page exposes the raw Buf and Extra pointers that SQLite reads through the C pcache contract. RegisterPageCache and MustRegisterPageCache install the module process-globally before the first sql.Open; subsequent Open calls are gated through a one-shot Xsqlite3_config(SQLITE_CONFIG_PCACHE2) so a too-late Register returns ErrPageCacheTooLate rather than silently falling through to the built-in pcache1. The binding owns the sqlite3_pcache_page stub and re-consults the implementation on every Fetch, reusing the stub only when the returned Page value is unchanged, which keeps a bounded/evicting purgeable cache safe by construction.
  • See [GitLab merge request #126](https://gitlab.com/cznic/sqlite/-/merge_requests/126), thanks Ian Chechin!
  • Add modernc.org/sqlite/pcache, the reference page-cache implementation that accompanies the #126 SQLITE_CONFIG_PCACHE2 wrapper. pcache.New returns a *Pool satisfying the PageCache interface; register it once with sqlite.MustRegisterPageCache(pcache.New()) and every connection opened afterwards draws its pages from it. Each Pool.Create mints a fresh per-database Cache: a bounded, LRU-evicting page store that honours the PRAGMA cache_size soft cap and releases the least-recently-unpinned page when it must make room. Page memory — the Buf and Extra buffers SQLite reads through — is allocated with libc.Xmalloc/libc.Xcalloc and therefore lives off the Go heap, which keeps SQLite's interior pointer arithmetic on the page extras from tripping the race detector's checkptr enforcement. Pool.Stats reports aggregate lifetime counters (hits, misses, allocs, evictions, rekeys, truncates, caches) across every cache a Pool has created, so hit/miss/eviction behaviour is observable without instrumenting individual caches. Cross-connection page sharing is out of scope for now; each Create returns an independent per-database cache.
  • Validated end-to-end against the #126 stress workload (cache_size=16, 4000 BLOB rows with DELETE and incremental_vacuum, integrity_check clean under -race) and benchmarked for the memory-utilization goal tracked in [GitLab issue #204](https://gitlab.com/cznic/sqlite/-/issues/204).
  • See [GitLab merge request #127](https://gitlab.com/cznic/sqlite/-/merge_requests/127), thanks Ian Chechin!
  • Tighten the modernc.org/sqlite/pcache reference implementation per cznic's !127 review follow-ups. Adds Stats.EasyRefusals, a per-Pool counter for the cases where FetchCreateEasy returns nil at cap; SQLite reacts to a refusal by spilling dirty pages and retrying with FetchCreateForce, so the new field is a direct proxy for the I/O pressure the strict Easy contract imposes vs pcache1's recycle-without-spill behavior. BenchmarkPoolEvictionChurn was reworked to drive a rotating-residue DELETE (k % 3 = i % 3) and re-insert a matching batch each cycle so the spill pressure recurs and easy-refusals/op scales with b.N instead of capping at the seed's one-time first-cycle cost; both existing benchmarks now report easy-refusals/op alongside the page-allocs/evictions metrics. Stats.Evictions documentation was tightened to match the actual behavior (counts LRU eviction, Unpin(discard=true), Shrink releases, and Unpin(discard=false) trimming back to target after a FetchCreateForce overcommit; bulk frees from Truncate, Rekey collisions, and Destroy are not counted). The TestPoolRoundTripIntegrity comment claiming the workload exercises xRekey ~15 times has been corrected; the SQL surface does not reliably emit xRekey here, and that codepath is covered by the unit tests instead.
  • See [GitLab merge request #130](https://gitlab.com/cznic/sqlite/-/merge_requests/130), thanks Ian Chechin!
  • Make modernc.org/sqlite/pcache -race-clean under SQLite's cache=shared mode. The pool already runs correctly under shared-cache because every callback into a given Cache is serialised internally by SQLite's sqlite3BtreeEnter on the BtShared mutex; verified empirically with a lock-free in-flight probe (max-in-flight = 1 on the canonical two-connection workload, 4 on a positive control with goroutines hitting the cache directly). However the Go race detector does not recognise SQLite's libc mutex as a happens-before edge and reports false-positive races on Fetch vs Unpin reads/writes of the per-cache state, which surfaces as DATA RACE failures for any user who registers the pool and runs their suite under -race. A sync.Mutex on the cache type is now taken on every public method (SetSize, PageCount, Fetch, Unpin, Rekey, Truncate, Destroy, Shrink), always. On the common non-shared-cache path the lock is uncontended (one atomic CAS per Lock/Unlock pair, negligible next to the SQLite work it bookends); on the shared-cache path it just rubber-stamps the order SQLite's BtShared mutex already established. A new e2e_test.go TestSharedCacheTwoConns_Integrity drives two sql.Conn against the same cache=shared URI with concurrent writers and asserts PRAGMA integrity_check = ok under -race; passes cleanly with the lock, would surface the false-positive without it. Design notes live in pcache/sharing.go.
  • See [GitLab merge request #131](https://gitlab.com/cznic/sqlite/-/merge_requests/131), thanks Ian Chechin!
  • Add a Go wrapper for sqlite3_db_status, the per-connection runtime counters (cache hit/miss/write/spill rates, schema and prepared-statement memory, lookaside usage, deferred foreign keys). DBStatus is an interface implemented by the driver connection and reached through the database/sql escape hatch (*sql.Conn).Raw(), mirroring the existing FileControl surface; DBStatusOp is a distinct typed enum of the SQLITE_DBSTATUS_* verbs so a counter from a different op family will not compile in its place. Status(op, reset) returns the (current, high) pair and optionally resets the counter. This also lets modernc.org/sqlite/pcache measure real I/O instead of the EasyRefusals proxy: the new BenchmarkPoolSpillIO reads the pager-level SQLITE_DBSTATUS_CACHE_SPILL/_CACHE_WRITE counters, which the pager maintains identically for pcache1 and the pool, making the pcache1-vs-pool comparison cznic raised on the !127 review a genuine apples-to-apples measurement. On the rotating-residue eviction-churn workload at cache_size=16 the pool spills ~3.5x more than pcache1 (cache-spill/op 31.96 vs 8.96) for ~3% more page writes (cache-write/op 450 vs 436) at identical hit/miss, quantifying the I/O cost of the strict Easy contract that EasyRefusals only proxied.
  • See [GitLab merge request #132](https://gitlab.com/cznic/sqlite/-/merge_requests/132), thanks Ian Chechin!
  • Add an opt-in _dqs DSN query parameter that disables SQLite's double-quoted string literal compatibility quirk on a per-connection basis. When _dqs=0 (or any strconv.ParseBool false value) is supplied, the driver calls sqlite3_db_config with SQLITE_DBCONFIG_DQS_DDL and SQLITE_DBCONFIG_DQS_DML set to off before any statement is prepared, so a double-quoted identifier that fails to resolve raises a parse error instead of silently falling back to a string literal. Absence of the parameter, or _dqs=1, leaves SQLite's default behavior unchanged; existing DSNs continue to work byte-for-byte. Resolves [GitLab issue #61](https://gitlab.com/cznic/sqlite/-/issues/61).
  • See [GitLab merge request #128](https://gitlab.com/cznic/sqlite/-/merge_requests/128), thanks Ian Chechin!
  • Add an opt-in _error_rc DSN query parameter for clearer error reporting on open-time failures. When _error_rc=1 (or any strconv.ParseBool true value) is supplied, error strings synthesised from a (rc, db) pair only append sqlite3_errmsg(db) when sqlite3_extended_errcode(db) is consistent with the operation rc (full match first, primary code &0xff as fallback). On mismatch the canonical sqlite3_errstr(rc) is used alone, so an open-time SQLITE_CANTOPEN no longer carries the temporary handle's stale "out of memory" errmsg. Absence of the parameter, or _error_rc=0, preserves the legacy "errstr: errmsg" form byte-for-byte; existing callers that parse error strings are unaffected. The driver's *Error.Code() returns the same SQLite result code in both modes. Parsed before sqlite3_open_v2 so open-time errors are covered. Resolves [GitLab issue #230](https://gitlab.com/cznic/sqlite/-/issues/230).
  • See [GitLab merge request #129](https://gitlab.com/cznic/sqlite/-/merge_requests/129), thanks Ian Chechin!

• 2026-06-06 v1.52.0:

  • Upgrade to SQLite 3.53.2.
  • Add Backup.Remaining and Backup.PageCount, thin wrappers around the existing sqlite3_backup_remaining and sqlite3_backup_pagecount C symbols. Together they expose the per-Step progress counters that the underlying backup object already maintains, enabling progress reporting during online backups without dropping to modernc.org/sqlite/lib directly.
  • See [GitLab merge request #122](https://gitlab.com/cznic/sqlite/-/merge_requests/122), thanks Ian Chechin!
  • Drop the redundant second copy in (*conn).columnText, the path that backs every Rows.Scan into a Go string for a TEXT column. The value's bytes are still copied once out of SQLite-owned memory into a fresh Go buffer; that buffer is then reinterpreted as the result string with unsafe.String rather than copied a second time by the implicit string([]byte) conversion. This removes one allocation per TEXT value per row and roughly halves the bytes allocated on that path; on the new BenchmarkColumnTextScan cases it is ~13–20% faster for payloads of 256 B and larger, with no measurable change for very short strings. Purely internal: no API or behavioral change, and the returned string never aliases SQLite's buffer.
  • See [GitLab merge request #123](https://gitlab.com/cznic/sqlite/-/merge_requests/123), thanks Ian Chechin!
  • Cache each result column's declared type once per result set in newRows instead of recomputing it on every row. The TEXT branch of Rows.Next calls ColumnTypeDatabaseTypeName for every TEXT column on every row (independent of any DSN flag), which previously did a libc.GoString + strings.ToUpper each time; that lookup is now a single index into a cached, pre-uppercased []string, and ColumnTypeScanType reads the same cache and drops its per-call strings.ToLower. The declared type is fixed for the lifetime of a prepared statement, so the C round-trip is paid once per column rather than once per column per row, removing exactly 1 alloc + 8 B per TEXT column per row from the Next hot path. The new BenchmarkTextToTimeScan cases show ~7% faster on a 1000-row DATETIME SELECT under _texttotime=1. Purely internal: ColumnTypeDatabaseTypeName and ColumnTypeScanType return identical values, no API or behavioral change.
  • See [GitLab merge request #124](https://gitlab.com/cznic/sqlite/-/merge_requests/124), thanks Ian Chechin!
  • Cache, per result column, the parseTimeFormats index that first parsed a TEXT-stored DATE/DATETIME/TIMESTAMP value, and try that format first on later rows instead of re-walking the list from the top. (*conn).parseTime previously ran time.Parse down the format list on every such row; for the canonical SQLite TEXT datetime format every row paid two failed time.Parse attempts — each allocating a *time.ParseError — before the match. On a 1000-row DATETIME TEXT SELECT this cuts ~50% of allocs/op and ~57% of B/op and is ~37% faster. The fall-through chain is preserved exactly: the seven formats are mutually exclusive, so the cached hint can never select a different match than the in-order scan, and the parsed driver.Value is identical to before. Purely internal: no API or behavioral change.
  • See [GitLab merge request #125](https://gitlab.com/cznic/sqlite/-/merge_requests/125), thanks Ian Chechin!

• 2026-05-28 v1.51.0:

  • Pool the []driver.Value slice passed to scalar/aggregate UDF callbacks and to vtab Filter/Insert/Update callbacks, eliminating the dominant per-row allocation on UDF-heavy queries. Benchmarks on a 1000-row, 3-arg noop scalar UDF show ~40% fewer bytes/op and ~15% fewer allocs/op.
  • Document the matching "arguments are not valid past return" contract on vtab.Cursor.Filter and vtab.Updater.Insert/Update, consistent with the existing rule for FunctionImpl.Scalar / AggregateFunction.Step / WindowInverse.
  • Resolves [GitLab issue #226](https://gitlab.com/cznic/sqlite/-/issues/226). See [GitLab merge request #114](https://gitlab.com/cznic/sqlite/-/merge_requests/114), thanks Ian Chechin!
  • Add FileControl.FileControlDataVersion, a wrapper around SQLITE_FCNTL_DATA_VERSION for observing pager-cache data-version changes, including those made on the same connection. Useful as a primitive for application-level cache invalidation.
  • Exposed via the idiomatic database/sql escape hatch (*sql.Conn).Raw(), consistent with the existing FileControlPersistWAL.
  • See [GitLab merge request #115](https://gitlab.com/cznic/sqlite/-/merge_requests/115), thanks Ian Chechin!
  • Fix a regression where in-memory connections (:memory:, file::memory:, shared-cache memory URIs) were discarded by database/sql after a context-cancelled query, taking the entire in-memory store with them. The fix for #198 had added an sqlite3_is_interrupted check to the connection validator that mistakenly applied to in-memory connections too, re-introducing the bug originally fixed by !74. File-backed connections keep the existing behaviour and are still discarded after an interrupt.
  • Resolves [GitLab issue #196](https://gitlab.com/cznic/sqlite/-/issues/196). See [GitLab merge request #116](https://gitlab.com/cznic/sqlite/-/merge_requests/116), thanks Ian Chechin!
  • Add an opt-in FunctionImpl.VolatileArgs flag that hands TEXT and BLOB arguments to scalar and aggregate UDF callbacks as zero-copy views (unsafe.String/unsafe.Slice) over SQLite's own value buffers, eliminating the per-argument libc.GoString/make([]byte) copy that the #226 slice-pooling left as the remaining per-row allocation. On the same 1000-row, 3-arg (INTEGER/TEXT/BLOB) noop scalar UDF this removes a further ~35% of allocs/op and ~11% of bytes/op on top of #226.

... (truncated)

Commits

• 6b32d1e CHANGELOG.md: document experimental freebsd/386 + freebsd/arm (#119)
• 697300f Merge branch 'dbstatus-binding' into 'master'
• 759639f sqlite: review fixes for !132 — restore #131 CHANGELOG link, correct DBStatus...
• 40ff027 sqlite: add DBStatus wrapper for sqlite3_db_status + pcache spill-I/O benchmark
• 6a28fe7 HACKING.md: document CHANGELOG versioning + MR integration flow
• adff4b1 Merge branch 'pcache-shared-cache-draft' into 'master'
• 14e5790 vendor: regenerate freebsd/arm vec at SQLite 3.53.2
• 8725c22 Add freebsd/386 + freebsd/arm targets
• 73050dc Merge branch 'pcache-pool-polish' into 'master'
• 1897fdd CHANGELOG.md: consolidate untagged v1.53.0/v1.54.0 into one v1.53.0 section
• Additional commits viewable in compare view

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed June 30, 2026, 7:49 PM ET / 23:49 UTC.

Summary
The PR updates the direct Go dependency modernc.org/sqlite from v1.52.0 to v1.53.0 in go.mod and go.sum.

Reproducibility: not applicable. this is a dependency maintenance PR, not a reported bug. Source inspection shows the affected runtime surface is the store's SQLite driver registration and database open/query path.

Review metrics: 3 noteworthy metrics.

• Diff Scope: 2 files changed, 3 additions, 3 deletions. The patch is limited to Go module metadata, so review should focus on dependency compatibility rather than application logic.
• Runtime Dependency: 1 direct production module bumped. modernc.org/sqlite is imported by the store layer, so this is not a dev-only or test-only update.
• Check Rollup: 12 successful, 2 skipped, 0 failed. The inspected rollup shows CI and security checks green after the latest rebase.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🌊 off-meta tidepool
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P2] Optionally run a focused store smoke against fresh and existing databases before merge.

Risk before merge

• [P1] Merging this upgrades the direct SQLite driver behind Graincrawl archive storage, so upstream runtime changes could affect fresh or existing database open, write, query, and snapshot flows even though application code is unchanged.

Maintainer options:

1. Accept Green CI For The Bump (recommended)
   The PR is narrow and the inspected check rollup is green, so maintainers can merge if that coverage is sufficient for this routine SQLite driver update.
2. Run A Store Smoke First
   Before merge, run a quick Graincrawl store or CLI smoke that opens, writes, queries, and snapshots a fresh database and a redacted existing archive with v1.53.0.
3. Wait For A Newer Dependency PR
   If maintainers prefer to skip this incremental bump, leave it open or close it only after a fresh viable replacement PR exists.

Next step before merge

• No automated repair is needed; maintainers should decide whether the green checks are enough for this direct runtime SQLite driver bump or run an additional store smoke.

Security
Cleared: The diff keeps the same module path and only updates Go module version/checksum entries; no scripts, workflows, permissions, or dependency sources are added.

Review details

Best possible solution:

Land the bump after maintainers either accept the green CI coverage for this routine driver update or run a focused store smoke against fresh and existing Graincrawl databases.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a dependency maintenance PR, not a reported bug. Source inspection shows the affected runtime surface is the store's SQLite driver registration and database open/query path.

Is this the best way to solve the issue?

Yes: changing go.mod and go.sum is the narrowest maintainable way to apply this Go module bump. The remaining question is compatibility validation or maintainer risk acceptance, not a different implementation approach.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning high; reviewed against 5d2e6ad412c5.

Label changes

Label justifications:

• P3: This is a small routine dependency maintenance PR with no concrete patch defect found.
• merge-risk: 🚨 compatibility: The PR upgrades the direct SQLite driver backing Graincrawl database access, which can affect existing archive behavior after merge.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This is a Dependabot-authored dependency PR, so the external-contributor real behavior proof gate does not apply; green CI or maintainer store smoke should gate the runtime dependency risk.

Evidence reviewed

What I checked:

• Current main dependency pin: Current main still requires modernc.org/sqlite v1.52.0, so the requested v1.53.0 bump is not already implemented. (go.mod:8, 5d2e6ad412c5)
• Latest release dependency pin: The latest release tag v0.3.1 also contains modernc.org/sqlite v1.52.0, so the bump has not shipped in the latest release. (go.mod:8, 2cc577b8ebf4)
• PR diff scope: The refreshed PR head changes only go.mod and go.sum, replacing the v1.52.0 module/checksum entries with v1.53.0 entries. (go.mod:8, ee445c5d52b6)
• Runtime SQLite surface: The store layer imports modernc.org/sqlite for database/sql registration and opens read-only store queries through the sqlite driver, making this a production runtime dependency bump. (internal/store/query.go:12, 5d2e6ad412c5)
• Store open path: Graincrawl store access opens the archive database through the store layer, so SQLite driver behavior affects normal archive operations. (internal/store/store.go:14, 5d2e6ad412c5)
• Check rollup: GitHub reports the refreshed PR head with deps, lint, test, release-check, CodeQL, Socket, and secret-scanning checks successful, with two release-draft jobs skipped and no failing checks in the rollup inspected. (ee445c5d52b6)

Likely related people:

• vincentkoc: GitHub commit history shows vincentkoc introduced the SQLite dependency and authored the crawlkit-backed store and read-only SQL query paths affected by this driver bump. (role: introduced behavior and store area contributor; confidence: high; commits: 55af3f441170, c8b2352c8a45, 589c604d9726; files: go.mod, go.sum, internal/store/store.go)
• steipete: Recent history shows steipete prepared the v0.3.1 release state, refreshed adjacent dependency metadata, and requested Dependabot rebases on this PR. (role: recent dependency and release contributor; confidence: medium; commits: 2cc577b8ebf4, 423b98145238; files: go.mod, go.sum, CHANGELOG.md)
• openclaw/openclaw-secops: .github/CODEOWNERS assigns go.mod and go.sum to this owner handle, which is directly relevant to a dependency bump. (role: code owner for dependency metadata; confidence: high; files: .github/CODEOWNERS, go.mod, go.sum)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

@dependabot rebase

[steipete]

@dependabot rebase

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	modernc.org/​sqlite@​v1.52.0 ⏵ v1.53.0	+9

View full report

[steipete]

@dependabot rebase