Repository navigation
experiments: device field test runbook and run 1 of the TestFlight build - #23
Conversation
Adds a runbook of every device-only claim from the product description on t3/verification, the setup plan for the first site, and a script that replays a scene.json's photos through the app's coverage rules. Run 1 on a mock wall uploaded a scan whose ends sat within 4 in of the meter: "Can't get there" places an end at GuidancePlanner.reach, which stayed at 0 ft until photo 43 of 44 because the ground in front of the meter was only photographed on the way back. The server answered manual_review with no spot. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The recording shows the two "Can't get there" taps: the left one before any ground was seen, the right one at the corner while the ground row by the meter was still amber. Scores the device-only claims it shows and notes the tilt prompts never asked for the ground in front of the meter. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 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. Comment |
|
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. |
Spell out the positions and photos the coverage needs before a "Can't get there", add the see-behind check for builds with LiDAR occlusion, run C-4 before C-3, and group run 3 into short recordings with O-4 last. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- docs/00 reports the first TestFlight run on a real wall (PR #23), says rules.yaml marks every value without a public source as a placeholder, and calls Gemini the planned box detector, since no branch uses it yet. - docs/04 notes that the demo has no 1 ft wall-distance rule because the solver places the battery flush. - AGENTS.md and README point to PR #23, PR #17 and the exact docs/00 section, following the rewritten prompt-writing skill. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
Before this merges, please cut its write-up to the experiment format in #33 ( |
The evidence section said every result came from public datasets, but PR #23 has since run the app on a real phone. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
@AidenJohnston Sam’s experiment-format request is still open at 321ea7e. Please shorten the README to about 200 words using experiments/README.md, and keep any run evidence from the real site in git-ignored data/. I am reviewing this PR against main, including the replay and setup-plan artifacts. I will post any correctness or privacy findings separately. I will not edit your branch or #46. |
SamGu-NRX
left a comment
There was a problem hiding this comment.
Main-track review findings at the pinned head. Fixes belong to the branch writer; no source changes made by this caretaker.
|
* Sync a10-sparse-photo-flow breadth work from the Project store (no result file yet) * Sync a10-sparse-photo-flow breadth work from the Project store (no result file yet) * Sync a10-sparse-photo-flow breadth work from the Project store (no result file yet) * Sync a10-sparse-photo-flow breadth work from the Project store (no result file yet) * Sync a10-sparse-photo-flow breadth work from the Project store (no result file yet) * Sync a10-sparse-photo-flow breadth work from the Project store (no result file yet) * Sync a10-sparse-photo-flow breadth work from the Project store (no result file yet) * Sync a10-sparse-photo-flow breadth work from the Project store (no result file yet) * Sync a10-sparse-photo-flow breadth work from the Project store (no result file yet) * Sync a10-sparse-photo-flow breadth work from the Project store (result file A10-sparse-photo-flow.md)
What changed
The first run of the House Scan TestFlight build (1.1,
t3/ios-mvf657ab28) on a real iPhone uploaded a scan the server couldn't use. The phone walked about 19 ft of wall and kept 44 photos, but both wall ends were saved within 4 in of the meter. So the scan reported no observed wall or ground, and the server answeredmanual_reviewwith no spot.experiments/device-field-test/adds:t3/verificationproduct description, with test IDs to say aloud while screen recording.scene.json's photos through the app's coverage rules (uv run coverage_replay.py scene.json).Why the walk was lost
"Can't get there" sets that side's end at
GuidancePlanner.reach(ScanEngine+Actions.swift L315). That's the unbroken stretch from the meter where the wall and ground are both covered. The screen recording shows both taps: the left one before any ground was seen, and the right one at the corner, 16 ft away, while the ground row next to the meter was still amber (seen once). The tilt prompts never asked for the ground in front of the meter, soreachstayed at 0 ft and both ends landed at the meter. After that, coverage past the ends is dropped, even though the walk kept taking photos and accepting marks up to 19 ft away without saying so. The logic is unchanged at thet3/ios-mvfhead. The README lists fixes for the lane A owner to choose from; no app code changes here.Measurements, app minus tape: window right edge −0.5 in, sill +1.9 in, left edge +5.4 in, gas stand-in 4.8 in nearer the meter.
Verification
scene.jsonto the deployed server again:manual_review, ends at ±0.328 ft.coverage_replay.pyagainstCamera.pixel(of:)andCoverageMap, and ran it on the run 1 scan. Its output is in the README.Checklist
🤖 Generated with Claude Code