Core Laravel Package

Product Decisions This Supports

• Framework build-vs-buy for a lightweight service layer. Amethyst/core is a micro-framework kernel: application bootstrap, service container, service providers, config loading, and HTTP request handling glue. It gives the team a concrete reference point when deciding whether a new internal service needs full Laravel/Symfony or a slim kernel. The decision it informs is "what is the minimum framework surface we can own?" — not "should we adopt Amethyst?"
• Architecture pattern validation. The service-provider / kernel-bootstrapping model is the same shape as Laravel's providers and Symfony bundles. Reviewing it is cheap input for a platform team designing a plugin or module system for an internal toolkit.
• OSS intake policy calibration. With 1 star, 0 dependents, and a 0.035 score, this is a useful negative control in our dependency-approval rubric. It sharpens the thresholds we set for "approved," "evaluate only," and "reference only" tiers.
• Roadmap triage on microservice scaffolding. If the roadmap includes a "thin PHP service template" epic, this package is a compare-and-contrast artifact for the design spike, not a candidate dependency.
• Not a decision driver for: production runtime selection, security-sensitive services, or anything with a multi-year support horizon.

When to Consider This Package

Consider only as a reference or for legacy continuity:

• You are maintaining an existing Amethyst-based application and need to understand or patch its kernel/container contracts.
• You want a compact, readable example of a PHP micro-framework core for an architecture spike, internal training, or a design document comparing kernels.
• You need a very small DI + bootstrap surface and are prepared to fork and own it outright.

Look elsewhere when:

• The service is production-facing, customer-facing, or handles regulated data — there is no visible community, no security response process, and no downstream dependents to surface breakage.
• You need hiring leverage, documentation depth, or long-term support. Laravel, Symfony, Slim, and Laminas all dominate on every one of these axes.
• You need ecosystem integration (queues, auth, ORM, observability). Amethyst/core deliberately does not provide it; you would be assembling and maintaining that stack yourself.
• Your dependency policy requires active maintenance signals. Stars, dependents, and release cadence here are all below any reasonable adoption threshold.

Practical rule: treat this as reading material, not runtime code. Adoption cost is near zero in license terms (MIT) but the total cost of ownership is effectively "we forked it."

How to Pitch It (Stakeholders)

To executives: We evaluated Amethyst/core at essentially zero cost — MIT licensed, tiny footprint, no procurement or legal friction. The finding is that it is not an adoption candidate: it has negligible community traction and no downstream dependents, which means no safety net if we build on it. The recommendation is to spend a small, timeboxed amount of engineering effort using it as a design reference for our internal service scaffolding, and to standardize on a mainstream framework for anything we ship. Net ask: a few days of spike time, no new vendor relationship, no ongoing license or support commitment.

To engineering: The valuable artifact here is the pattern, not the package — kernel bootstrap plus a service-provider registry plus a PSR-11 container. It is a compact illustration of the same separation of concerns Laravel and Symfony formalize at much greater scale. Use it to pressure-test our own module boundaries, then discard it. Do not add it to composer.json for anything with a support obligation; if a team genuinely needs this shape, we should own a small internal kernel rather than depend on an unmaintained one. Flag any existing Amethyst usage in the estate so we can plan an exit.