Governance / Promotion Path

Promote legacy ideas into the shared system before the guide treats them as truth.

The guide can reference useful legacy patterns, but it should only canonize behavior that exists in shared code. This path keeps the documentation aligned with the product rather than drifting ahead of it.

Required sequence

  1. Confirm the pattern is repeated in real marketing, onboarding, or app flows and is not just a one-off route flourish.
  2. Decide whether the source of truth belongs in `packages/brand` (tokens, assets, CSS foundations) or `packages/ui` (reusable React primitives).
  3. Implement the shared token, class, or component first, including any required variants and surface guidance.
  4. Replace at least one real consuming usage so the candidate is proven in production code before the docs canonize it.
  5. Document the new shared truth in `brand.gensudo.com` using live examples and update governance notes if the decision changes usage rules.

How to decide where it belongs

Shared token candidate

If a new spacing value or semantic surface color is needed in multiple places, add it to `packages/brand` first and then replace route-local values.

Shared UI primitive candidate

If toggles, menus, or tables repeat in real product flows, build the reusable primitive in `packages/ui` before documenting it as supported.

Docs-only request

If the request is just to make the guide look nicer, do not invent a docs-only variant that the product and marketing surfaces do not consume.

Blocking rule

If a pattern still lives only in the legacy guide, Figma, or a single route file, it is not current shared truth yet. It must stay marked as legacy reference or future candidate until shared code and at least one consuming surface adopt it.