ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
9e435ea91f
TenantAtlas/specs/294-provider-verification-runtime-semantics/checklists/requirements.md
ahmido d3158f5103 test: stabilize provider verification runtime semantics (#349) 
## Summary
- align verification-start tests with the canonical credential-enabled provider fixture
- seed required tenant-permission evidence for provider operation start tests so inventory/compliance assertions exercise the real queued and `scopeBusy` contracts
- refresh stale provider-connection and verification-report test baselines to current shared output
- add the complete Spec 294 artifacts for the bounded provider/verification stabilization follow-up

## Scope
- bounded to `apps/platform/tests`, shared Pest test helpers, and `specs/294-provider-verification-runtime-semantics`
- no runtime application code changes under `apps/platform/app`
- no schema, route-cutover, framework, or asset changes

## Validation
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Verification/VerificationAuthorizationTest.php tests/Feature/Verification/VerificationStartAfterCompletionTest.php tests/Feature/Verification/VerificationStartDedupeTest.php`
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/ProviderConnections/ProviderDispatchGateStartSurfaceTest.php tests/Feature/ProviderConnections/ProviderOperationConcurrencyTest.php`
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/ProviderConnections/ProviderConnectionNeutralitySpec238Test.php tests/Feature/Verification/ProviderConnectionHealthCheckWritesReportTest.php`
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/ProviderConnections tests/Feature/Verification`
- `cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`

## Notes
- browser smoke was not run because the final diff contains no runtime app or UI changes; only tests, shared test helpers, and spec artifacts changed
- provider registration remains unchanged in `apps/platform/bootstrap/providers.php`
- no new globally searchable resource or destructive action behavior was introduced

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #349
2026-05-11 08:26:17 +00:00

4.1 KiB
Raw Blame History

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.