Cloudscape

Passes: 3, 3, 3

The Figma 2.0.3 file (full-file variable coverage, 703 resolved variables, 447 alias references) and the pinned style-dictionary source both show a layered raw -> alias/reference -> semantic/component token architecture. palette-values.ts holds raw hex primitives (colorGrey50 etc.); token-names.ts defines a ReferenceTokenName alias layer (colorPrimary/colorNeutral/colorError/etc. scales); one-theme/colors.ts and core token categories build semantic/component tokens that reference those aliases (e.g. colorBackgroundButtonPrimaryDefault: '{colorPrimary600}'); core/index.ts and one-theme/index.ts operationally assemble all ten token categories (color-palette, color-charts, color-severity, colors, typography, borders, motion, sizes, spacing, shadows) plus eight component-scoped contexts into an exported, built theme. The design-tokens documentation confirms the same CTI (Category>Type>Item>State) taxonomy is normatively documented with a themeable/light/dark matrix for 407 color tokens. A snapshot test (design-tokens.test.ts) operationally validates that the generated classic and visual-refresh token JSON (and its generated JSON schema) matches expectation, confirming the graph is actually built and shape-checked, not just described.

Selected anchor: Semantic layers and aliases are comprehensive and operational

Next anchor: The token graph is validated, measured, and maintained across consumers
Evidence needed: Score 4 requires the token graph to be validated, measured, and maintained across consumers; the only automated check observed is a same-repo snapshot test comparing two internal themes (classic, visual-refresh) to a stored snapshot: there is no evidence of cross-consumer measurement, drift detection, or maintained ownership metrics for the token graph itself.

Scope: foundation; system-wide. Evidence covers the foundation/token-generation layer and a full-file Figma variable export; it does not verify how individual component source files consume these tokens, nor does it cover internal test results referenced in governance.

What broke

No confirmed break.

Impact

Teams can rely on a stable, documented CTI naming/alias structure for building and theming products, but cannot yet cite an automated cross-consumer measurement of token graph health (e.g. drift or unused-alias detection across downstream packages).

Why

Evidence shows the layered token architecture is built and shape-tested within this repository, but no evidence packet source demonstrates measurement or maintenance of the graph across multiple external consumers.

What to change

Publish or surface evidence of cross-consumer token validation (e.g. a token-graph linter run against downstream theming-build/theming-runtime consumers, or adoption telemetry) to support a score of 4.

Evidence citations

• 925fe002c91a290304d7/figma-variable-summary.json, original source: lines 4-90
• 925fe002c91a290304d7/figma-variable-summary.json, original source: lines 99-121
• 9a0f2e03bdbcc9cdf76b/files/style-dictionary/core/palette-values.ts, original source: lines 5-25
• 9a0f2e03bdbcc9cdf76b/files/style-dictionary/utils/token-names.ts, original source: lines 4-15
• 9a0f2e03bdbcc9cdf76b/files/style-dictionary/one-theme/colors.ts, original source: lines 62-68
• 9a0f2e03bdbcc9cdf76b/files/style-dictionary/core/index.ts, original source: lines 24-35
• d0941996c36f90b26d7d/content.txt, original source: lines 15-36
• 9a0f2e03bdbcc9cdf76b/files/src/__tests__/snapshot-tests/design-tokens.test.ts, original source: lines 7-16

Passes: 3, 3, 3

Core low-level primitives: spacing (4px base unit, 10 Figma variables plus a documented scale), borders/radius (40 Figma variables spanning alert, badge, button, focus-ring, code-editor), shadows (14 variables), sizes (11 variables), icon sizing (5 variables), motion, and responsive breakpoints (breakpoints.scss defines an 8-step scale with up/down mixins): are documented in normative docs and implemented as discrete, reusable style-dictionary modules (borders.ts, sizes.ts, spacing.ts, shadows.ts, motion.ts) that are consumed through a single shared builder loop (core/index.ts tokenCategories) rather than duplicated per component. The spacing documentation directly cites consistent reuse of the same primitive scale across many unrelated component types (button, form field, container, tabs, grid, select, app layout, split panel, popover, cards, tutorial panel), and the sampled deep components (Toggle, Cards, Flashbar, Form field, Modal, Table) each bind to primitive variables from the same borders/sizes/spacing collections in Figma. This is direct, non-prose evidence of both comprehensiveness and consistent consumption via a cited shared mechanism, meeting anchor 3.

Selected anchor: Primitives are comprehensive and consistently consumed

Next anchor: Primitive coverage and adoption are measured and governed
Evidence needed: Anchor 4 requires measured and governed primitive coverage/adoption (for example, lint rules enforcing token-only styling, or a published adoption metric). No such measurement or governance artifact is present in the evidence packet.

Scope: foundation; system-wide. Cross-component consumption is directly observed only for the 10 resolved deep-component samples and the components explicitly named in normative spacing/breakpoint documentation; consumption by the remainder of the ~150+ catalog components is not individually verified in this packet.

What broke

No confirmed break

Impact

Product and component authors have a documented, reusable primitive layer rather than ad hoc values, reducing visual drift risk across surfaces, but there is no public signal of whether adoption is enforced or measured.

Why

Evidence shows the primitive set is centrally defined and imported once for the whole token build, and normative docs plus bound-variable data confirm reuse across varied component types.

What to change

Surface public evidence of primitive-adoption enforcement (for example, stylelint rules against raw px/hex values, or a published usage audit) to support anchor 4.

Evidence citations

• 925fe002c91a290304d7/figma-variable-summary.json, original source: lines 31-63
• 925fe002c91a290304d7/figma-variable-summary.json, original source: lines 144-165
• 925fe002c91a290304d7/figma-variable-summary.json, original source: lines 188-198
• 9a0f2e03bdbcc9cdf76b/files/style-dictionary/core/index.ts, original source: lines 24-35
• 9a0f2e03bdbcc9cdf76b/files/src/internal/styles/foundation/breakpoints.scss, original source: lines 6-18
• 3bf3ad465032403cabc9/content.txt, original source: lines 29-45

Passes: 3, 3, 3

Color mode (light/dark), density mode (comfortable/compact), and motion mode (default/disabled) are implemented as first-class, systematic dimensions in the style-dictionary architecture: utils/modes.ts defines createColorMode/createDensityMode/createMotionMode, and core/index.ts and one-theme/index.ts apply this shared `modes` array uniformly to every token category (color-palette, colors, typography, borders, motion, sizes, spacing, shadows) and to every visual context (compact-table, top-navigation, header, flashbar, alert, app-layout-toolbar) via addTokens/addContext calls in a single loop, not per-component special-casing. The Figma file independently confirms a Light/Dark mode dimension on the color-variable and color-charts-palette collections. Density is concretely evidenced in code (one-theme/spacing.ts: spaceFieldVertical comfortable/compact values). Responsive adaptation is documented as a systematic element-query mechanism tied to a defined breakpoint scale (breakpoints.scss), and theming/visual-context overrides are documented with a working code example (theming-docs). Accessibility guidance is extensive and cites concrete per-component practices (Table row-header semantics, Form field labeling, App layout heading order, Tabs focus styling). This constitutes direct, non-prose evidence that modes are systematically threaded through the token architecture and components, meeting anchor 3.

