Studio Laravel Package

Technical Evaluation

Architecture fit. orchestra/studio is a development-time code generator, not a runtime dependency. It emits Orchestra Platform extension scaffolding — composer manifest, service provider, routes, language files, orchestra.json, migrations, models, resource controllers, and admin views. Architecturally this means it has zero production footprint and total coupling to Orchestra Platform's extension manager and ACL. On a plain Laravel app the output references providers and menus that do not exist, producing a blank admin surface — the single most reported failure mode. Fit is therefore binary: if Orchestra is already the admin layer, Studio compresses module cold-start cost; if it is not, there is no surface area to leverage.

Integration feasibility. Low-to-moderate, gated on one precondition: Orchestra Platform installed and /admin reachable. The install path is trivial (composer require --dev orchestra/studio:3.2.3, publish config and stubs, inspect php artisan list | grep -i studio), but the validation path is not. The changelog for this very release — "Use Laravel standard on opening tag/namespace" — is a direct signal that earlier stubs emitted non-standard casing, which on case-sensitive filesystems (Linux CI, Docker) becomes an autoload failure that never reproduces on a developer Mac. Feasibility must be proven on the target version matrix, not asserted.

Technical risk. Concentrated and unambiguous:

• Abandonment risk (high). Zero stars, zero dependents, near-zero package score, no advisories, no upstream obligation to fix anything. There is no community backstop, no third-party answers, no bus-factor relief.
• Version-coupling risk (high). Studio sits on Orchestra Platform, which sits on Laravel. A single incompatible transitive constraint blocks the toolchain with a confusing Composer resolution error.
• Non-idempotent regeneration (medium). The generator overwrites. Any run over an edited module destroys work, so regeneration cannot be a routine operation — only a scratch-branch diffing tool.
• Secure-defaults risk (medium). Generated controllers frequently ship $guarded = [], omit authorization wiring despite Orchestra's ACL hooks, and pass unvalidated input to create(). Everything emitted must be reviewed as if written by a contractor, because it was — the stub author.
• Convention lock-in (medium). Generated code encodes naming, layout, namespace casing, and registration patterns. This is an asset under a uniformity strategy and a liability under a bespoke-architecture strategy.

Key questions.

1. Is Orchestra Platform already installed, /admin reachable, and owned — or is this a parallel evaluation that duplicates effort?
2. Who is the named internal owner of the stubs, version pins, and upgrade regression suite?
3. What is the measured baseline for "time to first working admin module" today, so the generator's lift is quantified rather than assumed?
4. Does the roadmap contain a plugin/partner-extension ecosystem commitment that makes generated conventions a de facto SDK?
5. What is the documented fallback (php artisan make:* plus stub overlays) and has it been exercised?

Integration Approach

Stack fit. Requires Orchestra Platform on a supported Laravel line, PHP with Composer 2, and a team fluent in Orchestra's extension manager and ACL. Install strictly in require-dev, pinned exactly at 3.2.3. Never a production dependency; nothing it emits should be treated as a runtime capability. Where the stack is mainstream Laravel without Orchestra, the correct comparison set is Filament, Nova, Laravel Blueprint, or plain artisan make:* plus stub overlays — all with active maintenance and hiring pools.

Migration path. There is no migration in the data sense; the migration is process. Move the team from ad-hoc scaffolding to a single documented path:

• config/studio.php published once and committed, so config drift shows up in review.
• A resources/studio/stubs overlay directory, version-controlled and greppable, overriding only the templates that matter: strict types, house base controller, FormRequest stub instead of inline validation, standard namespace casing.
• A wrapper script (scripts/scaffold.sh) so engineers invoke one documented command — generate, composer dump-autoload, migrate --pretend — rather than memorizing flags.

Stub overlays are the migration's core lever: fixing the template compounds across every future module; fixing the output does not.

Compatibility. Maintain a written three-way compatibility matrix — Studio, Orchestra Platform, Laravel — with all three pinned. Before any Laravel upgrade, run a generator regression: generate the reference throwaway extension on a branch from a clean checkout, diff against known-good output, run its tests. This is also the mechanism for detecting stub drift without touching real code. Grep for mixed app\ / App\ casing before blaming Composer for a Class not found.

Sequencing.

1. Confirm Orchestra is installed and /admin renders. If not, stop.
2. Publish config and stubs; read every stub before running a generator — the templates are the contract.
3. Prove the round-trip with one obviously disposable extension: generate → composer dump-autoload → activate via the extension manager → confirm the menu entry renders at /admin. This isolates the classic failure (files on disk, extension never activated) before any real feature depends on it.
4. Layer in stub overlays for the three-to-five recurring corrections.
5. Then, and only then, generate in dependency order — extension, migration (run and verify schema), model, resource controller, views — reviewing at each step, because a broken step 1 silently poisons steps 2–5.
6. Harden immediately on the same branch: authorization/policy plus a test asserting it, FormRequest extraction, explicit $fillable replacing $guarded = [], and a smoke test per resource with a factory.
7. Land with an explicit "generator output, unedited" commit marker so six months later git log --grep answers provenance questions.

Operational Impact

Maintenance. Upkeep falls entirely in-house. That means owning stub overlays, the compatibility matrix, the wrapper script, and the regeneration policy. Budget a recurring slice — not a one-off setup — plus a quarterly scope check: if engineers are hand-rewriting more than half of what the generator emits, it has stopped paying rent and the decision flips to forking the stubs or replacing it with artisan make:* plus overlays.

Support. No upstream support contract, no advisories, no community answers, no dependents to consult. Treat it as vendored internal tooling with a named owner, not a vetted third-party dependency. That framing is what makes the support gap a managed risk rather than an unmanaged one — and it is the single most important thing to communicate to stakeholders, because the tool's apparent maturity (a versioned release, a documented changelog) reads as far more institutional than it is.

Scaling. Scales with module count, not with traffic — it is a development-time tool and has no runtime scaling surface. Benefits compound as the number of similarly-shaped CRUD/admin modules grows and as stub overlays mature. They degrade as the codebase drifts toward bespoke or plain-Laravel controllers. Team scaling benefits are real but conditional: onboarding improves only where Orchestra familiarity already exists, since engineers must otherwise learn the platform and the generator simultaneously.

Failure modes. Each has a known signature and a known response, which should be documented before the first incident:

Ramp-up. Fast for an Orchestra-fluent team — the first disposable round-trip is an afternoon, and the value shows up by module two or three. Slow and misallocated for a team new to Orchestra, where the generator's productivity gain is consumed by learning the platform underneath it. Practical ramps: read the stubs before generating; run with -v and read the emitted file list to learn conventions; inspect the stub rather than patching the output when something looks wrong; git stash before speculative runs.

Recommendation. Run a time-boxed pilot on an internal-only surface with agreed success metrics — time-to-first-working-module, percentage of generated code surviving review unedited, and stub-overlay churn per module. Position it to executives as developer-productivity tooling with optionality on a future plugin ecosystem, never as a product feature. Keep a documented, exercised fallback path, and make fork-and-own or replace an explicit exit criterion written down at pilot kickoff rather than discovered at a Laravel upgrade.