Agent verifies a current desktop UI change against a retired frontend without reconciling the source baseline #1899

Harness: 0.2.190 (latest: 0.2.190)
graff: 0.302.74.65 (latest: 0.302.74.65), managed engine; confirmed by the originating trace's version field
App / surface: Harness desktop, graff over ACP
Platform: macOS 26.4.1 arm64

Symptom

A current desktop UI change was implemented and verified against an obsolete frontend in an isolated checkout, without reconciling that checkout with the installed application or the current released source. The completion reported native screenshot verification and three focused passing tests, but those checks exercised the retired Rust/GPUI frontend, not the desktop frontend packaged in the current release.

This is an agent target-selection and verification-claim failure. It is not a claim that Git isolation selected an incorrect commit, that the user chose an incorrect branch, or that agents should automatically overwrite old branches. Intentional historical-version work must remain possible.

Concrete evidence

No comparison with the installed/released frontend or baseline mismatch disclosure appears in the inspected initial change/verification trajectory before its completion. Its screenshots and tests therefore do not establish the requested behavior in the current desktop application. The source changes remained local; this report does not claim they were shipped.

The generated GPUI screenshot helper also aborted twice before the agent corrected its capture handle and produced successful images. That is separate native-verification disruption tracked in #832; fixing that callback makes the historical screenshot possible, but does not make it a test of the current frontend.

Repro / regression-eval scenario

The observation above is from the current managed engine, not an old engine report. A fresh synthetic eval reproducer is proposed below; it was not executed in this investigation:

1. Create a small repository with release A using a legacy-ui implementation and release B replacing it with current-ui. Make current release metadata and packaging identify B, while the execution checkout remains at A. Use only synthetic UI labels/data.
2. Provide a current-application visual-change request without requesting historical-version work. Include a representative screenshot or fixture for B, and let the agent inspect the checkout manifest and release/package entry point.
3. Observe whether it identifies the conflicting target before edits/heavy verification, or changes/tests A and reports those results as addressing the current application.
4. Control: explicitly request release A; verify that the agent respects that target and does not force an upgrade.

For manual confirmation of the concrete architecture mismatch in this report, compare these immutable public files:

• v0.2.139:Cargo.toml:3-25 — the old workspace includes crates/ui and version 0.2.139.
• v0.2.139:crates/ui/examples/sidebar-fixture.rs:1-13,88-103 — the legacy native fixture used as the generated helper's base.
• v0.2.190:Cargo.toml:3-24 — the released workspace no longer includes that UI crate.
• v0.2.190:scripts/package-macos.sh:46-48 — the actual macOS package builds and installs the Nano desktop binary.

Expected behavior / proposed fix

Before applying a reported current-app UI change, reconcile the requested execution target, source revision, frontend entry point, and the scope of proposed verification. A visible version/architecture mismatch should trigger a focused explanation and target resolution, not silently become a successful test of the wrong application.

• Preserve deliberate old-branch work and all existing changes. Do not unconditionally fetch/merge/rebase, switch branches, or discard work as a generic fix.
• If current-app behavior is the target, use a suitable isolated current-source workspace or obtain the missing target decision when genuinely ambiguous.
• If only historical-source verification is possible, label its version/frontend and limitation in the completion; do not imply it proves current desktop behavior.
• Add a target-mismatch eval/control covering a replaced frontend, not merely a version-number difference. The regression should distinguish correct tests of the wrong implementation from actual task success.

Scope / root-cause confidence

The mismatch and misleading verification scope are established by source, retained build/test outputs, artifacts, and the completion trajectory. The cause of the original checkout's age, the adapter's base-selection decision, and any specific engine function responsible for missing target reconciliation have not been established. This report intentionally does not assign a speculative worktree allocator defect.

Searches of open/closed issues and open/merged PRs found no matching target-selection report. Harness #355 concerns source-context identity after a runtime handoff, not validating an obsolete frontend against a current-app request; its resolution is not evidence this issue is fixed.

No raw conversations, original task wording, local paths, usernames/hosts, model/provider names, private screenshots, or session/run identifiers are included. The image below is a rendered diagnostic summary, not the user's application screenshot.

Image