TenantAtlas/specs/216-provider-dispatch-gate/spec.md

Feature Specification: Provider-Backed Action Preflight and Dispatch Gate Unification

Feature Branch: 216-provider-dispatch-gate
Created: 2026-04-19
Status: Draft
Input: User description: "Provider-Backed Action Preflight and Dispatch Gate Unification"

Spec Candidate Check (mandatory — SPEC-GATE-001)

• Problem: Provider-backed actions currently use two different start patterns, so the same missing-prerequisite or concurrency problem can be blocked before queue on one surface but only discovered later as a failed run on another.
• Today's failure: Operators click a provider-backed action, see nothing obviously wrong, and only later discover that the job failed because a primary connection, valid consent, usable credentials, or an available scope was missing.
• User-visible improvement: Covered provider-backed action surfaces all answer the same first question immediately using one public vocabulary: was the start queued, is it already running, is the scope busy, or is it blocked and what should I do next.
• Smallest enterprise-capable version: Extend one canonical preflight-and-dispatch path plus one shared result-presentation contract to every current operator-triggered provider-backed start surface, without redesigning provider architecture or adding new provider domains.
• Explicit non-goals: No provider-connection label redesign, no broad provider-domain expansion, no operation naming overhaul, no new workflow hub, no legacy-credential cleanup, and no full backend normalization of every legacy provider service in this spec.
• Permanent complexity imported: One expanded start-gate contract, one shared start-result presentation contract, focused regression coverage across existing action hosts, and limited next-step translation expansion where current blocked reasons are insufficient.
• Why now: The roadmap marks this as an active adjacent hardening lane, the proven start-gate pattern already exists, and every new provider-backed action that bypasses it increases trust debt on core operator surfaces.
• Why not local: The failure mode spans tenant action surfaces, provider-connection surfaces, onboarding, and monitoring. Per-action fixes would recreate inconsistent blocked, deduped, and next-step language on roughly twenty workflows.
• Approval class: Core Enterprise
• Red flags triggered: New shared support contract and broad multi-surface rollout. This remains justified because it does not add new persisted truth, it protects operator trust on remote actions, and the narrowest alternative is still one shared gate rather than many local copies.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 1 | Komplexität: 1 | Produktnähe: 2 | Wiederverwendung: 2 | Gesamt: 10/12
• Decision: approve

Spec Scope Fields (mandatory)

• Scope: workspace, tenant, canonical-view
• Primary Routes: /admin/t/{tenant}/... existing tenant-scoped provider-backed action surfaces, /admin/provider-connections, /admin/onboarding/..., /admin/operations/{run}
• Data Ownership: Tenant-owned provider connections and tenant-bound operation runs remain the authoritative runtime records. Workspace context continues to scope access and canonical monitoring views; this spec does not introduce new persisted ownership models.
• RBAC: Existing workspace membership, tenant entitlement, and per-action capabilities remain authoritative. Preflight blocks never replace server-side authorization checks.

For canonical-view specs, the spec MUST define:

• Default filter behavior when tenant-context is active: Canonical run links opened from a tenant-context action continue to preserve the active tenant context and related filtering behavior rather than widening back to all tenants by default.
• Explicit entitlement checks preventing cross-tenant leakage: Canonical run detail, existing-run dedupe links, and blocked next-step guidance must only be built after workspace membership and tenant entitlement are confirmed. Non-members or non-entitled viewers remain deny-as-not-found and must not learn whether another tenant currently has an active conflicting run or configured provider connection.

UI / Surface Guardrail Impact (mandatory when operator-facing surfaces are changed; otherwise write N/A)

