Summary: Upgrade Filament to v5 (Livewire v4), replace Filament v4-only plugins, add first-party JSON renderer, and harden Monitoring/Ops UX guardrails. What I changed: Composer: upgraded filament/filament → v5, removed pepperfm/filament-json and lara-zeus/torch-filament, added torchlight/engine. Views: replaced JSON viewer with json-viewer.blade.php and updated snapshot display. Tests: added DB-only + tenant-isolation guard tests under Monitoring and OpsUx, plus Filament smoke tests. Specs: added/updated specs/057-filament-v5-upgrade/* (spec, tasks, plan, quickstart, research). Formatting: ran Pint; ran full test suite (641 passed, 5 skipped). Validation: Ran ./vendor/bin/sail artisan test (full suite) — all tests passed. Ran ./vendor/bin/sail pint --dirty — formatting applied. Ran npm run build locally (Vite) — assets generated. Notes / Rollback: Rollback: revert composer.json/composer.lock and build assets; documented in quickstart.md. One pending app migration was noted during validation; ensure migrations are applied in staging before deploy. Reviewers: @frontend, @backend (adjust as needed) Spec links: spec.md tasks.md quickstart.md Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local> Reviewed-on: #66
1.3 KiB
1.3 KiB
Data Model: Admin UI Stack Upgrade (Filament v5 + Livewire v4)
This feature is a framework/UI dependency upgrade. No new domain entities are introduced.
Existing Entities (Referenced)
Tenant
- Purpose: tenant-scopes all UI data access.
- Key fields (existing):
id, tenant identity metadata. - Relationships:
Tenant→ manyOperationRun.
OperationRun
- Purpose: canonical Monitoring → Operations record per constitution.
- Key fields (existing, inferred from usage):
tenant_idtype,status,outcomeinitiator_namecreated_at,started_at,completed_at- JSONB: run context/failures/summary (per repo context)
- Relationships:
- belongsTo
Tenant.
- belongsTo
Schema / Migration Expectations
Decision: No database schema changes intended
- Rationale:
- Filament/Livewire upgrade does not require domain schema changes.
- Spec allows migrations only if strictly required by dependencies; current plan avoids introducing such requirements.
Guardrails (if a migration becomes necessary)
- Must be reversible with a safe
down(). - Must be non-destructive (no data loss; avoid drops unless explicitly planned).
- Must be called out in release notes.
Validation Rules / State Transitions
- No new validation rules.
- No new state machines.
- Existing
OperationRunstatus/outcome conventions remain unchanged.