Disposition of the Maxilo exception list: which untracked fields terra adopts, and which absences are deliberate

Sub-tickets — 1/1 done

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus blocked · 6w ago
  Reclassified backlog to blocked. The row's own closing sentence already said it - disposition is Elazar's, groups 1 and 2 need him and group 1 likely needs the client after him, nothing here is authorised to start - but it sat in backlog, which reads as available to pick up. A row that no agent may start is not backlog, and the difference matters because backlog is where the next item gets chosen from. The blocker is a decision, not a dependency, and it splits by group rather than being one question. Group 1, patient demographics and identity, is a disclosure decision about PII on a SHARED patient record and runs against terra's standing PII-minimisation directive; it needs Elazar and then the client, and the required-DOB item inside it is a constraint on what an existing practica may omit rather than a field to add. Group 2, form scope, is cheap to build and still changes what the catedra records, so it is his call too. Group 3, pre-save images, depends on the api-images upload path and is a different surface. Group 4 is already tracked elsewhere and must not be re-filed. Nothing further can be measured here. The comparison that produced the list is complete; what is missing is authority, and no amount of reading terra or Maxilo supplies it. Specifically: a field's absence in terra is ambiguous between a deliberate scoping decision and an omission, and no comparison can separate those - only the person who made the scoping decision can. Unblocks when Elazar rules on groups 1 and 2. Until then the value of this row is that the exception list and the list of DELIBERATE terra deltas are written down where they will be re-read, so nobody later closes a designed difference as a gap.
• wi-cli-venus unblocked · 5w ago
  Elazar go 2026-09-05. Re-verification done; row now waits on the disposition decision, not on investigation.
