An unconfirm reason routes nowhere: the client states a correctable fact and no terra surface shows it to anyone who can correct it
Measured by coder-terra-cc 2026-08-16, answering a direct question rather than assuming: an unconfirm reason code reaches NOBODY who can act on it. The three isConfirmedByClient read sites are /cirugias (per-row label), /panel and /administrar (counts); none reads appEvents, and terra has no surface anywhere that shows an unconfirm reason to a docente, bedel or admin. WHY THIS IS A DEFECT AND NOT A NICE-TO-HAVE. Three of the five ruled reason codes - notOnThisList, wrongNombre, wrongModulo - assert that the DATA is wrong, not that the confirmation was wrong. A client who picks wrongNombre has stated a correctable fact about a cirugia and told nobody. The row lands in appEvents and stops. That is the SAME SHAPE as the defect TERRA-52 exists to fix - a client performing an action that has no effect on the thing they are trying to change - displaced one layer inward. TERRA-52 fixes the flip and reproduces the shape on the reason. FILED SEPARATELY ON PURPOSE, NOT DEFERRED: TERRA-52 must not widen to carry a reason-surfacing UI, and the two working arms of TERRA-52 are not held behind this one. But TERRA-52 shipping is what makes this reachable by a real user, so this is not backlog-forever. OPEN, and the reason this is not yet a spec: WHICH surface, and whether the answer is a queue (something a bedel works through and clears) or a per-row annotation on /cirugias visible to staff. A queue needs a cleared/actioned state, which is a new writer and a new state machine; an annotation needs neither and shows the reason next to the row it is about. Recommend the annotation unless someone argues the reason must be worked to completion - and if it must, say so before building, because that is the difference between a read and a workflow.
Questions
Activity
-
Annotation on /cirugias ADOPTED over a queue. coder-terra-cc's argument carried it and is better than pm's: a queue needs a CLEARED state, and 'cleared' would be a claim about the catalogo that nobody is currently positioned to make - three of the five reason codes say the DATA is wrong, and correcting the data is a capability terra does not have (now TERRA-56). An annotation makes no claim it cannot keep; a queue's cleared flag would be a false one. pm's original argument was only that a queue costs a new writer and a new state machine, which is a cost argument, not a correctness one.
-
Shipped v0.23.0 (8a82a607): /cirugias reads the unconfirm event back from appEvents and annotates the row, shown to EVERY reader rather than gated on canConfirm - three of five reason codes assert the DATA is wrong and the roles who fix data are the ones without the confirm control. Unconfirm filter sits OUTSIDE the DISTINCT ON, pinned with a must-fail control that builds the defective statement. PTD remote form PASS, prod serving this commit on second poll. Coverage limit: SQL is read, never executed - nothing here proves Postgres agrees about DISTINCT ON ordering.