Docs stable
Contributing
The lightweight RFC
A proposal is a draft DSDS entity, nothing more. Before any code or Figma work, write the entity with status draft: the scenarios it serves (use-cases with stances), evidence the need repeats in at least three real places, what existing components it composes, and what it must never be confused with. A draft entity is cheap to write and cheap to reject, and if it graduates, the RFC already is the documentation.
One whole landing
A component lands on all five surfaces in one change: the Figma set, the code component, the DSDS entity, the registry and story entry in the styleguide, and the doc plate on its Figma page. Partial landings do not merge. This is why nothing in the system exists in Figma but not in code, or in code but not in the docs.
The automated reviewer
npm run verify is the first reviewer on every change and it does not negotiate: the token build, the contrast contracts in both themes, DSDS schema validation over every entity, and the changelog version gate. Storybook runs axe at error level on every story on top. A red gate is a finished review with a rejection; fix the change, not the gate.
Graduation
The status field in each entity is the lifecycle: draft means proposed, experimental means shipped and allowed to change, stable means the component has full docs, a rendered styleguide page, and real usage. Deprecated is a stage, not a deletion: it must name its replacement and migration path, and it lands together with its changelog entry.
Human review, recorded
Design review happens in the browser on rendered output. A veto never dies in a comment thread: it is recorded as a guideline in the entity it applies to and, when it changes shipped behavior, as a changelog entry. The next contributor, human or agent, inherits the ruling instead of rediscovering it.