high priority medium complexity infrastructure pending infrastructure specialist Tier 5

Acceptance Criteria

A custom analyzer plugin or custom_lint rule package exists under `tools/` or `packages/` in the monorepo
The rule rejects any expression matching `Color(0x...)`, `Color.fromARGB(...)`, `Color.fromRGBO(...)`, or `Colors.*` used outside the DesignTokenProvider implementation file itself
The rule produces a descriptive diagnostic message referencing the DesignTokenProvider API to use instead
The rule is listed in analysis_options.yaml and activates without additional developer setup
`dart analyze` flags violations introduced in widget files with severity `error`
The DesignTokenProvider source file is excluded from the rule via `exclude:` patterns so it does not self-violate
Rule is documented with an example fix in `docs/lint-rules.md` or inline dartdoc
CI pipeline enforces the rule — PRs with hardcoded colors fail the analyze check

Technical Requirements

frameworks
Flutter
Dart analyzer
custom_lint (dart pub)
analyzer plugin API
data models
DesignTokenProvider
performance requirements
Plugin initialization adds no more than 2 seconds to `dart analyze` cold start

Execution Context

Execution Tier
Tier 5

Tier 5 - 253 tasks

Can start after Tier 4 completes

Implementation Notes

The lightest-weight approach is the `custom_lint` package (pub.dev), which lets you write lint rules as plain Dart without the full analyzer plugin boilerplate. Create a new Dart package (e.g., `packages/likeperson_lints`) with `custom_lint_builder` as a dependency. Implement a `DartLintRule` subclass that visits `InstanceCreationExpression` and `PrefixedIdentifier` AST nodes, checking for `Color` constructor calls and `Colors.*` references. Use `context.addError()` with a `Fix` suggestion pointing to `DesignTokenProvider`.

Add the package to the app's `dev_dependencies` and register it in `analysis_options.yaml` under `custom_lint > rules`. Exclude `lib/core/design_tokens/design_token_provider.dart` via the `exclude` list. This approach is preferred over a full analyzer plugin because it does not require `dart pub publish` and works with `dart analyze` in CI out of the box.

Testing Requirements

Write unit tests for the custom lint rule using the `custom_lint` test utilities (`testLint`). Test cases must cover: (1) Color literal in a widget file triggers error, (2) Color literal inside DesignTokenProvider file is suppressed, (3) DesignTokenProvider.of(context).primary usage passes with no diagnostic, (4) Colors.transparent used as a special case — decide policy and enforce it. Target 100% branch coverage on the rule visitor logic.

Component
Flutter Accessibility Lint Configuration
infrastructure low
Epic Risks (3)
high impact medium prob technical

The WCAG 2.2 relative luminance formula requires gamma-corrected sRGB calculations. Floating-point rounding differences between Dart and reference implementations could produce off-by-one classifications for near-threshold color pairs, resulting in pairs that just pass or just fail in CI but behave differently at runtime.

Mitigation & Contingency

Mitigation: Implement the algorithm directly from the WCAG 2.2 specification using the exact linearisation constants. Validate the Dart implementation against the W3C reference test vectors and against a known-good JavaScript implementation for at least 50 color pairs spanning the compliance boundaries.

Contingency: If discrepancies are found, add a configurable tolerance margin (e.g., ±0.005 on the ratio) and flag near-threshold pairs as warnings rather than hard failures, escalating to the design team for manual review.

medium impact high prob scope

The token manifest is a static data file. If developers add new color tokens to the design-token-provider without updating the manifest, the manifest becomes stale and the CI validator produces false negatives — passing builds that contain unvalidated color pairs.

Mitigation & Contingency

Mitigation: Add a CI step that cross-references every token constant exported by the design-token-provider against the manifest at build time, failing if any token is present in the provider but absent from the manifest. Document this requirement clearly in the contributing guide.

Contingency: If drift is detected post-merge, run a full manifest regeneration script and treat the resulting manifest diff as a blocking pull request with mandatory accessibility review.

medium impact medium prob dependency

The flutter_accessibility_lints package (or custom lint rules) may produce false positives on patterns the team deliberately uses — for example, decorative icon widgets that intentionally omit semantic labels. Excessive false positives will lead developers to add blanket ignore comments, undermining the entire lint strategy.

Mitigation & Contingency

Mitigation: Audit the full lint rule set against the existing codebase before enabling rules. Create a documented list of approved ignore-comment patterns with mandatory justification comments. Restrict ignore patterns to decorative-only contexts.

Contingency: If false positive rates exceed 10% of lint output, disable the highest-noise individual rules and replace them with targeted custom lint rules scoped to the specific patterns the team controls.