ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
platform-dev
TenantAtlas/specs/295-full-suite-ci-baseline/checklists/requirements.md
ahmido f03555eae1 Spec 295: full suite CI lane baseline (#350) 
## Summary
- add the Spec 295 artifacts for full-suite failure classification and CI lane baseline work
- fix `scripts/platform-test-artifacts` so Sail passes artifact staging inputs into the embedded PHP script via argv
- add a guard test covering the artifact staging input contract

## Scope guards
- no browser screenshot baselines included
- no generated test artifacts included
- no runtime application code changes included

## Notes
- classification evidence and follow-up ownership are documented in `specs/295-full-suite-ci-baseline/failure-classification.md`
- this PR is intentionally limited to the CI/lane/artifact contract slice for Spec 295

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #350
2026-05-11 11:14:56 +00:00

2.8 KiB
Raw Permalink Blame History

Specification Quality Checklist: Full Suite Failure Classification & CI Lane Baseline

Purpose: Validate specification completeness and quality before implementation
Created: 2026-05-11
Feature: /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/295-full-suite-ci-baseline/spec.md

Content Quality

  • No application implementation details leak into product requirements beyond required repo-truth paths and validation commands.
  • Focused on user value and business needs: restored or classified CI signal after Specs 293 and 294.
  • Written for maintainers and reviewers who must interpret CI output.
  • All mandatory Spec Kit sections are completed or explicitly marked N/A.

Requirement Completeness

  • No unresolved clarification markers remain.
  • Requirements are testable and unambiguous.
  • Success criteria are measurable.
  • Success criteria are technology-aware only where repo validation commands require it.
  • All acceptance scenarios are defined.
  • Edge cases are identified.
  • Scope is clearly bounded.
  • Dependencies and assumptions are identified.

Feature Readiness

  • All functional requirements have clear acceptance criteria.
  • User scenarios cover primary classification, lane signal, follow-up split, and final readiness decision flows.
  • Feature meets measurable outcomes defined in Success Criteria.
  • No application implementation has been performed during preparation.

Spec 295 Guardrails

  • Pinned categories stay aligned: ci-signal-restored, ci-wrapper-or-manifest-regression, artifact-publication-regression, budget-or-trend-baseline-drift, product-runtime-or-test-regression, browser-lane-regression, flaky-or-environment, follow-up-spec-required, resolved-or-not-needed.
  • Pinned seams stay aligned: raw-full-suite, fast-feedback-lane, confidence-lane, heavy-governance-lane, browser-lane, profiling-or-junit-support, lane-reporting, artifact-publication, budget-trend-baseline, legacy-cutover-regression-guard, provider-verification-regression-guard.
  • Completed Specs 293 and 294 are context only and are not rewritten.
  • Legacy /admin/t/... and TenantPanelProvider restoration is explicitly forbidden.
  • In-scope fixes are limited to CI wrapper, manifest, report, artifact, and budget/trend contract defects.
  • Product/runtime failures are explicitly split to follow-up ownership.
  • No new permanent lane, CI framework, runtime persistence, provider abstraction, Filament resource, or browser family is introduced.
  • Filament v5 / Livewire v4 compliance is preserved; no panel provider registration change is planned.

Notes

  • Preparation analyze found no blocking readiness gap after aligning category and seam names across all artifacts.