--- name: functional-industrial-ui description: Create tactile industrial instrument interfaces with warm-grey machined frames, near-black inset evidence displays, hard square controls, restrained recessed texture, technical typography, and one muted signal-orange active state. Use when an AI agent needs to design or implement operations consoles, control surfaces, component labs, dashboards, repository heroes, or technical card series in self-contained HTML/CSS, React, or another frontend framework. --- # Functional Industrial UI Create compact industrial instruments that make state, evidence, and action legible through material hierarchy. ## Workflow 1. Identify the primary user decision and the evidence needed to make it. 2. Classify every visible element as `evidence`, `context`, `action`, or `status`. 3. Read `references/visual-contract.md` and preserve its six signature mechanisms. 4. Choose one registered composition from `references/composition.md`. 5. Apply the material and color roles in `references/tokens.md`. 6. Implement semantic controls using `references/components.md`. 7. Mark simulated data as synthetic in both source data and the rendered interface. 8. Validate structure and accessibility using `references/validation.md`. 9. Treat material quality and visual acceptance as a separate human decision. ## Design rules - Use one continuous warm-grey instrument frame rather than a floating-card canvas. - Place the dominant evidence inside one near-black recessed display. - Give controls hard top planes, visible sidewalls, short travel, and honest pressed states. - Reserve signal orange for one active, primary, or consequential owner. - Use recessed perforation only as bounded technical texture or status chrome. - Keep readouts visually inset, fields editable, and actions visibly pressable. - Use system fonts by default. Do not require bundled or remote font files. - Keep examples self-contained and usable without a network connection. - Provide keyboard focus, descriptive labels, and minimum 44px interactive targets. - Never imply that structural validation is visual approval or production readiness. ## Public naming and asset boundary Use neutral project, component, and example names. Do not include third-party names, logos, product labels, screenshots, source pixels, bundled commercial fonts, or claims of affiliation. Do not describe this boundary as legal clearance for visual similarity. ## Output requirements For a self-contained HTML deliverable: - include ``, `lang`, viewport metadata, and one `
`; - include `data-synthetic="true"` when sample data is invented; - avoid external scripts, stylesheets, images, and font requests unless the user supplies licensed assets; - include visible focus treatment and reduced-motion handling; - keep diagnostics visible in the page or write concise errors to stderr; - run `scripts/validate-demo.mjs` before handoff. ## Bundled resources - Read `references/visual-contract.md` before designing any surface. - Read `references/tokens.md` when choosing color, type, spacing, or motion. - Read `references/components.md` when composing controls, data displays, tables, or status regions. - Read `references/composition.md` when selecting a page structure. - Read `references/validation.md` before claiming that an output passes checks. - Use `assets/theme.css` as the independent baseline theme. - Use `scripts/build-demo.mjs` to generate a reproducible standalone example. - Use `scripts/validate-demo.mjs` to run bounded static validation. ## Example commands ```sh node functional-industrial-ui/scripts/build-demo.mjs \ --config examples/operations-dashboard/data.json \ --out examples/operations-dashboard/index.html node functional-industrial-ui/scripts/validate-demo.mjs \ examples/operations-dashboard/index.html ```