Can the same software request be traced through agent action to requester-confirmed closure?

Brief and result, October 1, 2026. After Dru opened a learning-study summary, but did not speak, followed the programme’s original trace gap rather than post another adoption count. Good evidence would join one incoming request to agent implementation/answer, human judgment and action rights, release, requester confirmation or reopening and the time spent in handoff. A merge or ‘Done’ cannot stand in for customer closure. See bounded closure and feature trace.

What was already known. Linear says merging reopens Intercom customer requests for human CX contact; Klaviyo says a customer fix shipped in three days without showing customer confirmation; SQLFluff has a public user report, agent PR, human pre-release repair and release but no requester post-release check.

Four tested subquestions / searches. (1) Public issue → coding-agent PR → release with requester confirmation or reopening? A query combining Copilot, fixed, thanks and release surfaced false positives about bugs in Copilot, not an original customer-to-agent PR chain. None meeting the whole bar in this pass. (2) First-person support/engineering account of same complaint-to-code-to-follow-up? Linear’s account is a composite of workflows. Bitmovin’s named support-side builder describes a shipped, bounded-support agent and one Cursor-produced customer-bug reproduction, but not a public request whose own resolution is traceable. (3) Ownership, human minutes, wrong closes and reversals? Linear’s April/May changelogs encode distinct duplicate and canonical issue states so a duplicate no longer triggers premature Intercom follow-up while the original keeps all customer request links. Bitmovin describes human handoff after triage. Neither quantifies human minutes, incorrect closures or customer acceptance. (4) Same-product falsified closure with subsequent maintenance? GitHub’s gh-aw investigator detects repeated internal workflow failures after its maintenance ticket was marked ‘not planned’ and reports reopens. One of six alleged same-signature runs in an August 6 pass was log-confirmed, five presumed; the issue is again marked closed as not planned. It is an original agent-monitoring trace, not a customer issue or proven repair.

Short primary-source list. Linear first-person April 10 workflow, April 23 duplicate fix, May 21 canonical-link changelog; Bitmovin May 8 first-person account; gh-aw original issue and six-hour failure report. These are different products and tasks; never stitch them into one customer story.

Stop / next trigger. Do not keep collecting closure announcements. Return on publication of original ticket/PR/release/user-reply identifiers, a maintenance review of an authorized agent’s production support system, or stratified cohort data that include silence versus customer confirmation, reopens, human minutes and repair owner. Internal workflow reopens do show why a status transition is a weak endpoint, not what percentage of customer needs went unresolved.