TenantAtlas/specs/234-dead-transitional-residue/research.md
ahmido 603d509b8f
Some checks failed
Main Confidence / confidence (push) Failing after 58s
cleanup: retire dead transitional residue (#270)
## Summary
- remove deprecated baseline profile status alias constants and keep baseline lifecycle semantics on the canonical enum path
- retire the dead tenant app-status badge/default-fixture residue from the active runtime support path
- add the `234-dead-transitional-residue` spec, plan, research, data-model, quickstart, checklist, and task artifacts plus focused regression assertions

## Validation
- not rerun during this PR creation step

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #270
2026-04-23 16:54:48 +00:00

42 lines
3.7 KiB
Markdown

# Phase 0 Research: Dead Transitional Residue Cleanup
## Decision: Remove the deprecated `BaselineProfile::STATUS_*` aliases entirely
**Rationale**: The only confirmed definitions of `BaselineProfile::STATUS_DRAFT`, `STATUS_ACTIVE`, and `STATUS_ARCHIVED` are in `apps/platform/app/Models/BaselineProfile.php`. No current `apps/platform` runtime or test reference still depends on those aliases. The canonical contract is already the `BaselineProfileStatus` enum cast, so keeping the constants adds dead language without serving current behavior.
**Alternatives considered**:
- Keep the aliases but leave them deprecated: rejected because they no longer protect any active caller and continue to advertise parallel truth.
- Replace them with forwarding helpers: rejected because that would add new residue to preserve dead semantics.
## Decision: Remove the tenant app-status badge domain from the central badge path
**Rationale**: The remaining runtime path for tenant app-status semantics is the central badge registry: `BadgeDomain::TenantAppStatus`, the `BadgeCatalog` mapper entry, and `TenantAppStatusBadge`. Current confirmed consumers are badge tests, not active tenant surfaces. Once the legacy badge domain has no runtime consumer, removing it centrally is cleaner than keeping it as diagnostic folklore.
**Alternatives considered**:
- Keep the badge domain as a dormant diagnostic mapping: rejected because no current runtime surface needs it and dormant central mappings make it easier to reintroduce dead semantics accidentally.
- Move the mapping into a test helper: rejected because test-only preservation would still keep the dead semantics alive as sanctioned language.
## Decision: Remove ambient `app_status` defaults from test and smoke setup
**Rationale**: `TenantFactory` still defaults `app_status` to `ok`, and `SeedBackupHealthBrowserFixture` still writes `app_status => 'ok'`. That keeps a retired value ambient in new tenant records and smoke data even though current tenant surfaces no longer depend on it. The safer contract is explicit legacy setup only where a test or fixture intentionally proves suppression.
**Alternatives considered**:
- Keep the default for convenience: rejected because convenience is exactly how dead semantics keep surviving.
- Remove `app_status` from every explicit test and fixture immediately: rejected because a few tests intentionally set historical values to prove they no longer surface as truth.
## Decision: Keep historical schema and stored fields out of scope
**Rationale**: The repo still contains historical migrations and the stored `tenants.app_status` column. This cleanup is about active runtime/support residue, not schema deletion. Removing columns or historical migrations would widen the slice beyond the approved cleanup boundary.
**Alternatives considered**:
- Drop the column now: rejected because the spec explicitly forbids schema work in this slice.
- Add a migration shim or deprecation wrapper: rejected because this is pre-production cleanup, not a compatibility exercise.
## Decision: Reuse existing tenant-truth and baseline-profile regressions instead of creating a new cleanup harness
**Rationale**: The current proof burden is continuity after residue removal. Existing tenant-truth feature tests and baseline-profile feature tests already exercise the active behavior we need to protect. A small badge-catalog unit slice is enough for the central registry cleanup. A new meta guard framework would add more long-term burden than value.
**Alternatives considered**:
- Add grep-driven guard tests for every removed symbol: rejected because behavior-facing tests are the primary proof and repo grep is sufficient as a review aid.
- Rely on manual inspection only: rejected because cleanup regressions are easy to reintroduce silently.