User Laravel Package

Technical Evaluation

Architecture fit konekt/user is not a standalone auth package; it is a module within the Konekt/Concorde modular monolith ecosystem. Its core design decision is that a User is a login-capable extension of a Person (from konekt/person), with roles and permissions delegated to konekt/acl. That is a strong fit for CRM, ERP, back-office, and multi-tenant admin platforms where identity (person) and access (user) are deliberately separated, and where the app is assembled from Concord modules. It is a poor fit for consumer SaaS, API-first/headless products, or any team expecting a drop-in replacement for laravel/ui/Breeze/Fortify, because the abstraction it offers (person + user + ACL + module bootstrapping) is heavier than most products need.

Integration feasibility Feasibility is effectively gated by whether the organization has already committed to Concorde. Standalone adoption implies pulling in at least konekt/concorde, konekt/person, and konekt/acl, registering modules in the correct order, and accepting Concord's conventions for service providers, migrations, and route/model resolution. The auth surface itself (guard, provider, password hashing, remember tokens) is conventional Laravel, so the risk is not cryptographic but structural: dependency graph size, migration ordering, and module lifecycle assumptions. Expect days, not hours, for a first working integration even in a greenfield app.

Technical risk

• Adoption signal is weak: 2 stars, 0 dependents, opportunity score 46. This is a niche package inside a niche framework; there is no ecosystem gravity to lean on.
• Bus factor: effectively a single primary maintainer (ArtKonekt). No commercial support tier is evident.
• Coupling risk: the package's value is inseparable from Concorde and its sibling modules; pinning one version pins all of them.
• Security surface: authentication is a high-blast-radius component, and a low-audience package means fewer eyes on edge cases (session fixation, password reset flows, email verification, token expiry).
• Version drift: Laravel major-version compatibility must be verified per release rather than assumed.

Key questions to resolve before commitment

1. Which Laravel and PHP versions are supported in the latest tagged release, and what is the release cadence over the last 24 months?
2. Is the auth guard/provider customizable, or is it hard-wired to the Concord user model?
3. What is the supported path for password resets, email verification, 2FA, and API tokens — built-in, delegated, or absent?
4. How does the Person→User relationship behave for users who are also customers, employees, or contacts (the common real-world overlap)?
5. What is the upgrade story across Laravel majors — are there maintained branches, or is it "latest only"?
6. Is there an exit path — i.e., can the User model be detached from Concord without a rewrite?

Integration Approach

Stack fit Reasonable only for a Laravel application already built on (or explicitly choosing) Concorde, targeting a back-office/CRM-style domain with role- and permission-based access control. It is a mismatch for SPA/API-first architectures, for products using an external identity provider, and for teams that want minimal dependencies in the auth path.

Migration path

• Greenfield: adopt Concorde's app skeleton first, then layer person → user → acl in that order. Treat the package as one module among several, not as a library.
• Brownfield (existing Laravel app): expect a genuine data migration, not a swap. Standard users rows must be split into persons and users with a foreign key, password hashes carried over unmodified, and existing role/permission logic remapped onto konekt/acl. Plan for dual-write or a read-only freeze window during cutover.
• Brownfield (existing Concorde app): low friction; verify module registration and migration order, then adopt incrementally.

Compatibility Validate with a throwaway PoC before any planning commitment: composer require the full chain in a clean Laravel app at the target version, boot the modules, run migrations, and exercise login, logout, password reset, and a permission check. Any failure at this stage is a stop signal, not a workaround candidate.

Sequencing

1. Compatibility PoC (1–2 days) — confirm PHP/Laravel constraints resolve cleanly.
2. Architecture decision — confirm Concorde adoption is a deliberate platform choice, not an incidental one.
3. Module scaffold — Concorde skeleton, then person, then user, then acl.
4. Auth wiring — guard, provider, middleware, password broker.
5. Data model mapping — persons/users split, role mapping table.
6. Migration dry run in staging with production-shaped data.
7. Cutover with a rollback plan and a frozen auth path during the window.

Operational Impact

Maintenance Ongoing cost is dominated by reading source rather than reading docs. Budget for a named owner who understands the Concord module lifecycle and the Person/User/ACL layering. Dependency upgrades are coupled: bumping Laravel may force bumps across the whole Konekt chain simultaneously. Consider vendoring or forking early so that a maintainer going quiet is a fork decision rather than a re-platforming decision.

Support Expect GitHub issues as the only channel, with no SLA and variable latency. Internal runbooks and an architecture decision record are not optional here — they are the institutional memory for a package with a two-star community footprint. Escalation to a commercial vendor is unlikely to be available.

Scaling Horizontal scaling is unproblematic: the package is session/DB-backed Laravel auth, not a stateful service. The scaling concern is query shape: the Person↔User join and ACL permission lookups are easy places to introduce N+1 queries in list views and authorization checks. Permission caching (if present in konekt/acl) must be invalidated correctly on role changes; stale authorization is a security-relevant failure, not a performance one.

Failure modes to design for

• Module boot-order misconfiguration producing silent route/model resolution failures.
• Migration ordering conflicts when Concorde modules are added out of sequence.
• Password hash incompatibility if migrating from a non-bcrypt source.
• Auth provider misconfiguration that appears to work until password reset or remember-me is exercised.
• Stale ACL caches after role changes, granting or denying incorrectly.
• Abandonment: no release for the target Laravel major version, forcing either a fork or an unplanned migration.

Ramp-up Plan 1–2 weeks for a competent Laravel engineer to become productive, most of it spent on Concord's module conventions and the Person/User/ACL distinction rather than on the package itself. A team unfamiliar with modular monolith patterns should add buffer. Documentation should be treated as a supplement to source, not a substitute.

Bottom line for the TPM: this is a defensible choice only inside a deliberate Concorde platform bet on a CRM/back-office domain. Outside that context — 2 stars, 0 dependents, single-maintainer auth code — the risk-adjusted cost of adoption exceeds the cost of building equivalent functionality on first-party Laravel auth plus a maintained ACL package. Recommend a time-boxed PoC before any roadmap commitment, and treat "does not resolve at our target Laravel version" as a decisive no.