Dogfood diagnostic commands

Two commands answer the question that costs the most time when a development stack misbehaves: is what I am running actually current. wildo fwk wt-status prints one screen covering build freshness, linked-snapshot coherence, registry alignment, process and port state, and index freshness. wildo fwk wt-tail streams every process log of the same application together with coloured prefixes. Both are read-only.

The problem it solves

In a repository where an application consumes the framework through linked copies of compiled output, a large share of apparent bugs are not bugs. A symptom that reproduces in one process and not another is usually a stale compiled artifact, a linked snapshot that has fallen behind, or a process that has been running since before the fix. Every one of those presents as a logic defect: a missing export reads as a bad import, a stored document rejected by a schema reads as a validation bug, a service that will not start reads as a configuration problem. The investigation goes into the code, and the code is fine.

What makes this expensive is that the cheap check is never the one anyone runs first, because at the moment of the symptom there is no reason to suspect the artifact. These commands exist to make that check cost one line instead of an afternoon, and to make it a single screen rather than six separate questions.

What it does

Two commands answer the question that costs the most time in a development stack: is what I am running actually current?

The snapshot compares each package’s compiled output against its source, then validates the linked snapshot the application resolves its framework dependencies through — reporting whether files are missing, drifted, or present in the snapshot after being DELETED from the framework. It compares the three module registries an application declares, which have to agree and are edited separately. It reports which processes are up, what their last build signal says, which ports are occupied, and whether the code-intelligence index is fresh.

Each finding names the exact command that repairs it, and the repairs differ: a drifted file is reconciled, a file left behind by a deletion has to be pruned instead, and an unfinalized compiled tree is a build problem wearing a snapshot symptom.

The currency sweep behind the same question is broader and application-agnostic. It asks one thing across every derived surface: whether the file watchers can still see edits at all, compiled output against source, unfinalized emit, accepted generations against the paths they name, linked snapshots compared by file set, the package store against the links that reach it, the configuration cache against its inputs, the provider set each runtime will bind against the configuration that declares it, each supervised process’s START time against the build it loads, and published documentation. It discovers application roots rather than being told them, and it prints both timestamps and the delta so a reader can see which side of the threshold a finding sits on.

The log tail is the companion to that: the development stack does not centralise its logs, so it finds whatever log files exist, prefixes each line with a coloured label, and can list which logs are present and which are missing rather than silently tailing nothing.

What you decide

Both are gated to a framework checkout and never appear to someone running the command line inside their own application. The currency sweep is also a plain script invocation, deliberately: the operator who needs it is usually mid-incident with a command line whose own compiled output is one of the suspects.

Limits

Both commands are hardwired to one reference application. The paths they read are that application’s own, so they say nothing about any other application in the repository.

Nothing here fails a build or a boot. The sweep exits zero even with findings by default, on the stated ground that a currency check that failed a start would be a new way to break the stack — a strict flag exists for a pipeline that has decided otherwise. Acting on a finding is a separate, manual step.

The sweep reports staleness, not correctness. It compares timestamps and file sets, so an artifact rebuilt from wrong source is current and reported as such.