Endodoncia I comision LETTER CONFLICT (SOP-MARS-58): Mars follows the client 209-x-es-y mapping 6/6 and the catedra attendance sheet uses the other letter - client decision, not a data repair

Sub-tickets

Activity

• wi-cli-venus created · 4w ago
• wi-cli-venus note · 4w ago
  CORRECTION TO THIS ROW, AND IT REVERSES ITS TITLE AND PRIORITY. I opened MARS-728 as a CONFIRMED P1 data defect ("the comision D cohort is filed under B"). THAT WAS PREMATURE. The digital source files Elazar pointed me to falsify the "Mars got it wrong" reading. Mars's import is faithful to every client-supplied source, 6 of 6. Lowering to P3 and reframing as a CLIENT CONVENTION CONFLICT. The 52/52 measurement in the original body stands and is not withdrawn - only its interpretation is. THE SOURCE FILES: pm/client-provided-docs/originals/2026-08-05/endodoncia-i/ holds six Endodoncia I rosters named 209-<X>-es-<Y>: 209-a-es-c, 209-b-es-a, 209-c-es-d, 209-d-es-b, 209-e-es-e, 209-f-es-g. The name encodes a LETTER MAPPING and its meaning is documented NOWHERE - not in index.md, not in manifest.json (inferredPurpose is the generic "UTF-8 conversion of Endodoncia I student roster"). It survives only in the filename. VERIFIED: MARS FOLLOWED THE SUFFIX, 6/6. Took the first student of each file and read their live comision: ABALOS (209-a-es-c) -> C; AGUER (209-b-es-a) -> A; ACOSTA (209-c-es-d) -> D; ALVAREZ (209-d-es-b) -> B; ALTAMIRANDA (209-e-es-e) -> E; AGUILAR CALIZAYA (209-f-es-g) -> G. Every cohort landed on its suffix letter. There is no import bug and no partial application. AND THE TEACHER FILE AGREES INDEPENDENTLY. pm/client-provided-docs/master/docentes-grado-v008.tsv: "SERON Romina Silvina | B | Ay 1o", "VAZQUEZ MAGNI Ma. De la Paz | B | Ay 1o", "LOIACONO Romina | D | JTP". So a SECOND client artifact, produced separately from the student rosters, also places Seron and Vazquez Magni on B and makes Loiacono the JTP of D. Mars matches it. coder03's original "possible name collision between the two Rominas" was the right instinct and I dismissed it too fast. SO THE ACTUAL CONFLICT IS BETWEEN TWO CLIENT SOURCES, NOT BETWEEN THE CLIENT AND MARS: Saying B: the roster filename suffix (-es-b) AND docentes-grado-v008.tsv. Both August artifacts. Saying D: Romina Seron, who teaches the cohort, and her printed CATEDRA DE ENDODONCIA attendance sheet headed "COMISION D (endo 1)" with attendance columns running 14-ago through 11-sep. Note the tell: her sheet's letter D matches the file PREFIX (209-d), not the suffix. The same 53 students appear in both, and the row counts agree exactly - 209-d-es-b.tsv has 53 data rows, her sheet has 53 names. It is the SAME COHORT under TWO DIFFERENT LETTERS, which is precisely what a "<siu letter> es <catedra letter>" mapping exists to translate - applied in the direction the people in the room disagree with. WHAT IS NOT IN DISPUTE, and it is the student-visible harm she reported: ~52 students are shown a comision letter that differs from the one used in their classroom and on their attendance sheet, and every practica they load is recorded under that letter. Teaching access is unaffected because the teachers are mapped the same way, which is why this produced no error and surfaced only as a human noticing. THIS IS NOT MINE TO DECIDE AND NOT A DATA REPAIR. The question for the catedra is exactly one sentence: FOR ENDODONCIA I, IS THE COHORT OF ALVAREZ/BUJALDON/CAAMANO CALLED B OR D? Whoever answers must also say whether the answer generalises to all six comisiones, because the mapping is not identity on four of them (a->c, b->a, c->d, d->b) and is identity on one (e->e). Relabelling is a six-comision change touching everything already recorded; moving students would be wrong outright if the mapping is correct. DO NOT let anyone fix this one comision in isolation. ONE REAL DISCREPANCY WORTH FIXING REGARDLESS, small and separate: docentes-grado-v008.tsv gives Seron cargo "Ay 1o" (ayudante) only, but Mars carries her on B - Endo 1 as BOTH ayudante AND jtp. The extra jtp membership is not explained by any source file. Same for checking Vazquez Magni. PROCESS LESSON, and it is mine: I had the 52/52 measurement and jumped from "Mars disagrees with a paper sheet" to "Mars is wrong", stated as CONFIRMED. The paper sheet is one source, not the source of truth, and I had not yet looked for the import inputs - which existed, in the repo, and reversed the reading. Measuring one side carefully does not license a conclusion about which side is wrong. Same family as [[feedback_measure_the_claim_that_gates_the_action]]: the conclusion needed TWO sources and I had measured ONE.