Surface / Change	Operator-facing surface change?	Native vs Custom	Shared-Family Relevance	State Layers Touched	Exception Needed?	Low-Impact / N/A Note
Tenant-scoped provider-backed start surfaces	yes	Native admin actions + shared provider-start feedback	shared provider action family	page, modal, detail	no	Existing start actions remain; only preflight and queue-accept feedback are unified
Provider-connection resource surfaces	yes	Native admin actions + shared provider-start feedback	shared provider action family	table, detail	no	Existing connection-check and provider-triggered actions adopt the same result language
Onboarding provider step	yes	Native wizard actions + shared provider-start feedback	shared provider action family	wizard step	no	No new onboarding page is introduced
Canonical provider-backed operation run detail	yes	Native monitoring detail primitives	shared monitoring family	detail	no	Run detail keeps diagnostics secondary to translated execution meaning

Decision-First Surface Role (mandatory when operator-facing surfaces are changed)

Surface	Decision Role	Human-in-the-loop Moment	Immediately Visible for First Decision	On-Demand Detail / Evidence	Why This Is Primary or Why Not	Workflow Alignment	Attention-load Reduction
Tenant-scoped provider-backed start surfaces	Primary Decision Surface	Decide whether to start remote provider work now or resolve a blocker first	Start accepted vs blocked vs already running vs scope busy, short reason, next step, existing-run path when relevant	Full run detail, low-level provider diagnostics, connection detail	Primary because this is the moment an operator commits to remote work or resolves a blocker	Follows the action-start workflow directly on the tenant work surface	Removes the need to click, wait, and later inspect a failed run for preventable prerequisite problems
Provider-connection resource surfaces	Secondary Context Surface	Resolve provider readiness and retry a blocked provider-backed action	Current start-prevention reason, next step, retry path	Connection detail, historical runs, deeper diagnostics	Secondary because the connection surface supports the real start decision rather than replacing it	Follows provider-readiness remediation workflow	Shortens recovery from blocked states without inventing a second start dialect
Onboarding provider step	Primary Decision Surface	Decide whether onboarding can proceed with provider-backed verification or needs operator follow-up	Start accepted vs blocked, reason, next step, safe continue path	Provider detail, existing run detail, low-level diagnostics	Primary because onboarding must tell the operator immediately whether the next remote step can proceed	Follows onboarding completion workflow, not monitoring navigation	Prevents onboarding from feeling successful until a hidden failed run appears later
Canonical provider-backed operation run detail	Tertiary Evidence / Diagnostics Surface	Understand what happened after a covered operation was actually accepted	Human-readable outcome, dominant reason, next step, scope identity	Raw payload context, low-level diagnostics, implementation detail	Tertiary because operators usually arrive here after a start surface or notification already answered the first decision	Follows drill-in and troubleshooting workflow	Keeps deep diagnostics available without making them the first explanation for start-preventing problems

UI/UX Surface Classification (mandatory when operator-facing surfaces are changed)

Surface	Action Surface Class	Surface Type	Likely Next Operator Action	Primary Inspect/Open Model	Row Click	Secondary Actions Placement	Destructive Actions Placement	Canonical Collection Route	Canonical Detail Route	Scope Signals	Canonical Noun	Critical Truth Visible by Default	Exception Type / Justification
Tenant-scoped provider-backed start surfaces	Record / Detail / Edit	Detail-first Operational Surface	Start work or resolve the blocker that prevented it	Existing detail page or modal on the current tenant surface	forbidden	Existing safe navigation remains secondary to the primary start decision	Existing dangerous actions stay where they already live; this spec adds none	/admin/t/{tenant}/...	existing tenant-scoped detail routes	Workspace and tenant scope, action target, provider readiness	Provider-backed operations / Provider-backed operation	Whether the action can start now and what the operator should do next	none
Provider-connection resource surfaces	List / Table / Bulk	CRUD / List-first Resource	Inspect provider readiness or start a connection-scoped check	Full-row click to connection detail where already used	allowed	Existing secondary actions remain grouped or contextual	Existing destructive connection lifecycle actions remain in danger placements	/admin/provider-connections	existing provider-connection detail route	Workspace and tenant scope, provider identity, readiness state	Provider connections / Provider connection	Whether the connection is usable for the requested operation	none
Onboarding provider step	Workflow / Wizard / Launch	Wizard / Step-driven Flow	Continue onboarding or resolve provider prerequisites	Existing wizard step as the only primary context	forbidden	Secondary navigation stays outside the primary step action	Destructive actions are out of scope	/admin/onboarding/...	existing onboarding step route	Workspace and tenant scope, onboarding phase, provider readiness	Onboarding / Onboarding step	Whether onboarding can continue with provider-backed work right now	none
Canonical provider-backed operation run detail	Record / Detail / Edit	Detail-first Operational Surface	Inspect the accepted run or open the related resolution surface	Explicit run detail page	forbidden	Related navigation and diagnostics remain secondary	Destructive actions are out of scope	/admin/operations	/admin/operations/{run}	Workspace and tenant scope, operation target, provider identity, active vs terminal state	Operation runs / Operation run	What actually happened after the operation was accepted	canonical monitoring detail

