yam-flow 0.1.2 → 0.1.4

package/references/ueye.md

@@ -65,6 +65,7 @@ Use these when the task depends on visual truth, reference matching, or design q
 2. Reference Read Proof.
 3. Reference vs Implementation Matrix.
 4. Design Quality Review.
+5. Review Continuity and Comparison Report.
 
 Default bound:
 
@@ -145,6 +146,26 @@ Review dimensions:
 For each relevant dimension, record `pass`, `needs-polish`, or `fails`.
 Keep actionable findings in P0-P3 order. Prefer fixing P0/P1 and cheap local P2 issues before broad polish.
 
+### Review Continuity and Comparison Report
+
+Use when a screen has more than one visual pass, a reference needs follow-up, or a previous Ueye report should stay connected to the next one.
+
+Record:
+
+- `review_session_id` for the current pass.
+- previous report path or previous session id when available.
+- reference sources and implementation screenshot sources.
+- comparison result.
+- previous and current screenshot ids when available.
+- viewport and state.
+- similar, different, and missing items.
+- resolved findings, new findings, still-open findings, and regression status.
+- design quality result.
+- next visual action.
+- truth status.
+
+Use `yam ueye report --previous-report previous.json --review-session-id current-pass --similar "..." --different "..." --missing "..." --json` when you need a compact continuity record.
+
 ## P0-P3 Ledger
 
 - P0: blocker, unusable, impossible to complete primary workflow, severe accessibility or responsive failure.
@@ -162,8 +183,9 @@ Keep actionable findings in P0-P3 order. Prefer fixing P0/P1 and cheap local P2
 6. Screenshot/browser recheck when feasible.
 7. Reference vs Implementation Matrix when reference fidelity matters.
 8. Design Quality Review.
-9. P0/P1 closeout.
-10. Truth status.
+9. Review Continuity and Comparison Report when the work spans multiple passes.
+10. P0/P1 closeout.
+11. Truth status.
 
 ## Truth Caps
 

package/skills/question/SKILL.md

@@ -8,7 +8,7 @@ description: Very-light Q&A route. Use when the user invokes $question or asks a
 Use for:
 - Simple conceptual explanations.
 - "What is X?" or "Can I do Y?" questions.
-- Local harness/project usage questions.
+- Local workflow/project usage questions.
 - Clarifying a decision that does not need fresh source gathering.
 
 Do not use for:

package/skills/ueye/SKILL.md

@@ -36,7 +36,10 @@ Do not use for:
 - Image evidence should stay bounded: inspect the primary screen first, then only the states/images needed to support the claim.
 - Design quality judgment belongs after implementation/review: compare to the reference first, then judge whether the result is good design.
 - Keep Ueye as one route: start fast, then opt into `yam ueye capture` and `yam ueye compare` only when a `verified` visual claim needs real screen evidence.
-- Prefer the Codex in-app Browser plugin for interactive visual checks. Do not switch to the user's Chrome browser unless the user explicitly asks for Chrome or the task requires existing Chrome cookies, sessions, extensions, or profile state.
+- Use `yam ueye report` when reference, implementation screenshot, comparison result, design quality, and next action should be recorded as one compact run report.
+- For follow-up visual reviews, keep continuity explicit: previous report/source, current report/source, comparison delta, resolved findings, new findings, and next action.
+- Generated media can guide direction, but it cannot verify the implemented screen without implementation screenshot evidence.
+- Prefer the in-app browser for interactive visual checks. Do not switch to a profile-dependent browser unless the user explicitly asks or the task requires existing cookies, sessions, extensions, or profile state.
 
 ## Workflow
 
@@ -54,10 +57,12 @@ Do not use for:
 6. Implement the smallest coherent design improvement when implementation is requested.
 7. Check default, loading, error, empty, disabled, hover/focus, and mobile states when relevant.
 8. Run browser/screenshot verification when feasible.
-   - Prefer the Codex in-app Browser plugin for local pages, localhost, file URLs, and ordinary visual QA.
-   - Do not silently use Chrome as a fallback. If the in-app Browser cannot capture or inspect, report the visual cap as `partial` or `blocked`.
-   - Use `yam ueye capture --url URL --out path.png` when a local Playwright install is available and the claim needs real browser evidence.
+   - Prefer the in-app browser for local pages, localhost, file URLs, and ordinary visual QA.
+   - Do not silently use a profile-dependent browser as a fallback. If the in-app browser cannot capture or inspect, report the visual cap as `partial` or `blocked`.
+   - Use `yam ueye capture --url URL --out path.png` when a project-local capture backend is available and the claim needs real browser evidence.
    - Use `yam ueye compare --reference ref.png --actual shot.png` when reference fidelity needs a proof-ready local comparison record.
+   - Use `yam ueye report --reference ref.png --actual shot.png --design-quality needs-polish --json` to preserve the run-level visual provenance and next action.
+   - When continuing a prior review, include previous/current report or screenshot identifiers and mark the comparison as improved, regressed, unchanged, or not-verified.
 9. Compare reference and implementation when reference fidelity was requested:
    - matched, similar, different, not-applicable, or not-verified.
    - Separate "faithful to reference" from "good design."
@@ -95,6 +100,12 @@ Use these artifacts for reference-led implementation or serious visual review. K
 5. Design Quality Review:
    - judge whether the result is good UI/UX/design after reference comparison.
    - use pass, needs-polish, or fails for each relevant design dimension.
+6. Review Continuity and Comparison Report, when this is a follow-up review:
+   - record previous source/report, current source/report, comparison delta, resolved findings, new findings, still-open findings, truth status, and next action.
+7. Media Generation Proof, when generated images are part of the task:
+   - record whether generation was requested, attempted, blocked, or produced an output.
+   - use `yam media proof --requested --attempted --output path.png --wait-loop --json` when a generated image materially affects the design direction.
+   - never use generated media proof as a substitute for implemented screen evidence.
 
 ## Visual Truth Caps
 
@@ -135,6 +146,7 @@ Report:
 - Source evidence used.
 - Reference Read Proof and reference comparison result when a reference was used.
 - Design Quality Review result when implementation or serious visual review was requested.
+- Review continuity/comparison result when this continues a prior Ueye run.
 - P0-P3 issues or confirmation that no blockers were found.
 - States/viewports checked.
 - Truth status and visual verification cap.