ios: fill's synthesized-replacement route lands a corrupted value (traced: 11 chars requested, 7 observed, frozen)

[thymikee]

A fill on the penalized coordinate route committed a value that is neither the requested text nor a prefix of it, and stayed that way. The commit wait caught it — #1995 working as designed — but it turns an expensive lane red on unrelated PRs, which is the #1874 symptom from a third mechanism.

The trace

From the iOS smoke lane of PR #2059 (run 33067586234), a PR that changes one workflow file, one test and vitest.config.ts — nothing reachable from the runner.

Step: agent-device fill id="field-email" ada@example (11 characters).

AGENT_DEVICE_RUNNER_TEXT_ENTRY_ROUTE route=synthesized-first-responder-replacement
[DEBUG-1874] synthesize posted 11 chars status=0 tookMs=1084
[DEBUG-1874] wait start expectedLen=11 route=replacement
[DEBUG-1874] poll t=1102ms observedLen=7 expectedPrefixLen=1
[DEBUG-1874] poll t=2395ms observedLen=7 expectedPrefixLen=1
[DEBUG-1874] poll t=3717ms observedLen=7 expectedPrefixLen=1
[DEBUG-1874] poll t=5097ms observedLen=7 expectedPrefixLen=1
[DEBUG-1874] wait outcome=notObserved elapsedMs=6293 route=replacement

Read it as: the field settled at 7 characters sharing exactly one character with ada@example, and never moved again. Four polls over ~4 s at a stable length. status=0 — the synthesize call reported success.

This is the dropped-middle-character family already documented in awaitSynthesizedReplacementCommitOutcome ("ada@example" -> "aexample", "Ada Lovelace" -> "Avelace"), reproduced in CI with a trace attached.

What it is not

• Not a throttle. expectedPrefixLen is flat at 1 for the whole wait. A throttled burst walks the prefix upward; this one never progressed after the first observation.
• Not the fix(ios): grant the text-entry commit wait time against progress #2035 deadline. The wait behaved correctly: progress at the first poll only, then condemned 3 s later (the 6293 ms total includes the ~1.1 s placeholder read that precedes the poll loop).
• Not the placeholder collision fixed in fix(ios): grant the text-entry commit wait time against progress #2035. field-email's placeholder is now Type your email; the filled value shares nothing with it.
• Not the failing PR's doing. ci(1874): declare the diagnose lane and stop it misreading its own loop #2059 touches CI configuration only.

Why it is worth its own issue

#1874 tracks "why does the input pipeline throttle". This is a different defect with a different signature: the characters are not late, they are wrong, and the value is stable. Grouping them would put two mechanisms behind one needs-info.

The immediately useful next step is to learn what the 7 characters actually were. The cadence log is value-free by design (#1924), so the corrupted string is not in any artifact — a one-off local reproduction on the penalized route, or a temporary opt-in that logs the observed value under a test-only flag, would say whether the loss is leading, middle or trailing, which points at RunnerSynthesizedTextEntry.replaceText's select-all-then-type sequence versus the per-character pacing above it.

Related: #1995 (the verification that caught this), #1924 (honest reporting), #1874 (same symptom, different mechanism).

---

Generated by Claude Code

[thymikee]

Triage: valid and ready for an evidence-first agent pass.

Acceptance for the next slice:

• reproduce the synthesized-first-responder-replacement route on the smallest practical local iOS target;
• capture the exact stable observed value through narrowly scoped test-only instrumentation (do not broaden production value logging);
• identify the earliest stage where the requested 11 characters diverge and classify the loss as leading, middle, or trailing;
• preserve the existing commit-wait behavior and add a focused regression only after the responsible boundary is isolated.

Treat this as diagnosis, not authorization for a speculative fallback or pacing change.

[thymikee]

The obvious fix is unsafe — recording why, so the next attempt does not rediscover it

I tried a single idempotent re-post of the replacement (#2086) and closed it after review. The reasoning that killed it is worth having here.

.notObserved is a collapsed outcome. awaitSynthesizedReplacementCommitOutcome returns it for four different situations:

1. a placeholder collision — returned before any polling, where the field may hold exactly the right text;
2. observe() reading nil throughout, i.e. nothing resolving at the refresh point;
3. a stable wrong value — this issue;
4. nothing ever arriving.

Any retry keyed on .notObserved fires on all four.

And this route has no bound target. synthesized-first-responder-replacement synthesizes to the global first responder; it never resolves an XCUIElement — that is precisely the condition shouldUseSynthesizedFirstResponderReplacement gates on (hasResolvedElement == false). A retry re-posts after a wait of up to 10 s, by which time focus may have moved. Select-all-and-write would then mutate a control the command never targeted — a worse failure than the one being avoided.

So a safe retry needs three things this issue does not have yet:

• a typed outcome that distinguishes a stable corrupted value from the other three cases;
• re-establishment of the same target before re-posting, not an assumption that focus held;
• coverage that plants both halves red: a wrong stable first value followed by the exact second value, and a changed/lost focus refusing the retry.

All of which should follow the reproduction this issue asks for, not precede it. A retry cannot be justified without knowing whether the loss is deterministic under load — if it is, it fails twice and doubles the time.

The diagnosis still needed is unchanged and is the first thing to do: learn what the 7 characters actually were. The cadence log is value-free by design (#1924), so a local reproduction on the penalized route, or a test-only opt-in that logs the observed value, is what would say whether the loss is leading, middle or trailing — and that points at RunnerSynthesizedTextEntry.replaceText's select-all-then-type sequence versus the per-character pacing above it.

Note also that replaceText posts the select-all record and the text record back to back, and synthesizeWithError returns at post time. If the app has not applied the selection before the characters begin arriving, that is a candidate mechanism for a value that is neither the old nor the new text — worth ruling in or out first, since it would be a real fix rather than a retry.

---

Generated by Claude Code

[thymikee]

Triage rechecked after the #2086 retry analysis. This remains ready-for-agent only for the existing diagnosis slice: reproduce the synthesized replacement route, capture the exact stable corrupted value through test-only instrumentation, and isolate the first divergence boundary. The newer note narrows the work and is not a blocker, but it explicitly forbids a retry, pacing change, fallback, or production value logging until the mechanism is proven and target identity can be re-established safely.