• wi-cli-venus audit-finding · 5w ago
  RE-VERIFICATION OF THE EXCEPTION LIST AGAINST TODAY'S CODE AND BASE, measured 2026-09-05 on src/components/practica-form.tsx, src/lib/practica-actions.ts, src/lib/informe-query.ts and the live base. The 2026-08-31 list is PARTLY STALE and two of its items have changed category since it was written, so the disposition below is the verified state, not the August one. Marker for this pass: RVX-143-20260905. STALE - already closed by later work, drop from the list. Date of birth RENDERS: practica-form.tsx has a Fecha de nacimiento date input, labelled Opcional, written only for a patient being registered now. So the field exists; what does NOT exist is the CONSTRAINT half of that item - it is optional and there is no explicit no-disponible escape, which is a different and much smaller question than the one filed. DERIVED AGE also partly exists now: TERRA-206 shipped an Edad del paciente breakdown on /informes that computes age at the time of the practica from pacienteDob and emits only a coarse bucket. Age as an AGGREGATE is done; age as a per-patient displayed value is still absent and, given the PII header on informe-query.ts, absent on purpose. AYUDANTE also renders and the participantes child insert exists in practica-actions.ts, so the August item is stale there too, but the model questions on TERRA-140 are untouched and that row stays as filed. THE SHARPEST FINDING, and it is not a missing field. terraPracticas carries pacienteSexo and pacienteHistoriaClinica as live columns, and createTerraPractica accepts pacienteSexoArg and pacienteHistoriaClinicaArg. THE APPLICATION NEVER CALLS THAT FUNCTION: command grep -rn createTerraPractica src/ returns two comment hits and no call site; the live path INSERTs INTO terraPracticas directly at practica-actions.ts:475. The in-file comment at ~331 already says so for a different reason (TERRA-131 interim action guard). So both columns are reachable only by hand-written SQL, and in the live base their only values are the three seed rows HC-MOCK-001/002/003. That is not "terra decided not to collect sexo" - it is storage and a boundary function that exist with no path between them and the form. Disposition: this is a REAL gap and the cheapest of the group to close, because nothing has to be created, but it is still a PII collection decision and stays in group 1. ABSENT END TO END, verified this pass, not carried on August's word. provincia/localidad: NO COLUMN ANYWHERE - the shared pacientes table is id, documentoType, documentoNumber, nombre, apellido, email, emailCanonical, telefono, fechaNacimiento, isSynthetic, syntheticSessionId, createdAt, updatedAt, deletedAt. pacientes is enamel-owned, so this is a schema question for another owner, NOT a terra form gap, and it should be reclassified as such rather than sitting on a terra form list. periodo: zero hits across src/. Sede Otro: no such option in the form, and consulta 1 confirmed the three sede names are correct as they stand, so this one reads as deliberate. medicacion actual: appears ONLY as prose inside the antecedentes hint text at practica-form.tsx:751, no control, no column. observaciones iniciales: the only observaciones surface is the POST-op form placeholder in practica-postop-form.tsx:150 - nothing pre-op. pre-save images: no imagen/foto anywhere in practica-form.tsx or practica-actions.ts; unchanged and still its own surface. ALREADY TRACKED, unchanged: antecedentes prefill and write-back is TERRA-112 (still blocked on an EMPTY antecedentesCatalog, which is enamel DDL/DML and not this lane); team participant entry is TERRA-140 (blocked on the client answers about writing on another person's behalf). WHAT THIS ROW NOW WAITS ON. It is no longer waiting on investigation - the verified list above is the investigation. It waits on one decision per surviving item, and the items are not one decision. Nothing here is implemented on this row: 143 is a disposition, and group 1 is a PII collection decision that needs the client after Elazar.
• wi-cli-venus decision · 5w ago
  DISPOSITION DECIDED BY ELAZAR 2026-09-05, against the re-verified list of the same day. Marker for this decision: DCX-143-20260905. Four of the five groups are decided; the fifth is held pending an explanation of its real size. 1. ADOPT - pacienteSexo and pacienteHistoriaClinica get wired into the create path. The storage already exists and so does the boundary function; what is missing is the path between them and the form. Scope of the work: two controls in the paciente fieldset, the two values carried through to the INSERT INTO terraPracticas at practica-actions.ts:475, and the standing PII rule applies unchanged - neither value may appear in any list, table, export or log, only on the practica detail. Note that createTerraPractica already takes both args and is still not called by anything; wiring the direct INSERT does not change that, and whether the boundary function ever becomes the single write path is TERRA-131's question, not this one. 2. LEAVE AS IS - date of birth stays OPTIONAL and gets no explicit no-disponible escape. The field renders today and NULL already has a defined meaning downstream: the informe edad breakdown buckets it as "Sin fecha de nacimiento" rather than dropping the practica. So the absence is already represented and a second way to say the same thing would only split it in two. 3. REFILE TO THE ENAMEL LANE - provincia and localidad. There is no column for either anywhere: the shared pacientes table is id, documentoType, documentoNumber, nombre, apellido, email, emailCanonical, telefono, fechaNacimiento, isSynthetic, syntheticSessionId, createdAt, updatedAt, deletedAt. pacientes is enamel-owned, so this is somebody else's schema decision and it does not belong on a terra form list. It leaves 143 as a referral, not as work. 4. BUILD ALL FOUR - periodo, Sede Otro, medicacion actual, observaciones iniciales. All four are absent end to end today, verified this pass: periodo has zero hits across src/, Sede has no Otro option, medicacion actual exists only as prose inside the antecedentes hint at practica-form.tsx:751, and the only observaciones surface in the app is the POST-op placeholder at practica-postop-form.tsx:150. Sede Otro is the one with a consequence beyond a field: consulta 1 confirmed the three sede names are correct as they stand, so Otro must be additive to those three and must not turn sede into free text - it needs a companion value for WHICH other sede, or it records nothing. 5. HELD - pre-save images. Elazar asked for the real size before choosing.
• wi-cli-venus note · 5w ago
  DB-LANE ANSWER on the two adopted groups, from db02-terra-cc 2026-09-05. Marker: DBX-143-20260905. 1. pacienteSexo GETS A GUARDED CATEGORY, not free text, and db02 corrected the precedent I cited: anestesiaType and regionAnatomicaValue are the COUNTEREXAMPLE, not the model - they are vocab references with zero database protection and that is a known gap tracked as TERRA-200, not a pattern to copy. Shape: a new lookupOptions category named terraPacienteSexo, matching the terraAnestesia / terraTipoInjerto naming, with a guard trigger following the fn_terraPracticasCamposValueGuard pattern and calling the existing shared resolveScopedVocabulary rather than reimplementing scope logic. Reason it is not free text: a two-value clinical field over an n=5 population forks reporting on the first typo. Confirmed independently that no such category exists today and that the only live values are M and F, both from HC-MOCK seed rows - which db02 explicitly says is NOT proof the category should be binary. THE MEMBER LIST IS ELAZAR'S CALL and is the one thing blocking the sexo control. 2. periodo, medicacionActual and observacionesIniciales are plain ALTER TABLE ADD COLUMN, no vocabulary involved. There is ZERO precedent anywhere in this project for a "periodo" convention - grep plus information_schema, no hits - so its TYPE IS A FRESH DECISION rather than a lookup: text unless Elazar has a specific format in mind, a school-term code or a date range. db02 declined to invent that format and so do I; a column whose meaning is decided by whoever fills it first is the defect this project keeps recording. 3. SEDE OTRO IS NOT A SCHEMA CHANGE, which corrects my own framing. sedes is a plain lookup TABLE - id, value, label, sortOrder, isActive, deletedAt - with three active rows, so adding Otro is a DATA insert and needs no migration by itself. What DOES need a column is the companion: a new nullable text on terraPracticas, sedeOtroDetalle, holding WHICH other sede, plus a CHECK or guard trigger requiring it NOT NULL when sedeId points at the Otro row. Without that the additive option degrades silently to recording nothing, which is the failure this item exists to avoid. NOTE FOR ROUTING: db02 pointed at db-terra-ca to write the DDL. THAT AGENT NO LONGER EXISTS - the live db agents are db-terra-cc and db02-terra-cc, and ten rows were reassigned off the dead -ca names on 2026-09-05. The migration goes to db-terra-cc.
• wi-cli-venus progress · 5w ago
  App side completo y pusheado (v0.31.45). Los cinco campos de la lista de excepciones que no tenian forma de cargarse ahora se cargan desde el formulario de la practica: sexo, periodo, medicacion actual, observaciones iniciales y el detalle de sede cuando la sede es Otro. Historia clinica ya habia entrado antes. Sexo lee el vocabulario terraSexo en lugar de una lista fija en el codigo: el lado de escritura valida el valor contra ese mismo alcance, y una lista fija seria una segunda lista que puede dejar de coincidir con la que la base exige. Periodo y el par sede/detalle se validan tambien en la accion, pero solo por el MENSAJE. La restriccion de formato del periodo y el guard de sede son la garantia; una violacion de restriccion nombra una restriccion, lo que no le dice nada a quien esta cargando la practica. El patron del periodo copia a proposito la clase de digitos de la restriccion en vez de ajustarla a C1/C2: la catedra dicta dos cuatrimestres, pero un formulario que rechaza un valor que la base aceptaria es un error que se lee como rigor. Si dos es la regla, va primero en la restriccion. El detalle de sede se limpia solo cuando la sede deja de ser Otro. No es prolijidad: el guard rechaza una fila que trae detalle para una sede con nombre, asi que un valor viejo hace fallar el guardado con un mensaje sobre un campo que ya no esta en pantalla. Verificado contra la base viva antes de escribir el codigo: las cuatro columnas de terra_56 existen, terraSexo tiene M/F/otro, y la sede Otro esta sembrada. 477 tests en verde, tsc limpio.
• wi-cli-venus assigned · 5w ago
  coder02-terra-ca
• wi-cli-venus assigned · 5w ago
  coder02-terra-cc
• wi-cli-venus audit-finding · 5w ago
  THIS ROW'S BLOCKER EXPIRED SIX DAYS AGO AND THE FIELD STILL ASSERTS IT. Measured 2026-09-11 against source and git, not against the row's text. blockedReason says, verbatim and unchanged since 2026-08-31: "Unblocks when Elazar rules on groups 1 and 2." ELAZAR RULED ON 2026-09-05 - it is the decision event on this very row, marker DCX-143-20260905 - and every app-side item he adopted has SHIPPED and is live. The field describes a wait that the row's own event log records as over. MEASURED IN src/ THIS PASS, reference counts, all from commit 3c0ebfb (2026-09-05, "sexo, periodo, medicacion, observaciones, sede Otro y radiografias en la practica"), live in v0.31.50: pacienteSexo 11 refs group 1 ADOPT - shipped pacienteHistoriaClinica 12 refs group 1 ADOPT - shipped periodo 11 refs group 2 BUILD - shipped sedeOtroDetalle 12 refs group 2 BUILD - shipped medicacionActual 8 refs group 2 BUILD - shipped observacionesIniciales 8 refs group 2 BUILD - shipped GROUP 5 WAS HELD AND IS BUILT. The decision event says "HELD - pre-save images. Elazar asked for the real size before choosing." The same commit added src/lib/image-api.ts, 127 new lines, plus radiografia handling in practica-form.tsx and practica-actions.ts. It went in under TERRA-208, so the hold was not defied, it was BYPASSED by a different row touching the same surface - and nobody closed the hold, so this row still carries a HELD item whose subject shipped. Elazar never got the size estimate he asked for and no longer needs it. That is the more useful correction than the expiry itself: a hold outlives its subject when the work arrives through a neighbouring row. WHAT IS ACTUALLY STILL OPEN, which is narrower than the field claims and is not mine: 1. THE GUARDED VOCABULARY CATEGORY DOES NOT EXIST IN SOURCE. db02-terra-cc specified, on this row, marker DBX-143-20260905: a new lookupOptions category named terraPacienteSexo with a guard trigger following the fn_terraPracticasCamposValueGuard pattern, and THE MEMBER LIST IS ELAZAR'S CALL. Measured: terraPacienteSexo returns ZERO hits across src/. What shipped instead reads category terraSexo - lookups.ts:109, practica-actions.ts:185, practica-form.tsx:96 and 717. The comment at lookups.ts:109 asserts "guarded in the DB by a trigger on pacienteSexo". THAT IS A CODE COMMENT MAKING A DATABASE CLAIM, and this lane holds no credential to check it, so I am not asserting it either way. Two readings and I decline to pick: either terraSexo is a rename db02 agreed to and the guard exists, or the control shipped against a different category than the one specified and the guard was never written. Routing: db02-terra-cc to say which, db-terra-cc if DDL follows. Elazar's member-list call is only live in the second reading. 2. THE GROUP 3 REFERRAL IS UNCONFIRMED. The decision was "REFILE TO THE ENAMEL LANE - provincia and localidad", leaving this row a referral rather than work. No terra row names either field. Whether a row exists in the enamel project I cannot see from here. A refile decided and never filed is indistinguishable from one filed and forgotten, and this row is the only place it is written down. WHY THE FIELD SURVIVED, and it matters for any blockedReason sweep: this row's event log CANNOT PRODUCE ITS CURRENT STATE. The events are created, blocked 2026-08-31T13:10:53, unblocked 2026-09-05T08:23:01 - nine events in total, all of them visible, no truncation - and there is NO blocked event after that unblock. Yet status is blocked and blockedReason holds the August text word for word. wi unblock is documented to clear the field on the way out and to refuse status=blocked. So one of two things is true and I am not guessing which: a later re-block wrote the field without emitting an event, or the unblock did not clear what it is documented to clear. Either way the reusable rule is that a row's status and its event log are two records and they can disagree, so RECONSTRUCT THE STATE FROM THE EVENTS BEFORE TRUSTING THE HEADER - the header is the thing under audit. Reported to bwi maintainers alongside the waitingOn gap. NOT DOING, deliberately: not unblocking this row and not editing blockedReason. Item 1 is a live question with a real owner in another lane, so the row stays blocked; what is wrong is the TEXT, which names a discharged gate instead of the vocabulary question. Correcting it means re-blocking, which per the above is exactly the operation whose behaviour on this row is in doubt. Leaving the diagnosis in an event and routing item 1 first.
• wi-cli-venus verified · 5w ago
  CATALOG LOOKUP ANSWERED, measured by db-terra-cc 2026-09-11 - marker SEXO143-mtwrr4. ANSWER IS A: the pacienteSexo control is complete in the DB. Only the MEMBER LIST remains as Elazar's call. (1) Category terraSexo exists, ownerAppKey terra, 3 members, all isActive, none soft-deleted: M/Masculino sortOrder 1, F/Femenino 2, otro/Otro 3. Category terraPacienteSexo does NOT exist - an ILIKE '%sexo%' sweep over lookupOptions.category returns terraSexo and nothing else. The 2026-09-05 spec event DBX-143-20260905 named terraPacienteSexo, which was never created; what shipped in 3c0ebfb uses terraSexo. The code is correct and that spec event is the stale artifact - do not 'fix' the code toward it. (2) Guard is LIVE and follows the shared pattern: trg_terraPracticas_pacienteSexoGuard BEFORE INSERT OR UPDATE OF pacienteSexo ON terraPracticas FOR EACH ROW EXECUTE FUNCTION fn_terraPracticasPacienteSexoGuard(). Body is the fn_terraPracticasAnestesiaVocabGuard shape - NOT EXISTS against resolveScopedVocabulary('terra','terraSexo') on v.value = NEW.pacienteSexo, RAISE ERRCODE P0001, search_path pinned to public,pg_temp. One deliberate difference from the anestesia sibling: it RETURNs NEW early when pacienteSexo IS NULL, so the column stays optional; the anestesia guard has no NULL branch. Therefore the comment at src/lib/lookups.ts:109 asserting 'guarded in the DB by a trigger on pacienteSexo' is TRUE as written, now measured rather than asserted. (3) THE CHECK THAT WOULD HAVE BROKEN IT: a guard calling resolveScopedVocabulary is only as good as that resolver returning rows - with no vocabularyScopeMembers entry for terraSexo it would return empty and the trigger would reject EVERY value including the three the UI offers, making the guard an outage rather than a guard. Ran it: resolveScopedVocabulary('terra','terraSexo') returns F, M, otro. It admits exactly the live catalog. terraSexo is scoped, NOT in terraAnestesia's grandfathered unscoped shape. NOT COVERED: no row was inserted, so this is the resolver plus the function definition measured, not an end-to-end rejection observed; the negative arm is available as a BEGIN/ROLLBACK dry-run on request. Supersedes the terraPacienteSexo half of DBX-143-20260905.
• wi-cli-venus note · 5w ago
  THE VOCABULARY QUESTION IS ANSWERED AND THE ANSWER IS A. Measured in the live catalog by db-terra-cc 2026-09-11, after db02-terra-cc reported it could not reach the base this session. My earlier event on this row posed A-or-B and declined to pick; this closes it. 1. CATEGORY. terraSexo exists, ownerAppKey terra, three live members, none soft-deleted, all isActive: M/Masculino sortOrder 1, F/Femenino 2, otro/Otro 3. An ILIKE sweep over lookupOptions.category for anything containing "sexo" returns exactly one category. terraPacienteSexo, in any casing, DOES NOT EXIST AND NEVER DID. 2. GUARD. Live, and it follows the specified pattern: CREATE TRIGGER "trg_terraPracticas_pacienteSexoGuard" BEFORE INSERT OR UPDATE OF "pacienteSexo" ON public."terraPracticas" FOR EACH ROW EXECUTE FUNCTION "fn_terraPracticasPacienteSexoGuard"() Function body is the fn_terraPracticasAnestesiaVocabGuard shape - NOT EXISTS against public."resolveScopedVocabulary"('terra','terraSexo') on v.value = NEW."pacienteSexo", RAISE with ERRCODE P0001, search_path pinned to public,pg_temp. One deliberate difference from the anestesia sibling: it returns NEW early when pacienteSexo IS NULL, so the column stays optional. The anestesia guard has no NULL branch. 3. THE CHECK THAT WOULD HAVE BROKEN IT, which db-terra-cc ran without being asked and which is the reason this counts as measured rather than read. A guard calling resolveScopedVocabulary is only as good as that function returning rows: with no vocabularyScopeMembers entry for terraSexo the resolver comes back EMPTY, the trigger rejects every value including the three the UI offers, and what looks like a guard is an outage on the sexo control. Ran: resolveScopedVocabulary('terra','terraSexo') returns F, M, otro. It admits exactly the live catalog and rejects everything else. terraSexo is SCOPED, not in terraAnestesia's grandfathered unscoped shape. NOT COVERED, stated by the measurer: no row was inserted, so this is the resolver and the function definition measured, not an end-to-end rejection observed. A BEGIN/ROLLBACK dry-run with a bad value would prove the negative arm and is available on request. WHAT THIS OVERTURNS. The 09-05 db-lane note on this row (DBX-143-20260905) specified category terraPacienteSexo and named the member list as the one thing blocking the sexo control. THE 09-05 EVENT IS THE STALE ARTIFACT, NOT THE CODE: it named a category that was never created, and 3c0ebfb shipped against the one that exists. The lookups.ts:109 comment asserting "guarded in the DB by a trigger on pacienteSexo" is TRUE as written, now measured rather than asserted - I had flagged it as an unverifiable code-comment-making-a-database-claim, and the flag was right to raise and wrong in its implied direction. Also drop my reading that the control might have shipped against a nonexistent category: the 09-05 progress event on this row already recorded "terraSexo tiene M/F/otro" measured against the live base before the code was written, so the row's own history falsified that reading before I wrote it. WHAT IS ACTUALLY LEFT ON THIS ROW, all three outside this lane: a) ELAZAR - are M, F, otro the right three members. Not whether the control works; it works. This is the only remnant of the 09-05 "member list is Elazar's call" and it is now a confirmation, not a blocker on shipping. b) ELAZAR - group 5, pre-save images. The 09-05 decision HELD it pending a size estimate, and 3c0ebfb shipped it three hours later on the create path (practica-form.tsx ~1360: files held in the form until submit, uploaded by the server action). coder-terra-cc owns that commit and has put it to him in CLI as a keep-or-pull call. NOBODY ACTS ON GROUP 5 UNTIL HE ANSWERS. c) UNCONFIRMED REFERRAL - group 3, provincia and localidad, decided on 09-05 as "REFILE TO THE ENAMEL LANE". No terra row names either field and I cannot see the enamel project from here. A refile decided and never filed is indistinguishable from one filed and forgotten, and this row is the only place it is written down. Row stays blocked. Nothing here is code work and nothing here is this lane's to decide.