• wi-cli-venus note · 4w ago
  CORRECTION TO THIS ROW, AND IT REVERSES ITS TITLE AND PRIORITY. I opened MARS-728 as a CONFIRMED P1 data defect ("the comision D cohort is filed under B"). THAT WAS PREMATURE. The digital source files Elazar pointed me to falsify the "Mars got it wrong" reading. Mars's import is faithful to every client-supplied source, 6 of 6. Lowering to P3 and reframing as a CLIENT CONVENTION CONFLICT. The 52/52 measurement in the original body stands and is not withdrawn - only its interpretation is. THE SOURCE FILES: pm/client-provided-docs/originals/2026-08-05/endodoncia-i/ holds six Endodoncia I rosters named 209-<X>-es-<Y>: 209-a-es-c, 209-b-es-a, 209-c-es-d, 209-d-es-b, 209-e-es-e, 209-f-es-g. The name encodes a LETTER MAPPING and its meaning is documented NOWHERE - not in index.md, not in manifest.json (inferredPurpose is the generic "UTF-8 conversion of Endodoncia I student roster"). It survives only in the filename. VERIFIED: MARS FOLLOWED THE SUFFIX, 6/6. Took the first student of each file and read their live comision: ABALOS (209-a-es-c) -> C; AGUER (209-b-es-a) -> A; ACOSTA (209-c-es-d) -> D; ALVAREZ (209-d-es-b) -> B; ALTAMIRANDA (209-e-es-e) -> E; AGUILAR CALIZAYA (209-f-es-g) -> G. Every cohort landed on its suffix letter. There is no import bug and no partial application. AND THE TEACHER FILE AGREES INDEPENDENTLY. pm/client-provided-docs/master/docentes-grado-v008.tsv: "SERON Romina Silvina | B | Ay 1o", "VAZQUEZ MAGNI Ma. De la Paz | B | Ay 1o", "LOIACONO Romina | D | JTP". So a SECOND client artifact, produced separately from the student rosters, also places Seron and Vazquez Magni on B and makes Loiacono the JTP of D. Mars matches it. coder03's original "possible name collision between the two Rominas" was the right instinct and I dismissed it too fast. SO THE ACTUAL CONFLICT IS BETWEEN TWO CLIENT SOURCES, NOT BETWEEN THE CLIENT AND MARS: Saying B: the roster filename suffix (-es-b) AND docentes-grado-v008.tsv. Both August artifacts. Saying D: Romina Seron, who teaches the cohort, and her printed CATEDRA DE ENDODONCIA attendance sheet headed "COMISION D (endo 1)" with attendance columns running 14-ago through 11-sep. Note the tell: her sheet's letter D matches the file PREFIX (209-d), not the suffix. The same 53 students appear in both, and the row counts agree exactly - 209-d-es-b.tsv has 53 data rows, her sheet has 53 names. It is the SAME COHORT under TWO DIFFERENT LETTERS, which is precisely what a "<siu letter> es <catedra letter>" mapping exists to translate - applied in the direction the people in the room disagree with. WHAT IS NOT IN DISPUTE, and it is the student-visible harm she reported: ~52 students are shown a comision letter that differs from the one used in their classroom and on their attendance sheet, and every practica they load is recorded under that letter. Teaching access is unaffected because the teachers are mapped the same way, which is why this produced no error and surfaced only as a human noticing. THIS IS NOT MINE TO DECIDE AND NOT A DATA REPAIR. The question for the catedra is exactly one sentence: FOR ENDODONCIA I, IS THE COHORT OF ALVAREZ/BUJALDON/CAAMANO CALLED B OR D? Whoever answers must also say whether the answer generalises to all six comisiones, because the mapping is not identity on four of them (a->c, b->a, c->d, d->b) and is identity on one (e->e). Relabelling is a six-comision change touching everything already recorded; moving students would be wrong outright if the mapping is correct. DO NOT let anyone fix this one comision in isolation. ONE REAL DISCREPANCY WORTH FIXING REGARDLESS, small and separate: docentes-grado-v008.tsv gives Seron cargo "Ay 1o" (ayudante) only, but Mars carries her on B - Endo 1 as BOTH ayudante AND jtp. The extra jtp membership is not explained by any source file. Same for checking Vazquez Magni. PROCESS LESSON, and it is mine: I had the 52/52 measurement and jumped from "Mars disagrees with a paper sheet" to "Mars is wrong", stated as CONFIRMED. The paper sheet is one source, not the source of truth, and I had not yet looked for the import inputs - which existed, in the repo, and reversed the reading. Measuring one side carefully does not license a conclusion about which side is wrong. Same family as [[feedback_measure_the_claim_that_gates_the_action]]: the conclusion needed TWO sources and I had measured ONE.
