Ecommerce Laravel Laravel Package

Technical Evaluation

Architecture fit

v1.0.3 resolves the central ambiguity of the prior assessment: this is a full Laravel application scaffold, not a distributable library. The release notes describe composer create-project as the intended install path, Filament panels (/app and admin), Fortify authentication, Socialstream social login, and a Shield-based permission set. No service provider or contract surface is implied anywhere.

The confirmed architecture is a multi-panel modular monolith with partial multi-tenancy:

• Two Filament panels with distinct authorization predicates: admin → super_admin role, app → team membership. Panel access is now a real gate rather than return true.
• Tenant isolation is team-scoped at the panel boundary but global at the role layer — config('permission.teams') is false, so roles are global despite code that reads as team-scoped. This is a meaningful architectural constraint: any requirement for per-tenant role definitions, per-store staff permissions, or tenant-admin delegation requires work, not configuration.
• Storefront and back office are separate surfaces sharing one user model; shoppers hold no team and no role, and team grants flow through TeamPolicy::create gated on create_store. That is a defensible design and a reasonable fit for a mid-market commerce build. It remains a poor fit for headless/composable or multi-service targets.

Integration feasibility

Feasibility improves materially, but a new class of friction replaces it.

• Confirmed provenance. The changelog resolves to liberu-ecommerce/ecommerce-laravel, so the canonical org question is substantially closed. The AGENTS.md reference to liberusoftware/ecommerce-laravel should still be treated as stale metadata, not a second canonical repo, until issue-tracker links are checked.
• Test surface is real. 1,245 passing tests with 7 added, described as verified end-to-end. That is a genuine signal and materially better than the prior "unknown coverage."
• Version resolution is broken by design. The release explicitly states the prior line was v13.0.0, tracking the Laravel major, and that Packagist still resolves it as highest — so composer create-project fetches v13.0.0 unless the caller pins 1.0.3. The v1 tag was moved. This is a supply-chain-adjacent trap: the default install path yields a different, older codebase than the one documented. Every automated install, CI template, and onboarding doc must pin 1.0.3 explicitly.
• Documentation maturity remains low. Still no install guide, API reference, upgrade guide, or security policy in evidence. The release notes are the most substantive documentation produced so far, and they are release notes.
• Adoption unchanged. 0 dependents; no third party has validated the integration path.

Technical risk — HIGH (recharacterized)

The risk profile has shifted from unknown scope to known but unresolved security and authorization debt. That is easier to price and harder to dismiss.

• A tagged release shipped an authorization bypass. canAccessPanel ended in return true; // TODO: Check panel and role, admitting a user with zero roles and zero teams into Products, Orders, Invoices, and Customers. It was masked only because registration threw first. The maintainers state this plainly: fixing registration alone would have opened the door. This is the single most important data point in the update — it demonstrates that a green CI run and a passing release did not imply a safe authorization posture.
• Tests were green while production registration failed. FortifyActionsTest::makeTeam() created the team and the staff role, fabricating the exact precondition that real signup could not produce. The test was removed. Coverage breadth is therefore not evidence of behavioural fidelity; test realism must be assessed separately.
• Known authorization gap remains open. ArticleResource and CollectionResource have no policy and strictAuthorization is off, so a team member can CRUD their own tenant's articles and collections — including price — without a permission check. Reachability now requires a team, which is a mitigation, not a fix. Closing it requires policies and seeded permissions together, because the Shield set has no article_*/collection_* entries at all.
• Latent stored XSS. Product upload accepts image/svg+xml to a public disk. Unreachable today only because public/storage is not linked; it becomes live the moment storage:link runs. This is a one-command distance from exploitable and must be treated as a pre-launch blocker.
• Weak credential policy. Password::default() is min 8 with no complexity and no breach check.
• Inherited dead code from an unrelated domain. RoleBasedRedirect comes from a property-management application and its six targets all 404. This is provenance evidence: the codebase contains copy-paste inheritance from sibling projects, which raises the prior on finding more.
• Seed data is misleading. inventory_count = 0 on every product means the demo storefront ships sold out — a poor evaluation artifact and a potential trap for anyone using seeders as a reference implementation.
• Release hygiene improved but versioning is now actively confusing. Semver was reset from v13 to v1 and a tag was moved. Both are defensible individually; together they mean tag-to-commit mapping cannot be trusted without checking.

