From agent-built change to field acceptance and recovery

October 16 research question. What carries a proposed, model-assisted change from a correct-looking plan, green checks and reviewer findings through a named human release decision to observed field behavior, a recovery path and later value? A full answer would track one request with versioned decisions, test oracle provenance, proposed and rejected patches, owner disposition, real-world trial, deployment/rollback scope, active human minutes and later issue returns. Our shared plan reaches dependency integration, not deployment; SQLFluff has a pre-release fix to an agreed warning without explicit pre-merge defer ownership; Jain’s harness provides held-out behavioral checks for one greenfield service without real-user acceptance.

Four subquestions and primary-source list. (1) How can the environment contradict the software oracle? Singh’s firsthand 800,000-sensor modernization separates physical sensor tests from store-scale emulation and designs staged OTA firmware updates with recovery. AI helped exploration and tooling, but production firmware is not traced to an agent; this is a comparator, not coding-agent productivity evidence. (2) Where does a real model-assisted finding go? Google’s September engineering account locates scanning before code submission, structural triage, a model-proposed fix in the original PR for human review, and an overnight multi-change scan. No public fixed cohort or released-patch ledger. (3) What is a real agent-built field disposition? Read the top and dated history of FastyBird #1032 again: September 9 owner reversed a hardware-first development blocker while retaining a hardware release gate; September 10 poll-overlap failed, and after further repair an October 3 ordinary switch test yielded owner acceptance with broad planned client trials explicitly retired unperformed. The team did not call a staging pass a release pass. (4) What can a release control enforce? GitHub’s current review-deployments documentation permits distinct approve/reject environment jobs and optionally bars self-approval; a configured policy may permit bypass, so approval alone does not establish a tested behavior. The UK pilot separates agent/scanner findings, human verification and remediation but reports no complete per-patch deployment record. These first-party accounts disagree in scope, not in their denominators: hardware operators need physical oracle and rollback, security operators want low-latency pre-submit triage, GitHub documents mechanism rather than its adoption. No second real operator trace found with public plan reversal, independent field use and later request closure in one series; generic searches stopped.

Result and residual problem. A useful packet would bind an intent revision and its approving person to the reviewed patch, each accepted or retired warning, a behavior test outside the builder’s fixture, the exact deployed artifact, rollout/recovery choice and a dated operator/requester observation. But it can create overhead and false certainty when evidence is partial. FastyBird exposes both merits and cost: its owner narrowed the release scope after many ledger entries, and neither that closure nor Google’s fast triage gives 30-day customer outcomes or full human hours. A platform deployment approval can hold an artifact, not prove its oracle correct. Next compare a real team’s submitted warning against a deployed build and subsequent customer incident in one cohort, measure work spent keeping the packet current, and watch for a reopened FastyBird issue rather than treating closure as permanent.

Feed decision: Google is a possible short weekday technical post, but four existing unread posts include a fresh planning coffee read; hold. Singh is a longer weekend comparator only if the physical-oracle thread opens. No replacement generic proof-of-scale item earns a feed slot on October 16.