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

Data Model: Provider Verification Runtime Semantics Stabilization

Overview

294 introduces no new application entity, table, or persisted runtime artifact. Its only modeled data is spec-local preparation truth for later implementation: one failure-classification artifact, one bounded failure-category inventory, and one bounded stabilization-seam inventory.

Pinned Failure-Classification Categories

Category	Meaning	Default Treatment in `294`
`surface-or-report-baseline-drift`	stale visible provider connection or verification report expectation that no longer matches current shared summary/report truth	fix in `294`
`fixture-contract-drift`	test setup no longer matches the repo's canonical startable verification or provider-operation fixture contract	fix in `294` before widening runtime changes
`provider-verification-runtime-regression`	a canonical shared runtime owner is still wrong after fixture alignment	allow minimal targeted fix in `294`
`dedupe-concurrency-contract-drift`	current expectations for dedupe versus `scopeBusy` or queue counts no longer match the shared gate contract	fix in `294`
`out-of-scope-existing-debt`	failure or drift outside the bounded provider/verification stabilization scope	document, do not silently absorb
`resolved-or-not-needed`	initially suspected drift no longer needs work after classification or adjacent repair	record and stop

Pinned Stabilization Seams

Seam Key	Meaning	Primary Targets
`provider-neutrality-surface`	provider connection create/edit/list/detail expectations around neutral target-scope disclosure and nested provider identity detail	`ProviderConnectionSurfaceSummary`, target-scope descriptor/normalizer, resource detail expectations
`shared-startable-fixtures`	canonical test fixture contract for queued verification and provider starts	`tests/Pest.php`, `createUserWithTenant(...)` call sites, provider connection factory usage
`verification-start-contract`	canonical verification start, dedupe, blocked, and new-run-after-completion behavior	`StartVerification`, directly implicated resolver/identity seams, verification feature tests
`provider-dispatch-concurrency`	canonical provider-operation dedupe versus `scopeBusy` behavior for the same connection	`ProviderOperationStartGate`, directly implicated run-identity owner, provider operation feature tests
`verification-report-summary`	canonical verification report counts and visible summary expectations	`MicrosoftProviderHealthCheck`, report writer/schema seams, report feature tests

Spec-Local Artifact: `failure-classification.md`

Field	Meaning
`Group`	failing test, failing scenario family, or grouped lane-visible mismatch
`Seam`	one pinned stabilization seam
`Category`	one pinned failure category
`Observed Failure`	short description of what the current failing output shows
`Candidate Owner`	current best owner seam to inspect first during implementation
`Fix In 294?`	`yes`, `no`, or `only-if-runtime-owner-proven`
`Follow-up`	next action if the group remains open
`Status`	current implementation-tracking note

Invariants

The same six failure categories must appear in spec.md, plan.md, research.md, quickstart.md, tasks.md, checklists/requirements.md, and failure-classification.md.
The same five stabilization seams must appear in spec.md, plan.md, research.md, quickstart.md, tasks.md, checklists/requirements.md, and failure-classification.md.
294 introduces no new runtime product state and no new runtime persistence.
294 must not widen into route-cutover repair, full-suite repair, or a broader provider-boundary foundation package.
Browser proof remains conditional and reuses the existing Spec281ProviderConnectionScopeSmokeTest only when visible provider-connection disclosure changes.

Out-of-Scope Data Changes

no database migrations by default
no new provider-profile or verification-report persistence
no new provider abstraction or registry
no new verification schema version
no new browser fixture family

4.1 KiB Raw Blame History