# Quickstart: Queued Execution Reauthorization and Scope Continuity

## Goal

Validate that queued tenant-affecting work is re-authorized when execution begins, blocked runs fail closed before side effects, and Monitoring clearly distinguishes blocked execution from generic failure.

## Prerequisites

1. Start Sail.
2. Ensure at least one workspace exists with a tenant that can run provider, inventory, or restore operations.
3. Ensure at least one actor-bound operation and one initiator-null or scheduled-style operation can be queued in the local environment.
4. Ensure queue workers are running through Sail.

## Implementation Validation Order

### 1. Run focused unit coverage for the execution-legitimacy core

```bash
vendor/bin/sail artisan test --compact tests/Unit/Operations/QueuedExecutionLegitimacyGateTest.php
vendor/bin/sail artisan test --compact tests/Feature/Operations/QueuedExecutionMiddlewareOrderingTest.php
```

Expected outcome:
- Legitimacy decisions distinguish actor-bound and system-authority execution.
- Denial reasons distinguish capability, scope, operability, and prerequisite failures.
- A run is not marked `running` before legitimacy passes.

### 2. Run focused provider-operation tests

```bash
vendor/bin/sail artisan test --compact tests/Feature/Verification/ProviderExecutionReauthorizationTest.php
vendor/bin/sail artisan test --compact tests/Feature/Operations/RunInventorySyncExecutionReauthorizationTest.php
```

Expected outcome:
- Dispatch-time provider blocking still works.
- Execution-time scope or prerequisite changes block the job before side effects.
- Blocked runs remain visible in Monitoring with stable reason codes.

### 3. Run focused restore and write-hardening tests

```bash
vendor/bin/sail artisan test --compact tests/Feature/Operations/ExecuteRestoreRunExecutionReauthorizationTest.php
```

Expected outcome:
- Restore or write jobs no longer depend on job-local checks alone.
- Execution-time blocking remains observable as a blocked run, not a silent skip or generic failure.

### 4. Run focused bulk and retry-path tests

```bash
vendor/bin/sail artisan test --compact tests/Feature/Operations/BulkOperationExecutionReauthorizationTest.php
vendor/bin/sail artisan test --compact tests/Feature/Operations/QueuedExecutionRetryReauthorizationTest.php
vendor/bin/sail artisan test --compact tests/Feature/Operations/QueuedExecutionContractMatrixTest.php
```

Expected outcome:
- Representative bulk orchestrators re-check legitimacy when execution begins.
- Retry attempts perform a fresh legitimacy decision instead of inheriting stale authority.

### 5. Run focused Monitoring and notification tests

```bash
vendor/bin/sail artisan test --compact tests/Feature/Operations/OperationRunBlockedExecutionPresentationTest.php
vendor/bin/sail artisan test --compact tests/Feature/Operations/SystemRunBlockedExecutionNotificationTest.php
vendor/bin/sail artisan test --compact tests/Feature/Operations/QueuedExecutionAuditTrailTest.php
vendor/bin/sail artisan test --compact tests/Feature/Operations/TenantlessOperationRunViewerTest.php
```

Expected outcome:
- User-initiated blocked runs still use the canonical terminal feedback path.
- Initiator-null blocked runs remain visible in Monitoring without initiator-only terminal DB notifications.
- Run detail clearly distinguishes `blocked` from `failed`.
- Canonical operations access preserves `404` for non-entitled actors and `403` for in-scope capability denial on both `/admin/operations` and `/admin/operations/{run}`.

### 6. Manual smoke-check in the browser

1. Start a tenant-affecting queued operation from an existing admin surface.
2. Before the worker processes it, revoke the initiating user's relevant capability or tenant membership.
3. Let the worker pick up the job and confirm `/admin/operations` shows the blocked run without misclassifying it as generic failure.
4. Open `/admin/operations/{run}` and confirm the run is terminal with a blocked-style reason and no side effects occurred.
5. Validate that a non-entitled actor receives `404` and an in-scope actor lacking capability receives `403` on both canonical operations surfaces.
6. Repeat with a tenant that becomes non-operable before execution.
7. Repeat with a scheduled or initiator-null run and confirm Monitoring shows the blocked outcome without a user-targeted completion notification.

## Non-Goals For This Slice

- No new external or public API routes.
- No new Graph contract registry entries.
- No new assets, panel registration changes, or UI redesign.
- No repo-wide migration of every queued job in one pass beyond the explicitly in-scope job families listed in this spec.