Triagem Bundle Laravel Package

Technical Evaluation

Architecture fit: The package is novosga/triage-bundle — a Symfony bundle, not a Laravel package. That distinction is the single most important framing point for a TPM: it is a framework-specific artifact from the Novo SGA (queue/triage management) ecosystem, targeting appointment scheduling and priority triage. It will not drop into a Laravel application via package discovery, facade, or config/*.php publishing; it ships Symfony DI extension classes and a bundle configuration tree. Fit is strong if the consuming system is Symfony-based or if the domain model (units, appointments, triage priority) can be used as a standalone library. Fit is weak if the expectation was a Laravel-native package.

Integration feasibility: Moderate. The v2.3.0 change set is small and coherent — one correctness fix, one framework alignment, one dev-tooling refresh, one feature. Nothing indicates a rewritten public API. The real integration cost sits outside the changelog: translating the Symfony bundle's service wiring into the host container (a Laravel service provider bridge or an anti-corruption layer), and validating config semantics for the new Appointment max delay setting. A spike in a non-production branch is warranted before committing to the dependency.

Technical risk:

• Implicit version floor. Upgrading the Symfony constraint from 7.1 to 7.4 LTS is a chore in intent but a compatibility boundary in effect. Any consumer pinned to Symfony 7.0–7.3, or to 6.4 LTS, is locked out of this release even though semver calls 2.3.0 a minor. Confirm whether the constraint is ^7.4 or a wider range.
• PHP floor. Symfony 7.4 and PHPUnit 11 both imply PHP 8.2+. Runtime PHP requirements should be verified in composer.json, not inferred.
• Correctness history. The timezone fix ("use unit timezone when parsing scheduled appointment datetime") means appointments scheduled before this release may have been persisted or interpreted under the wrong timezone. This is a silent data-integrity issue, not a cosmetic bug — it requires a data audit, not just a version bump.
• Undocumented feature semantics. "Appointment max delay config" arrives with no described default, unit, or boundary behavior. Whether the default preserves prior behavior (no delay enforcement) or silently begins rejecting appointments is the highest-impact unknown in this release.
• Governance. Single primary maintainer, small contributor surface. Consistent with healthy small OSS, but a bus-factor consideration for anything operationally load-bearing.

Key questions:

1. Does the new max-delay setting default to "disabled/unlimited," and is a zero or null value treated consistently?
2. Is the timezone fix behavior-changing for existing stored records, and is a backfill or re-interpretation needed?
3. Does 2.x still publish a 6.4 LTS-compatible line, or is 7.4 now the only supported path?
4. Is there a supported way to consume the domain services outside a full Symfony kernel (plain PSR container, standalone instantiation)?
5. What is the CI matrix — PHP and Symfony versions actually tested — and is there coverage around timezone/DST boundaries?
6. Are there downstream migrations or schema changes implied by the max-delay feature?

Integration Approach

Stack fit: Treat the package as a bounded-context domain library rather than a framework plugin. In a Laravel estate, that means: register the underlying services manually in a service provider, map bundle configuration keys into config/ by hand, and explicitly disable reliance on Symfony bundle auto-discovery. In a Symfony estate, standard composer require plus bundles.php registration and a config/packages/*.yaml block. Do not assume Laravel's container can resolve the bundle's compiler passes.

Migration path: There is no prior version in use, so this is greenfield adoption rather than migration — but the release introduces two adoption forks. For hosts on Symfony 7.4+, adopt 2.3.0 directly. For hosts on Symfony 7.1–7.3 or 6.4, start at 2.2.1 and treat the 7.4 upgrade as its own tracked work item. Separately, if any appointment data is being imported from a system that already used an earlier 2.x version, run the timezone audit before assuming parity.

Compatibility: Verify and record four constraints before sign-off — PHP minimum, Symfony version range, database driver assumptions for the bundle's persistence layer, and whether the dev-tool upgrades (PHPStan 2, PHPUnit 11, PHPCS 4) leak into production requirements. The dev-tool bump is developer-experience only and should carry no runtime risk, but PHPStan 2 raising its analysis level can produce new CI failures if the project reuses the bundle's static analysis config.

Sequencing:

1. Confirm host PHP and Symfony versions against the bundle's composer.json.
2. Spike the integration in a non-production branch, exercising the DI bridge (or bundle registration) end to end.
3. Build a multi-timezone test fixture — at minimum two units in different zones plus a DST transition date — and validate scheduled appointment parsing.
4. Configure Appointment max delay explicitly with an intentional value rather than accepting the default, and document the chosen semantics.
5. If any pre-existing appointment data is in scope, run a read-only audit comparing stored datetimes against expected unit-local times.
6. Roll out behind a feature flag if triage behavior affects live queue operations.

Operational Impact

Maintenance: The release signals an actively maintained project that tracks upstream framework lifecycle — moving to 7.4 LTS and clearing its deprecations in the same window is a good-faith maintenance indicator, as is the paired dev-tooling modernization. The counterweight is concentration: one primary contributor across all five pull requests. Plan for the possibility of slow upstream turnaround on issues, and budget for the option of vendoring or forking the small surface area if the package becomes load-bearing.

Support: Open source with no visible commercial SLA. Support runs through GitHub issues and pull requests. The clean, conventional-commit-style changelog and PR-linked history make self-support tractable, but there is no vendor to escalate to. For a TPM, that means the package should not sit on a critical path without an internal owner who can read the source.

Scaling: Triage and appointment scheduling are typically I/O- and database-bound rather than compute-bound, so the package itself is unlikely to be the scaling bottleneck. Watch the timezone-conversion path — per-record timezone resolution during appointment listing can multiply into repeated lookups at volume — and watch query patterns around delay-window filtering once max-delay is enabled, since that predicate may not be index-friendly.

Failure modes:

• Silent timezone mis-scheduling — appointments interpreted in the wrong unit's zone, producing no error but wrong queue positions. This is the failure this release fixes and the one most worth regression-testing.
• Configuration drift — max-delay left unset in one environment and set in another, causing inconsistent acceptance of appointments between staging and production.
• Container resolution failure — the DI bridge works in the spike but breaks on a cold cache or a differently ordered provider registration.
• Version lockstep — the next Symfony LTS bump strands the application until the maintainer publishes a matching release.
• Deprecation debt — the bundle clearing 7.4 deprecations now does not guarantee it will clear 8.x deprecations on the same cadence.

Ramp-up: Low for the mechanics — install, register, schedule an appointment. Moderate for the domain: Novo SGA's model of units, priority weighting, and triage rules carries real semantic depth, and the max-delay feature compounds it with scheduling policy. Budget roughly a day for a capable PHP engineer to get a working integration and a further two to three days to build confidence in the timezone and delay-window behavior with realistic multi-unit data. A TPM should not approve this package on the strength of its changelog alone; the value is in the domain model, and the risk is concentrated in the two behavior-affecting changes shipped in this minor version.