v0.3.0

Closer to what the guides on making a design system AI-ready ask for: spec
files the agent reads, a closed token layer, an audit that runs without an
agent, and a sync routine that says what went out of date when the design
system shipped.

Added

• markdown-specs adapter: reads a design system written down as a folder of
  Markdown spec files (foundations/, tokens/, atoms/, molecules/,
  organisms/) as it is, with no inventory to generate. Front matter, title,
  first paragraph, Usage and Don'ts sections become the component record;
  token tables become the token set. auto picks it when
  .design-system/specs exists. A new DirectoryTransport carries it, and
  hit_fields keeps search hits from carrying whole files.
• ds.sh sync: diffs the design system's components and tokens against a
  committed snapshot and lists every spec line, ledger decision and source line
  that names something removed, deprecated or changed. sync record takes the
  snapshot. The gate reports SYNC_SNAPSHOT_VERSION, and the check command runs
  sync before Recall when the design system has moved.
• ds.sh scan reports durations, z-indices, opacities and font weights as raw
  values, and names the token that already carries a value (tokens) or the
  nearest colour or length token (nearest).
• --strict on scan and sync: exit 1 on violations, for CI. Without it
  both keep the one-JSON-object, exit-zero contract.
• The design system version is read from the installed package
  (design_system_package, or the package the adapter stands for) when
  design_system_version is not set. The gate reports it as
  DESIGN_SYSTEM_VERSION, ledger lookup uses it, and ledger record fills
  it in.
• principles.source may be a Markdown file.

Upgrading. Nothing in design-config.yml has to change, but these things
behave differently without it:

• adapter: auto now picks markdown-specs when .design-system/specs
  exists; before, that project got static-json. Set adapter: explicitly to
  keep the old choice.
• For the library adapters (mui, antd, chakra, ark-ui, radix) the
  design system version is now read from the installed package. Ledger
  decisions recorded against another version are flagged stale and re-walked
  rather than adopted, and the answer cache starts cold once. Set
  design_system_version to pin it.
• scan reports durations, z-indices, opacities and font weights, so a
  validation round can raise findings the same code did not raise under 0.2.0.
• Run ds.sh sync record once and commit
  .specify/memory/design-system-snapshot.json to start tracking changes.

v0.2.0

Faster, simpler, and closer to the RFC. A run asks the design system each
question once, stops at the first rung that holds for the everyday surfaces,
reviews the implementation once and then checks only the fixes, and carries
the design brief a team pastes into its RFC through to validation. The ladder
is now strict about what goes in and light on how things are used, after the
contribution process of Meta's
Astryx design system.

In a simulated run (3 surfaces, 8 tasks, 3 validation rounds before, 2 after)
the design system's CLI was called 126 times with 0.1.0 and 36 times with
this release. That count comes from replaying the calls the command bodies
prescribe, not from an agent run; ds.sh cache stats reports the real number
for yours.

Upgrading. /speckit.design.context and its after_specify hook are
gone; the gate does their work. Nothing in design-config.yml has to change.
max_validation_rounds now defaults to 2; set it back to 3 if you want the old
bound.

Added

• Answer cache. The design system's CLI or MCP answers are remembered per
  feature (.specify/extensions/design/.cache/, gitignored), so a run asks
  each question once instead of once per phase, task and validation round.
  Failures are never remembered, the gate's reachability probe is always a real
  call, and extend, validate and report_gap are never replayed.
  Configured under cache (enabled, ttl_minutes); overridable with
  SPECKIT_DESIGN_CACHE_ENABLED and SPECKIT_DESIGN_CACHE_TTL_MINUTES.
• A short path through the ladder. A surface that an earlier decision
  answers (Recall), or that one search and one look at a component covers
  (Reuse), is resolved there, recorded in a short form without a candidate
  table. The full walk, with candidate tables, a final search and a gap
  record, is reserved for Compose, Extend and Create: strict about what goes
  in, light on how things are used, after the contribution process of Meta's
  Astryx.
• Lab components. What Create builds is a lab component: in the project,
  from the system's tokens and primitives, scoped to the feature, and marked
  as not part of the design system with a pointer to its gap record. Whether
  it joins the design system is for the system's owners to decide.
• ds.sh scan. The mechanical half of validation: literal colours,
  lengths and font stacks in the implementation (with file and line), token
  names the contract or spec asks for that the design system does not have,
  and contract tokens written nowhere in the code. Files that define the tokens
  are exempt through the new validation.theme_globs. Every validation round
  starts from it, so the review spends its attention on what needs a reader.
• A place for the design brief in the RFC. An optional
  ## Design guidelines section in the RFC template, free text, for what a
  team pastes from its guidelines: light or dark, which variant, which tokens.
  ds.sh rfc returns it as sections.design under the usual headings,
  German ones included (Design-Vorgaben, Gestaltung, Styleguide). The run
  saves the RFC as rfc.md next to the spec (FEATURE_RFC in the gate), the
  gate turns each instruction into a DS- requirement with the token that
  delivers it, and ds.sh scan checks its token names too.
• Call count. ds.sh cache stats reports how often the design system was
  actually asked and how often memory answered instead, per capability, kept
  whether or not caching is on. ds.sh cache clear starts the feature over.

Removed

• /speckit.design.context and its after_specify hook. The design
  system is now consulted once before planning, by the gate: it resolves the
  principles, tokens and breakpoints, walks the ladder, and writes the spec's
  ## Design System Requirements in one pass. Before, the context hook
  searched every surface and the gate searched it again. Anyone driving Spec
  Kit by hand gets the same spec section before planning starts, one step
  later than before. The spec addendum's candidates table is gone with it:
  resolutions live in design-system.md only.

Changed

• The gate checks every token name the spec or its RFC asks for against the
  design system's token list, and marks a name it does not have as
  [NEEDS CLARIFICATION] rather than substituting the nearest one.
• Validation is one full review and one fix round. max_validation_rounds
  defaults to 2, down from 3. Round 1 reviews the whole change; round 2 checks
  only the fixes, what they touched, the scan and the tests. When the last
  allowed round's findings have been ticked off, workflow status now says
  stop rather than asking for a round the bound refuses.
• Verify is part of the clean round. The round with no findings checks the
  change against the RFC's acceptance criteria and writes ## Verification in
  the same pass, instead of a separate phase that re-read everything. next: verify remains only for a clean round that omitted the section.
• gate.min_candidates_considered applies only where a surface lands on
  Extend or Create. Reuse and Compose use what exists and need no quota; the
  quota used to pad candidate tables for components used exactly as documented.
• For a Reuse surface, the constraints carried into the plan refer to the
  component's own documentation instead of copying it, and spell out only what
  the feature adds.

v0.1.0

Initial Release