Cli Laravel Package

Technical Evaluation

Verdict: reject as a production dependency; retain only as reference reading. hoa/cli is a single module from the archived Hoa project — a research-grade, academically structured PHP library collection that was split into dozens of micro-packages. It is 8+ years past its last release, has 12 stars and zero dependents, and the upstream organisation is archived (read-only). There is no scenario in a Laravel codebase where adopting it produces more value than the ~30 lines of Symfony Console / laravel/prompts code it would replace.

Architecture fit

• Hoa packages are not self-contained: they assume hoa/consistency and hoa/stream, which register a custom hoa:// protocol/stream-wrapper layer via a bootstrap side effect. This is an ambient runtime dependency, not an explicit one — the opposite of Laravel's service-provider/explicit-facade model.
• No Laravel integration surface exists: no service provider, no config publish, no facade, no contract. Any use requires hand-rolled wiring in AppServiceProvider, and the package will still register global state on boot.
• Functional overlap is near-total with Artisan (Symfony Console) for tables, helpers and questions, and with laravel/prompts (Laravel 10+) for interactive input, validation and styled output. The package does not fill a gap; it duplicates the platform.

Integration feasibility

• Composer-installable but likely to resolve against PHP 5.5/7.x-era constraints. Modern Laravel (10/11/12) requires PHP 8.1+; expect composer require to fail on platform constraints, or to succeed only with --ignore-platform-reqs — a red flag for a TPM to escalate, not work around.
• The Hoa autoload/protocol shim is a known source of conflicts with Composer's PSR-4 autoloader and with other packages that touch stream wrappers.
• Exact API surface should be confirmed by reading src/ before any spike; the package's own documentation is thin and the project site/DNS is unreliable post-archive.

Technical risk

• Abandonment risk: certain. No security response process, no CVE monitoring, no patch path. Any vulnerability found becomes ours to fork.
• PHP 8 compatibility: unverified and unlikely. Hoa code predates PHP 8's reserved-word and signature strictness; expect deprecations and possible fatals. Deprecation noise alone will pollute Artisan output and CI logs.
• Autoload/global-state risk: high. Protocol registration and stream wrappers can affect unrelated code paths, which is hard to attribute during incident response.
• Non-interactive/CI risk: readline-style helpers that block on STDIN will hang pipelines unless every call site is guarded — and Laravel's --no-interaction flag will not automatically propagate into a third-party library that never heard of it.

Key questions

1. What specific capability do we believe is missing from Artisan + laravel/prompts + symfony/console? Name the user story.
2. Does the spike run green on our minimum supported PHP with E_ALL and deprecations as errors?
3. Does it honour --no-interaction, respect STDOUT/STDERR separation, and detect TTY correctly under our CI runner?
4. Who owns the fork if we vendor it, and what is the maintenance budget line?
5. Has legal signed off on a BSD-3-Clause dependency with no maintainer to notify for attribution or advisory purposes?

Integration Approach

Stack fit

• Poor. Laravel's console layer is Symfony Console; hoa/cli sits beside it, not on top of it, so we would end up maintaining two output/input abstractions in one process.
• The idiomatic stack for the same need is: laravel/prompts for interactive input, symfony/console helpers (Table, ProgressBar, QuestionHelper) for structure, and nunomaduro/termwind for styled output.

Migration path

• Recommended path is no migration: do not introduce the dependency. If a capability was identified, implement it directly against the platform primitives.
• If a spike is authorised, timebox it to one day, isolate it in a throwaway branch behind a single adapter class (App\Support\Console\InputAdapter), and require a documented diff of what Symfony Console could not do. Delete the spike regardless of outcome.
• Only fallback if a genuinely unique capability emerges: fork into a first-party namespace under our ownership, not as a third-party require. That decision must be TPM-owned with a named maintainer and a quarterly review.

Compatibility

• Confirm PHP constraint resolution first; treat any need for --ignore-platform-reqs as an automatic fail.
• Check for collisions on stream wrappers and autoloader hooks in a full composer install of the real app, not a scratch project.
• Verify behaviour under Laravel's artisan bootstrap, under --quiet, --no-interaction, and with STDERR redirected.

Sequencing

1. Gate 0 (do now): record an ADR documenting the rejection, the overlap analysis, and the sanctioned alternatives. This is the deliverable, not code.
2. Gate 1: if a gap is claimed, write the user story and prove the gap against laravel/prompts docs before any install.
3. Gate 2: one-day spike, isolated adapter, PHP matrix in CI, deprecations as errors.
4. Gate 3: only if Gate 2 passes cleanly — fork, ownership, budget, security-review cadence.
5. Never: direct composer require hoa/cli into a production service.

Operational Impact

Maintenance

• Zero upstream maintenance; the archive banner is permanent. Every future PHP upgrade becomes our problem to diagnose against dead code.
• Adds a non-obvious transitive surface (hoa/consistency, possibly hoa/stream) that appears in composer outdated reports and security scans with no remediation available, generating recurring triage noise that a TPM will have to repeatedly waive.

Support

• No issue tracker responses, no maintainer contact, no versioning roadmap. Internal engineers inheriting the code will have no escalation path.
• Onboarding cost is disproportionate to value: the Hoa idioms (Xcallable, hoa://, protocol registration) are unfamiliar to typical Laravel engineers and exist nowhere else in our stack.

Scaling

• Irrelevant at scale for compute, but relevant operationally: blocking-input helpers do not scale to parallel CI jobs, containerised task runners, or queue workers where STDIN is absent. Each call site needs defensive guards that a first-party implementation would not.

Failure modes

• Hang: blocking read on closed/absent STDIN in CI or a queue worker — jobs time out rather than error.
• Boot failure: protocol/stream-wrapper registration clashing with autoloading or another package, surfacing as a fatal in unrelated code.
• Noise: PHP 8 deprecations emitted into Artisan output, breaking log parsers or golden-file tests.
• Silent degradation: colour/cursor escape codes written into piped output, corrupting machine-readable logs.
• Unpatchable CVE: advisory published, no fix available, forced emergency fork under incident pressure.

Ramp-up

• For this package specifically: near-zero worth in ramp-up terms. Budget the engineering time instead against laravel/prompts and Symfony Console helpers, which have current docs, active maintainers, and existing team familiarity.
• The one legitimate form of "leverage" is research: Hoa's modular decomposition and its separation of terminal I/O concerns are worth a 30-minute read for a CLI design discussion, and can inform our own adapter boundaries. Cite it in the ADR as prior art — do not import it.