• wi-cli-venus priorityChanged · 4w ago
  3
• wi-cli-venus titleChanged · 4w ago
  Endodoncia I comision LETTER CONFLICT (SOP-MARS-58): Mars follows the client 209-x-es-y mapping 6/6 and the catedra attendance sheet uses the other letter - client decision, not a data repair
• wi-cli-venus note · 4w ago
  ELAZAR RULING 2026-09-12: Romina Seron is the ONLY point of contact for Endodoncia I, so her word settles the lettering. He asked whether the other five comisiones can be inferred from the filename convention rather than asked about one by one. THEY CAN, AND THE INFERENCE CLOSES. THE RULE, fixed by her single confirmed case: the CATEDRA letter is the filename PREFIX. Mars imported the SUFFIX. Her cohort is file 209-d-es-b: prefix d, and she says it is comision D. So prefix = catedra, suffix = the other (SIU/administrative) lettering. APPLYING IT TO ALL SIX: file catedra (prefix) Mars today (suffix) 209-a-es-c A C 209-b-es-a B A 209-c-es-d C D 209-d-es-b D B <- Romina's, the confirmed one 209-e-es-e E E 209-f-es-g F G As a relabel of the CURRENT Mars names: A->B, B->D, C->A, D->C, E->E, G->F. IT IS A BIJECTION, WHICH IS WHAT MAKES IT SAFE. Six distinct sources, six distinct targets, no collisions. Cycle structure: (A B D C) is a 4-cycle, E is a fixed point, G->F is the only letter that leaves the set. That is why NO comision can be corrected in isolation - every one of the four in the cycle is occupied by the cohort that has to vacate it, so a single-comision fix collides by construction. It has to be one atomic change or none. SIZE CORROBORATION, independent of any letter argument: each Mars comision's roster size matches its source file. C=54 vs 209-a=54, D=51 vs 209-c=51, E=52 vs 209-e=52, G=45 vs 209-f=45 - exact on four. A=58 vs 209-b=56 and B=54 vs 209-d=53 carry 2 and 1 later additions. So the file-to-comision assignment itself is not in doubt; only the letter is. THIS IS A RENAME, NOT A DATA MIGRATION - the single most important point for whoever executes. studentAssignments, teacherComisionMemberships and practicas all reference comisiones.id, never the name. So correcting the lettering is SIX UPDATEs on comisiones.name and nothing else: no rows move, no FK is touched, no practica is re-parented, and every student and teacher stays attached to the same cohort they are in now. It is also REVERSIBLE by applying the inverse permutation, which a student-moving approach would not be. Must run in ONE transaction (or via a temporary name) because the 4-cycle means an intermediate state has duplicate names. WHAT THE INFERENCE RESTS ON, stated plainly rather than buried: ONE confirmed case, plus the assumption that the naming convention is UNIFORM across the six files. That assumption is reasonable - one batch, one folder, one date (2026-08-05), one scheme - but it is an assumption and it is not verified, and the convention's meaning is documented NOWHERE (not index.md, not manifest.json). THE ONE CHEAP QUESTION THAT VALIDATES OR BREAKS IT, and Romina can answer it herself: ASK HER FOR THE FULL SET OF ENDODONCIA I COMISION LETTERS. Mars currently holds A, B, C, D, E, G. Under the rule the true set is A, B, C, D, E, F - no G at all. So: if she says the catedra's comisiones are A through F, the rule is confirmed on a second, independent point and the whole relabel can proceed. If she says there IS a comision G, the rule is wrong and the prefix reading fails. One question, binary outcome, and it tests the uniformity assumption rather than re-testing her own comision. EXECUTION when confirmed: db-mars-cc, six UPDATEs in one transaction, under setArchiveContext. Not this lane. Do not touch studentAssignments.
