Keep the method useful after the first release
An application keeps changing after it first works. Wildo’s playbooks can revisit product definitions and implementation plans using the application that exists now, rather than treating creation as a one-time sequence.
The problem it answers
A product decision can outlive the assumptions behind it. A new customer group, changed requirement or additional resource can make earlier work worth reviewing without making the whole application obsolete.
The useful question is what needs attention now. That requires looking at the current definitions and their relationships, not merely remembering which step ran last.
What it rules in, and what it rules out
The catalogue declares what each method needs and produces. Eligibility evaluates those declarations against the working application; freshness highlights declared inputs that have moved since an output was committed.
Coherence asks another question: whether the loaded definitions agree with each other. A newer input and a broken reference deserve different explanations and different follow-up work.
The same methods remain available when the product changes. Method phases organize the catalogue; they do not force a mature application to start again from an empty project.
What it means for someone building with Wildo
Keep product definitions beside their implementation, inspect what changed and choose the appropriate method again. You can refine a particular decision without treating the application as a new project.
Use the derived reports to focus review, then verify the resulting behavior. Acceptance and any automatic commit policy remain separate from deciding that a method is eligible to run.
For engineers
Where it lives in the framework
Compare an output with its declared inputs
The freshness derivation receives Git facts from the host. This selected source shows how a committed output is compared with its input families:
const output = freshness.get(family);
const derivedAt = output?.committed === true ? output.lastCommitUnixTime : undefined;
if (derivedAt === undefined) return { family, changedInputs: [], derivationPointUnknown: true };
const changedInputs = inputFamilies.filter((input) => {
if (input === family) return false;
const state = freshness.get(input);
if (state === undefined) return false;
return !state.committed || state.lastCommitUnixTime === undefined || state.lastCommitUnixTime > derivedAt;
});
return { family, changedInputs, derivationPointUnknown: false };
An uncommitted output has an unknown derivation point rather than automatically appearing as stale. For an existing input, uncommitted content, unreadable commit time or a newer commit signals change. An absent input is not treated as a changed one by this calculation; existence and validity belong to separate checks.
The declaration defines the coverage. A method that never declares an input cannot receive a freshness finding about that input. Commit-time comparison is useful follow-up evidence, not a proof that one exact output was produced from one exact input revision.
Inspect readiness and consistency together
From the application workspace with its companion running:
# Read the current eligibility board.
wildo context journey
# Inspect relationships across the loaded product families.
wildo context coherence
The board reports readiness and sequencing reasons. An explicit request may proceed past sequencing advice while still needing its readiness conditions. The unattended loop uses the applicable eligibility rules before selecting its next work.
The coherence report complements this view. It identifies supported cross-family inconsistencies and coverage questions; a clean report does not prove every requirement is implemented correctly.