Operator Surface Contract (mandatory when operator-facing surfaces are changed)

Surface	Primary Persona	Decision / Operator Action Supported	Surface Type	Primary Operator Question	Default-visible Information	Diagnostics-only Information	Status Dimensions Used	Mutation Scope	Primary Actions	Dangerous Actions
Tenant-scoped provider-backed start surfaces	Tenant operator or manager	Decide whether to start remote provider work now	Detail / launch affordance	Can this operation start now, and if not, what should I do next?	Start result, short reason, next step, existing-run path where relevant	Low-level provider diagnostics, raw failure context, deeper connection detail	start eligibility, dedupe, concurrency, actionability	Microsoft tenant and TenantPilot run creation when accepted	Start operation, open existing run, open resolution surface	none added
Provider-connection resource surfaces	Tenant manager or owner	Resolve connection readiness and retry blocked work	List/detail	Is this connection ready for the operation I am trying to start?	Start result, reason, next step, connection identity	Historical diagnostics, low-level provider context	readiness, actionability	TenantPilot only until an operation is accepted	Inspect connection, run connection-scoped checks, retry action	Existing destructive connection actions unchanged
Onboarding provider step	Tenant manager or onboarding operator	Continue onboarding or stop to resolve provider readiness	Wizard step	Can onboarding proceed with the next provider-backed action?	Start result, reason, next step, safe continuation or resolution path	Deep provider diagnostics, monitoring drill-in	readiness, actionability, progress continuity	TenantPilot onboarding flow and remote provider work when accepted	Continue onboarding, open resolution path	none added
Canonical provider-backed operation run detail	Tenant operator, workspace operator, support reviewer	Diagnose accepted provider-backed work after it started	Detail	What happened to the accepted operation, and what should happen next?	Human-readable outcome, short reason, next step, scope identity	Raw payload context, exception detail, low-level provider metadata	execution outcome, completeness, actionability	none	Open related target, inspect diagnostics	none added

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no
• New persisted entity/table/artifact?: no
• New abstraction?: yes
• New enum/state/reason family?: no
• New cross-domain UI framework/taxonomy?: no
• Current operator problem: Operators cannot trust provider-backed start behavior because equivalent prerequisite and concurrency problems are surfaced at different times and in different languages depending on the action host.
• Existing structure is insufficient because: The current split between one guarded start path and many legacy local start paths creates inconsistent operator truth and inconsistent queue behavior across the same class of remote actions.
• Narrowest correct implementation: Reuse the existing canonical start-gate pattern and extend it to all current operator-triggered provider-backed starts, with one shared result-presentation contract and no new provider-domain framework.
• Ownership cost: One broader start-gate contract, one shared result-presentation contract, and focused regression coverage across covered action hosts and monitoring surfaces.
• Alternative intentionally rejected: Per-action preflight fixes on each surface. That would look cheaper short term but would preserve multiple provider-start dialects and duplicate concurrency logic in local action handlers.
• Release truth: Current-release truth. This feature closes a present operator and monitoring trust gap on already-shipped provider-backed workflows.