• wi-cli-venus priorityChanged · 4w ago
  2
• wi-cli-venus note · 4w ago
  EXECUTED, FIVE OF SIX. Migration 161 applied to prod, handoff commit 8f42bdb (Local-Author: db-mars-cc, one file), coder-mars-cc publishes. Relabel A->B, B->D, C->A, D->C, E fixed point. G->F HELD - see below. Verified live AFTER commit, independently of the migration's own post-check: A=54 B=58 C=51 D=54 E=52 G=45 (G unchanged), which is exactly the permutation applied to the pre-state A=58 B=54 C=54 D=51 E=52 G=45. Spot-checks both as specified: ALVAREZ, Agustina Solange now reads D - Endo 1; ACOSTA, Ximena Valeria now reads C - Endo 1. NO STUDENTASSIGNMENT WAS TOUCHED, AND I DID NOT ASSERT THAT FROM MY OWN SQL. studentAssignmentsArchive carries ZERO rows in the window, so the audit trail proves the negative independently of what I believe I ran - trg_student_assignments_archive is tgenabled='A' since migration 159, so it would have fired had anything been written. This matters because the row's central warning is that moving rows would reach the same visible place while destroying the ability to tell afterwards which defect it was. WHY G->F WAS HELD, which was coder-mars-cc's explicit open point and my call. The 4-cycle is FORCED: the one confirmed fact is B->D (Romina's own cohort), D is occupied, so landing it requires D->C, which requires C->A, which requires A->B. All or nothing. G->F is the ONLY one of the six not forced by that confirmed correction, and it is simultaneously the SHARPEST TEST of the assumption everything else rests on - the prefix rule predicts a true letter set of A..F with no G at all, while Mars holds A,B,C,D,E,G. Applying the one letter whose answer is still pending, when it is severable and when a 'yes, there is a comision G' answer would falsify the whole rule anyway, takes the untested half of the inference for free and buys nothing. If Romina confirms A..F, G->F is a follow-up migration with no cycle and no collision risk. If she says G exists, 161 is reverted by its inverse permutation (A->C, B->A, C->D, D->B), documented in the file - which is the entire reason the fix had to be a rename. TWO MECHANICS THAT DIFFERED FROM THE DISPATCH'S ASSUMPTIONS, recorded so the next execution does not rediscover them. (1) The dispatch offered 'defer the unique constraint if one exists - check first'. Checked: uq_comisiones_periodoId_name is a partial UNIQUE INDEX (CREATE UNIQUE INDEX ... WHERE deletedAt IS NULL), NOT a deferrable constraint, so SET CONSTRAINTS has nothing to act on and deferral was never available. Temp-name staging was the only route, and the staging names had to be collision-proof against the OTHER live rows in the periodo, not merely against each other. (2) setArchiveContext is server-only TypeScript and cannot be called from psql. Its actual mechanism is two transaction-local GUCs that the trigger reads through current_setting - app.user_id and app.archive_reason - so the migration sets them directly. All 8 comisionesArchive rows carry non-NULL archivedBy AND archiveReason. Skipping this would have left the change most likely to be audited later completely unattributed. ONE GUARD ADDED THAT WAS NOT ASKED FOR, because a bare permutation sitting in the applied set is a trap: a PRE-STATE ASSERTION refusing to run unless the six rosters read exactly A=58 B=54 C=54 D=51 E=52 G=45. Re-running the file after success would otherwise rotate the cycle a SECOND time and silently produce a third lettering with no error at all. The post-check likewise asserts roster SIZES per label rather than just the labels - a mis-staged cycle yields perfectly valid-looking letters attached to the wrong cohorts, and only the sizes catch that. READING THE ARCHIVE ROWS LATER: fn_archiveComisionChange is shape (C) - the fall-through handles INSERT and UPDATE reading NEW - so these rows record the NEW names and show TWO hops per comision (the __mars728_tmp_ staging name, then the final letter). The pre-rename letters recover by chaining back to each comision's preceding archive row, not from these rows. Expected, not a defect. STILL OPEN ON THIS ROW AND NOT MINE UNLESS ASKED: (a) correcting the record with Romina on SOP-MARS-58 - she was told we could not reproduce her report, and she was right and supplied the evidence that proved it; (b) Romina's own answer on the full letter set, which gates G->F; (c) the separate discrepancy already noted on this row - Seron carries BOTH ayudante and jtp on the cohort while docentes-grado-v008.tsv gives her ayudante only, and the extra jtp membership is unexplained by any source file. Offered to coder-mars-cc as a separate change. Self-DM to coder02-mars-cc sent in the same turn per the review-tier pilot, with four specific attack surfaces named rather than a generic ask - including whether my zero-studentAssignments proof is actually valid and whether the escaped-underscore LIKE pattern in the post-check is vacuous.
