ahmido
12fb5ebb30
Some checks failed
Main Confidence / confidence (push) Failing after 1m20s
## Summary - add the workspace-scoped findings hygiene report, overview signal, and supporting classification service for broken assignments and stale in-progress work - add Spec 225 artifacts and focused findings hygiene test coverage alongside the new Filament page and workspace overview wiring - align product roadmap and spec candidates around the layered canonical control catalog, CIS library, and readiness model - extend SpecKit constitution and templates with the XCUT-001 shared-pattern reuse guidance ## Notes - validation commands and implementation close-out notes are documented in `specs/225-assignment-hygiene/plan.md` and `specs/225-assignment-hygiene/quickstart.md` - this PR targets `dev` from `225-assignment-hygiene` Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #264
64 lines
5.0 KiB
Markdown
64 lines
5.0 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.
|
|
|
|
## 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.
|