TenantAtlas/specs/294-provider-verification-runtime-semantics/checklists/requirements.md

Requirements Checklist: Provider Verification Runtime Semantics Stabilization

Scope and Problem Framing

• The package is explicitly framed as the bounded post-293 provider/verification runtime stabilization follow-up.
• The primary failing lane is exactly tests/Feature/ProviderConnections plus tests/Feature/Verification.
• Non-goals explicitly exclude full-suite repair, route-cutover repair, new provider abstractions, new verification schema versions, and historical-spec rewrites.

Repo-Truth Anchoring

• The targeted failing command was already rerun and confirmed as the current baseline for 294.
• The authoritative prep-time failure baseline lives in failure-classification.md, and other artifacts treat it as context only.
• The owner seams were read directly from the repository before drafting the package.
• The current canonical startable verification fixture contract is recorded as repo truth to align before widening runtime changes.

Failure Categories and Seam Inventory

• Pinned failure categories listed here: surface-or-report-baseline-drift, fixture-contract-drift, provider-verification-runtime-regression, dedupe-concurrency-contract-drift, out-of-scope-existing-debt, resolved-or-not-needed.
• Pinned stabilization seams listed here: provider-neutrality-surface, shared-startable-fixtures, verification-start-contract, provider-dispatch-concurrency, verification-report-summary.
• spec.md, plan.md, research.md, data-model.md, quickstart.md, tasks.md, checklists/requirements.md, and failure-classification.md all use the same six failure categories.
• spec.md, plan.md, research.md, data-model.md, quickstart.md, tasks.md, checklists/requirements.md, and failure-classification.md all use the same five stabilization seams.
• failure-classification.md defines one-row-per-group tracking with one seam and one category per failing group.

Runtime Ownership and Boundedness

• StartVerification is named as the verification start owner seam.
• ProviderOperationStartGate is named as the provider-operation dedupe and scopeBusy owner seam.
• ProviderConnectionSurfaceSummary and the target-scope helpers are named as the provider-neutral disclosure owner seams.
• MicrosoftProviderHealthCheck and VerificationReportSchema are named as the report-summary owner seams.
• The package introduces no new tables, persisted provider profiles, run status values, verification schema version, or abstraction family.

Validation Workflow

• The full in-scope proof command is recorded exactly.
• Focused reruns are recorded for verification start, provider dispatch/concurrency, and surface/report baseline clusters.
• The existing provider-connection scope browser smoke is documented as conditional reuse only for visible provider-connection disclosure changes.
• Formatting closure through ./vendor/bin/sail bin pint --dirty --format agent is recorded.

Related-Spec Guardrails

• Spec 293 is explicitly treated as context only and not a refresh target.
• Specs 238, 188, 084, and 074 are explicitly treated as historical context only.
• The manual follow-up status is documented because the automatic candidate queue is intentionally empty.

Filament and Platform Guardrails

• Livewire v4.0+ compliance is stated explicitly.
• Provider registration remains in apps/platform/bootstrap/providers.php.
• No new globally-searchable resource is introduced.
• No new destructive action or new asset strategy is introduced.

Implementation Close-Out

• Application implementation stayed bounded to the active ProviderConnections plus Verification lane.
• The implementation resolved the seven tracked failure groups without widening into route-cutover, full-suite, provider-framework, or schema-version work.
• The final bounded lane rerun is green at 109 passed.

Outcome

• Review outcome class: acceptable-special-case
• Workflow outcome: keep
• Test-governance outcome: keep
• 294 is ready for bounded implementation.