propose_condition_edit
Propose a condition change (tag rename, waste %, multiplier, height, roll setup) as a pending diff the estimator accepts or rejects. Nothing changes until approval.
Instructions
PROPOSE a change to a condition instead of making it (#365): a diff — a new finish tag (rename), waste %, ×N multiplier, height_ft, roll_setup — held PENDING until the estimator accepts it from the panel. edit_condition is the wrong power for "I think this condition is wrong": a tag rename or a knob change should be a decision the estimator makes, not one they discover. Until acceptance NOTHING changes — takeoff_summary and export_report keep computing from the current values and carry the diff beside them (proposed_condition_edits), and once accepted the report is byte-for-byte what a direct edit_condition would have produced (the same write path). Only fields that differ from the current value are recorded; a proposal that changes nothing is refused, and a rename onto a tag another condition already carries is refused (two conditions on one tag would make one unreachable). One pending diff per condition — proposing again replaces the earlier one (undo_last restores it). rationale is required: the estimator accepts a reason.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| condition | Yes | Finish tag of an EXISTING condition, e.g. 'CPT-1' | |
| height_ft | No | ||
| rationale | Yes | Why — the schedule row, the spec section, the sheet note that decided it | |
| waste_pct | No | ||
| finish_tag | No | Proposed new tag (a rename) | |
| multiplier | No | ||
| roll_setup | No | Proposed roll-goods setup, or null to propose opting out |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | ||
| current | Yes | ||
| proposed | Yes | ||
| condition | Yes | ||
| rationale | Yes | ||
| proposal_id | Yes | ||
| condition_id | Yes | ||
| replaced_proposal_id | No | Present when this proposal replaced an earlier pending one on the same condition |