Selected anchor: Modes are systematic across tokens and components

Next anchor: Mode compatibility is continuously validated across supported consumers
Evidence needed: Anchor 4 requires mode compatibility to be continuously validated across supported consumers. The only automated artifact observed is a two-theme snapshot test for token JSON output (design-tokens.test.ts); there is no evidence of automated cross-mode (for example, dark+compact+RTL) regression testing or validation across multiple downstream consumer packages.

Scope: mixed; system-wide. Platform/bidirectionality (RTL) mode is referenced only as a documentation title in the llms.txt index and is not evidenced in this packet, so its systematic status is unknown; per-component automated accessibility test execution (vs. documented guidance) is likewise not directly observed.

What broke

No confirmed break

Impact

Applications get systematic, low-effort support for dark mode, density, reduced motion, responsive layout, and accessible interaction patterns because these are wired into the shared token build rather than reimplemented per component.

Why

The mode dimensions are implemented once in utils/modes.ts and consumed uniformly by both open-source theme builders, and are corroborated by the Figma file's own Light/Dark variable modes.

What to change

Publish evidence of automated, continuous validation of mode combinations (for example, visual regression across dark/compact/RTL permutations) across the packages that consume these tokens to support anchor 4.

Evidence citations

• 9a0f2e03bdbcc9cdf76b/files/style-dictionary/utils/modes.ts, original source: lines 3-25
• 9a0f2e03bdbcc9cdf76b/files/style-dictionary/core/index.ts, original source: lines 18-22
• 9a0f2e03bdbcc9cdf76b/files/style-dictionary/one-theme/spacing.ts, original source: lines 9-17
• 925fe002c91a290304d7/figma-variable-summary.json, original source: lines 16-30
• ae35a7bd403e54a14bcb/content.txt, original source: lines 41-54
• ec87dab9e2768f5dba72/content.txt, original source: lines 7-18
• d6ffc1c5decf6c9a61b4/content.txt, original source: lines 7-10
• 61084b9599fcd2c92b19/content.txt, original source: lines 61-69

Passes: 3, 3, 3

Cloudscape ships foundations as versioned, machine-consumable artifacts to more than one consumer type: the npm package @cloudscape-design/components (peerDependency react >=16.8.0, with an explicit build:react18 script and react18-aliased devDependencies for a second React major-version consumer), companion published packages consumed as dependencies (@cloudscape-design/theming-runtime, @cloudscape-design/component-toolkit, and theming-build used by the style-dictionary pipeline), a generated JSON design-tokens artifact plus its JSON schema (validated by a snapshot test), and a separately versioned Figma Community design library (2.0.3) explicitly documented as independent from the daily-published React package. Build-time theming additionally generates a themed component + design-token package via buildThemedComponents, showing artifact generation is a real, invokable mechanism, not just a description.

Selected anchor: Multiple consumers receive consistent versioned artifacts

Next anchor: Delivery contracts are validated and migration impact is measured
Evidence needed: Score 4 requires delivery contracts to be validated and migration impact measured; no changelog/semver-diff tooling, consumer-impact measurement, or breaking-change gate was evidenced: only shape-level snapshot validation of generated token JSON.

Scope: foundation; system-wide. Evidence confirms the delivery mechanism and versioning scheme structurally, but does not include registry-level confirmation of the exact evaluated npm version's contents, nor any migration-impact measurement across consumer upgrades.

What broke

The pinned repository snapshot's package.json declares version 3.0.0, while the assignment's evaluated npm version is 3.0.1348; the evidence packet does not contain the corresponding published package.json to directly confirm artifact contents at that exact published version.

Impact

This is a traceability gap rather than a capability failure: it does not undermine the observed delivery mechanism (versioned multi-consumer artifacts), but it means the exact published-version artifact contents were not independently confirmed against the pinned repository source in this evidence set.

Why

Cloudscape's own governance evidence states additional internal testing occurs before npm publication, consistent with the main-branch package.json (3.0.0) differing from a later auto-incremented published patch version (3.0.1348); the repository and npm registry are versioned independently by design.

What to change

Include the published npm package.json (or registry metadata) for the exact evaluated version alongside repository source, and add migration-impact evidence (e.g. semver-diff or changelog-linked breaking-change reports) to support a score of 4.

Evidence citations

• 9a0f2e03bdbcc9cdf76b/files/package.json, original source: lines 1-9
• 9a0f2e03bdbcc9cdf76b/files/package.json, original source: lines 21-27
• 9a0f2e03bdbcc9cdf76b/files/package.json, original source: lines 50-52
• ae35a7bd403e54a14bcb/content.txt, original source: lines 144-171
• 9a0f2e03bdbcc9cdf76b/files/src/__tests__/snapshot-tests/design-tokens.test.ts, original source: lines 7-16
• 25b3525c021ca3ca39bc/content.txt, original source: lines 11-15

Passes: 3, 2, 3

Every sampled Figma component-set name maps through a consistent, predictable transform onto its code component identifier (Title Case with optional '(Atom)' suffix for atomic components ↔ PascalCase TypeScript component name), and the one structural divergence (Button) decomposes into four Figma sets whose names match the code's Variant enum values one-for-one, with an explicit system-authored 'compound' disposition and rationale in the coverage profile. Spinner's absence from the Figma file is likewise explicitly recorded as a design-evidence boundary, not left as an unexplained naming gap. No automated naming-parity checking or drift measurement was found, which excludes the top anchor.

Selected anchor: Names are systematically aligned across surfaces

Next anchor: Parity is automatically checked and drift is measured
Evidence needed: No evidence of an automated naming-parity check (for example, a lint rule, Code Connect script, or CI job) that measures or reports naming drift between the Figma library and the npm package: required for the automated-validation anchor.

Scope: deep-component; sample-only. Only the declared deep-component sample was checked against name transforms; the remaining component sets in the 154-set Figma catalog were not individually verified, so this finding cannot be generalized to the full catalog without further sampling.

What broke

No confirmed break: sampled component names in Figma follow a consistent, predictable transform (Title Case plus an '(Atom)' suffix for atomic components) that maps cleanly onto each component's PascalCase code identifier and, for Button, onto its variant enum values.

Impact

Practitioners can reliably locate the Figma asset for a given code component (or vice versa) using a predictable naming convention, without needing a manual lookup table.

Why

Cross-referencing figma-sample-details.json component-set names (for example, 'Toggle (Atom)', 'Modal', 'Primary button (Atom)') against the corresponding TypeScript component/prop names in cloudscape-component-implementation (for example, ToggleProps, ModalProps, ButtonProps.Variant='primary') shows a one-to-one, predictable name transform for every sampled component, and the figma-sample-resolution.json disposition fields explicitly document the two structural exceptions (Button compound, Spinner not-observable).

What to change

