Ruwork Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow — still resolved to "borrow patterns, not code." ruwork/ruwork-bundle is a wiring/meta-bundle for Ruwork components (historically a Symfony bundle, published as ruvents/ruwork-bundle). The 0.2.0 release does not create a buy case; it strengthens the reading case slightly and the dependency case not at all.
• Framework fit check on the roadmap — unchanged. The prompt frames this as a Laravel/PHP package; it is not. It follows Symfony DI/configuration conventions. Any roadmap item premised on dropping this into a Laravel service provider model remains mis-scoped and should be killed early.
• Vendor-risk triage for legacy estates — now with a pin-and-hold caveat. The genuinely useful decision it informs: if you inherit a Symfony 3.x/4.x-era application whose composer.json already references Ruwork components, this bundle documents how they were intended to be registered. New in 0.2.0: the redesigned @Redirect is a behavioural change inside a 0.x line, so an unpinned ^0.1 constraint may now resolve to a version with different annotation/redirect semantics. Treat the upgrade path as a decision you must actively make, not one that happens on composer update.
• Dependency policy reinforcement. Zero stars, zero dependents, archived, and — prior to this release — no publish since 2018-07-17. A single 0.2.0 release with a two-line changelog does not reset that signal; it confirms the project is pre-1.0 and unstable rather than maintained. Use it as the canonical "unmaintained / no release cadence" case in the ADR.
• Reference for bundle architecture — marginally improved. If your team is authoring an internal Symfony bundle (service registration, extension classes, config tree), the repo is a small MIT-licensed teaching artifact readable in an afternoon. 0.2.0's refactor is worth a skim to see what the author considered cleanup, but it is not a reason to depend on the code.

When to Consider This Package

Consider (narrowly):

• You are maintaining a legacy Symfony application that already depends on Ruwork components and you need to understand or temporarily preserve the service wiring during an extraction — and you have pinned the bundle version, because 0.2.0 redesigns @Redirect and is not a drop-in for 0.1.x behaviour.
• You want a read-only reference implementation of Symfony bundle conventions and are comfortable treating GitHub as a textbook.
• You need a legally unambiguous pattern source: MIT means you can copy idioms into your own code with attribution, without taking a dependency.

Look elsewhere (default):

• Any new project. The 0.2.0 release does not supply what was missing: no visible security-response path, no stated PHP 8+ compatibility, no Composer 2 / Symfony 5+ guarantees, no support commitment. A 0.x version with a two-bullet changelog is not a maintenance signal.
• Any Laravel application — wrong framework, full stop.
• Any scenario requiring support, SLAs, CVE turnaround, or an upgrade path. There is still no published maintainer escalation route, and a "Redesigned @Redirect" delivered inside a minor bump indicates API churn without a deprecation policy.
• Any case where a first-party Symfony recipe or a maintained bundle covers the same ground. The opportunity score of 5.87 reflects category attractiveness (bundles are useful), not the health of this artifact; its composite score of 0 still governs.
• Anywhere your team would need to own a fork. Forking is cheap under MIT but you inherit indefinite maintenance for zero differentiated value — and now also the obligation to reconcile 0.2.0's refactor.

Adoption criteria, stated plainly: only adopt if (a) it is already in the lockfile, (b) you have a dated plan to remove it, and (c) no maintained alternative exists for the specific component you need. Failing all three, do not adopt. Add a fourth operating rule after 0.2.0: pin exact versions and read the diff before any bump — do not accept a floating constraint on a pre-1.0, archived package.

How to Pitch It (Stakeholders)

For executives (one paragraph): We re-reviewed ruwork/ruwork-bundle after a new 0.2.0 release and our recommendation is unchanged: no-go for any new or existing product surface. The release is a refactor plus a redesign of one annotation, shipped inside a minor version on a package that remains archived, has zero stars, zero downstream dependents, and had no publish for roughly seven years before this. That is not evidence of revived maintenance — it is evidence of a pre-1.0 codebase still changing its API without a documented upgrade path, security process, or modern PHP/Symfony compatibility statement. The license is permissive (MIT), so there is no legal exposure and no cost to ignoring it; the only cost would be adoption, plus the upgrade risk if a floating constraint silently resolves to 0.2.0 in a legacy service. Net: no spend, no integration, no risk added — and one new action item to pin versions where it already exists.

For engineering (the ask): Treat this as reference material, not a library. If it appears in a legacy composer.json, flag it in the tech-debt register with a removal ticket, pin the exact version before your next dependency update, and capture whatever wiring logic you need into our own bundle before deleting it. Review the @Redirect redesign if you currently rely on that annotation — it is a behaviour change, not a patch. Do not introduce it into new services, and do not plan around it for Laravel work — it is a Symfony bundle and the framing is a mismatch. If someone wants the DI/configuration patterns, copy them under MIT attribution rather than pulling the package.

The one-line decision: Reject as a dependency; retain as a reading reference; pin if already present.