Iss Satellite Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork (still the primary decision). v0.2.4 does not change the licensing picture (MIT, low switching cost) but it does change the confidence picture: the package is under active development, not abandoned. The decision it supports is still "evaluate, then adopt / fork / build," with fork now the more attractive fallback because there is a moving target worth freezing.
• Domain scoping for Brazilian contract-termination and ISS flows. The release notes are the most informative artifact we have: "Mega queries for Distrato/AVRA flow" places the package squarely in Brazilian real-estate/contract-cancellation (distrato) processing with an integration into Mega (the ERP/back-office system). If the roadmap touches distrato handling, ISS calculation on terminated contracts, or Mega data extraction, this is now a concrete input to scoping rather than a guess from a package name.
• Integration-surface decision with Mega. "Mega queries" implies outbound data access to a third-party Brazilian ERP. That is an architecture decision in its own right — do we centralize Mega access in one adapter, and is this package that adapter or a stopgap? A PM should decide the shape of the Mega integration before endorsing any single implementation of it.
• Make-vs-extend for a satellite module. The "satellite" convention (small sidecar packages attached to a core Laravel app) is confirmed by the repo structure and the org name (appnave), not by Bildvitta as originally guessed. This is an exemplar of an internal satellite pattern — useful if we are standardizing that convention, but it is one team's convention, not an industry one.
• Vendor and maintenance risk review — revised. Still effectively single-maintainer, but v0.2.4 brought a first-time contributor. That is a marginal positive on bus factor and a marginal positive on "someone other than the author can land a PR." It is not succession planning. The upgrade-ownership question for Laravel majors remains open.
• Pre-1.0 API stability as a roadmap input. At 0.2.x, minor version bumps can and will break callers. Any adoption decision must budget for pinning and periodic upgrade work, and the PM should treat "who absorbs that churn" as part of the cost case.

When to Consider This Package

Consider a timeboxed evaluation only if all of the following hold:

• The functional scope genuinely overlaps a roadmap item — now more credibly: distrato/AVRA handling with Mega-backed queries. Confirm by reading PR #18 and the surrounding code, not the release note alone.
• It supports the Laravel and PHP versions in your current support matrix; check composer.json constraints against your upgrade timeline. Pre-1.0 versioning means you should also read the v0.2.3→v0.2.4 diff for silent behavior changes.
• You can identify a named owner (internal team or maintainer) who will respond to security reports and Laravel major bumps.
• Test coverage, static analysis, and CI exist and pass on a clean checkout — release notes alone still give no evidence of this.
• The dependency tree is small and does not drag in abandoned or pinned-vendor packages.
• Your Mega integration strategy is compatible: if we standardize Mega access in a single internal adapter, this package must be wrappable behind it rather than called directly.

Look elsewhere — or plan to build/fork — when:

• The repository still has no meaningful README, no changelog, and a placeholder description. v0.2.4 added a feature, not documentation. That remains a quality signal.
• Release metadata looks untrustworthy. The anomalous "last release" date of 2026-10-16 is still unexplained. Active releases make this more worth resolving, not less — if the publishing pipeline emits bad timestamps, release history cannot be used as a maintenance signal.
• The domain is regulated (tax, invoicing, fiscal documents). Distrato and ISS touch municipal tax rules that vary by jurisdiction and change frequently. Established Brazilian fiscal tooling (ACBr, NFePHP and similar) remains the benchmark; a thin 0.x package should not be the system of record for compliance logic unless we own the update loop.
• Your team cannot absorb ownership and pre-1.0 churn. Two contributors on one PR is better than one, but there is still no user community to share upgrade pain with.
• The capability is small enough to implement in-house behind an interface in less time than the due diligence takes.

How to Pitch It (Stakeholders)

To executives: The package we flagged for a technical spike shipped a new version (v0.2.4) adding distrato/AVRA query support against Mega. Two things changed: the project is actively maintained rather than dormant, and the domain is now clear — Brazilian contract-cancellation and ISS processing. Two things did not change: it is pre-1.0 with no community adoption, and there is no evidence of tests or documentation. We are still not proposing it as a production dependency. We are proposing the same short, fixed-cost spike, now with better-defined scope and a better fallback: if the code is sound, we can fork and own it cheaply under MIT; if not, we build behind our own Mega adapter.

To engineering: Read PR #18 first — it is the clearest specification of intent we have. Then check composer.json constraints, CI status, and test coverage, and diff v0.2.3→v0.2.4 for behavioral changes before pinning anything. The 2026 release-tag anomaly is still unresolved and should be raised with the maintainer or noted as a standing caveat. If we proceed, wrap Mega access behind an internal interface so the domain layer and the ERP integration are independently replaceable, and assign a named owner for upgrades and pre-1.0 churn.

Bottom line for the decision log: activity signal improved, production-readiness signal unchanged. Low confidence on quality, low switching cost, permissive license. Fund evaluation, do not fund adoption; default remains build-or-fork.