ahmido
15b21c3080
Some checks failed
Main Confidence / confidence (push) Failing after 44s
## Summary - add the full Spec 201 artifact set for enforcement and review guardrails - update the SpecKit workflow surfaces to carry UI/surface guardrail classification, handling modes, proof depth, and close-out targeting - align the operator UX standards reference and agent context with the new guardrail workflow ## Validation - completed cross-artifact consistency analysis for spec, plan, tasks, research, data model, contracts, and quickstart - recorded the low-impact workflow path at `00:48` and the representative guarded review at `02:34` - no Pest or runtime test suite was run because this is a docs/workflow-only feature - integrated browser smoke on the tenant dashboard could not complete because tenant-scoped unauthenticated navigation currently redirects to `/admin/t/login`, which returns `404 Not Found` ## Filament Notes - Livewire v4.0+ compliance is unchanged - provider registration remains in `bootstrap/providers.php` - no globally searchable resources were added or modified - no destructive runtime actions were introduced or changed - no asset strategy changes were made; existing `filament:assets` deployment behavior remains unchanged Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #250
58 lines
4.4 KiB
Markdown
58 lines
4.4 KiB
Markdown
# [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.
|
|
|
|
## Signals, Exceptions, And Test Depth
|
|
|
|
- [ ] CHK007 Any triggered repository signal is classified with one handling mode: `hard-stop-candidate`, `review-mandatory`, `exception-required`, or `report-only`.
|
|
- [ ] CHK008 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.
|
|
- [ ] CHK009 The required surface test profile is explicit: `shared-detail-family`, `monitoring-state-page`, `global-context-shell`, `exception-coded-surface`, or `standard-native-filament`.
|
|
- [ ] CHK010 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
|
|
|
|
- [ ] CHK011 One review outcome class is chosen: `blocker`, `strong-warning`, `documentation-required-exception`, or `acceptable-special-case`.
|
|
- [ ] CHK012 One workflow outcome is chosen: `keep`, `split`, `document-in-feature`, `follow-up-spec`, or `reject-or-split`.
|
|
- [ ] CHK013 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.
|
|
- `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.
|