Scribble Laravel Package

Technical Evaluation

Architecture fit. Scribble is a form-field plugin for Filament admin panels — a Field subclass that mounts a client-side editor into a Livewire-rendered form schema. That is a narrow, well-understood extension point, not a framework, a service, or shared infrastructure. Blast radius is small: it touches one form component on one page class at a time, and it removes as cleanly as it is added. The catch is that the package's identity is unresolved across its own artifacts — the repository title says "rich text editor," the description text references an "AI text-refinement service," prior internal evaluations describe a signature pad and a file-based Markdown blog, and the only release note is about Faker-generated links in tests. Those are four different products with four different risk profiles. The first TPM action is not evaluation, it is reconciliation: have an engineer confirm what src/, composer.json, and resources/ actually contain before this enters a roadmap, a vendor registry, or a budget line. Everything downstream assumes the rich-text-editor interpretation; if that is wrong, stop.

Integration feasibility. Mechanically low. composer require, publish config and assets, register on the panel provider if required, add the field to a schema. A day for a Filament-fluent engineer to reach a working round-trip. The cost is not install, it is the constraint check: composer resolution against a current Laravel/Filament/PHP stack is where archived packages fail first. Pin the exact tag (0.8.1-alpha), never a caret range — there is no later patch to float to. Beyond that, feasibility hinges on two engineering decisions that are TPM-relevant because they set exit cost: (1) persist HTML, not TipTap/ProseMirror JSON, so a future field swap is a class change rather than a content migration; (2) wrap the field in our own factory class so the eventual replacement is one file, not a grep across every resource.

Technical risk.

• Lifecycle risk (high). Archived, alpha-tagged, last release 2024-09-26, 48 stars, 0 dependents. Zero dependents is the operative number: no community fork is waiting to inherit maintenance, no downstream is motivated to patch. There is no Filament v4 tracking and no upstream fix for any defect we find.
• Security risk (high, and ours). A rich-text field persists markup that is later rendered with {!! !!}. With no upstream, the bypass-fix pipeline does not exist. Server-side sanitization on write (mews/purifier or equivalent) and on render becomes a hard requirement, not a best practice. Any legacy rows written before the sanitizer must be back-filled.
• Platform-absorption risk (high). Filament ships a native RichEditor. The honest question is not "does Scribble work" but "what specific gap does it cover that the maintained, in-lockstep native field does not?" If the answer is not crisp and written down, the correct decision is to use the native field.
• Integration-surface risk (medium). Compiled JS asset, Livewire mount/unmount lifecycle, CSP interaction. These are exactly the seams that break on Livewire minors and asset-pipeline changes, with no upstream to absorb the break.

Key questions to answer before approval.

1. What does the source actually implement, and does that match the use case we have in mind? (Resolve the four-product identity problem first.)
2. What capability does Scribble provide that Filament's native RichEditor does not, stated in one sentence?
3. What does the field write to form state on dehydrate — HTML string or ProseMirror JSON? This is the exit-cost decision.
4. Who is the named internal owner, and what is the scheduled review date? An archived dependency without an owner is a finding.
5. If the "AI rewrite" reading of the description is correct, has a privacy/DPA review cleared text egress to a third-party service? (If it's the rich-text reading, this question evaporates — another reason to resolve identity first.)

Integration Approach

Stack fit. Laravel 10-era, PHP 8.1+, Filament 3-era. If the panel is current Filament v3+, the package is plausibly in-range but must be constraint-checked before install. If the panel is Filament v4, treat it as incompatible until proven otherwise: there is no v4-tracking release and no upstream to ship one.

Migration path. Assume from day one that this is transient. The migration path is engineered in, not improvised later:

• Field factory. Define an internal RichText field class that returns a configured Scribble::make() today and a RichEditor::make() (or whatever we choose later) tomorrow. Every resource depends on the factory, not the package.
• Storage contract. Persist sanitized HTML in a text/longText column, enforced by a model mutator. Do not persist TipTap JSON. This is the single decision that turns exit from a content migration into an afternoon.
• Render contract. Sanitize on render in Blade as a belt-and-braces measure.

Compatibility. Three checkpoints, all before first commit:

• composer.json constraints against the target app (Filament, Laravel, PHP, Livewire).
• Asset publishing actually resolves and the compiled bundle is served — toolbar-only failures are almost always unpublished assets or a CSP block.
• No second TipTap/ProseMirror bundle already on the panel. Two divergent editor bundles on one page produce selection and cursor bugs that present as Livewire issues and are not.

Sequencing. Shadow first, promote second, remove on a schedule.

1. Day 1 — reconcile identity. Engineer reads src/, composer.json, resources/. Document what the package actually is. If it does not match the intended use case, stop here.
2. Day 2–3 — install and round-trip on the least critical resource. Internal notes, an ops runbook page, an internal announcement PostResource. Create, edit, save, reload, render with sanitization on.
3. Week 2 — factory extraction and sanitizer. Move the field behind the internal factory; add the model mutator; verify stored content is clean HTML.
4. Release cycle — soak. Let it survive one Livewire minor and one Filament patch without breaking the editor. That is the practical ceiling of confidence available for an archived alpha.
5. Scheduled exit. Remove before the next Filament or Laravel major upgrade — never during one. Exit is a class swap plus a purifier pass plus composer remove plus deleting published config/assets/registration.

Operational Impact

Maintenance. We own it. Archived, alpha, zero dependents, no upstream fix pipeline. This is not a maintenance risk, it is a maintenance line item: budget for reading the source when it breaks, because there is no release note coming. Register it in the dependency inventory with a named owner and a review date on the same day it is added — "archived dependency with no owner" is a finding.

Support. None. There is no maintainer to escalate to, and no downstream consumer community to lean on. Internal support is whatever the named owner plus the wider team knows, and that knowledge needs to live in the internal field factory and the storage contract — not in tribal memory or in the package's README, which is itself unreliable.

Scaling. Two distinct axes, only one of which matters here:

• Editor scale. Per-field, per-page. The field's cost is dominated by the client-side editor bundle, not by backend throughput. For an internal admin tool this is negligible.
• Content scale. The longText column and the sanitization pass. The sanitizer runs on every write; if content volume grows, it is a known, bounded cost. The larger scaling concern is breadth: every resource that adopts Scribble widens the surface that must be migrated when we exit. Confine adoption to a small, enumerated set of resources.

Failure modes. In rough order of likelihood:

• Editor renders blank or toolbar-less after a Livewire or asset-pipeline change — almost always an unpublished asset or a CSP block. Diagnosable in minutes if the owner knows to look there, expensive if they don't.
• Duplicate TipTap bundle producing selection/cursor bugs that masquerade as Livewire problems.
• Composer resolution break on the next Laravel or Filament bump — the most likely trigger for the exit decision, and the reason exit is scheduled before major upgrades, not during.
• Stored-XSS from unsanitized content, including any legacy rows written before the sanitizer was added. This is the failure that has no upstream to blame and a real security incident behind it.
• Silent behavior change if anyone unpins the version. Version pinning is a hard rule, not a preference.

Ramp-up. Low for engineers already fluent in Filament — the field is idiomatic. The ramp-up that matters is organizational: engineering standards need an explicit line ("no archived or pre-1.0 dependencies for new form fields") so the next developer does not rediscover this package and re-litigate the same decision. The TPM deliverable is not a code review, it is a documented decision — adopt or reject — with the rationale, the owner, the review date, and the scheduled exit attached. For an archived 48-star zero-dependent plugin, the default answer is reject and use the native RichEditor; adoption requires a specific, written justification that survives that default.