• wi-cli-venus verified · 4w ago
  PASS:8f42bdb (coder02-mars-cc review). Reviewed under the same authorization shape as MARS-703 - Elazar personally ruled and dispatched this row's fix in his own words, so I treated it as within scope of the general fleet STOP's Elazar-directed-work allowance rather than new agent-initiated work. Unpublished at review time; coder-mars-cc still needs to push 8f42bdb. Independently verified, not taken from db-mars-cc's message: recomputed the live post-state myself (A=54 B=58 C=51 D=54 E=52 G=45, matches exactly), confirmed zero __mars728_tmp_ staging names survive, confirmed the LIKE escape pattern in the post-check matches the actual 4 underscores in the staged prefix (not vacuous), read fn_archiveComisionChange's prosrc directly and confirmed it reads current_setting('app.user_id', true) / ('app.archive_reason', true) - the exact two GUC names set_config wrote - and confirmed 8 comisionesArchive rows tagged MARS-728, all 8 with non-NULL archivedBy and archiveReason. One correction to db-mars-cc's own reasoning, not blocking: the 'zero studentAssignments moved' claim was evidenced via studentAssignmentsArchive being empty (an absence-of-alarm inference, valid but only as strong as the alarm mechanism). The migration file itself contains ZERO DML against studentAssignments - only 8 UPDATEs against comisiones - which proves the same fact directly from the statement list rather than through an inference chain. Flagged for future writeups of this shape, not this one. G->F held pending Romina's confirmation: agreed, no dispute - strictly the conservative choice, the 4-cycle is forced regardless of her answer, and holding it is a second independent test of the uniformity assumption at zero cost.
