Manual Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for an in-app help center. This package is a concrete, readable reference for the cheapest credible build: a help-article model (title, slug, body, category, publish state), Markdown rendering, admin CRUD, and a public read route. It anchors the estimate at days, not weeks — which reframes the real decision from "which knowledge base vendor?" to "do we actually need editorial workflow, search, and versioning, or is a small first-party module enough?"
• Scoping the MVP boundary. The package is most useful for what it omits: no full-text search, no drafts/scheduling, no i18n, no per-release versioning, no author permissions, no article analytics. Each of those becoming a real requirement is a signal to move from "small internal build" toward "buy," and the PM can use that list as the buy-trigger checklist.
• Validating the content ownership model. Markdown-backed articles assume non-engineers (CS, docs, PM) can publish without a deploy. That's an organizational commitment — who owns help content, what the review path is, whether CS gets write access to production content — that the package quietly assumes but does not enforce. Surfacing it early prevents a shipped feature nobody is staffed to maintain.
• Defining success metrics before committing. An in-app help module is justified by ticket deflection and time-to-first-value, not by code volume. This package implies the measurement plan: deflection rate on the top N articles, help-article views per session, support-ticket volume trend post-launch. If those metrics can't be instrumented, the feature shouldn't be prioritized.
• Roadmap sequencing and non-decisions. It supports an explicit, documented non-decision: do not adopt as a dependency. The repo is a Symfony 2 bundle (not Laravel, not modern Symfony), archived, 3 stars, zero dependents, EOL framework generation. It informs the design and the estimate; it does not enter the dependency tree. Recording that in an ADR stops the team from re-litigating it.
• Use cases it maps to: in-product contextual help, CS-authored FAQ/onboarding guides, internal handbooks and runbooks (the internal case is often the fastest to justify — low risk, immediate time savings, no customer-facing XSS surface if content is trusted).

When to Consider This Package

Consider it only as a read-only reference — a spec to read, not a package to install:

• You need to sanity-check your own schema (article body as raw Markdown, slug, category/order, publish state) before writing migrations.
• You want to see a minimal authoring flow that lets non-engineers publish without deploys, to validate the UX shape with CS before building.
• You're maintaining a legacy Symfony 2.x application already on the Opifer stack and need a throwaway internal help module — and even then, fork it into a private repo rather than depending on an archived remote.
• You need a sandbox proof-of-concept for Markdown authoring, with no production exposure.

Look elsewhere — decisively — when any of these hold:

• You're on Laravel. The brief labels this Laravel/PHP; it is not. It targets Symfony 2 bundle registration, the DI container, Symfony routing, and Twig. Framework mismatch is disqualifying; "just composer require it" is wrong and will likely fail resolution against modern symfony/* constraints and PHP 8.x.
• You need a support or security path. Archived, zero dependents, 3 stars means you are the sole maintainer. There is no CVE response channel, and the bundled Markdown renderer is old — a stored-XSS surface if article content is ever user-editable.
• Procurement or compliance reviews third-party code. An abandoned EOL-framework bundle will not clear a dependency audit; proposing it costs more political capital than the feature is worth.
• Real help-system table stakes are required: search, drafts and scheduling, localization, per-version docs, author permissions, view analytics. None are in scope.

The Laravel equivalent is a small first-party module: a help_articles table, league/commonmark with safe mode for rendering, an admin resource (Filament/Nova) or a Blade admin, and a public route — or a hosted knowledge base if editorial workflow and search genuinely matter.

How to Pitch It (Stakeholders)

To executives: There's an open-source package that implements almost exactly the in-app help center we've discussed — Markdown articles that CS can edit without engineering involvement, embedded in the product. It's MIT-licensed and small, but it's built for a framework we don't use, hasn't been maintained since 2019, and has effectively no user base (3 stars, zero dependents). My recommendation is not to adopt it, and instead treat it as a template: the same capability is a small, low-risk internal build we fully control, with no dependency or security exposure. Decision needed: fund a scoped build (roughly a sprint-or-less slice) only if we see evidence users want in-product help — otherwise park it behind higher-priority roadmap items. Either way, the analysis has already de-risked the estimate, so this decision is cheap to make now.

To engineering: Use it as a design reference, not a dependency. The valuable parts are the data shape (Markdown body, slug, category, publish state) and the authoring flow that lets CS publish without deploys. The parts to deliberately exceed: a maintained Markdown parser with sanitization (league/commonmark safe mode), explicit draft/publish states, and access control on the admin surface. Installing the package itself is not viable — Symfony 2 is EOL, the repo is archived, and there is no one to patch a CVE. Budget roughly a week to reimplement on our stack; the render-parity check on real articles is the go/no-go gate.

Framing to use consistently: low cost, low urgency, high maintenance risk if adopted; near-zero risk if reimplemented. The package's real contribution is confidence in the estimate, not code we ship.