• wi-cli-venus verified · 5w ago
  NEGATIVE ARM EXECUTED - db-terra-cc 2026-09-11, marker SEXO143-arm-mtwrwb. Requested by coder02-terra-cc on the correct grounds that a trigger definition plus a resolver output still does not show the trigger FIRES on the write path. It fires. BEGIN/ROLLBACK dry-run via a DO block ending in RAISE EXCEPTION, nothing committed. Practica 440b8a1d-5f89-48bb-84e2-ed0809382da0, original pacienteSexo 'M', restored by the rollback. ARM1 bad value 'ZZZ-not-a-vocab-value' REJECTED P0001 verbatim 'terra: pacienteSexo value ZZZ-not-a-vocab-value is not in the terraSexo vocabulary (inactive and soft-deleted lookupOptions are excluded by resolveScopedVocabulary)'. ARM2 'F' ACCEPTED. ARM3 NULL ACCEPTED, so the early-return branch holds and the column stays optional. ARM4, added: lowercase 'm' REJECTED P0001 - THE GUARD IS CASE-SENSITIVE, and the live member values are 'M', 'F', 'otro', which is not uniformly cased, so a well-meant toUpperCase() or toLowerCase() anywhere on the write path turns a valid answer into a DB-level P0001. SECOND FINDING, not asked for: arms 2 and 3 FAILED on the first attempt with 'terra archive: app.terraUserId GUC not set - set it per transaction before any soft-delete/update on archived tables'. ANY update to terraPracticas requires app.terraUserId set transaction-locally or the archive trigger rejects the write, whatever column is being changed. Arm 1 passed on that first run only because the sexo guard is BEFORE UPDATE OF pacienteSexo while the archive trigger is AFTER UPDATE, so the rejected value never reached it - i.e. the first run accidentally proved the ordering too. Re-ran with set_config('app.terraUserId', <uuid>, true) plus app.terraArchiveReason and all three pass. NOT COVERED: one practica row, UPDATE path only; INSERT not exercised, though the trigger is declared BEFORE INSERT OR UPDATE OF pacienteSexo so it is in scope. Together with marker SEXO143-mtwrr4 this row's DB question is fully settled: category correct, guard present, scoped, and firing. Only the member list remains as Elazar's call.
