Pular para conteúdo

Specification Quality Checklist: Cadastro profissional, validação e escopo por CRP

Purpose: Validate specification completeness and quality before proceeding to planning Created: 2026-08-11 Feature: spec.md

Content Quality

  • No implementation details (languages, frameworks, APIs)
  • Focused on user value and business needs
  • Written for non-technical stakeholders
  • All mandatory sections completed

Requirement Completeness

  • No [NEEDS CLARIFICATION] markers remain
  • Requirements are testable and unambiguous
  • Success criteria are measurable
  • Success criteria are technology-agnostic (no implementation details)
  • 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 meets measurable outcomes defined in Success Criteria
  • No implementation details leak into specification

Notes

  • FR-003 was resolved as account recovery for a duplicated CPF/CNPJ, without exposing the existing account.
  • FR-010 was resolved as provisional enablement with future validation attempts and automatic restriction after five calendar days without confirmation.
  • The specification now treats CRP as an optional operational filter with a consolidated “Todos” view, not as a separate account or hard tenant boundary.
  • CPF and CNPJ can coexist on one profile; every CRP retains an explicit link to exactly one of those documents.
  • The proposed header, interceptor/middleware and migration optimization were preserved separately in planning-notes.md so implementation details do not leak into the product specification.
  • Plan tiers and CRP/cadastro states are independent decision dimensions. This spec recognizes free and standard, implements only the known free capacity rule, and defers the commercial plan catalog to its own future specification.
  • UX review: “Todos” and the selector only exist with multiple CRPs; account blockers live in the sidebar, all user-facing copy is pt-BR, and patient creation inherits the selected CRP while remaining changeable.
  • The external OpenAPI publishes the available query parameters but not a typed success response; contract discovery is therefore required during planning.
  • A live request using the CRP example returned an internal server error on 2026-08-11, validating the chosen provisional five-day mode and retry requirements.