None required for the sampled set; extend the same explicit disposition/rationale metadata already used for Button and Spinner to the remaining catalog components so naming decisions are documented system-wide rather than inferred by a reviewer.

Evidence citations

• 925fe002c91a290304d7/figma-sample-details.json, original source: lines 79-101
• 925fe002c91a290304d7/figma-sample-details.json, original source: lines 1311-1334
• 925fe002c91a290304d7/figma-sample-resolution.json, original source: lines 279-288
• 5ac75e6e6b3f117f6eb1/files/src/button/interfaces.ts, original source: lines 224-225
• 5ac75e6e6b3f117f6eb1/files/src/spinner/interfaces.ts, original source: lines 9-33

Passes: 1, 2, 2

Core consumer-controlled choices correspond well across the sample: Toggle's Selected variant maps to the checked state, Flashbar's Content/Type combination maps to the loading prop, Button's compound atom structure maps to the variant enum, and hover/hidden runtime concerns are justifiably excluded via derived_mapping and runtime_only classifications. However, two concrete surface-specific controls in the sample are neither supported on the counterpart surface nor explicitly classified as design-only or runtime-only in the evidence: Figma's Button Type variant includes 'Dropdown'/'Dropdown+Main' options absent from ButtonProps.Variant, and Figma's Modal Size variant (Small/Medium/Large/Max) omits the x-large/xx-large values ModalProps.Size supports. Because these gaps are unexplained rather than justified exclusions, the sample does not meet anchor 3's requirement that 'surface-specific controls are explicitly classified.'

Selected anchor: Core consumer choices correspond through documented APIs or runtime mechanisms, with justified surface-specific controls excluded

Next anchor: Supported choices, derived states, slots, and composition map coherently, and surface-specific controls are explicitly classified
Evidence needed: Reaching anchor 3 requires that every surface-specific control in the sample be explicitly classified; the Button Dropdown/Dropdown+Main Type options and the Modal x-large/xx-large size values are unexplained gaps with no documented disposition in the evidence packet, so they remain genuine_gap rather than justified exclusions.

Scope: deep-component; sample-only. Property-by-property correspondence was directly checked for button, modal, toggle, flashbar, and table; app-layout, cards, form-field, input, side-navigation, and spinner were not individually mapped property-by-property in this analysis and may exhibit different correspondence quality.

Binding mappings

• Button variant (Primary/Normal/Link/Icon): shared_contract; design: Four separate Figma component sets: Primary button (Atom), Normal button (Atom), Link button (Atom), Icon button (Atom); code: ButtonProps.variant: 'normal' | 'primary' | 'link' | 'icon' | 'inline-icon' | 'inline-link'. The evaluation's declared design disposition classifies this as compound: the four independently-confirmed Figma sets collectively represent the single code variant enum, so the consumer-controlled 'variant' choice is honored across surfaces even though it is not modeled as one Figma component set.
• Button Type='Dropdown'/'Dropdown+Main' (Normal/Primary/Icon button atoms): genuine_gap; design: Type variant option list includes 'Dropdown' and 'Dropdown+Main' alongside 'Text only', 'Text + icon', 'External link'; code: ButtonProps.Variant has no 'dropdown' value; dropdown-trigger behavior is not exposed on the Button component in the supplied interfaces.ts. No design disposition or rationale in the evidence packet explains why the Button Figma atoms include dropdown-trigger Type options with no counterpart in ButtonProps.Variant; this is an unclassified, unexplained gap rather than a justified authoring-only or runtime-only control.
• Toggle checked/Selected state: shared_contract; design: Toggle (Atom) 'Selected' variant: Off/On; code: ToggleProps.ChangeDetail.checked: boolean (event payload for the controlled checked state). Figma's binary Selected variant corresponds directly to the boolean checked state that Toggle's onChange event and controlled usage pattern manage in code.
• Flashbar loading indicator: derived_mapping; design: Flashbar component set: Content variant ('Progress'/'Text') combined with Type='Info in loading state'; code: FlashbarProps.MessageDefinition.loading?: boolean, which replaces the status icon with a spinner and forces the type to info. The design models loading as a combination of two variant dimensions while code exposes it as a single loading boolean that forces type; the same meaning (a loading flashbar) is expressed through different but equivalent mechanisms.
• Modal size options: genuine_gap; design: Modal component set 'Size' variant: Small (320px), Medium (600px), Large (820px), Max; code: ModalProps.Size: 'small' | 'medium' | 'large' | 'x-large' | 'xx-large' | 'max'. Code supports two additional fixed sizes (x-large, xx-large) with no corresponding Figma variant option, and the evidence packet contains no rationale explaining the omission.
• Button hover state: derived_mapping; design: Normal/Primary/Icon/Link button atoms' 'State' variant includes 'Hover' alongside 'Default'/'Disabled'; code: No hover prop on ButtonProps; hover is implemented via a CSS pseudo-state driven by design tokens such as colorBackgroundButtonNormalHover. Figma models hover as an explicit static variant frame for design review, while code achieves the same visual state through a :hover-driven token rather than a settable prop; this is a legitimate derived mapping between a design-time state variant and a runtime pseudo-state.
• Table responsive content preview (Content (D)/Content (S)): design_only; design: Table component set exposes 'Content (D)#683:0' and 'Content (S)#683:3' INSTANCE_SWAP properties to preview desktop vs. small-viewport table content in Figma; code: Not applicable -- TableProps has no desktop/small content-swap property; responsive rendering is handled automatically by the component at runtime. This is an authoring-time preview mechanism letting designers swap in different mock content per breakpoint frame; it has no necessary code prop counterpart because the shipped Table component determines its responsive layout automatically rather than through an author-supplied breakpoint variant.
• Modal onDismiss: runtime_only; design: Not applicable -- the Modal component set's property definitions (Content, Size) do not model a dismiss event; code: ModalProps.onDismiss: NonCancelableEventHandler<ModalProps.DismissDetail>, fired on close-button click, overlay click, or Escape key. onDismiss is an event handler wired to application routing/state and has no necessary static Figma property; this is a justified runtime-only control excluded from parity comparison.

What broke

Figma's Button atoms (Normal/Primary/Icon) expose Type options 'Dropdown' and 'Dropdown+Main' with no corresponding ButtonProps.variant value, and Figma's Modal Size variant set (Small/Medium/Large/Max) omits the x-large and xx-large values present in ModalProps.Size, with neither gap explained by a documented disposition in the evidence packet.

Impact

A designer selecting a Dropdown-type Button atom in Figma cannot produce that exact configuration with the shipped Button component (dropdown-trigger behavior lives on a different component), and a designer authoring an x-large or xx-large modal spec has no matching Figma size option to reference, creating unexplained handoff friction for those specific configurations.

Why

figma-sample-details.json lists 'Dropdown' and 'Dropdown+Main' among the five Type variant options for the Normal button (Atom) set (node 12669:4938), while ButtonProps.Variant in button/interfaces.ts enumerates only normal/primary/link/icon/inline-icon/inline-link; similarly the Modal (Atom) Size variant (node 12669:37215) lists only four options while ModalProps.Size in modal/interfaces.ts adds 'x-large' and 'xx-large'.

