Cloak Analyzer Laravel Package

Product Decisions This Supports

• Coverage tooling standardization (weak signal): The package's only real thesis is that coverage analysis should be driver-agnostic — one API over Xdebug, PCOV, and php-code-coverage. That framing is useful when deciding whether to abstract coverage internally, but the package itself does not need to be the vehicle.
• Build vs. buy vs. fork: With 0 stars, 0 dependents, MIT license, and an archived repository, the honest decision this supports is build-internally or fork-with-ownership, not adopt. Anything you take from here becomes your maintenance burden on day one.
• CI quality-gate roadmap: If you are scoping PR-level coverage diffing, coverage trend dashboards, or "coverage must not regress" gates, this package is a useful reference design for the seam between test runner and report generator — not a dependency to plan around.
• Vendor risk assessment: A concrete example for your dependency policy: archived + zero dependents + zero stars is an automatic "no" for anything in the production path, and a "maybe, vendored" for internal dev tooling only.
• Do not let the score mislead you: The high opportunity score (8.23) against a near-zero overall score (0.05) is a scoring artifact — a niche abstraction with no competition looks "opportunitistic" while being unmaintained and unadopted. Opportunity is not adoption readiness. Treat these numbers as separate gates, not a blended verdict.

When to Consider This Package

Adopt-adjacent criteria (all must hold):

• You have a concrete, recurring need for a driver-agnostic coverage reader — e.g., you support multiple PHP versions or runtimes where Xdebug is unavailable and PCOV is the fallback.
• You are willing to vendor the source into your repo and own it, since upstream is archived and will receive no security or compatibility patches.
• You have verified the code against your current PHP and PHPUnit versions — an archived coverage abstraction is very likely pinned to an older php-code-coverage major, and that library changes its API regularly.
• Your use is internal developer tooling, never shipped in a product artifact or exposed at runtime.

Look elsewhere when:

• You need maintained coverage: use sebastianbergmann/php-code-coverage directly — it is the canonical implementation this package wraps — and pair it with Pest/PHPUnit output.
• You want the outcome, not the plumbing: Codecov, Coveralls, or SonarQube give you PR diffs, trends, and gates without owning an abstraction layer.
• You need mutation or quality signal beyond line coverage: Infection covers that ground.
• You need anything with a support contract, CVE response, or a maintainer to escalate to.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed abstraction over PHP code-coverage tools. It is archived, has no stars and no downstream dependents, and therefore carries full maintenance risk with zero community backstop. Recommendation: do not adopt. The underlying capability — coverage reporting and PR gates — is available from maintained libraries and managed services. There is no strategic reason to take on an orphaned dependency for a commodity capability.

To engineering: It is worth thirty minutes of reading for its interface design, and roughly an afternoon to replicate. The canonical library underneath it is actively maintained and should be used directly. If a specific driver-abstraction need emerges, we fork with a named owner and a pinned PHP/PHPUnit compatibility matrix — otherwise we skip it. Adoption is a "no" for production and a "reference only" for internal tooling.