ahmido 0b6600b926 059-unified-badges (#71 )

## Summary
- centralize all status-like badge semantics via `BadgeCatalog`/`BadgeRenderer` and new per-domain mappings plus coverage for every affected entity
- replace ad-hoc badge colors in Filament tables/views with the shared catalog and add a guard test that blocks new inline semantics
- stabilize restore views by avoiding `@php(...)` shorthand so Blade compiles cleanly, and document BADGE-001 in the constitution/templates

## Testing
- `vendor/bin/sail php vendor/bin/pint --dirty`
- `vendor/bin/sail artisan test tests/Unit/Badges tests/Feature/Guards/NoAdHocStatusBadgesTest.php`
- `vendor/bin/sail artisan test tests/Feature/Monitoring/OperationsDbOnlyTest.php tests/Feature/Monitoring/OperationsTenantScopeTest.php`
- `vendor/bin/sail artisan test tests/Feature/RestoreRunWizardMetadataTest.php tests/Feature/Filament/SettingsCatalogRestoreApplySettingsPatchTest.php`

Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local>
Reviewed-on: #71

2026-01-22 23:44:51 +00:00

1.3 KiB

Raw Blame History

Guardrails Contract — Unified Badge System (v1)

This feature enforces a single source of truth for status-like badge semantics (status/health and severity/risk).

What is enforced (v1)

Status-like badges must not define meaning ad-hoc per page/resource/widget/view.
Central semantics must be used for status/health and severity/risk signals.

Tag/category chips are out of scope for v1 and are not blocked by these guardrails.

Guard strategy (v1)

Mapping tests

Each status-like badge domain has automated tests that assert canonical mappings and invariants.
Invariant example: success/completed must never be represented with warning/attention meaning.

Lightweight repo guard

A test scans the codebase and flags newly introduced ad-hoc status-like badge semantics patterns.
The guard is intentionally lightweight (pattern-based) to keep noise low while preventing regression.

Examples of patterns the guard should flag

Ad-hoc status/severity match blocks inside badge rendering logic for status-like fields.
Per-resource status badge color maps defined inline on list pages/widgets.
Custom Blade badge markup for status-like semantics when the central system exists.

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

1.3 KiB Raw Blame History