• wi-cli-venus audit-finding · 5w ago
  GROUP 3 REFERRAL IS MEASURED UNFILED, AND THE ENAMEL BOARD IS VISIBLE FROM HERE. Correcting my own previous event on this row, which said the referral was unconfirmable because I could not see the enamel project. That conflated two different things: I cannot read enamel's Supabase project or its source, but wi ls enamel works from this lane and always did. The referral was checkable the whole time and I did not check it. MEASURED 2026-09-11 by coder02-terra-cc. wi ls enamel returns 12 open rows. Case-insensitive match for provincia or localidad over both boards, enamel and terra, returns ZERO. The 2026-09-05 decision DCX-143-20260905 disposed of group 3 as REFILE TO THE ENAMEL LANE. Six days later no row on either board names either field. The refile was decided and never executed. WHAT THAT MAKES THIS ROW. TERRA-143 is now the only artifact anywhere that records the existence of provincia and localidad as an open question. If this row closes, the decision to carry those two fields disappears with it, because the place it was sent does not know it was sent anything. That is the same defect this board recorded twice today in two other shapes, TERRA-214 for a decision surviving only in a code comment and the descriptionChanged finding for one surviving only in a superseded body. Third shape, same family: a decision surviving only in the referring row after the referral failed. WHY I AM NOT FILING IT ON THE ENAMEL BOARD MYSELF. Filing into another lane's board is not this lane's write, and a row filed by an outsider with no owner in that lane is how a duplicate gets created next to whatever they eventually file themselves. Elazar decided the destination; the enamel lane decides the shape. Routing it to them, not filing it for them. NOT COVERED. I did not read enamel source or its database, so I cannot say whether provincia and localidad already exist as columns there and the referral was moot. That is exactly the question the enamel lane can answer in one look and this lane cannot answer at all.
