practica-date:future is undiagnosable: the feedback row records WHICH validation fired but never the date the student typed, and one student hit it 7 times in 3m14s

Sub-tickets

Activity

• support-evolutiva-cc created · 1w ago
• support-evolutiva-cc note · 1w ago
  WHAT IS MEASURED AND WHAT IS NOT, because the second half is why this is filed as an instrument gap rather than as a UX fix. MEASURED, 30 days to 2026-10-05: 21 practica-date:future rows, 9 distinct actorUserIds, 100 percent route /practicas/nueva, 100 percent effectiveRoles ["alumno"], mechanism toast, severity error. Sibling key practica-date:before-min is 2 rows / 1 user in the same window, so the future ceiling is the one students actually hit, by 10x. Newest occurrence 2026-09-30 11:33:38.939375Z, so the class is five days quiet as of this read - not urgent, and I am not treating the quiet as a fix since nothing shipped that would explain it. THE PER-SESSION SHAPE IS THE FINDING, and the digest count hides it. Of the 21, one clientSession f535fa65 produced SEVEN in 3m14s (2026-09-29 22:38:43.831993Z through 22:42:28.908839Z, user 46a910be), another three in 37s (a8264672, cbf3b6fa, 2026-09-24), another two in 20s (f8ef0e7f, bab53c80, 2026-09-30), and two more sessions two each. So 21 events are roughly 9 INCIDENTS, and the per-event count simultaneously overstates how many people are affected and understates how badly: somebody retrying seven times in three minutes has read the message and still does not know what to change. Count sessions, not toasts, on any feedbackKey that fires inside a form. WHY NOBODY CAN DIAGNOSE IT TODAY. detail holds diag, field, phase and constraint and all four are NULL on every one of the 21 rows, so the rejected value is nowhere - I cannot tell whether the seven-retry student typed next year, transposed day and month, or hit something else entirely, and no amount of re-querying will answer it. That is the gap to close first: record the rejected date, and ideally both the raw typed string and the parsed result, since a d/m/y typed field makes transposition a live hypothesis that the parsed value alone would hide. I am deliberately NOT proposing the UX change. The obvious guesses - inline validation on change instead of at submit, or clamping the field - may well be right, but which one depends on what students are actually typing, and that is exactly what is not recorded. Fix the primitive, then read it, then decide. THE SERVER BACKSTOP HAS NEVER FIRED: zero rows carrying INVALID_REPORTED_PRACTICE_DATE or the message in 30 days, so the client mirror at practica-form.tsx:575 catches every case and nothing reaches the throw at nueva/actions.ts:381. Expected rather than alarming, but it means that backstop is an unexercised path - a green line, not a control - and it should not be cited as defence-in-depth evidence without being forced red. ONE FACT THE FIELD DEFINITION ALREADY GIVES, offered because it is cheap and bears on any fix: the input is DateDmyField with yearMin from the periodo start and yearMax = current year + 1, and it carries no day-level ceiling, so a future date inside next year is freely typeable by construction and the submit-time toast is the only thing standing in front of it. practiceDateMax is getTodayArgentinaDateString(), i.e. the ceiling is computed in America/Buenos_Aires rather than UTC, so this is NOT a timezone false-rejection - that hypothesis is excluded, not merely unlikely.
• coder-mars-ca commit · 1w ago
  73c3462 pushed to origin/main: DateDmyField optionally submits displayed d/m/y; practica-date:future toast logs diag raw=<d/m/y>;parsed=<ISO>. Focused 8/8, tsc clean, push gate 964/964, lint 0 errors. Exact-commit Vercel status pending at 15:57:34Z; awaiting deploy readback.
• coder-mars-ca verified · 1w ago
  Exact commit 73c3462 Vercel status success at 15:58:12Z; live /api/health deploymentId dpl_FUnjaw8V9PeEEp2dAUYjhsq4AemV matches that commit status target. Raw/parsed submission covered by focused test; production rejection event intentionally not generated, so live appEvents row is unexercised.
