Repair or rebuild a local environment
A local environment can become inconsistent across generated files, credentials, service readiness and application registration. Wildo provides an initialization journey that reconciles those layers while preserving backing-service data.
When an empty start is intentional, framework developers can use a separate rebuild command to remove local data before running that journey. Rebuilding is not restoring a backup.
Example — Keep records while repairing configuration
After a framework update, a developer wants current runtime configuration without losing local test records. wildo local init performs the non-destructive initialization path; clearing the databases requires an explicit different command.
For engineers
| Command | Who can use it | Intended result |
|---|---|---|
wildo local init | Application creators and framework developers | Reconcile initialization and preserve backing-service data |
wildo local init --register-only | Both audiences, with a healthy existing platform | Register this application without shared platform convergence |
wildo local reinit | Framework developers only | Wipe selected local data and initialize again |
wildo local reset | Application creators and framework developers | Stop and wipe, leaving the environment empty |
These commands require an active local environment. Initialization also needs a targeted application root and the installed CLI/framework path. reinit additionally checks framework-developer mode; --force does not bypass that check. Application creators who deliberately need an empty restart use local reset, then invoke local init separately.
Follow a Compose repair with application startup
# Preserve backing-service data while reconciling initialization.
wildo local init
# In a local Compose environment, start application development afterward.
wildo local dev
Initialization converges generated artifacts, backing-service readiness, platform initialization, application registration and runtime environment projections. Its completion includes an executable platform JWT/configuration postcondition. It prepares the infrastructure and control plane; application processes start separately.
The command needs the targeted application root and an existing local environment. Missing or invalid authored secrets must be restored or deliberately prepared through setup; repair must not invent a competing credential set.
Treat an empty rebuild as a different operation
In framework-developer context, local reinit stops the relevant supervised/tracked processes, wipes through the selected runtime lane and delegates back to initialization. Compose stops containers before host directories are removed. The cluster path releases claims and local storage before recreating the environment. Failed removal is reported rather than hidden behind a later bring-up.
In interactive mode, the destructive commands try to list the absolute data paths before asking for confirmation. That preview is best-effort: a path-resolution failure can leave the prompt without a directory list. Confirm the selected application and data scope before proceeding. Non-interactive execution requires explicit destructive opt-in. Do not use that mode merely to bypass a question during diagnosis.
Respect a live shared owner
A full initialization can disturb shared platform processes and generated state, so a live owning session causes a refusal. The --register-only path reconciles this application’s registration and projections against the existing platform instead. These commands are local lifecycle tools; they do not restore remote business data or replace a remote deployment procedure.