ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects 1 Releases Wiki Activity
a35cd88bff
TenantAtlas/specs/254-remove-acknowledged-compat/checklists/requirements.md
ahmido b511b08371
Some checks failed
PR Fast Feedback / fast-feedback (pull_request) Failing after 1m0s
Details
feat: remove findings acknowledged compatibility and unify canonical operation types (#296) 
This PR removes the legacy "acknowledged" status compatibility for findings and unifies the canonical operation types (e.g., transitioning from baseline_capture to baseline.capture). It includes updated tests, models, and services to reflect these changes.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #296
2026-04-29 07:34:39 +00:00

3.0 KiB
Raw Blame History

Specification Quality Checklist: Remove Legacy Acknowledged Finding Status Compatibility

Purpose: Validate specification completeness and quality before proceeding to planning
Created: 2026-04-29
Feature: specs/254-remove-acknowledged-compat/spec.md

Content Quality

  • No language/framework/API design leakage; concrete repo surfaces, status constants, capability keys, and shared helpers are named only because this cleanup removes those exact repo-visible compatibility seams.
  • Focused on user value and business needs
  • Written primarily for product and review stakeholders, with bounded repo-specific terminology only where the cleanup target would otherwise stay ambiguous
  • All mandatory sections completed

Requirement Completeness

  • No [NEEDS CLARIFICATION] markers remain
  • Requirements are testable and unambiguous
  • Success criteria are measurable
  • Success criteria stay outcome-oriented, with bounded repo-specific seams named only where they are required to define the cleanup target
  • All acceptance scenarios are defined
  • Edge cases are identified
  • Scope is clearly bounded
  • Dependencies and assumptions identified

Feature Readiness

  • All functional requirements have clear acceptance criteria
  • User scenarios cover primary flows
  • Feature defines measurable outcomes in Success Criteria and maps them to explicit proof tasks for implementation-time validation
  • No unintended implementation design leakage remains beyond the explicit cleanup special-case for named repo-visible compatibility seams

Test Governance Review

  • Lane fit is explicit: the package uses fast-feedback and confidence, plus bounded heavy-governance guard coverage so shared status-badge and filter drift cannot silently reintroduce acknowledged semantics.
  • No new browser or heavy-governance family is introduced; retained guard coverage stays explicit and limited to shared findings status seams.
  • Suite-cost outcome is net-neutral to slightly negative: acknowledged-only compatibility expectations should be consolidated or deleted rather than widening shared defaults.

Review Outcome

  • Review outcome class: acceptable-special-case
  • Workflow outcome: keep
  • Review-note location is explicit: the guardrail and lane-fit notes live in spec.md, the checklist, and the final preparation report.

Notes

  • The spec intentionally names concrete findings status constants, capability aliases, shared catalogs, and summary builders because the product value of this slice is removing those exact compatibility seams from repo truth.
  • Verification-check acknowledgement and onboarding acknowledgement remain explicit non-goals so the cleanup cannot expand into a broader terminology rewrite.
  • Validation pass complete: no clarification markers remain, the slice stays LEAN-001-compliant, and tenant-owned findings continue to treat workspace_id plus tenant_id as required anchors.