Fusion Laravel Package

Product Decisions This Supports

• Build vs. buy for docs/content surfaces: fusion remains a markdown-driven content engine for Laravel apps, and v1.2.1 strengthens the case for adoption. v1.2.0 lowered setup cost to a single guided command (fusion:start, --dir); v1.2.1 adds a cache layer for parsed Markdown rows using Laravel's configured cache store, with a configurable FUSION_CACHE_TTL (default one hour). That moves the package from "good for internal/low-traffic docs" toward "viable for a customer-facing help center" without adding a SaaS vendor.
• Production-readiness as a roadmap gate: caching is the first release note that directly answers the "is this fast enough under real traffic" question. For a PM, treat this as the signal to re-run the spike with a load expectation attached, and decide based on measured response times rather than feature lists.
• Content quality as an engineering-owned gate: opt-in deep Markdown validation plus JSON output in fusion:check (and --include-valid for full listings) means content correctness can be enforced in CI the same way tests are. This is the difference between "docs we publish" and "docs we can regression-test." It supports a decision to treat documentation as a maintained artifact with a pass/fail gate, not a best-effort side project.
• Operational ownership decisions: caching introduces invalidation semantics we now own. FUSION_CACHE_TTL and the documented cache behavior/invalidation in the README make this tractable, but a PM should confirm who owns "content changed but the page is stale" as an incident class before committing to a customer-facing surface.
• CI/CD and platform fit: fusion:check-model now returns a failure status when a model is incompatible with Fusion, and without --model it lists classes discovered under app/Models; --dir allows scanning a custom model directory. Combined with JSON validation output, this makes the package pipeline-friendly and workable for apps with non-standard directory layouts.
• Dependency-risk accounting: the v1.2.0 replacement of the abandoned spatie/commonmark-highlighter with tempest/highlight still stands as a vendor-health positive; v1.2.1 continues the pattern of incremental, non-breaking maintenance rather than churn.
• Use cases to validate: internal engineering docs, customer-facing help center, release notes, spec/RFC repositories, and now—given caching and CI validation—any docs surface where content is authored in git and must be both fast and verifiably well-formed.

When to Consider This Package

Consider it when:

• Content is authored in markdown in the same repo as the application, and we want docs versioned and reviewed alongside code rather than in a separate CMS.
• We need a docs/help surface inside a Laravel app without standing up a static-site pipeline or a third-party SaaS (no extra auth, theming, or deploy target).
• Read performance matters and a cache-backed render path with a tunable TTL is sufficient; validate with our own content volume rather than assuming.
• We want content and model compatibility enforced in CI — deep Markdown validation with JSON output and non-zero exit codes on incompatible models make fusion:check / fusion:check-model usable as pipeline gates.
• We want fast evaluation: the interactive fusion:start command and --dir option let us point at an existing markdown corpus and see output the same day.
• Our stack is on, or moving to, Laravel 13 / PHP 8.4–8.5, and we don't want a dependency that pins us to older runtimes.
• Non-engineers are not the primary authors, or a git-based review flow is acceptable for the editorial team.

Look elsewhere when:

• You need a full CMS: WYSIWYG editing, roles/workflow, scheduling, media library, localization management, or non-technical authoring. Flat-file markdown will not satisfy those stakeholders, and retrofitting them is a re-platforming project.
• You need search, versioned docs trees, or i18n at scale as first-class product features—verify these exist before committing; don't assume. Nothing in v1.2.1 addresses these; caching and validation are orthogonal to them.
• Content must be served independently of the app (CDN-static, multi-app reuse), which favors a dedicated static-site generator or headless CMS. Note that a cache layer inside the app is not a substitute for edge delivery.
• Cache invalidation ownership is a poor fit for the team—e.g. a content team that edits frequently and expects immediate propagation, with no one accountable for staleness triage.
• You require a single-maintainer package to carry a business-critical, high-traffic surface. Even with healthy releases, that's a concentration risk worth pricing in.
• Rendering fidelity is a hard requirement (complex tables, diagrams, embedded interactive components)—audit the tempest/highlight swap against our existing code samples before rollout.

How to Pitch It (Stakeholders)

To executives: We evaluated a lightweight Laravel package that publishes markdown content—docs, help center, release notes—directly from our existing codebase, with no new SaaS contract or separate CMS. The latest release adds caching for rendered content with a configurable expiry, and turns content and model checks into things our build pipeline can pass or fail. Together with the previous release's one-command setup, that means faster pages, fewer broken docs reaching customers, and a lower cost to try. Recommendation: run a short, low-cost spike on one internal docs surface, measure response times and pipeline integration, and decide on broader adoption from that result—not from the package alone.

To engineering: v1.2.1 is additive with no indicated breaking changes. It caches parsed Markdown rows via Laravel's configured cache store with FUSION_CACHE_TTL (default one hour), and documents cache behavior and invalidation in the README. fusion:check gains opt-in deep Markdown validation, JSON output, concise reports, and --include-valid; fusion:check-model now exits non-zero on incompatible models, lists app/Models classes when --model is omitted, and accepts --dir for a custom model directory. Ask: run the spike against a real markdown corpus, wire fusion:check into CI, confirm the tempest/highlight rendering of our existing snippets, verify cache invalidation behaves as documented under our edits, and report back on gaps (search, i18n, non-technical authoring) that would force a different choice.