Testing / Lane / Runtime Impact (mandatory for runtime behavior changes)

• Test purpose / classification: Feature
• Validation lane(s): fast-feedback, confidence
• Why this classification and these lanes are sufficient: The change is proven by operator-visible start behavior, queue-accept semantics, dedupe and scope busy outcomes, and monitoring/notification alignment on existing action hosts. Focused feature coverage is the narrowest sufficient proof.
• New or expanded test families: Expanded action-surface feature coverage for tenant start surfaces, provider-connection surfaces, onboarding, and provider-backed run/notification alignment. Limited focused unit coverage may support start-result mapping, but the proving purpose remains feature-level.
• Fixture / helper cost impact: Moderate. Tests need provider connection state, tenant membership, action capability context, and active-run fixtures, but can reuse existing workspace and tenant setup.
• Heavy-family visibility / justification: none
• Special surface test profile: standard-native-filament
• Standard-native relief or required special coverage: Standard admin-surface feature coverage is sufficient; no browser or heavy-governance lane is required for the first slice.
• Reviewer handoff: Reviewers must confirm that missing prerequisites and concurrency collisions are caught before queue acceptance, that covered start surfaces all use the same result vocabulary, and that accepted runs still follow the canonical monitoring feedback contract.
• Budget / baseline / trend impact: Low-to-moderate increase in feature assertions around start surfaces and provider-backed run outcomes; no new heavy cost center expected.
• Escalation needed: none
• Active feature PR close-out entry: Guardrail
• Planned validation commands: cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=ProviderBackedActionStart; cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=ProviderConnection; cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=OperationRun

User Scenarios & Testing (mandatory)

User Story 1 - Block Before Queue (Priority: P1)

An operator starts a provider-backed action and needs the product to stop immediately when the operation cannot legitimately start, instead of silently queueing work that only fails later.

Why this priority: This is the direct trust and workflow problem the spec exists to solve. If preventable failures still appear only as later failed runs, the spec has not delivered its core value.

Independent Test: Can be fully tested by triggering covered actions under missing-connection, unusable-access, and active-run-conflict conditions and verifying that the operator receives an immediate blocked, deduped, or scope busy result before any background work is accepted.

Acceptance Scenarios:

1. Given a covered provider-backed action has no usable provider connection or access, When an operator starts it, Then the product blocks the start immediately and shows the cause and next step before any background work begins.
2. Given an equivalent action is already active for the same tenant or scope, When an operator starts the same action again, Then the product returns a deduped or scope busy result and points the operator to the existing work instead of queueing a duplicate.

---

User Story 2 - Same Start Semantics on Every Covered Surface (Priority: P2)

An operator encounters the same provider problem from different action surfaces and needs the product to describe it in the same way every time.

Why this priority: Shared start semantics are the leverage of the spec. Without cross-surface consistency, the product keeps teaching a different operational language per action host.

Independent Test: Can be fully tested by triggering the same blocked or allowed scenario from tenant surfaces, provider-connection surfaces, and onboarding, then verifying that all of them return the same result categories and next-step structure.

Acceptance Scenarios:

1. Given the same blocked prerequisite appears from a tenant action and from onboarding, When the operator starts both actions, Then both surfaces use the same outcome category and the same next-step pattern.
2. Given the same action can start from a tenant surface and a provider-connection surface, When the operator starts it from either place, Then both surfaces confirm acceptance using the same queued-start pattern and the same run-link semantics.

---

User Story 3 - Keep Monitoring Truthful After Accepted Work (Priority: P3)

An operator starts provider-backed work successfully and later needs monitoring and notifications to explain accepted work in the same human-readable language family used on the start surface.

Why this priority: Start-surface trust must carry through to monitoring. Otherwise the product still feels split between action UX and run UX.

Independent Test: Can be fully tested by accepting covered work, letting it finish in successful or failed terminal states, and verifying that run detail and terminal notifications preserve the same translated problem and next-step direction without pretending a preflight block was an execution failure.

Acceptance Scenarios:

