@deslop/coding-standards 0.1.912 → 0.1.1014

package/dist/oxlint.js

@@ -1,5 +1,5 @@
-import { $ as fromOption, $n as isNullish$1, A as getSomes, Bn as optimize, C as findFirst, Ct as some, D as flatten, E as flatMap$1, Fn as symbol, G as sort, Gn as hasProperty, H as prepend, Hn as string, I as join, J as get$2, K as take, Kn as isBoolean, L as last, Ln as combine, M as isArrayEmpty, N as isArrayNonEmpty, Nn as byReferenceUnsafe, Pn as equals, Rn as hash, S as filterMap, St as orElse, Tn as NodeInspectSymbol, V as of, W as some$1, Wn as symbol$1, X as remove, Xn as isNotNull, Z as values, Zn as isNotNullish, _ as dropRight, _t as isSome, a as includes, ar as isString, at as all, b as every, bt as match$1, c as startsWith, ct as filter, d as TaggedError, dt as flatten$1, er as isNumber, ft as fromNullishOr, g as dedupe, h as contains$1, i as Order, ir as isReadonlyObject, j as head, k as get$1, lt as firstSomeOf, m as appendAll, mr as dual, mt as getOrElse, n as make$2, o as match, ot as contains, p as append, pt as fromUndefinedOr, q as fromEntries, r as update, s as split, st as exists, t as get$3, ut as flatMap, v as empty, vr as pipe, w as findFirstIndex, wt as zipWith, x as filter$1, xr as pipeArguments, xt as none, y as ensure, yt as map, z as map$1, zn as number } from "./MutableRef-NhSl8G9M.mjs";
-//#region ../../node_modules/.pnpm/effect@4.0.0/node_modules/effect/dist/internal/graph.js
+import { $ as fromOption, $n as isNotNull, A as getSomes, Bn as combine, C as findFirst, Ct as some, D as flatten, E as flatMap$1, G as sort, Gn as string, H as prepend, Hn as number, I as join, In as byReferenceUnsafe, J as get$2, Jn as hasProperty, K as take, L as last, Ln as equals, M as isArrayEmpty, N as isArrayNonEmpty, On as NodeInspectSymbol, Rn as symbol, S as filterMap, St as orElse, Un as optimize, V as of, Vn as hash, W as some$1, X as remove, Yn as isBoolean, Z as values, _ as dropRight, _r as dual, _t as isSome, a as includes, at as all, b as every, bt as match$1, c as startsWith, cr as isString, ct as filter, d as TaggedError, dt as flatten$1, er as isNotNullish, ft as fromNullishOr, g as dedupe, h as contains$1, i as Order, j as head, k as get$1, lt as firstSomeOf, m as appendAll, mt as getOrElse, n as make$2, nr as isNullish$1, o as match, ot as contains, p as append, pt as fromUndefinedOr, q as fromEntries, qn as symbol$1, r as update, rr as isNumber, s as split, sr as isReadonlyObject, st as exists, t as get$3, ut as flatMap, v as empty, w as findFirstIndex, wr as pipeArguments, wt as zipWith, x as filter$1, xr as pipe, xt as none, y as ensure, yt as map, z as map$1 } from "./MutableRef-CzOzKHjT.mjs";
+//#region ../../node_modules/.pnpm/effect@4.0.2/node_modules/effect/dist/internal/graph.js
 /** @internal */
 const TypeId = "~effect/Graph";
 /** @internal */
@@ -94,7 +94,7 @@ const finalize = (source) => {
 	return graph;
 };
 //#endregion
