Cli Laravel Package

Product Decisions This Supports

• Build vs. buy vs. inherit for developer-facing tooling. This package sits in the console/CLI layer: parsing argv into named options and arguments, and writing formatted output to a terminal. The decision it informs is whether a product adds a third-party CLI layer for internal tooling (ops scripts, code generators, scheduled maintenance commands, admin-only binaries) or uses what the framework already ships.
• Framework leverage audit. For a Laravel codebase the capability under evaluation is already present: Artisan is built on Symfony Console, which covers argument/option definitions, validation, help generation, interactivity, output verbosity levels, and table/progress formatting. Evaluating hoa/cli therefore produces a "no incremental capability" finding — a useful, citable data point when someone proposes adding a CLI dependency.
• Roadmap: developer-experience workstream. If the roadmap has a DX or internal-tooling initiative, this is a candidate to evaluate and reject in a single spike, which keeps the initiative's dependency budget clean and prevents an unmaintained package from becoming a load-bearing part of internal workflows.
• Design reference, not a dependency. The one genuinely interesting idea here is a declarative, grammar-style definition of a command's options rather than imperative registration. That pattern is worth borrowing as an internal convention on top of Symfony Console's InputDefinition; it is not worth importing as code.
• Maintenance/TCO decision. Archived repository, last release July 2017, 12 stars, zero dependents. That combination is a strong negative signal: no upstream fixes, no security response path, no community backstop if a defect surfaces. The low opportunity score corroborates the read — the capability is real but fully commoditized elsewhere.
• Product relevance check. Nothing in this package is customer-visible. It cannot differentiate the product; it only affects engineering velocity and risk. That framing matters when prioritizing — it belongs in a platform-hygiene conversation, not a feature roadmap conversation.

Verdict this assessment supports: do not adopt. Use the framework's existing console layer; treat hoa/cli as a design reference only.

When to Consider This Package

Adoption criteria — all would have to hold simultaneously:

• The codebase is a legacy Hoa-based PHP application that already pulls in hoa/consistency, hoa/ustring, and related Hoa modules, so hoa/cli adds no new dependency surface.
• The runtime is pinned to PHP 5.6/7.0-era constraints and there is no near-term upgrade path.
• The need is narrow: parse arguments and write console output. Nothing interactive, no readline, no terminal/window management (that was hoa/console, a different and larger package).
• The usage is confined to non-customer-facing, non-security-sensitive tooling where a defect is an inconvenience, not an incident.
• The team accepts no upstream support and has the appetite to vendor or fork if needed.

Look elsewhere when any of the following is true — which is the normal case:

• You are on Laravel 8+ / PHP 8+. Archived 2017-era packages routinely fail Composer resolution or emit deprecations on modern runtimes; the spike will almost certainly end in a failed composer require rather than a fair evaluation.
• You need maintained security posture, an active issue tracker, or any form of vendor accountability. An archived repo with zero dependents means the ecosystem has not stress-tested it — nobody else's production traffic is de-risking your adoption.
• You need more than parsing: interactive prompts, progress bars, tables, colored output, signal handling, or testing helpers for console commands.
• You are evaluating a standalone CLI product rather than commands inside an app — that is a different architecture (single-file binary, PHAR packaging, self-update) and neither this package nor Artisan alone addresses it.

Preferred alternatives, in order: Symfony Console (already a transitive dependency in any Laravel app — zero new surface), Laravel's own command and prompt APIs for in-app tooling, Laravel Zero or Minicli for standalone CLI products, and any of the actively maintained output-formatting libraries for presentation concerns. Adopt only what you cannot get from the dependency tree you already have.

How to Pitch It (Stakeholders)

Executive summary. A proposal surfaced to add hoa/cli, a PHP console/argument-parsing library, to our tooling. Recommendation: decline. The capability it provides — turning command-line flags into structured options and printing to a terminal — is already delivered by the console layer we get for free through our framework. Adopting this package would add a dependency without adding a capability, and it carries the specific risk profile we try to avoid: the project is archived, its last release was July 2017, it has 12 stars and zero dependent packages, and it has therefore never been exercised against a modern PHP runtime by anyone but its original author. The practical outcome is a short-term convenience paid for with a long-term maintenance and security obligation we cannot discharge. Cost of adoption exceeds benefit; the correct decision is to consume the framework's built-in console tooling and, if the team likes the declarative option-definition style, adopt that as an internal convention at zero dependency cost.

For engineering. Run a one-hour timeboxed spike if anyone wants the negative result on record: attempt composer require hoa/cli on our current PHP version, then port a trivial command. Expect resolution or deprecation friction. Either way, the recommendation stands — Symfony Console via Artisan covers option definitions, validation, help text, interactivity, and output formatting, and it is maintained by people whose job that is. There is no functional gap here to close.

What we are deliberately not doing, and why it's low-risk. We are not blocking future CLI investment. If a genuine need appears — a distributable CLI product, or richer terminal interaction inside the app — the answer is a maintained package evaluated on its own merits, not a resurrected one. Keeping an archived component out of the tree now preserves that optionality rather than spending it.