Key questions — status

1. Application template or installable package? Answered: application scaffold, composer create-project. Confirm composer.json type and whether any require-able path exists.
2. Domain coverage vs. scaffolding? Partially answered. Products, Orders, Invoices, Customers, Teams, storefront (/orders, /wishlist, /invoices, /payment_methods), checkout with intended() redirect, social login. Still unresolved: payments, tax, inventory movements, fulfillment, refunds.
3. Open — which Laravel and PHP versions does the v1 line support, and why did the versioning scheme decouple from the Laravel major? The reset implies the Laravel-tracking scheme was abandoned; confirm the supported matrix before committing.
4. Open — is v13.0.0 still installable and still broken? If Packagist serves it by default, that is an active hazard to anyone following the README. Determine whether it should be abandoned/unlisted.
5. Open — what is the commit cadence and bus factor? v1.0.2 → v1.0.3 indicates active patching, but contributor concentration is unknown.
6. Open — is there a security disclosure channel? No SECURITY.md surfaced; the SVG XSS and missing policies were disclosed in release notes, which is transparency but not a process.
7. Open — do CONTEXT.md and docs/adr/ contain real content? Still unanswered and still load-bearing for ramp-up cost.
8. New — what is the policy for shipping known-unfixed issues in tagged releases? v1.0.3 ships with an open authorization gap and a latent XSS. Acceptable for a self-hosted OSS project; not acceptable as an inherited baseline without our own remediation plan.

Integration Approach

Stack fit

Fits a Laravel monolith with Filament (admin and app panels), Fortify, Socialstream, and Filament Shield, on PHP 8.x. The presence of panel-specific authorization predicates means the target must actually want a panel-based back office; a headless or API-only target would inherit substantial unused surface. Confirm the Laravel major supported by the v1 line — the abandonment of the Laravel-tracking version scheme is a hint that the framework floor moved and the mapping was no longer useful.

Migration path

Unchanged in shape — greenfield accelerator, not a dependency — but the first step now has a hard prerequisite:

1. Pin the install. composer create-project liberu-ecommerce/ecommerce-laravel:1.0.3 explicitly. Never rely on default resolution. Record the resolved commit SHA alongside the tag.
2. Spike: run the 1,245-test suite, then write the failing tests the suite is missing — specifically a real end-to-end registration that asserts no team and no role, and a panel-access matrix for shopper / team member / super_admin / unauthenticated. Time-box to three engineer-days, up from two, because authz verification is now mandatory scope.
3. Pre-launch security remediation, before any feature work: add policies for ArticleResource/CollectionResource plus the missing article_*/collection_* Shield permissions; block or sanitize image/svg+xml uploads and make storage:link conditional on that fix; tighten Password::default(); delete RoleBasedRedirect.
4. Decision gate: adopt-as-baseline vs. cherry-pick modules vs. reject — now informed by actual domain and authz evidence rather than inference.
5. If adopted, fork under a pinned commit SHA with the remediation commits on top, and keep them as a named patch set so upstream sync stays tractable.

There is still no "migrate off" path because nothing is yet integrated. The real cost remains divergence, and it is now larger: our fork will carry security fixes upstream may never take.

Compatibility

• The versioning reset is the primary compatibility hazard. Anything that resolves "latest" gets v13.0.0; anything that resolves "v1" gets whatever the moved tag points at. Pin exact versions and commit the lockfile; pin by commit SHA in the fork.
• Add an SBOM step and a dependency audit to CI. The abandoned-Laravel-major-tracking line suggests dependency currency should not be assumed.
• Multi-tenancy: roles are global (permission.teams = false) while team membership gates the app panel. If requirements include tenant-scoped roles, budget re-architecture, not configuration.
• Socialstream is wired through a commented-out HasConnectedAccounts trait on User; /user/profile breaks when social login is enabled. Treat social login as not production-ready in this release.

