Ghostwriter Core Laravel Package

Product Decisions This Supports

• Build vs. buy for the AI drafting layer — reassessed upward in scope (v1.10.0). The original case was provider abstraction, prompt versioning, and structured output. The package now also ships credential management (Connections), editorial QA with a verification pass (Suggest edits), content-freshness ranking (Content to revisit), and an SEO layer (internal links, meta title/description, slug/filename rules, heading normalization) across five languages. That is no longer "the engine under a feature" — it is most of an editorial-assist product. The estimate shifts from "build an adapter and a UI" to "build an adapter, a UI, and the operational wrappers," but the residual build is still far smaller than greenfield.
• Roadmap sequencing across surfaces is now evidenced, not just claimed. The release is explicitly the shared engine behind Ghostwriter 1.3 (Statamic and Craft) and Ghostwriter for Filament 1.2 — three adapters at near-identical versions. That materially de-risks the "one bet, three channels" thesis: there is a demonstrated pattern of porting, not a design aspiration.
• Tiering and monetization — the seam is now concrete. Two decisions fall out of this release. First, Connections resolves keys from env/config first (always wins), then an encrypted store, behind a CredentialStore port — which means both bring-your-own-key and platform-provided-key can be supported without forking. That is a packaging and margin decision, not an engineering one. Second, the split between free checks (no model, no request) and paid AI passes (review, verifier, seo-editor, seo-verifier) gives a natural free/paid boundary: instant deterministic linting and the revisit list as the free tier, model-backed review and SEO generation as the paid tier.
• Unit economics is now a first-class input. A single first draft can trigger an seo-editor call, an seo-verifier call, and a layout plan; an existing page can trigger a reviewer call plus one verifier call per part that kept anything (long pages split via ReviewInput::calls()). Caps exist (2–5 links, ~1 per 250 words, SEO reasons capped at 25 via Priority::SEO_CAP, 5,000 link rows per group / 20,000 per site), but per-action cost is now variable and multi-call. Pricing and quota design must be modelled against call counts, not drafts.
• A defensible trust promise we can choose to market. The two-pass design (reviewer proposes, verifier keeps/fixes/drops) plus in-code anchoring (QuoteFinder, ScopedEditCheck, SourceCheck, SentenceFit, SuggestionValidator) is the strongest product asset in this release: it supports a "no invented facts, every suggestion anchored to your text" claim that competitors rarely substantiate. Whether we advertise it is a deliberate positioning decision, not a default.
• SEO layer: separate SKU or bundled differentiator. Internal linking on every first draft, meta title/description only where the page already says it, and heading normalization are high-perceived-value, low-glamour features that customers notice. Decide whether this is a headline capability of v1 or a premium add-on. Note the safer sub-decision: "Suggest links" for existing pages writes nothing (SeoPass::suggestLinksFor() returns proposals), which is a good default to ship before any auto-apply behaviour.
• Scope discipline and default safety as a pattern to inherit. External link checking is off by default (RevisitOptions::$externalLinks), rate-limited (one request/second/host, 10s timeout, 500/run), and only flags broken after two consecutive failures. Reuse this pattern for any other outbound feature we build — it is a reasonable template for operational risk in the editor.
• Market reach is broader than assumed. Full string coverage in English, German, French, Dutch, and Spanish — including phrase and date parsing for the free checks — lines up with DACH/Benelux/France/Spain go-to-market. Cheap to leverage; worth validating AI output quality in non-English before we promise parity.
• Risk register — partially improved, core item unchanged. This release does not resolve the license (NOASSERTION), does not establish community adoption, and does not change the single-publisher concentration. It does show sustained, high-cadence development, which cuts both ways: less abandonment risk, more churn risk for a pinned fork. It also adds surface: encrypted credential storage (with us owning the KMS/key-rotation story, since CredentialStore is a port we implement), and outbound link probing. Legal and security scopes both grew.

When to Consider This Package

Consider it when:

• We are a PHP shop already shipping into Statamic, Filament, or Craft — and this release shows the adapters track a common engine at close versions, so a single port investment is credible.
• The requirement spans more than draft generation: credential setup UX, internal linking, SEO metadata, and editing QA are all in scope, and we would otherwise build or buy each separately.
• We want provider optionality and BYO-key support — the env-first-then-encrypted-store resolution is a genuine product feature, not plumbing.
• We sell into English, German, French, Dutch, or Spanish markets; localization is already carried.
• We are willing to vendor or fork it: pin a commit, own the test suite, accept maintenance. This is now a larger commitment than in the prior assessment because the surface is ~3–4x broader.
• A time-boxed spike (extended to ~4–5 days given the new surface) can answer the decisive question: are Connections\*, Suggest\*, Revisit\*, and Seo\* independently adoptable, or is it all-or-nothing?

Look elsewhere when:

• The license still cannot be resolved. NOASSERTION remains a hard stop; nothing in this release changes that.
• We need a vendor with an SLA, security disclosure process, or indemnification. Still none.
• We want a narrow capability. The overkill risk is now greater, not smaller: adopting this for "summarize this field" makes even less sense than before.
• We cannot own key custody. CredentialStore is a port — storing customers' provider keys encrypted, with rotation and audit, is our obligation, and a serious one.
• We need a hosted, multi-tenant service rather than an embeddable library. The link index (daily passes, 20,000-row-per-site caps) and revisit scanning are per-site batch jobs we would have to operate.
• Compliance requires data-residency or retention guarantees. Data flows now include: draft text to model providers, stored API keys, outbound link probes to third-party sites, and image/stock APIs. The package documents behaviour but not a compliance posture.
• The team cannot absorb a fast-moving dependency. Bus factor remains effectively one, and the changelog velocity means a pinned fork drifts quickly.

How to Pitch It (Stakeholders)

To executives (one paragraph): We are evaluating a PHP library that supplies the engine for AI-assisted editing — provider abstraction, structured drafting, credential setup, an editorial review-and-verify pipeline, content-freshness ranking, and an SEO layer covering internal links and search metadata — so our team builds the integrations and the interface, not the engine. Its latest release (v1.10.0) is the same engine behind three shipped admin surfaces (Statamic, Craft, Filament), which supports a one-investment, three-segment thesis, and it adds a free deterministic tier alongside the paid AI tier, which we can use to shape packaging. The offset is unchanged and now larger in surface area: no community adoption, unclear license, single maintainer, and new obligations around storing customer API keys. Recommendation: approve a scoped technical spike on one surface plus a parallel legal and security review; do not commit roadmap until both clear.

To engineering (short): Framework-free PHP core with explicit ports — CredentialStore, RevisitStore, EntrySource, LinkIndexContract, LinkProbe, SeoWriter, ChecksKeys — most of which we must implement. The new value is concentrated in three places worth reading closely: the review/verify loop (Studio::suggestEdits() → Studio::verifyEdits(), with QuoteFinder/ScopedEditCheck/SourceCheck anchoring every suggestion to real text), the SEO pass ordering (SeoPass::afterWriter() runs before the layout planner so every layout carries links), and Connections env-first key resolution. Note the cost profile: reviewer plus one verifier call per kept part, seo-editor plus seo-verifier per draft — instrument call counts before we quote a price. Expect to read the whole source; there is still no external usage to learn from, and the surface is now much larger than when we first scoped it. First spike question: what is independently adoptable?

To finance/legal (short): License remains NOASSERTION — read as "unknown," not "permissive"; no shipment until provenance and terms are confirmed in writing. Scope has widened on two fronts. Security: the package defines an encrypted credential store for customer provider keys; we would own encryption, rotation, and audit. Outbound traffic: opt-in external link checking (rate-limited, 500/run), model-provider calls for drafting, review, verification, and SEO, plus stock-photo APIs with attribution terms. Budget for a data-flow and key-custody review, not just a license check.

Bottom line: the strategic fit improved and the dependency got heavier. Evaluate as an acquisition-of-code on a narrow pilot — free checks plus suggest-edits on one surface — and treat the SEO layer and Connections as separately justified phases, not part of the initial commitment.