Consumes one structured propose-change result and materializes its complete
replacement source through the normal G1-G4 candidate gate.
mix ptc.repair MANIFEST --report repair.json --out candidateMaterialization does not execute the candidate. A host may explicitly opt in to a live trial using a bounded validation suite:
mix ptc.repair MANIFEST --report repair.json --out candidate \
--validation-suite private/suite.json \
--validation-out private/trial \
--allow-live-validationA suite contains one to 32 host-owned cases. Each case supplies name,
exactly one JSON input or private_input, and an exact JSON expected
result. Use input for non-secret regression vectors so the provider data
class remains normal; private_input requires every selected provider to
admit private input. Test inputs are staged owner-only and removed after the
suite. Results, traces, inspection, envelopes, and the aggregate report are
written beneath the new private trial directory. Result values are never
printed. The directory also receives feedback.json, an owner-only handoff
that separates the model-authored candidate from host-authored comparisons
and retains each input, expected value, and available actual value. A later
correction run can consume that file as private input without reconstructing
validation facts in prose.
--allow-live-validation is deliberately explicit: the application is run
with its installed providers and can exercise their existing effects. The
static candidate gate prevents authority widening; it cannot make a live
application run transactional. Passing cases prove only the named inputs and
providers. Promotion remains a separate human decision.