Core Laravel Package

Product Decisions This Supports

• Roadmap gating for "configurable logic" features. If the roadmap contains anything that smells like user-defined rules, pricing formulas, eligibility checks, or text/DSL parsing, someone will eventually surface the Hoa family — Hoa\Ruler (business rules) and Hoa\Compiler (grammar/parser generation) both sit on Hoa\Core. This package's assessment is really the gate on that whole branch: it converts a vague "we could add a rules engine" idea into a scoped build-vs-buy decision.
• Build vs. buy vs. "buy the maintained one." The decision this supports is not "adopt hoa/core" — it's "reject the Hoa stack as an implementation base and fund an alternatives spike." Laravel already covers the adjacent ground: Storage/Flysystem for the hoa:// protocol-resolver use case, validation and typed properties for the consistency/type-checking helpers, native or maintained packages for parsing.
• Dependency-policy precedent. Archiving a "no" with rationale is itself a product artifact. A 2015-archived library with 35 stars and zero dependents is a clean, low-controversy example to point at when writing the rule: no new dependency without a named maintainer and a release in the last 24 months. Our scoring pass graded it 0.37 overall.
• Tech-debt triage if it's already in the tree. Zero dependents on the registry doesn't mean zero in our lockfile — legacy services that pulled in Hoa packages transitively need a replacement plan, and that's a roadmap line item with a real cost attached.
• Explicitly not a feature decision. There is no Laravel integration to evaluate: no service provider, no auto-discovery, no publishable config, no facade. It ships a custom autoloader, global constants, and a hoa:// stream wrapper registered as a bootstrap side effect. That last point alone makes it a non-starter for any app running under Octane or any long-running worker, where global stream-wrapper registration is shared state across requests.

When to Consider This Package

Adopt only under narrow, defensive conditions:

• You are maintaining a legacy PHP 5.x/7.0 application that already vendors Hoa packages and cannot be migrated this quarter; you pin the existing version and add it to the risk register with an owner and a removal date.
• You need it as a read-only reference implementation — the stream-wrapper/protocol abstraction and grammar-driven parsing patterns are legitimately instructive for an engineer designing an internal DSL layer. Read the source; don't install it.
• A vendor or acquired codebase hands it to you and you need to assess blast radius before deciding.

Look elsewhere when any of the following is true — which, for new work, is essentially always:

• You need PHP 8.1+ support, typed signatures, or a clean static-analysis baseline. A 2015 codebase will not survive modern CI without patching you now own.
• Security or compliance review is in scope. Archived means no patches, no CVE response, no maintainer to notify. That is an unconditional fail for most SOC 2 or customer-security-questionnaire processes.
• The underlying requirement is actually rules evaluation, parsing, or filesystem abstraction — use maintained alternatives or Laravel's own primitives.
• You want framework integration of any kind. Nothing here is Laravel-aware, and retrofitting a service provider around a global bootstrap is more work than the feature it enables.

How to Pitch It (Stakeholders)

To executives: This is a 2015-archived PHP core library with no maintainers, no dependents, and no security response path. It is not a candidate for adoption — it is a candidate for a documented "no." If engineering has proposed it, it almost certainly arrived attached to a rules-engine or parser idea, and the right move is to fund a short evaluation of maintained alternatives rather than accept the dependency. The cost of ownership is open-ended: we would inherit patching responsibility for code nobody is paid to fix, and the replacement cost later is higher than the cost of choosing correctly now.

To engineering: The composite score is 0.37 and the opportunity signal is not a reason to adopt — it reflects that the category (rules, parsing, resource abstraction) is valuable, not that this package is. There is no service provider, no config, no facade; it bootstraps a custom autoloader and registers a global hoa:// stream wrapper, which is directly hostile to Octane and to anything with per-request isolation. Concrete ask: a one-to-two week spike to scope the actual requirement (business rules? DSL? resource resolution?) against maintained options, returning a build-vs-buy recommendation with a rough TCO. If we hold legacy Hoa code today, that spike also produces the removal plan — name an owner and a target date, and treat the package as frozen until then.