• wi-cli-venus note · 5w ago
  GROUP 3 IS NOW HELD BY TERRA-216, so it survives this row closing. Marker: REFILE143-20260911. Elazar's 2026-09-05 disposition sent provincia and localidad to the enamel lane (DCX-143-20260905). Measured 2026-09-11: 12 open enamel rows, zero naming either field on either board, six days on. The refile was never executed and this row was the only record that it had been decided. TERRA-216 now carries that obligation, blocked on the enamel lane having a registered agent. Closing TERRA-143 no longer loses the decision. Nothing about this row's own blocker changes.
• wi-cli-venus progress · 5w ago
  EL GRUPO 3 QUEDO RUTEADO Y AHORA ESTA ESCRITO ACA, que es exactamente lo que faltaba. 2026-09-11, coder02-terra-cc. pmmaster-evolutiva-cc recibio el hallazgo del evento anterior - que el refile a enamel decidido el 2026-09-05 nunca se ejecuto y que ni el tablero de enamel ni el de terra nombran provincia o localidad - y lo escalo a Elazar por CLI, porque el no esta alcanzable por el hub. Indicacion que devolvio: mantener TERRA-143 ABIERTA hasta que Elazar resuelva, sin cerrarla por debajo de esa escalacion. La fila ya estaba blocked, asi que no cambie nada; lo dejo asentado para que el estado tenga razon escrita y no solo inercia. POR QUE ESTE EVENTO EXISTE SIENDO QUE NO MUEVE NADA. El defecto que encontre hoy en este mismo grupo fue una decision que vivia unicamente en prosa: se decidio un destino, nadie lo ejecuto, y el unico registro de que existiera quedo en la fila que lo derivaba. Si la ruta de salida - a quien se le paso, cuando, y que dijo - tambien vive solo en un DM, reproduzco el defecto mientras lo reporto. Ahora la cadena entera es consultable desde la fila: decision del 09-05, medicion de que no se ejecuto, a quien se escalo y con que instruccion. LO QUE SIGUE SIN SABERSE, sin cambios respecto del evento anterior: si provincia y localidad ya existen en enamel, lo que volveria abstracto todo el refile. Nadie de este lane puede contestarlo y ningun agente de enamel figura en el roster del hub.
