TenantAtlas/specs/274-billing-subscription-truth/checklists/requirements.md
ahmido 35b59eb628 274: Billing subscription truth - add workspace subscription model & tests (#326)
Automated PR: commit all local changes and add feature 274-billing-subscription-truth.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #326
2026-05-04 21:15:57 +00:00

3.9 KiB

Specification Quality Checklist: Billing & Subscription Truth Layer v1

Purpose: Validate specification completeness, boundedness, and readiness before implementation
Created: 2026-05-04
Feature: spec.md

Content Quality

  • The package stays on one bounded subscription truth follow-through over Specs 247 and 251 instead of inventing a billing engine, invoice layer, or customer portal.
  • The spec remains product- and behavior-oriented rather than reading like a low-level implementation diff.
  • The package explicitly names the repo-real anchors it builds on: WorkspaceEntitlementResolver, WorkspaceCommercialLifecycleResolver, ViewWorkspace, WorkspaceSettings, onboarding activation, and review-pack generation.
  • Mandatory repo sections for scope, RBAC, shared-pattern reuse, testing, proportionality, and candidate rationale are completed.

Requirement Completeness

  • No [NEEDS CLARIFICATION] markers remain.
  • Requirements are testable and bounded to one current subscription record, one resolver, existing lifecycle gating, one system mutation surface, and one read-only admin summary.
  • The package makes fallback behavior explicit for workspaces without a subscription record.
  • The package forbids a second runtime gate and keeps onboarding or review-pack behavior on the existing lifecycle resolver.
  • Canonical proof commands match across spec.md, plan.md, quickstart.md, and tasks.md.

Candidate Selection Gate

  • The selected candidate exists in docs/product/spec-candidates.md and docs/product/roadmap.md as Billing & Subscription Truth Layer v1.
  • Related anchor specs were checked for completion or close-out signals and treated as context only: Specs 247 and 251 are already repo-real and implemented.
  • The chosen slice is smaller and more bounded than deferred alternatives such as provider sync, invoices, or a customer billing portal.
  • The selected slice explicitly closes the remaining manual-promotion gap between plan or lifecycle truth and durable subscription truth.

Feature Readiness

  • The package justifies a new persisted entity and explains why more workspace-setting keys are insufficient.
  • The package keeps Filament on Livewire v4, provider registration unchanged in apps/platform/bootstrap/providers.php, global search unchanged, and assets unchanged.
  • The package keeps /system as the mutation plane and /admin read-only for subscription truth.
  • The package forbids provider-specific billing semantics, invoices, checkout, and portal scope.

Test Governance

  • Planned proof stays bounded to one new Unit family plus focused extensions to existing Feature suites.
  • No new heavy-governance or browser family is introduced by default.
  • Fixture growth remains bounded to one new factory plus existing workspace, onboarding, and review-pack helpers.
  • The review outcome, workflow outcome, and test-governance outcome are carried into plan.md and tasks.md.

Notes

  • Reviewed against .specify/memory/constitution.md, docs/product/spec-candidates.md, docs/product/roadmap.md, specs/247-plans-entitlements-billing-readiness/spec.md, specs/251-commercial-entitlements-billing-state/spec.md, current entitlement and lifecycle code under apps/platform, and the active 274 prep artifacts on 2026-05-04.
  • No application implementation was performed while preparing this package.

Review Outcome

  • Outcome class: acceptable-special-case
  • Workflow outcome: keep
  • Test-governance outcome: keep
  • Reason: The package promotes the remaining commercial manual-promotion gap as one bounded source-of-truth follow-through. It keeps lifecycle as the only runtime gate, adds only one current subscription entity, and stays off provider, invoice, and portal scope.
  • Workflow result: Ready for implementation.