Triagem Bundle Laravel Package

Product Decisions This Supports

• Scheduling/triage capability for NovoSGA-based queue systems. This bundle supplies the appointment and triage domain model (scheduled appointments, service/unit assignment, delay rules) rather than a generic calendar library — it is only worth a decision if you are building on or integrating with the NovoSGA queue-management ecosystem (typically healthcare/clinic or high-volume service counters).
• "No-show / late-arrival" policy as a configurable product rule. v2.3.0 adds Appointment max delay config, which turns a hard-coded constraint into a per-deployment setting. This is the most product-relevant item in the release: it lets you ship one codebase to clinics with different tolerance windows (e.g. 10 minutes vs. 30 minutes before a ticket is forfeited) instead of forking or hard-coding a business rule.
• Multi-timezone / multi-site rollout. The fix: use unit timezone when parsing scheduled appointment datetime change means an appointment booked against a service unit is now interpreted in that unit's timezone rather than a global default. For a PM this is a correctness precondition for launching in more than one region or in a country with multiple timezones — previously this was a latent data-integrity risk in schedule reporting and attendance decisions.
• Platform lifecycle / maintenance budget. The jump to Symfony 7.4 LTS plus PHPStan 2, PHPUnit 11 and PHPCS 4 signals an actively maintained dependency with a supported runway. This supports a "buy/borrow, don't build" call for the appointment domain layer and gives you a defensible answer to "will this still get security patches next year?"
• Build vs. buy scoping. The bundle covers the data model and appointment rules but is a domain bundle, not a product surface. It reduces the scope of what you must build (entities, delay logic, timezone handling) while leaving UI, notifications, check-in kiosks and reporting as your own work.

When to Consider This Package

Consider it when:

• You are on Symfony 7.x and already in, or deliberately integrating with, the NovoSGA/queue-management domain. The 7.4 LTS upgrade makes this a reasonable time to adopt; anyone still on Symfony 6.x or earlier should expect to do the upgrade work themselves, as the release is explicitly forward-moving.
• Appointment tolerance windows differ per site, service or unit — the new max-delay configuration is a direct fit and saves you a bespoke settings layer.
• Your users span multiple timezones, or you have been bitten by appointments being interpreted against server time. The timezone fix is the reason to upgrade rather than stay on 2.2.x.
• You need a maintained dependency with static analysis and a modern test stack — the tooling upgrade is a proxy for "someone is watching this."

Look elsewhere when:

• Your stack is Laravel. Despite being PHP, this is a Symfony bundle: it ships Symfony service definitions, configuration trees and event/listener wiring. Using it in Laravel means fighting the container and either running Symfony alongside Laravel or re-implementing the domain layer. For a Laravel product, a standalone scheduling library or a thin internal domain model is almost always the lower-risk path.
• You need an end-user scheduling product (booking UX, calendars, reminders, payments). This is infrastructure, not a product.
• You require published API/BC guarantees. The release contains two chore upgrades and a feat, with a patch-level timezone behaviour change — the versioning is loose. If you need strict semver discipline, treat every minor as potentially behaviour-changing and pin versions.
• You cannot absorb periodic framework upgrade chores. The 7.1 → 7.4 hop landed in a minor release; expect similar work to recur and budget for it.
• Licensing/support and long-term stewardship have not been reviewed. Single-maintainer projects warrant a contingency note in your risk register.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated the new 2.3.0 release of the triage/appointment component. It is a maintenance-and-correctness release with one genuinely useful product feature: appointment lateness limits are now configurable per deployment, so we can serve customers with different no-show policies without custom code. It also fixes a timezone bug that could have produced wrong arrival times in multi-region deployments, and moves the underlying framework to a long-term-support version — which lowers our maintenance risk. The main caveat is fit: this is a Symfony component, so it is a strong option for a Symfony/PHP service and a poor one inside our Laravel codebase. Recommendation: adopt only if the target service is Symfony-based and in the queue-management domain; otherwise treat it as a reference design, not a dependency.

For engineering (talking points):

• Upgrade driver: the unit-timezone parsing fix changes behaviour for scheduled appointment datetimes — verify existing appointment records and any reporting that assumed server-local parsing before rolling out.
• New surface: Appointment max delay config needs a config key, a default and validation; decide whether it is global, per-unit, or per-service, and document the precedence.
• Tooling: PHPStan 2 / PHPUnit 11 / PHPCS 4 raise the bar on our own contributions if we fork or submit patches; expect stricter static analysis locally.
• Deprecations: Symfony 7.4 deprecation clean-up means fewer surprises on the next major, but 7.1 is no longer the supported line — plan the 7.4 baseline across anything sharing the container.
• Risk: single-maintainer project; pin the version, keep a fork path open, and avoid letting this bundle own logic we would struggle to reimplement.

Suggested next step: timebox a spike that wires 2.3.0 into a non-production Symfony environment, replays a sample of real appointments across two timezones, and exercises the max-delay setting at its boundary values — then decide.