[scottcrawford03]

Why

Apps creation rejects MySQL persistence and drops the planned runtime profile before initialization. A partially initialized app also lacks a supported repair command.

What

Accept --persistence mysql for explicit fetch-js and process apps. Add bl apps initialize APP_ID to plan and repair an existing app without another reservation.

How

Preserve the planned runtime and persistence through reserve and initialize. Require MySQL plans to preserve the requested runtime and engine, and initialization responses to confirm MySQL. Retain server errors without falling back to SQLite. Recovery guidance names the selected runtime. Initialization rejects missing, deleted, or substituted identities.

Risk

Initialization can provision persistence or repair an existing stack, so it is an explicit command. Existing server admission still controls engine changes and availability.

Testing

A local build accepted MySQL creation and reserved the exact app. After a server connectivity fix, apps initialize recovered that same app and confirmed initialized: true and initialize.persistence: mysql. After the server mesh fix reached staging, an identical retry recovered the pending first deployment, and a notes app reached exact-version readiness. Its live POST returned 201 after a real MySQL INSERT and SELECT. Persistence across a later redeployment remains unverified. No new hosted fetch-js database test was run for this update; the release binary help was checked for both supported runtimes.

Generated with Codex

[nathan-thillairajah]

🤖 Looks good overall. All 82 Apps tests pass locally; just the README wording below.