Find what is stopping the stack
A startup failure may come from the machine, a service connection or application code. Wildo checks host prerequisites separately from the running stack, helping identify the layer that needs attention.
The report observes and explains. Repairs remain explicit actions, so asking for a diagnosis does not stop processes or delete local state.
Example — Identify a connection problem before changing application code
A database container appears healthy, but the platform administrator credentials no longer match it. The diagnostic checks the service connection as well as container state, making the difference visible.
For engineers
# Report host prerequisites and Compose running-stack checks.
wildo local doctor
# Observe the development processes and their current facts.
wildo local dev-status
Run these from the configured application workspace so they resolve the intended environment. The doctor does not initialize a missing environment on your behalf. Its running-service probes target Compose containers. On Kubernetes it still runs host checks and warns that cluster-specific diagnosis is not covered; a healthy host result does not establish pod or cluster health.
Separate preparation from runtime probes
| Check family | What it investigates |
|---|---|
| Host prerequisites | Working Node/package manager, native toolchain where relevant, Compose compatibility |
| Generated inputs | Provider runtime modules required by the declared runtime hosts |
| Process leftovers | Orphaned development watchers rather than every matching process |
| Compose runtime checks | Container health, published connectivity and platform administrator authentication |
| Additional diagnosis | Emulated containers, stale credentials and other environment findings |
For a local Compose session, local dev calls the shared collectLocalPreconditionChecks before starting its application tree. A failure blocks startup; a warning is printed and may continue. Running-stack probes remain in doctor, because a preflight must not require the stack it is about to start to be healthy already.
Is the running code current?
wildo local doctor also requests the derived-artifact currency sweep and the coding-agent probe. The shared development preflight omits these additional checks unless requested: it must remain suitable for starting the stack, while doctor spends more time diagnosing it.
When source and behavior disagree, read the currency result before changing the implementation. Source files, compiled output, injected package snapshots and an already-running process can represent different revisions. Currency findings are advisory; follow the named artifact and remediation, then confirm the process has loaded the refreshed output. A green compiler result alone does not establish which code a running service uses.
Interpret each result as an action
Example: a MongoDB container is running, but its administrator authentication fails. This is a shortened diagnostic result; the check name, status and authentication detail come from the implemented probe:
{
"name": "mongo admin auth",
"status": "fail",
"detail": "Authentication failed"
}
For this result, the check suggests comparing the container’s MONGO_INITDB_ROOT_PASSWORD with the administrator connection in the apps-manager’s MONGO_CONNECT_URL. Resolve the configuration mismatch before choosing a repair. A suggested reset wipes data; it is not a prerequisite for reading or understanding the report.
The database probes authenticate with platform administrator credentials. Success establishes that administrator connection, not the application’s own credentials or permissions. Listing stale application users is a separate inventory check; it does not authenticate as each user.
The shared diagnostic contract carries the observation and its next step separately. This is the framework result shape used by the checks and their renderers, not application configuration:
export enum LocalPreconditionCheckStatus {
PASS = 'pass',
WARN = 'warn',
FAIL = 'fail',
}
export interface LocalPreconditionCheckResult {
readonly name: string;
readonly status: LocalPreconditionCheckStatus;
readonly detail?: string;
readonly fix?: string;
}
A failure commits the preflight to blocking. A warning communicates a finding while allowing continuation. The optional fix carries guidance rather than executing it, preserving the separation between observation and repair.
Prefer executed evidence
The toolchain checks execute the relevant binaries; the C++ probe compiles a small modern-language program where supported. This distinguishes a reported version from a usable installation. The network and authentication probes similarly ask more than whether a port was declared in a Compose file.
A result can include a suggested remediation. Apply that action separately after understanding its scope. Orphan detection does not kill the processes it finds, and reporting stale service users does not remove them.
A successful diagnostic establishes only its measured checks. It does not prove the application implements its business rules correctly, nor that an unprobed platform is healthy. Use the per-check status and detail rather than treating the command as a blanket correctness certificate.