"Can't get there" during the walk can put the wall's end at the meter, and the rest of the walk is dropped

On a real iPhone (TestFlight build 1.1, capture code t3/ios-mvf 657ab28), a walk of about 19 ft along a wall
uploaded with both ends within 4 in of the meter. The exported baseline is 0.66 ft long and coverage.observed
is empty, so the server returned manual_review with no spot. Write-up: PR #23,
experiments/device-field-test/README.md, section "How the walk was lost".

Cause. During .walk / .markEnd, cannotAccessArea() sets that side's end at GuidancePlanner.reach
(ScanEngine+Actions.swift, the .walk(let side, _), .markEnd(let side) case). reach stops at the first 6-inch
cell whose wall and ground bands aren't both covered or skipped. The tilt prompts never asked for the ground
in front of the meter, so reach was 0 on both sides until photo 43 of 44. After that, CoverageMap ignores
everything past the ends, while the walk goes on keeping photos and accepting marks with no warning.

This code is unchanged at the t3/ios-mvf head (35ac3f2).

Repro. Mark the meter, do the close-up, and on "Walk slowly to your left" tap "Can't get there" without tilting
down at the meter. Then walk right and tap it again. You get "That's the whole wall" and a baseline about 0.66 ft long.

Possible fixes (your call):

place the end at the farthest point seen, or at the phone's position along the wall, instead of at reach;
or refuse the tap and say what's missing ("Tilt down to show the ground by your meter");
ask for the ground in front of the meter before the first "Walk slowly to your left";
at least warn when an end would land within a foot of the meter, and don't keep photos and marks past an end
without saying so.

Other device findings from the same run (B-16 "Tap the ac unit", "Slow down" while standing still, no battery
mark kind, a tilt-prompt distance going backwards) are in the same README.

@SamGu-NRX

@SamGu-NRX this still reproduces at t3/ios-mvf b837544: GuidancePlanner.swift is unchanged since 35ac3f2, and the commits since then don't touch the "Can't get there" path. Could you take a look?

Separately, TestFlight run 36264474758 (beta ec25f59) is waiting on your testflight environment approval.

Clips from the run 1 screen recording (TestFlight build 1.1). Times are from the full recording.

0:22, left "Can't get there". The tester hadn't walked or tilted down yet. The ground row by the meter is grey, so the left end lands at the meter.

01-left-cant-get-there-sets-end-at-meter.mp4

0:27–0:46, tilt prompts. They ask for the strip 3 ft 3 in, 2 ft 9 in, 4 ft 6 in, 7 ft and 8 ft 9 in right of the meter, never the ground in front of it.

02-tilt-prompts-skip-ground-at-meter.mp4

0:53, right "Can't get there". About 16 ft from the meter. The ground row is amber all the way from the meter. The card switches to "That's the whole wall" and the strip goes blank.

03-right-cant-get-there-whole-wall.mp4

1:23, marks past the end. The AC unit is still listed "About 16 ft right of your meter", past the right end.

08-marks-past-end-still-listed.mp4

1:28–1:44, result. "An installer will take a look", asking to keep walking past ends 0 ft 4 in either side of the meter.

09-upload-and-manual-review-result.mp4

@SamGu-NRX

