Conversation Laravel Package

Product Decisions This Supports

• Build vs. buy for a PHP content platform. Pushword is an MIT-licensed Symfony CMS, so the baseline decision it informs is whether to adopt a batteries-included CMS on the Symfony stack or build a bespoke content/admin layer. It removes the need to build an admin, media handling, page model, and templating from scratch.
• Roadmap bets on AI-native authoring. The monorepo is explicitly designed for agent workflows: commands detect an agent and emit single-line JSON (AgentOutputTrait, --format agent|text), AGENTS.md ships to downstream sites at vendor/pushword/docs/AGENTS.md, and rendering is deliberately byte-deterministic so AI edits produce reproducible diffs. A conversation package fits the "agent talks to the CMS" direction; committing to it is a bet that conversational/AI-assisted content ops is a differentiator rather than a gimmick.
• Git-as-CMS vs. database-as-CMS content strategy. The package positions content as maintainable "from the admin, from Git, or from your AI agent." If the roadmap includes content-as-code, PR-based editorial review, or static publishing, this supports choosing that model instead of a purely DB-backed editorial workflow.
• Static-first delivery decisions. The docs call out a static build with skip-unchanged and a cross-deploy Markdown fragment cache (var/cache/pushword-pools), plus a content-hash cache that only works if renders are deterministic. That is a concrete signal to prioritize static/edge delivery and byte-stable output over dynamic rendering.
• Extension/plugin strategy. It is a monorepo of Symfony bundles (core + extensions) with discovery via a docs extension registry, plus an EditorJsToolProviderInterface seam tagged into the container. This informs whether the product invests in a bundle-based extension ecosystem (PHP-native) versus a hosted plugin API.
• Feature scoping for the admin experience. EasyAdmin + EditorJS, with documented constraints (e.g., header buttons must live in {% block page_actions %}, tools registered at build time, Monaco loaded on demand). Useful for sizing admin/editor features realistically rather than estimating a generic rich-text editor.
• Operational model for upgrades. No migrations — doctrine:schema:update --force, one upgrade note per release under packages/docs/content/upgrade/. That pushes a decision on whether the team can absorb "read the upgrade note every release" as a standing cost.

When to Consider This Package

Consider it when:

• The team is already on PHP/Symfony and wants a CMS it can extend in PHP rather than integrate over HTTP.
• Content must be editable from the admin, from Git, and/or by an AI agent — the package is built around that three-way workflow.
• Deterministic static builds matter (documentation sites, content marketing, docs-as-code), since byte-reproducible renders are a stated invariant.
• You need a small, self-hosted footprint (SQLite by default; PostgreSQL/MariaDB via Doctrine) and want to avoid SaaS CMS lock-in.
• You value strong quality gates — composer stan, rector, phpunit, deprecation budgets, and an enforced post-change review — as a proxy for maintainability.

Look elsewhere when:

• The stack is not PHP/Symfony; the value proposition collapses without that runtime.
• You need a large plugin marketplace, hiring pool, or enterprise SLA. With ~30 stars and 0 dependents, ecosystem proof is essentially absent — this is an early-adopter bet, not a de-risked default.
• Your DBAs require versioned migrations. doctrine:schema:update --force is fine for greenfield and dev, but it is a governance gap for regulated or multi-environment production estates.
• You need multi-tenant, complex editorial workflows, or heavy localization ops out of the box; those are not evidenced here.
• You cannot absorb shared-repo operational discipline: shared git index across parallel agents, scoped --only commits, cache-version bumps (MarkdownParser::CACHE_VERSION, SplitContent::TOC_CACHE_VERSION) whenever rendered output changes.

Caveat to resolve before committing: the supplied evidence is monorepo-level (agents/AGENTS.md, rules, quality gates). Package-level docs for pushword/conversation were not provided, so scope its actual API surface (packages/conversation/src/, tests/) before treating it as a roadmap dependency. The "last release 2026-10-30" and low composite score (~20/100, opportunity ~29/100) suggest active development but thin external validation.

How to Pitch It (Stakeholders)

For executives (one paragraph): Pushword is an MIT-licensed Symfony CMS that lets one small team run content sites the way engineers run code — edited in an admin, committed from Git, or authored by an AI agent — and published as fast, deterministic static output. There is no license cost and no SaaS lock-in, and the repo has strong automated quality gates. The trade-off is maturity: it has a small community (~30 stars, no known dependents), so we should treat adoption as a time-boxed pilot with a defined exit path rather than a platform-wide replacement.

For engineering:

• Stack fit: Symfony bundles in a monorepo, PHP 8, Doctrine; SQLite by default, Postgres/MariaDB supported.
• Integration seam: bundle-based extensions plus tagged provider interfaces (e.g., pushword.editorjs_tool_provider); admin is EasyAdmin + EditorJS with documented pitfalls, so budget for those rather than discovering them.
• Operational contract: no migrations (schema:update --force), cache clearing after changes, cache-version bumps for rendered output, and a strict scoped-commit workflow — cheap to follow, expensive to retrofit.
• AI-readiness is a first-class feature, not an afterthought: agent-detected output, shipped AGENTS.md, deterministic renders. That is the strongest reason to choose it over a generic CMS.

Ask: approve a bounded pilot (one content surface, one static target) with success criteria on authoring speed, build determinism, and upgrade effort per release; revisit the build-vs-buy call after one upgrade cycle.