ahmido
38523814c2
## Summary - restore broad full-suite green-signal coverage across platform governance, operations, onboarding, dashboard/productization, and customer review flows - align related platform tests and supporting behavior with the current expected state for this restoration pass - update the spec-candidates queue as part of the same suite-restoration sweep ## Validation - `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Browser/Dashboard/TenantDashboardProductizationSmokeTest.php tests/Browser/Reviews/CustomerReviewWorkspaceSmokeTest.php tests/Browser/Spec194GovernanceFrictionSmokeTest.php tests/Browser/Spec265DecisionRegisterSmokeTest.php` Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #351
45 lines
3.5 KiB
Markdown
45 lines
3.5 KiB
Markdown
# Research: Full Suite Green Signal Restoration
|
|
|
|
## Decision 1: Treat Spec 296 As Manual-Promoted Cleanup, Not Auto Queue Selection
|
|
|
|
- **Decision**: Use the user-provided Spec 296 prompt as the selected candidate.
|
|
- **Rationale**: `docs/product/spec-candidates.md` says no safe automatic next-best-prep target remains, but the user explicitly promoted a concrete follow-up to Spec 295.
|
|
- **Alternatives considered**: Selecting a roadmap candidate automatically. Rejected because the active queue forbids auto-prep and the user gave a direct stabilization target.
|
|
|
|
## Decision 2: Raw Full Suite Remains The Preferred Signal
|
|
|
|
- **Decision**: The preferred end state is `cd apps/platform && ./vendor/bin/sail artisan test --compact` green.
|
|
- **Rationale**: Spec 295 classified lane wrappers but left the raw suite red. The new spec exists to restore the full-suite signal rather than merely classify it.
|
|
- **Alternatives considered**: Declare a default lane as the only CI truth immediately. Rejected unless every remaining non-green case is proven wrong-lane/browser/heavy/external and documented.
|
|
|
|
## Decision 3: Guard Lanes Must Run Before Broad Repairs
|
|
|
|
- **Decision**: Spec 288, Spec 293, and Spec 294 lanes are first-class gate lanes.
|
|
- **Rationale**: They protect no-legacy cutover truth, workspace-first routes, provider verification semantics, browser lane isolation, CI classification, and no-role-string RBAC.
|
|
- **Alternatives considered**: Repair all failures in raw-suite order. Rejected because broad output order can hide security or cutover regressions.
|
|
|
|
## Decision 4: Reuse Existing Route, Panel, And OperationRun Helpers
|
|
|
|
- **Decision**: Tests should use current `OperationRunLinks`, workspace route parameters, `WorkspaceContext::SESSION_KEY`, and `setAdminPanelContext()` rather than local route or panel hacks.
|
|
- **Rationale**: Repo truth shows operation routes are workspace-aware under `/admin/workspaces/{workspace}/operations`, and tests/Pest.php already resets and sets Filament admin context.
|
|
- **Alternatives considered**: Add fallback routes or global test boot hacks. Rejected as legacy restoration or context leakage.
|
|
|
|
## Decision 5: Browser Screenshots Are Evidence Unless Proven Baseline Truth
|
|
|
|
- **Decision**: Browser screenshots generated by failing tests are copied to `/tmp/tenantpilot-296-browser-evidence` and not committed by default.
|
|
- **Rationale**: Spec 295 found browser failures involving stale routes, panel context, and layout/copy assertions. Baseline updates would hide defects unless the UI state is proven correct.
|
|
- **Alternatives considered**: Commit updated screenshots whenever browser tests regenerate them. Rejected as screenshot churn.
|
|
|
|
## Decision 6: Spec-Local Evidence Artifacts Are Required
|
|
|
|
- **Decision**: Create `failure-inventory.md`, `fix-log.md`, `lane-decisions.md`, and `browser-evidence.md` in addition to normal Spec Kit artifacts.
|
|
- **Rationale**: The user explicitly requires them, and they are necessary for a long stabilization loop where classification, fixes, and lane decisions must remain auditable.
|
|
- **Alternatives considered**: Put all evidence into `tasks.md`. Rejected because it would be too dense and less reviewable.
|
|
|
|
## Decision 7: No New Application Persistence Or Abstractions
|
|
|
|
- **Decision**: No new application data model, migration, enum, resolver, registry, or provider framework is planned.
|
|
- **Rationale**: The problem is a red suite and stale/drifted tests, not missing product persistence.
|
|
- **Alternatives considered**: Create a permanent test-suite failure registry in application code. Rejected as overproduction and outside scope.
|
|
|