• wi-cli-venus note · 4w ago
  PASS:8f42bdb from coder02-mars-cc, reviewed under the same authorisation class as MARS-703 (Elazar personally ruled and dispatched this row in his own words, so it is not agent-initiated work under the fleet STOP). Still unpublished - coder-mars-cc pushes it. It checked all four surfaces I flagged, independently rather than from my message: (1) recomputed the pre/post roster state from live evidence, A=54 B=58 C=51 D=54 E=52 G=45, matching the asserted post-state, and confirmed no __mars728_tmp_ name survives - the guard is not theatre; (3) verified the escaped-underscore LIKE pattern matches the actual staged prefix and is not vacuous, cross-checked with a plain substring LIKE; (4) read fn_archiveComisionChange's prosrc directly and confirmed it reads current_setting('app.user_id') and current_setting('app.archive_reason') - exactly the two GUCs my set_config calls wrote, so the 8 attributed rows are not a different-path false positive. It agreed the G->F hold is strictly conservative and costs nothing. ONE METHODOLOGICAL CORRECTION WORTH MORE THAN THE VERDICT, on item (2). My proof that no studentAssignment moved was 'studentAssignmentsArchive has zero rows in the window', resting on that trigger being 'A' since 159. coder02 accepted the argument as sound but called it UNNECESSARILY INDIRECT, and it is right: the migration file contains ZERO DML statements against studentAssignments at all - only 8 UPDATEs against comisiones - so the negative is provable by reading the file's own statement list, which is airtight, rather than by an absence-of-alarm inference that is only ever as strong as the alarm. The indirect form imports the whole tgenabled/replica-bypass question as a dependency for no gain, which is exactly the mechanism whose reliability MARS-64 spent the night establishing. Generalised and saved: when proving a negative, read the ARTIFACT (statement list, diff, commit pathspec, GRANT list) and keep the observational check as corroboration, stated as such - never lead with the weaker one.
• wi-cli-venus assigned · 3w ago
  coder-mars-ca
• wi-cli-venus note · 3w ago
  Reassigned coder-mars-cc -> coder-mars-ca on 2026-09-19 under Elazar's direct Mars coder+PM handover, relayed by coder-mars-cc at 05:39 ART and explicitly ordered by pmmaster-evolutiva-cc at 05:40 ART. This transfers backlog ownership only; implementation/push authority remains governed by mars-commons.md.
• coder-mars-ca blocked · 1w ago
  BLOCKED ON CLIENT/ELAZAR COMMISSION-MAPPING DECISION: Mars currently follows the documented 209-x-es-y mapping; the catedra paper attendance sheet assigns the same students under another letter. This is not an authorized data repair or code change until the authoritative mapping and affected cohort are decided. Row created 2026-09-12 (24 days old on 2026-10-06). Preserve the separate support-ticket correction obligation recorded on the row.
• coder-mars-ca blocked · 1w ago
  CORRECTION of my 2026-10-06 blocker note: five of six authorized relabels ALREADY APPLIED in migration 161 on 2026-09-12 (A→B, B→D, C→A, D→C, E fixed), with live readback and archive attribution recorded on this row. Do not rerun or infer none was repaired. REMAINING BLOCKER: G→F was deliberately held pending Romina Seron confirmation that the catedra letter set is A–F (not G); this is the client decision, not a code or DB-credential gap. Separately owed now: correct the earlier false inconclusive answer to Romina on SOP-MARS-58. Created 2026-09-12 (24 days old on 2026-10-06). No data/code change in this re-triage.
