C1 single shared complic. pool filterable by modulo — reverses confirmed §9, needs Sebastian go

Sub-tickets

Activity

• wi-cli-venus created · 2026-06-26
• support-evolutiva-cc note · 1w ago
  HAY UN DATO DEL CLIENTE EN CONTRA DE ESTA PROPUESTA y es anterior a hoy. WhatsApp 2026-07-30 17:50 ART, sin que se le preguntara: 'Cuando pusiste para filtrar por complicaciones... quedo vacio. No abre nada. Habria que poner un filtro por complicaciones intraoperatorias y otro por complicaciones postoperatorias.' Esta fila propone exactamente lo contrario - un pool unico filtrable por modulo. No es una respuesta formal a C1 y no cierra la fila, pero presentarle C1 como pregunta limpia seria preguntar algo sobre lo que ya tenemos evidencia. Las dos cosas van juntas cuando se le pregunte. El defecto del filtro vacio quedo como VENUS-447. Pregunta 1 del bundle /home/rob/gdrive/projects/evolutiva/shared/client-questions-bundle/2026-10-06-consolidated-client-questions.md
• pmmaster-evolutiva-cc note · 1w ago
  CLIENT EVIDENCE FOUND, and it points AGAINST this row's proposal - surfaced by support-evolutiva-cc 2026-10-06 from the saved WhatsApp record while assembling the client-question bundle. On 2026-07-30 the client asked, UNPROMPTED, for TWO SEPARATE complication filters rather than one pool. C1 here proposes a single shared complication pool filterable by modulo, which reverses confirmed section 9. I am deliberately NOT closing this row on that evidence, because the two statements may be on different axes: the client's 'two separate filters' could mean intra-operative versus post-operative, which is not the same question as whether one pool is filterable BY MODULO. Reading his message as a direct answer to C1 would be inference, not evidence, and a catalogue decision taken on a misread is expensive to withdraw once records point at it. WHAT CHANGES: this stops being an open design question and becomes a CONFIRMATION. Do not ask the client C1 cold - show him what he already said on 07-30 and ask whether it answers C1 or is a separate request. Asking an open question we hold contradicting evidence about wastes the one scarce thing here, which is his attention. PROCESS POINT worth more than this row: a July client message sat unread for over two months while the row it bears on stayed parked 'needs Sebastian go'. The client record is a monitoring surface, not background context - rows blocked on a client answer should be checked against it before they are escalated, because the answer may already be in the channel. Three other parked questions turned out to be already answered in the same sweep, and three client requests had never become rows at all.
• pmmaster-evolutiva-cc canceled · 1w ago
  Canceled by pmmaster-evolutiva-cc 2026-10-06. This row's proposal CONTRADICTS both what shipped and what the client asked for, verified against the live app by support-evolutiva-cc. VENUS-47 proposed C1: a single shared complications pool filterable by modulo, reversing confirmed section 9. Two independent facts kill it. The client asked UNPROMPTED on 2026-07-30 for TWO SEPARATE complication filters rather than one pool. And both already exist in production: the shared pool AND the two separate filters shipped in commit fc4c5cf on 2026-07-31, the same commit that fixed the filter defect where the dropdown compared intra/post against the stored intraop/postop. The only genuinely open question left in this area is module-scoping, which is carried in the client-question bundle. So this row would have had us build the opposite of what the client requested, on top of a feature that was already live, and it sat for two months reading as pending client input. When I annotated it earlier tonight I declined to close it on the 07-30 message alone, because 'two separate filters' could have been a different axis (intra versus post) rather than an answer to C1. That caution was right at the time and is now resolved the only way it could be - by reading the live app rather than by interpreting the message harder. The lesson is the order of operations: check what SHIPPED before interpreting what the client said about it. Duplicates already handled: VENUS-101 canceled as the same question pair as this row and VENUS-48.