Scribble Laravel Package

Product Decisions This Supports

• What "content authoring" actually means in our admin panel. This package is offered as a Filament form field for writing content inside Laravel admin panels. The decision it informs is narrow but real: do we invest in a richer in-panel editing experience (formatting, links, structured copy), or is a plain textarea plus Markdown preview good enough for the workflow we actually have? For an internal notes tool, an ops runbook, or a lightweight CMS, "good enough" is usually yes — and that decision should be made before a plugin is added, not after.
• Build vs. buy vs. use-what-the-framework-ships. Filament v3+ includes a maintained native rich-text editor that versions in lockstep with the framework. The genuine product question is not "does Scribble work?" but "is our editing need specific enough to justify adding a third-party field on top of a capability we already own?" Scribble is only defensible if it covers a gap the native field doesn't — toolbar profile, Markdown-first workflow, distraction-free authoring — and if we accept the lifecycle cost. Note also that the package's own materials describe an AI text-refinement field in one place and a Markdown editor in another; that ambiguity is itself a decision blocker and should be reconciled against the source before it reaches a roadmap or a budget line.
• Storage format as an exit-cost decision. If the field persists clean HTML into a longText column, swapping editors later is an afternoon of work. If it persists TipTap/ProseMirror JSON, every migration becomes a data-migration project across all rows. This is decided on the first save, and it determines whether adopting the plugin is cheap or expensive to undo. The PM call: mandate HTML-on-save via a model mutator, regardless of which editor we pick.
• Security ownership for user-authored markup. Rich text means persisted markup rendered back to users. With no upstream maintainer, there is no one to ship a stored-XSS fix. Sanitizing on write and on render is a product requirement, not a nice-to-have, and it needs to be assigned to a team — otherwise we are shipping an unowned attack surface inside an admin panel.
• Dependency governance as a standing gate. Archived repository, last release 2024-09-26, latest tag v0.8.1-alpha, 48 stars, 0 dependents, MIT. Zero dependents specifically means no community fork is queued to inherit maintenance. This is a clean test case for a "no archived or pre-1.0 dependencies in new roadmaps" rule, and a useful precedent to point at in future architecture reviews.
• Platform absorption risk as upgrade-planning input. Filament already ships the native editor and the ecosystem keeps absorbing plugin functionality. Any third-party form field we adopt depreciates when the host platform closes the gap. Useful for roadmap sequencing: prefer platform-native surfaces; reserve plugin bets for genuinely differentiating capability.
• Where AI-assisted writing sits, if at all. Multiple readings of this package's description reference AI text rewriting against an external service. That converts a form-field choice into a privacy, DPA, and vendor-review decision about what text can leave our systems, plus a metered per-call cost that scales with editor activity. Even if we don't adopt this package, that decision — "does AI polish belong inside our admin forms, and who pays for it?" — is one we own.

When to Consider This Package

Adoption criteria — all should hold:

• You are on an existing Filament admin panel and authoring happens there, not in a separate SPA, public form, or headless content service.
• The use case is internal and low-stakes: notes, docs, product descriptions, runbook pages — content where a degraded editor is an annoyance, not an outage.
• You have verified what the package actually is by reading src/, composer.json, and resources/ — and it matches a rich-text/Markdown form field, not a signature pad, blog generator, or AI service client.
• Your stack fits the package's composer.json constraints (Filament 3-era, Laravel 10, PHP 8.1+), and you are prepared to pin the exact alpha tag — never a caret range.
• You have a named owner and a review date for the dependency, plus a plan to remove it before your next Filament or Laravel major upgrade.
• You have decided storage is sanitized HTML, not editor JSON, and have mews/purifier (or equivalent) wired into the save path.
• If the AI-service interpretation is correct: a privacy/DPA review has cleared text egress for the specific fields involved, and there is a budget line for metered inference.

When to look elsewhere:

• You're on Filament v3+. Use the native RichEditor. It is maintained, versions with the framework, and carries none of the lifecycle cost. Adopt Scribble only with a documented gap.
• You need long-term support or a security response SLA. An archived alpha with zero dependents cannot provide either. There is no fork to adopt.
• The editor must sit inside complex dynamic layouts. Repeaters, wizard steps, and lazy-loaded tabs mount and unmount the DOM under Livewire; that is where rich-text canvases go blank and where you will spend your sprint.
• Rendering is public-facing. Stored-XSS risk with no upstream fix path, on content served to untrusted users, is the wrong trade.
• You need a roadmap commitment. A pre-1.0 archived package cannot anchor a multi-quarter content platform — it can only fill a gap for one release cycle.
• Filament's native editor is also on the same panel. Two TipTap/ProseMirror bundles produce divergent HTML output and cursor bugs that look like Livewire problems but aren't. Pick one editor per panel.

How to Pitch It (Stakeholders)

To executives: We evaluated a small open-source rich-text field for our Laravel admin panel. Recommendation is not to adopt it as a platform dependency. It is archived, pre-1.0, last released September 2024, and has no downstream users — meaning if it breaks, we fix it ourselves, permanently. The framework we already pay for ships an equivalent field that is maintained in step with the platform. If we proceed at all, it is for a single internal, low-stakes form, wrapped behind our own abstraction so removal is a one-file change, with HTML-only storage so exiting is cheap. The bigger takeaway is process: this became a good test of our dependency standard, and the standard held.

To engineering: Two things to agree before any code is written. First, confirm what this package is — its README, description, and release notes describe a rich-text field, an AI text service, and a Markdown editor in different places. Read src/ and composer.json; if the source doesn't match the rich-text interpretation, stop. Second, store sanitized HTML, never editor JSON, and put the field behind our own RichText factory class so swapping to Filament's native RichEditor is one file, not a content migration. Sanitize on write and on render with mews/purifier; there is no upstream to fix a stored-XSS bypass. Keep it out of Repeaters and Wizards until the Livewire mount/unmount cycle is explicitly tested. Pin the exact tag — 0.8.1-alpha, no caret. Register a named owner and a review date the day it merges.

To security and legal: The field persists user-authored markup that gets rendered back, and the project is archived with zero dependents, so there is no vendor to notify and no patch to expect. We are assuming full remediation ownership. If any reading of this package's AI-text descriptions turns out to be accurate, that also means user input leaving our environment to a third-party inference service — which requires a DPA review and a decision on permitted data classes before a single field is wired up.

To the business owner: If the goal is "our CMS/notes content looks better," the native editor gets us there at zero incremental cost and zero maintenance overhead. If the goal is something specific — Markdown-first authoring, a particular toolbar profile — that is a legitimate reason to consider a plugin, but it is worth stating out loud, because the alternative is adopting an unmaintained alpha to solve a problem we may not have.