Sequencing

1. Pinned spike install at v1.0.3 plus authz test authoring (week 1).
2. Security remediation pass — policies, permissions, upload hardening, password policy, dead-code removal (week 1–2). This precedes the go/no-go because it is now cost-to-adopt, not optional polish.
3. Dependency, license, and SBOM audit (week 2).
4. Go/no-go with explicit build-vs-adopt comparison, priced against the remediation work already scoped.
5. If go: fork at SHA, add CI (lint, static analysis, tests with realistic fixtures), document the divergence policy and the patch set.
6. Adopt domain modules incrementally behind feature flags; do not replace an existing application wholesale.
7. Establish an upstream-sync review gate. Agent-authored commits arrive without context, and the v1.0.3 root cause was exactly the kind of single-line shortcut a context-free review waves through.

Operational Impact

Maintenance

Ownership transfers to us on fork, unchanged. Upstream is demonstrably active (v1.0.2 → v1.0.3, targeted fixes, honest disclosure of known issues) — a better signal than the prior assessment could offer. But we inherit the authz model, the permission set, and the panel predicates, and we become responsible for the open items upstream has flagged but not fixed. Expect to own framework upgrades, dependency patching, and policy work.

Support

Community-only via GitHub Issues; canonical org now effectively resolved to liberu-ecommerce. Still no vendor, no SLA, no commercial backing. The release notes are unusually candid, which is operationally valuable — but candor is not a support contract. Budget a named internal maintainer with allocated capacity, and assign explicit ownership of the open known-issues list.

Scaling

Inherited from Laravel and our infrastructure, with two package-specific caveats:

• Global roles constrain tenant scale. Onboarding many tenants with differentiated staff permissions will stress a model where roles do not partition per team. Validate against the org model before committing to load or customer-count projections.
• Filament panels are not free. Admin and app panels carry their own query and authorization cost; large tenant lists and per-request policy evaluation are worth profiling early.
• No published guidance on caching, queue topology, or search. Those decisions remain ours.

Failure modes

• Installing the wrong version — highest-probability failure today. Default Packagist resolution yields v13.0.0, which predates the registration and panel fixes. Mitigate with explicit pins in every template and doc.
• Authorization regression in a tagged release — demonstrated, not hypothetical. Mitigate with our own authz test matrix (shopper / team member / super_admin / unauthenticated) running on every commit, including upstream syncs.
• Latent XSS becoming live — triggered by a routine storage:link. Mitigate by remediating before linking, and by adding upload-type tests.
• Abandonment — still plausible at 0 dependents; mitigated by forking early at a SHA.
• Tag mutation or deletion — demonstrated in this very release (the v1 tag moved). Pin by commit SHA, never by tag.
• Silent divergence — our security patch set drifts from upstream, or upstream ships a conflicting fix. Mitigate with a scheduled quarterly diff review and a documented patch-set inventory.
• Inherited-defect discovery — RoleBasedRedirect proves copy-paste from sibling projects. Budget for finding more dead or wrong-domain code during onboarding.
• Scope surprise — reduced but not eliminated: payments, tax, inventory, and fulfillment remain unverified, and the seeded inventory_count = 0 suggests inventory handling is not exercised end-to-end.

Ramp-up

Laravel-fluent engineers remain productive within days on the framework layer. Domain comprehension cost is now better characterized and slightly higher: the codebase mixes storefront, admin, multi-panel authz, Shield permissions, Socialstream, and inherited foreign-domain code. Onboarding should include the authz model first (panel predicates, TeamPolicy, global-role caveat), then the ADR set, then a written divergence and patch-set policy before any engineer commits. If CONTEXT.md and docs/adr/ are substantive this drops to days; if placeholders, budget one to two weeks of reverse-engineering per engineer. The v1.0.3 postmortem is the best onboarding document currently available and should be required reading — it explains the authorization design better than any other artifact.