/* #variant_protocol @pprog_p8v2_impl_goal_20260804 @pprog_p8v2_questions_20260727 @pprogram_design_202606

The variant protocol: exploring a design on several axes at once

Used where a design has several open points, each with a few reasonable answers, and the choice
between them is a matter of taste and direction rather than something a number can settle. Instead
of deciding, we build all the answers and look at them together.

## One generation

- A BASELINE, which is a complete working variant: #<name>-v001 for the first generation.
- A set of AXES. Each axis is one open point with two or three alternatives, one of which the
  baseline already uses.
- The generation's runs are the baseline plus one or more variant per non-baseline alternative: each varies a single axis off the baseline and changes nothing else so there is never a cross-product or combinatorial explosion problem.
- Every run is instrumented the same way and rendered the same way, so the whole generation can be
  laid side by side.

## Axes are permanent

Axes are never renamed and never deleted (MJC, 2026-08-15, opening generation 5 of p8v2). Axis A
will always be A, and a digit value, once assigned, means forever what it meant in the generation
that assigned it -- retiring an alternative removes it from the live comparison, never from the
record. The letters are a convention, not the idea: an axis IS a core block of the implementation
that varies, and in time an axis may simply be named by its block -- "the f axis" -- rather than by
a letter. Every core block of an implementation is potentially an axis. That is how the "beam
search in program space" idea generalizes: the beam's dimensions are the program's own blocks.

## Choosing

The programmer picks the winner on each axis. The pick is by taste and by where the work is going
next -- an alternative that measures worse now may be the one that has somewhere to go, and an
alternative that wins on today's sample may be a dead end.

Measurement and visualization are EVIDENCE PUT IN FRONT OF THAT JUDGEMENT. They are never the
decision rule. There is no scoring function, no dominance test, no threshold, and nothing is
eliminated automatically. An agent's job in a generation is to build the variants, run them, make
the comparison legible, and stop. Agents do not prune.

An implementation that does not work may be the closest to the intended design.

Choosing is not through chat, but mostly through a choices or axes block that is written for each generation, with a need-feedback flag, in the same step when the visualization happens.
The programmer provides feedback on each axis in this block.
Most of the documentation about what the axes are should come through the visualizations, so this block stays light and has order of 1 line per alternative on each axis, like a multiple-choice quiz.

## Iterating

Picking on a single axis may require rebuilding and running tests or visualizing again on each other axis.
Eventually the decisions narrow to a single implementation, which becomes the next baseline, e.g. #<name>-v002 (or n+1), and the next generation runs off that.

Losers keep their blocks, with a PRUNED line naming the generation that dropped them and one line on why.

## Seeing the generation

Visualization is a deliverable of every generation.

## Workflow

First: a push by MJC defines the next direction.
Second: a short clarifying discussion leads to a goal block for the generation.
Third: implementation defines the axes and proposes visualizations (probably based on existing ones).
Fourth: visualization and measurement, iterative choosing along the various axes, eventually finishing up the generation.

For P-programs, tests/pprog/p8v2-viz-spec.md is the standing example: a self-contained spec for a
3-D rendering of E and P over a fixed 128-byte prefix, with its placeholders explicitly fenced so
scaffolding is never mistaken for a design decision.

Actually the only visualization that I've liked recently is one built by #p8v2_e64_viewer_goal_20260805.

## Cost control

Variants are blocks, not flags and not branches. An alternative is a block that replaces one block
of the baseline; a variant is a program block naming the alternatives it uses in its headers. The
interpreter resolves headers by id, so a generation adds no CLI surface and no build configuration,
and any variant can be re-run later by id.

First use: #pprog_p8v2_impl_goal_20260804.
*/