Sillbeam Laravel Package

Technical Evaluation

Architecture fit. The first thing a TPM must flag: this is a Symfony bundle, not a Laravel package. The request frames the evaluation as Laravel/PHP, but Sillbeam targets Symfony 7.4/8.x with native autowiring, service attributes, controller routing, and DoctrineBundle integration. If the target codebase is Laravel, this package is not adoptable as-is — there is no announced Laravel bridge, and Symfony's container/route/config semantics (which Sillbeam deliberately preserves) do not map onto Laravel's service container. The realistic framing is: evaluate only if we have a Symfony surface, otherwise track it as a reference architecture rather than a dependency. For a Symfony shop, the fit is good — it is additive, opt-in per feature area, and does not replace the runtime.

Integration feasibility. Installation is a single Composer require (websign-dev/sillbeam:^0.1.0), with manual bundle + route registration if a Flex recipe is not published. That manual path is the main feasibility question: it means integration effort is not zero and is undocumented-by-default for our exact Symfony version. Doctrine entity mapping is optional, so teams without Doctrine can adopt incrementally. The two console commands (sillbeam:architecture, sillbeam:about) suggest the validation can be wired into CI, but the release notes do not confirm exit codes or machine-readable output — that must be verified before we treat it as a gate.

Technical risk.

• Pre-1.0 API instability — explicitly stated; public API may change. Treat every minor bump as potentially breaking.
• Narrow platform envelope — PHP 8.4+ and Symfony 7.4/8.x only. Both are recent; any team on PHP 8.2/8.3 or Symfony 6.x/7.0–7.3 is excluded. This is likely the binding constraint on adoption and should be checked against our runtime matrix first.
• Static analysis is not sound — the release notes concede dynamically resolved class references are not covered. Boundary violations via container lookups, service locators, or string class names will pass validation silently. Do not position this as a guarantee of module isolation.
• Projects are not tenancy — explicitly stated. Anyone reading "Projects compose shared and private modules across multiple application surfaces" as multi-tenant isolation is a misunderstanding waiting to happen; this needs to be pre-empted in any internal write-up.
• Vendor and bus-factor risk — single small vendor (websign-dev), v0.1.0, no visible adoption history in the notes. MIT license is favourable (no lock-in to fork), but the architecture layer is a load-bearing dependency: if it is abandoned, the module boundaries it enforces degrade into convention only.

Key questions.

1. Do we actually operate a Symfony 7.4/8.x + PHP 8.4 codebase, or is this a Laravel-only estate? This gates everything else.
2. What is the vendor's path and timeline to 1.0, and will breaking changes be signalled by semver minor/major under 0.x?
3. Does sillbeam:architecture return a non-zero exit code on violation, support JSON output, and run without a booted kernel? (Determines CI viability.)
4. What is the runtime/compile-time overhead of module-aware container compilation on a large app?
5. Who maintains it — team size, release cadence, issue responsiveness, security disclosure process?
6. Does the module boundary model conflict with our existing bundle boundaries, or can both coexist?

Integration Approach

Stack fit. Adopt only on Symfony services. The package's core value proposition — explicit module boundaries plus dependency validation — is most valuable in a codebase that has already drifted into a tangled bundle graph. If our app is small or already well-partitioned, the added indirection of Modules and Projects is overhead without payoff. Score fit as conditional-high for a degraded Symfony monolith, low for a clean one.

Migration path. Do not attempt a big-bang restructure. The credible path is a strangler-style carve-out: register the bundle, define a single Module around one cohesive feature area (ideally something with few inbound dependencies), run the architecture validator to baseline the current violation count, then expand module coverage release by release. Because Sillbeam preserves native Symfony services, routing, and configuration, code inside a Module keeps working unchanged — that is the property that makes incremental adoption safe, and it should be the explicit success criterion for the pilot. Use the validator's baseline report as the migration burndown metric.

