Craft Bar

---
name: craft-bar
description: The execution-phase quality bar — use the strongest technique the domain actually offers, and clear a real craft bar instead of shipping default-looking output. Domain-agnostic, with worked examples for visual/web, CLI, data, mobile, games, backend, and embedded work. Load during the AIDD execution phase.
---

# The craft bar

The contract says *what* to build. This says *how well*. It applies to every project, in every domain.

## The rule

**Use the strongest thing the domain actually offers.** Not the first thing that works, not the easiest thing to type, not the answer you happen to remember from 2019. If the ecosystem has a better primitive than the obvious one, use it — and say why in the charter.

It cuts both ways. The strongest tool for a log parser is a tight state machine and good tests, not a framework. Reaching for something heavy where something small is correct is the same failure as reaching for something crude where something powerful is correct.

**Know what excellent looks like in this specific domain**, then aim there. Every domain has a version of "obviously made by someone who didn't care" and a version of "someone who knew what they were doing". You are aiming at the second one, and it looks different in every domain.

## Two rules that hold everywhere

**1. Default-looking output is a failure mode.** Every domain has a recognisable "generated by a model that didn't look at the problem" signature. If you can't tell whether a person or a model made your output, you haven't cleared the bar.

**2. No borrowed filler.** Nothing placeholder, nothing lorem, nothing hotlinked, nothing stock. Content, data, and assets are either real or generated by you for this project. This is deliberate: filler is how work announces that nobody looked at it.

## Worked examples

These are **examples of the rule, not the rule**. Find the equivalent for whatever you are actually building — most projects are not web projects, and a project may span several of these.

### Example: anything with a visual surface (web, landing pages, dashboards, rendered artifacts)

The tells of default output — centred hero over a purple-to-blue gradient, three equal feature cards, Inter at three weights, `rounded-2xl` and `shadow-lg` on everything, emoji as icons, evenly spaced sections with identical padding, one accent colour that means nothing.

Advanced visual technique is the point. Reach for whatever best showcases the work — a menu, not a checklist:

- **3D and shaders** — WebGL/WebGPU, raymarching and signed distance fields, custom vertex and fragment shaders, real depth and parallax
- **Post-processing** — bloom, chromatic aberration, film grain, displacement, colour grading
- **Generative and procedural** — particle systems, flow fields, fluid simulation, noise-driven form, procedural texture
- **Compositing** — SVG filters, masks and clip-paths, `mix-blend-mode`, duotone treatment
- **Motion** — scroll-driven narrative and scrubbed timelines, spring and inertia physics, View Transitions, magnetic elements and custom cursors
- **Typography** — variable fonts driven by scroll or cursor, per-character animation, kinetic typography, a type scale that is a decision rather than a default
- **Craft details** — a designed preloader, art-directed dark *and* light modes (not one inverted), sound design where it earns its place

Pick what serves *this* project. A fluid simulation on a tax form is as much a failure as a flat white page on a music label's site — both mean the maker did not look at the subject. Two techniques executed properly beat six half-wired.

**Generate imagery, never hotlink it.** No stock photography, no remote image URLs. CSS, SVG, canvas, WebGL, procedural. If you generate imagery with an image tool, treat it in-browser afterwards — duotone, grain, displacement, blend modes — rather than dropping raw output onto the page. Raw generated images look like raw generated images.

Non-negotiables here, because effects that break the page are worse than no effects:

- **Degrade honestly.** WebGL absent or context lost? A designed static composition, not a blank div.
- **`prefers-reduced-motion` respected**, and the reduced version *designed* — not just motion deleted.
- **Keyboard and screen readers still work.** Custom cursors do not replace focus states. Canvas needs a text equivalent.
- **Contrast holds** in both modes. A moody palette is not an excuse for grey-on-grey.
- **Frame budget is real.** 60fps on a mid-range laptop. Profile before claiming smooth; a shader at 12fps is a bug you shipped on purpose.
- **Weight is a design constraint.** No 600kB library for one effect you could write in 40 lines.
- **It works on a phone.** Touch, not hover. Test the narrow viewport before calling it done.

### Example: CLI and developer tools

Default output looks like: positional args only, `print()` for everything, a stack trace as the error message, no `--help` worth reading, silence during long work.

Aim at: a help text someone can act on without the README, errors that name the fix and not just the failure, exit codes that mean something, streaming progress for anything slow, colour that degrades when not a TTY, `--json` for machine consumption, tab completion, idempotent re-runs, and a `--dry-run` for anything destructive. Read like the tools you admire, not like a script.

### Example: data, analytics, and pipelines

Default output looks like: a default-palette bar chart, unlabelled axes, no null handling, a pipeline that silently drops rows.

Aim at: encodings chosen for the question being asked, annotation that states the finding rather than leaving the reader to hunt, uncertainty shown rather than hidden, colour that survives greyscale and colour-blindness, schema contracts enforced at the boundary, idempotent and replayable runs, row-count reconciliation, and failures that are loud and specific.

### Example: mobile

Default output looks like: a web layout in a native shell, no offline state, no empty state, jank on scroll, hardware back button ignored.

Aim at: platform-native navigation and gestures, real offline-first behaviour, designed empty/loading/error states, 60fps lists with recycling, respect for system text size and dark mode, haptics where they carry meaning, and battery cost treated as a design constraint.

### Example: games and simulation

Aim at: game feel first — input latency, easing, screen shake, audio timing tied to gameplay rather than decoration; a fixed-timestep simulation independent of frame rate; procedural or systemic content over hand-placed filler; readable silhouettes and colour hierarchy that survives motion.

### Example: backend, APIs, and infrastructure

Default output looks like: CRUD endpoints, 200 for everything, `console.log` observability, no pagination, secrets in config.

Aim at: a resource model that reflects the domain rather than the tables, correct status codes and typed errors, idempotency keys on anything that mutates, cursor pagination, backpressure and timeouts everywhere, structured logs with trace IDs, migrations that run online, and load-shedding behaviour designed rather than discovered.

### Example: embedded and systems

Aim at: bounded memory with no surprise allocation on the hot path, interrupt-safety reasoned about explicitly, deterministic timing, brownout and watchdog behaviour designed, power budget treated as a first-class constraint, and the failure mode chosen deliberately rather than inherited.

## The contract still outranks this

The gate already settled the technical decisions. This bar operates *inside* them:

- The user `APPLY`ed a minimal, text-first design? The craft goes into typography, rhythm, and restraint — not a particle field they explicitly did not choose.
- A `LOCKED` segment fixes the framework? Do the ambitious thing inside it.
- A note says "keep it fast, we serve rural connections"? That outranks every effect on any menu here.

Ambition inside the contract. Never ambition as a route around it.

## Verify by exercising it

Whatever the domain, verification means running the real thing and observing the real output. Reading your own source is not observation.

Rendered work: render it and look — both themes, reduced-motion on and off, narrow viewport, no-WebGL path. CLI: run the commands, including the failure paths. Data: check row counts and nulls against the source. API: hit it, including the error cases. Profile before describing anything as fast.