CLI output wording/ordering: stale-vs-missing, premature 'Built N' success line, version-consistency source-of-truth hint

[mike-north]

Found by the blind DX study wave 2026-07-19 (published @ai-plugin-marketplace/cli@0.6.0), independently reproduced in an isolated sandbox. Full data: scratch/dx-studies/wave-2026-07-19.

Problem

Three mechanical CLI output-wording/ordering defects that mislead users during a normal build/validate run. Grouped here because each is a small, self-contained output fix in the build/validate rendering path (the PM approved consolidating these rather than scattering them into the discovery/required-field issues).

1. "stale" vs "missing". Pre-build freshness reports files that do not exist YET as stale, when they are simply not built. It should say missing and direct the user to run aipm build.
2. Success line prints before a run-failing finding. Built N plugin(s) is printed BEFORE a hard finding that actually fails the run — so the user sees "success" immediately above the failure. The success line must not print (or must be phrased as non-success) when a hard finding fails the run.
3. version-consistency finding lacks a source-of-truth hint. The version-consistency finding (from Add version-consistency check to aipm validate #84) states the mismatch but does not name aipm.config.ts as the authoritative version source, so the user doesn't know which side to fix. Add a hint naming aipm.config.ts as the source of truth.

Acceptance criteria

1. Pre-build freshness on a not-yet-built (nonexistent) file reports it as missing with a "run aipm build" hint, not stale.
2. When a hard finding fails the run, the Built N plugin(s) success line does not appear before it (reorder so failures precede any success summary, or suppress the success summary on a failing run).
3. The version-consistency finding message includes a hint that aipm.config.ts is the source of truth for the version (so the user bumps the manifest to match config, per aipm validate should gate plugin.json manifest versions against aipm.config.ts #75's contract).
4. Tests assert each corrected string/ordering (spec-derived assertions, not snapshots).

Non-goals

• No behavior change beyond wording/ordering — the same conditions are detected; only how/when they are reported changes.
• The discovery finding (Design: embedded marketplaces & a Codex target #2) and required-field enforcement (feat(core): relocatable plugins/dist roots for embedded marketplaces #3) are tracked in their own issues.

Proof

UAT/output tests assert: a nonexistent artifact reports missing not stale; a failing run does not print Built N plugin(s) above the failure; the version-consistency message names aipm.config.ts. Each fails against current output.

[mike-north]

Claimed by the eng fleet (dispatched after #93-96 landed). Dispatching an implementer for the three output-wording/ordering fixes: pre-build freshness says 'missing' (not 'stale') for not-yet-built files with a run-aipm-build hint; the 'Built N plugin(s)' success line no longer prints before a run-failing hard finding; and the version-consistency finding names aipm.config.ts as the version source of truth.

[mike-north]

Opened #110

[mike-north]

Resolved by #110 (squash-merged). Three CLI output fixes: (1) a not-yet-built dist bundle file is reported as 'missing' with a 'run aipm build' hint, not 'stale'; (2) the 'Built N plugin(s)' success line prints only when the post-build validate passes, so it never appears above a run-failing hard finding; (3) the version-consistency finding now carries a hint that aipm.config.ts is the source of truth for the version (so the user bumps the manifest to match). Spec-derived tests for each, regression-guarded both directions for the success-line ordering.