@iamu-dev/iamu 0.8.0-beta.4 → 0.8.0-beta.6

package/dist/templates/prompts/designer.md

@@ -15,13 +15,13 @@ The person already judged what it was like: whether the product fits their role,
 - `persona`: who walked, with their device. `situation`: the moment of need, its tension, and the brief.
 - `findings`: what the person filed on this run, as refs: `F<n>` for problems, `S<n>` for what helped, each with its `step`. A finding's `severity` is the one the person filed.
 - `walker_summary`: what worked for them, what they still wondered, and how the walk ended.
-- `screens`: the run's screens in walk order. A screen's `key` is its URL path (with the host when the run crossed hosts; else the walker's name for it). A screen visited twice has two `visits`. Screenshot paths are relative to `run_dir`. Open every screenshot in `key_frames` and look at it; open `other_screenshots` when you need to see more. `steps` carry what the person did and thought at each step.
+- `screens`: the run's screens in walk order. A screen's `key` is its URL path (with the host only for a page on another site than the product; else the walker's name for it). A screen visited twice has two `visits`. Screenshot paths are relative to `run_dir`. Open every screenshot in `key_frames` and look at it; open `other_screenshots` when you need to see more. A key frame's `screenshot` is what the person saw; its `full_page`, when there is one, is the whole page at that moment: use it for anything below the fold, and for a `checked` entry on something the viewport frame does not show. `steps` carry what the person did and thought at each step.
 - `design.files`: the team's design docs (`design`) and product docs (`product`), by absolute path. A file with a `heading` means that section only. A file whose `applies_to` names only app directories may not concern these screens: judge that from the screens. Each `design` file entry also carries `rules`: the parser's canonical list of rule names extracted from that file (`Section > Name` when a name repeats). `design.proposals` lists edits already proposed, each with its `before` and `after`: to support an open one, propose the same change (the same `before` and `after`); never raise a rejected one again.
 - `facts`: computed from the team's code and docs, not taste; `null` when nothing is off. `facts.stale_references` lists references the design docs make (a path, a `path#Symbol`, a `--token`) that no longer exist. `facts.contrast_clashes` lists token pairs, by name, whose text contrast is flagged or whose status/brand fills are too close to tell apart, per `theme`. Raise one only where a screen you looked at shows it, and cite it as computed from the docs and tokens (with the ratio) rather than as something you saw; a clash on a screen the person never reached is a conformance issue, not a persona one. Never treat a missing `facts` as proof that the docs are current.
 - `judged_against`: `design-docs` when the team's design docs apply to this run, else `general-craft`.
 - `ignored`: issues a person has read and dismissed (one with no `screen` was about the whole run). Do not raise them again unless they got worse; if one did, say how.
 - `guidance`: the team's active guidance rules and settled constraints (`iamu/guidance/`), including test-locked copy or styling and domain conventions. Treat these as binding decisions: never raise a new issue or re-confirm an earlier `P<n>` (`same_as`) when it contradicts a rule in `guidance`.
-- `open_findings`: your earlier issues on these screens that are still being worked on, as refs `P<n>`. When you see one again on this run (and it is not covered by `ignored` or `guidance`), raise it as an issue of this run with `same_as: "P<n>"`. One you looked for and no longer see goes under `checked` (see below): that is how a fix is confirmed. One you did not look for goes in neither list and stays uncertain; leaving it out never confirms a fix. In the summary, say which still show and which are gone.
+- `open_findings`: your earlier issues on these screens that are still being worked on, as refs `P<n>`. When you see one again on this run (and it is not covered by `ignored` or `guidance`), raise it as an issue of this run with `same_as: "P<n>"`. One you looked for and no longer see goes under `checked` (see below): that is how a fix is confirmed. One you did not look for goes in neither list and stays uncertain; leaving it out never confirms a fix. In the summary, say which still show and which are gone. A `P<n>` marked `no_full_frame` is on a screen this run has no full-page frame of: when the viewport frames do not show where it was, say in the summary that it was not seen (below the fold, not checked) and do not list it under `checked`, which would count it as fixed.
 - `setup_notes`: about the test setup (accounts, seeded data), not the product. Never judge the product by them.
 
 ## What you open

package/dist/templates/skills/iamu-findings.md

@@ -167,6 +167,8 @@ Record the decision with `iamu triage` — it sets `triage_status` and `triage_n
 iamu triage <slug> --status addressed --note "Made handoff notes optional on /sv/handoff; verified on screen."
 ```
 
+For `addressed`, always pass `--note` with one line on what now shows on screen ("the icons on /orders carry text labels"), not the code change: the next run's matcher reads it to confirm the fix, and without it a fix the persona does not mention stays unconfirmed. A longer note goes in with `--note-file <path>` (`-` reads stdin).
+
 The resulting frontmatter:
 
 ```yaml

package/dist/templates/skills/iamu-run.md

@@ -679,7 +679,7 @@ When the user asks to review findings one by one:
      Record the agreed decision and advance to finding #<N+1>. Do NOT trap the user with modal dialogs after each conversational turn.
    - **Fix immediately (leave triage now)**:
      If the user explicitly chooses to drop out of triage and fix right now:
-     Fix with the fix loop, not blind: run `iamu fix-brief <slug> --json` and follow its `loop` (before and after screenshots of the page in `shots_dir`, helped / hurt / no visible change, the strengths and design rules it lists kept intact). Then record: `iamu triage <slug> --status addressed --note "<summary of fix>"`.
+     Fix with the fix loop, not blind: run `iamu fix-brief <slug> --json` and follow its `loop` (before and after screenshots of the page in `shots_dir`, helped / hurt / no visible change, the strengths and design rules it lists kept intact). Then record: `iamu triage <slug> --status addressed --note "<what now shows on screen>"` — one line on the visible change, which the next run's matcher reads to confirm the fix.
      Tell the user in 1 line: "✓ Applied fix. Finding #<N> marked addressed."
    - **Next finding (keep open / defer)**:
      Leave open (or set `triage_status: deferred` with note) and advance to finding #<N+1>.
@@ -705,7 +705,7 @@ When the user asks to review findings one by one:
        Proceeding with code fixes — say "re-run first" or "done for now" to adjust.
 
    - **Executing the queued fixes:**
-     When Option 1 is chosen, fix each queued finding in turn with the fix loop (`iamu fix-brief <slug>`, before and after screenshots of its page, helped / hurt / no visible change); findings on the same page go together as one change. Queued designer findings are fixed the same way from `iamu fix-brief <run-id>#D<n>`; mark each by the `finding.slug` its brief gives (a later designer's review of that screen confirms it, not the re-run). Verify once at the end (run test/typecheck suite). Update each finding with `iamu triage <slug> --status addressed --note "<summary of fix>"`.
+     When Option 1 is chosen, fix each queued finding in turn with the fix loop (`iamu fix-brief <slug>`, before and after screenshots of its page, helped / hurt / no visible change); findings on the same page go together as one change. Queued designer findings are fixed the same way from `iamu fix-brief <run-id>#D<n>`; mark each by the `finding.slug` its brief gives (a later designer's review of that screen confirms it, not the re-run). Verify once at the end (run test/typecheck suite). Update each finding with `iamu triage <slug> --status addressed --note "<what now shows on screen>"`.
      Tell the user: "✓ Applied fixes for <K> findings. All marked addressed."
 
    - Run `iamu validate --all`.
@@ -737,7 +737,7 @@ When the user asks to review findings one by one:
      6. In linked mode, run `iamu sync --json` once so teammates see the verified decisions.
 
 #### B. Direct Batch Actions ("fix 1 and 2", "fix all critical")
-The glance shows no recommendations, so never fix from a number alone. First show each named finding's card (step 6A format, without the decision prompt), then one line: `Fix <these N> as shown? Say "yes", or name the ones to leave out.` Only on a yes, fix each with the fix loop (`iamu fix-brief <slug> --json` and its `loop`; findings on one page go together as one change; a designer finding from `iamu fix-brief <run-id>#D<n> --json`) and record each with `iamu triage <slug> --status addressed --note "<summary of fix>"`. Then continue as in item 3's "Executing the queued fixes" from `iamu validate --all`.
+The glance shows no recommendations, so never fix from a number alone. First show each named finding's card (step 6A format, without the decision prompt), then one line: `Fix <these N> as shown? Say "yes", or name the ones to leave out.` Only on a yes, fix each with the fix loop (`iamu fix-brief <slug> --json` and its `loop`; findings on one page go together as one change; a designer finding from `iamu fix-brief <run-id>#D<n> --json`) and record each with `iamu triage <slug> --status addressed --note "<what now shows on screen>"`. Then continue as in item 3's "Executing the queued fixes" from `iamu validate --all`.
 
 #### C. Ad-hoc Questions & Challenges ("why did Karl do that?", "is #2 really a bug?")
 Answer directly using persona brief context and step evidence. If the walker got confused or misinterpreted intended behavior, recommend dismissing as `walker_error` or `not_relevant` rather than adding unnecessary code.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@iamu-dev/iamu",
-  "version": "0.8.0-beta.4",
+  "version": "0.8.0-beta.6",
   "type": "module",
   "description": "Test your product as realistic personas — scenario-driven development CLI",
   "license": "MIT",