undefined

If this file already exists, read it and resume from the correct iteration.

---

gh gist view 84a5c108d5742c850704a5088a3f4cbf --files

gh gist view 84a5c108d5742c850704a5088a3f4cbf -f <filename>

undefined

This table is the ground truth for coverage. Every row MUST be accounted for before the loop stops. Do NOT omit any criterion from any requirement.

**Priority order for picking the next journey:**
1. Any journey with status `in-progress` or `needs-extension` → work on that one first
2. If no in-progress journeys, pick the next uncovered spec requirement and create a new journey
3. Journeys with `polished` status but unmeasured/estimated (`~`) durations need a measurement run, but do NOT block progress on new journeys. The orchestrator can batch-measure these separately.

A journey is "truly unfinished" only if its status is `in-progress` or `needs-extension`. Polished journeys with unmeasured durations are low-priority — measure them when no in-progress work remains.

rm -f journeys/{NNN}-{name}/screenshot-timing.jsonl

undefined

Run this Bash command in the background. When it exits with code 1, a timing violation was caught. `SLOW-OK` entries (documented unavoidable gaps) are ignored.

**2e. Wait for the builder to complete.** Two possible outcomes:

**Outcome A — Builder completes normally (no violations):**
The watcher found no SLOW entries. Proceed to Step 3 (Refiner).

**Outcome B — Builder completes but evidence review finds gaps:**
The orchestrator reads the screenshots and timing log. If the snap index sequence has large gaps (e.g., snap names jump from "090-..." to "103-..." skipping the entire recording phase), the journey has silently skipped phases. Re-launch the builder with a directive to investigate and fix the gaps. Include the specific missing phases in the prompt.

**Outcome C — Watcher killed the test (violation detected):**
1. Read `screenshot-timing.jsonl` to find all SLOW entries
2. For each SLOW entry, read the test code to find what happens between the previous screenshot and the slow one
3. **Research**: Is it possible to make this step <= 5 seconds?
   - Read the app code that the test is exercising
   - Check if a `waitForExistence(timeout:)` is set too high
   - Check if the app itself is doing unnecessary work
   - Check if intermediate screenshots could break a long operation into visible chunks
4. **If fixable (can be <= 5s):** Fix the test code or app code. Go back to 2b (clear timing, re-launch builder).
5. **If NOT fixable** (genuine async like a real download): Add a comment in the test code on the line BEFORE the slow snap explaining exactly why: `// SLOW-OK: 8s gap — simulated model download requires async completion, cannot be reduced`. Then go back to 2b.
6. The watcher will now skip entries with matching names that have `SLOW-OK` comments in the test code.

**Important:** When investigating a SLOW entry, think carefully. Common fixable causes:
- `waitForExistence(timeout: 10)` where the element appears in <1s — lower the timeout
- Missing accessibility identifier causing XCUITest to do a slow tree search — add the identifier
- App performing synchronous work on main thread — move to background
- Test waiting for an element that doesn't exist yet because app code hasn't been written — write the app code

Common unfixable causes (document these):
- Real network/download simulation that must complete asynchronously
- App launch time (first screenshot always has overhead)
- System permission dialogs that appear unpredictably

| <iteration> | <journey-name> | <duration> | <score>% | <N changes> | <continue/done> |

Loop complete after <N> iterations.
Final score: XX%
Journeys built: <list with durations>
Spec coverage: X / N requirements fully covered (all criteria)
Criteria coverage: X / M acceptance criteria covered (impl + test + screenshot)
Uncovered criteria: (should be 0)
Total test suite duration: Xm
Run all tests with: <exact test command>