Domains
Products on the same design system, each with its own tasks, so the benchmark can ask whether the design system governs beyond one product.
What
A domain is a product the tasks come from. Ten tasks are banking (a fintech app); five are a warehouse (stock, picking, shipping, receiving, adjustments). They share the design system, the graders, the contexts and the catalog of generated views.
| id | Screen | Components |
|---|---|---|
stock-levels | Stock of one warehouse, with items to reorder marked | Card, Stat, Table, Badge |
pick-list | A sales order's lines in walking order, with progress | Card, Progress, Table, Badge |
shipment-detail | Carrier, tracking, status, destination, packages and history | Card, DataList, Table, Badge |
goods-receipt | Quantities received against a purchase order, dock, damaged goods | Card, FormField, Input, Select, Checkbox, Textarea, Button |
stock-adjustment | A new quantity after a count, the difference, a reason | Card, FormField, Input, RadioGroup, Textarea, Button |
- In
task.json:"domain": "warehouse". Without it a task is banking: the first ten were written before domains, and adding the field would change their hashes and cut them off from their history on/regressions. - In code:
DOMAINS(packages/bench/src/domains.ts, importable by the web app as@vektos/bench/domains) gives each domain a title and the product the spec mode's prompt names ("pages for a warehouse management app"). - In
bench:--domain warehouse,--domain all; banking by default, so a command written before domains still runs the same ten tasks. - On
/tasks: one section per domain, each with its own "Which tasks are hardest", read on the series that ran every task of that domain. - Across the app: the overview shows one domain at a time (
/?domain=warehouse; banking by default), because its means over tasks would mix products./runsand/rulesshow every domain unless one is chosen. The queries take the domain's task ids (tasksinhistory,listRuns,ruleCounts); the domain lives in the task files, not in the database.
Why
The thesis is that a governed design system keeps agents on the rails. One product cannot show that: the agents may have learnt fintech pages, and the tasks may suit the components. A second product with other words (SKU, bin, dock) and other shapes (dense tables of quantities and units, operational forms) asks whether the result carries over.
A warehouse first, because it is the furthest from banking that the design system already covers: no new component was needed.
Try it
bun run bench --model mock/ideal --domain warehouse --no-page
infisical run -- bun run bench --model reflection/beam-free --domain warehouse --context ds-mcp --label try
infisical run -- bun run bench --model reflection/beam-free --domain warehouse --context genui-spec --label try
infisical run -- bun run web # /tasks, the Warehouse sectionExtend it
- Another task in a domain: as in guide 08, with
"domain"intask.json. A test checks that everymustShowtext is in the brief or the data. - Another domain: a key in
DOMAINSwith its title and product, the domain's tasks, and the ids of those a view can answer inSPEC_TASKS(runner/spec.ts). Add a component to the design system only when a task truly needs one, with its stories and docs, as for any component.
Known gaps
/regressionsand a model's page do not filter by domain. Regressions compare shared tasks, so domains do not mix within a comparison; a model's page pools them.- No domain-specific rules. A warehouse page could require units next to every quantity; the graders know only the design system's rules.
- The
mustShowcheck is a substring match. It finds a label nowhere in the brief or data, not one that only resembles a word there ("Reorder" in "reordering"). - Five tasks is a small panel. Enough to compare with banking at the level of a context, not to rank warehouse tasks finely.