Each livecoding edit should introduce or retire exactly one concept-id so the diff is legible and attributable

The rule ‘one concept-id per edit’ serves two purposes. First, legibility: code is projected and the audience reads it live; a diff containing a single idea is parseable in seconds, while a multi-idea diff reads as opaque. Second, evaluation: the heuristic ‘did the last edit change the output’ assumes only one variable moved per save. When a change requires two ideas, it is realized as two consecutive saves rather than one bundled change.

Examples

Adding .degradeBy(.3) (one concept: probabilistic-variation) is one save. Adding .degradeBy(.3).room(.4) is two concepts and should be two saves.

Assessment

Explain the two reasons the rule ‘one concept-id per edit’ exists in livecoding practice, and give a concrete example of a change that violates it.