Botly Laravel Package

Technical Evaluation

Architecture fit. Botly is a thin, well-bounded insert into an existing Laravel application: a publishable config file, one migration for a persistent rules table, a Filament page that authors directives, and a renderer that emits robots.txt. There is no new runtime — no queue worker, no daemon, no external service, no second datastore. The architectural cost is one Composer dependency, one table, and one admin surface. The architectural value is that it converts a deploy-gated engineering artifact into a governed content object. That is the entire business case, and it holds only when Filament is already the admin stack. Without Filament you are buying a rules model and a string renderer and building the UI yourself, at which point build-versus-buy flips.

Integration feasibility. High and cheap to validate. The install path is standard Laravel: publish config, publish migrations, migrate, register the Filament page, reproduce the current static file as rules, diff the rendered output. A competent Laravel developer validates this on a canary environment in roughly half a day. v1.0.6 is a patch release with no API boundary change, so there is no migration work beyond the package's own table. The one non-trivial integration point is not install — it is precedence: what happens when both a committed robots.txt and the rules table exist, and which one the web server actually serves.

Technical risk. Three risks matter to a TPM, in order:

1. Blast radius versus friction. This package makes it easier to deindex a site. A low-friction UI over a high-consequence file is a governance risk before it is a technical one. Mitigation is organizational — a named approver for production rule edits, and the current static file retained as a rollback artifact.
2. Dependency posture. Six stars, zero dependents, one maintainer, external docs on docs.aw.codes, no deprecation policy or LTS. That is acceptable for an SEO convenience and unacceptable for anything contractual. Pin the tagged version and read diffs before bumping.
3. Metadata inconsistency. The repository tagline describes robots.txt management; the packaged description describes a bot-detection framework with fluent definitions, webhook handling, and conversation state. That was never reconciled after a pivot or template copy. Trust the release notes and the v1.0.6 changelog, not the description — confirm which artifact you are actually adopting before spending engineering time.

Secondary technical risks: request-time PHP rendering on every crawler hit (wrong default if generation cannot be written to disk), no evidenced multi-domain or multi-tenant support, and custom directives from config emitted verbatim, bypassing the v1.0.6 casing normalization.

Key questions to close before committing.

• Which Laravel, PHP, and Filament majors are supported, and is Filament a hard dependency or an optional integration?
• Is generation request-time, on-save, scheduled, or artisan-driven? Can it be written to disk from a deploy hook?
• When both a static file and the rules table exist, which wins — override, merge, or defer?
• What serves robots.txt if the database is unreachable? A 500 on that path is a real SEO incident.
• Are translations published at install, or will operators see raw keys as they did before the v1.0.6 notification fix?
• Does anything downstream (snapshot tests, CDN artifacts, committed files) diff on first regeneration due to the new Disallow / Allow / Crawl-delay / Clean-param casing?

Integration Approach

Stack fit. Adopt when Laravel + Filament is already the admin stack and non-engineers genuinely need to change crawler policy without a deploy. That is the strongest single signal — if every edit currently routes through a PR and a release train, the package pays for itself in latency alone. Deprioritize when you are not on Filament, when you need crawler analytics (log parsing, bot verification, crawl-budget reporting, sitemap generation — none of it is here), when you need multi-domain or per-tenant rendering, or when crawler policy is contractual and needs support guarantees.

Migration path. Treat this as a cutover, not an install:

1. Install on a canary/staging environment; publish config, migrations, translations; migrate.
2. Reproduce the existing committed robots.txt as rules — this is the acceptance test, not a formality.
3. Diff generated output against the current file byte-for-byte, accounting for the v1.0.6 casing normalization. Document every intentional difference.
4. Wire generation into the release script (artisan command or deploy hook) so output is written to disk rather than rendered per request.
5. Purge the edge/CDN cache for that path as an explicit pipeline step.
6. Retire the hand-maintained file only after one full release cycle runs clean. Keep it committed as rollback until then.

Compatibility. Low-risk on the Laravel side — no new runtime, no schema beyond the package's own migration. The compatibility surface that actually needs verification is Filament major version and the casing change in v1.0.6, which does not alter crawler behavior (directives are case-insensitive) but will diff committed files, snapshot tests, and CDN artifacts on first regeneration. Budget for that diff noise explicitly rather than discovering it during a release.

Sequencing. Config and migration → reproduce current file as rules → diff and sign off → deploy-pipeline generation → cache purge automation → grant non-engineer edit access with review → retire static file. The critical ordering constraint: do not open the UI to non-engineers before the diff, the pipeline generation step, and the cache purge all exist. The package's value is editing ergonomics; the guardrails must land first.

Operational Impact

Maintenance. Low ongoing engineering cost, higher-than-usual vendor-observation cost. The code surface is tiny and the dependency is pinned; the maintenance burden is watching a single-maintainer project whose recent release was mostly CI normalization onto shared fleet workflows plus Rector/PHPStan path alignment. That is healthy hygiene and a weak adoption signal simultaneously. Because documentation lives on an external hub (docs.aw.codes) and the README was trimmed to a landing page, onboarding cannot depend on a link — capture config keys, the generation command, the deploy hook, and the rollback procedure in an internal runbook.

Support. No support commitment, no LTS, no deprecation policy, zero dependents. Escalation path is "read the source" — which is feasible here given the size, but must be an accepted premise, not a surprise. Name an internal owner for the package even though it is third-party code.

Scaling. Three dimensions. Request volume: fine if generation is written to disk from a deploy hook; wrong if every crawler hit renders through PHP. Make disk generation a hard requirement, not a preference. Hosts and tenants: cost scales with hosts, and tenancy is not evidenced anywhere in the release notes. Retrofitting tenancy into a rules table is not a small change — evaluate the persistence model early, because that, not the UI, is the deciding factor for any multi-domain estate. Rule volume: robots.txt is a small file by design; if you find yourself authoring hundreds of rules, you likely want a different mechanism.

Failure modes. Rank by likelihood and impact:

• Human error via the UI — a mistyped directive hides the site from search. Highest likelihood, highest impact. Control: mandatory review for production edits and a named approver.
• Stale edge cache — rules changed in the admin but the CDN serves the old file, so nobody can tell whether the change took effect. Control: cache purge as an automated pipeline step, with an expected short delay communicated to stakeholders.
• Database unavailable — if generation is request-time, robots.txt returns 500 under DB pressure. Control: serve from disk; if you must render dynamically, define a static fallback.
• Static file versus rules table precedence ambiguity — the wrong artifact wins and edits appear to do nothing. Control: resolve and document precedence before cutover.
• Translation keys leaking to operators — the exact v1.0.6 bug class; verify translations are published and render in the admin locale.
• Dependency drift — an abandoned package or an unreviewed bump. Control: pinned version, diff review before upgrades.

Ramp-up. Two audiences. For engineering: half a day to install, reproduce the file, and diff; the residual effort is pipeline wiring for generation and purge. For SEO/marketing: near-zero tooling ramp-up — it is a Filament table with human-readable directive labels — but they need explicit training on the two constraints that will otherwise generate tickets: production rule changes go through a short review, and generated files behind the CDN need a purge before changes appear, so expect a short delay rather than an instant flip. Set that expectation up front.

Leverage summary for the roadmap. If a crawler-management epic exists, this package deletes the authoring slice — rule CRUD, directive rendering, AI-crawler toggles. It does not touch log analysis, bot verification, crawl-budget reporting, crawl simulation, or sitemap generation. Scope the epic correctly; over-scoping it because a package "does robots.txt" is the failure mode. Adopt as a deliberately small bet: reasonable for an SEO convenience, unreasonable for anything contractual.