fix: the judge of an operation holds what the operation works through, and a red judge names the scaffolds it runs over

[rodrigoteamx]

It came stacked on #148, which is in main now: this one's base is main, with main merged in — against it, it changes its own six files.

Why

The house says the judge comes before the body. In the three finished course runs of the reference run's first stage, the residents scaffolded their operations and then spent 23, 32 and 18 tool calls — 14 to 17 calls to the model, nine to ten minutes of a 25-minute run — before sending a first body. In all three the reasoning says the same thing: declare the test first, then find out how a test gets the repository an operation's run() receives. One of them never found out and filled no body at all. The judge's scaffold was a bare TestCase that fails on purpose and holds nothing.

In another run, one judge was written for the plugin's whole cycle and named after one operation. That operation's body was refused three times as «judged red by its own test», and the run ended with it still a scaffold. The judge called the plugin's other operations, which in that copy of the house were scaffolds. The refusal showed ten lines of phpunit.

Both are the house making a builder look for something the house already knows (greenhouse evidence/1156).

What changes

• The judge of an operation is scaffolded holding what the operation works through. make what=test for a class that is an operation of the plugin builds the repository its plugin hands run() — in memory — and shows the call the house makes, with a value for each required input. It still fails on purpose. The generator reads the operation's source and its plugin's entry; it loads nothing.
• A red judge names the scaffolds it runs over. A behavior refusal now names the plugin's unfilled operations that the judge names — by class or by the operation they declare — and gives the order: fill and promote those, then send the same implement again. diagnostic.scaffolds lists them.
• The skill governed-authoring says to scaffold an operation's judge once the operation is in the house, and what a judge runs over.

What does not change

• The judge of anything that is not an operation, and a judge scaffolded before its class exists, are the bare scaffold, byte for byte.
• A judge red over no scaffold is told nothing new.
• An entry hands one repository. A second one in run()'s signature is shown missing in the judge, not held.

Tests

• 24 tests. 15 were written red first. 5 pin what does not change and passed from the start. 4 were written after the code, for hand mutants: three I expected to survive and one that did; two more tests were strengthened for the other two survivors.
• The judges are run by a real phpunit over what the real generators scaffold.
• Suite: 852. 29 hand mutants, all killed after that second pass. PHPStan, the formatter and the docblock gate are clean.

Measured in cattle, without a model

The scripted stand-in walks two operations and the judge of one, in a lab house, with and without this change.

	#148 alone	with this
the judge's scaffold	24 lines, bare	51 lines: the repository and the call
the judged body, sent while the other operation is a scaffold	refused: ten lines of phpunit	refused: names the scaffold and the order
after filling the other and sending the same body	lands, judged green	lands, judged green

Said plainly

• Nothing ran with a resident. Whether one writes its judge from the scaffold, or follows the refusal, is for the next run.
• The refusal says «implement» also when the body came through edit.
• The hint the runtime writes beside a refusal still contradicts this one until getmilpa/app-runtime carries its own small fix; that pull request is open beside this.