What to change

Classify the Dropdown/Dropdown+Main Button Type options as design_only (representing the trigger portion of the separate ButtonDropdown component) or add matching code support; extend the Modal Figma component set's Size variant to include x-large/xx-large, or publish a rationale for their exclusion from the design library.

Evidence citations

• 925fe002c91a290304d7/figma-sample-details.json, original source: lines 1303-1310
• 5ac75e6e6b3f117f6eb1/files/src/button/interfaces.ts, original source: line 225
• 925fe002c91a290304d7/figma-sample-details.json, original source: lines 531-541
• 5ac75e6e6b3f117f6eb1/files/src/modal/interfaces.ts, original source: line 110
• 925fe002c91a290304d7/figma-sample-details.json, original source: lines 55-62
• 5ac75e6e6b3f117f6eb1/files/src/toggle/interfaces.ts, original source: lines 53-55
• 925fe002c91a290304d7/figma-sample-details.json, original source: lines 288-300
• 5ac75e6e6b3f117f6eb1/files/src/flashbar/interfaces.ts, original source: lines 16-17
• 5ac75e6e6b3f117f6eb1/files/src/modal/interfaces.ts, original source: line 91
• 925fe002c91a290304d7/figma-sample-details.json, original source: lines 637-664

Passes: 2, 2, 2

Foundation variable coverage is full-file (not sampled), giving broad visibility into the Figma token model. Color tokens show strong identity and mode parity: the Figma color-variable collection (283 variables, Light/Dark modes) matches code's paired light/dark token objects (for example, colorGreyOpaque70) and the normative token docs' CTI-style semantic naming (for example, $color-background-button-normal-hover). However, the Figma spacing collection exposes only a single mode ('Value', 10 variables) while the implementation applies a distinct comfortable/compact density mode to spacing tokens (confirmed by createDensityMode() and one-theme spacing overrides with different comfortable/compact values, and documented on the public tokens page with separate Comfortable/Compact columns). Additionally, the raw Figma variable count for colors (615) is not reconciled against the 407 colors documented on the public design-tokens page. These are documented, evidence-based gaps rather than a full identity-and-mode match, placing the sample at anchor 2 rather than anchor 3.

Selected anchor: Core semantic tokens align with documented gaps

Next anchor: Token identity and modes align across design and code
Evidence needed: Reaching anchor 3 would require the Figma spacing collection to model a comfortable/compact density mode matching the code's createDensityMode dimension, and a reconciliation of the raw Figma variable count (703 total / 615 color) against the number of tokens documented on the public design-tokens page (407 colors), since this gap is currently unexplained in the evidence.

Scope: foundation; system-wide. Foundation variable coverage is stated as full-file rather than a sample, supporting a system-wide claim about the token model; however, the unexplained 615-vs-407 color-count discrepancy between the raw Figma variable export and the publicly documented token table was not reconciled within the evidence packet, and data-visualization-specific colors are covered on a separate documentation page not included here.

What broke

The Figma 'spacing' variable collection models only a single mode ('Value', 10 variables), while implementation spacing tokens branch into comfortable/compact density modes (confirmed by createDensityMode() and by one-theme/spacing.ts overriding several spacing tokens with distinct comfortable/compact values, and documented publicly with separate Comfortable/Compact columns for spacing tokens such as $space-alert-vertical: 8px/4px).

Impact

Designers working from the Figma spacing variables cannot see or select the compact-density spacing values the shipped component library applies in compact mode, so density-mode layouts may drift from the design source unless manually cross-referenced against the separate token documentation table.

Why

figma-variable-summary.json lists the spacing collection with a single mode object named 'Value' covering all 10 spacing variables, while style-dictionary/utils/modes.ts defines a 'density' mode with comfortable/compact states, and one-theme/spacing.ts sets spaceFieldVertical to { comfortable: '4px', compact: '2px' } -- a distinction the design-tokens documentation also surfaces via separate Comfortable/Compact mode columns.

What to change

Extend the Figma spacing variable collection with a density mode dimension mirroring the code's comfortable/compact modes, or explicitly document that spacing density is intentionally an implementation-only concern not modeled in the design source.

Evidence citations

• 925fe002c91a290304d7/figma-variable-summary.json, original source: lines 31-41
• 9a0f2e03bdbcc9cdf76b/files/style-dictionary/utils/modes.ts, original source: lines 11-17
• 9a0f2e03bdbcc9cdf76b/files/style-dictionary/one-theme/spacing.ts, original source: lines 9-17
• d0941996c36f90b26d7d/content.txt, original source: line 520
• 925fe002c91a290304d7/figma-variable-summary.json, original source: lines 16-30
• 9a0f2e03bdbcc9cdf76b/files/style-dictionary/visual-refresh/colors.ts, original source: line 12
• 925fe002c91a290304d7/figma-variable-summary.json, original source: lines 589-594
• d0941996c36f90b26d7d/content.txt, original source: line 39

Passes: 2, 2, 3

Each sampled component documentation page provides maintained, component-scoped links to the design library, source code, and API properties. The collected component API and implementation interfaces document supported properties and events while marking superseded APIs as deprecated, including Table’s visibleColumns, AppLayout’s contentHeader and disableContentHeaderOverlap, and Flashbar’s buttonText and onButtonClick. This supports the anchor that core assets have maintained references. However, no public evidence shows a maintained cross-surface mapping from specific Figma components and properties to corresponding code components and properties, or an automated mechanism detecting drift between them.

Selected anchor: Core assets have maintained references

Next anchor: Versioned mappings expose supported and deprecated APIs
Evidence needed: A publisher-maintained, versioned Figma-to-code mappingNot availablesuch as Code Connect or an equivalent manifestNot availablecovering current and deprecated design-side assets is needed to establish cross-surface traceability.

Scope: mixed; sample-only. Only the sampled components' interface files and doc pages, plus the public release workflows, were inspected; internal design-review or governance processes that might strengthen traceability are outside this public evaluation's declared governance scope, per the governance known_limitations.

What broke

No unexplained failure was found in the maintained per-component references, but no versioned design-to-code identifier mapping (for example, Code Connect) exists to expose deprecated design assets alongside deprecated code props the same way the component-api manifest does for code alone.

Impact

Consumers can find the right doc/code/design entry point per component via maintained links, and can discover deprecated code props from the manifest, but nothing currently flags a Figma asset as stale relative to a specific code API change, so drift between design and code deprecations would go undetected until manually reviewed.

Why

Every sampled component's documentation page (Button, Table, App layout, Flashbar, Form field, Modal, Toggle, Side navigation, Cards, Input) carries dated, component-scoped 'Browse code' and 'Get design library' links, and the versioned component-api.json documents deprecated props such as Table's visibleColumns and AppLayout's contentHeader/disableContentHeaderOverlap; no Code Connect dependency, workflow step, or Figma-node-to-code-identifier manifest appears in the release-governance workflows or package.json dependencies.

What to change