1. Given a provider-backed action was accepted and later fails for execution-time reasons, When the operator opens run detail, Then the page explains the dominant problem and next step using the same humanized language family as the start surface.
2. Given preflight prevented a covered action from starting, When the operator later checks monitoring, Then there is no misleading ordinary failed run implying that remote work actually executed.

Edge Cases

• Membership or capability denial must retain 404 and 403 semantics and must not be flattened into generic blocked-prerequisite copy.
• A provider connection can change after click time; accepted work must remain bound to the selected connection identity or record that identity before execution continues.
• Legacy operator-triggered actions that still rely on implicit provider resolution remain in scope for start gating even before full provider-connection normalization lands.
• Scheduled or system-triggered provider work is out of scope for immediate click-time feedback, but any shared reason language reused by monitoring must stay aligned with the covered start contract.
• Busy, blocked, and degraded follow-up conditions can overlap conceptually; the operator surface must lead with one dominant result and one next step instead of several equal-weight warnings.

Requirements (mandatory)

Constitution alignment (required): This feature changes how existing provider-backed remote work is admitted to execution. It does not introduce new remote domains or new contract-registry object types. All underlying provider calls remain on the existing contract path. The gate runs before remote work is accepted and must preserve tenant isolation, run observability for accepted work, and focused regression coverage.

Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001): The feature adds one shared start-gate expansion and one shared result-presentation contract because the operator problem is already cross-surface and cannot be solved safely with local action copy. No new persisted entity, no second source of truth, and no new top-level operation state family are introduced.

Constitution alignment (TEST-GOV-001): Proof stays in focused feature coverage over existing action hosts and monitoring surfaces. No browser or heavy-governance family is added. Any helper introduced for provider start fixtures must keep provider, workspace, membership, and active-run context explicit rather than default.

Constitution alignment (OPS-UX): Accepted provider-backed starts continue to use the three-surface feedback contract: queued intent feedback, active progress surfaces, and one terminal database notification. Preflight-blocked starts do not emit accepted-start feedback and must not masquerade as ordinary execution-failed runs. Any accepted run continues to use the canonical run-transition service and numeric summary-count rules.

Constitution alignment (RBAC-UX): Covered start surfaces live on the tenant/admin plane and the canonical monitoring plane. Non-members or non-entitled viewers remain 404. Established members missing the required capability remain 403. Server-side authorization remains authoritative for every covered start action, and preflight guidance must never leak another tenant's connection or active-run existence.

Constitution alignment (OPS-EX-AUTH-001): No authentication-handshake exception is used. This feature does not introduce synchronous outbound provider work on monitoring or auth routes.

Constitution alignment (BADGE-001): Start-result and run-outcome semantics remain centralized. Covered surfaces must not invent local status mappings for blocked, deduped, scope busy, or accepted provider-backed starts.

Constitution alignment (UI-FIL-001): Covered surfaces continue to use native admin actions, shared notifications, and shared monitoring detail primitives. The feature standardizes action feedback and explanation order without introducing custom local status widgets.

Constitution alignment (UI-NAMING-001): The target objects remain the existing operation nouns such as sync, restore, capture, generate, or check. The canonical start-result model remains accepted, deduped, scope busy, and blocked, while operator-facing wording maps those outcomes to queued, already running, scope busy, and blocked. That mapping and next-step guidance must stay aligned across buttons, modals, run links, notifications, and monitoring detail.

Canonical vocabulary mapping: The shared start-result model uses the internal outcomes accepted, deduped, scope busy, and blocked. Operator-facing wording presents those outcomes respectively as queued, already running, scope busy, and blocked.

Constitution alignment (DECIDE-001): Tenant-scoped start actions and onboarding remain the primary decision moments because they determine whether remote work begins. Provider-connection surfaces remain supporting context for resolving blocked starts. Canonical run detail remains the diagnostic drill-in after work was actually accepted.

