document-and-govern-design-system

Use the fixed 10-section standard: one-line description, use-when and don't-use-when with sibling component pointers, variants table, states table, props/API table, accessibility block, content rules, token names, one code example, and a do/don't table. A component is not in the system until this doc exists.

Score six NN/g dimensions from 0 to 3 with evidence: organizational alignment, team effectiveness, infrastructure, governance, support, and adoption. The lowest score is the highest-leverage gap by default, but low adoption with decent infrastructure points to governance or support instead.

A contribution must be needed in at least three places, not achievable with existing components, have all states specified including focus, include a complete accessibility block, use tokens only with zero raw values, ship documentation before merge, and include a changelog entry.

Do not use it to create token values, which belongs to build-token-system, or to design empty/loading/error states, which belongs to design-ui-states. It also does not write actual UI copy; it owns only the content standards that copy must follow.

Teams detach primarily when contribution reviews are slow or criteria are ambiguous. A fast rejection naming the specific failed criterion preserves trust better than a slow maybe, and a named enforcer catches one-offs early before they spread.