Mining Manager Laravel Package

Technical Evaluation

• Architecture fit: The release confirms this is a SeAT plugin, not a standalone Laravel package. That materially clarifies fit: it runs inside an existing SeAT deployment, extends SeAT's Eloquent models, permissions, webhooks, scheduler and ESI integration, and surfaces routes/views/tabs in the SeAT UI. Fit is therefore conditional on our SeAT version and on accepting SeAT as the system of record for corporation, character, wallet and mining data. The ecosystem signal remains weak (3 stars, 0 dependents, overall score 18.8/100, opportunity 28.63); v2.0.4 adds real depth but does not change the strategic recommendation: POC/reference accelerator, not an unexamined core dependency.
• Integration feasibility: Now demonstrably feasible as a SeAT plugin: Composer install, service-provider discovery, nine additive migrations, no new ESI scopes in this release, settings-driven feature toggles, scheduled jobs, webhooks, permissions, and Blade/UI surfaces. The hard dependencies are SeAT version compatibility, PHP/Laravel versions imposed by SeAT, MySQL schema behavior, queue/scheduler configuration, ESI rate limits, and corporation wallet access. Financial workflows (payments, balances, refunds, invoice matching) raise the bar: this is no longer just telemetry ingestion, it writes money-adjacent ledger state.
• Technical risk: GPL licensing remains a material risk for distributed or customer-facing distribution; legal review is still required before embedding or exposing it in a product. Low adoption and a small maintainer surface (public issue tracker, apparent single maintainer) imply bus-factor and validation risk. The v2.0.4 release notes disclose behavioral changes on upgrade even though the release is described as backwards compatible: webhook alert toggles can remain silently disabled, belt/ice/gas tax bills rise going forward, Janice split prices correct from the first refresh, partly paid invoices begin receiving reminders (including pre-existing ones), and the Data Export setting now actually blocks exports for everyone. These are release-management and member-communication risks, not just code risks. Financial correctness risk is elevated: payment matching, remainder cascades, account balances, refunds and manual "Mark as sent" flows need reconciliation and audit controls. Invoice immutability after issue is a positive control. Release metadata date anomaly from the prior assessment should still be verified.
• Key questions: Which SeAT versions are supported, and what is the upgrade path between them? Is this a plugin only, or does it also assume a full SeAT deployment we must own? Which ESI scopes and corporation roles are required, and does it ever store wallet, pool or miner credentials? How are payments matched, deduplicated and audited, and what is the source of truth for balances? Are refunds and balances reconciled against the corporation wallet, and how are discrepancies surfaced? Is the data model multi-tenant/corp-scoped, and are permissions enforced server-side (including the new mining-manager.moon_finder)? Are tests/CI/security policy present, and what is the release/upgrade policy? What queue, scheduler and network access does it require? What are our GPL obligations under our distribution and SaaS model? What is the comms and rollback plan for the disclosed behavioral changes?

Integration Approach

• Stack fit: Treat it as a SeAT-native plugin inside a pinned SeAT instance, not as a generic Laravel module. Isolate it in its own database schema or dedicated SeAT deployment where possible, wrap its data behind an internal adapter, and avoid leaking its models into core domain code. Run scheduled imports, tax calculation and wallet verification on dedicated queue workers with clear scheduler ownership. Restrict director-level features (payments, balances, refunds, moon finder, exports) through SeAT permissions and least-privilege roles.
• Migration path: Legal/license review → SeAT version compatibility check → staging SeAT clone with production-like data → apply the nine additive migrations → verify webhooks, settings, permissions and exports → run import-character-mining --dry-run and tax recalculation in dry-run where available → feature-flagged pilot on a non-critical corporation → communicate billing/reminder/export changes to directors and members → production rollout with backup and rollback. Do not run migrations against shared production SeAT without a tested restore point.
• Compatibility: Pin an exact plugin version and the matching SeAT/PHP/Laravel matrix. Validate MySQL behavior, Redis queues, scheduler timing, ESI rate limits, Janice price refresh, corporation wallet divisions, and Blade/UI asset assumptions. Because v2.0.4 changes billing and reminder behavior, test with representative historical invoices and partial payments. If incompatible with our SeAT version, fork under GPL with a named internal owner and a patch budget.
• Sequencing: 1) Confirm SeAT compatibility and GPL implications; 2) inventory the disclosed behavioral changes and assign owners for webhook re-enablement, billing comms, reminder comms and export policy; 3) stage the upgrade with backups; 4) validate payments/balances/refunds against a controlled test corporation; 5) build adapter and reporting contracts; 6) pilot with alerting and rollback; 7) decide rollout, fork or reject. Hold a hard decision gate after the pilot, with financial reconciliation signed off before production.

Operational Impact

• Maintenance: Single-maintainer and low-community risk persists. Budget for version pinning, upstream monitoring and a possible internal fork. Establish GPL compliance review before external distribution or SaaS exposure. Track SeAT upgrades as a first-class dependency, since plugin compatibility is bound to SeAT releases. Maintain a register of intentional settings changes after each upgrade, especially webhook alert toggles, export permissions and billing switches.
• Support: No vendor SLA. Require runbooks covering wallet verification, manual payment assignment and undo, balance and refund handling, "Mark as sent," webhook re-enablement, and export troubleshooting. Define L1/L2 ownership split between SeAT admins and finance/ops. Expect slow upstream escalation; plan for self-support and document EVE/ESI quirks.
• Scaling: Mining imports, ore registry valuation, Janice price refreshes, tax calculation and wallet verification can dominate load. Use queued jobs, batching, caching, rate limits, retention policies and horizontal workers. The new payments/balances and moon-finder features add read-heavy director dashboards and search queries; monitor DB growth, index coverage and dashboard query cost. The weekly Outstanding Mining Tax digest adds scheduled outbound notification load.
• Failure modes: Miner/ESI timeouts and auth failures, stale telemetry, queue backlog, migration conflicts, plugin upgrade breakage, silently disabled webhook alerts, incorrect billing after import aggregation changes, missed reminders, unexpected export blocking, payment double-crediting or mis-matching, balance/refund reconciliation gaps, secret or wallet exposure, GPL contamination, and upstream abandonment. Mitigate with idempotent jobs, circuit breakers, reconciliation reports, alerting, rollback plans, pre-upgrade backups and a fork contingency.
• Ramp-up: Laravel/SeAT engineers can onboard to the mechanics quickly; the real ramp-up is EVE domain knowledge, corporation wallet and ESI permissions, financial reconciliation discipline, moon/refinery intel workflows, and member communications. Documentation may be thin outside the release notes, so allocate a structured spike, pairing time and a finance-ops review before committing roadmap capacity. Treat the upgrade itself as a change-management exercise, not a routine dependency bump.