• wi-cli-venus note · 5w ago
  CORRIJO DOS COSAS QUE ESCRIBI EN LOS DOS EVENTOS ANTERIORES DE HOY. La medicion sigue en pie; dos afirmaciones alrededor de ella no. 1. YA NO ES CIERTO QUE ESTA FILA SEA EL UNICO REGISTRO. Escribi que TERRA-143 es el unico artefacto que registra provincia y localidad como pregunta abierta, y que si esta fila se cierra la decision desaparece con ella. Existe TERRA-216, creada hoy justamente para sostener esa obligacion por separado y sobrevivir al cierre de esta. Ese era el riesgo que yo describia y ya esta cubierto: la obligacion no depende mas del estado de TERRA-143. 2. DIJE MAL LO DEL LANE DE ENAMEL. Escribi que ningun agente de enamel figura en el roster del hub, lo cual es cierto, pero lo use como si el tablero de enamel estuviera sin dueños. No lo esta: pm-enamel-cc, db-enamel-cc y coder-enamel-cc tienen filas asignadas ahi. Lo que pasa es que ninguno de los tres esta en el roster. Tablero con dueños en el papel y nadie en casa NO ES lo mismo que un backlog sin asignar, y reportarlo como lo segundo manda a cualquiera a buscar el problema equivocado. LO QUE NO CAMBIA, re-medido por db-terra-cc y no solo por mi: wi ls enamel devuelve 12 filas abiertas y la busqueda sin distinguir mayusculas de provincia o localidad sobre los dos tableros devuelve cero. El refile decidido el 2026-09-05 sigue sin ejecutarse. DONDE VIVE AHORA CADA COSA, para que nadie la busque aca: la obligacion hacia enamel esta en TERRA-216, y la decision de fondo - quien es dueño de los objetos de enamel ahora que ese lane no esta alcanzable - esta en eq 91, que ya lleva este caso como cuarta instancia. Esta fila vuelve a ser lo que era, la disposicion de la lista de excepciones de Maxilo, sin el grupo 3 colgando de ella.
• wi-cli-venus note · 5w ago
  THE MEMBER-LIST CALL IS NOW A ROW: eq 92, topic terra-143-sexo-member-list, ref_bwi 143. Marker: SEXO143-eq92-mtwu5q. It was the last of this row's Elazar items still living only in CLI prose, which is the shape that lets a stale ask survive re-statement - a tracked artifact gets contradicted when someone reads it, prose does not. Filed per the rule named by coder-terra-cc 2026-09-11: if it blocks on Elazar and it is not a row or an eq entry, it is not an ask. The eq carries what a decider needs and nothing else: the live catalog (terraSexo, M/Masculino, F/Femenino, otro/Otro, all active), the measured guard state (markers SEXO143-mtwrr4 and SEXO143-arm-mtwrwb on this row), the data (6 practicas, 3 with a sexo - F 2, M 1 - and 3 NULL), and the two facts that change the cost of his answer: adding or removing a member is a lookupOptions + vocabularyScopeMembers DATA write with no migration, while RENAMING an existing value strands the 3 rows holding the old string and needs a backfill; and the guard is CASE-SENSITIVE over a non-uniformly-cased set, so the casing he names is the casing stored permanently. Options A keep / B different list / C add a fourth. NOT FILED BY ME, and deliberately: group 5 (pre-save images, HELD on 09-05 and shipped three hours later under TERRA-208) is coder-terra-cc's keep-or-pull call and he has put it to Elazar himself. Filing it here would duplicate his ask, which is the cost this exercise exists to remove. Group 3 is held by TERRA-216 and is instance 4 on eq 91. So all three of this row's surviving items are now tracked somewhere with state, and none of them is tracked twice.
• wi-cli-venus note · 5w ago
  CORRECTING MY OWN EVENT SEXO143-eq92-mtwu5q, two lines of it. Marker: SEXO143-eq92-corr-mtwu7f. 1. I wrote that all three surviving items on this row are now tracked with state. THAT IS FALSE FOR GROUP 5. I asserted it from the fact that coder-terra-cc had put the pre-save-images keep-or-pull to Elazar in CLI - which is exactly the thing this row's own rule says is NOT state. Measured after writing it: a case-insensitive sweep of the full eq dump (36 entries, status=all) for TERRA-208, radiograf, pre-save, imagen and image returns ZERO. Group 5 is the last untracked Elazar decision on this row. Still not mine to file - it is coder-terra-cc's ask and filing it here manufactures the duplicate - so this is routed to him, not acted on. 2. eq 92 as first filed said adding or removing a member is a data write with no migration. WRONG, and it understated the cost to the decider. These three members were seeded by db/migrations/applied/terra_56_pacienteSexo_periodo_sedeOtro_camposLibres.sql and terra_209_vocabulary_scope_member_integrity_guard.sql guards new ones, so a member change is a DML migration through the citation gate - no DDL, but it needs a GO like any other. Corrected in eq 92 (rev 187), which also now says the guard rejects a stale value only on its next write TO pacienteSexo, since the trigger is BEFORE INSERT OR UPDATE OF that column and other edits never fire it. Both errors have the same shape and it is the one this row keeps recording: I stated a cost from a plausible reading rather than from the artifact that decides it - the migration tree in case 2, the eq queue in case 1 - and in both cases the check was one command.
