# Laravel delivery acceptance workbook

Prepared 30 September 2026. A blank planning worksheet with a fictional report-review example, not evidence of a deployed application.

Guides: [Reverb](https://nomadicsoft.io/blog/laravel-reverb-private-channels), [Filament](https://nomadicsoft.io/blog/laravel-filament-admin-panel), [Sail](https://nomadicsoft.io/blog/laravel-sail-local-development).

## 1. One workflow and its owner

- Application/revision:
- Person completing the task:
- Starting condition and representative fictional data:
- Business result the person needs:
- Acceptable delay:
- Out of scope:
- Reviewer and evidence location:

Example: a support reviewer requests one retry of a customer's failed report, the worker records the new attempt, and the authorized customer can see the current result. A successful button click alone is not completion.

## 2. Local service inventory

| Process/service | Version or image | Caller | Internal address | Host/browser address | Verification |
| --- | --- | --- | --- | --- | --- |
| Laravel/PHP | | | | | |
| Database | | Laravel | | | |
| Redis/queue | | Worker and app | | | |
| Reverb, if needed | | App and browser | | | |
| Frontend build | | Browser | | | |
| Mail catcher/sandbox | | App | | | |

Record the committed Compose filename, environment template, dependency lockfiles, seed procedure and required PHP extensions. Keep credentials out of this worksheet. Mark unsupported integrations explicitly.

## 3. Staff access matrix

Fill every cell with allow, deny or a precise condition. Include customer/tenant scope. Role names alone are insufficient.

| Actor | Enter panel | List/view records | Add note | Request retry | Export/download | Manage access |
| --- | --- | --- | --- | --- | --- | --- |
| Customer | | | | | | |
| Support reader | | | | | | |
| Operations reviewer | | | | | | |
| Administrator | | | | | | |
| Revoked staff account | | | | | | |

Test direct record URLs, relation selectors, search results, exports, custom actions and permissions changed during an open session. Check the server response and resulting data, not only button visibility.

## 4. Retry operation contract

- Eligible starting states:
- Required permission and customer scope:
- Required reason and actor identity:
- Attempt/operation ID:
- Concurrent-update rule:
- Stored state before enqueue:
- Queue connection and name:
- Evidence of actual completion:
- How uncertain external results are reconciled:
- What makes repeating the action safe:

## 5. Acceptance record

| Case | Expected result | Actual result | Evidence | Reviewer/date |
| --- | --- | --- | --- | --- |
| Clean clone starts with fictional fixtures | | | | |
| Runtime and service versions identified | | | | |
| Owner reads/subscribes to own report | | | | |
| Another account requests that report | Denied | | | |
| Customer attempts internal panel entry | Denied | | | |
| Two staff request the same retry | One accepted attempt or documented conflict rule | | | |
| Transaction rolls back | No committed attempt/event | | | |
| Worker stops and resumes | State and queued work remain explainable | | | |
| Browser disconnects and reconnects | Current state recovered through an authorized read | | | |
| Access revoked mid-session | Further operations denied; socket behavior defined | | | |
| Environment stopped and started | Expected local data retained | | | |

## 6. Data reset and release decisions

- Which local data lives in named volumes?
- What must be exported before an intentional reset?
- Which fixture recreates the required starting state?
- Who confirmed that a reset may discard the selected data?
- Which long-lived workers/socket processes restart on release?
- What is the rollback boundary for queued payloads and schema changes?

Do not use volume deletion as an unexplained setup repair. Keep production release, backups, secrets and capacity checks separate from a local-development pass.