Components: Generate MessageBar

Summary

Generate MessageBar with its canonical contract, implementation, tests, stories, platform validation, and explicit package export so page- and section-level status feedback is covered. Existing component dependencies are sufficient, but this task must establish the cross-platform status-icon source also needed by Field and Toast.

Observed. message-bar is entry message-bar in the canonical catalog and has no
implementation in packages/agentic/components. Upstream describes it as: Composite status banner communicating page-level or section-level feedback across four semantic statuses (Information, Warning, Error, Success). Covers the status-driven color palette, icon slot conventions, optional action buttons, and the dismiss control.

Goal

Generate the message-bar component in
packages/agentic/components/src/components against the
canonical Fluent Flex spec, with the colocated coverage, stories, and platform
validation the package requires, and export it explicitly from
src/index.ts.

Stage

Stage 2 (beta). Wave 1 - local component dependencies already generated.

Why it matters

Observed. The canonical catalog has 50 components and the agentic library has
generated 18. message-bar is one of the 32 in the gap, enumerated in
the missing-components index.

Inferred. Every generated component dependency exists, but this task must
establish the shared cross-platform status-icon source before message-bar,
field, or toast can complete.

Observed current state

Canonical spec and source

Field	Value
Canonical spec	plugins/components/skills/message-bar/SKILL.md with usage.md, web/tokens.yaml, web/accessibility.md, and web/interaction.md, at x3-design/fluent-design @ d334acf
Upstream tier	molecule
Upstream catalog key	message-bar in component-map.yaml
Local staged spec	packages/agentic/components/specs/message-bar - SPEC.md, usage.md, interaction.md, accessibility.md, tokens.yaml, blockers.md
Local implementation	None. No src/components/message-bar directory exists

Closest existing FURN or V1 implementation

• packages/components/Notification - Notification.tsx, Notification.styling.ts, Notification.helper.tsx, and NotificationTokens.ts. NotificationTokens.ts is the cross-platform and desktop path; NotificationTokens.ios.ts is a mobile-only override.

Note on platform canon. Where a legacy package has platform-specific files, the
desktop path (.win32, .windows, .macos, or the unsuffixed cross-platform file)
is the compatibility reference. .ios, .android, and .mobile variants are not
treated as the cross-platform canonical implementation.

Local dependencies

• src/components/button - Observed present (component).
• src/primitives/icon - Observed present (primitive).

Known blockers

Observed (blockers.md, blocker class B in the index).

The recorded analysis states the layout, text, dismiss control, action buttons, role, and parent-owned dismissal are all implementable with the existing Button and Icon, and that the single blocker is the absence of a cross-platform source for the four Fluent status icons: "the repository does not provide the corresponding status icon font family or SVG source set for Windows + macOS".

Reassessment.

Still valid and narrow. The blocker is an asset-sourcing problem, not an architecture problem. Inferred: resolving the status icon source unblocks the whole component, and the same asset set is needed by toast and by field's validation state, so it is worth solving once.

Scope

• Ingest or promote the spec into the component directory in the generated shape
  (SPEC.md plus a spec/ folder), per
  spec-ingestion-and-generation.md.
• Establish the public contract first: variants, slots, native props, accessibility,
  interaction states, and platform behavior.
• Implement the required file structure from
  src/components/AGENTS.md:
  message-bar.types.ts, message-bar.styles.ts, use*.ts, use*Styles.ts, render*.tsx, and
  the assembly module with a displayName.
• Style from Flex tokens first and record genuine token gaps rather than substituting
  unrelated values.
• Export the component, its public types, and the state, style, and render stages
  explicitly from src/index.ts under component-qualified unstable names.
• Resolve the status icon source for Windows and macOS. Check src/common/iconSources.ts first; extend it rather than adding a component-local mapping.
• Own that shared status-icon result for field and
  toast; those tasks consume it rather than creating parallel
  mappings.
• Keep dismissal parent-owned, matching the recorded analysis and the package's externally driven state rule.

Out of scope

• Changing the contract of an existing generated component, unless this task explicitly
  calls for it above; raise it as its own item.
• Building shared infrastructure owned by another task: overlay hosting
  (popover), roving focus (focus-zone.md), spec
  ingestion (spec-ingestion-and-generation.md),
  or the coverage contract (component-test-strategy.md).
