Remote Prompt Laravel Package

Product Decisions This Supports

• Build vs. buy for deployment/ops tooling. rh (remote-prompt) covers a narrow but real slice of the deploy workflow — pushing individual files to a remote environment and running artisan there — with environment-scoped targeting and a production safety prompt. That is enough to defer investing in a bespoke deploy script for small Laravel estates, and enough to justify not adopting a heavier platform (Envoy, Deployer, Forge, full CI/CD pipeline) on day one.
• Whether to invest in agent/script-driven operations. v1.3.0 is explicitly an automation-enablement release: production put and rh artisan no longer refuse to run when there is no TTY, and artisan output now streams live instead of buffering to the end. This directly unblocks two roadmap items: (a) CI/scripted release steps, and (b) AI-agent-assisted maintenance tasks (migrations, imports, one-off fixes) where a long-running command needs visible progress and a trustworthy exit code.
• Safety-model and governance policy. This is the most consequential product decision the release surfaces. Previously the tool itself was the hard gate: no terminal → no production write. Now the gate is advisory and contextual — interactive terminals still get a red, default-no prompt, read-only artisan commands still skip it, but non-interactive callers run unrestricted. Any team that treated "the tool refuses without a human at a keyboard" as a control must now decide where the compensating control lives (CI approval gates, scoped deploy credentials, branch protection, audit logging, per-environment service accounts).
• Environment topology and release-model choices. The env abstraction (prod vs. non-prod) is a product-shaped decision lever: it encourages a small, named set of environments and makes the prod/non-prod distinction first-class rather than tribal knowledge in runbooks.
• Use cases it makes tractable: hotfixing a single model/controller on prod without a full redeploy; running one-off migrations or imports against a target environment; seeding/backfilling data; agent- or script-driven maintenance windows; onboarding engineers onto a consistent "how do I touch prod" path.
• Roadmap signal to watch: the release notes frame the human-approval expectation as belonging to the caller ("is expected to ask its person first"). That is a documented non-guarantee. If agent-driven ops is on the roadmap, plan for an approval/audit layer above this tool rather than assuming the tool provides it.

When to Consider This Package

Consider adopting when:

• You run one or a few Laravel apps with a small number of named environments (prod/staging/local) and already reach those boxes over SSH.
• Your pain is surgical remote operations — push one changed file, run one artisan command — not full release orchestration.
• You want a CLI-first, low-ceremony tool that individual engineers and agents can invoke without learning a DSL or provisioning a platform account.
• You intend to script or agent-drive operations and value: non-blocking execution without a TTY, streamed output for progress visibility, and pass-through exit codes for reliable failure detection.
• You are comfortable owning the production-approval control outside the tool (CI approval steps, restricted credentials, review process).

Look elsewhere when:

• You need atomic, zero-downtime releases, symlinked current/previous directories, or one-command rollback — this is not a release orchestrator.
• You operate a multi-server fleet, load balancers, or blue/green — no fleet coordination here.
• You require enforced, tamper-proof audit trails or RBAC as a compliance obligation (SOC 2, regulated environments). v1.3.0 moves the guardrail from enforcement to convention in non-interactive contexts; if your control framework depends on the tool refusing, this is a mismatch without a compensating layer.
• You need a declarative, version-controlled pipeline definition (Envoy/Deployer/GitHub Actions) rather than imperative commands.
• Your stack is not Laravel/PHP, or your team is Windows-terminal-centric.
• You want vendor-supported SLAs; this is a single-maintainer OSS package.

Specific note on upgrading to v1.3.0: the behavioral change is a loosening of a safety default. Teams that relied on the previous TTY refusal as a production control should treat this as a policy change requiring sign-off, not a routine minor-version bump — and should review their CI/agent credentials before rolling it out.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a lightweight open-source Laravel ops CLI that lets engineers push a single file or run an artisan command against a named environment — including production — without standing up a deployment platform. The new v1.3.0 release makes it usable from scripts and AI agents: production commands now run without an interactive terminal, and long-running commands stream their output live with a reliable exit code. That is a meaningful capability unlock for automating hotfixes, migrations, and maintenance tasks, at effectively zero licensing cost. The trade-off is that the tool's built-in production safeguard is now a speed bump for humans rather than an enforced control — so the go/no-go is less about the tool and more about whether we put an approval and audit step in front of it. Recommendation: adopt for narrow, scripted ops tasks with a compensating approval gate; do not treat it as our release/deployment platform.

For engineering leads: v1.3.0 removes the TTY requirement for production put and rh artisan, so CI jobs and agents can drive these directly. Interactive terminals still get a red, default-no prompt; read-only artisan commands still run unprompted. Output now streams instead of buffering, and exit codes pass through unchanged — both are what you need for progress-visible, failure-detectable automation. Two asks before we roll this out: (1) decide and document where the human-approval decision now lives for non-interactive prod runs — the release notes explicitly push that responsibility to the caller; (2) give automated callers their own scoped credentials so "runs without a prompt" doesn't mean "runs as a human admin." Also treat this as a security-relevant minor bump, not a patch — review it before it lands in any pipeline that touches prod.