Constant TASK_FILE_SPEC 

pub const TASK_FILE_SPEC: &str = "\
The task file is markdown. magi hands it to every candidate verbatim and to
every judge as the statement of what was asked, so it is the only thing any of
them knows about the change. Use this shape:

# <one line, imperative: what the change is>

## Context

Why this change, and what a competent stranger to this repository needs to know
that the code does not say. Name the files, the modules and the symbols
involved, with paths.

## Change

What to do, in enough mechanical detail that two candidates could not
reasonably disagree about the target: the interfaces, the names, the shape of
the data. Leave the *design* open - how it is built, in what order, with what
internal structure. That gap is where blind judging does its work; closing it
turns the competition into three transcriptions of the same answer.

## Constraints

Anything that must hold: files that must not be touched, dependencies that must
not be added, conventions to follow, commands that must not be run.

## Completion criteria

- [ ] One observable, checkable statement per line.
- [ ] Written so that a judge holding only the diff and this list can decide
      whether each line holds. \"Works well\" cannot be judged; \"`magi plan`
      exits non-zero and names the draft path when the draft has no completion
      criteria\" can.

## Out of scope

What this competition must not touch, so that no candidate can win on breadth
instead of on the change that was asked for.

Rules for the task itself:

- One change per competition. Bundling unrelated fixes makes the diff
  unjudgeable and the statistics meaningless.
- Nothing destructive or irreversible. Several candidates run unattended and in
  parallel, and no node stops to ask.
- Visual and UX judgement stays with the operator: no judge sees a rendered
  screen, so do not ask for one to be evaluated.
";

The task-file shape the leader is asked to produce.

This is handed to the leader verbatim as part of its briefing, and it is also the document review_draft enforces. The two are checked against each other by a test, because a spec that asks for something the validator does not require - or worse, the reverse - turns a good interview into a rejected draft for no reason the operator can see.