Legal Consent For Laravel Laravel Package

Product Decisions This Supports

• Make consent evidence defensible, not just collected. The package records each published legal-text version, every consent given to it, and a hash-chained ledger (legal-consent:verify-ledger). That turns "we have a checkbox" into an auditable artifact — a decision you can take to legal, security review, or a regulator without building a bespoke evidence pipeline.
• Decide how policy changes reach users. Versioned documents plus per-version consents let you answer the roadmap question "when a policy changes, who must re-consent and how do we prove it?" without designing that state machine yourself. legal-consent:changes and legal-consent:rerender support the content-change workflow.
• Integrate with an external system of record instead of replacing it. v0.47.0's sourceVersion lets a source (CMS, DMS, contract system) supply its own revision counter, stored verbatim alongside SemVer on the published version, on each consent, and in history(). It is inert for SemVer logic — it decides nothing — so it cannot break existing version resolution. For product this means you can adopt the package alongside an existing document repository rather than migrating authorship, and you still get a defensible link between "what the source published" and "what the user accepted."
• Choose per-source versioning policy deliberately. A source that supplies a source version but no SemVer gets deterministic behavior: first publication is 1.0.0, each subsequent one is the next minor of the active version, and republishing changed text under an already-published source version is refused. That is a real product rule (monotonic, no silent rewrites) you can adopt as-is or use as a constraint on how upstream editors are allowed to operate.
• Build vs buy for the UI shell. WireKit views are now pinned to pushery/wirekit 2.67.0, with plain-view fallback below it and legal-consent:doctor naming the floor. This is a concrete make-or-buy line: adopt the shipped dialog/views for speed, or publish and own them (vendor:publish --tag=legal-consent-wirekit) if your design system demands it — accepting that published copies do not receive view fixes automatically.
• Operational trust as a product requirement. The heartbeat contract now names seven failure-only signal names to alert on (including legal-consent:dispatch-notices.canceled since 0.45.0). If notice delivery is part of your compliance story, this is the difference between "we send notices" and "we can show notices were sent, and know when they weren't."
• Multi-tenant roadmap. Tenancy is treated as a first-class concern in the command surface (verify-ledger, cache-flush, rerender, changes each document how they treat tenants). That supports shipping consent as a per-workspace/per-brand capability rather than a single-tenant afterthought.
• Agent-assisted delivery. The Laravel Boost skill now names the four previously omitted commands, so an AI agent working in your codebase can actually suggest rerender, changes, cache-flush, and verify-ledger. Marginal, but it lowers the cost of onboarding engineers to the package's operational surface.

When to Consider This Package

Consider it when:

• You are on Laravel/PHP and consent is a legal/audit obligation (GDPR/ePrivacy-style consent records, terms acceptance, policy re-consent), not merely a cookie banner.
• You need versioned legal text with per-version consent evidence and a tamper-evident trail — i.e., you would otherwise hand-roll versioning, consent joins, and hashing.
• You have, or will have, external document ownership (marketing site, CMS, DMS) and want the package to record the source's own revision identity via sourceVersion without letting that external counter govern SemVer resolution.
• You operate multiple tenants/brands and need commands that are explicit about tenant scope.
• You want observability hooks for scheduled work (heartbeats, failure-only alert names) so silent non-delivery is detectable.
• Your team is comfortable running php artisan migrate as part of upgrades and reading upgrade notes — this release requires it, and consent row hashes are preserved because a source version is folded into the record hash only when present.

Look elsewhere when:

• You are not on Laravel — the value here is deep framework integration (migrations, commands, Blade/WireKit views, Boost skill); a different stack should use a different tool.
• You need only a consent banner with no evidentiary requirement; the versioning/ledger machinery is overhead you will pay for in migrations and upgrade discipline.
• You require e-signature, identity verification, or qualified/advanced electronic signatures with vendor legal attestation — that is a different product category.
• You need a stable, frozen public API. At 0.47.0 this is pre-1.0; the release itself shows the shape of churn (view-source pin bumps, a support class promoted to public API, migration changes). If you cannot absorb periodic migrations and vendor-publish refreshes, wait or budget for it.
• You cannot run migrations on upgrade or cannot tolerate published-file drift: published migrations and published WireKit views are snapshots. This release fixes the dialog by default, but vendor:publish --force is required for anyone who published views earlier — a fix you must choose to take.
• You want vendor-hosted SaaS with an SLA; this is a package you operate.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can stop treating consent as a front-end checkbox and start treating it as evidence. This Laravel package records which version of which legal text a person agreed to, keeps a hash-chained ledger we can verify on demand, and gives us an alerting contract for the background jobs that deliver notices — so our answer to "prove it" is a command, not a project. The new release makes it practical to keep authoring legal text in our existing document system: the source's own revision number is recorded verbatim next to the package's version and is deliberately inert, meaning it adds traceability without changing how versions resolve. Cost is bounded: it is a library we install and migrate, not a platform we buy, and this release also removes friction that would have shown up in code review — published migrations now call only public API, so static analysis is clean without editing vendor-published files.

For engineering (summary):

• Adopt: source_version on published versions and document_source_version on consents (also surfaced in history()). Requires php artisan migrate (or publishing 0001_01_01_000041_record_the_version_its_source_counts first if migrations are published). Hash-compatibility is preserved — source version only participates in the record hash when non-null, so no re-chaining, including for rows written before the upgrade.
• Versioning contract to encode in tests: source version + no SemVer ⇒ first publish is 1.0.0, subsequent publishes are the next minor of the active version, and a changed body under an already-published source version is refused. Treat that refusal as a feature; surface it to editors.
• Dependency: WireKit views are served from pushery/wirekit 2.67.0; below it auto falls back to plain views (as it did below 2.56.0), and legal-consent:doctor reports the floor. 2.67.0 is the oldest release the package's own suite installs, i.e. the proven floor — pin at or above it.
• Take the fix deliberately: the legal-text dialog now uses a button for "Open as a page" and lets text fill the dialog. Published view copies do not get this — run php artisan vendor:publish --tag=legal-consent-wirekit --force and diff.
• Optional dev tooling: composer.json now suggests pushery/sqlens-for-laravel; seven migrations carry #[NoSqlOnDriver]. Attributes are inert without it — no runtime dependency.
• Alerting: update runbooks and dashboards to seven failure-only heartbeat names, adding legal-consent:dispatch-notices.canceled. Docs and the Boost skill are corrected; if your own runbook copied the old "six", it is now wrong.
• Agent/onboarding: Boost skill now documents rerender, changes, cache-flush, verify-ledger, each with applicability and tenant behavior — useful for both new engineers and in-editor agents.
• Risk note: pre-1.0. Budget for migrations and vendor-publish refreshes at each minor; treat published files as forks you own.