User Module Laravel Package

Product Decisions This Supports

• Build vs. buy for auth and user management. This package is a real, worked Laravel user subsystem — accounts, profiles, password reset, optional roles/permissions, and admin CRUD — shipped as a self-contained module. Evaluating it forces the honest comparison: adopt an existing implementation, or build on Laravel's first-party auth stack. For most products the answer is the latter, but the comparison itself is the deliverable.
• Platform and CMS selection. It is a component of AsgardCMS, which means evaluating it is really evaluating an AsgardCMS-style, module-per-domain platform. That is a legitimate roadmap input if the product genuinely needs a pluggable back-office with modular administration.
• Architecture pattern reference. As a demonstration of Laravel module boundaries — isolated service providers, publishable config/migrations/views, per-domain routes and admin surfaces — it supports internal decisions about how to structure a multi-module Laravel product. This is the highest-value use, and it costs nothing.
• Dependency and maintenance-exposure assessment. The repo is marked read-only and redirected to AsgardCMS/Platform, with zero stars, zero dependents, and a NOASSERTION license. That profile is itself a decision input: any portfolio surface still on this lineage carries an unpriced maintenance and security liability that should be inventoried and budgeted.
• Legacy migration scoping. If a product sits on an older AsgardCMS build, this repo documents expected user-domain behavior — schemas, role/permission wiring, admin flows — and is directly useful when sizing a migration off the platform.
• Roadmap risk register entry. Zero field validation plus an ambiguous license plus a frozen upstream is a textbook "we would own this forever" item. Surfacing it now is cheaper than discovering it during a security review.

When to Consider This Package

Consider it when:

• You are maintaining an existing AsgardCMS deployment pinned to a version that consumes this module, and you need to understand, patch, or plan an exit from user-domain behavior.
• You want a reference implementation of AsgardCMS module structure and user/role/permission wiring for pattern-mining — read, not installed.
• You are running platform due diligence on AsgardCMS and need the full component inventory before committing.
• You are scoping a migration off a legacy CMS and need to bound the user-management surface area.

Look elsewhere when:

• You are starting a greenfield Laravel product. Use Laravel Breeze, Jetstream, or Fortify plus a maintained authorization package such as spatie/laravel-permission. Actively maintained, widely adopted, clearly licensed.
• You need production support, security patching, or a license you can rely on. NOASSERTION plus read-only status is a hard stop for commercial or compliance-sensitive work — legal must determine the grant before any engineering time is spent.
• You require community traction as a signal. Zero stars and zero dependents means no field validation, no install reports, no peer experience to lean on during an incident.
• You need documentation, issue triage, or an upgrade path. An archived module provides none of these, and it targets Laravel 4.2–5.x / PHP 5–7 — out of scope by version constraint for any modern stack.
• You need CMS-grade administration but are not already on AsgardCMS. Buy the platform decision wholesale (or evaluate a maintained alternative) rather than importing one orphaned module into a stack with no module loader.

If you must touch it: confirm the exact AsgardCMS/Platform version it maps to, fork from the maintained monorepo rather than this read-only repo, pin to a commit SHA, vendor it internally, verify license terms independently, and record it as a held dependency with a planned exit — never a strategic one.

How to Pitch It (Stakeholders)

To executives: This is an archived component of the AsgardCMS modular CMS, not a standalone product to adopt. It genuinely delivers user accounts, profiles, roles, and permissions as a Laravel module — real capability — but it is flagged read-only, redirects to its parent platform repo, has zero stars, zero downstream dependents, and an unresolved license. The score profile (0.88, opportunity 23.22) is consistent with a dead-end artifact: no adoption, no maintainer, superseded by its own successor. Recommendation: do not add it as a dependency. If user management is on the roadmap, fund the maintained first-party Laravel path — Breeze/Jetstream/Fortify plus Spatie Permission. The cost is low, the risk profile is dramatically better, and it does not pin us to an end-of-life runtime. The one caveat: if any live product still runs on AsgardCMS, that is a separate remediation conversation we should start now, because upstream has consolidated and this repo is frozen.

To engineering: Treat it as documentation, not a dependency. It is a clean illustration of module packaging in Laravel — isolated service providers, migrations, routes, and views per domain — and it shows how AsgardCMS separates user, role, and permission concerns. If our architecture needs a module-boundary model, mirror the pattern; do not inherit the code. Installing it is practically unsupported: Composer may resolve it, but it targets PHP 5–7 and Laravel 4.2–5.x, assumes the Asgard module loader and sibling modules (Media, Setting, Menu) exist, and has no install evidence in years. It also owns the security-critical surface — password reset, session handling, role assignment — with no advisory pipeline and no upstream fix path, so any vulnerability becomes a permanent internal fork obligation. If a product is still on AsgardCMS, inventory that exposure and plan the migration: extract the data model (it is small and portable), write reversible migrations, and fence the cutover with contract tests on login, logout, reset, and permission checks.

Decision in one line: Mine it for architecture patterns and legacy migration context; do not ship it.