Feedback: immediate repair versus durable product learning

Preview

The solve experience needs two feedback loops:

Immediate repair: Turn feasibility findings and typed failures into explicit actions such as “add one key-holder on Tuesday,” “supply max_hours for Ben,” or “disable this optional preference.” Show the proposed data or constraint change before applying it and rerun the same certified solve.
Durable product feedback: Capture whether the user accepted the schedule, which placement they changed, why they changed it, which manifest and solver version produced it, and whether the correction represents new domain meaning, bad data, a missing shared contract, or solver quality.

The current Solver UX has feasibility and suggestion components but no canonical persistent human-feedback API. Until that contract exists, do not store feedback in an ad hoc application-only schema and do not let accepted edits silently promote themselves into active rules. A future feedback record should be typed, tenant-scoped, version-linked, reviewable, and suitable for golden evaluation before any admission.