Block Library Laravel Package

Product Decisions This Supports

• Build vs. buy on commodity content blocks. Hero, features, pricing, FAQ, accordion, CTA, comparison, counter, divider, logos, stats, and content are solved problems in every marketing site we will ever ship. Adopting this package lets the team spend its scarce roadmap capacity on the two or three blocks that are genuinely differentiating — not on re-implementing a pricing table for the fourth time. That is the entire business case, and it's a good one.
• Feature scoping for "we need a page builder" requests. This package, plus Capell core, is a pre-built answer to that request. It turns an open-ended platform bet into a bounded evaluation: do the ~18 shipped blocks cover the content patterns our editors actually use? If yes, the roadmap item shifts from "build an authoring system" (quarters) to "configure an authoring system" (weeks).
• Content governance and accessibility as a product requirement, not an afterthought. The typed contracts here — BlockAccessibilityContractData, BlockContentContractData, PublicBlockPresentationData, BlockCompatibilityData, BlockScreenshotData — are the most strategically interesting part of the package. They give us a place to encode accessibility and presentation rules once, at the block level, instead of auditing every page. If accessibility or brand consistency is a committed roadmap goal, this is the lever that makes it enforceable rather than aspirational.
• Extensibility roadmap for custom blocks. RegisterBlockDefinitionProviderAction, ResolveBlockDefinitionAction, and ValidateDefaultBlockCatalogAction mean we can add our own blocks alongside the catalog without forking. That supports a phased roadmap: ship the catalog on day one, layer in proprietary blocks as they're justified.
• A deliberately reversible data decision. No migrations, no package-owned tables, no settings, no queues. Which means: no data-migration project to approve, no rollback plan to write for persisted content structure, and a genuinely cheap "try it in staging for two weeks and walk away" option. Low-stakes decisions should be made fast, and this qualifies.
• Vendor/concentration risk as a standing input. Zero stars, zero dependents, single-vendor, free-tier foundation bundle, and release notes that are changelog links with no described content. That doesn't kill the decision — it shapes it. The package is fine as a foundation we can replace, and a poor choice as a strategic dependency we build a moat on. Those are different product bets and should be recorded as such.

When to Consider This Package

Adopt when:

• The stack is already Laravel + Filament + Capell core. Outside that context this package has near-zero transferable value — it isn't a rendering library you can abstract behind your own interface, it's a slice of Capell's content architecture.
• The content model is conventional marketing/landing-page shaped: hero, social proof, pricing, FAQ. If our editors' real workload matches the shipped catalog, the fit is strong.
• We need composition capability on a near-term date and can't fund a from-scratch authoring layer.
• Accessibility or brand-consistency compliance is a committed goal — the contract data objects are worth more than the blocks themselves.
• We can accept the maintenance tax of reviewing undocumented releases (reconstructing intent from a diff, ~30–60 min per bump) as a named, resourced line item rather than an assumption.

Look elsewhere, or scope down, when:

• We are not on Capell/Filament. The integration cost becomes a rewrite.
• Our editors need block patterns outside the catalog and heavily custom ones. At that point we're building a catalog of our own inside someone else's framework, which is the worst of both worlds.
• The content model is genuinely bespoke (structured product data, regulated content, complex nesting) — a generic primitive library will fight us.
• We need vendor accountability: SLAs, documented semantic versioning, named support, or a security-response commitment. A 0-star, 0-dependent package with empty release notes cannot provide any of that, and no amount of internal process fixes it.
• The version pinning story is unacceptable to the platform team. Pinning to an exact patch is the right call given undocumented releases, but it means every security fix upstream becomes a manual, reviewed project. If nobody owns that, it doesn't happen.

Before committing, we need answers on: what actually changed across the recent patch releases (v1.0.47→v1.0.48 and back through ~30 releases with no described content), whether any of those touched block schema or rendered output, and what Capell/Filament/Laravel/PHP floors we'd be inheriting. Also worth flagging internally: the package metadata shows a last release date of 2026-10-28, which is in the future. That's almost certainly a manifest or pipeline artifact, but someone should confirm it isn't a sign that our release metadata isn't trustworthy — because a lot of the risk assessment here depends on trusting that metadata.

How to Pitch It (Stakeholders)

To the executive sponsor — one paragraph: We can ship content-composition capability in weeks instead of quarters by adopting a free, no-schema-impact package that already provides roughly eighteen standard content blocks with built-in accessibility and brand-consistency contracts. It requires no data migration and is reversible. The trade is a small, ongoing maintenance tax — roughly half an engineer-day per upstream release to review changes the vendor doesn't document — plus a dependency on a small single-vendor ecosystem. Recommendation: adopt it as a replaceable foundation, not as a platform differentiator, and fund the review process explicitly so it doesn't become invisible debt.

To engineering — the honest framing:

• Mechanically simple: composer require, provider registration, no migrations, no tables. Clear cached config/routes. Wire blocks into the Capell builder.
• The real work isn't installation, it's content governance: which blocks are enabled, who owns block templates, how block markup changes get validated before they reach production pages. That needs an owner on day one.
• Pin to an exact patch. The release notes are changelog links with no described content, so a caret range means absorbing unreviewed changes to stored content structure on a routine composer update. We accept manual upgrade toil in exchange for that control, and revisit once we see two or three consecutive releases with legible notes.
• Staging validation must include the editor experience — block insertion, reordering, save/republish — not just page rendering. Block-library regressions surface through the authoring UI first.
• Watch the authoring/public boundary: public Blade output and cached HTML must stay free of authoring markers, model IDs, permissions, and signed editor URLs. The package ships a health check and a block-library cache tag; use both.
• Known coupling points to verify up front: Capell core version constraints, Filament assumptions, and the PHP/Laravel floors in composer.json. A silent floor bump is the most common cause of a failed "routine" upgrade.

What we are explicitly not claiming: this package does not differentiate the product, it does not reduce our dependence on Capell, and it does not come with vendor support guarantees. It buys us time. What we do with that time is the actual bet.