Canvas Core Laravel Package

Product Decisions This Supports

• Build vs. buy for internal scaffolding. This package is the engine, not the feature. Choosing it means buying the plumbing (preset resolution, blueprint-driven file generation, source parsing to avoid collisions, post-generation hooks) and building only what is proprietary: our stubs, our presets, and the handful of generators that encode house conventions. The decision it resolves is not "should we scaffold?" but "do we write a generator framework or just the generators?"
• Feature-level: shrinking module setup cost. Every new module, package, or bounded context currently starts with copy-rename-delete cycles. This converts that into a single Artisan command with deterministic output. The PM-level metric is share of new modules created via the generator, plus measured delta in setup time against a captured baseline — a number to report, not a vibe to assert.
• Roadmap sequencing. Best scoped as a two-sprint pilot inside an existing developer-experience or platform initiative, with a pre-approved kill criterion. It is too narrow to headline a roadmap and too structural to be a background chore.
• Platform consistency and review throughput. Generated code inherits Laravel idioms rather than a parallel dialect, because the package tracks Illuminate\Console\GeneratorCommand, MigrationGeneratorCommand, PromptsForMissingInput, join_paths(), and PHP Attributes. Downstream effect is cheaper code review and faster onboarding — the arguments that actually move an engineering org.
• Risk triage, cheaply. Dev/CLI-only, MIT-licensed, no runtime footprint, no request path, no data. Approvals should be fast because the blast radius is bounded. That low severity is also the honest reason not to fund it as a flagship: opportunity score 55.25 against a 9.3 capability score says the engine is solid, the addressable upside is narrow.
• Explicit non-decision: no migration of existing code. Generation is additive. Retrofitting generators onto the existing codebase is a larger effort and should be declared out of scope in the approval doc before the first generator works and someone asks for it.

When to Consider This Package

Adopt when most of these hold:

• You repeatedly scaffold the same shape of module and can point to a concrete setup-time baseline for at least one representative module type.
• You have an engineer with Laravel console fluency who can own the preset, stubs, wrapper, and docs by name — not a team in aggregate.
• You will commit to a fixture-app generation job in CI on every Laravel major, so drift surfaces as a build failure rather than a review comment.
• You are willing to keep a single thin wrapper package as the only consumer of the core's API surface, so a Laravel bump is one file to change.
• Your Laravel major maps cleanly to a release line: v9.x ↔ Laravel 11, v10.x ↔ Laravel 12, v11.x ↔ Laravel 13.

Look elsewhere, or wait, when:

• orchestra/canvas already covers the need. Evaluate the sibling package first; if the ready-made commands fit, adopting the core is premature.
• You want a productivity win on install. The payout here is a build commitment, not a download.
• Adoption would be undocumented and unowned. README-only docs mean engineers read source; without an internal how-to as a named pilot deliverable, this becomes a one-person dependency.
• Your team cannot debug GeneratorCommand internals without upstream guides, and no ramp plan is funded.
• The generator would become the only path to creating a module. Keep hand-writing as a documented escape hatch; a single-broken-command bottleneck is worse than the copy-rename status quo.
• You are not prepared to read code, not changelogs, at upgrade time. The API tracks Laravel internals, possibleModelsUsingCanvas() was soft-deprecated toward possibleModels(), and the release notes are internally inconsistent about that direction. Pin versions; constrain the transitive orchestra/sidekick too.

How to Pitch It (Stakeholders)

For executives — one paragraph. We can stop hand-assembling every new Laravel module. This is the generation engine behind Orchestra Canvas: MIT-licensed, installed as a dev dependency only, with zero production footprint — no customer traffic, no data path, no runtime risk. The ask is one engineer, two sprints, to prove it on a single module type against a measured baseline. If we cannot show a credible drop in module setup time or review cycles by the end of Sprint 2, we stop and keep the standard commands — that outcome is pre-agreed as a success of the process. If it works, we get consistent, reviewable scaffolding across teams with adoption measured, not mandated.

For engineering — the short version. We adopt the engine, and we own the opinions. Presets define where models, factories, and seeders live; stubs define our conventions; a thin wrapper is the only thing that touches the core's API, so Laravel majors become a one-file change plus a fixture-app CI run. Everything is additive — no migration of existing code in v1. Success in Sprint 1 is deliberately social: one module generated and merged by someone who did not write the generator.

The three asks to attach to the pitch. (1) Name the owner of the stub library and internal preset. (2) Fund the internal how-to as a pilot deliverable, not an afterthought — the docs are README-only and the only real support model is our own fluency. (3) Commit to the CI generation test and the upgrade runbook, or don't adopt. Without those three, this is a demo that decays into an unowned build step nobody trusts.