ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
9e435ea91f
TenantAtlas/specs/296-full-suite-green-signal-restoration/research.md
ahmido 38523814c2 fix: restore full-suite green signals across platform workflows (#351) 
## 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
2026-05-12 18:50:40 +00:00

3.5 KiB
Raw Blame History

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.