docs(app-review): reconcile the review with its own evidence

[obvious-autobuild]

fleet-packet: basescanning-030

Documentation-only reconciliation of docs/app-review, per issue #128. No app code changes; the review stays pinned at a39d0a5.

What changed

The review documents disagreed with themselves or with the product descriptions they cite in eleven places. Corrections, by file:

ux/review.md

• The verdict counted R1 as a failed blocker on the strength of B-08 alone. R1 judges the final visible strip before the upload or finish state; B-08 is the skipped stretch that is never sent to the server, which says nothing about that strip. R1 now reads Not verified, and the verdict stays Block on R9, T5, I8 and B-09.
• The result row claimed H5 without a failed result anywhere: no cited run ends in one, so H5 now reads Not verified.
• The wall-walk row said nothing about I7, V4 or A2. It now records, labelled from source: guidance toward unobserved ground is the world-anchored ring and dots, not the text I7 asks for, and the target ring pulses while idle, which V4 rules out. A2 reads Not verified: the spoken summary can say "100 percent seen" with nothing covered and the ground unseen, and that description does not settle whether tracking status is announced.
• The close-up row said the problem pill fails contrast, while UX-03 says it failed at 24af434 and 525ea40 and passes at a39d0a5. The row now dates the failure to the earlier runs. It also records the T6 gap: the sources document blur and glare fixes but no cut-off-label instruction.
• The upload row stated "four text elements do not scale" as if current. It now separates the older runs from the a39d0a5 audit, which reports one fixed-size font, the walk's "Mark something".
• The mark-features row and the Fixed since the preview paragraph claimed I4 from a run that marked one window. From source, every window row carries its own question, so several windows would show one question per row and break I4's one-question rule. The pass is now scoped to that single window and the conditional failure is recorded.

product/bug-triage.md

• B-03 grouped the unreadable replay with camera-denied and camera-failure failures, but the only reproduction stayed on onboarding, for the replay. The entry now splits the two: unreadable replay (seen, stuck on onboarding) and camera denied or failed session (code only, stuck on find-meter). The triage table labels each side.

product/README.md

• The index said 2 resolved defects; the triage table resolves B-01, B-05 and B-15. It now says 3 resolved and names them.

The B-03 split, carried to the files that restate it (second commit)

Three other files repeated the grouping the corrected B-03 no longer supports, because the seen reproduction left the app on onboarding, not on find-meter:

• ux/friction.md: the stall table's find-meter row named one screen for all three causes; it now names the screen per cause and marks the replay leg seen, and the trailing note about source-only rows carves out that one seen case.
• product/foundations/flow.md: the open question scopes the find-meter consequence to the camera cases, labels it as read from source and not run, and records the seen replay result instead of inviting a check that has been run.
• product/screens/onboarding.md: the suspected-bug entry now labels the replay leg as seen and the camera legs as source-only, matching the file's own observed/unobserved convention.

Adds docs/app-review/check-links.py, a stdlib script that checks every relative link and heading anchor under docs/app-review (GitHub slug style, fenced code blocks skipped, website links ignored). Run from the repo root: python3 docs/app-review/check-links.py

Why

Issue #128. The docs are a historical review of the app pinned at a39d0a5, so the corrections change wording and evidence labels only. No correction claims new Simulator, accessibility or device testing; unsupported passes and unestablished failures read Not verified, matching the checklist's own evidence rules. The three repeat-site files are outside the issue's letter but inside its standard (the index, rows and findings agree): leaving them would have left the tree contradicting the corrected B-03 about which screen the homeowner is stranded on.

UI changes

N/A: documentation only; no app or site behavior changes.

Verification

• python3 docs/app-review/check-links.py prints "OK: all 130 relative links and anchors in docs/app-review resolve" and exits 0. The count includes repeated link occurrences.
• Cross-checked against a second, independently written checker over the same tree at eab8622: it discovered the identical set of 112 unique file-target pairs (129 counting repeats then) and found no broken file or anchor either way. The second commit adds one link, which the committed checker covers.
• git diff --stat main..obv/basescanning-030 touches only files under docs/app-review: 7 files, 108 insertions, 23 deletions, two commits.
• An independent acceptance audit of the first commit against the issue's eleven findings and acceptance criteria reported 11/11 findings and all acceptance criteria passing; a second independent audit of the issue against docs at main confirmed all eleven findings and flagged the three repeat sites, which the second commit corrects.

Not verified

• The corrected claims themselves. The wording now matches what the cited sources and past run reports say; re-running the app at a39d0a5 to re-observe the runs is out of scope and claimed nowhere.

Assumptions

• "Earlier runs" for the pill contrast and the four upload elements means the pre-a39d0a5 runs the review already cites; UX-03 and UX-04 carry the per-commit detail.
• R1 leaves the verdict's failing list rather than being re-attributed, because nothing in the docs establishes its failure; the verdict remains Block.
• The issue scopes the B-03 finding to bug-triage.md; I extended the same split to friction.md, flow.md and onboarding.md, which restate the grouping, so the tree agrees with itself.

Risk

Low. Documentation only. The one wording risk is the R1 sentence, which asserts a negative (B-08 alone does not establish the silent-gap failure); it spells out what R1 judges so a reader can check it against the checklist.

Checklist

• The scope is focused; related changes belong together
• I explained what changed and why
• N/A (before/after images): documentation-only change; nothing visible in the app changed.
• N/A (video): no motion or interaction to record.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 6c334cae-038c-4eeb-8fec-8fc7629b1688

---

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

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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.}