See what can move forward and why
A useful next step depends on what is already in the project. Wildo checks each method’s declared requirements and shows which work is ready, which needs more information and what an existing result would replace.
This gives people and agents an explained set of options. They can distinguish a missing input from an ordinary recommendation about doing one piece of work before another.
Example — Find the missing input before starting
A requirements method needs a usable vision and market snapshot. If the market information is missing, the board names that condition. Once it is available, the method can become an option without moving the whole application into a new phase.
For engineers
Read the evaluated contract
The current eligibility result exposes these selected fields:
readonly playbookRef: string;
readonly intent: string;
readonly eligible: boolean;
readonly preconditions: readonly PlaybookPreconditionVerdict[];
readonly unmet: readonly string[];
readonly blockedOnlyBySequencing: boolean;
readonly requiresElicitation: boolean;
readonly wouldReplace: readonly string[];
readonly unlandableFamilies: readonly string[];
readonly staleOutputs: readonly {
readonly family: string;
readonly changedInputs: readonly string[];
}[];
This is an interface excerpt, not an application configuration. The evaluator combines the playbook, artifact state and the set of families the runtime can land. Each unsatisfied condition contributes an actionable explanation to unmet.
| Condition | How it affects a run |
|---|---|
ARTIFACT_EXISTS or ARTIFACT_VALID | Establishes readiness for declared artifact input |
STEP_AVAILABLE | Requires a sibling result, optionally with a matching field value |
ARTIFACT_EXPECTED | Expresses sequencing; an explicit run can proceed past this class |
| No declared output can be landed | Adds a readiness refusal |
| Outputs derived from changed inputs | Adds freshness information rather than a refusal |
Keep annotations useful
wouldReplace exposes existing output content. staleOutputs describes changed inputs using the supplied Git freshness facts. Neither is a claim that the old result is semantically wrong. They help a person or selector decide whether another run is worth doing.
An already executed build plan can also make decomposition a sequencing concern when its upstream inputs are unchanged. Editing an upstream family reopens that reason to work.
Inspect current readiness
wildo context journey presents the board through the companion. The companion also exposes GET /playbooks and POST /playbooks/refresh-board. Treat a displayed board as the state evaluated at that time: the unattended loop reads again before each iteration. Eligibility establishes that declared prerequisites hold; it does not predict the quality of the result.
See the work a composite can affect
Replacement, freshness and unavailable-renderer annotations include the outputs declared by a composite’s children. outputOwners identifies the declaring playbooks; unresolvedPlaybookRefs identifies missing child definitions. These details describe possible effects, while the parent’s readiness continues to follow its own declared conditions. A child warning alone does not disable the parent.