Robots Extension Laravel Package

Technical Evaluation

Architecture fit. anomaly/robots-extension is not a general-purpose Laravel library — it is an addon for the Anomaly Labs Streams Platform (the PyroCMS lineage). It assumes a host application built on Streams' addon/module model, its service-provider registration conventions, and its admin UI layer. For a team already running a Streams-based CMS, it fits cleanly as a first-party-style extension. For a conventional Laravel application, "fitting" it means adopting an entire CMS platform to gain a robots.txt editor — a disproportionate architectural commitment.

Integration feasibility. Feasible and low-effort within the target ecosystem: composer require, register the provider, publish config/migrations, and manage rules through the admin panel. Outside that ecosystem, the integration cost curve is dominated by the platform dependency, not by this package. The functional surface is small (author and serve robots.txt), so the value is almost entirely in the admin UX and the hosting app's conventions.

Technical risk. High, driven by supply-chain signals rather than code complexity:

• Zero stars, zero dependents — no external validation, no evidence of production use, no downstream consumers to surface breakage.
• Ecosystem dormancy — the Streams Platform's release cadence has slowed materially; expect Laravel/PHP version pinning to older branches, which constrains upgrade paths for the host app.
• Public-facing blast radius — robots.txt governs crawler behavior. A bad edit can deindex a revenue-generating site; the risk profile is asymmetric relative to the package's apparent simplicity.
• Write/serve model unknown — whether it writes a static file into public/, serves dynamically via route, or stores rules in the DB determines caching, permissions, and multi-domain behavior. This is the single most important unknown.

Key questions.

1. Which Laravel, PHP, and Streams Platform versions are supported, and are composer constraints actively maintained?
2. Is robots.txt served statically from the filesystem, dynamically via a route, or virtualized — and how does that interact with web-server rewrite rules and CDN caching?
3. Is rule content validated/sanitized, or is raw text persisted and emitted verbatim?
4. Does it support multi-site/multi-domain and per-environment rules (staging Disallow: / vs production)?
5. Are sitemap directives and crawl-delay supported, or only allow/disallow?
6. What is the behavior on uninstall or disable — does a stale or missing file result?
7. Who owns content changes operationally — engineering or marketing/SEO?

Integration Approach

Stack fit. Green-light only for applications already committed to Anomaly/Streams. For vanilla Laravel, the correct decision is a thin in-house route or a maintained micro-package (spatie/laravel-robots and equivalents) — you get the same outcome with a fraction of the dependency surface and no CMS coupling.

Migration path. Assume adoption is additive, not a replacement:

1. Pin the host app's Laravel/PHP/Streams versions and confirm the package's constraints admit them.
2. composer require anomaly/robots-extension in an isolated branch; register the provider per Streams addon conventions.
3. Publish config and migrations; seed a conservative default ruleset equivalent to the current production file.
4. Reconcile route precedence against any existing public/robots.txt and web-server rewrites — confirm exactly one source of truth.
5. Diff generated output byte-for-byte against the incumbent file before cutover.

Compatibility. The binding constraint is the host platform, not this package. Verify PHP minor version, Laravel major, and Streams Platform tag together; a single mismatch typically manifests as a service-provider boot failure rather than a clean composer conflict. Test on the lowest and highest supported PHP versions if the matrix permits.

Sequencing.

1. Ecosystem commitment check — is the org staying on Streams for 12+ months? If no, stop.
2. Spike in a throwaway environment: install, author rules, verify serving path end-to-end.
3. Precedence and caching validation with the platform/DevOps owner (CDN TTL, nginx try_files, static vs dynamic).
4. Governance handoff — define who may edit rules and whether a review step is required.
5. Rollback rehearsal — restore the prior static file and disable the extension.

Operational Impact

Maintenance. You are effectively adopting a fork. With zero dependents there is no community patch stream and no signal when the platform breaks the extension. Budget for periodic manual review against Streams/Laravel releases, and treat the package as internal code you happen to have downloaded.

Support. MIT, community-only, no vendor SLA. Issue response on a zero-star repository should be assumed to be unbounded. Any production incident routes to your own team; plan for that in on-call expectations.

Scaling. Negligible runtime load — a robots.txt response is a few hundred bytes and is trivially cacheable. The scaling concern is organizational, not computational: multi-brand or multi-tenant deployments multiply the number of independently-editable public policy files, each a potential SEO incident.

Failure modes.

• 404 on robots.txt — crawlers broadly treat this as "allow all," silently inverting intent.
• Accidental Disallow: / — site removed from indexes; recovery takes weeks and is not guaranteed.
• Stale cache — CDN or opcache serving superseded rules after an urgent edit.
• Filesystem/permission errors if the extension writes into public/ under a restricted deploy user.
• Upgrade drift — Streams or Laravel bump breaks provider boot; admin UI disappears while the served file persists, creating config/state divergence.
• Environment leakage — staging rules promoted to production, or vice versa.
• Disable/uninstall residue — orphaned DB rows or a deleted file with no fallback.

Ramp-up. Low for engineers already fluent in Streams addon conventions (hours). Moderate for those new to the extension model (days). Non-engineering editors need guardrails before self-service: schema validation, a rendered preview showing exactly what crawlers will see, a diff against the live version, and ideally an approval gate — because the people with the strongest incentive to edit robots.txt (SEO/marketing) are the least equipped to assess the blast radius.

TPM recommendation. Opportunity score 33 suggests a real gap — CMS-native robots.txt governance — but this package is not a credible vehicle for closing it outside an existing Streams estate. Adopt only as an ecosystem-internal convenience with an explicit fork-ownership commitment; otherwise implement the capability in-house in under a day and keep the dependency graph clean.