Kai Personalize Laravel Package

Product Decisions This Supports

• Self-service operations as a product capability. The new Tools tab turns three previously shell-only maintenance tasks into a permission-gated browser workflow. This supports roadmap decisions around reducing support dependency for customers on shared hosting, managed WordPress-style environments, or customer-managed Laravel deployments where SSH and cron access are limited or prohibited.
• Build vs. buy for admin maintenance surfaces. If your roadmap includes an internal “run maintenance task” feature, this package provides a reference implementation of the safer pattern: allowlisted slugs, server-side command definitions, fixed arguments, permission checks, and confirmation on destructive actions. That is a meaningful build-vs-buy input — adopting or adapting this is likely cheaper and safer than building an ad-hoc command runner.
• Support-cost and operational-burden reduction. Each maintenance action exposed in-product removes a class of “please run this command for me” tickets. This supports prioritization of admin/ops features that are unglamorous but directly reduce support load and time-to-resolution.
• Data retention and compliance use cases. kai:cleanup --days=30 with a fixed retention window supports GDPR/CCPA-style retention policies and routine data hygiene. The decision to hard-code --days=30 rather than accept a browser-supplied value is a product choice worth preserving: predictable retention beats flexible-but-dangerous input.
• Security requirements for any future admin-command feature. The release demonstrates concrete requirements a PM can carry into other roadmap items: no client-supplied command strings, no client-supplied arguments, permission gating (Manage Settings), confirmation for destructive operations, and forced/non-interactive execution where a console prompt cannot be answered. These are reusable acceptance criteria.
• Roadmap candidates surfaced by this release. Natural follow-ons include audit logging of who ran which maintenance action and when, dry-run/preview output, scheduled execution, finer-grained permissions than a single Manage Settings gate, and redaction or structured display of command output. None are promised by this release, but each is a plausible next bet if the Tools tab sees usage.
• Use cases: SaaS admin panels, agency-managed client sites, on-prem/self-hosted Laravel products, and any deployment where the person responsible for retention/cache hygiene is not the person with shell access.

When to Consider This Package

Consider adoption when:

• You run a Laravel application that already has (or needs) a Settings area and a permission model, and you want maintenance operations available to authorized non-engineers.
• Your deployment reality includes shared hosting, restricted shell access, or customer-managed environments where “just SSH in and run it” is not a viable support model.
• The three shipped operations — fingerprint cleanup, cache refresh, and retention cleanup — map to real operational needs in your product (data hygiene, performance recovery, privacy retention).
• You want a constrained, allowlisted command runner rather than a general-purpose terminal in the browser. The design here is deliberately narrow, and that is the point.
• You can accept a single coarse permission (Manage Settings) for these actions, or you are prepared to wrap/extend it if you need finer roles.

Look elsewhere or proceed with caution when:

• You need arbitrary command execution from the UI. This package intentionally does not provide that, and treating it as a limitation rather than a feature is a recipe for unsafe extensions.
• You already have mature deployment automation, schedulers, observability, and on-call runbooks. The marginal value is lower, and the added admin surface may not be justified.
• You require audit trails, per-action permissions, approval workflows, or multi-tenant isolation for maintenance actions. These are not described in this release and should be validated against the codebase before committing.
• Command output may contain sensitive data. The release states output is shown “as-is,” so review what these commands can print before exposing the tab broadly.
• The package’s core domain (fingerprinting/cleanup) is irrelevant to your product; adopting it solely for the Tools tab would be over-scoped.
• You have not assessed maintenance cadence, Laravel version support, test coverage, or security posture. This release note describes one feature, not the overall health of the package.

How to Pitch It (Stakeholders)

For executives: This release converts three routine maintenance operations from shell-only tasks into a permission-controlled browser workflow. The business value is reduced support load and faster resolution for customers who cannot or should not have server access, plus a more defensible retention story because cleanup runs with a fixed, predictable window. It also reduces the temptation to grant broad server access just to perform routine hygiene. It is not a replacement for deployment automation or a general remote-admin tool, and the scope is intentionally limited to three named operations.

For engineering: The implementation is the interesting part. The browser submits a short slug, never a command string; arguments live in the server-side definition, so a caller cannot substitute --all for the 30-day cleanup or otherwise widen a destructive operation. Access is gated on the Manage Settings permission, the two data-deleting actions require confirmation, kai:cleanup is invoked with --force because a console prompt cannot be answered from the browser, and output is returned unmodified. This is a sound pattern for any future admin-triggered job: allowlist, server-owned arguments, authorization check, explicit confirmation, non-interactive execution. Before broad rollout, confirm test coverage for the authorization and argument-binding paths, review what the commands can emit in their output, and decide whether audit logging is needed.

For product/ops stakeholders: This is a self-service enabler, not a new product surface. The near-term questions are whether usage justifies follow-on investment in audit logs, dry-run previews, and granular permissions, and whether the single Manage Settings gate is acceptable for your customer base or needs to be split before the tab is exposed beyond internal users.