SQLFluff’s DuckDB MAP literal: agent PR, recognized review gap, next-day human fix

Question. Can a public, original issue show who owns acceptance and repair after an agent-produced change? This is one bug fix with two PRs, not a multi-feature project or a proof of ROI. Read the original issue #7272, Copilot PR #7564, human follow-up PR #7606, and 4.1.0 release (all primary repository records; accessed September 29, 2026).

What the record shows, in order. On November 12, 2025, a user reported that SQLFluff misparsed DuckDB MAP literals, preventing correct parsing of operators including IN; the issue supplied examples and expected all map construction syntaxes to parse. On March 2, 2026, maintainer peterbud dispatched GitHub Copilot; its issue-linked PR implemented a MAP-literal grammar with fixtures, and peterbud marked the draft ready for review. That day Greptile’s review explicitly asked whether trailing commas should also work, pointing to the existing array grammar; its summary still rated the original PR 4/5 and safe with that caveat. Human reviewer keraion agreed March 10 that the missing trailing-comma option should be included. Yet peterbud and alanmcruickshank approved the first PR and alanmcruickshank merged it March 12 with 49 checks passed. On March 13 keraion opened a small human-authored follow-up to support and test trailing commas; peterbud acknowledged missing it in the original PR, approved and merged that follow-up with 50 checks passed. Both PRs appear in the project’s March 26, 2026 4.1.0 release notes. The first fix reached the main branch one day before the correction; the record does not show an interim package release or a production incident caused by this gap.

Decision junction. A review agent spotted a concrete semantic edge case; a human accepted it; then the team merged the base PR and explicitly repaired the edge case in another PR before release. This is evidence of a review finding not made merge-blocking, not that the finding went unnoticed. Passing tests and code coverage measure tested cases, not completeness against DuckDB’s language; DuckDB documents permissive trailing commas. Distinguish the initial merge, the second repair PR, and shipped behavior: counting only first PR as ‘done’ misses human review and follow-up work, while labeling this a post-release agent regression would be false. The original reporter’s later confirmation, actual use or value, agent spend and active human work time are not public in these records.

Next questions. Was the review finding deliberately deferred so both changes could ship together, or was it lost across approvals? We lack a recorded reason. What fraction of accepted non-blocking review findings are merged before resolution, and what review time and later correction costs do they incur? Could the issue-to-PR packet carry a ‘known edge-case follow-up’ that remains visible at release? Connect to the trace bar, review autonomy, maintained-change accounting and comparative follow-up fixes.