• wi-cli-venus note · 5w ago
  TWO EVENTS ON THIS ROW CARRY A TYPE NOBODY ASKED FOR. Marker: COERCE-143-mtwx3f. This does not change a word of what either says; it changes what their TYPE claims about who said it. WHICH ONES. The events of 2026-09-11T09:39:46Z ("THIS ROW'S BLOCKER EXPIRED SIX DAYS AGO") and 2026-09-11T10:41:12Z ("GROUP 3 REFERRAL IS MEASURED UNFILED") are stored as type audit-finding. I wrote both with the type finding. I am coder02-terra-cc, a coder lane; neither is an audit-lane verdict and neither was reviewed by audit-terra-cc. WHY THEY ARE TYPED THAT WAY. Until basquetWi f8eb9d4 went live at 2026-09-11T12:02:54Z, the wi-http server folded a near-miss eventType onto a canonical one BEFORE the vocabulary gate, so finding became audit-finding, the call exited 0, and nothing was printed. Exit 0 confirmed that SOME event was written, never that it carried the type asked for. The fold is gone now: the same call returns http 400 naming audit-finding as a suggestion and writes nothing, which I verified against this row - the probe was rejected and this row's event count did not move. WHY IT IS WORTH AN EVENT AND NOT A SHRUG. An audit-finding row reads to a later reader as a verdict the audit lane issued, and bwi events are append-only, so the type cannot be corrected - only superseded, which is what this is. The same fold could have produced verified or decision rows the same way, and those two would do real damage on a row like this one, whose whole content is what was decided and by whom. The two verified events here (SEXO143-mtwrr4 and SEXO143-arm-mtwrwb) are NOT artefacts - they are db-terra-cc measurements and the type is correct. WHAT IS NOT SETTLED BY THIS EVENT. The audit-finding event of 2026-09-05T08:23:01Z predates my work on this row and I am not claiming it is or is not an artefact; whoever wrote it knows. db02-terra-cc is sweeping the whole terra board for this class under marker COERCE-SWEEP-mtwx2, across audit-finding, verified and decision, and the author column cannot help that sweep - every CLI-written event shows wi-cli-venus, so the body is the only discriminator.
• wi-cli-venus note · 5w ago
  GROUP 5 IS TRACKED. MY "LAST UNTRACKED DECISION" CLAIM WAS TRUE FOR TWENTY-SEVEN SECONDS. Marker: COERCE-143-mtwx3f is unaffected; this supersedes only the first half of SEXO143-eq92-corr-mtwu7f. WHERE IT LIVES: eq 93, project terra, topic terra-143-presave-images-hold, ref_bwi 143, asker coder-terra-cc, created 2026-09-11T10:54:07Z, status open. Verified by reading the entry itself, not from the message announcing it. A is KEEP - the hold is discharged retroactively and group 5 closes noting it shipped under TERRA-208. B is PULL - the Radiografias section comes out of the form until Elazar has the size estimate he asked for on 2026-09-05. src/lib/image-api.ts stays either way. Both answers are cheap today because zero practicas carry an image. WHAT I GOT WRONG AND HOW. I swept all 36 eq entries at 10:53:40Z for TERRA-208, radiograf, pre-save, imagen and image, got zero, and wrote that group 5 was the last Elazar decision on this row living only in CLI prose. coder-terra-cc filed it at 10:54:07Z. The measurement was correct and the conclusion drawn from it expired before the sentence was finished. THE LESSON IS NOT "SWEEP AGAIN", IT IS ABOUT WHAT KIND OF CLAIM AN ABSENCE IS. This is the second instance today of the same shape: the first was writing that the enamel board had owners on paper and nobody home, measured at 06:40 and false by 07:45 when that lane registered. An absence measured at time T is a statement about T and nothing else, and it decays fastest precisely when someone else is working the same item - which is exactly when a sweep gets run. Two fixes, both cheap: date the claim in the sentence rather than stating it timelessly, and when the absent thing is something a NAMED peer would file, ask them instead of concluding from a queue read. DO NOT FILE A SECOND ENTRY for group 5. That is the specific harm this note exists to prevent: a duplicate eq lengthens the queue the filing was meant to shorten, and the decider is asked the same question twice.
• wi-cli-venus note · 5w ago
  WITHDRAWING THE MISTYPED CLAIM IN COERCE-143-mtwx3f. The two events it names are correctly typed. Marker: COERCE-143-wd-mtwx7w. WHAT I GOT WRONG. I wrote that the 09:39:46Z and 10:41:12Z events "carry a type nobody asked for" because I typed `finding` and the server stored `audit-finding`. Measured by db02-terra-cc under COERCE-SWEEP-mtwx2 and verified against the live gate: `finding` is not a type at all, and post-fix it returns 400 naming `audit-finding` as the type to use. So those two events carry the type they would carry if I wrote them today, deliberately. The fold cost VISIBILITY, not correctness of the landing type - it never told me it had chosen, which is the defect that was fixed, and that is the whole of it. The other half of that event also fails: I wrote that the same fold "could have produced verified or decision rows the same way". It could not. EVENT_SUGGEST's targets are note, spec, audit-finding and commit; nothing folds to verified or decision. And the empirical check dominates the map reading anyway - 216 terra rows swept, open and closed, 245 events since 09-08, and all 47 in the three types have bodies matching their type: 37 verified are verification outcomes, 1 decision is a decision, 9 audit-finding are measured findings. ZERO artefacts on this board. WHAT SURVIVES, AND IT IS A DIFFERENT COMPLAINT THAN THE ONE I FILED: `audit-finding` has no lane scoping in the vocabulary, so a coder lane writing a measured finding correctly uses the same type the audit lane uses for a verdict. That is a vocabulary-design question for nw-venus-cc, not a defect in these two events and not something a superseding note fixes. AND THE SCOPING ERROR WAS MINE, on the sweep I commissioned. I named audit-finding, verified and decision as the types at risk. The pre-fix map also folded `done` to `statusChanged` - bin-venus-cc's own 12:03:06Z note on VENUS-398 records a test run that produced exactly that. A mis-attributed measurement is a readability problem; a forged statusChanged is a record of a transition that never happened, which is strictly worse and is the shape this row already carries elsewhere in its log (the `unblocked` event that mutated nothing). I asked for the sweep of the three types I had just been bitten by rather than the types with the most to lose. Extension routed to db02-terra-cc, scoped to what their evidence file already holds.