Publish a versioned Figma-to-code identifier mapping (or adopt Code Connect) so deprecated or renamed design assets can be traced to their code equivalents the same way deprecated code props already are traced within the component-api manifest.

Evidence citations

• e273bdf592e031a7dd7b/content.txt, original source: line 5
• 228b6d8d6230ed435338/content.txt, original source: line 5
• 5ac75e6e6b3f117f6eb1/files/src/table/interfaces.tsx, original source: line 345
• 5ac75e6e6b3f117f6eb1/files/src/app-layout/interfaces.ts, original source: lines 182-192
• 5ac75e6e6b3f117f6eb1/files/src/flashbar/interfaces.ts, original source: lines 175-182
• b34144cf3ef4b623c2d1/content.txt, original source: line 1

Passes: 3, 3, 3

The public catalog (cloudscape-llms-index, cloudscape-component-api) documents over 100 components spanning layout, navigation, forms, data display, feedback, and charts: comprehensive breadth for a general enterprise console product scope. The Figma library independently maps matching component sets for the declared deep-component sample (Toggle, Cards, Flashbar, Form field, Modal, Button variants, Table, App layout, Side navigation), corroborating that catalog breadth extends into the design surface, not just code. This satisfies the anchor's single clause (comprehensive coverage for stated scope) without reaching the measurement anchor.

Selected anchor: Coverage is comprehensive for the stated scope

Next anchor: Gaps, adoption, and component health are measured
Evidence needed: No public evidence of measured adoption, gap tracking, or component health metrics (required for score 4); cloudscape-governance known_limitations explicitly states adoption dashboards and internal test results are outside this public evaluation.

Scope: catalog; system-wide. Catalog presence proves breadth and inventory only; it does not by itself prove deep state, accessibility, or responsive quality for every listed component: only the declared deep-component sample was inspected in depth for this evaluation.

What broke

No confirmed break

Impact

Teams building common enterprise-console product surfaces (forms, tables, cards, navigation, feedback, charts) can rely on a documented, first-party component for most needs rather than building custom one-offs

Why

cloudscape-llms-index and cloudscape-component-api jointly enumerate over 100 documented components with full API declarations, and cloudscape-figma independently confirms matching component sets for the sampled deep components

What to change

Publish a public catalog gap-analysis, adoption, or component-health dashboard to support a higher (4) score in future evaluations

Evidence citations

• 58abc1f907e6f691c0eb/content.txt, original source: lines 28-121
• b34144cf3ef4b623c2d1/content.txt, original source: line 1
• 925fe002c91a290304d7/figma-sample-details.json, original source: lines 79-101

Passes: 3, 3, 3

Within the declared sample, several components have both a rich state model in code and direct test evidence: Button's disabled/loading/disabledReason behavior is exhaustively tested (tooltip open/close on focus, blur, hover, and Esc; aria-disabled vs disabled; tab-order skip); FormField's error/warning text and debounced live-region character count are tested; Flashbar's type/loading states and alert-vs-status focus behavior on add/dismiss are tested; Table's interfaces define a four-state loader (pending/loading/finished/error) plus skeleton and empty slots. System-authored pattern docs (validation, loading-and-refreshing, empty-states) give explicit, component-referenced guidance tying these states together across the declared flow and patterns. This satisfies 'comprehensive ownership and guidance' for the well-evidenced subset, but permission-specific behavior is not directly evidenced (only disabledReason as an analog), and input/toggle/side-navigation/cards/spinner state transitions are only supported by interface declarations rather than visible test excerpts in this packet, so the anchor is met unevenly across the full declared sample.

Selected anchor: Normal and recovery states have comprehensive ownership and guidance

Next anchor: State contracts are executable, tested, and measured
Evidence needed: No execution/measurement evidence (CI pass/fail results, coverage dashboards) ties these state contracts to continuous testing; permission-specific state behavior and state-transition tests for input, toggle, side-navigation, cards, and spinner are not directly shown in this packet, so a score of 4 is unsupported.

Scope: mixed; sample-only. Findings apply to the declared deep-component and composition sample and do not establish state behavior for catalog components outside this sample.

What broke

No confirmed break at the comprehensive-guidance level, but permission-state evidence and cross-sample automated-test evidence are thin

Impact

Consumers can rely on documented/tested state contracts for button, form-field, flashbar, and table's loader model, but should independently verify state behavior for input, toggle, side-navigation, cards, and spinner, and should not assume permission-denied handling matches disabledReason's tested pattern without checking

Why

Evidence favors deep coverage on a subset of the declared sample (button, form-field, flashbar, table interfaces) while other declared components/compositions show only design-level or documentation-level support in this packet

What to change

Provide direct unit/integration test evidence for input, toggle, side-navigation, cards, and spinner state transitions, and for permission-denied scenarios, to substantiate a higher score

Evidence citations

• 5ac75e6e6b3f117f6eb1/files/src/flashbar/interfaces.ts, original source: lines 153-153
• 5ac75e6e6b3f117f6eb1/files/src/table/interfaces.tsx, original source: lines 481-511
• 2601b913b69dcea6b4ee/content.txt, original source: lines 56-78
• 52e4c7492e153c75ccff/content.txt, original source: lines 14-21
• eded4765c42d7ec57cd7/content.txt, original source: lines 7-38

Passes: 3, 3, 3

Cloudscape’s responsive-development guidance defines a system-wide mechanism in which components adapt to the width of their containing element using predefined breakpoints rather than relying only on viewport width. Collected test source encodes specific expected adaptations across the declared sample: Cards defines exact column counts at multiple container widths and after preference changes; AppLayout defines mobile behavior across supported visual themes; and Table defines different focus and horizontal-scroll behavior at narrow and wide viewports. Together, the normative mechanism and executable test definitions support consistent adaptation across the sampled conditions. Score 4 is not supported because no current CI or visual-regression execution results were observed across the complete supported condition matrix.

Selected anchor: Components adapt consistently across supported conditions

Next anchor: Responsive behavior is continuously tested across the matrix
Evidence needed: Current automated execution results covering the supported viewport, container, theme, density, and content matrixNot availablealong with tracked responsive regressionsNot availableare needed to establish continuous validation.

Scope: mixed; system-wide. The element-query mechanism is cited as applying system-wide, but only cards, app-layout, and table have direct executed test evidence in this packet; other catalog/deep components' responsive behavior is not independently confirmed here.

What broke

No confirmed break: responsive adaptation is documented via a system-wide element-query mechanism and directly exercised by tests across several sampled components and viewports.

Impact

Consumers assembling the create-configure-save flow (small/medium/large viewports) and loading/empty-state patterns can rely on tested, viewport-appropriate behavior for app-layout, cards, and table, reducing risk of layout breakage on resize.

Why

Executed tests assert concrete pixel-based behavior (breakpoint thresholds, mobile-forced states, scroll behavior) rather than only describing intent in prose.

What to change

Surface visual-regression/CI run results (for example, from the referenced visual-regression workflow) so responsive behavior can be confirmed as continuously validated rather than validated only at the point these test files were authored.

Evidence citations

