ahmido
bd26e209de
Some checks failed
Main Confidence / confidence (push) Failing after 57s
## Summary - add the provider boundary catalog, boundary support types, and guardrails for platform-core versus provider-owned seams - harden provider gateway, identity resolution, operation registry, and start-gate behavior to require explicit provider bindings - add unit and feature coverage for boundary classification, runtime preservation, unsupported paths, and platform-core leakage guards - add the full Spec Kit artifact set for spec 237 and update roadmap/spec-candidate tracking ## Validation - `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Providers/ProviderBoundaryClassificationTest.php tests/Unit/Providers/ProviderBoundaryGuardrailTest.php tests/Feature/Providers/ProviderBoundaryHardeningTest.php tests/Feature/Providers/UnsupportedProviderBoundaryPathTest.php tests/Feature/Guards/ProviderBoundaryPlatformCoreGuardTest.php` - `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Providers/ProviderGatewayTest.php tests/Unit/Providers/ProviderIdentityResolverTest.php tests/Unit/Providers/ProviderOperationStartGateTest.php` - `cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent` - browser smoke: `http://localhost/admin/provider-connections?tenant_id=18000000-0000-4000-8000-000000000180` loaded with the local smoke user, the empty-state CTA reached the canonical create route, and cancel returned to the scoped list Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #273
76 lines
6.3 KiB
Markdown
76 lines
6.3 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.
|
|
|
|
## OperationRun Start UX Contract
|
|
|
|
- [ ] CHK019 The change explicitly says whether it creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an `OperationRun`, and the required `OperationRun UX Impact` section exists when applicable.
|
|
- [ ] CHK020 Queued toast/link/artifact-link/browser-event/dedupe-or-blocked messaging and tenant/workspace-safe operation URL resolution are delegated to the shared OperationRun UX contract instead of local surface code.
|
|
- [ ] CHK021 Any queued DB notification is explicit opt-in in the active spec or plan, running DB notifications remain absent, and terminal notifications still flow through the central lifecycle mechanism.
|
|
- [ ] CHK022 Any exception records the explicit spec decision, architecture note, test or guard-test rationale, and temporary migration follow-up decision.
|
|
|
|
## Provider Boundary And Vocabulary
|
|
|
|
- [ ] CHK010 The change states whether any touched shared seam is provider-owned, platform-core, or mixed, and provider-specific semantics do not silently spread into platform-core contracts, taxonomy, identifiers, compare semantics, or operator vocabulary.
|
|
- [ ] CHK011 Any retained provider-specific shared boundary is justified as a bounded current-release exception or an explicit follow-up-spec need instead of becoming permanent platform truth by default.
|
|
|
|
## Signals, Exceptions, And Test Depth
|
|
|
|
- [ ] CHK012 Any triggered repository signal is classified with one handling mode: `hard-stop-candidate`, `review-mandatory`, `exception-required`, or `report-only`.
|
|
- [ ] CHK013 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.
|
|
- [ ] CHK014 The required surface test profile is explicit: `shared-detail-family`, `monitoring-state-page`, `global-context-shell`, `exception-coded-surface`, or `standard-native-filament`.
|
|
- [ ] CHK015 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
|
|
|
|
- [ ] CHK016 One review outcome class is chosen: `blocker`, `strong-warning`, `documentation-required-exception`, or `acceptable-special-case`.
|
|
- [ ] CHK017 One workflow outcome is chosen: `keep`, `split`, `document-in-feature`, `follow-up-spec`, or `reject-or-split`.
|
|
- [ ] CHK018 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.
|