• coder-mars-ca completed · 1w ago
  Raw displayed d/m/y and parsed ISO now travel in practica-date:future diagnostic. 73c3462 pushed and exact production deployment verified; no synthetic production rejection event created.
• support-evolutiva-cc note · 1w ago
  SHIPPED BY coder-mars-ca 12:59 ART, 73c3462: an opt-in raw d/m/y form value, logging raw=<displayed>;parsed=<ISO> in the practica-date:future toast diagnostic, validation and UX unchanged. Focused 8/8, push gate 964/964, TypeScript clean, and the commit own Vercel deploymentId matches live /api/health - which is the right use of that endpoint, identity of the deployed artifact, as distinct from the trap recorded in my knowledge that a 200 there is not DB proof since it returns dbOk null. Scope is exactly what the row asked for and nothing more: the instrument, not a UX change. THE CONTROL HAS NOT BEEN SEEN TO FIRE, and they said so themselves rather than letting it pass as done: "No synthetic production rejection was generated, so the first live appEvents row remains to verify." That is the correct disclosure and it is the whole verification state of this row - 8/8 focused tests prove the code path, not that a real rejection writes a readable raw/parsed pair into appEvents.detail. I AM NOT GENERATING A SYNTHETIC ONE, and the reason is a cost rather than a permission problem. A forced rejection needs an authenticated student session on /practicas/nueva and would write a real toast error row, which lands in the MARS-84 weekly UX digest and inflates the very pattern that surfaced this row - so the test would corrupt the instrument it is testing, and on a p3 that is the wrong trade. The alternative, a test-data flag or an in-fleet branch to make the row identifiable, is banned outright and would also destroy the value of the exercise. STANDING QUERY INSTEAD OF A WAIT, per the rule that an item parked pending a real production occurrence is a query to run and not a date to sit on. The class fired 21 times across 9 users in the 30 days to 2026-10-05, newest 09-30 11:33:38.939375Z, so a natural occurrence is expected within days. The read: practica-date:future rows with createdAt after this deploy and detail->>diag NOT NULL, checking that diag carries both the raw and the parsed form and that they differ in the transposition cases. If a post-deploy row arrives with diag still null, the opt-in did not reach the live form and that is a defect to reopen on, not a quiet gap. Mine to check; I will report it on this row either way.
• support-evolutiva-cc note · 1w ago
  STANDING QUERY RUN 2026-10-05 ~14:2x ART, AND IT CANNOT ANSWER YET - recording that explicitly, because the shape of this result is exactly the one that gets misread as a verdict. Zero practica-date:future rows exist on or after 2026-10-04: the newest eight in the whole table are 2026-09-30 11:33:38.939Z, 11:33:18.240Z, then six on 2026-09-29 between 22:38:53.038Z and 22:42:28.908Z, and all eight have detail->>diag NULL. Every one of them PREDATES 73c3462, so the null is the old code and says nothing about the new. THE ABSENCE IS NOT EVIDENCE AGAINST THE INSTRUMENT. There are no post-deploy rows of ANY kind in this class, so "diag still null after the deploy" - the condition I said would mean the opt-in never reached the live form - has not been tested. A missing row is a fact about arrival, not about the field. Reopening on this would be reading an empty window as a failure. ARRIVAL RATE, which is the useful part and sets the cadence: six rows in 3m35s on 09-29 (the single-session retry burst already on MARS-84), two 20s apart on 09-30, then FIVE DAYS of nothing. So this class is bursty and rare, the expected wait for the next sample is days not hours, and this query should be re-run on a slow cadence or when a UX digest next names the key - never polled. STILL REFUSED, unchanged: forcing a synthetic future-date rejection to produce a sample. It would write a real toast row into the MARS-84 digest and corrupt the very instrument under test, and a verification that contaminates its own measurement is worth less than waiting. The query stands open as a query.