• d6ffc1c5decf6c9a61b4/content.txt, original source: lines 5-9
• e0316b5e191225869ac3/files/src/cards/__integ__/responsive.test.ts, original source: lines 44-79
• e0316b5e191225869ac3/files/src/app-layout/__tests__/mobile.test.tsx, original source: lines 49-92
• e0316b5e191225869ac3/files/src/table/__integ__/keyboard-scroll.test.ts, original source: lines 10-44
• 6706222a7bf445fe2764/content.txt, original source: lines 267-278

Passes: 3, 3, 3

Within the declared sample, accessible behavior is comprehensively implemented and tested for several components: Button tests aria-disabled vs disabled, aria-describedby/hidden-text for disabledReason with focus/blur/hover/Esc-driven tooltip visibility, aria-expanded/aria-haspopup/aria-controls, and keyboard tab-order skipping of disabled buttons. Modal tests initial focus delegation, focus restoration, avoidance of stray focus capture, and keeping focused elements visible above a sticky footer. Flashbar tests ARIA role (alert vs status) selection and focus movement on add/dismiss, including debounced multi-item announcements. App layout tests aria-label/aria-expanded/aria-controls/role semantics for drawer, tools, and navigation triggers across themes and mobile. FormField associates a semantic <label> element and tests accessible error/warning icon text and debounced live-region character-count announcements. This is backed by a normative WCAG-aligned foundation doc citing specific Cloudscape components as accessibility exemplars. The gap to the top anchor is that dedicated a11y-regression test files (a11y-refresh-dark/light, table a11y.test.tsx) exist per the file listing but their content, results, or CI gating are not shown in this packet.

Selected anchor: Accessible behavior is comprehensive and tested

Next anchor: Assistive-technology coverage and regressions are continuously measured
Evidence needed: Dedicated automated accessibility-regression test files (a11y-refresh-dark.test.ts, a11y-refresh-light.test.ts, table/__tests__/a11y.test.tsx) exist per the file listing, but their content, pass/fail results, or CI gating were not included in this evidence packet, so continuous AT-coverage measurement cannot be confirmed for a score of 4.

Scope: mixed; sample-only. Findings are strongest for button, modal, flashbar, app-layout, and form-field; side-navigation and toggle show only minor accessibility test coverage, and input, cards, table, and spinner accessibility depth is not shown in this packet, so this should not be generalized to those components without further evidence.

What broke

No confirmed critical accessibility failure; the gap is limited to proof of continuous/measured AT-regression coverage

Impact

Consumers can rely on tested keyboard/focus/ARIA behavior for button, modal, flashbar, app-layout, and form-field; broader system-wide continuous AT monitoring is unconfirmed from this packet, and side-navigation, toggle, input, cards, table, and spinner accessibility depth is only lightly or not evidenced here

Why

Referenced a11y-specific test suite files (a11y-refresh-dark/light, table a11y.test.tsx) were listed as valid evidence paths in the packet's source repository but not excerpted with content

What to change

Include content/results from the a11y-refresh-dark/light test suites and table a11y.test.tsx, or CI gating configuration, to substantiate continuously-measured AT coverage

Evidence citations

• 61084b9599fcd2c92b19/content.txt, original source: lines 61-69

Passes: 3, 3, 3

Foundation documentation defines a 4px-based spacing scale with concrete usage mappings (e.g. 4px between form-field label and control, 40px app-layout content padding on large screens) and an application-layout anatomy (five named regions) plus a responsive mechanism (element queries against predefined breakpoints, not viewport). This is not merely prose: the app-layout code (interfaces.ts, index.tsx) implements the same contract observed in docs: contentType values ('default'|'form'|'table'|'cards'|'wizard'|'dashboard') drive default navigation/content-width behavior, and useAppLayoutPlacement computes responsive placement from header/footer selectors. The Figma sample for app-layout is fully resolved with 18 bound variable IDs on a single node, consistent with the declared full-file variable coverage. Together this covers the stated product scope (the app-layout-anchored flow and pattern samples) with primitives that are both documented and implemented, but no automated measurement of layout exceptions or breakpoint conformance was present in evidence, so anchor 4 is not reached.

Selected anchor: Layout primitives cover the stated product scope

Next anchor: Layout use and exceptions are validated and measured
Evidence needed: No observed automated validation or measurement of layout use/exceptions (e.g. breakpoint or visual-regression execution results) was present in the supplied evidence text, only test file paths without visible content, so 'validated and measured' cannot be scored.

Scope: mixed; system-wide. Foundation guidance and full-file variable coverage support system-wide layout primitives, but direct code/Figma cross-verification was only performed for the app-layout sample; per-component conformance to spacing tokens outside the sample was not independently checked.

What broke

No confirmed break

Impact

Teams can rely on a documented, code-consistent set of layout primitives (grid, spacing, app-layout regions, responsive element queries) for the declared product scope, but cannot point to measured evidence that exceptions or breakpoint drift are caught automatically.

Why

Foundation docs and app-layout code agree on the same contentType-driven layout contract, and Figma variable binding is full-file, but no automated breakpoint/visual-regression results were included in the evidence packet.

What to change

Surface CI visual-regression or breakpoint-conformance results (e.g. from the referenced app-layout-responsive visual tests) as directly cited evidence to support a higher anchor.

Evidence citations

• fcfe8d5259a492b07599/content.txt, original source: lines 13-33
• 3bf3ad465032403cabc9/content.txt, original source: lines 29-45
• d6ffc1c5decf6c9a61b4/content.txt, original source: lines 5-13
• 5ac75e6e6b3f117f6eb1/files/src/app-layout/index.tsx, original source: lines 94-108
• 925fe002c91a290304d7/figma-sample-details.json, original source: lines 5-24

Passes: 3, 3, 3

Composition rules are documented at the slot level for every component required by the declared flow/patterns: app-layout's notifications, navigation, tools, content, and splitPanel regions each have explicit placement rules (e.g. flashbar 'in the notification region of app layout'); cards and table docs both state that full-page variants 'must be the first component in the content slot'; modal specifies using space-between for multiple footer buttons. These rules are corroborated by the observed AppLayoutProps slot API (content, tools, notifications, navigation, splitPanel, drawers) in interfaces.ts, so the guidance is not merely prose disconnected from implementation. This covers the supported assemblies named in create-configure-save, loading-recovery, and empty-state-recovery, but no evidence shows these composition rules are enforced automatically (e.g. lint rule failing when cards aren't first in content), so anchor 4 is not reached.

Selected anchor: Composition contracts cover supported product assemblies

Next anchor: Composition rules are executable or automatically validated
Evidence needed: No automated or executable enforcement of composition rules (e.g. a lint/test failing if a full-page cards instance is not first in the content slot) was present in the evidence, so 'executable or automatically validated' cannot be scored.

Scope: composition; sample-only. Evidence establishes composition contracts only for the components named in the declared create-configure-save, loading-recovery, and empty-state-recovery samples; it does not establish a system-wide composition-validation mechanism applicable to components outside this sample.

What broke

No confirmed break

Impact

