TenantAtlas/specs/294-provider-verification-runtime-semantics/failure-classification.md

Failure Classification: Provider Verification Runtime Semantics Stabilization

Baseline

Observed from:

export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/ProviderConnections tests/Feature/Verification

Current confirmed baseline at prep time: 11 failed, 98 passed, 755 assertions.

Post-implementation verification for the bounded lane: 0 failed, 109 passed, 782 assertions.

Grouping unit: one row below equals one failing test file or one failing scenario cluster that shares one seam and one category. The current 11 failing assertions collapse into 7 tracked groups.

Pinned Categories

• 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 Seams

• provider-neutrality-surface
• shared-startable-fixtures
• verification-start-contract
• provider-dispatch-concurrency
• verification-report-summary

Current Failing Groups

Group	Seam	Category	Observed Failure	Candidate Owner	Fix In 294?	Follow-up	Status
ProviderConnectionNeutralitySpec238Test	provider-neutrality-surface	surface-or-report-baseline-drift	Current provider connection disclosure no longer matches one or more stale Spec 238 wording expectations, while the neutral target-scope summary remains the intended owner seam.	ProviderConnectionSurfaceSummary, target-scope descriptor/normalizer, touched resource detail/list expectations	yes	Resolved by refreshing the assertion to the current neutral Provider context baseline.	resolved
ProviderDispatchGateStartSurfaceTest	provider-dispatch-concurrency	dedupe-concurrency-contract-drift	Starting a different provider operation on the same active connection no longer returns the expected shared scopeBusy follow-through and queue/run count contract.	ProviderOperationStartGate	yes	Resolved after seeding the required provider-capability evidence the gate already expects.	resolved
ProviderOperationConcurrencyTest	provider-dispatch-concurrency	dedupe-concurrency-contract-drift	Multiple same-operation and cross-operation scenarios disagree with the current shared dedupe and scopeBusy contract, including run identity expectations.	ProviderOperationStartGate, one-hop OperationRunService identity path only if proven	yes	Resolved after aligning the startable provider-operation fixture prerequisites; no runtime owner change was needed.	resolved
VerificationAuthorizationTest	shared-startable-fixtures	fixture-contract-drift	An authorized operator receives blocked instead of started, which suggests the test's connection setup may no longer satisfy the canonical startable verification contract.	tests/Pest.php, touched verification fixture call sites, then StartVerification only if still wrong	yes	Resolved by using the canonical credential-enabled verification fixture path.	resolved
VerificationStartAfterCompletionTest	verification-start-contract	provider-verification-runtime-regression	A post-completion verification restart does not produce the expected fresh run and falls back to the wrong run identity or blocked behavior.	StartVerification, one-hop OperationRunService identity path only if proven	only-if-runtime-owner-proven	Resolved after fixture alignment; reruns proved the runtime owner contract was already correct.	resolved
VerificationStartDedupeTest	verification-start-contract	provider-verification-runtime-regression	Repeated verification starts return conflicting run keys instead of one canonical deduped run contract.	StartVerification, one-hop OperationRunService identity path only if proven	yes	Resolved after fixture alignment; reruns proved the runtime owner contract was already correct.	resolved
ProviderConnectionHealthCheckWritesReportTest	verification-report-summary	surface-or-report-baseline-drift	summary.counts.total now reflects a larger emitted check inventory than the stale hard-coded ceiling in the test.	MicrosoftProviderHealthCheck, directly implicated report writer seam, test expectation	yes	Resolved by removing the stale literal ceiling and pinning the count to the emitted check inventory.	resolved

Classification Rules

• Every in-scope failure group must keep exactly one seam and one category.
• If a rerun shows the failure is gone after adjacent fixture alignment, reclassify it to resolved-or-not-needed instead of widening runtime code.
• If a rerun proves the problem lives outside the bounded ProviderConnections/Verification scope, reclassify it to out-of-scope-existing-debt and stop widening 294.
• Do not invent a new category or seam inside implementation without first updating spec.md, plan.md, research.md, data-model.md, quickstart.md, tasks.md, and checklists/requirements.md.