Page Scanner Laravel Package

Product Decisions This Supports

• Buy vs. build for page QA / scanning. A scanner that ships inside the CMS rather than as a separate SaaS turns SEO/content-quality checks into a property of the authoring loop. The decision this supports: do we license a standalone scanning service, or make scanning a first-class step of publish? The monorepo's own conventions (event names in PushwordEvents.php, tagged provider interfaces) suggest QA hooks are meant to be extension points, not bolt-ons — so a "scan as part of publish" bet is architecturally coherent here.
• Agent-first DX as a roadmap line, not a marketing line. The repo documents a real mechanism: AgentOutputTrait plus a --format auto|agent|text option on commands, with a maintained list in docs/content/agent-output.md. That is evidence a machine-readable CLI is a designed surface. It justifies funding "every command has a stable machine output" as a roadmap commitment with an acceptance test, rather than a demo.
• Determinism as a cost lever. The documented rule that renders must be byte-deterministic because the static build skips unchanged pages (and cache version constants gate the fragment pool) is a hosting/CDN cost decision, not just a code rule. It supports choosing static export + incremental deploys over always-rebuild pipelines for content-heavy sites.
• Low-ops positioning. SQLite by default with Postgres/MariaDB via Doctrine, and schema changes applied with doctrine:schema:update --force instead of migrations. This supports a "small team, single site, low infrastructure" product posture — and rules out a multi-tenant or regulated-environment posture without investment.
• Docs-as-growth-model. One Markdown file per topic under packages/docs/content/, slugs tied to paths, redirects tracked in redirection.csv, and an upgrade note required in the same commit as any change that asks something of an upgrading site. That is a self-serve onboarding strategy encoded in process; it supports a product-led growth motion over sales-led, and makes docs completeness a release gate you can actually check.
• Discovery before roadmap, on the scanner itself. The supplied description ("A Symfony CMS to rapidly create, manage and maintain your websites…") describes the platform, not page-scanner. No feature list, rule set, or output format for the scanner is present. That argues for a time-boxed spike before any roadmap commitment — this assessment can ground platform-level decisions, not scanner-level ones.

When to Consider This Package

Consider it when:

• The team is a PHP/Symfony shop already, and the site is a content site where scanning belongs next to authoring rather than in a separate tool.
• MIT licensing and a small dependency surface matter more than a vendor SLA.
• You want an agent-facing CLI out of the box and are willing to keep it stable yourself.
• You can live with SQLite or a single relational DB and are comfortable with schema-push rather than managed migrations.
• A spike is enough to answer "does the scan output match our quality bar?" — i.e., you need the capability, not a supported product.

Look elsewhere when:

• You are a Laravel team. This is a Symfony CMS monorepo of bundles, not a Laravel package; nothing in the supplied material documents a Laravel service provider or framework-agnostic entry point. Integration cost is unbounded until proven, so budget a spike or skip.
• You need the scanner as a standalone library. There is no evidence of a boundary that lets you call the scanner outside a Pushword site. If your decision is "scan arbitrary URLs from our own app," this is the wrong shape.
• You need semver stability, LTS windows, or a migration path. No-migration schema updates and a fast-moving monorepo are fine for one team, disqualifying for audited change control.
• Ecosystem depth is a hiring or risk argument. 30 stars and 0 dependents means no third-party plugins, no Stack Overflow corpus, no bench of contractors. Treat it as single-maintainer risk.
• Release cadence is a procurement requirement. The listed last release (2026-10-30) is future-dated relative to normal intake data; verify the actual cadence and open-issue posture before pinning a version into a plan.

How to Pitch It (Stakeholders)

For executives (one minute). This is an MIT-licensed PHP/Symfony content platform with a page-scanning component, small and self-hostable. The strategic value is not the scanner feature — it is the pattern: quality checks run inside the publish flow, and every admin command emits machine-readable output so AI agents and CI can drive the CMS. That is a credible differentiator if our roadmap is "content operations for small teams with automation," and it is irrelevant if our roadmap is "enterprise CMS." The cost side is real: 30 stars, zero dependents, no migration tooling, and a Laravel-shaped gap if our stack isn't Symfony. Recommendation: a two-week spike, not an adoption decision. Success criteria: the scanner's output format is usable in our publish gate, and the CLI's --format agent output is stable enough to script against.

For engineering (what you'd actually own). You inherit a monorepo of Symfony bundles with strong internal conventions: composer stan|rector|test as gates, cache clearing after every change, version constants that must be bumped whenever rendered output changes, and a hard rule that no entropy (random()) may enter a render path. Those rules exist because the static build skips unchanged pages — violate them and you get silent full rebuilds or stale content. There is also a documented requirement to add an upgrade note in the same commit as any change that asks something of an upgrading site. Budget for that discipline; it is the price of the determinism guarantee, and it is not optional overhead you can defer.

The ask. Approve a scoped spike: run the CMS in the dev app, exercise the page-scan path on ten representative pages, and confirm (a) scan findings are actionable, (b) the agent-format output is parseable, (c) the no-migration schema story is acceptable for our environments. If any of the three fails, we stop at spike cost rather than platform cost.