Manual Bundle Laravel Package

Technical Evaluation

Architecture fit. opifer/manual-bundle is a Symfony 2 bundle, not a Laravel package — this is the first thing a TPM must correct in the brief. It depends on Symfony's bundle registration, DI container, routing YAML, Doctrine entities, and Twig views. In a Laravel codebase its out-of-the-box architectural fit is zero. Its durable value is the pattern: a Markdown-backed article store (title, slug, body, category/order, timestamps) with public list/detail routes and an admin CRUD surface. That pattern is portable and cheap to reimplement; the code is not.

Integration feasibility. Low. Three hard blockers: (1) framework-generation mismatch (Symfony 2 reached EOL in 2019; the bundle will not resolve against modern symfony/* or PHP 8.x constraints); (2) the repository is archived — no fixes, no security response; (3) 3 stars, 0 dependents means no real-world validation; we would be the first serious consumer. composer require into a Laravel app is not a realistic path; anything resembling adoption is a port, and a port is a rewrite.

Technical risk. High on every axis that matters to delivery: EOL framework, no maintainer, no trustworthy test corpus, and an old bundled Markdown renderer — a stored-XSS surface if help content is ever author-editable. The dependency-resolution risk alone typically surfaces during an unrelated upgrade, at the worst possible time.

Key questions to resolve before committing any effort:

• Is the target genuinely Laravel (or modern Symfony)? If yes, the decision is "reference only" and this evaluation is closed.
• Is there existing content in this bundle's schema that must be preserved? That determines whether a one-off export is in scope.
• Do we need authenticated authoring (admin CRUD) or read-only public help? This changes build cost by roughly an order of magnitude.
• Who owns help content post-launch — engineering, CS, or docs? That is an org decision the package assumes but does not enforce.
• Is there any reason to prefer this over a ~1-week internal build on supported framework primitives?

TPM recommendation. Score 0.0075 and archived status are accurate signals. Do not adopt as a dependency. Fund a small first-party module instead, and treat the bundle as a design reference that de-risks the estimate.

Integration Approach

Stack fit. Poor as a dependency, useful as a spec. The portable contract is small: an article model (slug, title, Markdown body, category/order, publish state, timestamps), a render-at-read pipeline, public read routes, and an admin authoring surface — all first-class in Laravel (Eloquent + league/commonmark + Filament/Nova/Blade).

Migration path (reimplement, don't install):

1. Content extraction — if articles exist in this schema, export to neutral JSON/Markdown first. This is the only step touching legacy code and the real migration risk; do it early with row-count and sample-diff verification.
2. Schema parity — mirror fields in Eloquent + migration; keep body as raw Markdown and render at read time so formatting fixes never require a data migration.
3. Render parity — replace the bundle's renderer with a maintained one in safe mode with HTML sanitization, plus golden-file tests comparing old vs new HTML on a sample of real articles. This is the go/no-go gate.
4. Admin authoring — rebuild on existing admin tooling; do not port Twig CRUD. Most of the build estimate lives here.
5. Public routes/views — straightforward; use the bundle's routes as a contract test.
6. Cutover, then delete the legacy dependency entirely.

Compatibility. Only plausible if the target is a genuine Symfony 2 app — and even then, fork into a private repo and vendor it rather than depending on an archived remote. For Laravel/modern Symfony, compatibility is a non-starter; do not spend discovery time proving it.

Sequencing. Content export → schema → render-parity gate → admin authoring → public routes → cutover → remove legacy. Scope the whole slice as roughly one sprint-or-less; the estimate is now credible because the reference implementation confirms the shape.

Operational Impact

Maintenance. The dominant cost of adoption is ownership, not code. Archived + 0 dependents means every defect, PHP bump, and CVE is ours, forever. A reimplementation is less long-term maintenance because it sits on supported primitives and inherits our CI, linting, and dependency-update bots. Budget the migration once; avoid a permanent orphan-dependency tax.

Support. No upstream channel, no maintainer response path for security disclosure. That is unacceptable for anything rendering production content, given Markdown → HTML is a known XSS vector.

Scaling. Workload is trivial — a low-read article table. Cache rendered HTML at the CDN/edge and scaling is a non-issue. The real scaling risk is organizational: as more teams add help content, an unmaintained component becomes an increasing liability and a blocker on framework upgrades.

Failure modes to design against:

• Dependency-resolution failure on upgrade (most likely; surfaces at the worst time).
• Unpatched Markdown renderer → stored XSS in help content.
• Silent render divergence during migration (tables, code fences, links) — mitigated by golden-file parity tests.
• Content loss during export — mitigate with row counts and sample diffs.
• Bus factor of one on the legacy schema — mitigate with documented schema and tests.

Ramp-up. Low for the reimplementation (days for a competent Laravel engineer, given a well-known pattern). Low-but-risky for direct adoption, because a new engineer will reasonably assume the code is maintained when it is not. Record the "reference only, do not install" decision in an ADR so it isn't re-litigated.

Bottom line for stakeholders. The package's contribution is confidence in the build estimate and a validated data shape — not code we ship. Fund the small internal build only if we see evidence users want in-product help; otherwise park it behind higher-priority roadmap items and keep the ADR.