Activation Security Check Extension Laravel Package

Product Decisions This Supports

• Activation gating as a policy decision, not a code decision. The package implements the "user must be activated before proceeding" enforcement point as a pluggable security check in the Anomaly Users module. As a PM, this is the decision to make explicitly: do unactivated accounts get blocked at login, at route access, or only at first privileged action? The package's existence tells you the ecosystem expects this to be a configurable check rather than hardcoded logic — that framing is useful in your own architecture reviews.
• Build vs. buy vs. borrow. At roughly the scope of a single security-check class, this is a "borrow the pattern" decision, not a vendor decision. The PM-level call is whether your team writes 50–150 lines against your own auth stack or adopts an existing extension. Treat the repo as a reference implementation and spec, not a dependency.
• Roadmap input for account lifecycle and onboarding. Concrete use cases: blocking login for self-registered users pending email confirmation, gating admin-invited or provisioned accounts that haven't completed first login, preventing access for deactivated/suspended users, and separating "account exists" from "account is usable" in your onboarding funnel metrics.
• Compliance and trust-and-safety scoping. Activation enforcement is a common control in KYC-lite onboarding, anti-abuse (blocking throwaway registrations), and access-review requirements. Helps you decide whether activation state is a hard gate, a soft gate, or an auditable signal.
• Informing the extension-point contract. If your platform has (or should have) a registry of security checks that run in sequence at authentication time, this package is evidence that such a registry is the expected integration seam — useful when prioritizing platform extensibility work.

When to Consider This Package

Consider it when all of the following hold:

• You are already running Anomaly Labs / PyroCMS Streams Platform with the anomaly/users module and its security-check registry; the extension is meaningless outside that context.
• You need only the activation-state gate — nothing more — and want it as a drop-in rather than custom code.
• You can accept the maintenance risk of a small, low-traffic, single-vendor extension (2 stars, 0 dependents) and are willing to vendor/fork it.

Look elsewhere — or write it yourself — when:

• The license is unclear. NOASSERTION means the repository does not declare a recognized license. For any commercial product, this is a hard stop until the author clarifies; you cannot safely redistribute or embed it. This alone usually kills adoption.
• You are on stock Laravel. Laravel already ships MustVerifyEmail and the verified middleware. Reimplementing this as a package adds a dependency for behavior you get for free; a two-line route middleware gets you there.
• You need more than activation. Password policy, MFA, rate limiting, lockout, session/device checks, IP allowlisting — none of that is in scope here. Do not let one narrow check stand in for an auth hardening roadmap.
• You need maintenance guarantees. Zero dependents and a single-maintainer, low-signal repo means no community backstop. No security disclosure process, no release cadence, no third-party review.
• Your platform is current-generation. The Streams Platform ecosystem is effectively legacy; adopting its extensions creates a migration liability you will pay for later.

How to Pitch It (Stakeholders)

To executives: This is a very small, narrowly scoped extension that enforces one rule — unactivated users can't get in. It is not a security product, and it is not a strategic dependency. It is useful to us as a reference pattern for how to implement activation gating cleanly, and as a prompt to make an explicit product decision about whether unactivated accounts should be blocked, and where. My recommendation is do not adopt it as a dependency: the license is undeclared, it has essentially no user base, and it only works inside a legacy CMS ecosystem. If we need this behavior, we should implement it in our own stack in under a day.

To engineering: Treat this repo as a design reference for a pluggable "security check" that runs at authentication time and asserts account-activation state. In a standard Laravel app, the equivalent is MustVerifyEmail plus the verified middleware, extended to cover admin-invited and suspended accounts. Key requirement to carry forward: activation state must be a distinct, queryable field with a clear enforcement point, so it can serve as both a gate and an onboarding metric. Do not add the package to composer.json until the license is resolved in writing.