Introduction.

Vehicle checks, opening inspections, maintenance jobs, and warehouse close-downs all record answers to a fixed list of questions. If you edit that list in place, older answers no longer match the questions that produced them.

Laravel Checklist runs that work from template authoring through review. You can publish a template, start or schedule a checklist, record answers with notes and evidence, submit a scored result, and store a review outcome. Each checklist stays tied to the exact version it used, so later template edits do not change its questions or results.

use ByRcsc\LaravelChecklist\Authoring\TemplateBuilder;

$version = TemplateBuilder::make('Vehicle inspection')
    ->passFail('Tires are roadworthy')->required()->critical()
    ->text('Notes', maxLength: 500)
    ->publish();

$checklist = $version->start(subject: $vehicle, assignedTo: $driver);
$checklist->answer($version->items()->firstOrFail(), 'pass', $driver);
$checklist->submit();

The package supplies the checklist engine and Eloquent models. Your application supplies the forms, authorization, users, teams, and file-serving rules.

The package also runs on SQLite in its test workbench. The supported production matrix tests MySQL and PostgreSQL directly.

Key terms

A template holds the shared name for a family of versions. A template version holds the sections, items, conditional rules, and pass threshold as they exist when you publish it. Publishing makes that structure immutable.

A checklist is one run of a published version. It may point at a subject, such as a vehicle, and an assignee. Both links are optional.

A response holds the current answer to one item. Correcting an answer updates that response, while the append-only action history retains the before and after values.

Included behavior

• Nine input forms across eight item types. Single and multiple select share the same item type.
• Required answers, conditional evidence and notes, and conditional item or section visibility.
• Weighted scores, pass thresholds, critical failures, and nested section rollups stored at submission.
• Storage-backed photos, files, and signatures with MIME, size, and SHA-256 metadata.
• Daily, weekly, monthly, and every-N-days schedules with due-soon and overdue transitions.
• Laravel events, mail and database notifications, query scopes, reports, export data objects, and a hash-chained action history.

What it does not do

Laravel Checklist has no facade and no user interface. Use the builder and models directly.

It does not provide authorization, file URLs, thumbnails, PDF rendering, threaded comments, assignment routing, or multi-stage approval. It also does not expose custom item type registration in v1.

Three further exclusions are deliberate rather than pending:

• iCal RRULE recurrence. Schedules support daily, weekly, monthly, and every-N-days recurrence. They do not parse iCal RRULE expressions.
• Repeatable sections, such as one copy per room. A published version owns its section structure. Adding sections at run time would make completed checklists differ from their published version.
• Materialized or cached statistics tables. Reports are plain queries against stored results, so nothing can fall out of step with the data.

For threaded comments and multi-stage approval, see Composing with sibling packages.

What to read next

• Installation and setup to publish the package assets and create its tables.
• Quick start to complete and review one checklist.
• Templates and versions to understand why published structure cannot change.