• support-evolutiva-cc verified · 1w ago
  OWED CORRECTION IS DISCHARGED AND HAS BEEN SINCE 2026-09-12. Verified by support-evolutiva-cc on request from coder-mars-ca (coder-mars-ca-muwd27nradlo). No new support send, and one would be actively wrong: it would reopen a thread the reporter closed with thanks. The row's premise is that Romina Seron was told the commission-letter problem could not be reproduced and was never corrected. The first half is true. The second is not - the retraction went out 25 minutes later, on the same channel, and she acted on it. supportTicketMessages for ticket 58, every one of these PUBLIC and therefore reporter-visible: - 2026-09-11 23:36Z internal triage (coder03-mars-cc): 52 D-Endo1 assignments cross-checked, no comisionId mismatch found. - 2026-09-12 07:29Z PUBLIC: "Estuvimos revisando el caso de tu lado y no pudimos reproducir la inconsistencia que nos comentas." This is the message the row is about. - 2026-09-12 07:54Z PUBLIC, twenty-five minutes later: "Revisamos a fondo y queremos corregir lo que te dijimos antes: tenias razon en que algo no coincide." Names the cause - two different comision naming conventions in circulation - and confirms her 53-student sheet is loaded complete and correct. - 2026-09-12 08:05Z PUBLIC: asks her to confirm ALL the Endodoncia I comision letters for the term, "la lista completa (A, B, C, D, E...) tal como las nombra la catedra". - 2026-09-12 13:31Z PUBLIC: "ignora los mensajes anteriores, fueron confusos y la culpa es nuestra... Ya lo corregimos: tus alumnos ahora figuran como comision D. Tambien corregimos las demas comisiones de Endodoncia I, que tenian el mismo problema." That is migration 161's five relabels, reported to her the same day they were applied. - 2026-09-14 13:03Z REPORTER: checked her attendance sheet against the app, "son correctos", and raised two students separately (Leiva, Mencia Davalos). - 2026-09-15 / 2026-09-19: Leiva resolved as a real misassignment and removed; Mencia Davalos answered as attendance, not misassignment. - 2026-09-19 12:41Z REPORTER: "Perfecto, muchas gracias!" - Ticket resolved 2026-09-22. So the correction was not merely sent - it was READ AND ACTED ON, which is stronger evidence than a delivery record: she replied to its substance twice and verified the fix against her paper sheet. WHAT IS GENUINELY STILL OPEN, and it is a DIFFERENT item from the one this row names: the question asked at 2026-09-12 08:05Z was never answered. She was asked for the full letter set and replied about comision D's roster instead, then moved on to the two students. There is no message in the thread containing the A-F list. So coder-mars-ca's G->F hold is correctly held - but it is waiting on an UNANSWERED QUESTION, not on an unsent correction, and those have different remedies. A re-ask is legitimate; a correction is not owed. INSTRUMENT LIMIT, stated because I nearly reported the opposite off it. emailOutbox CANNOT corroborate any of the above and is not evidence either way: its oldest surviving row is 2026-09-29, a week after this ticket resolved, and a prefix census of all 698 rows returns 'auto' only - ZERO rows with a 'support:' dedupeKey have ever been observed in the surviving window. My own knowledge file records the shape as support:<uuid>:reporter:<comment|resolved>:<hash> with four such rows sent on 2026-09-22, so those rows existed and have been pruned. I first read the absence of a support: row for this address as "no correction was ever mailed", with 14 sent auto: mails to the same address as the positive control. That inference was wrong, and the thing that broke it was checking whether the key shape appears ANYWHERE rather than only for this recipient - a zero that is global is a fact about retention, not about the case. The message thread is the correspondence record here; the outbox is out of window. Also noted, not raised as a finding: ticket 58's resolutionNote is EMPTY despite resolvedAt being set. On mars the resolutionNote IS the reporter-facing close email, so the close sent her nothing. Harmless in this instance - she had already been answered and had said thanks - but it means the close itself carries no record of why it closed.
• coder-mars-ca blocked · 1w ago
  BLOCKED ON ROMINA SERON LETTER-SET ANSWER: five of six authorized relabels already applied in migration 161 on 2026-09-12; only G→F remains held until she confirms whether the catedra letters are A–F (rather than including G). Support-evolutiva-cc verified ticket 58 public-thread correction sent 2026-09-12 07:54Z after the mistaken 07:29Z reply, completion notice 13:31Z, and reporter thanks on 09-19; do NOT send another correction. She confirmed D roster but never answered the A–F question. Row created 2026-09-12 (24 days old on 2026-10-06). No code/data/support send from this re-triage.
• coder-mars-ca assigned · 6d ago
  coder-mars-cc