Wall ends: open review findings from #48 and #47 (wrong-side fallback, short-wall refusal, lost task detail, inferred end marks) #162

Sam's reviews of #48 and #47 raised four findings that were still open when both merged into t3/ios-mvf (his alert on #10 at d02cc11). None has been fixed since, and no issue tracked them. I checked that each is still present at t3/ios-mvf e62be65 and at beta 2db95af. #99 (#66, the "leaves out N ft you walked" line) doesn't cover them. Sam noted that on #99, and they're out of its scope.

1. "Wall ends here" can still end the wrong side (#48)

WalkedEnd.side (ios/HouseScanKit/Sources/HouseScanKit/Guidance/WalkedEnd.swift) falls back to the first open side in three cases: the phone has lost its place, it stands at the meter, or its own side already has an end. During a tilt or step-back task "Wall ends here" is still offered in those cases, and WalkedEnd.end then puts the other side's end at that side's farthest walked point, not where the homeowner stands. WalkedEndTests.wallEndsHereEndsTheSideThePhoneIsOn asserts the fallback.

Suggested fix (Sam): hide or refuse the action when the phone's side isn't established or is already ended, rather than silently choosing another side.

2. The short-wall refusal hides the task's detail (#48)

While wallTooShort is set, WallWalkScreen.instruction shows the refusal with only the guidance title as its detail. An aim request loses its distance and location on screen and in VoiceOver. Keep the task's detail alongside the refusal.

3. The short-wall rule is a copied placement number, and it can block a real wall (#48)

WallFrame.minWallLength (0.79 m) is the server's battery width copied onto the phone. Placement numbers are supposed to live only in rules.yaml. finishWalk refuses ends closer than that, clears both ends, and asks the homeowner to walk. That has two effects:

• A real wall shorter than a battery (a return between a door and a corner) can never be finished. Codex raised the same point as a P1 on ios: end the side the phone is on, and no zero-length walls (#24) #48.
• An end already answered "Something blocks it" (a .limit end) is thrown away, along with its kind.

The comment in ScanEngine+Actions.swift (finishWalk) assumes ends this close mean nobody walked, and a real short wall disproves that. On beta, WalkRefusals.walkedMinimum (#135) reuses the same constant.

Suggested fix (Sam): refuse on walk evidence instead of length. Neither side has a kept view past one photo spacing (walkedFarthest(.left) and walkedFarthest(.right) both under AutoCaptureConfig().spacingMeters). Clear only the ends set without walking, and keep a .limit end.

4. An inferred end is written to the packet as a homeowner mark (#47)

When a past_end request is met, settleClearedEnd's satisfied branch (ScanEngine.swift) calls setEnd. That stamps markTimes[MarkKey.end(side)] with the current clock, so packetInputs writes a wall_end mark at the edge of the ground request, timed as if the homeowner had tapped there. The packet owner's ruling on #47: inferred ends must not become homeowner marks.

• Keep a set of inferred ends and leave them out of the packet's marks.
• Clear their mark time.
• Let the past-end request's guidance entry say how it ended.
• Keep the end in scene.json, and leave the restore branch and real taps as they are.

The beginServerGap comment says a cleared end stays cleared until the homeowner marks it again, but GapRequestScreen has no control for that. The comment should say so.

Related: #24, #71, #82, #135, #136, #147.

🤖 Generated with Claude Code