Addressing data duplication and 'single source of truth' issues within `DESIGN.md` due to separate YAML front matter and Markdown body.

## Feedback

Thanks for sharing this. I’ve been experimenting with this pattern already. [Implementation example](x.com/torbenanderson/st...

I like the goal of making `DESIGN.md` useful to both humans and tools, but I think the current format creates drift risk. Appreciate that this is already documented as alpha, but I thought I'd lay out the concern anyway.

As I understand it, YAML front matter contains the normative design-token values, while the markdown body provides human-readable guidance. In practice though, many of the same facts will likely appear twice:

1. once in YAML for tools
2. again in markdown prose/tables for humans

For example:

- YAML says `dark-muted: #858585`
- prose says dark muted is `#777777`

At that point the document still looks authoritative, but now contains two versions of the truth.

Markdown should already be structured enough for many design-system facts through headings, tables, lists, and code blocks. Repeating exact values in YAML creates a second source of truth inside the same file.

It also changes the reading experience a bit, particularly in markdown editors.

## Suggestion

A few possible directions:

1. Make markdown the primary source of truth and parse structured markdown.
2. Generate YAML from markdown, and keep YAML external in a separate `.yaml` file.
3. Format YAML section in an md format, rather than yaml

If both layers remain, then the linter should either:

- discourage repeated facts...