Feature request: Durable deployment receipts and automation controls for the Base44 CLI

[Briver59]

The Base44 CLI provides a strong starting point for automated deployment, but external project-management and build systems need a durable, machine-readable control surface around it.

Use case

An external system coordinates an application build, authorizes a release, invokes the Base44 CLI, and then needs to verify exactly what happened before issuing the next unit of work. A synchronous success or failure response is not enough when deployments must be governed, auditable, recoverable, and safe to retry.

Requested minimum capability

1. Machine-readable JSON output from deployment commands with a documented, versioned schema.
2. A durable deployment_id or operation ID returned when a deployment is accepted.
3. A command or API for retrieving deployment status using that ID.
4. Terminal states such as succeeded, failed, and cancelled, with structured error information.
5. A durable deployment receipt containing:
   • deployment ID;
   • application ID;
   • submitted source/version identifier;
   • deployed version identifier;
   • timestamps;
   • initiating actor;
   • validation results;
   • final status.
6. A caller-supplied idempotency or correlation key so retrying after a timeout cannot create an unintended second deployment.
7. A supported rollback command that restores a known prior deployed version.

Useful follow-on capabilities

• Signed webhooks for deployment lifecycle events.
• A plan or dry-run command showing the proposed deployment changes.
• Deployment-scoped log retrieval.
• Cancellation before deployment reaches its irreversible stage.
• Stable error codes for automation.
• A way for an external control plane to associate test results, approval evidence, or release metadata with the deployment.

A possible CLI shape could be:

• base44 deploy --json --correlation-id <id>
• base44 deploy status <deployment_id> --json
• base44 deploy logs <deployment_id> --json
• base44 deploy rollback <deployment_id> --json

The most valuable first increment would be the durable deployment ID, JSON receipt, status lookup, and idempotency key. Those four capabilities would make the existing synchronous CLI substantially safer to use from CI and external build-control systems, even before webhooks and rollback are available.

Would this fit the CLI team’s direction? If related functionality is already planned, guidance on the intended automation pattern would be appreciated.

[Sidby140]