Laravel Accessproof Laravel Package

Getting Started

• Install as a dev-only dependency: composer require --dev mykholy/laravel-accessproof:^1.2. It is not a runtime package — nothing should reference it outside your test suite.
• Check your platform first: PHP 8.3+, Laravel 12 or 13. Verified against SQLite, MySQL 8, PostgreSQL 16, and an independent Laravel 13 app.
• Read docs/SCENARIOS.md (the scenario cookbook) before writing anything bespoke. It is the fastest path from install to a working cross-tenant test. Then skim docs/FIELD_REPORT.md to see the class of defects the tool was validated against — that list doubles as a checklist for what to write tests for in your own app.
• First use case: multi-tenant isolation. Create two tenants with one user and one record each in an isolated test database, then assert that the tenant-A user cannot read, update, or delete tenant-B's record. Use watchRows() to confirm no rows were silently written by a request that should have been denied.
• Wire it into a tests/Feature/Authorization suite using RefreshDatabase or DatabaseTransactions. Point it only at an isolated test database populated with synthetic fixtures.

Implementation Patterns

• Turn production defects into locked regressions. The field report categorizes nine real defects into three buckets: tenant selection, same-tenant object/role checks, and cross-tenant related-record references. Each of those categories maps directly to a test you should have. Write one test per historical bug and keep it forever.
• Two-tenant fixture baseline. The workhorse pattern is: tenant A + user A + record A, tenant B + user B + record B, then a matrix of acting-user × target-record × HTTP verb. A PHPUnit/Pest dataset provider keeps this readable — one test method, a dozen data rows.
• Combine with Laravel's built-ins, don't replace them. Gate::assertDenied(), assertAllowed(), and direct policy unit tests still cover the pure decision logic cheaply. Use this package where you need to exercise the full route → middleware → controller → policy → database path.
• watchRows() for side-effect assertions. This is the piece that catches the "returns 403 but already wrote the row / queued the job / touched the related record" class of bug. It works against actual SQLite records, so fixtures must be genuinely persisted, not in-memory models.
• Run a database matrix in CI. The field report explicitly re-ran the same 34 tests / 86 assertions on both SQLite and MySQL 8 and treated that as the bar. SQLite-only green is not evidence of correctness; add MySQL 8 and PostgreSQL 16 jobs for anything touching query scopes, soft deletes, or JSON columns.
• Mirror the dual-consumer CI pattern. The release notes describe one job installing the stable Packagist package and another installing the checked-out source. Reproducing that locally is a cheap way to catch packaging problems (missing files in the archive, autoload drift) that a source checkout hides.
• Keep it in the dev dependency graph, pinned. ^1.2 in require-dev; a patch-level bump should never require a code change.

Gotchas and Tips

• It is not a scanner. The package does not install authorization policies, crawl routes, or discover your endpoints. Coverage is exactly the tests you write. Do not assume an empty test suite means "no issues."
• Remote side effects are out of scope. Queued jobs, outbound HTTP, mail, and events are not monitored. Pair authorization tests with Queue::fake(), Http::fake(), Mail::fake(), and Event::fake() to close that gap yourself.
• Never point it at real data. The install notes say isolated test databases and synthetic fixtures only. Running authorization assertions against a staging copy of production risks both false results and data mutation.
• Treat the field report as scope, not certification. It is explicitly an anonymized regression report — 34 tests / 86 assertions in one private SaaS — not a security audit. Cite it internally as "this class of bug is catchable," not "we are certified compliant."
• watchRows() needs real rows. If your fixture builder leaves models in memory or uses make() instead of create(), row watching has nothing to observe and will silently look clean.
• Database parity surprises. Behavior that passes on SQLite can differ on MySQL 8 or PostgreSQL 16 around collation, nullable uniqueness, and cascading deletes. If a tenant-isolation test only fails on one engine, that is a finding, not flakiness.
• No documented extension points. The public PHP API is unchanged since 1.2.0, and the release notes describe no plugin or hook surface. Compose behavior through fixtures and dataset providers rather than reaching into internals — anything undocumented is fair game to break in a future patch.
• Safe upgrade. v1.2.1 is backwards compatible from v1.2.0 with no runtime changes; the delta is documentation and publication verification. Bump without ceremony, but do read the updated SCENARIOS.md — that is where the practical value landed.