Triage Bundle Laravel Package

Technical Evaluation

Architecture fit. novosga/triage-bundle is a Symfony bundle, not a Laravel package — a critical distinction for this evaluation. It ships no Laravel service provider, no publishable config, no facades, and no Laravel-native test harness. It is a domain module for appointment/triage scheduling inside the Novosga queue-management ecosystem (Symfony full-stack). Fit is therefore strong only if our target is a Symfony 7.x application or the Novosga platform itself; fit for a Laravel codebase is poor-to-moderate and requires an explicit bridge or service-boundary decision.

Integration feasibility. v2.3.0 is a low-drama, additive minor release under semver. Two items carry real integration weight:

1. Symfony 7.1 → 7.4 LTS (PR #7) plus deprecation cleanup (PR #9). This is a maintenance-positive signal — 7.1 is out of support, 7.4 is the LTS line. It does, however, hard-pin our host application to the Symfony 7.x / PHP 8.2+ track and removes any lingering compatibility with Symfony 6.x consumers. Anyone still on 6.4 LTS cannot take this release.
2. Appointment max delay config (PR #10) is a genuine capability addition, not a chore. It introduces a new configuration surface governing scheduling/delay tolerance. Additive features in a 2.x minor should default to current behavior, but that default must be verified before rollout.

The timezone fix (PR #6, "use unit timezone when parsing scheduled appointment datetime") is the sleeper. It is labeled a bug fix but changes how appointment datetimes are interpreted for units whose timezone differs from the server default. That is a data-correctness improvement with user-visible consequences: previously mis-parsed appointments may now render at different times. Treat it as a behavior change requiring regression coverage, not a routine patch.

Technical risk. Moderate-low on code quality, moderate on governance. Dev-tool modernization (PHPStan 2, PHPUnit 11, PHPCS 4 — PR #8) indicates active static analysis and a real test suite, which is reassuring. Against that: single-maintainer project (@rogeriolino authored every change in this release), small PR volume (single-digit PR numbers), and a dependency on the upstream Novosga release cadence. There is no vendor SLA, no security policy evident in the notes, and no LTS commitment for the bundle itself.

Key questions.

• Is our host application Symfony 7.x, Laravel, or neither? If Laravel, is the intended pattern an HTTP/service boundary rather than in-process consumption?
• What is the default value of the new max-delay setting, and does it reproduce v2.2.1 behavior exactly?
• Which units are configured with a timezone differing from the server default, and are their existing appointments affected by PR #6?
• Who owns the Novosga upstream relationship if the maintainer goes dormant?
• What is our PHP floor today, and are any services still on 8.1?

Integration Approach

Stack fit. Green-light for a Symfony 7.4 / PHP 8.2+ host or for deployments already inside the Novosga platform. For Laravel, do not attempt in-process integration via bundle registration hacks; either (a) isolate triage scheduling behind a thin HTTP/queue contract and run the bundle in its native Symfony context, or (b) reimplement the appointment-delay and timezone semantics in Laravel-native code and accept the divergence cost. Option (a) is the lower-risk TPM recommendation: it preserves upstream upgrade paths and keeps the bundle's assumptions intact.

Migration path. Sequence in three gates.

1. Pin and audit. Pin to v2.3.0, read the diff for PRs #6 and #10 specifically, and confirm the max-delay default. Do not float on ^2.3.
2. Framework uplift. Land Symfony 7.4 LTS and PHP 8.2+ on the host before or with the bundle bump. Resolve deprecation notices surfaced by PR #9 in the same change window so we do not accumulate a second cleanup backlog.
3. Behavioral verification. Build a timezone matrix test — at minimum one unit per distinct timezone in production — asserting scheduled datetimes before and after the fix. Where the fix corrects previously wrong data, decide explicitly whether to backfill, display-only correct, or grandfather historical records.

Compatibility. Confirm no transitive constraint pins Symfony <7.4 elsewhere in the tree; the LTS bump is the most likely source of resolver conflicts. Confirm PHPUnit 11 does not conflict with the host's own test tooling if we run the bundle's suite in CI. Note that Symfony 7.x has no 6.x bridge — this release effectively closes the door on dual-version support.

Sequencing. Config/feature adoption (max delay) should trail the framework and timezone work by at least one release cycle. Ship the bug fix and the LTS upgrade as a correctness-and-hygiene release; ship the new max-delay configuration as a separately gated, product-owned rollout with its own default-value decision and stakeholder sign-off.

Operational Impact

Maintenance. Light. The bundle is small, the release is mostly chores plus one feature, and the move to Symfony 7.4 LTS reduces near-term upgrade pressure — we should be able to sit on this line for the LTS window. The dev-tool refresh (PHPStan 2, PHPUnit 11) means our CI can adopt current static-analysis and test-runner versions without shims. Budget ongoing effort mainly for tracking the single maintainer's releases, not for patching.

Support. This is the weak point. One maintainer, no visible support contract, no published security-response process. Operationalize by: vendoring or mirroring the repository, keeping a fork-ready posture, and assigning a named internal owner for the dependency. Treat it as a community dependency with a documented fallback, not a vendor-supported component.

Scaling. The scheduling/triage domain is low-throughput relative to queue transactions; the new max-delay check is a configuration comparison, not a heavy query, and should not alter scaling characteristics. The realistic scaling concern is timezone correctness at multi-site scale: more units across more timezones increases the blast radius of any parsing defect. The PR #6 fix improves this; the test matrix must grow with site count.

Failure modes.

• Silent timezone drift — appointments parsed under server timezone instead of unit timezone; patients arrive at wrong times. Highest-severity, lowest-visibility failure in this package. Mitigate with per-unit assertions and monitoring on schedule-vs-checkin deltas.
• Config default regression — if the max-delay default is not behavior-preserving, existing scheduling rules tighten or loosen without an explicit decision. Verify before deploy.
• Dependency-resolution break — Symfony 7.4 LTS colliding with other pinned constraints; surfaces at build time, fails loudly, low risk.
• Upstream abandonment — no new releases means no security patches; slow-burn, mitigated by fork readiness.
• Laravel mis-integration — if someone attempts bundle registration in a Laravel app, expect subtle container and config-loading failures. Prevent by architecture, not by review.

Ramp-up. Low for a Symfony-fluent engineer: small surface, conventional bundle layout, clear domain. The real ramp cost is domain literacy — triage priority, appointment delay policy, and per-unit timezone semantics — which is product knowledge, not framework knowledge. Plan a half-day for a Symfony developer to read the bundle, and a full sprint of pairing with the scheduling/product owner before anyone is trusted to change max-delay policy. If the team is Laravel-only, add meaningful ramp for Symfony fundamentals plus the service-boundary pattern, and expect the first integration to take materially longer than the bundle's size suggests.