Core Laravel Package

Product Decisions This Supports

• Build vs. buy for shared platform plumbing. Core is effectively a pre-built "internal platform" layer: unified configuration, a base service provider, a shared logging/audit channel, a facade base class, a constants/enums registry, a base exception hierarchy, and a Testbench-based testing kit. If your roadmap contains a suite of first-party Laravel packages (or you maintain several internal modules with drifting config conventions), this is a credible shortcut versus writing and maintaining that scaffolding yourself.
• Ecosystem commitment / standardization decision. The real product decision this package forces is whether to standardize on ArtisanPack UI at all. Core is the hub: it only pays off alongside siblings (cms-framework, visual-editor, ui-components, accessibility). Adopting Core is a platform bet, not a feature bet — treat it as an architecture decision record, not a sprint ticket.
• Roadmap sizing for platform work. The 1.2.0 command set — artisanpack:diagnose (--json, --fix), artisanpack:check-compatibility (--strict), artisanpack:check-updates (--security-only, --changelog), artisanpack:make-package — maps directly to reduced support and onboarding cost. Estimate savings in engineer-hours of environment triage, dependency drift, and new-package bootstrapping before committing to build equivalents.
• Compliance and auditability requirements. ArtisanPackLogger with audit(), the AuditLogCreated event, a configurable logging channel, and artisanpack.core.logging.audit.enabled give you a hook for "who changed what, when." Useful if a roadmap item is SOC 2 / audit trail / admin action history — but only if your own packages emit through it; it is not a turnkey compliance product.
• Developer onboarding and time-to-first-PR. ArtisanPackServiceProvider collapses a sibling provider to a few properties plus one registerPackageBindings() hook; ArtisanPackTestCase plus ArtisanPackAssertions (assertPackageInstalled, assertConfigEquals, assertCommandExists, assertFacadeWorks) means new contributors get ecosystem-aware tests on day one. Directly supports a "reduce ramp-up time" OKR.
• Configuration governance / operability. Unifying every package into one config/artisanpack.php, with --force semantics and preservation of existing customizations, is a deploy-safety and ops-story feature: one file to review in a PR, one file to diff across environments, one file to hand to support.
• Upgrade-path planning. Version history is instructive for a roadmap: 1.1 dropped Laravel 10 and relocated the a11y* helpers into artisanpack-ui/accessibility; 1.2 widened to Laravel 13 with no removed public API and opt-in migration. Budget a migration spike for any pre-1.1 code, and note PHP 8.3 is required for Laravel 13.

When to Consider This Package

Strong fit when:

• You are adopting (or already use) two or more ArtisanPack UI packages and are feeling configuration sprawl; the unified artisanpack.php plus artisanpack:scaffold-config is the whole point.
• You maintain your own suite of Laravel packages and would otherwise hand-roll a base service provider, config manager, logging convention, exception base, and Testbench harness. Even outside the ecosystem, 1.2.0's internals are a reasonable reference implementation — though forking or copying patterns may be saner than depending on it.
• You are on Laravel 11, 12, or 13 with PHP 8.2+ (8.3+ for L13) and want the ops command set — diagnose, check-compatibility, check-updates — as a substitute for bespoke CI health checks.
• You need a structured, package-prefixed audit log and are willing to route your own logging through ArtisanPackLog.
• Your team values MIT-licensed, no-vendor-lock tooling and can absorb reading the source.

Look elsewhere / defer when:

• You need only one feature. Core delivers almost no user-facing value in isolation; if you are not using siblings, this is dependency weight with near-zero return.
• Maturity risk is disqualifying. 1 star and 0 dependents means the surrounding ecosystem is essentially unproven in the wild. For a revenue-critical system, demand a spike, an exit plan, and an internal fork/wrap strategy before adopting. Single-maintainer bus factor is a real, unmitigated risk.
• You are on Laravel 10 or PHP < 8.2. Blocked, and 1.1's Laravel 10 drop signals a willingness to make breaking platform moves on minor versions.
• You need a vendor SLA, security disclosure process, or long-term support commitment. MIT and one maintainer is not that.
• You already have a mature internal platform layer (config aggregation, shared logging, package scaffolding). Migration cost exceeds the benefit; the 1.2 features are opt-in and additive, so partial adoption is possible but awkward.
• You require production-hardened audit logging. audit() emits an event and a log line; retention, immutability, and tamper-evidence are yours to build.

How to Pitch It (Stakeholders)

For executives (one paragraph): ArtisanPack UI Core is a small MIT-licensed foundation package that lets a family of Laravel packages share one configuration file, one logging and audit channel, and one set of developer tools. The business case is efficiency and consistency, not new customer-facing capability: it reduces the engineering cost of maintaining multiple in-house packages and gives us built-in diagnostics, compatibility and update checking, and package scaffolding. The risk is maturity — the project has negligible public adoption and a single maintainer — so we recommend a time-boxed spike inside a low-risk service rather than a platform-wide commitment, with a documented exit path since the license permits forking.

For engineering (the pitch): Adopt Core 1.2 as the substrate for our package suite. It gives us, for free: ArtisanPackServiceProvider (config merge, command/view/route registration, singletons — declared via properties), ConfigurationManager with schema-based validation (type/required/in) behind artisanpack_config(), a [package]-prefixed logger with audit events, BladeDirectiveRegistrar that validates directive names at registration instead of at render, a typed exception hierarchy, and ArtisanPackTestCase + assertions so new packages get tests immediately. Operationally, artisanpack:diagnose --json --fix, check-compatibility --strict, and check-updates --security-only slot straight into CI. Constraint check: Laravel 11–13, PHP 8.2+ (8.3 for L13); 1.2 removes no public API, so it is a safe increment from 1.1. Mitigation: pin the version, wrap Core/ArtisanPackConfig behind our own interfaces, and keep the audit sink in our code so a swap is a week, not a quarter.

Ask: one sprint of evaluation on a non-critical service, with success measured by (a) config sprawl reduced to a single artisanpack.php, (b) artisanpack:diagnose wired into CI, and (c) at least one internal package scaffolded via make-package.