Puter Deployer

# Puter Deployer

Use a strict flow: preflight → build/stage → deploy path selection → verify → rollback note.

1) Preflight (always)

Run:

```bash bash skills/puter-deployer/scripts/preflight.sh <project_dir> <build_dir> ```

• This checks:
• `puter` CLI exists
• `puter whoami` works
• build directory exists and is non-empty
• `index.html` exists

If any check fails, stop and report exact fix commands.

2) Deployment path selection

Choose one path explicitly:

1. Create new Puter app entry (CLI-supported):
2. - `puter app:create <name> <remoteDir> --description "..." --url "..."`
3. Update/publish build content:
4. - Use Puter API fallback guidance in `references/api-fallback.md`.
5. - If API details are unclear for this host/version, inspect active `puter-cli` source behavior before pushing.

Important: current public `puter-cli` command surface is limited. Do not invent non-existent commands.

3) Verify deployment (always)

Run:

```bash bash skills/puter-deployer/scripts/verify_url.sh <url> [expected_snippet] ```

• Require:
• HTTP 200
• expected snippet present (if provided)

If verification fails, mark deployment unsuccessful.

4) Rollback note (always)

• Return these fields in final report:
• source commit
• previous known-good artifact path
• previous known-good URL
• exact rollback command/runbook

Use `scripts/deploy_report_template.md` as output skeleton.

Guardrails

• Never print auth tokens.
• Never delete remote app/site without explicit user request.
• Require explicit confirmation before overwriting production targets.
• On failure, classify into one bucket:
• 1) auth/session
• 2) missing build artifact
• 3) wrong app/site target
• 4) platform/API error

References

• `references/deploy-checklist.md` — end-to-end checklist
• `references/api-fallback.md` — API-first fallback logic when CLI is insufficient
• `references/failure-playbook.md` — common failure signatures + fixes