* feat(craft): add brand-agnostic craft references and refero-derived lint rules
Introduce `craft/` as a third top-level content axis alongside `skills/`
and `design-systems/`, holding universal (brand-agnostic) craft rules
that apply on top of any DESIGN.md. Skills opt in via a new
`od.craft.requires` front-matter array; the daemon resolves the slug
list and injects the matching files between DESIGN.md and the skill
body in the system prompt.
Initial vendor (MIT, adapted from referodesign/refero_skill): typography
craft, color craft, anti-ai-slop. Pilot wired on saas-landing.
Extend the existing lint-artifact pass with two refero-derived rules:
- P0 ai-default-indigo — solid #6366f1 / #4f46e5 / #4338ca / #8b5cf6 as
accent (not just gradients) is the most-reported AI tell.
- P1 all-caps-no-tracking — `text-transform: uppercase` rules without
≥0.06em letter-spacing.
The craft loader silently drops missing files so a skill can
forward-reference future sections (e.g. `motion`) without breaking.
* fix(daemon): skip :root token blocks in ai-default-indigo lint
The ai-default-indigo P0 check scanned the whole HTML for the raw
hex, so brands that intentionally encode indigo as `--accent: #6366f1`
in :root and consume it via var(--accent) downstream were flagged
as AI-default — a false positive that forced the agent to "fix"
valid output. Strip :root token-definition blocks (including
attribute-selector theme variants) before scanning, mirroring the
existing pattern used by the raw-hex P1 check. Hex still flagged
when it appears in component rules or inline styles.
* docs(craft): address PR #225 P3 review feedback
- craft/README.md: explain why missing craft sections are silently
dropped (forward-compatibility) instead of surfacing a warning.
- craft/typography.md: ground the 0.06em ALL CAPS tracking floor in
Bringhurst-derived typographic practice rather than presenting
the threshold as unattributed.
- craft/color.md: cover the edge case where a brand's DESIGN.md
intentionally encodes indigo as --accent — `var(--accent)` uses
remain unflagged because the linter only inspects hardcoded hex.
- docs/skills-protocol.md: link the "missing files dropped silently"
note back to craft/README.md for the canonical slug list and the
rationale behind the choice.
* fix(craft): address PR #225 P0 review feedback
- tools/pack: copy `craft/` into the packaged resource root alongside
`skills`, `design-systems`, and `frames`, so the `od.craft.requires`
integration isn't a silent no-op when the daemon resolves
`${OD_RESOURCE_ROOT}/craft` in packaged builds.
- packages/contracts: add `craftRequires?: string[]` to `SkillSummary`
(and therefore `SkillDetail`) so the field that `listSkills()`
already returns and `/api/skills(/:id)` already serializes via
`...rest` is part of the documented web/daemon contract instead of
leaking through as an untyped property.
- apps/daemon/lint-artifact: expand the indigo token-strip pass to
cover selector lists containing `:root` (e.g. `:root, [data-theme="light"]`)
and any rule whose body is custom-property-only (e.g. a
`[data-theme="dark"] { --accent: ... }` theme variant). Real
component rules with a hardcoded indigo are still preserved so the
P0 finding still fires; tests cover the new selector-list and
theme-variant cases.
* fix(craft): address PR #225 follow-up review feedback
- lint-artifact: scope the indigo token-strip to <style> blocks so the
rule-shaped regex no longer captures leading `<style>` text into the
selector (which broke `:root` recognition for token blocks that mix
`color-scheme`/etc. with `--accent`). Run the strip on the extracted
CSS instead, with a regression covering `:root { color-scheme: light;
--accent: #6366f1 }`.
- lint-artifact: tighten the custom-property-only exemption to global
theme-scope selectors (`:root`, `html`, `body`, bare attribute
selectors like `[data-theme="dark"]`). Component-local rules such as
`.cta { --cta-bg: #6366f1 }` are no longer exempted, so an agent
cannot launder default indigo through a local var. Regression test
added.
- craft/anti-ai-slop.md: stop claiming every rule below is enforced by
the linter; only several are. The unenforced rules (standard
Hero→Features→Pricing→FAQ→CTA flow, decorative blob/wave SVG
backgrounds, perfect symmetry) are now flagged inline as
"(guidance, not auto-checked)" so the contract with the lint surface
stays honest.
* fix(daemon): tighten lint-artifact iteration and :root token gating
- all-caps-no-tracking: iterate every <style> block. The previous
check called `exec` once on a non-global regex, so an artifact
whose offending uppercase rule sat in a second <style> block
(e.g. a reset block followed by a components block) slipped
past. Switch to `matchAll` and break across both loops once a
violation is found. Regression test covers a second-block
uppercase rule.
- ai-default-indigo: stop unconditionally exempting any selector
list containing `:root`. The exemption now requires both
conditions to hold: every selector in the list is global theme
scope AND the body is token-shaped (CSS custom properties or
the `color-scheme` keyword). So `:root { background: #6366f1 }`
and `:root, .cta { --cta-bg: #6366f1 }` no longer launder a
hardcoded indigo through the strip pass. Regression tests cover
both bypass shapes.
* fix(daemon): scope theme-attr exemption and strip CSS comments in token blocks
Address PR #225 review feedback on `ai-default-indigo`:
- The bare-attribute branch of `selectorListIsGlobalThemeScope` accepted
any `[attr=...]` selector, so a custom-property-only rule on a
component/state attribute (e.g. `[data-variant="primary"]`,
`[aria-current="page"]`) was treated as a global theme block and
stripped before the indigo scan — exactly the component-local indigo
laundering this lint is meant to catch. Restrict the exemption to a
small allowlist of known theme switches: `data-theme`,
`data-color-scheme`, `data-mode`.
- `stripTokenBlocksFromCss` split rule bodies on `;` and matched each
fragment from the start, so a token block whose body contained a
normal CSS comment such as `:root { /* brand accent */ --accent:
#6366f1; }` produced a fragment beginning with the comment, failed
`isTokenShapedDeclaration`, and the rule was left in scope of the
indigo scan — a false P0 on a legitimate token definition. Strip CSS
comments before splitting/classifying declarations.
Add regression coverage: arbitrary component/state attribute selectors
still trip `ai-default-indigo`; `data-color-scheme` theme variants stay
exempted; `:root` token blocks with leading, trailing, and
between-declaration CSS comments are recognized.
* fix(daemon): strip CSS comments and recognize tokens nested in at-rules
The all-caps-no-tracking scan ran against raw `<style>` content, so a
commented-out rule like `/* .eyebrow { text-transform: uppercase; } */`
matched `upperRe` and emitted a P1 for CSS the browser ignores. Strip
CSS comments from the style body before structural matching.
`stripTokenBlocksFromCss` only matched flat `selector { body }` rules,
so a media-query-wrapped token block like
`@media (prefers-color-scheme: dark) { :root { --accent: #6366f1 } }`
had its outer `@media` rule treated as the selector/body pair and the
inner `:root` token block was never stripped, producing a P0 false
positive on legitimate responsive theme CSS. Tighten the body
alternation to `[^{}]*` so the regex matches innermost rules and
recognizes the inner `:root` block directly while preserving the
outer at-rule wrapper.
* fix(daemon): align ai-default-indigo list with documented cardinal sins
The lint's AI_DEFAULT_INDIGO subset omitted #3730a3 and #a855f7, which
craft/anti-ai-slop.md lists as P0-blocked solid accents. An artifact
could hard-code one of those documented colors as a button fill and
slip past the indigo scan unless it happened to be inside a gradient.
Bring the lint set to the exact list documented in the craft doc, and
tighten the doc's wording from "etc." to an explicit enumeration that
points at AI_DEFAULT_INDIGO so the prompt contract and daemon behavior
stay in sync. Add regression tests pinning each newly-included hex.
* fix(daemon): tighten theme-scope selector and scan inline ALL CAPS
The theme-scope exemption used to accept any attribute on `:root`,
`html`, or `body` (e.g. `:root[data-variant="primary"]`), letting an
agent launder default indigo through a component/state attribute and
slip past the `ai-default-indigo` lint. The prefixed branches now
require the attribute name to be one of GLOBAL_THEME_ATTRIBUTES,
matching the bare-attribute branch.
The `all-caps-no-tracking` rule only iterated `<style>` blocks, so
inline declarations like `<span style="text-transform: uppercase">`
produced no finding even though craft/typography.md treats the
≥0.06em tracking floor as having no exceptions. Added a second scan
over `style="..."` attributes that runs the same letter-spacing
check and dedupes against the existing `<style>`-block finding so
the agent gets a single corrective signal per artifact.
* fix(daemon): align uppercase tracking px floor with the 0.06em rule
The previous absolute fallback (>=1.5px) was stricter than the craft
rule it enforces. `font-size: 12px; letter-spacing: 1px` is 0.083em
— above the 0.06em floor — but 1.5px would reject it and trigger an
unnecessary correction loop on compliant small-label CSS.
Extract `hasAdequateUppercaseTracking`: read `font-size` from the same
rule body and compare px tracking against `fontSize * 0.06`; fall back
to a conservative >=1px floor when font-size is inherited (covers the
default 16px body where 1px ≈ 0.0625em). Apply the helper to both the
<style>-block scan and the inline-style scan, and add 12–14px label
tests in both branches.
* fix(daemon): treat rem letter-spacing as absolute, not per-element em
`rem` was previously folded into the same branch as `em` and accepted
at the 0.06 threshold. But `rem` is relative to the root font-size
(16px default), not the element's own font-size, so on a 48px heading
`letter-spacing: 0.06rem` resolves to 0.96px — about 0.02em of the
element, well below the 0.06em rule the lint enforces.
Convert rem to absolute px through the 16px root assumption and reuse
the same px-vs-element-font-size resolution: same-rule `font-size: <n>px`
gives an exact `n * 0.06` floor; otherwise the conservative >=1px
fallback applies. Add regression tests for 48px headings with 0.06rem
tracking (must flag) plus the 16px-element and rem-floor matches that
must keep passing, in both <style>-block and inline-style branches.
* fix(daemon): resolve var() refs in uppercase tracking lint
`hasAdequateUppercaseTracking` only matched literal numeric values,
so a tokenized rule like `letter-spacing: var(--caps-tracking)` —
exactly the pattern the craft prompt steers artifacts toward — was
falsely reported as `all-caps-no-tracking`. Extract `--name: value`
declarations from global theme scopes (`:root`, `html`, theme-attribute
selectors) once per artifact, then expand simple `var(--name)` (and
`var(--name, fallback)`) references in the inspected rule body before
applying the existing 0.06em / px-floor / rem-conversion logic.
References without a matching token and no fallback stay in place,
preserving the conservative "missing tracking" finding.
* fix(daemon): resolve rem and var() font-size in uppercase tracking lint
Previously the px-vs-element-font-size resolution only matched
`font-size: <n>px`. Any rem-based or tokenized display size fell
through to the lenient `>= 1px` body-text fallback, so an artifact
emitting `.display { font-size: 3rem; text-transform: uppercase;
letter-spacing: 1px; }` (a ~48px heading with a 2.88px floor) slipped
past the lint that this helper exists to enforce.
Resolve `rem` font-size via the same root-font assumption already used
for tracking, and treat any explicitly declared but unresolvable unit
(`em`, `%`, `calc(...)`, an unresolved `var(...)`) conservatively —
refuse the lenient fallback so the rule must use either an `em`
letter-spacing or a verifiable px/rem font-size.
`var()` font-size declarations resolve through the existing
`resolveCssVars` pass before the size scan runs, so the same fix
catches the tokenized-display-size pattern (`--display-size: 3rem`).
* fix(daemon): parse declarations to ignore custom-prop names in uppercase tracking lint
The hasAdequateUppercaseTracking and resolveFontSizePx helpers used substring regexes against the rule body, so a token-name declaration such as `--letter-spacing: 0.08em` or `--display-font-size: 48px` could satisfy the `letter-spacing` / `font-size` checks even though it has no rendered effect — letting actual ALL-CAPS-without-tracking rules slip past the P1 lint.
Parse the declaration list, compare exact property names, and skip declarations whose property starts with `--`. Adds regression tests covering token-name letter-spacing (style-block + inline) and a token-name font-size masking the bail-out branch.
* fix(daemon): scope indigo token exemption to --accent only
Previously stripTokenBlocksFromCss removed every custom-property-only
global theme block before the ai-default-indigo scan, which let a
laundered indigo token like `:root { --primary: #6366f1 }` consumed
via `var(--primary)` slip past the lint. The craft contract is that
the only escape hatch is encoding indigo as the design system's
`--accent` token; any other token name is still the LLM-default
color hidden behind an arbitrary name. Narrow the strip pass so a
non-`--accent` token whose value carries an AI-default indigo hex
keeps the rule in scope, and add regression tests for `--primary` /
`--button-bg` global tokens feeding a CTA, including the at-rule
and theme-attribute variants.
* fix(daemon): model CSS cascade in tracking lint and detect blue→cyan trust gradients
Address PR #225 review feedback (3 comments):
- `letter-spacing` / `font-size` selection now picks the LAST matching
declaration in the rule body, modeling CSS source-order cascade.
`.eyebrow { letter-spacing: 0.08em; letter-spacing: 0.02em }` renders
the noncompliant 0.02em the browser actually shows; the previous
first-match behaviour silently passed it.
- `extractCssTokens` now records every distinct value seen for a token
across global theme scopes, and `hasAdequateUppercaseTracking`
enumerates each combination so a default-theme value below the floor
cannot be rescued by a scoped override that happened to be parsed
later (`:root { --caps-tracking: 0.02em }` +
`[data-theme="dark"] { --caps-tracking: 0.08em }` now fires).
- New `trust-gradient` P0 rule pairs blue/sky tokens against cyan
tokens in `linear-gradient(...)` bodies so `blue→cyan` two-stop
trust gradients (documented as a cardinal sin in
`craft/anti-ai-slop.md`) are actually enforced — both the hex form
(`linear-gradient(90deg, #3b82f6, #06b6d4)`) and the keyword form
(`linear-gradient(90deg, blue, cyan)`).
Adds 11 regression tests covering each path (cascade override in
<style> and inline form, font-size cascade shifting the floor, both
orderings of the conflicting-token cascade, the don't-over-fire case
when every theme value clears the floor, hex / keyword / sky variants
of the trust gradient, and the don't-double-fire case when
purple-gradient already caught a mixed gradient).
* fix(daemon): apply per-scope cascade in extractCssTokens
When the same CSS custom property is declared more than once inside a
single rule body (e.g. `:root { --caps-tracking: 0.02em;
--caps-tracking: 0.08em }`), CSS source-order cascade collapses to the
last value; the earlier declaration never reaches any element.
`extractCssTokens` was treating intra-scope duplicates as simultaneous
theme alternatives, so `hasAdequateUppercaseTracking` enumerated the
stale 0.02em and emitted a spurious all-caps-no-tracking finding.
Collapse duplicate token declarations within a rule body to the last
value before merging into the cross-scope distinct-value map. Cross-scope
overrides (separate `:root` and `[data-theme]` rules) remain preserved
as distinct values so the conservative theme-cascade check still fires
when ANY applicable theme renders below the floor.
* fix(daemon): scope tracking lint to innermost rules and per-theme tokens
Restrict the upperRe body alternation to [^{}]* so the regex matches
innermost CSS rules and skips at-rule wrappers — an outer @media or
@supports could otherwise capture as a single rule whose selector was
the at-rule and whose body began with the inner selector token, masking
the same-rule font-size and letting noncompliant tracking on large
headings slip through the lenient inherited-size fallback.
Replace the by-name-distinct-values token map with per-scope token
records and a buildResolvedThemes pass that materializes one effective
map per theme. Paired token declarations now stay paired during
evaluation, so theme variants like :root + [data-theme=dark] no longer
generate cross-theme cartesian pairings (e.g. default-size + dark-track)
that emit false positives on legitimate light/dark themes.
---------
Co-authored-by: looper <looper@open-claude.dev>
ensureWebDevNodeModules() called fs.symlink(target, path, "dir") to
link apps/web/node_modules into the web runtime root. On Windows,
"dir" symlinks require either Administrator rights or Developer Mode
(SeCreateSymbolicLinkPrivilege). Standard non-elevated user accounts
without Developer Mode get EPERM and tools-dev exits before web ever
starts.
Junctions ("junction") are functionally equivalent for directory-only
links on the same volume, work for any user without elevation or
Developer Mode, and are silently treated as plain symlinks on POSIX.
The existing isSymbolicLink() check on the next launch still matches
junctions on Node.
Reproduced on Windows 11 + Node 24 with a non-elevated PowerShell
session and Developer Mode off.
* feat(tools-dev): add --prod flag and OD_HOST for headless server deployment
- Lazy-load electronBinaryPath so daemon+web can start without Electron
- Add --prod flag to tools-dev start/run that sets NODE_ENV, OD_WEB_PROD,
and OD_WEB_OUTPUT_MODE automatically for production Next.js builds
- Add OD_HOST env var support to daemon and web sidecar bind addresses
(defaults to 127.0.0.1, set to 0.0.0.0 for remote access)
- Skip next.config.ts distDir override when OD_WEB_PROD=1 so production
builds resolve the default .next directory
Closes#221
* fix: address PR review — hardcode daemon bind to 127.0.0.1, cache electron path
- Revert OD_HOST from daemon: daemon is a local privileged process and must
only bind 127.0.0.1. Remote access goes through the web sidecar proxy.
- Web sidecar resolveDaemonOrigin now always uses 127.0.0.1, separated from
the web bind address (OD_HOST) so the daemon proxy works correctly even
when the web listener binds 0.0.0.0.
- Add OD_HOST character validation to reject clearly invalid values early.
- Cache electronBinaryPath getter result to avoid repeated require() calls.
---------
Co-authored-by: yamsfeer <yamsfeer@users.noreply.github.com>
tools-dev generated a temp web tsconfig with Windows backslash relative paths in extends, which Next/TypeScript failed to resolve in some environments. Normalize runtime tsconfig/dist path strings to POSIX separators so dev config resolution works consistently across Windows/Linux/macOS.
Surface daemon log tails when tools-dev waits for daemon status and add targeted guidance for native Node addon ABI mismatches.
Generated-By: looper 0.0.0-dev (runner=worker, agent=gpt-5.5)
* feat(dev): add desktop tools-dev control plane
* refactor(sidecar): split Open Design contracts
Move Open Design-specific sidecar protocol definitions into @open-design/contracts so sidecar and platform can remain descriptor-driven primitives.
* refactor(daemon): organize package sources
Keep daemon app code, tests, and sidecar entrypoints in separate package directories so each layer can be built and verified independently.
* chore(repo): streamline maintenance entrypoints
Centralize agent guidance by directory and reduce root command chains while preserving the existing build scope.
* docs: translate agent guidance to English
* fix(sidecar): tolerate stale IPC sockets
Remove stale Unix socket files only after confirming no listener is active, so tools-dev can restart after unclean shutdowns.