Constitution alignment (UI-CONST-001 / UI-SURF-001 / ACTSURF-001 / UI-HARD-001 / UI-EX-001 / UI-REVIEW-001 / HDR-001): The feature does not add a new inspect model or new primary pages. Existing action hosts keep navigation separate from mutation, secondary navigation stays grouped or contextual, destructive actions remain in their current danger placements, and run detail remains the canonical diagnostic destination for accepted work.

Constitution alignment (ACTSURF-001 - action hierarchy): Covered surfaces may standardize start-result feedback, but they must not mix navigation, mutation, and remediation into an unstructured catch-all. Existing start actions remain the primary action. Existing run links or resolution links remain secondary and contextual.

Functional Requirements

• FR-216-001: Every current operator-triggered provider-backed action that can accept remote provider work MUST pass through one canonical preflight-and-dispatch path before background execution is admitted.
• FR-216-002: The canonical start path MUST use one shared result model with exactly four canonical outcomes: accepted, deduped, scope busy, and blocked. Operator-facing wording MUST present those outcomes consistently as queued, already running, scope busy, and blocked.
• FR-216-003: Missing or unusable provider access, missing required permissions, non-operable tenant state, and equivalent start-preventing conditions MUST be detected before queue admission on all covered start surfaces.
• FR-216-004: A covered action that is blocked during preflight MUST not silently queue work and later appear as an ordinary execution-failed run.
• FR-216-005: Deduped and scope busy outcomes MUST be decided at click time for covered operations and MUST direct the operator to the existing work or the correct resolution path.
• FR-216-006: Accepted starts MUST bind to a specific provider connection identity and carry that identity into accepted-work context so later monitoring and notifications can explain which connection the work used.
• FR-216-007: Covered starts MUST use dispatch-time conflict protection so two conflicting provider-backed operations for the same protected scope cannot both be accepted at once.
• FR-216-008: Covered start surfaces MUST render the shared start outcomes through one shared presentation contract rather than action-local conditional copy.
• FR-216-009: The shared presentation contract MUST preserve each action's domain verb and target object while keeping the outcome vocabulary and next-step structure consistent across all covered start surfaces.
• FR-216-010: Terminal notifications and canonical run detail for accepted provider-backed work MUST use the same translated problem and next-step direction as the covered start surfaces whenever they are explaining the same problem class.
• FR-216-011: Existing guarded provider-backed starts that already use the canonical preflight pattern MUST migrate to the shared presentation contract without losing any current protection.
• FR-216-012: The first implementation slice MUST cover all current operator-triggered provider-backed starts reachable from tenant-scoped surfaces, provider-connection surfaces, and onboarding.
• FR-216-013: Scheduled or system-triggered provider operations are out of scope for click-time UX. In scope for this feature is only that Monitoring-side shared reason vocabulary and initiator-aware notification behavior for those runs remain compatible with the covered start contract where the same problem class is shown.
• FR-216-014: The feature MUST not introduce a second provider-start framework, a parallel queue-admission path, or new per-action local preflight logic for covered surfaces.
• FR-216-015: Monitoring and audit surfaces MUST continue to distinguish between work that was actually accepted and executed versus work that was prevented from starting.
• FR-216-016: Covered start and monitoring surfaces MUST preserve deny-as-not-found tenant isolation and must not leak other tenants' connection readiness, active-run existence, or provider identity through start-result messaging.

UI Action Matrix (mandatory when Filament is changed)

If this feature adds/modifies any Filament Resource / RelationManager / Page, fill out the matrix below.

For each surface, list the exact action labels, whether they are destructive (confirmation? typed confirmation?), RBAC gating (capability + enforcement helper), whether the mutation writes an audit log, and any exemption or exception used.

