Agentic Component Beta and Production Readiness

[JasonVMo]

Summary

Coordinate the theming, component, and desktop infrastructure work required to
take the Fluent UI React Native agentic stack from its current experimental
state through beta and production readiness.

This is the parent tracking issue. The three linked workstreams define their
beta and production outcomes, staging, dependencies, and exit criteria; each
workstream in turn tracks its implementation issues. Suggested additions remain
decision-gated until they are explicitly added to the program.

Workstream tracker

Workstream	Research	Suggested additions	Beta delivery	Production delivery
Theming	Complete	All promoted	Not started	Not started
Components	Complete	2 pending review	Not started	Not started
Infrastructure	Complete	6 pending review	Not started	Not started

Research outcome

Initial research completed on 2026-08-20 with 46 issue-ready task documents.
The bundle-size and dependency-budget additions approved on 2026-08-21 add one
cross-workstream infrastructure task. The next approved expansion adds six
theming tasks, three component tasks, and three infrastructure tasks, bringing
the program total to 59.

Workstream	Task documents	Key result
Theming	12	Defines one design-package contract plus generated defaults, appearance, drift and snapshot gates, consolidated high contrast, current docs, Storybook integration, optional OKLCH and contrast utilities, and a specification-backed Apple theme.
Components	39	Defines testing and readiness contracts, FocusZone and spec ingestion, primitive scope, Button/ToggleButton alignment, shared accessibility conformance, and one task for each of 32 missing catalog components.
Infrastructure	8	Covers driver landing and release proof, Storybook E2E and Win32, bundle budgets, smoke-harness disposition, Windows visual evidence, and portable real-platform accessibility assertions.

The original requested scope is fully represented. The extra desktop-driver
release task is an evidence-backed split of implementation landing from
real-platform proof. Owner-approved Suggested Additions are promoted into the
task hierarchy; the two remaining component additions and six remaining
infrastructure additions stay decision-gated.

Current delivery gaps

• The desktop driver's macOS backend still needs clean-machine proof, and all
  three desktop endpoints need required CI gates before production.
• The provisional component assessment places all 23 current exports at
  experimental because no item has pinned spec provenance and two-platform
  on-device validation yet; the component task records the higher ceiling each
  item could reach after those universal gaps close.
• No repeatable bundle-size or dependency-budget gate currently makes the
  component package boundary and theming optionality claims enforceable.

Program staging

Stage 0: Approve scope

• Review the evidence, boundaries, and open decisions in all three
  workstreams.
• Decide which Suggested Additions should become issue-ready tasks.
• Convert approved task documents into GitHub issues and record their issue
  links in the corresponding workstream.

Stage 1: Establish beta foundations

• Stabilize theming contracts needed by generated components.
• Establish component readiness criteria, repeatable tests, and spec
  ingestion.
• Establish deterministic local desktop test infrastructure and the
  Storybook endpoints needed by beta validation.

Stage 2: Deliver beta

• Complete every task marked as a beta requirement.
• Satisfy the beta exit criteria in each workstream.
• Publish a cross-workstream readiness assessment with unresolved
  production gaps.

Stage 3: Harden for production

• Complete every task marked as a production requirement.
• Run the supported platform, compatibility, performance, accessibility,
  and release gates defined by the workstreams.
• Satisfy all production exit criteria and record ownership for ongoing
  maintenance.

Cross-workstream dependency order

1. Approve the theming public contracts, component readiness model, spec
   ingestion boundary, and infrastructure architecture.
2. Land reusable theming and testing foundations before scaling component
   generation.
3. Generate and assess missing components in dependency-aware waves.
4. Exercise beta candidates through Storybook and the desktop test pipeline.
5. Harden compatibility, performance, accessibility, release automation, and
   operational ownership for production.

The detailed workstream plans may refine this order when repository evidence
requires a stricter dependency.

Completion rules

Research is complete when every owner-listed task has an evidence-backed task
document, internal links resolve, beta and production scope are explicit, and
Suggested Additions remain clearly separated for owner review. Delivery
checkboxes should only be updated from merged code, passing required
validation, or another cited durable result.

• Every owner-listed task has an evidence-backed task document.
• All 32 evidence-backed missing components have dedicated task documents.
• Beta and production scope and exit criteria are explicit per workstream.
• Cross-workstream dependencies and delivery order are recorded.
• Suggested additions are separated and decision-gated.
• The approved component and theming bundle-size additions are represented
  by one cross-workstream infrastructure task.
• All theming additions, Components additions 1, 3, and 4, and
  Infrastructure additions 1, 2, and 8 have issue-ready task documents.
• Internal Markdown links and anchors resolve.