Cornerstone Laravel Package

Product Decisions This Supports

• Greenfield scaffolding & build-vs-buy for internal starter kits. This package is an opinionated Laravel application scaffold. It replaces hand-rolled "app template" repos with a maintained, versioned baseline — a direct build-vs-buy call for platform/DevEx teams.
• Database ID strategy (the big one). v0.5.0 mandates snowflake identifiers on the default User model and every generated application model. That's a first-class architectural decision, not a default. It enables shardable, mergeable, distributed-friendly primary keys (multi-region, multi-service, event-driven pipelines) where auto-increment integers break down. It also constrains API contracts: 64-bit IDs overflow JavaScript Number, so JSON serialization as strings is required.
• Standardization across teams. "Architecture coverage" + "Cornerstone support 0.3" implies enforced Pest architecture tests and static-analysis rules shipped with the template. That's a governance lever — every generated app inherits the same conventions, reducing drift and review overhead.
• Roadmap input for platform tooling. Whether to adopt, fork, or wrap this package feeds the platform team's roadmap: do we standardize on it for new services, or maintain our own scaffold?
• Migration/tech-debt decisions. The requirement is a breaking change for anyone on v0.4.x who customized generated models. PMs need to decide: retrofit existing apps, freeze v0.4.x for them, or fork.

When to Consider This Package

Adopt when:

• You're starting new Laravel applications and want opinionated, enforced defaults rather than a blank skeleton.
• You expect to scale horizontally — sharding, multi-region writes, service-to-service data merges, or event sourcing — where snowflake IDs earn their keep.
• You value enforced architecture (Pest architecture coverage) and want consistency across a multi-team org.
• You want a versioned scaffold you can consume, rather than maintaining your own template repo.

Look elsewhere when:

• You need to integrate with legacy databases using BIGINT AUTO_INCREMENT or external systems with their own ID contracts.
• Your client stack can't safely handle 64-bit integers (vanilla JS JSON.parse precision loss) and you're not prepared to serialize IDs as strings everywhere.
• Your team isn't ready to own snowflake generation infrastructure — worker/node ID assignment, clock-skew handling, and the operational discipline that implies.
• You rely on stock Laravel behavior and want minimum deviation from upstream (the mandatory-model-ID requirement will fight you during upgrades).
• You need portability of IDs across environments (fixtures, seeds, cross-env data sync) where deterministic IDs matter.

How to Pitch It (Stakeholders)

Executives: A maintained, opinionated Laravel starter kit that bakes in a scalable identifier strategy and enforced architecture conventions. It reduces per-project setup risk and standardizes new builds, at low cost to trial. Worth a bounded pilot on one new service before any org-wide commitment.

Engineering (and the honest caveats): v0.5.0 is a breaking release. It now requires snowflake identifiers on the default User model and all generated models, backed by architecture coverage and Cornerstone 0.3. Anyone on v0.4.x who customized models will need migration work — plan for that. Adoption also implies owning snowflake ID generation (worker IDs, clock handling) and serializing 64-bit IDs as strings to avoid JS precision bugs. Dependency bumps (Livewire, Pest, Pint, Vite, Mockery) are routine but should be regression-tested. Recommend a pilot on a single greenfield service, not retrofitting existing apps; evaluate the enforced architecture as a strength for consistency and a potential rigidity trade-off before broad rollout.