TenantAtlas/.specify/templates/checklist-template.md

[CHECKLIST TYPE] Checklist: [FEATURE NAME]

Purpose: [Brief description of what this checklist covers] Created: [DATE] Feature: [Link to spec.md or relevant documentation]

Note: This checklist is generated by the /speckit.checklist command based on feature context and requirements. If the checklist covers UI or surface work, use it to reach both one review outcome class (blocker, strong-warning, documentation-required-exception, or acceptable-special-case) and one workflow outcome (keep, split, document-in-feature, follow-up-spec, or reject-or-split). Low-impact docs-only or template-only work may mark runtime-only checks N/A, but should still leave one explicit workflow outcome and one note explaining why no guardrail spread exists.

Applicability And Low-Impact Gate

• CHK001 The change explicitly says whether an operator-facing surface or guardrail workflow surface is affected; low-impact N/A handling is used once and not contradicted elsewhere.
• CHK002 The spec, plan, and task artifacts carry forward the same native/custom classification, shared-family relevance, state-layer ownership, and exception need without inventing second wording.

Native, Shared-Family, And State Ownership

• CHK003 The surface remains native/shared-primitives first; fake-native controls, GET-form page-body interactions, and simple-overview replacements are not treated as harmless customization.
• CHK004 Any shared-detail or shared-family surface keeps one shared contract, and any host variation is either folded back into that contract or explicitly bounded as an exception.
• CHK005 Shell, page, detail, and URL/query state owners are named once and do not collapse into one another.
• CHK006 The likely next operator action and the primary inspect/open model stay coherent with the declared surface class.

Shared Pattern Reuse

• CHK007 Any cross-cutting interaction class is explicitly marked, and the existing shared contract/presenter/builder/renderer path is named once.
• CHK008 The change extends the shared path where it is sufficient, or the deviation is explicitly documented with product reason, preserved consistency, ownership cost, and spread-control.
• CHK009 The change does not create a parallel operator-facing UX language for the same interaction class unless a bounded exception is recorded.

Signals, Exceptions, And Test Depth

• CHK010 Any triggered repository signal is classified with one handling mode: hard-stop-candidate, review-mandatory, exception-required, or report-only.
• CHK011 Any deviation from default rules includes a bounded exception record naming the broken rule, product reason, standardized parts, spread-control rule, and the active feature PR close-out entry.
• CHK012 The required surface test profile is explicit: shared-detail-family, monitoring-state-page, global-context-shell, exception-coded-surface, or standard-native-filament.
• CHK013 The chosen test family/lane and any manual smoke are the narrowest honest proof for the declared surface class, and standard-native-filament relief is used when no special contract exists.

Review Outcome

• CHK014 One review outcome class is chosen: blocker, strong-warning, documentation-required-exception, or acceptable-special-case.
• CHK015 One workflow outcome is chosen: keep, split, document-in-feature, follow-up-spec, or reject-or-split.
• CHK016 The final note location is explicit: the active feature PR close-out entry for guarded work, or a concise N/A note for low-impact changes.

Notes

• blocker: the change conflicts with the declared surface contract or guardrail and cannot proceed as proposed.
• strong-warning: the change may proceed only after the active workflow records the remaining guardrail risk explicitly.
• documentation-required-exception: the change is valid only once a bounded exception and close-out note exist.
• acceptable-special-case: the change is legitimate without extra escalation beyond ordinary documentation.
• keep: the current scope, guardrail handling, and proof depth are justified.
• split: the intent is valid, but the scope should narrow before merge.
• document-in-feature: the change is acceptable, but the active feature must record the exception, signal handling, or proof notes explicitly.
• follow-up-spec: the issue is recurring or structural and needs dedicated governance follow-up. For already-implemented historical drift, prefer a follow-up spec or active feature note instead of retroactively rewriting closed specs.
• reject-or-split: hidden drift, unresolved exception spread, or wrong proof depth blocks merge as proposed.
• Check items off as completed: [x]
• Add comments or findings inline
• Link to relevant resources or documentation
• Items are numbered sequentially for easy reference
• Reviewer-facing checklists SHOULD stop merge when nativity, shared-family boundaries, state ownership, exception spread, test depth, or escalation handling is unclear.