Remote Prompt Laravel Package

Technical Evaluation

Architecture fit: remote-prompt fits Laravel/PHP teams that need a single CLI (rh) to execute commands against named remote targets (e.g., staging, production). It wraps common remote operations — rh put for file transfer and rh artisan for remote Artisan invocation — which aligns with existing Laravel deployment and operational workflows. The package is complementary to CI/CD rather than a replacement: it gives developers and agents a consistent interface for targeted remote actions.

Integration feasibility: Low-to-moderate. Adoption requires Composer installation, target configuration (hosts, credentials, environment labels), and team agreement on which targets are production. No application code changes are implied. Integration with scripts, CI jobs, and AI agents is now more feasible because v1.3.0 removes the non-TTY refusal for production writes and streams rh artisan output in real time.

Technical risk: The main risk is the deliberate relaxation of a production safety guardrail. Previously, production writes from a non-terminal context were refused; v1.3.0 allows them and relies on the caller — script or agent — to ask a human first. That is a policy control, not an enforced technical control. Risks include:

• An agent or automation invoking rh put or destructive rh artisan commands against production without human approval.
• False assumptions about TTY detection: a process may appear non-interactive even when a human is nearby, or vice versa.
• Streaming output changes buffering behavior; consumers that parsed complete output at exit may need review, though exit codes are preserved.
• Production prompts remain default-no in a terminal, and read-only Artisan commands still bypass prompts — the boundary between “read-only” and “write” must be trustworthy.

Key questions:

• How are targets classified as production, and can that classification be protected from local override?
• Does the package provide audit logging of who/what ran which command against production, especially in non-TTY mode?
• Is there an opt-in/opt-out setting to restore the prior non-TTY refusal for stricter environments?
• How does rh determine “read-only” Artisan commands, and can teams extend or restrict that allowlist?
• What authentication and authorization mechanisms protect remote targets (SSH keys, bastion, per-user credentials)?
• Are there Laravel/PHP version constraints or remote-shell assumptions that affect our stack?

Integration Approach

Stack fit: Strong for Laravel/PHP shops already using Artisan and Composer. rh artisan maps directly to existing operational commands (migrate, queue:restart, imports), and rh put supports targeted file deployment. The package should sit alongside CI/CD for ad-hoc and agent-driven operations, not replace controlled deployment pipelines.

Migration path: No prior assessment exists, so treat this as a new adoption. Start with a non-production target to validate connectivity, credentials, and command behavior. Then add production targets with read-only operations only (rh artisan prod ... read-only commands). Only after policy and audit expectations are agreed should production writes via rh put or mutating Artisan commands be enabled for scripts and agents.

Compatibility: v1.3.0 is a minor release with no stated breaking changes. The behavioral change is significant but backward-compatible for interactive terminal users: production still prompts with a red default-no confirmation. Non-TTY callers see changed behavior — commands that previously refused will now run. Any existing automation that depended on the refusal as a safety mechanism must be reviewed.

Sequencing:

1. Install and configure targets in a sandbox/non-production environment.
2. Validate rh artisan streaming output and exit-code propagation with long-running commands.
3. Define production policy: who may run writes, which commands require human approval, and how agents request approval.
4. Pilot production read-only commands.
5. Enable production writes for a limited group/agent, with audit logging or wrapper scripts that enforce approval.
6. Roll out more broadly after reviewing logs and incident-free operation.

Operational Impact

Maintenance: Low. The package is a CLI wrapper; ongoing maintenance is mainly keeping target configuration current, rotating credentials, and tracking upstream releases. The v1.3.0 changes do not appear to add new infrastructure dependencies.

Support: New support burden is policy-related, not technical. Teams must document that non-TTY production writes now execute and that the human-approval expectation is on the caller. Support runbooks should distinguish interactive terminal use (prompt remains) from script/agent use (no prompt). Users may be surprised by the removal of the “Refusing to …” behavior; communicate this explicitly.

Scaling: Good for scaling command execution across environments and automation. Streaming output improves observability for long imports and migrations started by scripts or agents. Scaling risk is organizational: more agents and scripts with production write access increase the need for identity, approval, and audit controls.

Failure modes:

• Agent executes a destructive production command without human approval because non-TTY mode no longer blocks it.
• TTY detection misclassifies an interactive session, causing an unexpected prompt or bypass.
• Streaming output interleaves with local logs; downstream parsers expecting buffered output may misread progress lines.
• Remote command exits non-zero but surrounding automation ignores the propagated exit code.
• Credential or target misconfiguration causes commands to run against the wrong environment, especially if production labeling is manual.

Ramp-up: Moderate. Developers familiar with Laravel Artisan will understand rh artisan quickly. The learning curve is in target configuration and production safety policy. Training should cover: the difference between terminal and non-terminal behavior, why --force on migrate is a Laravel flag and not an rh approval, how read-only commands are classified, and how scripts/agents must obtain human approval before production writes. A short internal runbook and a pilot with one team are sufficient before broader rollout.