Generated from cat-harness/processes/ui/wireframe-design-review.bpmn by gen-processes-viz.ts — do not edit here. All processes

Wireframe design review

Process_WireframeDesignReview · advisory · 6 step(s)

WireGen (methodologies/wiregen) made executable: a written design intent, at least two mid-fidelity candidates each with a web AND a mobile layout, mechanical checks, a blind per-criterion review, adjudication where reviewers disagree, and a recorded choice. A wireframe is part of the design process for adjudication (owner, 2026-09-23). Operating skill: wireframe-design-review. Issue #1023. The same mechanical checks back the as-is wireframe every declared visualiser owes, which check:wireframes runs.

How it connects

• Called by: CRDM Phases 2–4 — BPA and requirements, Questionnaire wireframe review
• Calls: Criterion adjudication, Options analysis
• Names the wireframe-design-review skill without calling this process: Questionnaire wireframe review, SMART Guideline end to end — activity-calls-skill-process asks whether each should be a call activity.
• Presented on: no docs page section shows this diagram

Lanes — who acts

lane	role	what it does here
Designer	authoring-agent	Writes the intent, produces candidates with real content, and runs the mechanical checks. Does not review its own candidates.
Feedback providers	feedback-provider	One or more reviewers (agent and human) who see candidates shuffled, without their author, and record pass, warn or fail per criterion with a reason. There are no scores and no averages.
Adjudicator	adjudicator	Reached only when entries for one criterion disagree. Settles the disagreement with a reason, and decides between surviving candidates through options analysis.

Steps

Every one of the 6 step(s) is documented.

step	lane	skill / sub-process	what it does
Write the design intent D_Intent	Designer	wireframe-design-review	A short statement of who the screen is for, what they need to do, and what it must show. It is the criterion every candidate is judged against.
Produce >= 2 candidates, web + mobile D_Candidates	Designer	wireframe-design-review	Mid-fidelity HTML: monochrome, real folio content, semantic icons, no placeholder text. Each candidate has both a web layout and a mobile layout.
Mechanical checks, both viewports D_Check	Designer	wireframe-design-review	Tool wireframe-check renders every candidate at a web and a mobile viewport. It fails on horizontal overflow at mobile width, on placeholder text, and on a missing viewport, and writes screenshots and a script entry per criterion.
Blind review per criterion R_Review	Feedback providers	wireframe-design-review	Criteria: intent-fit, web usability, mobile usability, accessibility, and alternatives considered. A review at one viewport only is incomplete.
Adjudication Call_Adjudicate	Adjudicator	calls Criterion adjudication	folio-assistant’s adjudication: the adjudication leads, the checker’s entry is kept, and the dispensation carries its reason. Reviewers disagreeing on ONE criterion is a criterion disagreement, so this calls the QA-criterion specialisation (bean bvuk, owner 2026-09-23): the failing entry stands, the criterion does not apply to this screen, or a dispensation is granted with its reason. FOR THIS CALLER THE SPLIT WAS A REGRESSION, not a fix, and that is worth keeping because the PR that made it said the opposite. When bvuk moved the outcome half out of adjudication.bpmn, #1074 reported that all four remaining callers “no longer reach A_ScopeCriterion or A_Dispensation” and framed it as the intended effect. True for three of them, whose question never admitted those steps. Here it removed the two steps the sentence above already documents, so the call was left pointing at a shared judgement that no longer runs either. Repointing restores what the documentation always claimed rather than changing it. The entry condition matches exactly rather than approximately: GW_Agree asks whether the blind reviewers’ entries agree and takes no here, and Process_CriterionAdjudication starts at “entries for one criterion disagree” — R_Review records pass, warn or fail PER CRITERION with a reason, so the disagreement reaching this step is a per-criterion disagreement between reviewer entries and nothing else.
Choose a candidate Call_Choose	Adjudicator	calls Options analysis	A one-off choice between surviving candidates. Rejected candidates are kept, with the reason each lost.

Decisions

Every one of the 3 decision(s) is documented.

decision	what decides it	branches
Checks pass? GW_Checks	Answered by the mechanical checks at both viewports. yes goes to blind review; no returns to producing candidates.	yes → Blind review per criterion no → Produce >= 2 candidates, web + mobile
Entries agree? GW_Agree	Do the blind reviewers’ entries agree? no goes to adjudication; yes goes to choosing a candidate.	no → Adjudication yes → Choose a candidate
Revise the intent? GW_Iterate	Asked after a candidate is chosen: should the design intent be revised? yes rewrites the intent and starts again; no accepts the wireframe.	yes → Write the design intent no → Wireframe accepted