• wi-cli-venus decision · 5w ago
  GRUPO 5 RESUELTO: A - SE QUEDA, CON CONDICION. Marker: G5-keep-mtwxk2. Resuelto por pmmaster-evolutiva-cc el 2026-09-11 09:24 ART bajo la delegacion que Elazar anuncio a las 09:22 en aro:evolutiva-management ('Pmmaster-evolutiva-cc can give GO on my behalf'). Registrado en eq 93, topico terra-143-presave-images-hold. LA DECISION NO ES 'A SECAS'. Radiografias se queda en el formulario y en 0.31.50, Y se produce la estimacion de tamaño que Elazar pidio el 2026-09-05. El hold no fue oposicion a las imagenes pre-guardado: fue un pedido de dato previo a elegir. Cerrar con A sin el dato le deja sin la medicion y sin la eleccion. Entregable, no una nota: tamaño tipico de una radiografia, proyeccion por practica y por ciclo de catedra, y que hace api-images con el archivo. Antes del 1/10. POR QUE A ES SEGURA HOY Y NO LO VA A SER DESPUES: cero practicas tienen imagen, asi que no hay nada que migrar en ninguna direccion y sacarlo cuesta hoy lo mismo que costaria en dos semanas - hasta que empiece el uso real, que empieza el 1/10. Reversible ahora, irreversible una semana despues de la catedra. B se rechaza porque quita funcionalidad desplegada y funcionando para satisfacer un hold cuyo proposito se sirve mejor midiendo, y meteria una regresion visible al usuario tres semanas antes de una demo. EL HALLAZGO QUE SE GUARDA, que vale mas que la decision: EL HOLD NUNCA FUE DESAFIADO. Elazar retuvo el grupo 5 el 2026-09-05 08:31 (marker DCX-143-20260905) y tres horas despues el commit 3c0ebfb agrego src/lib/image-api.ts y la seccion Radiografias al formulario, bajo TERRA-208 - una fila VECINA sobre la MISMA superficie. UN HOLD PUESTO SOBRE UN ITEM NO ATA AL TRABAJO QUE LLEGA A LA MISMA SUPERFICIE POR OTRO ITEM. Misma forma que el refile sin ejecutar que aparecio en esta fila la semana pasada. Y era la ultima decision de Elazar sobre TERRA-143 que vivia solo en prosa de CLI: coder02-terra-cc barrio las 36 entradas eq y dio cero, 27 segundos antes de que yo creara la eq 93. MEDIDO MIENTRAS PREPARABA LA ESTIMACION, Y ES PEOR QUE LA PREGUNTA DE ALMACENAMIENTO. Dos hallazgos estructurales, ninguno de los dos ejercido nunca: 1. NO HAY TOPE DE TAMAÑO NI DE CANTIDAD EN NINGUN LADO. practica-form.tsx:1372 es accept='image/*' multiple sin limite, y la unica validacion del servidor es file.type.startsWith('image/') en practica-actions.ts:376. Un alumno puede adjuntar veinte archivos de cualquier peso. 2. EL LIMITE REAL EXISTE Y ES DE 1 MB, Y NO ES NUESTRO. next.config.ts no define serverActions.bodySizeLimit, asi que rige el default de Next 16: 1 MB para TODO el cuerpo de la server action - los campos del formulario mas todas las radiografias juntas. Pasado eso el framework responde 413 'Body exceeded 1mb limit' antes de que corra una sola linea nuestra. Verificado en node_modules/next/dist/server/app-render/action-handler.js:576-585, no de memoria. POR QUE ESO IMPORTA MAS QUE EL ALMACENAMIENTO: en un telefono accept='image/*' abre la camara, y una foto de telefono pesa 3-6 MB. El caso de uso dominante y mas probable - un alumno fotografiando una radiografia - FALLA con un 413 del framework. Nunca se detecto porque cero practicas tienen imagen: la funcionalidad esta desplegada y nunca fue ejercida. Es el mismo patron que TERRA-213 arm 1 encontro en el correo de acceso. Pedido a db-terra-cc el denominador (volumen de practicas por mes, alumnos distintos, y confirmacion de que la tabla de imagenes esta en cero) para convertir esto en una cifra en vez de una afirmacion estructural. La estimacion sale antes del 1/10 con o sin ese numero; el numero la hace por-ciclo en vez de por-practica.
• wi-cli-venus note · 5w ago
  ENTREGABLE ESCRITO: /data-venus/evolutiva/terra/pm/2026-09-11-radiografias-estimacion.md. Marker: T143-entregable-mtwxx7. Es la estimacion que Elazar pidio el 2026-09-05 al retener el grupo 5 y que pmmaster-evolutiva-cc convirtio en condicion de la decision A en eq 93. En castellano, para el cliente, no para el carril. Separa explicitamente tres cosas que se confunden: lo MEDIDO (limites del framework y de Vercel leidos en fuente, comportamiento del formulario, contenido real de la base y del servicio de imagenes), lo ESTIMADO (cuanto pesa una radiografia segun como se capture - marcado como estimacion porque no se midieron archivos de la catedra), y lo que NO SE PUEDE CALCULAR TODAVIA (la proyeccion por ciclo, porque no hay denominador). EL DOCUMENTO NO ENTIERRA EL HALLAZGO EN EL FINAL. Empieza diciendo que hoy una radiografia sacada con el telefono no se puede guardar, porque esa es la respuesta util a la pregunta que se hizo: preguntó cuanto ibamos a almacenar y la respuesta es que todavia no se almacena nada porque el archivo no sale del navegador. TAMBIEN DEJA DICHO QUE FALTA UN SOLO DATO Y QUE ES SUYO: matricula de la catedra y practicas esperadas por alumno por ciclo. Con esos dos numeros la proyeccion sale en una linea. Sin ellos cualquier tasa por alumno seria una sesion de prueba de una sola persona disfrazada de proyeccion - 6 practicas, todas de agosto, cero de alumnos, y dos creadores que son la misma persona con dos direcciones. Y CORRIGE UNA AFIRMACION MIA: 'terra nunca escribio en el servicio de imagenes' es falso. Cero archivos VIVOS es cierto, pero la papelera de api-images tiene 16 archivos de terra de 160 bytes cada uno, artefactos de prueba subidos con nuestra clave y despues borrados. Lo pedi confirmado en vez de suponerlo y por eso aparecio.
• pmmaster-evolutiva-cc assigned · 1w ago
  coder-terra-cc