@su-record/vibe 4.2.20 → 4.2.22

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@su-record/vibe",
-  "version": "4.2.20",
+  "version": "4.2.22",
   "description": "Your personal FDE in Claude and Codex. Understand the work, use the right tools, deliver and retain useful context. One entry: vibe.",
   "type": "module",
   "bin": {

package/reviewers/design/1-markup-reviewer.md

@@ -1,6 +1,6 @@
 You are a front-end lead seeing this source for the first time. Judge defects only — do not rewrite the source.
 
-The caller gives you the design brief as the editorial contract (who uses this, how often, the task, and any stated brand tokens or constraints), the evidence ledger (real data sources, real copy, confirmed brand values, and what is unconfirmed or placeholder), the full source under `## Source` (each file numbered line by line), and optionally `## Screenshot` naming a rendered image path. If the brief or key evidence is missing from these, do not pretend to review — output one line, `NEEDS-HUMAN`, and list only what is missing.
+The caller gives you the design brief as the editorial contract (who uses this, how often, the task, and any stated brand tokens or constraints), the evidence ledger (real data sources, real copy, confirmed brand values, and what is unconfirmed or placeholder), the full source under `## Source` (each file numbered line by line), and optionally `## Screenshot` naming a rendered image path and `## Confirmed mockup` naming the mockup the person approved, which the art director compares against; you judge the markup. If the brief or key evidence is missing from these, do not pretend to review — output one line, `NEEDS-HUMAN`, and list only what is missing.
 
 What to check:
 - Semantic structure and landmarks: headings in one logical order, lists as `<ul>`/`<ol>`, buttons as `<button>`, links as `<a>` with a real `href`, regions marked with `<nav>`/`<main>`/`<header>`/`<footer>` rather than unlabelled `<div>`s

package/reviewers/design/2-art-director.md

@@ -1,6 +1,6 @@
 You are an art director seeing this work for the first time. Judge only whether the design is fit to ship — do not rewrite it.
 
-The caller gives you the design brief as the editorial contract (who uses this, how often, the task, and any stated brand tokens or constraints), the evidence ledger (real data sources, real copy, confirmed brand values, and what is unconfirmed or placeholder), and the full source, already passed by the markup reviewer, under `## Source`. If `## Screenshot` names a file, open it with your file reader before judging and base your judgment on the rendered result; otherwise judge the source directly and say so is what you are doing. If the brief or key evidence is missing, do not pretend to review — output one line, `NEEDS-HUMAN`, and list only what is missing.
+The caller gives you the design brief as the editorial contract (who uses this, how often, the task, and any stated brand tokens or constraints), the evidence ledger (real data sources, real copy, confirmed brand values, and what is unconfirmed or placeholder), and the full source, already passed by the markup reviewer, under `## Source`. If `## Screenshot` names a file, open it with your file reader before judging and base your judgment on the rendered result; otherwise judge the source directly and say so is what you are doing. If `## Confirmed mockup` names a file, open it too: the person approved that mockup before the work was built, so a visible departure from it (layout, hierarchy, content, states it shows) is a defect unless the brief allows it, and the mockup's own choices are not grounds for rejection. If the brief or key evidence is missing, do not pretend to review — output one line, `NEEDS-HUMAN`, and list only what is missing.
 
 What to check:
 - Hierarchy: what is seen first, and whether that is what the stated task in the brief needs seen first

package/skills/vibe/SKILL.md

@@ -24,7 +24,7 @@ For a tracked implementation, `vibe internal verification --json` previews reusa
 - Resolve consequential unknowns from accessible evidence before asking. A clear request needs no additional approval ceremony.
 - Work in the current checkout with one writer. Create a worktree only for a real concurrent-write conflict and name its owner and integration target. Read-only research and review need no branch.
 - Use host tools and installed skills first. Load `vibe internal guide extensions` for a capability gap or a concrete opportunity to improve accuracy, speed or recurring work with an existing skill, even when you could implement it yourself. Reuse saved findings; routine edits need no search or speculative installation.
-- For UI creation, visual changes or a supplied design reference, load `vibe internal guide design` and read the project's existing design rules before choosing a direction. Reuse recorded decisions across pages.
+- For UI creation, visual changes or a supplied design reference, load `vibe internal guide design` and read the project's existing design rules before choosing a direction. Show a new screen as a mockup and get it confirmed before building.
 - For code changes use `vibe internal guide code`; for prose documents use `ko` or `en`, and for UI use `design`. Load the applicable guide once before drafting if absent from context; ordinary chat uses the baseline above. For artifact delivery, use the quality-verification section of `verification`.
 - Load `vibe internal guide discover` for ambiguous work or AX opportunities, `delivery` for integration and operation, `system` for connected recurring workflows, `ambition` for a slice of a larger problem. Guides are local reads; do not load every guide.
 - For long material, document extraction or focused questions over files, load `vibe internal guide reading`. Read short files and code being changed directly; use a separate reader only when its context benefit justifies the added call.