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
3.3 KiB
3.3 KiB
Data Model: Full Suite Green Signal Restoration
No application data model is introduced by Spec 296.
The following are spec-local workflow artifacts only.
Failure Inventory Entry
Represents one observed failing group or one seed group imported from Spec 295.
| Field | Meaning |
|---|---|
| Test file | File, lane, or suite grouping where the failure was observed. |
| Test name | Test title or grouped failure name. |
| Failure summary | Short description of the observed failure. |
| First observed command | First command that produced this failure during Spec 296 or prior seed evidence. |
| Owner area | Owning test/runtime area. |
| Classification | One pinned classification from failure-inventory.md. |
| Fix type | One pinned fix type from failure-inventory.md. |
| Fixed now? | Whether Spec 296 fixed it. |
| Follow-up required? | Whether it remains outside final green/default signal. |
| Validation command | Focused or lane command proving status. |
| Final status | pending, fixed, moved, skipped, obsolete, environment, follow-up, or superseded. |
Fix Log Entry
Represents one changed file and the contract it protects.
| Field | Meaning |
|---|---|
| File changed | Absolute path of changed file. |
| Why? | Reason for the change. |
| Test or Runtime? | Classification of the change. |
| Product contract protected | Workspace isolation, RBAC, provider boundary, OperationRun truth, browser evidence, or lane signal. |
| Validation executed | Command proving the change. |
| Status | prepared, fixed, pending validation, or follow-up. |
Lane Decision Entry
Represents a decision to keep, move, skip, or remove a test.
| Field | Meaning |
|---|---|
| Test file | Target test file or group. |
| Test name or group | Specific test or grouped behavior. |
| Decision | keep, move, skip, obsolete, or re-evaluate. |
| Target lane | Default, fast-feedback, confidence, heavy-governance, browser, or external/environment. |
| Reason | Why that lane is the honest proving scope. |
| Product bug hidden? | Must be no for a move/skip/removal to be accepted. |
| Validation command | Command proving the lane/default outcome. |
| Status | pending, accepted, rejected, or superseded. |
Browser Evidence Entry
Represents one browser screenshot/evidence/baseline decision.
| Field | Meaning |
|---|---|
| Screenshot or artifact | File or evidence path. |
| Generated by command | Browser command that generated it. |
| Shows real bug? | Whether the image proves broken current UI. |
| Committed? | Whether it remains in git diff. |
| Baseline updated? | Whether screenshot baseline changed intentionally. |
| Reason | Rationale for commit or non-commit. |
| Status | pending, evidence-only, committed, restored, or follow-up. |
State Transitions
Failure inventory entries move through:
seeded -> current-baseline -> classified -> fixed -> validated
seeded -> current-baseline -> classified -> lane-decision -> validated
seeded -> current-baseline -> classified -> follow-up
Browser evidence entries move through:
generated -> evidence-only -> restored
generated -> baseline-candidate -> documented -> committed -> browser-lane-green
Persistence Review
These artifacts are markdown files in the spec directory. They do not introduce database persistence, runtime state, or product source-of-truth semantics.