@domandigital/craft 0.20.1 → 0.20.3

package/CHANGELOG.md

@@ -1,5 +1,20 @@
 # @domandigital/craft
 
+## 0.20.3
+
+### Patch Changes
+
+- 6800957: Compare carousel purposes before diagnosing duplication, avoid selecting a design by edit size alone, and allow explicit protected-staging placeholders while retaining outstanding publication requirements.
+- d0d9234: Decision confidence: reviewing a proposed change, with attribution to Eunice Ordor and the provenance of the principle (a phone-layout review on 15 October 2026) in CHARACTER.md and PRINCIPLES.md. New `craft direction review --notes design-review.json` weighs feedback against the visitor's job in `art-direction.json`. Each note keeps the observation, the visitor problem under it, the proposed solution, the evidence and the smallest defensible change apart, and judges the suggestion and the recommendation separately. The problem is observed, inferred, preference or unknown: only something inspected (a screenshot, rendered behaviour, source, a measurement, the page's content) makes it observed, a report from an audit, stakeholder or customer makes it inferred, and a claim at a width nobody looked at stays unknown. A recommendation is a confirmed correction, a design hypothesis, an optional refinement or no change, and a review can end on "no change is recommended". Changes climb a ladder from copy to restructure; a structural step or an addition (carousel, script, dependency, animation, testimonial, call to action, repeated content) has to say why every smaller step was not enough. A second carousel is not supported where a gallery exists, information is not removed without an observed cost, a reasoned section order is not overridden by a preference, repetition and similarity to other sites are not defects without a stated cost to the visitor, and a change that needs a fact nobody supplied is held rather than written in. `craft direction validate` also raises an inferred identity finding when a job that worries about who the visitor would deal with first meets a person after three or more sections, and asks for a name and a line, not a biography moved up or a portrait. New `differentiation` lens, `design-review.schema.json`, and exports `assessReview`, `isStructural` and the review types. Fixtures: a calibration review of a plumbing homepage plus clinic and salon reviews, which reach different outcomes for different reasons.
+- bb9b233: Decision confidence. A page in `art-direction.json` can now record `confidence`: the widths its decisions were examined at (`mobile`, `tablet`, `desktop`) and the evidence it offers (`proof`: work, people, credentials, reviews, experience or outcomes, each with a section, `first-look` or `on-request` depth, and a reason tied to the customer's job). `craft direction validate` reads it and prints findings tagged observed, inferred or unknown, each with the lens it belongs to (relevance, hierarchy, evidence, identity, action, disclosure, mobile) and why it matters to that visitor. There is no score and no conversion claim, and nothing is required: a file without `confidence` validates and reports exactly as before, and no evidence kind, founder portrait, slideshow, phone number or section order is ever demanded. A finding made on one width is never carried to another; widths nobody examined are reported as unknown. `craft direction research` asks where the visitor looks, what would settle it and what the next step is, without assuming a phone or a portrait. Exports `assessConfidence`, `validateConfidence`, `viewportOf` and the new types; the JSON Schema gains `confidence`. CHARACTER.md, PRINCIPLES.md, STANDARD.md section 10 and the README describe it, and three fixtures (sole-trader plumber, private physiotherapy practice, appointment-based salon) show one principle giving three different answers.
+- 0dba997: Sites made with create-site deploy their preview to Cloudflare only. `scripts/gates/deploy-preview.mjs` no longer has a Vercel branch or looks for `.vercel/project.json`, `preview.host` in `site.programme.json` is `cloudflare` or null, the `host` answer prompt suggests `cloudflare`, and `docs/site-programme.md` and the README say so. A site that still sets `preview.host` to `vercel` now stops at Stage 06 with a message naming the host; remove the key or set it to `cloudflare`. The synthetic README and a craft comment no longer name Vercel; no behaviour changes in those two.
+
+## 0.20.2
+
+### Patch Changes
+
+- 5199c0e: `measureRoute(open, options)` measures every viewport for a page only the caller can open, such as a portal screen behind a sign-in: the phone half in a page the caller opens in `PHONE`, the wide half in one it opens in `DESKTOP` (now exported), merged and written once for `craft phone-first --measured`, as `measureSite` does for a public page (DOM-835).
+
 ## 0.20.1
 
 ### Patch Changes

package/CHARACTER.md

@@ -19,6 +19,10 @@ the floor in STANDARD.md and the page audit.
 Character also comes from the display face, accent, shape, motif and one
 signature moment, with evidence from the client's world.
 
+Whether the order gives this visitor what they need to trust the business and
+take the next step is the question [Decision confidence](#decision-confidence)
+asks. It reads the same hierarchy layer; it is not a second standard.
+
 ## Three signals, and a reason behind every choice
 
 Any fixed list of tells goes stale. Ban Inter and a model moves to Space
@@ -296,6 +300,311 @@ words.
 The editor schema ships as `@domandigital/craft/art-direction.schema.json`.
 A file from phase A that holds only exceptions stays valid.
 
+### Decision confidence
+
+Attributed to Eunice Ordor, Client Relations & Operations at Doman Digital
+("Eunice's Lens"). The question it asks of every page:
+
+> What does this visitor need to see, understand and believe before they are
+> comfortable taking the next appropriate action?
+
+It sits beside usability, accessibility, visual quality, performance, brand
+character and the business's own aims, and replaces none of them. It exists to
+improve design judgement, not to make sites alike.
+
+A page should give a visitor what they need to understand the business, trust
+it and take the next appropriate step, in an order that follows how they
+decide rather than a sequence of stock sections. Craft already records most of
+that: the job says who is visiting, what worries them and how long they take;
+the hierarchy says what leads, what order, and where the ask sits. Decision
+confidence is the reading of those decisions against the visitor, with three
+additions to the hierarchy layer and no new layer.
+
+The questions, with where Craft already answers each. They are lenses to look
+through, not a checklist or a score, and `evidence` and `identity` below are
+the two that cover decision confidence and human accountability:
+
+| | Question | Where it is decided or read |
+| --- | --- | --- |
+| A | Visitor relevance: does the page meet who this is and what worries them? | `job`, `hierarchy.*.lead`, and the finding that names a worry no decision answers |
+| B | Information hierarchy: is related information together, and nothing needed early buried? | `hierarchy.*.order` and `journey` reasons; evidence placed in a section the order lacks |
+| C | Evidence and credibility: is what is offered relevant, and does anything show it exists? | `confidence.proof` (kind: work, people, credentials, reviews, experience, outcomes) |
+| D | Human identity and accountability, where relevant: can the visitor tell who they would deal with? | `confidence.proof` of kind `people`, in whatever form fits: a name, a register entry, a portrait |
+| E | Action clarity: is the next step the one this visitor takes, and does the page offer it? | `hierarchy.*.primaryAction`: call, book, enquire, quote, explore, buy |
+| F | Progressive disclosure: essential early, detail when sought, and a signal that the detail exists? | `confidence.proof[].depth`: `first-look` or `on-request` |
+| G | Brand personality and contextual fit: does the character come from this business? | The token layer and its evidence, unchanged |
+| H | Mobile experience: was it looked at on a phone, and what was not examined? | `confidence.examined` and STANDARD.md section 10 |
+| I | Contextual differentiation: does it differ where that helps recognition, clarity, confidence or brand, and only there? | The token layer and `craft estate compare`. Similarity between conventional patterns is not a defect |
+
+`confidence` is optional on each page and records two things the hierarchy did
+not: which widths the decisions were looked at (`examined`), and the evidence
+the page offers (`proof`). Each item says what it is, which section it sits in,
+whether a visitor meets it without looking (`first-look`) or opens it
+(`on-request`), and why this visitor needs it. The reason goes through the same
+rule as every other reason: eight words, tied to this client's job, and a
+default such as "social proof builds trust" fails. Cite a source when one shows
+the evidence exists.
+
+```json
+"confidence": {
+  "examined": ["mobile"],
+  "proof": [
+    {
+      "kind": "work",
+      "what": "one photograph of a finished boiler job with the street and date on a card in the shot",
+      "position": "hero",
+      "depth": "first-look",
+      "because": "The visitor wants to see the actual work before letting a stranger into the house, so one finished job is met on the first screen.",
+      "evidence": ["jobs"]
+    }
+  ]
+}
+```
+
+`craft direction validate` reads it and prints findings after the problems.
+Each names the lens, where in the file, what was found, and why it matters to
+this visitor, and carries one of three bases:
+
+- **observed**: directly supported by the file or the snapshot. Evidence placed
+  in a section the declared order does not have; an ask positioned in a section
+  the order lacks.
+- **inferred**: a reasonable reading that nobody has checked. Detail held back
+  for those who seek it, with nothing of its kind met first, so it may never be
+  found. This is a hypothesis, not a rule.
+- **unknown**: needs the client or a test. Evidence no source shows exists (a
+  planned testimonial, a claimed credential, an outcome nobody has compiled);
+  a worry from the job no decision names; a width nobody examined.
+
+Nothing here is a score, a count to push towards zero or a prediction. A
+finding says what Craft could and could not establish. A page with no findings
+is not "confident", and one with several is not wrong: unknown means ask.
+
+What it deliberately does not do:
+
+- Require any evidence kind. A sole trader, a clinic and a salon rely on
+  different evidence, and a page with none recorded validates.
+- Require a slideshow, a founder portrait, testimonials above the fold, a
+  telephone number, an enquiry form, or any section order. The job decides
+  whether the ask is to call, book, enquire, request a quote, explore or
+  buy; a clinic whose patients are at work and would rather write is not
+  failed for lacking a phone button.
+- Treat a conventional page as weaker. Conventional order is allowed with a
+  reason, as above.
+- Carry a finding between widths. A review of a phone layout is evidence about
+  the phone. The desktop and tablet are reported as not examined until
+  someone examines them, and the findings are then made there.
+- Treat an example claim as a fact. Example copy, a hypothetical years in
+  practice or a quote nobody collected is not a source; leave `evidence` empty
+  and it is reported as unknown.
+
+Three executable fixtures show one principle giving three answers, in
+`src/__tests__/fixtures/confidence/`: a sole-trader plumber (call at once,
+the work and the man's name and van on the first screen, no portrait), a
+private physiotherapy practice (write rather than ring, registration shown as
+text, practitioners by name and specialism with no portraits, an outcomes
+summary reported as unknown because nobody has compiled one), and an
+appointment-based salon (book beside each stylist's own colour work, a full
+gallery on request). They are invented, as the electrician is. None has a
+slideshow; two have no phone action; none has a founder portrait; all validate.
+
+#### Where it came from
+
+On 15 October 2026 Eunice reviewed the phone layout of a UK plumbing
+business's homepage. She did not review the desktop. Four things came out of
+it, and they are kept apart on purpose:
+
+1. **Her observations.** The owner was introduced late. Information about the
+   work, services, reviews and the owner felt fragmented. Visitors should be
+   able to feel confident without searching. The site could show more
+   personality. Trust signals should read as a set.
+2. **Her proposed solutions.** A hero slideshow. Removing some project
+   captions.
+3. **An independent audit's conclusions.** It agreed with the underlying
+   concerns, that the owner should be met earlier and credibility shown sooner.
+   It did not accept two of the solutions. The site already had a swipeable
+   project gallery, so a slideshow would repeat it. The captions were short and
+   helped people move through the work. Services were early for a reason: a
+   visitor first needs to know the business does their job. Moving the whole
+   biography under the hero could make the page worse. It preferred targeted
+   changes to a redesign. These were the audit's findings, reported to Craft,
+   not measurements Craft took.
+4. **This principle.** A stakeholder can be right about the problem and wrong
+   about the fix, and the two are judged separately. Nothing from that one
+   site is a design law: it is the case Craft's reasoning is tested against.
+
+Craft has no rule for that plumber or any other client. The same reasoning is
+tested on a sole trader, a clinic and a salon, and gives a different answer
+for each.
+
+### Reviewing a proposed change
+
+`craft direction validate` reads a page's declared decisions. A review is
+different: somebody has said something about a page, and Craft has to decide
+what follows. `craft direction review --notes design-review.json` weighs the
+notes against the visitor's job in `art-direction.json`. For each note it keeps
+five things apart:
+
+| | What it is | Held in |
+| --- | --- | --- |
+| 1 | The observation: what was said or seen, and by whom | `observation`, `raisedBy` |
+| 2 | The underlying visitor problem, if there is one | `problem`, `impact` |
+| 3 | The proposed solution, from whoever proposed it | `suggested` |
+| 4 | The evidence, and what kind it is | `evidence`, `basis` |
+| 5 | The smallest defensible improvement | `recommend` |
+
+**How well the problem is known** (`basis`):
+
+- **observed**: something was inspected. A screenshot, rendered behaviour,
+  source, a measurement, or what the page says. Evidence that was only
+  reported, by an audit, a stakeholder or a customer, can support
+  **inferred** at most, however confident it sounds.
+- **inferred**: plausible, supported by something reported but not looked at.
+- **preference**: taste, or a stakeholder's wish, with no stated cost to the
+  visitor. A fact with no visitor impact is also read this way when it is
+  inferred, and as polish at most when it is observed.
+- **unknown**: cannot be established from what is available. Nothing is
+  recommended until it is.
+
+Craft reads the declared basis against the evidence and says when it changed
+it, in the note. A claim made at a width nobody looked at stays unknown there:
+a review of the phone says nothing about the desktop.
+
+**What the recommendation is worth** (`recommend.class`):
+
+- **confirmed-correction**: fixes an observed defect that costs the visitor
+  something. Needs observed evidence and a stated impact.
+- **design-hypothesis**: could help, and needs judgement or a check to know.
+  Names how it would be checked (`validation`).
+- **optional-refinement**: polish. No important visitor problem is addressed.
+- **no-change**: the design already does the job. This is a successful result,
+  and a review can end on it: "The existing design is already appropriate for
+  what was reviewed. No change is recommended." Craft never invents an issue to
+  have something to say.
+
+**Minimum effective change.** `recommend.step` is on a ladder, smallest first:
+`copy`, `relocate`, `group`, `imagery`, `trust-placement`, `adjust-component`,
+`remove-redundancy`, then the structural `restructure` and `new-component`. A
+change takes the smallest step that answers the problem. A structural step, or
+any addition that costs something (`carousel`, `javascript`, `dependency`,
+`animation`, `testimonial`, `cta`, `duplicate-content`), must say which smaller
+steps were considered and why none was enough (`smaller`). A small step says why
+nothing larger is needed (`whyEnough`).
+
+The rules a review is held to, all checked without a model:
+
+- A suggestion and a recommendation are each held to the same tests, so a
+  right observation can come with a suggestion that is not supported. Craft
+  then reports it as `supported`, `comparison-needed`, `not-supported` or `not-needed`. The legacy
+  `narrower-change-preferred` value remains readable, but a step rank alone no
+  longer selects a winner. Compare whether each proposal answers the problem.
+- An existing gallery, slideshow or swipeable set prompts a comparison of
+  purpose, content and placement. `comparisons` records the exact `existing`
+  description, `samePurpose` and `because` on each proposal. A documented
+  duplicate should be reused; distinct roles can justify separate components.
+  A keyword alone does not establish duplication.
+- Removing information needs an observation that it is redundant and a stated
+  cost to the visitor. Short useful captions are not redundancy.
+- A structural change or an addition needs a problem that is observed, or
+  inferred with a stated impact. A preference does not justify it.
+- A section the declared order already places with a reason is not moved on a
+  preference. Only something observed overrides it.
+- Repetition, a long page, a conventional order and a likeness to other sites
+  are not defects. They become findings only through a stated cost to this
+  visitor.
+- A change that depends on a fact or asset nobody has supplied (a register
+  number, the owner's own words) is held, and the note says what is
+  outstanding. Craft does not write it in, and does not infer a registration,
+  a qualification or a regulatory status from its absence or presence.
+
+Impact is a reason like any other: eight words, about this client's job, and
+neither a preference ("the client wants it") nor the category's default.
+
+A note in a review:
+
+```json
+{
+  "id": "owner-late",
+  "lens": "identity",
+  "observation": "The owner is introduced too far down the page.",
+  "raisedBy": "Eunice Ordor (stakeholder), agreed by the independent audit",
+  "problem": "A homeowner letting a stranger into the house cannot tell who is coming until well down the page.",
+  "basis": "observed",
+  "evidence": [
+    { "kind": "screenshot", "ref": "captures/home-375.png", "viewport": "mobile" },
+    { "kind": "audit", "ref": "independent audit of the phone layout", "viewport": "mobile" }
+  ],
+  "impact": "A homeowner with a stopped boiler cannot see who is coming into the house, so they may ring someone else or ask before reaching the introduction.",
+  "appliesTo": ["mobile"],
+  "suggested": { "change": "move the full biography directly below the hero", "step": "restructure" },
+  "recommend": {
+    "class": "confirmed-correction",
+    "change": "show the owner's name and one line about working alone beside the first call button",
+    "step": "trust-placement",
+    "because": "The visitor's worry is who is coming into the house, so a name and one line answer it where the call is first offered.",
+    "whyEnough": "The full biography already serves visitors who want it further down, so only a name and a line need to meet the homeowner early.",
+    "requires": [{ "what": "the owner's name and that he works alone and answers the phone", "source": "tom" }]
+  }
+}
+```
+
+The shape is `design-review.schema.json`. The calibration review in
+`src/__tests__/fixtures/confidence/calibration-review.json` carries the case
+above as a set of notes, against an invented plumber, with the answer Craft
+gives to each: the owner met earlier by a name and a line, and not by moving the
+biography; credibility earlier as a hypothesis with a check; no second carousel;
+the captions left alone; the services left early; no decoration added for
+personality; the owner's own words held until he supplies them; the desktop left
+unknown. The clinic and salon reviews next to it reach different outcomes for
+different reasons: a registration check joined to the profile but held for the
+register numbers; a founder biography declined because booking comes first.
+
+
+#### Context and learning from a later result
+
+The 15 October calibration records the earlier audit's recommendation, not a
+permanent verdict. The later Bellerose mobile comparison on 18 October preferred
+work photographs followed by a compact owner introduction, then trust and contact.
+The useful test is whether each alternative answers the visitor's question.
+Considering smaller edits remains required; fewer edits alone do not establish
+that the result is better. Keep human approval, observed layout changes and
+unmeasured commercial outcomes separate.
+
+For each carousel proposal, `comparisons` contains one entry per relevant existing
+component: `{ existing, samePurpose, because }`. Match the existing description
+exactly and explain the purpose, content and placement. This validates the
+recorded reasoning, not the truth of an aesthetic judgment. Same-purpose
+components prompt reuse; missing comparisons request an assessment without
+claiming duplication. Review and photo carousels may answer different questions.
+
+Reviews default to publication context. Explicit `context: "protected-staging"`
+can proceed when an unsupplied requirement declares `kind: "asset"`, `phase: "publication"` and a
+clearly marked `placeholder` description. Other requirements still hold the
+change. Every missing item remains in `outstanding`, and `publicationReady`
+remains false. This does not authorize publishing a placeholder or inventing a
+fact. Record actual asset delivery before assessing publication again.
+
+Save real before/after examples with capture dates, viewport, source commits,
+feedback attribution, decisions and validation. Assess the page independently
+before reading stakeholder recommendations when possible; if feedback is already
+known, record that limitation. A preferred example is useful calibration, not a
+universal order, a conversion claim or an exemption from future scrutiny.
+
+#### Using it
+
+Generating a page: run `craft direction research`, which asks where the
+visitor looks, what would settle it for them and what the next step is, without
+assuming a phone, a portrait or any one of them. Write the hierarchy from those
+answers, add `confidence` where the page makes decisions about evidence, and run
+`craft direction validate`. The findings are the list of what to confirm with
+the client or look at before launch.
+
+Reviewing a page or acting on feedback: write each remark as a note (what was
+said, what the visitor loses, what was proposed, what was inspected), then run
+`craft direction review --notes design-review.json`. Do the changes that come
+back as `change`, ask for what is `hold`, find out what is `gather-evidence`,
+and leave what is `no-change`. When a note names something that was not
+inspected, look before you act on it.
+
 ## Declaring an exception
 
 Doman Digital's own brand is violet. A hue rule with no way to say so flags the

package/PRINCIPLES.md

@@ -15,10 +15,10 @@ curves depending on which repo you were standing in.
 
 **`--ease-emphasized` was byte-identical to `--ease-standard`.** Both
 `cubic-bezier(0.2, 0, 0, 1)`. Every component reaching for emphasis got the
-standard curve and no emphasis. This is invisible on inspection — the names
+standard curve and no emphasis. This is invisible on inspection: the names
 differ, the values are 26 characters apart, and nothing fails.
 
-**`--ease-exit` was `cubic-bezier(0.4, 0, 1, 1)` — an ease-*in* curve.** It
+**`--ease-exit` was `cubic-bezier(0.4, 0, 1, 1)`, an ease-*in* curve.** It
 starts slow and accelerates out of view. It is the one curve never to use for
 UI: a dismissal on an ease-in reads as the interface dragging the thing away from
 you rather than getting out of your way.
@@ -34,7 +34,7 @@ the end state applies, and nothing moves.
 **141 classes painting nothing.** `bg-bg3` (48 uses) and `border-border` (93) in
 the portal reference Tailwind theme keys that do not exist under v4. They resolve
 to nothing and fall through to whatever the base rule said. Adding the missing
-keys would not be a fix — it would suddenly paint 48 surfaces nobody designed.
+keys would not be a fix. It would suddenly paint 48 surfaces nobody designed.
 
 **Two guesses at one accessible accent.** Two client repos each hand-picked a
 "legible variant" of the brand accent and wrote the contrast ratio into a
@@ -59,7 +59,7 @@ silence.
 
 **Both contrast models, because they disagree and the disagreement matters.**
 The portal's shipped `--violet-400` (`#a78bfa`) scores 7.21:1 against the
-marketing canvas — comfortably AA — and Lc −49.1, which is under the house bar
+marketing canvas, comfortably AA, and Lc −49.1, which is under the house bar
 for body text. WCAG 2.x is what an audit asks for; APCA is what tracks
 readability on dark backgrounds. The house bar is the pair.
 
@@ -71,7 +71,7 @@ passes: maximum brand, minimum sufficient contrast.
 **Motion is a decision before it is a curve.** The commonest motion defect is
 not a wrong easing, it is animating something that should have been instant.
 `shouldAnimate` refuses keyboard-triggered motion outright, refuses anything a
-user hits a hundred times a day, and always gives a reason — so a "no" is
+user hits a hundred times a day, and always gives a reason, so a "no" is
 arguable rather than mysterious.
 
 **Plain custom properties, nothing else.** The consumers do not agree on a
@@ -84,7 +84,7 @@ decide: the styling engine, the motion library, or where the tokens live.
 An anchor's real lightness and the ramp's lightness curve contradict each other.
 `#7050f5` sits at OKLCh L=0.564; `LIGHTNESS_CURVE[500]` is 0.658. Pin the anchor
 at 500, generate 600 from the raw curve at 0.586, and step 600 comes out
-*lighter* than step 500 — a ramp that reverses direction halfway down.
+*lighter* than step 500, a ramp that reverses direction halfway down.
 
 Both properties are required, so neither can be dropped. The curve is warped
 instead: a piecewise-linear map pinned at 0 and 1 that passes through
@@ -105,3 +105,27 @@ never the page grammar, because a page that looks typical for its category is
 the one visitors trust first. And it never asks for novelty. It asks for a
 reason: every expressive choice records where it came from in the client's own
 world, and a choice with no reason is the one flagged.
+
+## Decision confidence
+
+The same restraint applies to trust. A page is judged against what this
+visitor needs in order to understand the business, believe it and take the
+next step: who they are, what worries them, which evidence would settle it, and
+what the sensible next action is. That differs between a plumber with a
+stopped boiler, a clinic whose patients want to check a register and a salon
+whose clients want to see colour work before they book. So Craft asks for the
+reasoning, never for a pattern: no required hero, portrait, slideshow, section
+order or phone button, and no finding that a design is "less confident". What
+it records is what was observed, what is inferred, and what is unknown and needs
+the client or a test, and at which widths each was looked at. The phone is
+where this is examined first; a finding made there is not assumed to hold on a
+desktop. See [CHARACTER.md](./CHARACTER.md#decision-confidence).
+
+The principle is Eunice Ordor's, from a review of a phone layout on 15 October 2026,
+and its question is: what does this visitor need to see, understand and believe
+before they are comfortable taking the next appropriate action? It adds to the
+standards above and replaces none of them. It also sets how a change is chosen:
+a stakeholder's observation, the visitor problem under it, the proposed fix and
+the evidence are judged apart, and the smallest change that answers the problem
+wins. "The existing design is already appropriate" is a result. See
+[Reviewing a proposed change](./CHARACTER.md#reviewing-a-proposed-change).

package/README.md

@@ -107,6 +107,20 @@ npx craft estate compare --estate estate.json --directions
 npx craft direction validate --snapshot http://localhost:3000 --page home --strict
 ```
 
+A page may also record `confidence`: the widths its decisions were examined at
+and the evidence it offers, each with a reason. `craft direction validate`
+reports what is observed, inferred or unknown about it, with why it matters and
+no score. Nothing in it is required: no evidence kind, portrait, slideshow,
+phone button or section order. See [Decision confidence](./CHARACTER.md#decision-confidence).
+
+Feedback on a page is weighed against the visitor. `craft direction review --notes
+design-review.json` keeps what was said, the visitor problem under it, what was
+proposed, the evidence and the smallest defensible change apart, says how well
+each is known (observed, inferred, preference or unknown), and can conclude that
+no change is needed. Evidence only reported by an audit or a stakeholder cannot
+make a problem observed, and a width nobody looked at stays unknown. See
+[Reviewing a proposed change](./CHARACTER.md#reviewing-a-proposed-change).
+
 `--snapshot` accepts saved files and preview or production URLs. Drift fails
 with `--strict`; declared estate comparisons stay advisory. Version 1 files
 still validate with a warning. See [CHARACTER.md](./CHARACTER.md) for the full
@@ -305,7 +319,10 @@ test(`every viewport: ${route}`, async ({ page }) => {
 ```
 
 `measureViewports` works on the page the suite opened and signed in, so a
-portal keeps its fixtures. `measureSite(browser, { base, routes })` opens each
+portal keeps its fixtures. `measureRoute(open, { route, mainAction })` does
+both halves for such a page: `open("phone")` and `open("wide")` return the
+route opened and signed in, in a `PHONE` and a `DESKTOP` context, and the two
+halves are merged and written once (DOM-835). `measureSite(browser, { base, routes })` opens each
 route itself, the phone half in a phone context and the wide half in a desktop
 one, for a page anyone can open: create-site's `measure.mjs` uses it.
 `craft viewports --url <base> --route /` is the same for the command line: it
@@ -340,3 +357,10 @@ routes measured only at 375 with `measurePhone`.
 ## Licence
 
 Apache-2.0
+
+
+Design reviews compare proposed carousel purposes through `comparisons`; a shared
+widget name no longer proves duplication. A smaller implementation does not
+select a better design automatically. Protected staging reviews may reserve
+explicitly marked publication assets while reporting `publicationReady: false`.
+See CHARACTER.md, “Context and learning from a later result”.

package/STANDARD.md

@@ -162,7 +162,11 @@ is designed, built and measured first, and every wider layout is derived from
 it. A desktop layout squeezed onto a phone keeps the desktop's priorities and
 drops whatever did not fit; a phone layout widened keeps what matters and adds.
 Fitting on a phone is the floor. The bar is a page optimised for the phone and
-intended at every width, and the two sub-sections below set it.
+intended at every width, and the two sub-sections below set it. What the phone
+visitor needs in order to trust the business and take the next step is a
+judgement about the page, not a measurement; it is recorded and reported as
+[decision confidence](./CHARACTER.md#decision-confidence), and a finding made on
+the phone is not carried to another width without looking there.
 
 - **The phone is the base.** Base styles are the phone layout. Wider layouts
   are added with `min-width` queries only (Tailwind: unprefixed is the phone,

package/art-direction.schema.json

@@ -434,6 +434,88 @@
             "additionalProperties": false
           },
           "minItems": 2
+        },
+        "confidence": {
+          "type": "object",
+          "description": "Optional. Decision confidence for this page: the widths its decisions were examined at, and the evidence it offers, where it sits and how much is met first. Nothing in it is required: the job decides which kinds of evidence matter. Findings craft reads from it are never a score.",
+          "properties": {
+            "examined": {
+              "type": "array",
+              "items": {
+                "enum": [
+                  "mobile",
+                  "tablet",
+                  "desktop"
+                ]
+              },
+              "description": "The widths the evidence behind these decisions was looked at. A finding from one width is not carried to another."
+            },
+            "proof": {
+              "type": "array",
+              "items": {
+                "$ref": "#/$defs/proofItem"
+              }
+            }
+          },
+          "additionalProperties": false
+        }
+      },
+      "additionalProperties": false
+    },
+    "proofItem": {
+      "type": "object",
+      "required": [
+        "kind",
+        "what",
+        "position",
+        "depth",
+        "because"
+      ],
+      "properties": {
+        "kind": {
+          "enum": [
+            "work",
+            "people",
+            "credentials",
+            "reviews",
+            "experience",
+            "outcomes"
+          ]
+        },
+        "what": {
+          "type": "string",
+          "description": "What it is, in a few words: photographs of three finished bathrooms, the register number."
+        },
+        "position": {
+          "anyOf": [
+            {
+              "$ref": "#/$defs/role"
+            },
+            {
+              "enum": [
+                "header",
+                "sticky"
+              ]
+            }
+          ],
+          "description": "Where it sits. A section role must be in the page's order."
+        },
+        "depth": {
+          "enum": [
+            "first-look",
+            "on-request"
+          ],
+          "description": "first-look is met without being sought; on-request is detail a visitor opens or follows."
+        },
+        "because": {
+          "type": "string"
+        },
+        "evidence": {
+          "type": "array",
+          "items": {
+            "type": "string"
+          },
+          "description": "Source ids that show this exists. With none it is a claim the client has yet to confirm."
         }
       },
       "additionalProperties": false