ExecPlan status fields are stale and use an inconsistent vocabulary

[leynos]

Observation

docs/execplans/4-2-1-kani-harnesses-for-manifest-to-ir-safety-checks.md carries Status: READY FOR REVIEW, although its own Progress and Outcomes sections describe completed work, the roadmap marks item 4.2.1 and all its sub-items [x], and the harnesses it specifies are committed and verifying.

Surveying the whole directory, this is not an isolated slip. The status field is stale in at least one place and uses at least five different vocabularies for the same state.

Evidence

$ for f in docs/execplans/*.md; do printf '%-64s ' "$(basename "$f")"; grep -m1 -i "^Status:" "$f" || echo "(none)"; done

Distinct values in use for "the work is finished": COMPLETE, COMPLETED, DONE, IMPLEMENTED. Three files carry no status line at all (3-6-1-ensure-default-subcommand-builds-manifest-defaults.md, cli-output-clarity.md, issue-83-support-overriding-ninja-executable.md). One is stale (4-2-1, READY FOR REVIEW). Several append free-text qualifiers, for example COMPLETED (Stages E–F descoped; Stage D completed).

The execplans skill template specifies a closed set:

Status: DRAFT | APPROVED | IN PROGRESS | BLOCKED | COMPLETE

Why it matters

Low severity, and no code is affected. The cost is to anyone — human or agent — orienting in the repository:

• A reader who trusts the status field will believe 4.2.1 is unreviewed work in flight and may either redo it or avoid building on it.
• The vocabulary spread means the field cannot be filtered, counted, or checked mechanically, so drift is invisible.
• The failure mode is self-reinforcing: once a field is known to be unreliable it stops being maintained, which is roughly where the directory is now.

The reliable signals today are the roadmap checkboxes, the committed artefacts, and each plan's own Progress and Outcomes sections. That is worth stating explicitly somewhere, whichever way this is resolved.

Suggested resolution

Either of these is a reasonable outcome; the choice is a maintainer's:

1. Normalize and keep the field. Map the existing values onto the template's closed set, correct 4-2-1 to COMPLETE, add the field to the three files missing it, move free-text qualifiers into a sentence beneath the header, and add a note to AGENTS.md or docs/documentation-style-guide.md recording the closed set. A trivial contract test could then keep it honest.

2. Retire the field as a source of truth. Record in docs/documentation-style-guide.md that an ExecPlan's authoritative state is its Progress and Outcomes sections plus the roadmap, and that the header status is advisory.

Doing neither leaves a field that looks authoritative and is not.

Discovered during

Planning for roadmap item 4.2.3 (PR #564), while establishing whether 4.2.1 and 4.2.2 had been implemented. Recorded in that plan's Surprises & discoveries with the note "do not treat execplan status fields as a source of truth" — which this issue exists to make unnecessary.