Design proposal: wall ends (#24, #28, #29, and B-06 / #35)

@SamGu-NRX, these four overlap, so here is one proposal for all of them, read at t3/ios-mvf 49a676e. No code yet. Each part has a recommended option (A). Could you pick per part, or just say "all A"? I'll then build it as one PR against t3/ios-mvf: one commit per part, with the logic in HouseScanKit (GuidancePlanner / CoverageMap) and unit tests there.

1. Where "Can't get there" puts an end. Today, during .walk / .markEnd it sets an unexplored end at GuidancePlanner.reach (Actions L355-L359). reach is how far coverage runs unbroken (L100-L118), so one gap by the meter puts the end at 0.

A. Put the end at the farther of reach and the phone's position along the wall, capped at the edge of what was seen (seenExtent). It stays unexplored. Gaps left behind aren't lost: once both ends are marked, firstHole asks for them, and "Can't get there" there marks them skipped as today. If the end would still land within 1 ft of the meter, don't set it; say "Walk a few steps to your left first".
B. Refuse the tap while reach is under 1 ft and say what's missing ("Tilt down to show the ground by your meter").
C. Keep reach and only warn (part 4).

2. Ask for the ground at the meter first (#28). laggingBand asks for ground only where the wall is already covered, within 1 m of the phone (L141-L154), so the cells reach starts from are never asked for.

A. In preferredTask (L120-L139), before the first .walk, return .aimAtGround(s: 0) while the ground cells either side of the meter aren't covered or skipped. The existing "Can't get there" skips it, so it can't block the walk.
B. Have laggingBand prefer the run nearest the meter. That also stops the distance going backwards (3 ft 3 in, then 2 ft 9 in), but it still waits for the wall to be covered first.

3. Offer "Wall ends here" before 20 ft (#29, B-06). It shows only in .markEnd, which needs reach ≥ 6.1 m (L28-L31, L133).

A. During .walk(side), once the phone is about 1 m out on that side, also show "Wall ends here" in the empty primary slot next to "Mark something" (the .walking row is a Spacer today, WallWalkScreen L221). It goes through the existing markWallEnd and end question, so only "Something blocks it" makes a limit. Show the same button on the gap screen during a past-end request (Past-end requests: a band request beyond a marked end never fills, and a past_end request drops the end #35).
B. Relax what reach needs (the 6.5 ft wall row, the 4 ft ground row) or lower the 6.1 m. That changes what "covered" means for everything downstream.

4. Warn before photos or marks past an end are dropped. Coverage records nothing past a marked end (CoverageMap L314-L320). The walk still keeps photos and accepts marks there, and says nothing (#24, 1:23 clip).

A. When the phone is more than 0.5 m past a marked end on its side, show a card "You're past the left end you marked" with "Move the end here" (re-marks the end at the phone, then asks the end question) and "Go back". A feature tapped past an end is refused with the same choice. Also, "Done with this wall" asks for confirmation when the wall is under 3 ft end to end.
B. Silently move an unexplored end outward as the phone walks past it; never move a limit. Simpler, but the homeowner never learns where the end is.
C. A one-line banner only, with no action.

With 1A + 2A, run 1's first "Can't get there" would have landed at the tester's position, not at the meter, and the ground prompt would have come before the walk. 3A would have let the tester finish at 16 ft without "Can't get there" at all.

Addressed in 3c7b83a on t3/ios-mvf (merged in 75dea41).

What changed

"Can't get there" while the card says to walk a side now ends that side where the phone is along the wall, capped at the farthest kept photo on that side (new WalkedEnd in HouseScanKit). It no longer uses the unbroken covered reach. If the phone is on the other side of the meter or has lost its place, the end goes to the farthest kept photo on that side, not to the meter.
A new "Wall ends here" button next to "Mark something" during the walk does the same, then asks "It turns a corner / Something blocks it".
The wall strip shows a dashed line where the end would land and dims what's past it. If that cuts off part of the walk, a line under the strip says "Ending the wall here leaves out N ft you walked".
Past an unexplored end, when nothing between the ends is in view, photos aren't kept and the card says "You're past the end of the wall".
The walk's first request is now the ground in front of the meter (Tilt-down prompts never ask for the ground in front of the meter #28).

What's left

Feature marks past an end are still accepted with no warning. The commit keeps them on purpose, because the server puts them on the wall's line past the end.
Nothing stops an end landing at the meter. "Can't get there" or "Wall ends here" on a side you haven't walked puts that end at the meter, and "Wall ends here" is shown from the first prompt after the close-up. "Done with this wall" doesn't ask about a wall only inches long.

To confirm on the first TestFlight build with 3c7b83a
Repeat run 1: mark the meter, do the close-up, and tilt down when asked. On "Walk slowly to your left", tap "Can't get there" (the left end at the meter is expected here, since you didn't walk left). Walk about 15 ft right, check the dashed line on the strip is under you, and tap "Can't get there". The right end should land about 15 ft out, not 4 in from the meter, and the result shouldn't ask you to walk past ends at the meter. Then walk a few steps past that end while looking away from the wall: the card should say "You're past the end of the wall".

@SamGu-NRX

Update: Sam's 3c7b83a (merged into t3/ios-mvf at 75dea41, a few minutes after the proposal above) already covers most of it:

Part 1: "Can't get there" now ends the wall at the phone, within what was walked on that side (WalkedEnd).
Part 2: the ground in front of the meter is now the walk's first request.
Part 3 (B-06): "Wall ends here" is offered during the walk, and the end prompt follows the walked distance.
Part 4, photos: photos past an unexplored end are refused, with "You're past the end of the wall".

What's still open:

Marks past an end. markFeaturePoint still accepts a tap past a marked end with no warning (the AC unit at 1:23 in the clip above).
The gap screen (Past-end requests: a band request beyond a marked end never fills, and a past_end request drops the end #35, B-12). It still has no "Wall ends here" during a past-end request. A band request beyond a still-marked end still can't fill, and a skipped past-end request leaves its end cleared.

@SamGu-NRX, ignore the options above for parts 1–3. For those two leftovers, should I take them in a small PR against t3/ios-mvf? The plan: refuse or warn on a mark past an end, and on the gap screen show "Wall ends here" during a past-end request and restore the end if the request is skipped.

Still there in field test run 2 (build 3.1, beta ad91620, capture code e9e405d), on both sides. The scan export was lost, so this is from the recording and the strip, at 5 fps.

0:53, left. Tapped on "Walk slowly to your left". The ground cell just left of the meter was still amber (seen once). The left end landed at the meter; the first upload said "Keep walking past the left end of the scan (0 ft 4 in left of the meter)".
2:40, right. Tapped at the physical end of the mock wall, about 17 ft right ("can't get there because I'm at this wall"). Only one 6-inch cell next to the meter was covered in both bands, so the right end landed at 0 ft 6 in right. The window (about 7 ft) and the AC stand-in (about 16 ft) ended up outside the scan.

The tester had read the runbook's workaround aloud but hadn't filled the strip left of the meter before the first tap. The code is unchanged at ad91620: ScanEngine+Actions.swift#L354-L359, reach at GuidancePlanner.swift#L102-L118, and the clamp at ScanEngine+Export.swift#L128-L133.

New knock-on effects in this run: the walk kept asking for stretches past the right end (#38), and the server's past-end request then stretched the left end to 7 ft 6 in (#35).

Merge pull request #48 from SamGu-NRX/t3/wall-end-guards

Checked run 2's symptoms against t3/ios-mvf (3c7b83a, plus 5c8c739). Build 3.1 came from e9e405d, which doesn't have 3c7b83a, so run 2 didn't test the fix.

2:40, right end at 0 ft 6 in at the physical end of the 17 ft wall: fixed by 3c7b83a. "Can't get there" during the walk now ends the side at the phone, capped at the farthest kept photo on that side. The replay in Tests for #24, #28 and #29: synthetic walk-guidance cases modeled on field runs 1 and 2 #56 puts that end at 5.18 m (17 ft), with the window and the AC inside the scan.
0:53, left end at the meter with the ground left of it amber: fixed for that cause. The amber cell no longer affects where the end goes. If nothing was walked left, the end still lands at the meter by design, and the server's past-end request asks for the rest. ios: end the side the phone is on, and no zero-length walls (#24) #48 refuses a wall whose two ends are both at the meter.
Run 1's 1:23 AC mark past the end: still accepted on purpose, since the server puts it on the wall's line.

Next field test (a build with 3c7b83a, ideally with #48 and #56): walk about 3 ft left before tapping "Can't get there", and check the left end lands there. At the far end of the wall, check that the dashed line on the strip is under you before tapping. The first upload shouldn't ask you to keep walking past an end that's inches from the meter.

The fix is on t3/ios-mvf: 3c7b83a, merged at 75dea41. Two follow-ups sit on top of it, 5c8c739 and the walking height in d0ff1be. Build d02cc11 or later for runs 2 and 3; it is green (CI run 36279804539).

What changed for this issue:

"Can't get there" now ends that side where the phone is: its position along the wall, no farther than the path you walked on that side. The old code used the unbroken covered stretch from the meter, which was 0 in run 1.
If the phone stands on the other side of the meter, the end goes at the farthest point walked on the side being ended. A side never walked ends at the meter.
Before you tap, the strip shows a dashed line where the end will land. It dims whatever the end would leave out, and says "Ending the wall here leaves out N ft you walked" when you've walked past that point.
Photos taken past an unexplored end, looking at nothing between the ends, aren't kept, and the card says so.
Regression test: FullFlowUITests/testCantGetThereEndsWhereThePhoneIs taps "Can't get there" before the ground by the meter is seen. It checks each end is within 1.7 ft of the phone and that wall and ground are exported over the walked stretch. The scene validates against the server schema.

Your #48, merged at 2f193aa and in d02cc11, makes "Wall ends here" end the side the phone is on.

Build 4.1 field test (TestFlight 4.1, beta 45017ba, iPhone 14 without LiDAR, three runs on 2026-09-26): mostly fixed, with two cases still wrong.

Fixed in run 1 (mock wall): "Can't get there" ended each side where the phone had walked: left end 1 ft 0 in left (2:20), right end 20 ft 3 in right (2:55). Before, both went to the meter.
Still wrong on a short side, run 2 (mock wall), 1:45: "Wall ends here" at the left post put the end at the meter, and the strip dropped the cells it had just shown. WalkedEnd.end caps the end at the farthest kept photo, and no photo was kept left of the meter (one is kept only every ~0.5 m of movement).
Still wrong in run 3 (a real house), 1:34–1:35: the left end landed 13 ft 2 in left although the phone never went past about 6 ft 8 in left, and the right end at 1 ft 9 in with the phone at about 5 ft right. Not yet explained; the device log would settle it.

Follow-up: #71. Analyses: PR #60 (run 1, run 2, run 3).

How the build 4.1 runs bear on the end-placement options above, and what's still needed to decide, is now on #71: #71 (comment)

🤖 Generated with Claude Code

Merge the audit's stable element reads (the #24 test flake)

Merge the engine lane's freeze blockers

Add the server build plan and facade reference media (#24)

Navigation Menu

Repository navigation

"Can't get there" during the walk can put the wall's end at the meter, and the rest of the walk is dropped #24

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

"Can't get there" during the walk can put the wall's end at the meter, and the rest of the walk is dropped #24

Description

Activity

AidenJohnston commented on Sep 26, 2026

AidenJohnston commented on Sep 26, 2026

AidenJohnston commented on Sep 26, 2026

AidenJohnston commented on Sep 26, 2026

AidenJohnston commented on Sep 26, 2026

AidenJohnston commented on Sep 26, 2026

AidenJohnston commented on Sep 26, 2026

SamGu-NRX commented on Sep 27, 2026

AidenJohnston commented on Sep 27, 2026

AidenJohnston commented on Sep 27, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions