Welcome

Welcome and governance

Design-system entry point, reader paths, and local-only claim boundaries.

Design SystemPrivate local scaffold proof

Contract map

Local proof only

Start here

Use this Storybook as the contract map for shared TCRN frontend presentation. It explains which UI decisions are owned by the design system, which proof is local, and where product adoption must be proven separately.

Reader paths

ReaderStart withThen check

Frontend implementerComponents and patternsAccessibility and proof notes

Product reviewerGovernance boundariesNo-adoption claims

QA reviewerProof matrixBrowser and a11y receipts

Release coordinatorRelease and bug policyPublication route status

Claim boundaries

Package-local proof

Evidence is local to this design-system scaffold.

Consumer adoption separate

This proof surface intentionally makes no downstream acceptance claim.

Downstream evidence required

External, product, or release evidence is still required.

local package proofsynthetic examplesconsumer adoption separate

Governance boundaries

Boundary map for design-system, product, workflow, and release ownership.

Boundary map

OwnerOwnsMust not claim here

Design SystemPresentation contracts, tokens, copy-state, React primitives, Storybook examples, and proof harnesses.Product acceptance

Product reposAPI clients, RBAC, routing, persistence, domain semantics, and production evidence.Package publication

WorkflowCross-project governance, freshness checks, route coordination, and promoted knowledge.Product UI acceptance

Release routePackage publication, remote creation, version readback, and downstream release evidence.Owner Intent exceptions

External Storybook references may inform information architecture only; implementation, assets, styles, and tokens stay original to TCRN.

Maintainers and routing

Where each design-system question should route before implementation or proof.

Routing directory

QuestionPrimary ownerExpected route

Visual polish or component ergonomicsFrontend StudioDesign-system implementation review

Accessibility, browser, or visual proofVerification laneProof receipt review

Security, secrets, or external provider riskSecurity reviewSeparate risk route

Package publication or version rolloutRelease routeBatch Push Gate route

Product adoption in AOS or TMSProduct implementation ownerConsumer adoption route

Routing rule

When the work would mutate product repos, publish packages, create remotes, or claim acceptance, leave this Storybook route and open the owning route.

Contribution model

Admission rules for proposals and product-validated ideas entering the shared system.

Admission: Admit only cross-product presentation needs with synthetic proof.
Source: A product-validated idea may be proposed, but product evidence must be converted into synthetic examples.
Story contract: Each story needs purpose, anatomy, states, copy, accessibility, and proof notes.
Proof: Run Storybook, browser, accessibility, visual, and no-overclaim checks.
Promotion: Consumer adoption remains downstream and route-owned.

Product data, RBAC, API DTOs, and tenant truth stay outside this package.

Release and bug policy

How local checkpoints, package publication, consumer adoption, and bugs stay separate.

CaseDispositionBlocked action

Local checkpointDesign-system source, stories, tests, and receipts are current locally.No package publication

Package publicationRelease owner proves remote, version, tarball, changelog, and Batch Push Gate readback.No consumer adoption

Consumer adoptionAOS or TMS owner imports the package and proves route behavior in that product.No final MVP acceptance

Bug or visual regressionFix the smallest owning surface and rerun affected proof.No release readiness shortcut