Phealng Laravel Package

Product Decisions This Supports

• Build vs. buy for EVE Online integrations — decided: build on ESI, not on this. This package is a client for CCP's retired XML API (shut down in 2018). It is archived, receives no security patches, and has zero dependents on Packagist. Any roadmap item that assumes PhealNG is a viable integration layer should be re-scoped to the modern ESI (JSON REST + OAuth 2.0 SSO) surface.
• Legacy maintenance triage. The only decision this package actively informs is whether to keep a legacy service pinned to it. Because the underlying endpoints no longer exist, keeping it provides no functional value — the decision becomes "freeze, port, or retire," not "upgrade."
• Technical-debt quantification. Its presence in a dependency graph reliably signals a codebase untouched since ~2018 and therefore also carrying stale PHP (5.4+ era), Composer, and PSR-0 autoloading assumptions. That is a useful input to a modernization epic's sizing and sequencing.
• Migration scoping and effort estimation. Reading the existing PhealNG call sites gives a concrete inventory of which EVE data domains (character, corporation, market, killmails) are actually used — the shopping list for an ESI port — and shows where the old caching layer and key/ID handling were bolted in, since ESI replaces those with OAuth tokens and scoped access.
• Not a use case: greenfield features, new third-party integrations, or anything customer- or revenue-facing. There is no supported path from this package to working EVE data.

When to Consider This Package

Adoption criteria — effectively, none for new work. The narrow, defensible conditions are:

• You are forensically reading it to understand a codebase you acquired or inherited, and you need the reference implementation of the old XML responses to map fields onto ESI equivalents.
• You maintain an offline/archival tool that deliberately replays or parses historical EVE XML payloads you already hold, and you want the response-parsing shape without rewriting it from scratch. Even here, vendoring the code is safer than depending on an archived package.
• You need a one-off script against a private, self-hosted XML fixture for testing or data migration.

Look elsewhere — specifically at an actively maintained ESI client, or a thin in-house HTTP/OAuth wrapper — when any of the following hold:

• You need authentication: ESI requires OAuth 2.0 SSO with scopes and refresh tokens; PhealNG's keyID/vCode model has no counterpart in the current API.
• You need reliability guarantees: no maintainer, no issue triage, no CVE response, no PHP 8.x compatibility testing.
• You need rate-limit and error-budget handling (ESI's error-limit headers, ETag caching). PhealNG cannot model these, so you would be building it anyway.
• Your platform standard is PHP 8+ / PSR-4 / modern Composer: the package is PSR-0 and targets PHP 5.4, so it becomes an anchor on your upgrade path.
• Your dependency policy forbids archived upstreams — which, for most organizations, settles it.

How to Pitch It (Stakeholders)

For executives (one line): PhealNG is a well-regarded, MIT-licensed client for a third-party game API that no longer exists — the vendor shut it down in 2018 and the library was formally archived. It carries no licensing cost but also no support, no security updates, and no way to reach live data. It is a migration artifact, not a platform choice.

For engineering:

• Status: archived upstream, unmaintained since 2018, PHP 5.4+/PSR-0, zero dependent packages. No upgrade path exists because the remote API is gone — the blocker is external, not something we can patch.
• Recommendation: do not add it to any new project. For existing consumers, treat the dependency as a migration trigger: inventory call sites, map each data domain to its ESI equivalent, and replace the transport plus auth in one pass rather than attempting incremental fixes.
• Effort framing: small surface area — historically a handful of namespaced request classes — so the work is mostly auth (OAuth 2.0 + scopes), caching (ETags), and rate-limit handling, not business-logic rewrites. That is the honest cost of the port, and it is bounded.
• Risk of inaction: low immediate blast radius (the code fails closed rather than exfiltrating data) but high opportunity cost and a permanent blocker on PHP upgrades, dependency hygiene, and security review sign-off.
• Credit where due: the package's original virtue — an API client that did not need changing when the vendor's API changed — is the requirement to carry into the replacement design: isolate the vendor boundary behind our own interface so the next API migration is a config change, not a rewrite.