• Migrating any legacy FURN consumer onto this component.
• Mobile platform support; the applicable upstream companion is web, retargeted to
  React Native for Windows and macOS.

Deliverables

• src/components/message-bar/ implementing the full required file structure.
• SPEC.md and a spec/ companion folder with provenance recording the upstream path,
  SHA, and ingestion date.
• Colocated message-bar.test.tsx, message-bar.types.test.ts, and message-bar.stories.tsx.
• Snapshot coverage where the visual contract is state-dependent, or a recorded
  exemption.
• Explicit exports from src/index.ts, with src/index.test.ts updated.
• A changeset, per the repository's version management rules.
• A recorded readiness level with its supporting evidence.

Required coverage, stories, and platform validation

Runtime and type coverage:

• All four statuses, each with its icon and palette.
• Action buttons present, absent, and multiple.
• Dismiss control present and absent; dismiss reports through the caller's handler and does not self-hide.
• Live-region or alert accessibility semantics appropriate to each status.
• Constrained-width layout with long message text.
• User style and handler forwarding, and that user styles are applied after component
  styles.
• Compile-time slot acceptance and any mutually exclusive props.

Stories: a typed Meta titled Components/MessageBar, an args-driven Default, a
grouped Overview when the contract has several axes, one focused story per variant
axis, and an interactive story for each stateful axis. Self-driving axes expose
default<State> as the control; externally driven selection is owned by the story with
React.useState. Identity-changing axes are not exposed as controls.

Platform validation: the component's stories render and behave correctly on macOS
and on React Native Windows Fabric through apps/storybook,
including hover, pressed, disabled, focus, optional-slot, and constrained-content
scenarios. Add a stable root testID if the component joins the automated smoke set.

Acceptance criteria

• src/components/message-bar exists with the required file structure and a displayName.
• Every variant axis in the component's SPEC.md is implemented, or a deviation is recorded in the spec.
• The component styles from Flex tokens, with any genuine token gap recorded rather than approximated.
• Focus feedback renders through FocusVisual; no outline* props and no React Native Windows native focus visuals are introduced.
• State precedence is explicit: disabled wins over pressed, which wins over hovered.
• Every stateful axis is classified as self-driving or externally driven, and both paths are covered.
• Runtime, type, and story coverage satisfy the package coverage contract.
• The component, its public types, and its pipeline stages are exported explicitly from src/index.ts, and src/index.test.ts covers them.
• The component's stories render on macOS and on React Native Windows Fabric.
• yarn workspace @fluentui-react-native/components format, lint, build, and test pass, and the Storybook bundle succeeds for both desktop platforms.
• A readiness level is recorded with its supporting evidence.
• A changeset is included.

Dependencies and ordering

• Gated by component-test-strategy.md: the component must satisfy the coverage contract on arrival rather than being retrofitted.
• Gated by readiness-model.md: the target readiness level must be stated before the work starts.
• Consumes the Infrastructure workstream (storybook-e2e.md) for automated macOS and Windows Fabric validation; until it lands, platform validation is manual.

Risks and open decisions

1. The status icon asset decision is shared with toast and field; solving it locally would duplicate it three times.
2. React Native has no direct equivalent of an ARIA live region on every desktop platform; the announcement behavior must be verified on macOS and Windows Fabric rather than assumed.

Evidence and references

• Upstream spec: plugins/components/skills/message-bar/SKILL.md and
  components-index/SKILL.md
  at x3-design/fluent-design @ d334acf.
• Local staged spec and blocker record: packages/agentic/components/specs/message-bar.
• Canonical implementations to follow: src/components/button
  for a styled higher-order component and src/primitives/icon
  for a primitive.
• Authoring rules: src/components/AGENTS.md and the
  agentic component authoring skill.
• Workstream context: Components README and
  the missing-components index.

Sources retrieved 2026-08-20.

Start with packages/agentic/components/specs/message-bar/SPEC.md and blockers.md, then inspect src/common/iconSources.ts and the legacy packages/components/Notification implementation. Review src/components/AGENTS.md before checking the component package and apps/storybook entry points. Done means the required implementation, tests, stories, exports, platform validation, spec provenance, changeset, and readiness evidence are complete, including the shared Windows and macOS status-icon source.