@dryui/ui 2.0.2 → 3.0.0

package/dist/accordion/accordion-button-trigger.svelte

@@ -19,6 +19,7 @@
 	type="button"
 	--dry-btn-justify="space-between"
 	--dry-btn-radius="0"
+	--dry-btn-active-transform="none"
 	aria-expanded={itemCtx.open}
 	aria-controls={itemCtx.contentId}
 	data-state={itemCtx.open ? 'open' : 'closed'}

package/dist/button/button.svelte

@@ -179,6 +179,7 @@
 		--_dry-btn-color: var(--dry-btn-color, var(--_dry-btn-on-accent));
 		--_dry-btn-border: var(--dry-btn-border, transparent);
 		--_dry-btn-radius: var(--dry-btn-radius, var(--dry-radius-md));
+		--_dry-btn-active-transform: var(--dry-btn-active-transform, scale(0.98));
 		--_dry-btn-padding-x: var(--dry-btn-padding-x, var(--dry-space-4));
 		--_dry-btn-padding-y: var(--dry-btn-padding-y, var(--dry-space-2_5));
 		--_dry-btn-font-size: var(
@@ -236,7 +237,7 @@
 		}
 
 		&:active:not([data-disabled]) {
-			transform: scale(0.98);
+			transform: var(--_dry-btn-active-transform);
 		}
 
 		&[data-disabled] {

package/dist/color-picker/color-picker-channel-input.svelte

@@ -59,7 +59,6 @@
 		font-family: var(--dry-font-mono);
 		color: var(--dry-color-text-strong);
 		background: var(--dry-color-bg-raised);
-		/* dryui-allow solid-border-on-raised: numeric color channel inputs use field affordance inside a raised picker. */
 		border: 1px solid var(--dry-color-stroke-strong);
 		border-radius: var(--dry-radius-md);
 		transition:

package/dist/combobox/combobox-content.svelte

@@ -94,7 +94,6 @@
 			max-content
 		);
 		background: var(--dry-color-bg-overlay);
-		/* dryui-allow solid-border-on-raised: popover listbox keeps a crisp edge for option scanning. */
 		border: 1px solid var(--dry-color-stroke-weak);
 		border-radius: var(--dry-radius-md);
 		box-shadow: var(--dry-shadow-lg);

package/dist/file-select/file-select-root.svelte

