Filed by greptile-iterator from rejected (out-of-scope-for-PR) greptile suggestion on PR #69.
Source PR: #69
Source thread: #69 (comment)
File: flows/contacts-list.yml:38 (and the same pattern in chats-list.yml, settings.yml, map.yml)
What greptile suggested
tapOn: optional: true correctly handles "already on this tab" but provides no guard if the tab disappears or is renamed. Without an assertVisible for a landmark element on each target screen before takeScreenshot, flows can silently capture the wrong screen and produce quietly incorrect BEFORE/AFTER pairs.
Why it was deferred
Out of scope for Stage 1 of the ui-screenshotter (per flows/README.md: "capture + write the table to PLAN.md only"). At Stage 1 a human reviews the BEFORE/AFTER table visually, so silent wrong-screen capture is loud — the reviewer sees the wrong screen. Adding assertVisible per flow requires identifying a stable landmark element on each tab that won't false-fail on legitimate UI changes — work that belongs with regression-gating (Stage 3), not capture-only (Stage 1).
Suggested follow-up
Before promoting ui-screenshotter to Stage 3 (regression gating, where flows fail the PR if they drift > N%), add one assertVisible per flow targeting a screen-specific landmark (e.g., a navigation title, a known empty-state string, or a debug-only accessibility identifier) immediately before takeScreenshot. Apply uniformly across all four flows.
🤖 Filed by greptile-iterator. Rationale + audit trail in the agent run record under `/80 Assistant/Agent Bus/runs/2026-05/greptile-iterator-Columba-iOS-pr69.md`.
Filed by
greptile-iteratorfrom rejected (out-of-scope-for-PR) greptile suggestion on PR #69.Source PR: #69
Source thread: #69 (comment)
File:
flows/contacts-list.yml:38(and the same pattern inchats-list.yml,settings.yml,map.yml)What greptile suggested
tapOn: optional: truecorrectly handles "already on this tab" but provides no guard if the tab disappears or is renamed. Without anassertVisiblefor a landmark element on each target screen beforetakeScreenshot, flows can silently capture the wrong screen and produce quietly incorrect BEFORE/AFTER pairs.Why it was deferred
Out of scope for Stage 1 of the ui-screenshotter (per
flows/README.md: "capture + write the table to PLAN.md only"). At Stage 1 a human reviews the BEFORE/AFTER table visually, so silent wrong-screen capture is loud — the reviewer sees the wrong screen. AddingassertVisibleper flow requires identifying a stable landmark element on each tab that won't false-fail on legitimate UI changes — work that belongs with regression-gating (Stage 3), not capture-only (Stage 1).Suggested follow-up
Before promoting ui-screenshotter to Stage 3 (regression gating, where flows fail the PR if they drift > N%), add one
assertVisibleper flow targeting a screen-specific landmark (e.g., a navigation title, a known empty-state string, or a debug-only accessibility identifier) immediately beforetakeScreenshot. Apply uniformly across all four flows.🤖 Filed by greptile-iterator. Rationale + audit trail in the agent run record under `/80 Assistant/Agent Bus/runs/2026-05/greptile-iterator-Columba-iOS-pr69.md`.