Compatibility. Verify three things before committing: (a) PHP 8.4 and the exact Symfony minor we run; (b) whether a Flex recipe exists for our Flex version, since a missing recipe means manual bundles.php and routing edits that complicate rollback; (c) DoctrineBundle version compatibility if Doctrine mapping is used. Pin to an exact 0.1.x patch, not a caret range, and commit the lockfile — pre-1.0 caret ranges are unsafe here.

Sequencing.

1. Spike (days): one developer, throwaway branch, one Module, both console commands, measure compile time and validator behaviour. Confirm the Laravel-vs-Symfony question is settled first — this spike is wasted effort if we have no Symfony surface.
2. CI gate design: decide whether the validator is advisory or blocking. Advisory first; blocking only after the violation baseline is driven down and the exit-code behaviour is confirmed.
3. Pilot in one non-critical application surface for one or two release cycles. Instrument for compile-time regression and for developer friction in day-to-day work (adding a class now has a "which Module?" question attached — that is a real tax).
4. Internal guidance doc covering the Projects-are-not-tenancy caveat, the dynamic-reference blind spot, and the pre-1.0 upgrade policy.
5. Broader rollout only after 1.0 or after the vendor commits to a deprecation policy.

Operational Impact

Maintenance. Ongoing cost is mostly developer maintenance, not infrastructure: every new class needs to be filed into a Module, and module dependency declarations must be kept honest. Expect a modest but permanent tax on feature work, concentrated on onboarding and on cross-cutting changes. Version upgrades are the sharper risk — 0.x semantics mean a minor bump can break the architecture definitions themselves, so budget a review step per upgrade rather than treating it as routine dependency hygiene.

Support. Single small vendor. No SLA, no commercial support tier mentioned, MIT license means we can fork but also means we own the fork. Escalation path for a blocking bug is "open an issue." For a layer that constrains how the whole codebase is structured, that is thin. Mitigation: keep the module definitions thin and declarative so an exit to plain Symfony conventions (or a fork) is a bounded effort rather than a rewrite. Do not let Sillbeam-specific idioms leak into application code beyond the module manifests.

Scaling. Two axes. Organisational: the module boundary model is genuinely useful as team-ownership boundaries and scales well up to perhaps a few dozen modules; beyond that, Projects become the composition tool, and the "shared container" design means a Project cannot be independently deployed or isolated — scaling is horizontal only within one runtime. Technical: module-aware container compilation adds build-time work; measure it in the spike on the largest service definition set we have, since compile time is on the critical path for every deploy and every test run.

Failure modes.

• Silent boundary erosion — dynamic class references bypass static analysis; the architecture looks compliant while coupling grows. Detect via periodic manual review, not the tool alone.
• False confidence in Projects — misread as tenancy; would be a serious incident if anyone put customer data behind that assumption. Pre-empt in writing.
• Upgrade breakage — a 0.2.0 release redefines module semantics; the app still boots but boundaries are misdeclared. Pin and test.
• Tool abandonment — vendor stops shipping; validator bit-rots against a newer Symfony and gets removed from CI, at which point the boundaries are convention only. Have a stated fallback (PHPStan/Deptrac-style tooling) identified up front.
• Rollback difficulty — manual bundle registration plus module manifests means backing out is not a composer remove; it is a code restructure. Keep the pilot small enough to reverse cheaply.

Ramp-up. The mental model is learnable in a day for a Symfony developer — Modules, dependencies, optional Projects, two commands. The harder part is the cultural shift: teams must accept that the architecture checker constrains their design choices and that "just reference the other module's service directly" now requires justification. Plan a short internal walkthrough plus the guidance doc, and expect the first month of the pilot to generate the real body of "how we do it here" knowledge. Documentation lives on GitHub in the repo's docs/ tree alongside the source, which is adequate for v0.1.0 but is not a substitute for the internal conventions doc we will need to write ourselves.