-//#region ../../node_modules/.pnpm/effect@4.0.0/node_modules/effect/dist/internal/graphCsr.js
+//#region ../../node_modules/.pnpm/effect@4.0.2/node_modules/effect/dist/internal/graphCsr.js
 const cache = /*#__PURE__*/ new WeakMap();
 const makeAdjacency = (csr, incoming) => {
 	const impl = toImpl(csr.graph);
@@ -168,7 +168,7 @@ const get = (graph) => {
 	return result;
 };
 //#endregion
-//#region ../../node_modules/.pnpm/effect@4.0.0/node_modules/effect/dist/Graph.js
+//#region ../../node_modules/.pnpm/effect@4.0.2/node_modules/effect/dist/Graph.js
 /**
 * Models relationships between indexed nodes and edges.
 *
@@ -177,6 +177,7 @@ const get = (graph) => {
 * both nodes and edges. The module includes traversal, analysis, path-finding,
 * transformation, and diagram export utilities.
 *
+* @stability unstable
 * @since 4.0.0
 */
 /**
@@ -189,6 +190,7 @@ const get = (graph) => {
 * Use when handling failures thrown by graph operations that reject invalid
 * graph structure or unsupported algorithm inputs.
 *
+* @stability unstable
 * @category errors
 * @since 3.18.0
 */
@@ -229,6 +231,7 @@ const getMutableImplForMutation = (graph) => {
 *
 * @see {@link directed} for constructing a directed graph directly
 * @see {@link undirected} for constructing an undirected graph directly
+* @stability unstable
 * @category constructors
 * @since 4.0.0
 */
@@ -268,6 +271,7 @@ const make = (type) => (mutate) => {
 * Array.of(Graph.nodeCount(graph), Graph.edgeCount(graph)) // => [3, 2]
 * ```
 *
+* @stability unstable
 * @category constructors
 * @since 3.18.0
 */
@@ -297,6 +301,7 @@ const directed = /*#__PURE__*/ make("directed");
 *
 * @see {@link beginMutation} for opening a manual mutation scope
 * @see {@link mutate} for automatically scoped mutation
+* @stability unstable
 * @category mutations
 * @since 3.18.0
 */
@@ -351,6 +356,7 @@ const mutateScoped = (mutable, f) => {
 * @see {@link mutate} for obtaining a mutable graph from an immutable graph
 * @see {@link addEdge} for connecting existing nodes
 *
+* @stability unstable
 * @category mutations
 * @since 3.18.0
 */
@@ -379,6 +385,7 @@ const addNode = (mutable, data) => {
 * Graph.getNode(graph, 0) // => Option.some("Node A")
 * ```
 *
+* @stability unstable
 * @category getters
 * @since 3.18.0
 */
@@ -424,6 +431,7 @@ const invalidateCycleFlagOnAddition = (mutable) => {
 * @see {@link mutate} for obtaining a mutable graph from an immutable graph
 * @see {@link addNode} for creating node indexes before connecting them
 *
+* @stability unstable
 * @category mutations
 * @since 3.18.0
 */
@@ -489,6 +497,7 @@ const addEdge = (mutable, source, target, data) => {
 *
 * @see {@link isStronglyConnected} when only a boolean check is needed
 * @see {@link weaklyConnectedComponents} when edge orientation should be ignored
+* @stability unstable
 * @category algorithms
 * @since 3.18.0
 */
@@ -612,7 +621,7 @@ Object.freeze({
 	}
 });
 //#endregion
-//#region ../../node_modules/.pnpm/oxlint@1.85.0_oxlint-tsgolint@7.0.2003_vite-plus@1.0.0_@opentelemetry+api@1.9.1_@types+_bd1fc584f29238a6938d999624a6e509/node_modules/oxlint/dist/index.js
+//#region ../../node_modules/.pnpm/oxlint@1.85.0_oxlint-tsgolint@7.0.2003_vite-plus@1.1.0_@opentelemetry+api@1.9.1_@types+_9cc4ccd295d1e4fa3c5d39f32d54a2b1/node_modules/oxlint/dist/index.js
 /**
 * Define an Oxlint configuration with type inference.
 *
@@ -2508,7 +2517,11 @@ const oxlint = defineConfig({
 	},
 	overrides: [
 		{
-			files: ["**/*.config.ts", "**/main.*"],
+			files: [
+				"**/*.config.ts",
+				"**/app.plugin.js",
+				"**/main.*"
+			],
 			rules: { "import/no-default-export": "off" }
 		},
 		{
@@ -3252,7 +3265,7 @@ const oxlint = defineConfig({
 	},
 	settings: {
 		react: { version: "19.0" },
-		shadcn: { ui: ["@deslop/components/ui", "@dual/ui/components"] }
+		shadcn: { ui: ["@deslop/components-web/ui", "@dual/ui/components"] }
 	}
 });
 var oxlint_default = definePlugin({

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@deslop/coding-standards",
-  "version": "0.1.912",
+  "version": "0.1.1014",
   "repository": {
     "type": "git",
     "url": "https://github.com/MP281X/deslop",
@@ -32,8 +32,8 @@
     "access": "public"
   },
   "dependencies": {
-    "@shadcn/lint": "^0.2.0",
-    "oxlint-plugin-react-doctor": "^0.9.14"
+    "@shadcn/lint": "^0.2.1",
+    "oxlint-plugin-react-doctor": "^0.9.17"
   },
   "devDependencies": {
     "@oxlint/plugins": "1.85.0",

package/skills/design/SKILL.md

@@ -1,30 +1,37 @@
 ---
 name: design
-description: 'UI and UX rules for screens and visual explanations. Use when building, prototyping, or reviewing a component, diagram, review page, or other rendered agent output.'
+description: 'UI and UX rules for product screens, creative pages and visual explanations. Use when building, prototyping or reviewing a component, page, diagram, review page or other rendered agent output.'
 ---
 
 # Design
 
-**Scope.** Follow repository-specific CODING_STANDARDS.md and engineering.
+Follow the repository's `CODING_STANDARDS.md` and the engineering skill.
 
-**Two modes.** Consistent mode works inside an existing product: its components, tokens and every rule below. Creative mode covers work with no product to match, such as websites, landing pages, portfolios, launch pages, motion design and videos. It follows [Creative mode](#creative-mode) in place of Decide and Build, whose calm, dense product rules make every page a dashboard; only Access and responsiveness and Verify still apply. When a request mixes both, the product's screens stay consistent.
+**Two modes.** Consistent mode works inside an existing product and follows every rule below. Creative mode covers work with no product to match, such as websites, launch pages, portfolios, motion and video. It replaces Decide and Build with [Creative mode](#creative-mode), because dense product rules turn every page into a dashboard; Access and phones and Verify still apply. In a mixed request, the product's screens stay consistent.
 
 ## Decide
 
-**Direction.** Start from the actual task, audience, content and settled preferences. Make the next user action and its relevant content dominant, not generic "premium" styling. When a reference is useful, inspect the relevant accepted one for transferable hierarchy, density and interaction choices; distinguish observed details from inferred ones. Community brand analyses are inspiration, not verified current tokens.
+**Direction.** Start from the task, audience, content and the user's settled preferences. The next user action and its content dominate, not a generic "premium" style. When a reference helps, take hierarchy, density and interaction from the accepted one, and say which details you observed and which you inferred. Community brand analyses are inspiration, not verified current tokens.
 
-**One meaning.** Each visible element must add information, enable a distinct action or clarify a relationship. Delete repeated headings, summaries, counts, status badges, decorative wrappers and controls that say or do the same thing. Remove explanations that merely restate the visible example/state. Keyboard shortcuts, screen-reader labels and responsive placement are not redundant visible controls; preserve their function.
+**One meaning.** Each visible element adds information, enables a distinct action or shows a relationship. Delete repeated headings, summaries, counts, status badges, decorative wrappers and controls that say or do the same thing, and text that restates the visible example or state. Keyboard shortcuts, screen-reader labels and responsive placement are not redundant; keep their function.
 
-**Scan-first.** Put the task, relevant content and next action where they can be identified without reading a paragraph. Use stable visual roles, not another card/badge/icon for every fact. Expose needed detail on demand, never hide a consequential warning or essential action.
+**Scan first.** The task, its content and the next action read without a paragraph. Use stable visual roles, not another card, badge or icon for each fact. Put detail on demand, but never hide a consequential warning or an essential action.
 
-**Hierarchy.** Blur a capture: the primary content and the next action must still stand out. Give unequal priorities unequal weight, and repeat one layout only for records with equal roles. De-emphasize labels, metadata and chrome before enlarging the important content. Give each decision area one strongest action, with secondary or text variants for the rest. Keep gaps inside a group smaller than gaps between groups, and space above a heading larger than below it. The first phone viewport shows real content and the next action, not an introduction. Left-align prose and records; keep prose at 45 to 75 characters per line. Reserve the accent for actions and selection, status colors for states and chart colors for series.
+**Hierarchy.** Blur a capture: the primary content and the next action still stand out.
 
-| Content                    | Preferred treatment                                                       |
-| -------------------------- | ------------------------------------------------------------------------- |
-| Comparable records/options | Aligned rows/columns; consistent order, units and metadata placement      |
-| Familiar action            | Conventional icon-only control with an accessible name; one visible owner |
-| Ambiguous action           | Clear text label, not an invented/guessed icon or redundant icon + text   |
-| Explanation                | Real state/example first; text only for missing context or consequences   |
+- Unequal priorities get unequal weight; repeat a layout only for records with equal roles.
+- Mute labels, metadata and chrome before you enlarge content. Each decision area has one strongest action; the others use secondary or text variants.
+- Gaps inside a group are smaller than gaps between groups; space above a heading is larger than below it.
+- The first phone viewport shows real content and the next action, not an introduction.
+- Left-align prose and records, and keep prose at 45 to 75 characters a line.
+- The accent marks actions and selection, status colors mark states, and chart colors mark series.
+
+| Content                       | Treatment                                                                             |
+| ----------------------------- | ------------------------------------------------------------------------------------- |
+| Comparable records or options | Aligned rows and columns with consistent order, units and metadata placement          |
+| Familiar action               | A conventional icon-only control with an accessible name and one owner                |
+| Ambiguous action              | A clear text label, never an invented or guessed icon, or an icon with redundant text |
+| Explanation                   | The real state or example first; text only for missing context or impact              |
 
 ```tsx
 // one visible action, named for assistive technology
@@ -33,13 +40,13 @@ description: 'UI and UX rules for screens and visual explanations. Use when buil
 <Button><PencilIcon />Rename</Button>
 ```
 
-Do not remove necessary names, status, comfortable hit targets or instructions merely to make a screen smaller.
+Never remove a needed name, status, comfortable hit target or instruction only to make a screen smaller.
 
 ## Build
 
-These rules apply to product UI. A rendered explanation follows the host's rendering contract and the rules below.
+These rules cover product UI. A rendered explanation follows the host's rendering contract and these rules.
 
-**Canonical components.** Reuse the existing renderer, states and interactions for the same role. Inspect its relevant source/API, not a full catalogue; add missing primitives through the repository registry command. Fix wrong shared patterns at their owner when delivering retained code, not before an exploratory preview. Without a sibling, use the supplied reference and component defaults within settled preferences.
+**Components.** Reuse the existing renderer, states and interactions for the same role; read its relevant source or API, not the whole catalogue. Add a missing primitive through the repository's registry command. Fix a wrong shared pattern at its owner when you deliver retained code, not before an exploratory preview. Without a sibling, use the supplied reference and the component defaults within settled preferences.
 
 ```tsx
 // same model-selection control used elsewhere
@@ -48,7 +55,7 @@ These rules apply to product UI. A rendered explanation follows the host's rende
 <Select value={model} onValueChange={setModel} />
 ```
 
-**Tokens and structure.** Use the existing app host, compiler, theme, shared components and Tailwind tokens. No custom-CSS/dynamic-class escape, hardcoded color/size exception or weakened shared rules. Keep surfaces flat and dense; group by proximity before adding borders or elevation. No nested cards or wrappers that merely label content again. Whitespace must support hierarchy, separation or comfortable use, not fill the page.
+**Tokens and surfaces.** Use the existing app host, compiler, theme, shared components and Tailwind tokens. Add no escape into custom CSS or dynamic classes and no hardcoded color or size exception, and weaken no shared rule. Keep surfaces flat and dense: group by proximity before borders or elevation, and nest no cards or wrappers that only label content again. Whitespace serves hierarchy, separation or comfortable use, not filling the page.
 
 ```tsx
 // existing primitives and semantic tokens
@@ -57,105 +64,111 @@ These rules apply to product UI. A rendered explanation follows the host's rende
 <div className="rounded-full bg-[#eef] px-[7px] text-[11px]">No runs yet</div>
 ```
 
-**Typography.** Give headings, navigation, body text and data deliberate roles through the existing type scale, weights, line heights and readable line lengths. Use tabular numerals where values need comparison; let prose wrap without making controls inconsistent. Preserve established fonts and tokens rather than changing them for novelty. Do not substitute tiny labels, gratuitous capitals or isolated accent words for hierarchy.
+**Typography.** Give headings, navigation, body text and data deliberate roles from the existing type scale, weights, line heights and line lengths. Use tabular numerals for compared values, and let prose wrap without making controls inconsistent. Keep the established fonts and tokens; never change them for novelty. Never use tiny labels, needless capitals or one accented word in place of hierarchy.
 
-**Copy.** Name actions from the user's task, not implementation internals. Keep the same vocabulary across controls and confirmations. Use plain verbs and sentence case; labels describe outcomes, not decoration. Empty states offer a relevant next action; errors identify the failed action and available recovery. Reuse its existing control rather than repeating the action in text or adding another button; do not invent a recovery that cannot work.
+**Copy.** Name actions after the user's task, not implementation internals, with one vocabulary across controls and confirmations. Use plain verbs and sentence case; labels describe outcomes. An empty state offers the relevant next action. An error names the failed action and the recovery that exists, beside its existing control; never repeat the action in text or invent a recovery that cannot work.
 
 | Weak                   | Useful                                                            |
 | ---------------------- | ----------------------------------------------------------------- |
-| `Submit`               | `Save changes` → `Changes saved`                                  |
+| `Submit`               | `Save changes`, then `Changes saved`                              |
 | `Something went wrong` | `Couldn't save.` beside the existing retry action; keep the draft |
 | `No data`              | `No notes yet` beside the existing create action                  |
 
-**Alignment.** Give related headings, search, pinned rows, dividers and records one owning grid/inset. Headers and row contents share columns; action columns stay fixed when labels wrap or are absent. Use the same component/size variant for equivalent controls: icon box/stroke, hit target, control height, baseline and spacing. Pinned content stays outside the scroll area; borders do not jump while scrolling. Fix the owning layout/component, not per-instance offsets; matching boxes alone does not establish optical alignment or legibility. Trace the cause before applying these repairs:
+**Alignment.** Related headings, search, pinned rows, dividers and records share one grid and inset, and headers share columns with row contents. Action columns stay fixed when labels wrap or are missing. Equivalent controls share component and size: icon box, stroke, hit target, height, baseline and spacing. Pinned content stays outside the scroll area, and borders stay still while scrolling. Fix the owning layout or component, never one instance's offset; equal boxes alone prove neither optical alignment nor legibility. Trace the cause first:
 
-| Defect                             | Check                                         | Owning repair                                                                                      |
-| ---------------------------------- | --------------------------------------------- | -------------------------------------------------------------------------------------------------- |
-| Squashed icon/avatar               | Fixed-size flex child shrinks                 | Preserve its canonical box with `shrink-0`                                                         |
-| Trailing action disappears         | Content track refuses to shrink               | `min-w-0` on content; `shrink-0` on the control, or a shrinkable grid track                        |
-| Wrapped rows look adrift           | Center alignment against variable-height text | Consistent, deliberate top/baseline alignment                                                      |
-| Identifiers look identical         | Truncation hides the distinguishing segment   | Preserve that segment; expose the full value through an existing keyboard/touch-accessible surface |
-| Counts shift during updates        | Proportional digits/inconsistent formatting   | `tabular-nums` + consistent locale/units                                                           |
-| Accents/tall scripts clip          | Tight line height or text-box clipping        | Fix the owning type-scale/overflow choice; don't shrink the font to fit                            |
-| Missing metadata leaves separators | Empty optional slots still render             | Omit orphaned separators/lines; reserve space only when the layout needs it                        |
+| Defect                             | Cause                                   | Repair                                                                             |
+| ---------------------------------- | --------------------------------------- | ---------------------------------------------------------------------------------- |
+| Squashed icon or avatar            | A fixed-size flex child shrinks         | `shrink-0` keeps its canonical box                                                 |
+| Trailing action disappears         | The content track refuses to shrink     | `min-w-0` on the content and `shrink-0` on the control, or a shrinkable grid track |
+| Wrapped rows look adrift           | Centering against text of varied height | One deliberate top or baseline alignment                                           |
+| Identifiers look identical         | Truncation hides the distinct part      | Keep that part; show the full value on an existing keyboard and touch surface      |
+| Counts shift during updates        | Proportional digits or mixed formats    | `tabular-nums` with consistent locale and units                                    |
+| Accents or tall scripts clip       | Tight line height or text-box clipping  | Fix the owning type scale or overflow; never shrink the font to fit                |
+| Missing metadata leaves separators | Empty optional slots still render       | Omit orphaned separators and lines; reserve space only when layout needs it        |
 
 **Prevent before rejecting.** When the app already knows an action is not allowed, such as a missing permission, a referenced record or invalid input, disable or hide the control and show the reason beside it. Never let the user act and then show an error the app can predict.
 
-**Motion.** Explain change without delaying input or moving content just for decoration. Reuse existing tokens/components; no new library for a fade or universal curve, duration, bounce or press scale. Show press, pending, success and failure through the existing primitives. Where no primitive sets the easing, use ease-out for entrances, ease-in-out for morphs and linear only for elapsed progress. Start an entrance near its resting size, never from zero. Keep a dismissible surface mounted through its exit, reverse its entry path, and move its panel, backdrop and content together while unrelated chrome stays still. Delay a loader so fast results never flash it, and size it like the final content. List transition properties explicitly; never `transition-all`. Delay the first tooltip, then open neighboring ones at once.
-
-| Interaction                            | Treatment                                                                                          |
-| -------------------------------------- | -------------------------------------------------------------------------------------------------- |
-| Typing, shortcuts, frequent navigation | Immediate response; no decorative movement                                                         |
-| Trigger-anchored surface               | Enter/exit from its trigger; a centered unanchored modal keeps a centered origin                   |
-| Rapid toggle/reversal                  | Retarget from the visible state; no input lock, stale-target snap or wait for the prior transition |
-| Drag/gesture                           | Follow the pointer; preserve the existing primitive's capture, cancellation and release behavior   |
-| Reduced motion                         | Preserve feedback through a suitable static or gentle non-spatial equivalent                       |
-
-Use responsive entry easing and brief existing durations. Simple retargetable states suit transitions; gestures can use the existing spring. Prefer transforms and opacity where appropriate, but CSS and WAAPI do not guarantee compositor execution. Profile observed performance problems, not every animation. Inspect rapid repetition, reversal and reduced motion, not only the final frame.
+**Motion.** Motion explains a change; it never delays input or moves content for decoration. Reuse existing tokens and components: no new library for a fade, and no universal curve, duration, bounce or press scale. Show press, pending, success and failure through the existing primitives.
 
-**Access and responsiveness.** Preserve the complete task on phones, not merely stacked desktop panes. Keep essential actions reachable with keyboard, touch and zoom. Use semantic structure, accessible names, visible focus, logical order and deliberate focus return. Inspect long/duplicate content, overflow, contrast and relevant failure/permission states. Do not remove an accessible affordance to satisfy visual minimalism.
+- Use brief existing durations and responsive entry easing. Where no primitive sets the easing, use ease-out for entrances, ease-in-out for morphs and linear only for elapsed progress.
+- An entrance starts near its resting size, never from zero. A dismissible surface stays mounted through its exit and reverses its entry path; its panel, backdrop and content move together while unrelated chrome stays still.
+- A surface anchored to a trigger enters and exits from it; a centered unanchored modal keeps a centered origin.
+- Typing, shortcuts and frequent navigation respond at once, without decorative movement. A rapid toggle or reversal retargets from the visible state, with no input lock, stale-target snap or wait for the earlier transition.
+- A drag follows the pointer and keeps the primitive's capture, cancel and release behavior. Reduced motion keeps the feedback with a static or gentle non-spatial equivalent.
+- Delay a loader so fast results never flash it, and size it like the final content. List transition properties; never `transition-all`. Delay the first tooltip, then open neighbors at once.
+- Transitions suit simple states that retarget; gestures can use the existing spring. Prefer transforms and opacity, but neither CSS nor WAAPI guarantees compositor execution. Profile only an observed performance problem.
+- Inspect rapid repetition, reversal and reduced motion in slowed intermediate frames for jumps and stretched text, not only the final frame.
 
-| Mobile defect                                 | Check                                                                                                |
-| --------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
-| Hover remains after tap                       | Capability-aware styles; inspect the framework's handling before adding another gate                 |
-| Input zoom/wrong keyboard                     | Readable input sizing + correct input type/mode; never disable browser zoom                          |
-| Bottom controls disappear                     | Real browser chrome, software keyboard and safe areas; appropriate supported viewport sizing/insets  |
-| Drag blocks scrolling/content can't be copied | Scope gesture/selection restrictions to their owner; preserve scrolling, zoom and selectable content |
+**Access and phones.** The whole task works on a phone, not only stacked desktop panes, and essential actions stay reachable with keyboard, touch and zoom. Use semantic structure, accessible names, visible focus, logical order and deliberate focus return. Inspect long and duplicate content, overflow, contrast, and the failure and permission states that apply. Never remove an accessible affordance for minimalism.
 
-Touch and mouse can coexist; do not infer capabilities from user-agent strings or viewport width. No blanket suppression of overscroll, selection or native feedback without a demonstrated need and working replacement. Emulation verifies selected layout cases, not every phone behavior: affected device-specific keyboard/viewport/gesture contracts need target-device proof before completion.
+- Hover that stays after a tap needs capability-aware styles; read the framework's handling before you add another gate.
+- Inputs use a readable size and the right input type and mode; never disable browser zoom.
+- Bottom controls survive real browser chrome, the software keyboard and safe areas, with supported viewport units and insets.
+- Scope gesture and selection limits to their owner, and keep scrolling, zoom and selectable content.
+- Touch and mouse coexist: never infer capabilities from the user agent or the viewport width. Add no blanket suppression of overscroll, selection or native feedback without a shown need and a working replacement.
+- Emulation verifies selected layout cases, not every phone behavior: an affected device-specific keyboard, viewport or gesture contract needs proof on the target device.
 
 ## Creative mode
 
-Work as the design lead of a studio whose clients reject anything templated, and aim at the level of an award-winning site, not a tidy product page. Every choice of palette, type, layout and motion comes from this brief.
+Work as the design lead of a studio whose clients reject anything templated, and aim at an award-winning site, not a tidy product page. Every choice of palette, type, layout and motion comes from this brief.
 
-**Ground it.** Name the subject, the audience and the page's one job before designing. Take the visual language from the subject's world: its materials, tools, documents, places, times of day and vernacular. The brief's data is raw material for an idea, not content to lay out; write copy that names concrete capabilities and outcomes, never selling filler.
+**Ground it.** Before designing, name the subject, the audience and the page's one job. Take the visual language from the subject's world: its materials, tools, documents, places, times of day and vernacular. The brief's data is raw material for an idea, not content to lay out. Copy names concrete capabilities and outcomes, never selling filler.
 
-**Concept first.** Before any system or code, write three concepts that differ in structure, not in palette. Each is one paragraph: the big idea in one sentence; the metaphor or artifact from the subject's world; the structure it gives the page, such as a clock running from night to morning, a document being read, a journey or one interactive object; the signature moment; the motion; and the visual world of type, color, texture and imagery. Score each from 1 to 5 on three questions: would a viewer remember it tomorrow, could it exist for no other subject, does it make the reader act. Discard any concept whose structure is hero, features, list and form. Build the winner whole, with the full canvas, display typefaces chosen for the subject from Fontshare or Google Fonts, and canvas or SVG where the idea needs them; never retreat toward a safe page while building.
+**Concept first.** Before any system or code, write three concepts that differ in structure, not palette. Each is one paragraph: the big idea in one sentence; the metaphor or artifact from the subject's world; the structure it gives the page, such as a clock from night to morning, a document being read, a journey or one interactive object; the signature moment; the motion; and the visual world of type, color, texture and imagery. Score each from 1 to 5: would a viewer remember it tomorrow, does it belong to this subject alone, does it make the reader act. Discard any concept built as hero, features, list and form. Build the winner whole: the full canvas, display typefaces from Fontshare or Google Fonts chosen for the subject, and canvas or SVG where the idea needs them. Never retreat toward a safe page while building.
 
-**Plan, then challenge the plan.** Then write a compact system for the chosen concept: four to six named colors with roles (canvas, ink, atmosphere, action), one or two clearly distinct typefaces with roles and a type scale, and a layout concept with alignment. Sketch three different compositions as ASCII wireframes, not three palettes, and pick one. Then ask what you would produce for any similar brief; revise every part of the plan that matches it, and say what changed.
+**Plan, then challenge it.** Write a compact system: four to six named colors with roles (canvas, ink, atmosphere, action), one or two distinct typefaces with roles and a type scale, and a layout concept with its alignment. Sketch three compositions as ASCII wireframes, not three palettes, and pick one. Then ask what you would produce for any similar brief, change every part of the plan that matches it, and say what changed.
 
-**Defaults to avoid.** These appear whatever the subject, so they read as generated: a cream canvas with a serif display and a clay accent; near-black with one acid accent; broadsheet hairlines with zero radius; identical rounded cards with soft shadows and gradient washes; all-caps eyebrows above headings, middle-dot meta strings, a monospace face for labels, `→` on every link; one emphasized word in a headline; numbering on content that is no sequence. Also the generated launch-page skeleton: hero, feature table, ranked list, logo row, email form, each section opened by a heading on the left and a grey paragraph on the right; a pale sage or off-white canvas with navy ink. Use one only when the brief asks for it.
+**Defaults to avoid** unless the brief asks for one, because they appear whatever the subject and read as generated:
 
-**Compose.** Build the page around one artifact from the subject's world, shown as it lives there: the message as it arrives, the object as it is used, the document as it is read. Invent the page's structure from the story that artifact tells, not from a section template, and give the product a mark people remember. Open with the most characteristic thing in its best form: a headline, an image, a live demo or an interaction, not a big number with a gradient by default. Own the grid: deliberate spans, overlaps and whitespace, with repeated layouts only for content with equal roles. Alternate dense demonstrations with quiet reading passages. Let typography carry the personality, as an active visual element, with body lines under 75 characters. Spend boldness on one memorable signature, keep everything around it quiet, and remove one more element before you finish.
+- a cream canvas with a serif display and a clay accent; near-black with one acid accent; navy ink on pale sage or off-white;
+- broadsheet hairlines with zero radius; identical rounded cards with soft shadows and gradient washes;
+- all-caps eyebrows, middle-dot meta strings, a monospace label face, `→` on every link, one emphasized headline word, and numbering on content that is no sequence;
+- the launch-page skeleton: hero, feature table, ranked list, logo row and email form, each section a heading on the left and a grey paragraph on the right.
 
-**Imagery and texture.** Make subject-specific assets with one consistent light, material, palette and crop; keep text and controls in code. Take texture from the subject's real materials, never a universal grain or grid overlay. Never present a generated picture or invented testimonial as evidence.
+**Compose.** Build the page around one artifact from the subject's world, shown as it lives there: the message as it arrives, the object in use, the document as it is read. Take the structure from that artifact's story, not a section template, and give the product a mark people remember. Open with the most characteristic thing in its best form: a headline, an image, a live demo or an interaction, not a big number with a gradient by default. Own the grid with deliberate spans, overlaps and whitespace, and repeat a layout only for content with equal roles. Alternate dense demonstrations with quiet reading passages. Typography carries the personality as an active visual element, with body lines under 75 characters. Spend boldness on one signature, keep the rest quiet, and remove one more element before you finish.
 
-**Motion.** Use motion to explain: a cause and its effect, a before and after, a process in order, not content fading in. Choreograph one orchestrated moment, such as the page load or one reveal, instead of fade-up entrances on every section. Before coding a sequence, write its purpose, focal order, movement, easing, duration, overlap and resting moment. Animate interactions from their spatial origin and keep them interruptible. Bind scroll storytelling to scroll progress without hijacking scrolling, and keep the first viewport readable and actionable before any animation runs. Every motion has a complete reduced-motion and static version; stop offscreen animation. For a video, storyboard timed keyframes with reading holds, persistent objects and deterministic frames, and check text at the size it plays.
+**Imagery and texture.** Make assets for the subject with one consistent light, material, palette and crop, and keep text and controls in code. Take texture from the subject's real materials, never a universal grain or grid overlay. Never present a generated picture or an invented testimonial as evidence.
 
-**Critique.** Capture desktop and phone, and slowed motion frames; compare them with the plan and with the defaults above. Batch the repairs and recheck once. The quality floor is silent: responsive to phones, visible keyboard focus, sufficient contrast and reduced motion respected.
+**Motion.** Motion explains a cause and its effect, a before and after, or a process in order; it never only fades content in. Choreograph one moment, such as the page load or one reveal, instead of fade-ups on every section. Before coding a sequence, write its purpose, focal order, movement, easing, duration, overlap and resting moment. Animate interactions from their spatial origin and keep them interruptible. Scroll storytelling follows scroll progress without hijacking it, and the first viewport reads and acts before any animation runs. Every motion has a complete reduced-motion and static version, and offscreen animation stops. A video gets a storyboard of timed keyframes with reading holds, persistent objects and deterministic frames, and its text is checked at playback size.
+
+**Critique.** Capture desktop, phone and slowed motion frames, and compare them with the plan and the defaults above. Batch the repairs and recheck once. The quality floor holds without mention: phone layouts, visible keyboard focus, enough contrast and reduced motion.
 
 ## Prototype
 
-**Try the question.** Build one rough representative screen or interaction in the existing host with realistic data. Inspect enough to make the trial trustworthy, then show it to the user before merge-readiness work. Label stubs and limits; a conceptual sketch is sufficient only when execution is unnecessary, never proof of working software. Set a short first-preview budget; show a partial result or blocker rather than expanding unseen. No production completeness or polished gallery first.
+**Try the question.** Build one rough representative screen or interaction in the existing host with realistic data. Inspect enough to trust the trial, then show it before any merge-readiness work. Label stubs and limits; a sketch is enough only when execution is unnecessary, and it never proves working software. Set a short budget for the first preview, and show a partial result or a blocker rather than growing unseen. Build no production completeness or polished gallery first.
 
-**Use the findings.** For layout questions, compare hierarchy or interaction, not color-only variants. Compare several directions at the mockup stage; add real attempts only for unresolved uncertainty, feedback or an explicit request. A style question can compare style. Keep useful comparisons; discard/rebuild freely and combine compatible strengths, not incompatible mechanisms. Test the weakest assumption while it can change the choice. A settled direction needs no manufactured taste question or exploration round.
+**Use the findings.** For a layout question, compare hierarchy or interaction, not color variants; a style question can compare style. Compare several directions as mockups, and build real attempts only for open uncertainty, feedback or an explicit request. Keep useful comparisons, discard and rebuild freely, and combine compatible strengths, never incompatible mechanisms. Test the weakest assumption while it can still change the choice. A settled direction needs no invented taste question or exploration round.
 
 ## Verify and show
 
-**Inspect retained UI.** Open actual captures at the sizes needed for the task. Compare related edges, columns, baselines and equivalent controls across rows/screens—not just successful clicks. Use realistic long names/URLs, translated labels, Unicode, missing fields and relevant 0/1/many records at the actual container width. Respect schema/API limits; never add a validation limit to make layout pass. Mix cases across rows. Check selected/focus/error states and scrolling; a clean default row can hide misalignment. Inspect hierarchy, density, legibility and clipping. Exercise the relevant keyboard/touch, narrow/wide, zoom and focus-return journeys; run axe where applicable. A clean scan does not prove contrast or usability. Inspect meaningful video frames and sequence; a playable file is not proof of a good composition. Batch relevant inspection/repairs; recheck affected views rather than restart a whole audit after each micro-edit. Visible misalignment, inconsistent controls or redundant elements remain defects even when types/tests pass; fix them before claiming acceptance. Inspect motion in slowed intermediate frames for jumps and stretched text.
+**Inspect retained UI** in real captures at the sizes the task needs:
 
-**Generic output.** Check every capture for these tells and fix each one before showing it:
+- Compare related edges, columns, baselines and equivalent controls across rows and screens, not only successful clicks.
+- Use long names and URLs, translated labels, Unicode, missing fields and 0, 1 and many records, mixed across rows at the real container width. Respect schema and API limits; never add a validation limit to make a layout pass.
+- Check selected, focus, error and scrolling states, and the hierarchy, density, legibility, contrast and clipping.
+- Walk the keyboard, touch, narrow, wide, zoom and focus-return journeys that apply, and run axe where it applies; a clean scan proves neither contrast nor usability.
+- Inspect video frames in sequence; a playable file is not a good composition.
 
-| Tell                                            | Check                                                    |
-| ----------------------------------------------- | -------------------------------------------------------- |
-| Every section is a bordered card with an icon   | Each container has a grouping purpose; remove the others |
-| Everything has equal prominence                 | The blurred capture still shows the primary content      |
-| Uniform gaps                                    | Unrelated groups sit farther apart than related items    |
-| Each tile gets its own accent color             | Every hue names a state, series or action                |
-| An emphasized headline word or decorative label | Removing the treatment loses no meaning, so remove it    |
-| Charts, rings or dots without readable data     | Each graphic shows values, units or state                |
-| Generic copy such as "seamless" or "Learn more" | Each label names its capability or the click's outcome   |
-| Content that waits for an entrance animation    | The first frame is readable and actionable               |
+Batch repairs and recheck only the affected views instead of restarting the audit after each small edit. Misalignment, inconsistent controls and redundant elements stay defects when types and tests pass; fix them before you claim acceptance.
 
-**Show the design.** Use inspected screenshots for layout and short video for behavior. Compare at consistent sizes with states needed for the decision; no variant switcher just to see the options. A visual must add spatial or interactive information, not reproduce prose, a file list or a fake runtime screenshot. Embed useful existing captures in the render rather than recreate them. For diagrams, review pages and rendered answers, follow Visual explanations below. Use the user's theme and verify the actual browser color preference. Preserve useful media and retire settled attempts; environment decides how long previews run.
+**Generic output.** Fix each of these tells before you show a capture:
 
-**Review surfaces.** Open on the outcome the user needs to judge, with technical detail available on demand. Group by changed behavior, not files or agent stages. A selected example, diagram or diff must reveal its scope; never make curated evidence look like complete coverage. Do not build a custom review dashboard when existing captures and the PR can answer the question. A design-skill edit is not a product-screen change.
+| Tell                                            | Check                                                  |
+| ----------------------------------------------- | ------------------------------------------------------ |
+| Every section is a bordered card with an icon   | Each container groups something; remove the others     |
+| Everything has equal prominence                 | The blurred capture still shows the primary content    |
+| Uniform gaps                                    | Unrelated groups sit farther apart than related items  |
+| Each tile gets its own accent color             | Every hue names a state, series or action              |
+| An emphasized headline word or decorative label | Removing the treatment loses no meaning, so remove it  |
+| Charts, rings or dots without readable data     | Each graphic shows values, units or state              |
+| Generic copy such as "seamless" or "Learn more" | Each label names its capability or the click's outcome |
+| Content that waits for an entrance animation    | The first frame is readable and actionable             |
 
-## Visual explanations
+**Show the design** with inspected screenshots for layout and short video for behavior, at consistent sizes, with the states the decision needs, in the user's theme and the browser's real color preference. Embed existing captures instead of recreating them, and build no variant switcher only to view options. Keep useful media and retire settled attempts; environment decides how long previews run. A review surface opens on the outcome the user judges, with technical detail on demand, and groups by changed behavior, not by file or agent stage. Build no custom dashboard when captures and the pull request answer the question. A design-skill edit is not a product-screen change.
 
-These rules cover diagrams, review pages and rendered agent answers; the pair prompt decides when a reply needs a render. A render replaces the text it shows; it never repeats it.
+## Visual explanations
 
-**Pick the exhibit from the question.**
+These rules cover diagrams, review pages and rendered agent answers; the pair prompt decides when a reply needs a render. A render adds spatial or interactive information and replaces the text it shows; it never redraws prose, a file list or a fake runtime screenshot.
 
 | The reader asks                      | Exhibit                                                        |
 | ------------------------------------ | -------------------------------------------------------------- |
@@ -171,30 +184,18 @@ These rules cover diagrams, review pages and rendered agent answers; the pair pr
 | Which option is better?              | Options side by side at the same size and with the same data   |
 | What will a video show?              | Storyboard of chapter frames, the outcome frame marked         |
 
-When none fits, choose the form that matches the data's shape, not the first card layout that comes to mind. Draw a list as a list.
-
-- **One message.** Each page answers one question. Its title states the conclusion, such as "The catalog loads 26 times faster", not the topic.
-- **One dominant element.** Size, weight and position show importance. Mute the context and make secondary detail smaller.
-- **Color means something.** Use the theme's status colors only for states and the chart colors only for series. Keep one accent, and never color for decoration.
-- **Label directly.** Put names and values on the data instead of a distant legend. Show units, and use one scale per comparison.
-- **Real content.** Use real names, numbers and captures. Show the scope, so a sample never looks like full coverage.
+When none fits, choose the form that matches the data's shape, not the first card layout; draw a list as a list.
 
-- **Grid and rhythm.** Align to one grid. Use a spacing scale of 4, 8, 12 and 16 pixels, two or three type sizes, and one corner radius.
-- **Little text.** Labels and captions stay under twelve words. A visual holds no paragraphs.
-- **Small multiples.** Compare several cases with repeated small exhibits on the same scale, rather than one crowded chart.
-- **Both themes and widths.** Use the host's theme variables, check light and dark, and keep the page readable at phone width.
-- **Inspect before showing.** Look at the rendered page for clipping, overlap, contrast and empty areas, and fix them first.
+- **One message.** Each page answers one question, and its title states the conclusion, such as "The catalog loads 26 times faster", not the topic.
+- **One dominant element.** Size, weight and position show importance; mute the context and shrink secondary detail.
+- **Color.** Use the theme's status colors only for states and its chart colors only for series. Keep one accent and no decorative color.
+- **Labels.** Put names, values and units on the data instead of a distant legend, with one scale per comparison. Repeat small exhibits on one scale rather than crowd one chart.
+- **Real content.** Use real names, numbers and captures, and show the scope, so a sample never looks like full coverage.
+- **Grid.** Align to one grid with 4, 8, 12 and 16 pixel spacing, two or three type sizes and one corner radius. Labels and captions stay under twelve words, and a visual holds no paragraphs.
+- **Check.** Use the host's theme variables, check light, dark and phone width, and fix clipping, overlap, contrast and empty areas before you show it.
 
-**Avoid** these:
-
-- A table or bullet list redrawn as styled boxes.
-- A card, badge or icon for every fact.
-- Gradients, shadows and illustrations that carry no information.
-- Crossing links, when an ordered list or lanes would show the same relation.
-- A visual that repeats the text around it.
+**Avoid** a table or list redrawn as styled boxes, and a card, badge or icon for every fact. Avoid gradients, shadows and illustrations that carry no information, crossing links where an ordered list or lanes show the same relation, and a visual that repeats the text around it.
 
 ## Image assets
 
-Use image generation only for a needed illustrative asset, atmosphere, texture or icon exploration—not ordinary text, exact diagrams or fake working UI. Use the native tool exposed by the harness; no invented invocation or replacement API client when unavailable. Report missing capability honestly.
-
-Describe purpose, placement, composition, palette and intended size and aspect ratio. For edits, supply the real source and state what remains unchanged. Generate only what the chosen direction needs; prefer existing icons or CSS when they express the job precisely. Inspect the returned asset at its intended size for crop, text and edge artifacts, contrast and fit. Preserve useful originals and identify generated assets as such; they are not runtime or browser proof. Keep only used assets in product source.
+Generate an image only for a needed illustration, atmosphere, texture or icon exploration, never for text, exact diagrams or fake working UI. Use the harness's native tool; when it is missing, say so instead of inventing an invocation or an API client. Describe the purpose, placement, composition, palette, size and aspect ratio; for an edit, supply the real source and state what stays unchanged. Generate only what the chosen direction needs, and prefer existing icons or CSS when they fit. Inspect the result at its real size for crop, text, edge artifacts, contrast and fit. Keep useful originals, label generated assets as generated, never count them as runtime or browser proof, and keep only used assets in product source.