# Guardrails Contract — Tag Badge Catalog (v1)

This feature enforces a single source of truth for tag-like (metadata) badge rendering and prevents regression back to ad-hoc tag colors.

## What is enforced (v1)

- Tag-like badges must not use forbidden health/status colors (`success|warning|danger`).
- Tag-like badges should be rendered via the centralized tag badge catalog on targeted surfaces.

Status-like badges remain governed by BADGE-001 and are out of scope for these guardrails.

## Guard strategy (v1)

### Mapping tests
- Tag badge mapping tests assert:
  - Canonical label normalization for representative values.
  - Palette invariants (allowlist only).
  - Unknown/unmapped fallback (“Other: <value>”).

### Lightweight repo guard
- A test scans the codebase and flags newly introduced forbidden colors used on tag-like badge surfaces.
- The guard is intentionally lightweight (pattern-based) to keep noise low and avoid blocking legitimate status-like semantics.

## Examples of patterns the guard should flag

- Tag-like table columns or Blade badges using `success`, `warning`, or `danger` colors to represent metadata.
- Newly introduced inline per-value color maps for tag domains that bypass the central catalog.

The exact patterns are defined by the guard test implementation and may be refined to reduce false positives.
