ios: bring the t3/ios-mvf UI test flake fixes to beta

[AidenJohnston]

Beta carries the same full-flow harness as t3/ios-mvf, so it has the same intermittent UI test failures. This brings the three t3/ios-mvf fixes for them to beta. Beta is 298 commits ahead of t3/ios-mvf, so this is a separate branch rather than a merge. #165 explains each failure in full.

Commits

• f45fef0, cherry-picked from 397b6d6: a solid fill on the instruction card's reply button. Beta's reply capsule is still 14% white over the camera behind the card. The audit failed it on gapRequest-followUp-AX5: Contrast failed (id 'action.skipGap' label 'I can't get there') in runs 36299913974 (codex/beta-qa-next) and 36276179058, and on the walk's "Can't get there". The solid colour (#2D333F) is what the translucent one looked like over ink, and chalk text on it is about 11:1 whatever is behind the card. This is a real contrast fix in the app, not a test change.
• 3011831, cherry-picked from ad942d8 (ios tests: audit the walk strictly once held and in motion to report; triage of the UI test failures #165): audit the walk once the autopilot holds it. The full-flow tests audited the walk while the autopilot was still marking, ending and tilting up over a playing replay. Each audit pass caught a different crossfade, and transient issues from two passes matched on a label or on the "no element" key. The app now leaves <phase>.held in the gate folder while it waits on a gate, and the walk is audited once that file appears. README conflict resolved by keeping beta's text and adding the .held sentence to the -autopilotGate row. 9fc6019 (from ee8cdcc) corrects the comment on what the held walk shows.
• 029050e, cherry-picked from Sam's 4461f13: the held-back gap the Can't-get-there flow asks for, and the replay's upper walk. testCantGetThereEndsWhereThePhoneIs sometimes went from the review straight to the upload, because the held-back window's gap wasn't one that flow asks for, and failed on screen.gapRequest never appeared (run 36310614834 on t3/practice-meter, and five runs on t3/ios-mvf). It cherry-picked cleanly; XcodeGen 2.46.0 regenerates the committed project unchanged. If beta would rather take it with the next merge of t3/ios-mvf, drop this commit.

Still red on beta, not touched here

• testPracticeMeterFromReplay: "the reader never offered the sample meter's number" on the Mac mini, "action.startOver" not found in CI. This is Sam's practice-meter work, as ios: make beta green: aim legend layout and review-flow test waits #155 says.
• onboarding-practice: Dynamic Type font sizes are partially unsupported ... 'Practice meter on' in the every-state audit. codex/beta-qa-practice-label-20260927 works on it.

Testing

On the Mac mini (Xcode 26.6, iPhone 17 on iOS 26.5, the workflow's flags):

• swift test of HouseScanKit with HOUSESCAN_REQUIRE_UPSTREAM=1 and warnings as errors: passes. The XcodeGen drift check: no change.
• FullFlowUITests, 3 iterations: every test passes every time (testCantGetThereEndsWhereThePhoneIs, testFullFlowFromLidarReplay, testFullFlowFromReplay, testLiveFogWalkScreenshots, testSomethingThereChecksTheWallAgain), except testPracticeMeterFromReplay, as above.
• ScreenStatesUITests with the every-state audit: every test passes. The audit's one finding is onboarding-practice ... 'Practice meter on', listed above; gapRequest-followUp-AX5 and the other reply buttons pass with the solid fill.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Repo admins can enable using credits for code reviews in their settings.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 01c5a45b-4bba-4a93-ad45-668aced2605d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[codemetrics-ai]

Note

Review skipped

Codemetrics is installed on this repository, but it hasn't been added to your team yet.

To enable AI code reviews for this repo, go to your dashboard and add house-scanning-master to your team's repositories.

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Adds test fixture frames and adjusts replay logic for UI test stability.

The PR should not merge until walked-end planning matches the ends the app can actually set; the gate timeout margin also warrants attention.

Findings

1.  Planned ends can differ ▶
2.  Held gate may expire ▶

Fix with agent prompt

### Issue 1
ios/HouseScanKit/Sources/HouseScanKit/Replay/ReplayPlanning.swift:237-239
With `-autopilotCantGetThere`, this code plans each end at the farthest position of any retained frame. The actual walk uses `WalkedEnd.choose`, which can place an end closer when that frame has limited tracking, is too far from the wall, or is more than 2 m past the kept-view evidence. In those cases, the held-back frames are chosen to close a gap the app may not request; it can ask for a different gap or none at all.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

### Issue 2
ios/HouseScanUITests/FullFlowUITests.swift:380-384
After finding `wallWalk.held`, the test still takes a screenshot, runs a multipass audit, and performs its `beforeLeaving` check. The app stops waiting 120 seconds after writing the marker, while the “Can’t get there” wall-tape check alone can wait 90 seconds. If those checks run slowly in CI, the autopilot can leave `wallWalk` before the test finishes, making the settled-screen audit unreliable. The gate timeout should cover the work performed after the marker appears.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR adds a solid instruction-card reply fill, holds the walk for a settled accessibility audit, and extends synthetic replays and held-back planning to exercise the “Can’t get there” and upper-wall flows.

• The walked-end planner can disagree with the ends the app actually sets on some replay inputs.
• The held-screen test barrier has a narrow timeout margin after the marker appears.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Load replay] --> B[Plan held-back walk frames]
  B --> C[Play walk without held-back window]
  C --> D[Set ends and play tilt-up run]
  D --> E[Write wallWalk.held]
  E --> F[UI test screenshots and audits]
  F --> G[Write wallWalk gate file]
  G --> H[Finish walk and handle gaps]

Loading

_{Reviews (1) · Last reviewed commit: "Replay: an upper walk that sees the wall..."}

[greptile-apps]

Planned ends can differ

With -autopilotCantGetThere, this code plans each end at the farthest position of any retained frame. The actual walk uses WalkedEnd.choose, which can place an end closer when that frame has limited tracking, is too far from the wall, or is more than 2 m past the kept-view evidence. In those cases, the held-back frames are chosen to close a gap the app may not request; it can ask for a different gap or none at all.

Prompt To Fix With AI

This is a comment left during a code review.
Path: ios/HouseScanKit/Sources/HouseScanKit/Replay/ReplayPlanning.swift
Line: 237-239

Comment:
**Planned ends can differ**

With `-autopilotCantGetThere`, this code plans each end at the farthest position of any retained frame. The actual walk uses `WalkedEnd.choose`, which can place an end closer when that frame has limited tracking, is too far from the wall, or is more than 2 m past the kept-view evidence. In those cases, the held-back frames are chosen to close a gap the app may not request; it can ask for a different gap or none at all.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[AidenJohnston]

This is Sam's code from 4461f13 on t3/ios-mvf; this PR only cherry-picked it, so I'm leaving the fix to him. The point stands as far as I can tell: .walked plans each end at the farthest retained frame, and WalkedEnd.choose can stop short of it. On the synthetic fixture the planned gap was asked for in all 10 of 10 Mac mini runs of testCantGetThereEndsWhereThePhoneIs, so it doesn't bite there. It would on a replay whose farthest frame has limited tracking or stands far from the wall.

[greptile-apps]

That makes sense, and the synthetic fixture result explains why this cherry-pick is reliably green. The concern is still valid for other replays: .walked models the ends as the extrema of retained phone positions, while WalkedEnd.choose can clamp an end based on tracking, wall distance, or the 2 m evidence limit. That can make the planned gap differ from the one the app requests. Since this PR intentionally only cherry-picks the fix and the correction belongs to Sam’s 4461f13 work, I’m leaving it as a follow-up rather than treating it as a regression introduced here.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.

[greptile-apps]

Held gate may expire

After finding wallWalk.held, the test still takes a screenshot, runs a multipass audit, and performs its beforeLeaving check. The app stops waiting 120 seconds after writing the marker, while the “Can’t get there” wall-tape check alone can wait 90 seconds. If those checks run slowly in CI, the autopilot can leave wallWalk before the test finishes, making the settled-screen audit unreliable. The gate timeout should cover the work performed after the marker appears.

Prompt To Fix With AI

This is a comment left during a code review.
Path: ios/HouseScanUITests/FullFlowUITests.swift
Line: 380-384

Comment:
**Held gate may expire**

After finding `wallWalk.held`, the test still takes a screenshot, runs a multipass audit, and performs its `beforeLeaving` check. The app stops waiting 120 seconds after writing the marker, while the “Can’t get there” wall-tape check alone can wait 90 seconds. If those checks run slowly in CI, the autopilot can leave `wallWalk` before the test finishes, making the settled-screen audit unreliable. The gate timeout should cover the work performed after the marker appears.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[AidenJohnston]

Valid. The test does its audit and map check only after .held appears, and the Can't-get-there map check can wait up to 90 s, so a slow runner could have used up the two-minute gate. c3aeabe raises the gate to four minutes. It's in #172 (beta) and #165 (t3/ios-mvf, as 4925f37). In practice the map check returns at once, because both ends are already set when the walk is held.