Developers assembling the declared create/loading/empty-state flows have concrete, component-linked slot rules to follow, reducing ambiguity about where each component belongs, but there is no automated guardrail evidenced to catch violations of those rules.

Why

Composition guidance is normative documentation cross-checked against the actual AppLayoutProps slot surface, but no lint, type-level, or test enforcement of ordering/placement rules (e.g. cards-first-in-content) was present in the supplied evidence.

What to change

Cite or add automated checks (lint rule, structural test) that fail when a documented composition rule (e.g. full-page cards not first in content) is violated, to support a higher anchor.

Evidence citations

• dbbb2396ec1b3d1896bc/content.txt, original source: line 199
• 228b6d8d6230ed435338/content.txt, original source: line 690
• 46fc909f4c7432b63a0f/content.txt, original source: lines 124-126
• f92f5b5440bc211f2a48/content.txt, original source: lines 21-23
• 6706222a7bf445fe2764/content.txt, original source: lines 265-322

Passes: 3, 3, 3

All three declared patterns are documented as reusable task patterns with explicit, lettered building blocks (single-page create: breadcrumbs, form page header, container, primary fields, expandable section, form actions, info link, help panel, side navigation) or state-by-state guidance (loading-and-refreshing: manual/automatic refresh, refreshing issues, skeleton vs. spinner loading; empty-states: empty state vs. zero-results state, each with heading/description/action-button building blocks), and each links directly to the components named in the coverage profile (table, cards, button, flashbar, spinner, form). This matches anchor 3's requirement that patterns cover important tasks and remain linked to components. The known limitation that no matching end-to-end Figma screen was claimed is consistent with these patterns being declared code+documentation surfaces only, not a design-surface gap. No adoption, outcome, or lifecycle measurement of pattern usage was present, so anchor 4 is not reached.

Selected anchor: Patterns cover important tasks and remain linked to components

Next anchor: Pattern use, outcomes, and lifecycle are measured
Evidence needed: No evidence of pattern usage, outcome, or lifecycle measurement (e.g. adoption analytics, deprecation tracking) was present in the supplied evidence, so 'pattern use, outcomes, and lifecycle are measured' cannot be scored.

Scope: composition; sample-only. Evidence covers only the three declared patterns and their linked components; it does not establish that all Cloudscape patterns (only three of which are in scope here) meet the same bar, nor does it confirm a matching Figma end-to-end screen exists for these patterns.

What broke

No confirmed break

Impact

Teams implementing create, loading/refresh, or empty-state flows have canonical, component-linked reference patterns to follow rather than having to invent structure per feature, but there is no evidence these patterns' real-world usage or outcomes are tracked.

Why

