Facile Laravel Package

Product Decisions This Supports

• A platform-ergonomics bet, not a product-capability bet. orchestra/facile is a lightweight form/extension layer inside the Orchestra Platform family: a fluent, chainable form builder with field definitions, labels, selects, submit buttons, old-input and validation-error wiring, Blade-friendly rendering, and extensible field types and macros. Its entire business case is fewer lines of glue code for engineers assembling form-heavy admin screens. It informs "should we invest in platform ergonomics?" — never "does this unlock something a customer will pay for?" Framed any other way, the case collapses.

• Build vs. buy vs. write-it-ourselves for internal scaffolding. Three honest options: (a) adopt if the team is already committed to Orchestra Foundation and wants a modest ergonomic win; (b) reimplement the handful of helpers and Blade partials in an application-owned support namespace — the preferred path, roughly an afternoon of work, zero dependency risk; (c) skip entirely on vanilla Laravel, where the package contributes a dependency edge plus global symbols in exchange for markup helpers the team can own outright.

• Roadmap sequencing: platform layer vs. product layer. Adopting it is an explicit claim that platform-layer work deserves roadmap capacity. If there is no room to absorb the maintenance risk — constraint pins, upgrade chasing, a named owner — defer. This package does not deserve its own initiative; at most it belongs as a scoped, time-boxed trial inside one internal project.

• The clearest use cases: internal back-office tooling, admin consoles, CRUD-heavy extension modules, and multi-tenant dashboards built on Orchestra Foundation — surfaces where repeated form markup is the dominant cost and where a boot-time failure does not touch revenue. The narrower and more repetitive the form surface (a dozen near-identical CRUD screens), the stronger the ergonomic argument; the broader the product surface, the weaker it gets.

• A vendor-risk register entry. Zero stars, zero dependents, a composite score of 0.3, and the only release note in evidence targeting Laravel 8 — a release line out of security support — is a near-perfect negative adoption signal. The real PM decision here is a risk-tolerance decision: accept ownership of a small, effectively frozen dependency in exchange for modest boilerplate savings, or decline and own the code.

• A template for how the team treats unmaintained dependencies. Whatever you decide becomes precedent. "We adopt and own, behind an adapter, with a named maintainer and a pre-approved fork-or-reimplement fallback" is a reusable governance stance worth far more than this one package.

When to Consider This Package

Adopt only when all of the following hold:

• You are already committed to Orchestra Platform and its extension, memory, and authorization conventions. Outside an Orchestra-bootstrapped app the package has no independent value — it assumes Orchestra's boot order, container bindings, and helper conventions.
• The value you need is ergonomic, not functional — you are removing repeated form markup and old-input/validation wiring, not gaining a capability Laravel does not already offer.
• A dependency-graph spike has passed. Confirm a satisfiable illuminate/* constraint set exists for your target Laravel version before spending design time (composer why-not orchestra/facile, --dry-run, composer show). With zero dependents there is no public evidence anyone has resolved this against a currently supported release. Time-box it to one day; if it forces a platform upgrade or downgrade, stop.
• The public API surface is small and auditable — enumerate it by reflection. If it is under roughly ten symbols, reimplementation is an afternoon and the dependency is indefensible.
• You will treat it as vendored internal code: exact pins across PHP minor, Laravel minor, and every orchestra/* component; a thin application-owned adapter at each call site; an ADR recording rationale and scope; and a named owner who carries it through the next Laravel major.
• It sits off the customer-facing and revenue-critical path, and its failure mode (a boot-time fatal from a renamed helper or contract drift) is caught by a boot smoke test and a rendered-markup snapshot test in CI.

Look elsewhere — or write the equivalent yourself — when:

• You are on vanilla Laravel. The value is contingent on Orchestra's conventions and does not transfer.
• You need community support, a security response process, or a release cadence. There is no upstream signal to rely on, and the family moves in lockstep — one component drags in the whole platform's maintenance posture.
• The forms are on a customer-facing or revenue-critical path, where an unmaintained dependency's silent failure (subtly changed escaping, old-input, or dotted-path handling) is an incident rather than an inconvenience.
• You are not prepared to own it. If nobody is named to chase the next Laravel upgrade, and there is no appetite for a fork into an internal namespace, the honest answer is to write the helpers yourself.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small convenience library that shortens the code our engineers write for internal admin forms. It saves real but modest time on one class of internal screens and adds no customer-facing capability. The catch is maturity: it has no visible users, no release activity beyond a Laravel 8 compatibility note, and no security process — so adopting it means we own it. My recommendation is not to adopt it as infrastructure. Instead, keep the decision reversible: either write the equivalent helpers ourselves as an owned internal utility (an afternoon of work, zero risk), or, if the team insists on the trial, run it behind our own wrapper on a single internal admin screen with a one-day install spike up front and a pre-approved fallback. Either way the cost of saying no is trivial and the cost of unmanaged adoption is not.

For engineering (the ask):

• Do the one-day spike first, before any design work. composer why-not orchestra/facile, a --dry-run require, and composer show to read the declared illuminate/* and php ranges. If resolution moves our platform version, the answer is no.
• Enumerate the API by reflection from the vendor tree — there is no meaningful documentation, so the source is the documentation. If the surface is under about ten symbols, we write it ourselves and close the ticket.
• If we proceed: wrap it in an App\Support\Forms adapter so the package name appears in exactly one directory; define form shapes in PHP classes and render in Blade; register macros and view overrides from a provider that boots after the package's; pin the whole orchestra/* family exactly; add a boot smoke test plus a rendered-markup snapshot; and explicitly test escaped values, nested field names (user[address][line1]), and our own error-bag configuration.
• Scope it to one internal CRUD screen first and diff the output byte-for-byte against our current Blade partials — old-input and validation-error display are the two behaviours most likely to diverge quietly.
• Record the decision in an ADR with the pins, the screens in scope, the named owner, and the pre-approved fork-or-reimplement fallback. That ADR is the actual deliverable — it sets the precedent for every unmaintained dependency we evaluate after this one.