@@ -4,6 +4,8 @@
 
 	interface Props {
 		value?: string | null;
+		accept?: string | undefined;
+		directory?: boolean | undefined;
 		onrequest?: (() => Promise<string | null>) | undefined;
 		onchange?: ((value: string | null) => void) | undefined;
 		disabled?: boolean | undefined;
@@ -12,6 +14,8 @@
 
 	let {
 		value = $bindable(null),
+		accept = '',
+		directory = true,
 		onrequest,
 		onchange,
 		disabled = false,
@@ -19,20 +23,56 @@
 	}: Props = $props();
 
 	let loading = $state(false);
+	let fallbackInputEl: HTMLInputElement | null = null;
+
+	function commitValue(nextValue: string | null) {
+		if (nextValue === null) return;
+
+		value = nextValue;
+		onchange?.(nextValue);
+	}
+
+	function getFallbackInputValue(files: FileList | null): string | null {
+		const file = files?.[0];
+		if (!file) return null;
+
+		const directoryName = file.webkitRelativePath.split('/').find(Boolean);
+		return directory && directoryName ? directoryName : file.name;
+	}
+
+	function openFallbackInput() {
+		if (!fallbackInputEl) return;
+
+		fallbackInputEl.value = '';
+		fallbackInputEl.click();
+	}
+
+	function attachFallbackInput(node: HTMLInputElement) {
+		fallbackInputEl = node;
+		return () => {
+			if (fallbackInputEl === node) {
+				fallbackInputEl = null;
+			}
+		};
+	}
 
 	async function defaultRequest(): Promise<string | null> {
 		if (typeof window === 'undefined') return null;
-		if (!('showDirectoryPicker' in window)) return null;
-		try {
-			const handle = await (
-				window as unknown as {
-					showDirectoryPicker: (opts: { mode: string }) => Promise<{ name: string }>;
-				}
-			).showDirectoryPicker({ mode: 'read' });
-			return handle.name;
-		} catch {
-			return null;
+		if (directory && 'showDirectoryPicker' in window) {
+			try {
+				const handle = await (
+					window as unknown as {
+						showDirectoryPicker: (opts: { mode: string }) => Promise<{ name: string }>;
+					}
+				).showDirectoryPicker({ mode: 'read' });
+				return handle.name;
+			} catch (error) {
+				if (error instanceof DOMException && error.name === 'AbortError') return null;
+			}
 		}
+
+		openFallbackInput();
+		return null;
 	}
 
 	async function request() {
@@ -41,15 +81,17 @@
 		try {
 			const pick = onrequest ?? defaultRequest;
 			const result = await pick();
-			if (result !== null) {
-				value = result;
-				onchange?.(result);
-			}
+			commitValue(result);
 		} finally {
 			loading = false;
 		}
 	}
 
+	function handleFallbackInputChange(event: Event & { currentTarget: HTMLInputElement }) {
+		commitValue(getFallbackInputValue(event.currentTarget.files));
+		event.currentTarget.value = '';
+	}
+
 	function clear() {
 		if (disabled) return;
 		value = null;
@@ -72,10 +114,29 @@
 </script>
 
 <div data-file-select data-disabled={disabled || undefined}>
+	<input
+		{@attach attachFallbackInput}
+		type="file"
+		{accept}
+		webkitdirectory={directory}
+		disabled={disabled || undefined}
+		aria-hidden="true"
+		tabindex="-1"
+		class="file-select-hidden-input"
+		onchange={handleFallbackInputChange}
+	/>
+
 	{@render children()}
 </div>
 
 <style>
+	.file-select-hidden-input {
+		display: none;
+		position: absolute;
+		height: 0;
+		overflow: hidden;
+	}
+
 	[data-file-select] {
 		container-type: inline-size;
 		display: grid;
@@ -85,7 +146,6 @@
 		padding: var(--dry-space-2) var(--dry-space-3);
 		font-family: var(--dry-font-sans);
 		background: var(--dry-color-bg-raised);
-		/* dryui-allow solid-border-on-raised: file select is a form control and needs a persistent field edge. */
 		border: 1px solid var(--dry-color-stroke-strong);
 		border-radius: var(--dry-radius-md);
 		transition:

package/dist/file-select/file-select-root.svelte.d.ts

@@ -1,6 +1,8 @@
 import type { Snippet } from 'svelte';
 interface Props {
     value?: string | null;
+    accept?: string | undefined;
+    directory?: boolean | undefined;
     onrequest?: (() => Promise<string | null>) | undefined;
     onchange?: ((value: string | null) => void) | undefined;
     disabled?: boolean | undefined;

package/dist/file-upload/file-upload-item.svelte

@@ -27,7 +27,6 @@
 		font-family: var(--dry-font-sans);
 		color: var(--dry-color-text-strong);
 		background: var(--dry-color-bg-raised);
-		/* dryui-allow solid-border-on-raised: uploaded file rows need a visible item boundary in dense lists. */
 		border: 1px solid var(--dry-color-stroke-weak);
 		border-radius: var(--dry-radius-md);
 	}

package/dist/internal/modal-content.svelte

@@ -106,9 +106,9 @@
 	/* ---------- Dialog (center) ---------- */
 
 	[data-modal-content][data-variant='dialog'] {
-		/* dryui-allow width */
+		/* dryui-allow width: resets native <dialog> sizing so the outer grid track owns the centered panel width. */
 		width: 100vw;
-		/* dryui-allow width */
+		/* dryui-allow width: paired with the width reset above. */
 		max-width: none;
 		display: grid;
 		grid-template-columns: min(90vw, var(--dry-dialog-max-width, 32rem));
@@ -172,9 +172,9 @@
 	/* ---------- AlertDialog (center) ---------- */
 
 	[data-modal-content][data-variant='alert-dialog'] {
-		/* dryui-allow width */
+		/* dryui-allow width: resets native <dialog> sizing so the outer grid track owns the centered panel width. */
 		width: 100vw;
-		/* dryui-allow width */
+		/* dryui-allow width: paired with the width reset above. */
 		max-width: none;
 		display: grid;
 		grid-template-columns: min(90vw, var(--dry-dialog-max-width, 32rem));
@@ -319,7 +319,6 @@
 
 	[data-modal-content][data-variant='drawer'][data-side='top'] [data-modal-panel] {
 		--_drawer-rest-transform: translateY(0);
-		/* dryui-allow symmetric-exit-animation: this is the off-canvas enter position for a top drawer, not the exit animation. */
 		--_drawer-enter-transform: translateY(-100%);
 		grid-row: 1;
 		height: var(--dry-drawer-size);
@@ -328,7 +327,6 @@
 
 	[data-modal-content][data-variant='drawer'][data-side='bottom'] [data-modal-panel] {
 		--_drawer-rest-transform: translateY(0);
-		/* dryui-allow symmetric-exit-animation: this is the off-canvas enter position for a bottom drawer, not the exit animation. */
 		--_drawer-enter-transform: translateY(100%);
 		grid-row: 2;
 		height: var(--dry-drawer-size);

package/dist/internal/picker-popover-content.svelte

@@ -82,7 +82,6 @@
 		margin: 0;
 		display: inline-grid;
 		padding: var(--dry-space-3);
-		/* dryui-allow solid-border-on-raised: date picker popovers need a clear calendar boundary. */
 		border: 1px solid var(--dry-color-stroke-weak);
 		border-radius: var(--dry-radius-lg);
 		background: var(--dry-color-bg-overlay);

package/dist/kbd/kbd.svelte

@@ -45,7 +45,7 @@
 		font-size: var(--dry-kbd-font-size);
 		font-weight: 600;
 		line-height: 1;
-		box-shadow: inset 0 -1px 0 color-mix(in srgb, var(--dry-color-text-strong) 10%, transparent);
+		box-shadow: inset 0 0 0 1px color-mix(in srgb, var(--dry-color-text-strong) 10%, transparent);
 		user-select: none;
 		white-space: nowrap;
 	}

package/dist/mega-menu/mega-menu-panel.svelte

@@ -117,7 +117,7 @@
 		border-radius: var(--dry-radius-lg, 0.5rem);
 		box-shadow: var(--dry-shadow-lg, 0 10px 15px -3px rgba(0, 0, 0, 0.1));
 		padding: var(--dry-space-4, 1rem);
-		/* dryui-allow width */
+		/* dryui-allow width: viewport cap for the anchored floating panel, not a child-layout sizing rule. */
 		max-inline-size: var(--dry-mega-menu-panel-max-width, min(92vw, 60rem));
 		display: grid;
 		grid-auto-flow: column;

package/dist/menubar/menubar-content.svelte

@@ -123,7 +123,6 @@
 
 		background: var(--dry-color-bg-overlay);
 		color: var(--dry-color-text-strong);
-		/* dryui-allow solid-border-on-raised: menu popover keeps a visible edge while floating above varied content. */
 		border: 1px solid var(--dry-color-stroke-weak);
 		border-radius: var(--dry-radius-popover);
 		box-shadow: var(--dry-shadow-overlay);

package/dist/menubar/menubar-root.svelte

@@ -82,7 +82,6 @@
 		gap: var(--dry-space-1);
 		padding: var(--dry-space-1);
 		background: var(--dry-color-bg-overlay);
-		/* dryui-allow solid-border-on-raised: menubar root presents a persistent command strip boundary. */
 		border: 1px solid var(--dry-color-stroke-weak);
 		border-radius: var(--dry-radius-lg);
 	}

package/dist/multi-select-combobox/multi-select-combobox-content.svelte

@@ -87,7 +87,6 @@
 		margin: 0;
 		grid-template-columns: minmax(anchor-size(inline), max-content);
 		background: var(--dry-color-bg-overlay);
-		/* dryui-allow solid-border-on-raised: popover menu keeps an explicit edge for contrast against busy app surfaces. */
 		border: 1px solid var(--dry-color-stroke-weak);
 		border-radius: var(--dry-radius-md);
 		box-shadow: var(--dry-shadow-lg);

package/dist/multi-select-combobox/multi-select-combobox-root-input.svelte

@@ -82,11 +82,16 @@
 	}
 
 	function selectValue(itemValue: string) {
-		if (disabled || value.includes(itemValue) || !canSelectValue(itemValue)) {
+		if (disabled || !canSelectValue(itemValue)) {
 			return false;
 		}
 
-		setSelectedValues([...value, itemValue]);
+		if (value.includes(itemValue)) {
+			setSelectedValues(value.filter((entry) => entry !== itemValue));
+		} else {
+			setSelectedValues([...value, itemValue]);
+		}
+
 		setQueryValue('');
 		activeItemId = '';
 		focusInput();
@@ -251,7 +256,6 @@
 		justify-content: start;
 		gap: var(--dry-space-1_5);
 		padding: var(--dry-space-2);
-		/* dryui-allow solid-border-on-raised: composite input needs a persistent field edge plus raised fill for token contrast. */
 		border: 1px solid var(--dry-color-stroke-strong);
 		border-radius: var(--dry-radius-md);
 		background: var(--dry-color-bg-raised);

package/dist/navigation-menu/navigation-menu-link.svelte

@@ -39,7 +39,6 @@
 	[data-nav-menu-link][data-active] {
 		background: var(--dry-color-fill-brand-weak);
 		color: var(--dry-color-text-brand);
-		box-shadow: inset 2px 0 0 var(--dry-color-stroke-selected);
 		font-weight: 600;
 	}
 

package/dist/option-picker/option-picker-preview.svelte

@@ -87,6 +87,7 @@
 			var(--_preset-color) 58%,
 			color-mix(in srgb, black 12%, var(--_preset-color) 88%) 100%
 		);
+		/* dryui-allow inset-shadow: 1px top highlight + 1px bottom shadow give the preset color swatch a beveled material look. */
 		box-shadow:
 			inset 0 1px 0 color-mix(in srgb, white 22%, transparent),
 			inset 0 -1px 0 color-mix(in srgb, black 10%, transparent);

package/dist/rich-text-editor/rich-text-editor-toolbar-button-input.svelte

@@ -516,7 +516,6 @@
 		gap: var(--dry-space-2);
 		padding: var(--dry-space-2);
 		background: var(--dry-color-bg-overlay);
-		/* dryui-allow solid-border-on-raised: inline link editor is a small popover that needs a distinct edge. */
 		border: 1px solid var(--dry-rte-border);
 		border-radius: var(--dry-radius-md);
 		box-shadow: var(--dry-shadow-md);

package/dist/tags-input/tags-input-root.svelte

@@ -86,7 +86,6 @@
 	[data-part='root'] {
 		display: block;
 		padding: var(--dry-space-2);
-		/* dryui-allow solid-border-on-raised: tag editor is a form field with token chips on a raised input surface. */
 		border: 1px solid var(--dry-color-stroke-strong);
 		border-radius: var(--dry-radius-md);
 		background: var(--dry-color-bg-raised);

package/dist/toast/toast-root.svelte

@@ -108,7 +108,6 @@
 		}
 	}
 
-	/* dryui-allow ad-hoc-enter-keyframe: toast predates motion wrappers and keeps reduced-motion handling in this file. */
 	@keyframes slideIn {
 		from {
 			opacity: 0;

package/dist/toolbar/toolbar-root.svelte

@@ -89,7 +89,6 @@
 		gap: var(--dry-space-1);
 		padding: var(--dry-space-1);
 		background: var(--dry-color-bg-overlay);
-		/* dryui-allow solid-border-on-raised: toolbar chrome needs a visible control group boundary. */
 		border: 1px solid var(--dry-color-stroke-weak);
 		border-radius: var(--dry-radius-lg);
 	}

package/dist/tree/tree-item-label.svelte

@@ -51,8 +51,6 @@
 	[data-part='label'][data-selected] {
 		background: var(--dry-tree-item-selected-bg, var(--dry-color-fill-brand-weak));
 		color: var(--dry-tree-item-selected-color, var(--dry-color-text-brand));
-		box-shadow: inset 2px 0 0
-			var(--dry-tree-item-selected-indicator, var(--dry-color-stroke-selected));
 		font-weight: 600;
 	}
 </style>

package/dist/tree/tree-root.svelte

@@ -238,7 +238,6 @@
 		--dry-tree-item-hover-bg: var(--dry-color-fill);
 		--dry-tree-item-selected-bg: var(--dry-color-fill-brand-weak);
 		--dry-tree-item-selected-color: var(--dry-color-text-brand);
-		--dry-tree-item-selected-indicator: var(--dry-color-stroke-selected);
 		--dry-tree-icon-size: 1rem;
 	}
 </style>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dryui/ui",
-  "version": "2.0.2",
+  "version": "3.0.0",
   "description": "Zero-dependency styled Svelte 5 components with scoped styles and --dry-* CSS variable theming.",
   "author": "Rob Balfre",
   "license": "MIT",
@@ -817,14 +817,14 @@
     "check:publish-hygiene": "bun run check:publint && bun run check:attw"
   },
   "dependencies": {
-    "@dryui/primitives": "^2.0.2"
+    "@dryui/primitives": "^3.0.0"
   },
   "peerDependencies": {
-    "svelte": "^5.55.4"
+    "svelte": "^5.55.5"
   },
   "devDependencies": {
-    "@dryui/lint": "^0.7.1",
-    "svelte": "^5.55.4",
+    "@dryui/lint": "^1.0.0",
+    "svelte": "^5.55.5",
     "@sveltejs/package": "^2.5.7",
     "svelte-check": "^4.4.6",
     "typescript": "^6.0.3"

package/skills/dryui/SKILL.md

@@ -11,41 +11,45 @@ Zero-dependency Svelte 5 components. All imports from `@dryui/ui`. Requires a th
 
 ## UI Creation Pipeline
 
-DryUI work is explicit. Do the design thinking where the user can see it, then validate the result.
+DryUI work is explicit. Confirm contracts, build, then validate.
 
-1. **User brief** — capture audience, job-to-be-done, product/domain, constraints, and any existing design direction.
-2. **DESIGN.md identity** — read or create the local design identity before choosing components. Google-style `DESIGN.md` is a supported optional format, not a required dependency.
-3. **DryUI lookup/plan** — use `dryui info`, `dryui compose`, or MCP `ask` to confirm component contracts, tokens, layout rules, and recipes.
-4. **make-interfaces-feel-better polish intent pass** — state which polish details matter for this screen before implementation. This is an explicit planning step, not hidden taste.
-5. **Implementation** — build with DryUI components, Svelte 5, grid layout, tokens, and accessible composition.
-6. **Deterministic check** — run `dryui check [path]` or MCP `check` to catch contracts, accessibility, tokens, and CSS discipline.
-7. **Visual review** — run `dryui check --visual <url>` or MCP `check` with `visualUrl`; include the make-interfaces-feel-better rubric in the review intent.
-8. **Repair loop** — fix the highest-signal issues, then repeat deterministic check and visual review until the UI matches the brief.
+1. **User brief** — one line capturing what you are building and for whom.
+2. **DryUI lookup/plan** — use `dryui ask` or MCP `ask` to confirm component contracts, tokens, recipes, and accessibility notes before choosing components.
+3. **Implementation** — build with DryUI components, Svelte 5 runes, grid layout, `--dry-*` tokens, and accessible composition.
+4. **Deterministic check** — run `dryui check [path]` or MCP `check` to catch contract drift, accessibility regressions, token drift, and CSS discipline violations.
 
-Precedence when guidance conflicts:
+## Design guidance, critique, polish
 
-1. User intent and task constraints.
-2. Local `DESIGN.md` identity.
-3. DryUI component contracts, accessibility rules, and token/theming discipline.
-4. Official Svelte MCP guidance for Svelte and SvelteKit syntax/framework questions.
-5. make-interfaces-feel-better polish rubric.
+DryUI is zero-dependency components + tokens + contracts. It deliberately does NOT ship design opinion. For design-quality flows like brief, critique, polish, visual review, or anti-pattern detection, use [impeccable](https://impeccable.style), which is installed alongside DryUI by `dryui init` or via `npx impeccable skills install`.
+
+Invoke from your AI harness:
+
+- `/impeccable teach` — one-time: scaffold `PRODUCT.md` + `DESIGN.md`
+- `/impeccable craft` — design-then-build a feature
+- `/impeccable shape` — plan UX/UI before writing code
+- `/impeccable critique <target>` — UX design review
+- `/impeccable audit <target>` — a11y, performance, responsive checks
+- `/impeccable polish <target>` — final pass before shipping
+- Full catalog: https://impeccable.style/cheatsheet
+
+`PRODUCT.md` and `DESIGN.md` at the project root are impeccable-owned. DryUI tools do not read or write them. Anti-pattern detection: `npx impeccable detect <path-or-url>`.
 
 ## 1. Look Up Before You Write
 
 **Never guess a component API. Always verify first.**
 
-- Call `dryui info <component>` or `dryui compose "<query>"` before using any component for the first time. If MCP is available, `ask --scope component` and `ask --scope recipe` are equivalent.
-- Component APIs vary — `bind:value`, `bind:open`, `bind:checked` are NOT interchangeable
-- Compound vs simple, required parts, available props — all differ per component
-- If you skip the lookup, you'll write plausible-looking code that silently breaks
+- Call `dryui ask --scope component "<Component>"` or `dryui ask --scope recipe "<pattern>"` before using any component for the first time. MCP `ask` is the equivalent surface.
+- Component APIs vary. `bind:value`, `bind:open`, `bind:checked` are NOT interchangeable.
+- Compound vs simple, required parts, available props — all differ per component.
+- If you skip the lookup, you'll write plausible-looking code that silently breaks.
 
-The test: can you point to a `dryui info`, `dryui compose`, or `ask` call for every component or pattern in your output?
+The test: can you point to a `dryui ask` or MCP `ask` call for every component or pattern in your output?
 
 ## 2. Everything is Compound Until Proven Otherwise
 
 **Use `.Root`. Always check.**
 
-Most DryUI components are compound — they require `<Card.Root>`, not `<Card>`. The bare name silently fails or renders wrong. Assume compound; verify with `dryui info <Component>` or `ask --scope component`.
+Most DryUI components are compound. They require `<Card.Root>`, not `<Card>`. The bare name silently fails or renders wrong. Assume compound, verify with `ask --scope component`.
 
 ```svelte
 <!-- Wrong -->
@@ -54,7 +58,7 @@ Most DryUI components are compound — they require `<Card.Root>`, not `<Card>`.
 <Card.Root>content</Card.Root>
 ```
 
-Compound components are tracked in the manifest at `packages/mcp/src/component-catalog.ts`. Verify with `dryui info <Component>` or `ask --scope component` before you assume a bare name works, then use `.Root` and wrap the parts inside it.
+Compound components are tracked in the manifest at `packages/mcp/src/component-catalog.ts`. Verify with `ask --scope component` before you assume a bare name works, then use `.Root` and wrap the parts inside it.
 
 The test: every compound component in your markup uses `.Root`, and its parts are wrapped inside it. See `rules/compound-components.md` for the parts reference.
 
@@ -62,11 +66,11 @@ The test: every compound component in your markup uses `.Root`, and its parts ar
 
 **Import it. Use its tokens. Don't fight it.**
 
-- Import `@dryui/ui/themes/default.css` (and `dark.css`) before any component use
-- Use `--dry-color-*` and `--dry-space-*` tokens — never hardcoded colors or spacing
-- Don't add decorative CSS (gradients, shadows, colored borders) — the theme handles appearance
-- Override semantic tokens (Tier 2) in `:root`, not component tokens (Tier 3)
-- Prefer `<html class="theme-auto">` — use `data-theme="light|dark"` only for explicit overrides
+- Import `@dryui/ui/themes/default.css` (and `dark.css`) before any component use.
+- Use `--dry-color-*` and `--dry-space-*` tokens. Never hardcode colors or spacing.
+- Don't add decorative CSS (gradients, shadows, colored borders). The theme handles appearance.
+- Override semantic tokens (Tier 2) in `:root`, not component tokens (Tier 3).
+- Prefer `<html class="theme-auto">`. Use `data-theme="light|dark"` only for explicit overrides.
 
 ```css
 /* Wrong */
@@ -84,14 +88,16 @@ The test: every compound component in your markup uses `.Root`, and its parts ar
 
 The test: does your CSS contain zero hex colors, zero `rgb()` values, and zero inline styles?
 
+Theming precedence beats design opinion. If impeccable guidance conflicts with DryUI theme contracts, tokens, or accessibility rules, DryUI wins.
+
 ## 4. Grid for Layout. Container for Width. @container for Responsive.
 
 **Nothing else.**
 
-- All layout is `display: grid` with `--dry-space-*` tokens in scoped `<style>`
-- `Container` (simple component, no `.Root`) for constrained content width
-- Use `@container` queries for responsive sizing — never `@media` for layout breakpoints
-- No flexbox. No inline styles. No `width`/`min-width`/`max-width` properties
+- All layout is `display: grid` with `--dry-space-*` tokens in scoped `<style>`.
+- `Container` (simple component, no `.Root`) for constrained content width.
+- Use `@container` queries for responsive sizing. Never `@media` for layout breakpoints.
+- No flexbox. No inline styles. No `width`/`min-width`/`max-width` properties.
 
 ```svelte
 <div class="layout">...</div>
@@ -104,29 +110,29 @@ The test: does your CSS contain zero hex colors, zero `rgb()` values, and zero i
 </style>
 ```
 
-The test: grep your output for `display: flex`, `style=`, `@media` — all should return nothing.
+The test: grep your output for `display: flex`, `style=`, `@media`. All should return nothing.
 
 ## 4A. Escape Hatches Mean Stop.
 
 **If lint or the compiler pushes you toward an escape hatch, the structure is usually wrong.**
 
-- Never add `:global()`, `!important`, `all: unset`, `<svelte:element>`, or `<!-- svelte-ignore ... -->` just to make a selector or warning go away
-- Never add `width`, `min-width`, `max-width`, `inline-size`, `min-inline-size`, or `max-inline-size` to solve layout pressure
-- Never use raw native elements outside their canonical DryUI component directories just because composition feels inconvenient
-- Never pass `class=` to DryUI components expecting it to style their internals; use wrapper elements, component props, `data-*` attributes, or `--dry-*` tokens instead
-- When blocked, restructure the markup instead: add a local wrapper, split explicit `{#if}` branches, move sizing to parent grid tracks, or promote the pattern into the canonical component where the raw element belongs
-- Treat `dryui/no-global`, `dryui/no-important`, `dryui/no-width`, `dryui/no-raw-native-element`, `dryui/no-css-ignore`, and `dryui/no-svelte-element` as design feedback, not obstacles to suppress
+- Never add `:global()`, `!important`, `all: unset`, `<svelte:element>`, or `<!-- svelte-ignore ... -->` just to make a selector or warning go away.
+- Never add `width`, `min-width`, `max-width`, `inline-size`, `min-inline-size`, or `max-inline-size` to solve layout pressure.
+- Never use raw native elements outside their canonical DryUI component directories just because composition feels inconvenient.
+- Never pass `class=` to DryUI components expecting it to style their internals. Use wrapper elements, component props, `data-*` attributes, or `--dry-*` tokens instead.
+- When blocked, restructure the markup instead: add a local wrapper, split explicit `{#if}` branches, move sizing to parent grid tracks, or promote the pattern into the canonical component where the raw element belongs.
+- Treat `dryui/no-global`, `dryui/no-important`, `dryui/no-width`, `dryui/no-raw-native-element`, `dryui/no-css-ignore`, and `dryui/no-svelte-element` as design feedback, not obstacles to suppress.
 
-The test: grep your output for `:global(`, `!important`, `all: unset`, `svelte-ignore`, `svelte:element`, raw `<button`, raw `<input`, raw `<select`, raw `<dialog`, raw `<hr`, raw `<table`, and `width:` — all should return nothing unless you are editing the canonical component that owns that native element.
+The test: grep your output for `:global(`, `!important`, `all: unset`, `svelte-ignore`, `svelte:element`, raw `<button`, raw `<input`, raw `<select`, raw `<dialog`, raw `<hr`, raw `<table`, and `width:`. All should return nothing unless you are editing the canonical component that owns that native element.
 
 ## 5. Every Input Gets a Field.Root
 
 **Accessibility isn't optional.**
 
-- Wrap every form input in `Field.Root` with a `Label`
-- Use `AlertDialog` (not `Dialog`) for destructive confirmations
-- Add `aria-label` to every icon-only button
-- Use `type="submit"` on primary form action buttons
+- Wrap every form input in `Field.Root` with a `Label`.
+- Use `AlertDialog` (not `Dialog`) for destructive confirmations.
+- Add `aria-label` to every icon-only button.
+- Use `type="submit"` on primary form action buttons.
 
 ```svelte
 <!-- Wrong -->
@@ -146,9 +152,9 @@ The test: every `<Input>`, `<Select.Root>`, `<Textarea>` is inside a `Field.Root
 
 **If a DryUI component exists for it, use it.**
 
-`DatePicker` not `<input type="date">`. `Select.Root` not `<select>`. `Dialog.Root` not `<dialog>`. `Separator` not `<hr>`. `Button` not `<button>`. DryUI components handle theming and accessibility automatically — native elements don't.
+`DatePicker` not `<input type="date">`. `Select.Root` not `<select>`. `Dialog.Root` not `<dialog>`. `Separator` not `<hr>`. `Button` not `<button>`. DryUI components handle theming and accessibility automatically. Native elements don't.
 
-The test: search your markup for raw `<input`, `<select>`, `<dialog>`, `<button>`, `<hr>`, `<table>` — each should be a DryUI component instead.
+The test: search your markup for raw `<input`, `<select>`, `<dialog>`, `<button>`, `<hr>`, `<table>`. Each should be a DryUI component instead.
 
 ## 7. Ask the Svelte MCP for Svelte Questions
 
@@ -156,7 +162,7 @@ The test: search your markup for raw `<input`, `<select>`, `<dialog>`, `<button>
 
 For Svelte 5 runes (`$state`, `$derived`, `$effect`, `$props`), snippets, SvelteKit load fns, `+page.server.ts` shape, form actions, and anything Svelte-syntax adjacent: call the official `svelte-autofixer` and `get-documentation` tools from `@sveltejs/mcp` before guessing from memory.
 
-- `dryui setup --install` registers `@sveltejs/mcp` by default; pass `--no-svelte-mcp` to skip.
+- `dryui setup --install` registers `@sveltejs/mcp` by default. Pass `--no-svelte-mcp` to skip.
 - If it's not registered, the fallback is the remote endpoint `https://mcp.svelte.dev/mcp` or a one-liner like `claude mcp add -t stdio -s user svelte -- npx -y @sveltejs/mcp`.
 - Scope split: DryUI `ask`/`check` cover component APIs, theming, composition, and validation. Svelte MCP covers the runtime, compiler, and framework idioms.
 
@@ -180,13 +186,13 @@ dryui
 
 ```bash
 dryui init             # existing project
-dryui init my-app      # new project — scaffolds SvelteKit + DryUI in one step
+dryui init my-app      # new project, scaffolds SvelteKit + DryUI in one step
 cd my-app && bun run dev
 ```
 
 This works for greenfield (empty directory), brownfield (existing non-SvelteKit project), and existing SvelteKit projects. On existing projects, `dryui install` prints the ordered plan and `dryui detect` verifies that setup is complete.
 
-> **No global install?** `bunx @dryui/cli <cmd>` and `npx -y @dryui/cli <cmd>` work anywhere without installing — same commands, just slower (re-fetches on each call).
+> **No global install?** `bunx @dryui/cli <cmd>` and `npx -y @dryui/cli <cmd>` work anywhere without installing. Same commands, just slower (re-fetches on each call).
 
 **4. Add the editor integration layer** after the CLI is working:
 
@@ -195,12 +201,12 @@ This works for greenfield (empty directory), brownfield (existing non-SvelteKit
 - OpenCode: `npx degit rob-balfre/dryui/packages/ui/skills/dryui .opencode/skills/dryui` + add the `dryui` and `dryui-feedback` local MCP servers in `opencode.json` (OpenCode also loads `.agents/skills/dryui` and reads `AGENTS.md`)
 - Copilot/Cursor/Windsurf: `npx degit rob-balfre/dryui/packages/ui/skills/dryui .agents/skills/dryui` + add MCP config (see https://dryui.dev/tools)
 
-**5. Register the Svelte MCP companion.** `dryui setup --install` does this automatically for Copilot, Cursor, OpenCode, Windsurf, and Zed. For Claude Code run `claude mcp add -t stdio -s user svelte -- npx -y @sveltejs/mcp`; for Codex add `[mcp_servers.svelte] command = "npx", args = ["-y", "@sveltejs/mcp"]` to `~/.codex/config.toml`. See rule 7 above.
+**5. Register the Svelte MCP companion.** `dryui setup --install` does this automatically for Copilot, Cursor, OpenCode, Windsurf, and Zed. For Claude Code run `claude mcp add -t stdio -s user svelte -- npx -y @sveltejs/mcp`. For Codex add `[mcp_servers.svelte] command = "npx", args = ["-y", "@sveltejs/mcp"]` to `~/.codex/config.toml`. See rule 7 above.
 
 ### Manual setup
 
 1. `bun add @dryui/ui`
-2. `bun add -d @dryui/lint` — enforces grid-only layout, bans flexbox/inline-style/width at build time. Without this step the CSS discipline rules are not enforced at build time, and only post-write `check` / CLI validation remain.
+2. `bun add -d @dryui/lint`. Enforces grid-only layout, bans flexbox/inline-style/width at build time. Without this step the CSS discipline rules are not enforced at build time, and only post-write `check` / CLI validation remain.
 3. Wire the lint preprocessor in `svelte.config.js` (add `dryuiLint` as the **first** item in the `preprocess` array):
 
    ```js
@@ -220,7 +226,7 @@ This works for greenfield (empty directory), brownfield (existing non-SvelteKit
    export default config;
    ```
 
-4. Add `class="theme-auto"` to `<html>` in `src/app.html`
+4. Add `class="theme-auto"` to `<html>` in `src/app.html`.
 5. In root layout (`src/routes/+layout.svelte`), import themes:
    ```svelte
    <script>
@@ -228,18 +234,18 @@ This works for greenfield (empty directory), brownfield (existing non-SvelteKit
    	import '@dryui/ui/themes/dark.css';
    </script>
    ```
-6. Import `app.css` AFTER theme CSS if you have custom styles
+6. Import `app.css` AFTER theme CSS if you have custom styles.
 
-> `dryui init` applies all six steps automatically — prefer it over manual setup when you can.
+> `dryui init` applies all six steps automatically. Prefer it over manual setup when you can.
 
-## Bindable Props — Common Confusion
+## Bindable Props, Common Confusion
 
-Always verify with `dryui info <Component>` or `ask --scope component`, but these are the most common mistakes:
+Always verify with `ask --scope component`, but these are the most common mistakes:
 
 - `bind:value` (Input, Select, Tabs...) vs `bind:checked` (Checkbox, Switch) vs `bind:pressed` (Toggle) vs `bind:open` (Dialog, Popover, Drawer...)
-- Select and Combobox support both `bind:value` and `bind:open`
-- ColorPicker also exposes `bind:alpha`; Transfer uses `bind:sourceItems` / `bind:targetItems`
-- Tour uses `bind:active`, not `bind:open`
+- Select and Combobox support both `bind:value` and `bind:open`.
+- ColorPicker also exposes `bind:alpha`. Transfer uses `bind:sourceItems` / `bind:targetItems`.
+- Tour uses `bind:active`, not `bind:open`.
 
 ## Tools
 
@@ -247,12 +253,10 @@ Use these to look up APIs, discover components, plan setup, and validate code.
 
 ### Recommended workflow
 
-1. Start from the user brief and local `DESIGN.md` identity, then resolve any component or recipe uncertainty with `dryui info <Component>` or `dryui compose "<query>"`. If MCP is available, `ask --scope component` and `ask --scope recipe` are the equivalent surface.
-2. Before writing code, make an explicit make-interfaces-feel-better polish intent pass: text wrapping, radius, icon motion, numbers, transitions, entrances/exits, shadows, icon alignment, image edges, and token consistency.
-3. Build the route or component with raw CSS grid, `Container` for constrained width, and `@container` for responsive layout.
-4. Run `dryui check [path]` or MCP `check` after implementation to catch composition drift, layout violations, accessibility regressions, and token drift.
-5. Run `dryui check --visual <url>` or MCP `check` with `visualUrl` for rendered review, then repair and repeat until the UI satisfies the brief.
-6. Never guess component shape from memory. DryUI is intentionally strict, and the lookup cost is lower than rework.
+1. Resolve any component or recipe uncertainty with `dryui ask --scope component "<Component>"` or `dryui ask --scope recipe "<pattern>"`. If MCP is available, `ask --scope component` and `ask --scope recipe` are the equivalent surface.
+2. Build the route or component with raw CSS grid, `Container` for constrained width, and `@container` for responsive layout.
+3. Run `dryui check [path]` or MCP `check` after implementation to catch composition drift, layout violations, accessibility regressions, and token drift.
+4. Never guess component shape from memory. DryUI is intentionally strict, and the lookup cost is lower than rework.
 
 ### CLI (default entry point)
 
@@ -262,12 +266,10 @@ Install once with `bun install -g @dryui/cli@latest` (or `npm install -g @dryui/
 dryui                           # default onboarding entry point
 dryui setup                     # explicit onboarding subcommand
 dryui init [path] [--pm bun]    # Bootstrap SvelteKit + DryUI project
-dryui info <component>          # Look up component API
-dryui compose "date input"      # Composition guidance
+dryui ask <scope> "<query>"     # Look up components, recipes, tokens, setup
 dryui detect [path]             # Check project setup
 dryui install [path]            # Print install plan
 dryui check [path]              # Validate file, theme, directory, or workspace
-dryui check --visual <url>      # Screenshot a URL and critique rendered polish
 dryui list                      # List components
 dryui tokens --category color   # Browse design tokens
 dryui ambient                   # SessionStart context
@@ -275,7 +277,7 @@ dryui install-hook --dry-run    # Preview Claude hook wiring
 dryui feedback init             # Feedback tooling setup
 ```
 
-Without a global install, prefix any command with `bunx @dryui/cli …` or `npx -y @dryui/cli …` — same behaviour, just slower (re-fetches on each call).
+Without a global install, prefix any command with `bunx @dryui/cli …` or `npx -y @dryui/cli …`. Same behaviour, just slower (re-fetches on each call).
 
 ### MCP tools (same workflow in-editor)
 
@@ -285,7 +287,6 @@ Without a global install, prefix any command with `bunx @dryui/cli …` or `npx
 | Lookup & composition | `ask --scope component`, `ask --scope recipe`, `ask --scope list` |
 | Validation           | `check <file.svelte>`, `check <theme.css>`                        |
 | Audit                | `check`, `check <directory>`                                      |
-| Rendered UI          | `check` with `visualUrl`, or direct `check-vision`                |
 
 Categories: action, input, form, layout, navigation, overlay, display, feedback, interaction, utility
 
@@ -298,11 +299,8 @@ Read these when you need deeper guidance:
 - **`rules/composition.md`** — Form patterns, page layouts, composition recipes
 - **`rules/accessibility.md`** — Field.Root, ARIA, focus management, pre-ship checklist
 - **`rules/svelte.md`** — Runes, snippets, native browser APIs, styling rules
-- **`rules/design.md`** — Minimal code, no premature abstraction, naming conventions
-- **`rules/design-brief.md`** — User brief, DESIGN.md identity, precedence, and polish review pipeline
-- **`rules/visual-effects-performance.md`** — Tiered budgets and implementation rules for shader, blur, glass, and pointer-reactive effects
 - **`rules/native-web-transitions.md`** — View Transition API, scroll animations, reduced-motion
 
 ---
 
-**These rules are working if:** every component traces to a lookup, diffs contain zero hardcoded colors, and the reviewer finds nothing.
+**These rules are working if:** every component traces to a lookup, diffs contain zero hardcoded colors, and `dryui check` finds nothing.

package/skills/dryui/rules/composition.md

@@ -398,7 +398,7 @@ Use Field.Error to show validation messages.
 
 ## Component Selection Quick Reference
 
-Before using any component, call `dryui compose "<query>"` or `dryui info <Component>` to get the correct component and usage snippet. If MCP is available, `ask --scope recipe` and `ask --scope component` are equivalent. This table is a quick reference — the CLI and MCP surfaces both return the fuller snippets and anti-patterns.
+Before using any component, call `dryui ask --scope recipe "<pattern>"` (for layouts) or `dryui ask --scope component "<Component>"` (for APIs) to get the correct component and usage snippet. This table is a quick reference. The CLI and MCP surfaces both return the fuller snippets and anti-patterns.
 
 | UI Need           | Use This                               | NOT This                     |
 | ----------------- | -------------------------------------- | ---------------------------- |
@@ -431,7 +431,7 @@ Before using any component, call `dryui compose "<query>"` or `dryui info <Compo
 
 ## Composition Recipes
 
-Call `dryui compose "<recipe>"` with any recipe name to get a full working snippet. If MCP is available, `ask --scope recipe "<recipe>"` is equivalent.
+Call `dryui ask --scope recipe "<recipe>"` with any recipe name to get a full working snippet.
 
 | Recipe                    | Description               | Key Components                         |
 | ------------------------- | ------------------------- | -------------------------------------- |
@@ -457,7 +457,7 @@ DryUI is a presentation and accessibility system, not a workflow engine. For dep
 - Normalize route/session state in script before rendering DryUI inputs.
 - Reset dependent `Select.Root` values when their parent choice changes; do not rely on stale child state surviving domain changes.
 - Use raw CSS grid to lay out planner sections, and keep orchestration logic in route-level stores or derived state.
-- Run `dryui info <Component>` or `dryui compose "<pattern>"` before introducing a new field shape, then run `dryui check [path]` or MCP `check` after the flow is wired. Use `dryui check --visual <url>` or MCP `check` with `visualUrl` when the rendered page needs visual review.
+- Run `dryui ask --scope component "<Component>"` or `dryui ask --scope recipe "<pattern>"` before introducing a new field shape, then run `dryui check [path]` or MCP `check` after the flow is wired.
 
 ```svelte
 <script lang="ts">

package/skills/dryui/rules/compound-components.md

@@ -18,7 +18,7 @@ Every compound component uses `.Root` as the container. Never use the bare name.
 
 ## Parts Reference
 
-Below are the parts for the most commonly used compound components. Prefer `dryui info <name>` for the full, up-to-date parts list; if MCP is available, `ask --scope component "<name>"` is equivalent.
+Below are the parts for the most commonly used compound components. Prefer `dryui ask --scope component "<name>"` for the full, up-to-date parts list.
 
 ### Card
 
@@ -307,6 +307,6 @@ Parts: Root, Input, Content, Item, Empty
 
 ## Full Compound Component List
 
-Run `dryui info <name>` for any component's complete parts list. If MCP is available, `ask --scope component "<name>"` is equivalent:
+Run `dryui ask --scope component "<name>"` for any component's complete parts list:
 
 Accordion, AlertDialog, Breadcrumb, Card, Collapsible, ColorPicker, Combobox, CommandPalette, ContextMenu, DataGrid, DatePicker, Dialog, DragAndDrop, Drawer, DropdownMenu, EmptyState, Field, FileUpload, FloatButton, Pagination, Popover, RadioGroup, RichTextEditor, Select, Splitter, Stepper, Table, Tabs, TagsInput, Toast, ToggleGroup, Toolbar, Tooltip, Tour, Transfer

package/skills/dryui/rules/native-web-transitions.md

@@ -80,7 +80,7 @@ Always include a reduced-motion override:
 }
 ```
 
-The `@media` block comes after the default rule in the same scoped stylesheet, so equal specificity plus source order handles the override without `!important` — which is banned by `@dryui/lint` (`dryui/no-important`). In JS, skip delayed typewriter/replay steps and render the final state immediately when reduced motion is active.
+The `@media` block comes after the default rule in the same scoped stylesheet, so equal specificity plus source order handles the override without `!important` (banned by `@dryui/lint` via `dryui/no-important`). In JS, skip delayed typewriter/replay steps and render the final state immediately when reduced motion is active.
 
 ## Svelte notes
 

package/skills/dryui/rules/design-brief.md

@@ -1,59 +0,0 @@
-# Design Brief Pipeline
-
-Use this rule before building or materially changing a UI. It keeps intent, component contracts, and polish review in the same visible loop.
-
-## Pipeline
-
-1. **User brief** — capture the audience, primary job, product/domain, density, tone, constraints, and success criteria. Ask only for missing information that changes the implementation.
-2. **DESIGN.md identity** — read the project `DESIGN.md` if present. If the project lacks one and the UI has meaningful visual direction, draft the identity in the working notes or create the file when the user asks for durable design guidance. Google-style `DESIGN.md` is an optional supported format, not a dependency.
-3. **DryUI lookup/plan** — use `dryui info`, `dryui compose`, or MCP `ask` before selecting components or recipes. Plan around confirmed component contracts, accessibility, tokens, and grid layout.
-4. **make-interfaces-feel-better polish intent pass** — explicitly list the polish details that apply before implementation. This is a planning step, not hidden preference.
-5. **Implementation** — build with DryUI components, Svelte 5, scoped grid CSS, tokenized styling, and accessible composition.
-6. **Deterministic check** — run `dryui check [path]` or MCP `check` against edited files or the workspace.
-7. **Visual review** — run `dryui check --visual <url>` or MCP `check` with `visualUrl`. Name the user brief and the polish intent in the review prompt when possible.
-8. **Repair loop** — fix issues in priority order, then repeat deterministic check and visual review until the screen satisfies the brief.
-
-## Precedence
-
-When guidance conflicts, use this order:
-
-1. User intent and explicit task constraints.
-2. Local `DESIGN.md` identity.
-3. DryUI component contracts, accessibility rules, and token/theming discipline.
-4. Official Svelte MCP guidance for Svelte and SvelteKit syntax/framework decisions.
-5. make-interfaces-feel-better polish rubric.
-
-## Brief Shape
-
-Keep the brief short and implementation-oriented:
-
-- Who is using this?
-- What are they trying to do?
-- What information or action must be visible first?
-- How dense should the interface be?
-- What brand, product, or domain cues should shape the identity?
-- What constraints are fixed by the user, existing code, or platform?
-
-## DESIGN.md Identity
-
-Use `DESIGN.md` to preserve durable identity decisions: product personality, visual tone, density, navigation model, content hierarchy, color/token direction, motion posture, and examples of what to avoid.
-
-Do not treat `DESIGN.md` as more important than the user's current request. If the user changes direction, follow the user and update the identity only when the change is meant to persist.
-
-## Polish Intent
-
-The make-interfaces-feel-better pass should be explicit in planning and visual review. Check the applicable details:
-
-- balanced headings and pretty body wrapping
-- concentric radius for nested surfaces
-- icon swaps that crossfade without jitter
-- tabular numbers for counters, prices, clocks, and scores
-- transitions for interactive state, not keyframe-only state changes
-- staggered entrances when groups appear
-- smaller exits than entrances
-- shadow treatment for raised surfaces
-- optical icon alignment inside buttons
-- adaptive image edges for media and avatars
-- token consistency across color, radius, shadow, spacing, duration, and easing
-
-If a detail does not apply, skip it deliberately. Polish is a review rubric, not decoration.

package/skills/dryui/rules/design.md

@@ -1,71 +0,0 @@
-# Clean Code Standards
-
-## Core Principle
-
-Write the minimum correct code. Every line must earn its place.
-
-## Rules
-
-### No Premature Abstraction
-
-- Three similar lines > one premature helper
-- Only extract when you have 3+ real call sites
-- No "just in case" configurability, feature flags, or extension points
-- Delete code you don't need -- don't comment it out
-
-### No Noise
-
-- No comments that restate what code does
-- Comments only where the _why_ is non-obvious
-- No empty catch blocks -- handle or rethrow
-- No unused imports, variables, or parameters
-- No `console.log` left in production code
-- No commented-out code -- use git history
-
-### Names Are Documentation
-
-- Functions: verb + noun (`getUser`, `handleClick`, `parseDate`)
-- Booleans: `is`/`has`/`should` prefix (`isOpen`, `hasError`)
-- Collections: plural (`users`, `items`)
-- Callbacks: `on` + event (`onClose`, `onChange`)
-- Constants: UPPER_SNAKE only for true compile-time constants
-
-### Functions
-
-- One job per function
-- Max 3 parameters -- use an options object for more
-- Return early to avoid nesting
-- Pure functions where possible -- side effects at the edges
-
-### Error Handling
-
-- Only validate at system boundaries (user input, API responses, file reads)
-- Trust internal code -- don't null-check values you just created
-- Use specific error types, not generic strings
-- Handle errors at the level that can meaningfully respond
-
-### File Organization
-
-- One concept per file
-- Keep files under 300 lines -- split if growing
-- Colocate related code (component + styles + tests in same directory)
-- Index files only for re-exports, never for logic
-
-## Anti-Patterns -- Stop and Fix
-
-| If you're about to...                   | Instead...                                                   |
-| --------------------------------------- | ------------------------------------------------------------ |
-| Add a "utils" file                      | Put it where it's used (shared module only at 3+ call sites) |
-| Create a base class                     | Use composition                                              |
-| Add a config option nobody asked for    | Don't                                                        |
-| Write a comment explaining _what_       | Rename so it's obvious                                       |
-| Add error handling for impossible cases | Trust internal code                                          |
-| Create a wrapper around a simple API    | Use the API directly                                         |
-
-## 5 Rules of Programming
-
-1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places.
-2. Measure. Don't tune for speed until you've measured.
-3. Fancy algorithms are slow when n is small, and n is usually small.
-4. Fancy algorithms are buggier than simple ones. Use simple algorithms and simple data structures.
-5. Data dominates. If you've chosen the right data structures, the algorithms will be self-evident.