The three declared patterns are documented with explicit building blocks and direct component links across the required code and documentation surfaces (design was correctly excluded per the flow's known_limitations), but usage/lifecycle telemetry is outside public evidence.

What to change

If pattern adoption or outcome data exists internally, surface it publicly (or cite it) to support measurement-based scoring; otherwise this remains a documentation-level ceiling.

Evidence citations

• 33772e57e314f15ee702/content.txt, original source: lines 30-70
• 52e4c7492e153c75ccff/content.txt, original source: lines 14-21
• eded4765c42d7ec57cd7/content.txt, original source: lines 9-38
• eded4765c42d7ec57cd7/content.txt, original source: lines 39-71

Passes: 3, 3, 3

AppLayout’s documentation and implementation interfaces define controlled-state ownership for navigation, tools, drawers, and split panels, plus imperative focus contracts for responsive transitions. Routing guidance explains when state should be reset or when an AppLayout instance should be scoped to a route. Collected integration-test source encodes focus transitions across split panels, tools, drawers, navigation, and information links on mobile and desktop across supported visual themes. Modal guidance additionally defines dialog-nesting and focus-on-open ownership. This supports comprehensive navigation, focus, and state contracts for the AppLayout-centered create-configure-save flow. Loading-recovery and empty-state-recovery ownership remain supported primarily by prose guidance in the reviewed evidence, and no current CI execution results were observed.

Selected anchor: Navigation, focus, and state contracts are comprehensive

Next anchor: Cross-composition contracts are executable and continuously verified
Evidence needed: Current continuous-execution results for the AppLayout focus contracts, plus equivalent implementation or test coverage for loading-recovery and empty-state-recovery transitions, are needed to establish executable and continuously verified cross-composition ownership.

Scope: mixed; sample-only. Ownership evidence is strong and code-verified for app-layout compositions but is documentation-only for the loading-recovery and empty-state-recovery patterns; findings should not be generalized to table/cards async ownership without further code-level evidence.

What broke

No confirmed broken ownership behavior in the sampled tests; the gap is uneven evidence depth across the declared compositions.

Impact

The app-layout shell used by the create-configure-save flow has a strong, test-backed ownership contract for drawers, tools, navigation, and split panel, reducing risk of focus loss or state desync during responsive transitions. But loading-recovery and empty-state-recovery (table/cards refresh, error, and recovery transitions) rely on prose guidance only here, so ownership risk during async table/cards state changes (e.g. focus during a failed refresh) is less independently verified.

Why

The component-quality snapshot supplied deep integ-test coverage specifically for app-layout, while the loading-and-refreshing and empty-states pattern sources in this packet are documentation pages without accompanying table/cards ownership test files.

What to change

Extend automated focus/state-ownership testing analogous to app-layout-focus-delegation.test.ts to table and cards loading/error/recovery transitions, and surface CI run evidence (e.g. workflow results) for the existing app-layout tests to support scoring toward anchor 4.

Evidence citations

• e0316b5e191225869ac3/files/src/app-layout/__integ__/app-layout-focus-delegation.test.ts, original source: lines 44-131
• 6706222a7bf445fe2764/content.txt, original source: lines 20-37
• 5ac75e6e6b3f117f6eb1/files/src/app-layout/interfaces.ts, original source: lines 288-317
• f92f5b5440bc211f2a48/content.txt, original source: lines 178-182

Passes: 3, 2, 3

CODEOWNERS assigns a single named team as the mandatory reviewer/merger for the entire repository, and this is a technically enforced GitHub mechanism, not merely a policy statement. CONTRIBUTING.md operationalizes support boundaries: contribution scope is limited to bug fixes, general support runs through issues/discussions, and security issues are routed to a dedicated non-public vulnerability-reporting channel rather than public issues. Together these show decision rights and support boundaries functioning, but no public ownership-health or service-expectation metrics exist, so the evidence stops short of anchor 4.

Selected anchor: Decision rights and support boundaries are operational

Next anchor: Ownership health and service expectations are measured
Evidence needed: No public ownership health or service-expectation metrics (for example, response-time SLAs, staffing/coverage data) are evidenced, which anchor 4 requires.

Scope: governance; system-wide. Applies to the entire public components repository as declared, but cannot reveal internal AWS ownership records, per-component ownership detail, or ownership health metrics, which the governance evidence scope marks as outside public evaluation.

What broke

Ownership evidence is limited to one flat, repo-wide CODEOWNERS entry with no per-component ownership breakdown, and no ownership health or responsiveness metrics are published.

Impact

Consumers can see who has merge authority and what the support boundaries are, but cannot tell which team owns a specific component or how healthy/responsive that ownership is.

Why

CODEOWNERS is a single wildcard rule naming one team for the whole repository, and CONTRIBUTING.md's support-boundary language is a static policy statement with no accompanying metrics.

What to change

Publish component/area-level ownership detail and ownership health indicators (for example, response-time data, staffing coverage) to move toward measured ownership maturity.

Evidence citations

• c323861524416605c72f/files/.github/CODEOWNERS, original source: line 1
• c323861524416605c72f/files/CONTRIBUTING.md, original source: lines 13-21
• c323861524416605c72f/files/CONTRIBUTING.md, original source: lines 65-67

Passes: 3, 3, 3

CONTRIBUTING.md documents a fork-PR-review-merge path, and this is made operational by two independent mechanisms observed directly: an automated CI gate (build-lint-test.yml) that runs on every pull_request and merge_group event across a React 16/18 matrix, and a PR template checklist that requires authors/reviewers to evaluate correctness (docs, backward compatibility, browser support, manual accessibility testing), security (checkSafeUrl validation), and testing (unit/integration coverage) on every submission. This is cross-discipline and operational, but the packet contains no measurement of review outcomes or throughput, which anchor 4 requires.

Selected anchor: Cross-discipline review criteria and decisions are operational

Next anchor: Review quality, throughput, and outcomes are measured
Evidence needed: No evidence of measured review quality, throughput, or outcomes (for example, review latency, defect escape rate, rejection rate) is present, which anchor 4 requires.

Scope: governance; system-wide. Confirms CI triggers and template content apply repo-wide, but does not confirm branch-protection enforcement of code-owner review or actual historical review behavior/outcomes, which are outside the observable public evidence.

What broke

No confirmed break: the review path is documented and operational across correctness/security/testing dimensions, but review outcomes are not measured.

Impact

Contributors face a consistently enforced review gate (CI plus a cross-discipline checklist) before merge, giving reasonable confidence in per-PR review rigor, but the project cannot demonstrate consistency or effectiveness of that review over time.

Why

build-lint-test.yml triggers automatically on pull_request, merge_group, and push-to-main events; PULL_REQUEST_TEMPLATE.md requires evaluation of correctness, security, and testing on every PR, per the evidenced files.

What to change

Track and publish review/CI outcome metrics (for example, pass rates, review latency, post-merge defect rate) to support a higher score, and confirm whether code-owner review is enforced via branch protection.

Evidence citations

• c323861524416605c72f/files/CONTRIBUTING.md, original source: lines 13-30
• c323861524416605c72f/files/.github/PULL_REQUEST_TEMPLATE.md, original source: lines 18-35
• e0316b5e191225869ac3/files/.github/workflows/build-lint-test.yml, original source: lines 1-31

Passes: 2, 2, 2

GENERAL_GUIDE.md documents a clear versioning policy (daily patch releases, patch versions never containing breaking changes) and explicitly scopes the public API surface (component APIs, test utilities, design tokens; internal HTML/class names excluded from breaking-change consideration). API_DOCS.md documents a `@deprecated` tag convention requiring a replacement recommendation, and the llms.txt index references a dedicated charts migration guide. This satisfies anchor 2's documentation requirement, but the packet does not evidence an explicit, general operational contract for deprecation notice periods, support windows, or systematic migration tooling: only a tagging convention and one component-family migration guide: so anchor 3 is not fully supported.

Selected anchor: Versions and important changes are documented

Next anchor: Deprecation and migration have explicit operational contracts
Evidence needed: Anchor 3 requires deprecation and migration to have explicit operational contracts (for example, stated notice periods, support overlap windows, or systematic migration tooling/codemods). The packet only evidences a tagging convention plus one named migration guide (charts), not a general, enforced deprecation/migration policy, so this anchor is not fully met.

Scope: mixed; sample-only. Migration tooling evidence is limited to the charts component family; a general deprecation-timeline contract is absent from the public packet, and internal pre-publish testing outcomes referenced in CONTRIBUTING.md are explicitly out of scope for this public evaluation.

What broke

Deprecation and migration lack an explicit, generalized operational contract despite documented versioning and a deprecation-tag convention.

Impact

Consumers know the release cadence and that patch versions are non-breaking, but have no published guarantee of deprecation notice periods or systematic migration support beyond the charts component family.

Why

GENERAL_GUIDE.md documents versioning and public API scope, and API_DOCS.md documents the @deprecated tag, but no evidenced source states deprecation timelines, advance notice requirements, or migration tooling coverage beyond the named charts migration guide.

What to change

Publish an explicit deprecation/migration policy (notice period, supported overlap window, migration tooling scope) and extend migration guidance beyond charts to other breaking transitions.

Evidence citations

• cb0b0ebff7f7fd10b293/files/docs/GENERAL_GUIDE.md, original source: lines 19-31
• c323861524416605c72f/files/docs/API_DOCS.md, original source: line 9
• 58abc1f907e6f691c0eb/content.txt, original source: line 11

Passes: 3, 2, 3

Cloudscape has substantial automated quality gates across pull requests, merge queues, supported React versions, accessibility, visual regression, testing, and bundle size. However, the score-3 anchor requires quality gates to cover both the supported lifecycle and exceptions. The public evidence contains snapshot-update instructions but no governed waiver, bypass, approval, or exception-tracking process, so the directly supported anchor is 2: core automated checks or review gates exist.

Selected anchor: Core automated checks or review gates exist

Next anchor: Quality gates cover the supported lifecycle and exceptions
Evidence needed: Additional evidence must satisfy the next anchor: Quality gates cover the supported lifecycle and exceptions

Scope: governance; system-wide. These CI/test artifacts are repository-wide mechanisms, not per-component samples, but internal post-merge testing, waiver/exception governance, and adoption or regression metrics are outside the declared public governance evidence scope.

What broke

No confirmed break: a substantial, observably-triggered set of automated quality gates exists, but public evidence of exception/waiver governance and measured outcomes is absent.

Impact

Contributions are protected by real automated build, visual-regression, accessibility, and bundle-size checks, but there is no visibility into how exceptions to these gates are governed or whether gate outcomes (pass rates, flake rates, waivers granted) are tracked and acted on.

Why

The sampled CI configuration and test suites demonstrate gate existence and triggering conditions, but none of the evidenced files describe an exception process or expose aggregate gate-outcome metrics.

What to change

Document how exceptions to automated gates (for example, an accepted visual diff or a11y waiver) are recorded and tracked, and publish gate-outcome metrics (pass rates, flake rates) to support measurement-based scoring.

Evidence citations

• e0316b5e191225869ac3/files/.github/workflows/build-lint-test.yml, original source: lines 1-31
• e0316b5e191225869ac3/files/.github/workflows/visual-regression.yml, original source: lines 29-155
• cb0b0ebff7f7fd10b293/files/.github/workflows/bundle-size.yml, original source: lines 1-31