Skeleton App Laravel Package

Product Decisions This Supports

• Build vs. buy for application scaffolding: This package represents the "buy a pre-built app" option for a PHP service — config loading, DI wiring, routing, and module bootstrapping already assembled around a framework. Evaluating it clarifies what a starter skeleton must supply versus what our own Laravel starter (Breeze, Jetstream, or an internal template) should own. The short answer after review: build on first-party Laravel starters, not this. The 2.1.2 housekeeping release does not change that answer.
• Architecture reference for framework-agnostic services: PPI is an interop-oriented framework, so the skeleton is a useful historical sample of decoupling application bootstrap from a specific framework runtime. If a roadmap item involves a PHP service that must survive framework churn, this is a read-only reference for how a modular skeleton was structured circa 2014–2016. 2.1.2's removal of a stale PSR-7 reference is a marginal freshening of that sample, not a modernization.
• Legacy retirement / migration scoping: If any asset in the portfolio is actually running on PPI, this package is the baseline for understanding its conventions and estimating migration cost to Laravel or Symfony. That is a real product decision (migrate vs. maintain vs. sunset), and it is the only decision here with budget attached. The 2.1.2 "skeleton module fix" is the kind of patch that suggests someone still runs this code path somewhere — worth a line item in the dependency spike, not a strategy change.
• Use cases where it is relevant at all: technical due diligence on PHP interop frameworks, archaeology of pre-PSR-7 bootstrapping patterns, and reference material for a "batteries-included skeleton" internal design review.
• Where it should not enter the roadmap: it is not a dependency, not a feature enabler, and not a candidate for a proof of concept. No feature workstream should block on it. Treat it as documentation, not infrastructure. A single patch release after a long dormancy is not a maintenance commitment and should not be read as one on a roadmap.

When to Consider This Package

Consider it only under these conditions:

• You already own or must maintain a PPI Framework application, and you need to understand its skeleton conventions — service registration, config layout, module loading — before touching or migrating it.
• You need a read-only reference implementation of a framework-agnostic PHP application skeleton for an architecture or design review. Clone it, read it, do not require it.
• You are doing comparative due diligence on PHP application skeletons and want the interop-framework data point alongside Laravel, Symfony, and Slim.

Look elsewhere — decisively — when:

• The work is greenfield Laravel. Use Laravel's own first-party starter kits; they track the framework, receive security fixes, and support current PHP.
• You need active maintenance, security patching, or an LTS commitment. There is a 2.1.2 patch (a skeleton module fix, a PSR-7 reference removal, and dropping a committed composer.lock), but it lands after a roughly nine-year gap with no visible security response process, no compatibility work for current PHP, and no PSR-7/PSR-15-era modernization. One housekeeping release is an anecdote, not a support commitment.
• You need ecosystem validation. Zero dependents and 53 stars mean no downstream pressure to keep it working. Any breakage is yours alone to fix.
• You need a bus-factor defense. This remains effectively a single-maintainer artifact. Do not put it in a production composer.json.
• You need breaking-change or deprecation signals to plan around. 2.1.2 is cosmetic/hygiene — no API changes — so it provides no forward-looking information about where the package is going, because there is no discernible direction.

The low opportunity score (1.14) is consistent with this read: the package offers little leverage and no compounding ecosystem value, and 2.1.2 does not move that number in any material way.

How to Pitch It (Stakeholders)

For executives (30 seconds): PPI Skeleton App is a pre-built demo application around the PPI Framework. It just shipped a small 2.1.2 housekeeping patch, but that follows a roughly nine-year dormancy, and it still has zero dependents and no support process. It is not a strategic dependency and should not be adopted for any new product work. Its only value is as reference material if we discover a legacy PPI system in the portfolio. Recommendation: archive/reference only, zero roadmap impact.

For engineering leads: Do not add this to composer.json. Read it for patterns only — specifically how the skeleton wires config, DI, and routing without hard-coupling to the framework. The 2.1.2 patch fixes the skeleton module and drops a stale PSR-7 reference plus the committed composer.lock; note the lockfile removal as the correct hygiene call, and nothing more. If we own a PPI-based service, this package is our baseline for scoping an exit to Laravel or Symfony, and that migration should be sized and scheduled rather than deferred. For new PHP services, standardize on Laravel's first-party starter kits.

Risk summary to state plainly: effectively unmaintained for ~9 years despite one recent patch; no security response; PHP version drift; single-maintainer bus factor; superseded by modern PSR standards. These remain disqualifying for production and acceptable only for read-only reference. The cost of adoption is not the package — it is the ownership we would inherit.

Ask: approve treating ppi/skeleton-app as archived reference material, and approve a small spike to confirm whether any current system depends on PPI — the 2.1.2 skeleton-module fix makes it slightly more plausible that a live consumer exists. If the spike finds nothing, close the topic permanently.