Surface	Location	Header Actions	Inspect Affordance (List/Table)	Row Actions (max 2 visible)	Bulk Actions (grouped)	Empty-State CTA(s)	View Header Actions	Create/Edit Save+Cancel	Audit log?	Notes / Exemptions
Tenant-scoped provider-backed start surfaces	Existing tenant detail pages and tenant-scoped resource pages that already expose provider-backed starts	Existing start actions such as sync, restore, capture, generate, or verify remain; no new header action is introduced by this spec	Existing inspect model remains unchanged on each host surface	Existing safe start affordances remain; no new visible destructive row action is added	Existing grouped bulk actions remain unchanged	Existing empty-state guidance remains unchanged	Existing start actions continue where already present	Existing create and edit flows remain unchanged	Existing operation-start and accepted-run audit behavior remains authoritative	This spec standardizes preflight result handling, not action inventory
Provider-connection resource surfaces	Existing provider-connection list and detail surfaces	Existing connection-management actions remain; connection-scoped checks adopt the shared start-result pattern where relevant	Full-row click or explicit inspect behavior remains unchanged	Existing safe actions such as inspect or connection health checks remain; no new destructive row action is added	Existing grouped bulk actions remain unchanged	Existing add-connection CTA remains unchanged	Existing connection-scoped start actions continue where already present	Existing create and edit flows remain unchanged	Existing connection lifecycle and accepted-run audit behavior remains authoritative	No connection-label redesign is introduced here
Onboarding provider step	Existing onboarding wizard step that triggers provider-backed verification or follow-up work	none added	n/a	n/a	none	Existing continue/setup CTA remains	Existing step actions remain the only primary controls	Existing save/continue flow remains	Existing onboarding audit behavior remains authoritative	The step adopts the shared blocked, deduped, scope busy, and accepted semantics
Canonical provider-backed operation run detail	Existing canonical monitoring detail surface	no new header action	Existing run detail open model remains canonical	none added	none	n/a	Existing related navigation remains	n/a	Existing run audit behavior remains authoritative	Detail hierarchy changes only insofar as it must stay aligned with the shared start-result language

Key Entities (include if feature involves data)

• Provider-backed Start Surface: Any existing operator-facing action host that can admit remote provider work and therefore must answer whether the operation can start now.
• Preflight Start Result: The shared start outcome for a covered action, including the canonical results accepted, deduped, scope busy, or blocked plus the operator-facing mapping to queued, already running, scope busy, or blocked, the short reason, and the next-step direction.
• Accepted Provider-backed Run Context: The canonical accepted-work context that records scope identity, chosen provider connection, and the related run or resolution path once work is admitted.

Assumptions & Dependencies

• Provider Connection Resolution Normalization remains a soft dependency. This spec may use bridge behavior where current operator-triggered starts still rely on legacy provider-resolution internals, but accepted work must still record the chosen connection identity consistently.
• Shared outcome vocabulary and translated next-step guidance from the operator-truth lane are available to extend rather than re-invent.
• No new provider domain, no platform-wide operation naming rewrite, and no provider-connection UX relabeling are pulled into this scope.
• Existing canonical monitoring detail and terminal notification behavior for accepted runs remain authoritative and are aligned, not replaced.

Success Criteria (mandatory)

Measurable Outcomes

• SC-216-001: In regression coverage for all covered start surfaces, 100% of seeded missing-prerequisite and scope-conflict scenarios are surfaced to the operator before any background work is accepted.
• SC-216-002: In release review across the covered start surfaces, operators encounter exactly one shared public start vocabulary: queued, already running, scope busy, and blocked.
• SC-216-003: In concurrent-start regression scenarios for the same protected scope, at most one provider-backed operation is accepted and all additional attempts are resolved as deduped or scope busy before queue admission.
• SC-216-004: In acceptance review, an operator can identify the next action for a blocked covered start within 10 seconds without opening low-level diagnostics.
• SC-216-005: Equivalent prerequisite problems no longer surface as immediate blocked guidance on one covered action and only as an after-the-fact ordinary failed run on another covered action.
• SC-216-006: In regression coverage for scheduled or system-triggered provider-backed runs that reuse shared reason translation, Monitoring preserves the same public wording for the same problem class without emitting initiator-only completion UX meant for click-time starts.