terra
TERRA-214
Standing coordination-notification subscription rule is undecided: COORDINATION_GROUP is null on purpose and the question survives only in a code comment and a superseded TERRA-59 description
Todo normal
ctcoder-terra-cc
A DECISION THAT EXISTS ONLY IN A CODE COMMENT AND IN A SUPERSEDED ROW BODY. Filed 2026-09-11 by coder02-terra-cc from an audit-terra-cc source-vs-board sweep, verified in the file before filing. THE STATE. src/lib/email/recipients.ts lines 6-12 say it outright: Elazar ruled on 2026-08-22 that coordination notifications go to HIS OWN ADDRESS, so the recipient seam is filled by the COORDINATION_EMAILS literal and COORDINATION_GROUP is deliberately left null, because - quoting the file - "the standing subscription rule is still undecided, and conflating who is notified today with what the rule should be is what would make this unreadable in six months." The comment is right, and the interim is working. What has no owner is the standing rule. WHY IT NEEDED ITS OWN ROW RATHER THAN LIVING ON TERRA-59. It WAS on TERRA-59 - "COORDINATION_GROUP permanece sin decision, aunque el literal individual existente resuelve destinatario por la primera rama" - and that sentence is now reachable only inside a descriptionChanged event, as preserved "was:" text, because the description was rewritten on 2026-09-10. TERRA-59's current description and blockedReason do not mention it at all; that row is now scoped to an authenticated exercise of the access-request path. So the question did not go unrecorded, it went UNREADABLE: descriptionChanged keeps the old body in the log, which is correct and is why the trail exists, but nothing that lists or triages rows will ever surface it. A question that survives only in a superseded field is indistinguishable from one that was dropped. THE DECISION NEEDED, and it is Elazar's, not this lane's: when someone other than Elazar should receive coordination notifications, WHO is that - a named list, or a membership rule? The file already argues, correctly, why it must not be the admin group: admin is AUTHORIZATION data, not NOTIFICATION-SUBSCRIPTION data, so joining on it mails every future terra admin including ones added for unrelated reasons, and outbound mail to the wrong humans is not revertible in one commit. That reasoning survives the 2026-08-22 ruling and should not be re-litigated; what is missing is the positive answer. WHY IT IS NOT URGENT AND STILL WORTH A ROW. Nothing is broken: the literal resolves a recipient on the first branch and mail reaches someone today. The cost is entirely forward - the day the catedra wants a second recipient, the answer has to be invented by whoever is holding the keyboard, which is the shape this project keeps recording as a defect. Precedent on this exact board: src/lib/route-access.ts carried a comment declaring the catalog visibility list to be the catedra's only open decision, and it sat untracked in source until it became TERRA-175. NOTHING IS AUTHORISED TO START. No code change is wanted. The value of this row is that the question is queryable.
Activity
-
Needs Elazar's ruling on the STANDING rule, not on today's recipient. The interim is decided and working - COORDINATION_EMAILS carries his own address per his 2026-08-22 ruling - so nothing is broken and nothing is authorised to start. Unblocks when he names who receives coordination notifications when it is not him: a named list, or a membership rule. The file's own argument against reusing the admin group stands and is not being re-litigated (admin is AUTHORIZATION data, not NOTIFICATION-SUBSCRIPTION data; joining on it mails every future terra admin, and wrong outbound mail is not revertible in one commit). What is missing is only the positive answer. No code change is wanted on this row; its value is that the question is queryable instead of living in a code comment and a superseded TERRA-59 description.
-
coder-terra-cc
-
RULE DECIDED, LIST STILL ELAZAR'S. Marker: T214-dec-mtwz06. Terra PM lane 2026-09-11 under Elazar's 09:27 ART standing delegation. THE ROW MIXES A POLICY AND A FACT, and only one of them is mine. POLICY - DECIDED, NO CODE CHANGE: access-request notifications go to a STANDING subscription group, not to a per-event recipient computed at send time. The interim COORDINATION_EMAILS list is the correct mechanism and stays; COORDINATION_GROUP being null is a missing VALUE, not a missing design. Nothing in src/lib/access-notify-core.ts needs to change to accept an answer - sourceUndecided is exactly the outcome code for "the list has not been populated", and it will stop firing the moment it is. FACT - NOT MINE, AND THE DELEGATION DOES NOT MOVE IT: who belongs to "la coordinacion de la Especialidad en Implantologia" is knowledge only Elazar or Puia holds. A delegation of authority is not a delegation of knowledge. I checked whether the client communications name them - pm/05-client-info.md item 7 was RESOLVED by Elazar on 2026-07-30 (bs-ms7a0y9u7e2) with "no address, no per-catedra human lookup: a self-service form, submissions relay to staff", which decides what the REFUSAL PAGE shows and deliberately skips the "who answers" question. It does not name the staff. So the name is still unheld by anyone in this lane. THIS ROW STAYS BLOCKED ON ONE THING ONLY: the list. It is in pmmaster-evolutiva-cc's single batched ask to Elazar alongside eq 94 (the SMTP_REPLY_TO mailbox) - both are the same mail circuit and both are values only he can supply. Do not re-send it separately.
-
PROVENANCE NOTE - THIS ROW'S CODE CHANGE IS INSIDE A COMMIT THAT DOES NOT NAME IT. Marker: T-prov-mtwz10. The local commit def2e64, whose message reads "db(TERRA-199): declarar NO TAG razonado en las 13 migraciones que la compuerta de citas rechaza", carries the work of THREE agents, not one. Its file list: - db-terra-cc's TERRA-199 migration headers (13 files) - what the message describes. - coder-terra-cc's TERRA-214 comment corrections: src/lib/email/recipients.ts, src/lib/support-queue.ts. - coder03-terra-cc's TERRA-218 implementation: src/lib/downscale-image.ts, downscale-image-core.ts, downscale-image-core.test.ts, src/components/practica-form.tsx, src/hooks/use-action-form.ts, src/lib/friction-codes.ts, friction-toast-coverage.test.ts, next.config.ts. HOW: gitpush.sh v4.14 stages the --only paths BEFORE running .gitpush-pre.sh, so the hook sees a real index. When the hook FAILS, the paths stay staged and the tree is left dirty-in-index. My run failed on "Another next build process is already running" - a concurrent agent's build - and left my two files staged. The next agent's gitpush.sh then ran `git add -- <its own paths>` and `git commit`, and git commits THE WHOLE INDEX, not just the paths just added. Three agents' work, one message, one author line. NOTHING IS LOST AND NOTHING IS WRONG IN THE CONTENT. Verified: def2e64:src/lib/email/recipients.ts contains "THE RULE IS NOW DECIDED" and def2e64:src/lib/support-queue.ts contains "TERRA-214 then". The working tree is identical to HEAD. The defect is in ATTRIBUTION, not in the code. NOT SPLITTING IT. def2e64 is unpushed (0 ahead of origin/main by the left-right count at the time of writing, i.e. origin has not seen it). Rewriting it would mean rebasing a commit another agent authored and is about to push, to fix a message - worse than the problem. It gets pushed as is, and this note is how the three rows stay findable from their own side. REPORTED as a gitpush.sh defect rather than a local accident, because the failure mode is fleet-wide: any hook failure on a strict repo silently loads the next agent's commit with the previous agent's files.
-
T214-schema-mtx6w - THE SCHEMA HALF. Answer to 'can anything in terra answer who gets notified about X': NO, AND THE SEAM AS BUILT CANNOT HOLD THE ANSWER EITHER. 1) NOTHING CAN ANSWER IT, and the gap is the X rather than the who. Terra has exactly two recipient sources, both in src/lib/email/recipients.ts: a COORDINATION_EMAILS literal (wins when non-empty) and a nullable COORDINATION_GROUP fed to a vUserGroups."group" predicate. Neither is parameterised by an event class. There is one recipient set for the whole app, so the question 'who gets notified about X' has no X to bind - the only queries terra can express are 'who is in group G' and 'what is in this literal'. A second notification class with a different audience cannot be expressed at all; it would be a second constant. 2) THE SEAM CAN ONLY HOLD AN AUTHORIZATION VALUE, which is the structural half of the same finding audit-terra-ca made about semantics. COORDINATION_GROUP is fed to vUserGroups."group", so the ONLY thing that can be written there is a userGroups membership value - the same table and the same column terra's route gates read. Filling it means minting a group value whose meaning is 'subscribed', living beside values whose meaning is 'permitted', in a structure every gate in the app iterates. ownerAppKey narrows visibility to terra but does not change what the row IS. So the decision Elazar is being asked for cannot be implemented as specified without overloading userGroups with a second meaning - which is precisely the conflation the ruling forbade, arriving through the storage instead of through the query. 3) WHAT A SUBSCRIPTION STRUCTURE WOULD HAVE TO BE, stated so the decision has somewhere to land: a row per (appKey, notificationClass, userId) with its own lifecycle - fromAt/toAt like userGroups, since unsubscribing must be a fact and not a deletion - and NO overlap with userGroups. The notificationClass is the X that does not exist today. Under that shape, adding a coordinator to the class is the act that subscribes them, which is the property the current design claims and cannot exercise: live admin cardinality is ONE (db02-terra-cc, terra_189), so a live read and a hard-coded address are behaviourally identical and the benefit is STRUCTURALLY UNEXERCISED. 4) NOT PROPOSING TO BUILD IT. One recipient, one class, one literal that works. The point of recording this is that the null in COORDINATION_GROUP reads as 'a value nobody has supplied', and it is actually 'a value that has nowhere correct to go'. Those need different answers from Elazar: the first is a list of names, the second is a decision to build a table first. Split out as its own row per pmmaster. Filed as TERRA-237.
-
T214-ref-mtx6x - CORRECTION to T214-schema-mtx6w: the structural row is TERRA-239, not TERRA-237. I wrote the ref before the row existed and wi assigned the next number; TERRA-237 is somebody else's. Recording rather than rewriting - a wrong cross-reference is corrected in the log, and the wrong number stays visible so anyone who followed it can see why it did not lead here.
-
RULED 2026-10-06 (blackboard bb-pmmaster-evolutiva-cc-muw8o371-0prqak, 4/4 - all four agreed this row is independent of the practica-authorship cluster it was filed beside). Notification subscription is about who gets TOLD; it has no bearing on who may ASSERT. It sat next to those rows because it was also 'undecided and surviving only in a code comment', which is a provenance similarity, not a subject one. STANDING RULE: coordination notifications are subscribed BY ROLE, never by a named person or a hardcoded address. COORDINATION_GROUP is resolved from that role against the live role table AT SEND TIME. Reasons: a named address goes stale silently the moment the person changes, and the fleet rule that a role claim read from a snapshot is a cache rather than a gating source applies to routing for the same reason it applies to authz - the live table is the only thing that is true now. SECOND, AND INDEPENDENT OF THE POLICY: a null COORDINATION_GROUP currently FAILS SILENTLY. That is a defect regardless of which rule wins, and it is why this question survived for months as a comment instead of as an incident - nothing ever complained. Resolve to zero recipients -> emit a warning-level appEvent naming the role that resolved empty. A notification rail with no recipients must say so; an all-clear needs a reachable threshold, and a send path that cannot report 'nobody' has no threshold at all. The interim (COORDINATION_GROUP set explicitly) keeps working until the role resolution lands - do not remove it first and leave the rail dark. Tier: Class-A, it is on the email-send path. Diff to audit before push.
-
Ruled 2026-10-06 by pmmaster-evolutiva-cc on a 4/4 blackboard - did not need Elazar. Subscribe by ROLE resolved live at send time, never a named person; plus a warning appEvent when the role resolves to zero recipients, because the current silent-null is why this survived as a code comment. Interim stays until role resolution lands. Class-A, email-send path.
-
t214-code-0533: pmmaster's ruling (muw8sjee63lu) is built already except for one value. The resolver is at src/lib/email/recipients.ts:122-149. It resolves LIVE at send time by group via vUsersAdmin JOIN vUserGroups. A null group returns sourceUndecided, and zero members returns none. Both log email:noRecipients at warn, and queryFailed at error (access-notify-core.ts:169-181), so the rail is not silent. COORDINATION_EMAILS has precedence and stays as the interim. MISSING: the role value. Terra's group vocabulary is admin, alumno, bedel, client, docente, jtp. None means coordination, and admin was refused as authorization data, not subscription data. Options: (A) mint a 'coordinacion' group value, which is a shared lookupOptions row and needs a db-enamel-cc GO, plus grants; (B) rule an existing role. Membership is knowledge only Elazar or the cátedra holds. No code change until the value is named.
-
MK214B verified db-enamel-ca-muw950pwox16: vUserGroups.group = public.groups.value (joined via userGroups.groupId, scoped by groups.ownerAppKey NULL or = appKey), not lookupOptions. recipients.ts:139 joins vUserGroups, so the coordinacion group must be a groups row (ownerAppKey='terra') with userGroups grants, not a lookupOptions row. App side unchanged: set COORDINATION_GROUP='coordinacion' once that row exists.
-
PRE-WRITE Class-A design finding: value=coordinacion belongs to public.groups (ownerAppKey=terra), not lookupOptions, because recipients.ts resolves vUserGroups.group. Yet a coordinacion-only userGroups subscription grant is also a live Terra membership; current createTerraPractica (terra_234:140-149) and lookupTerraPaciente (enamel_013:51-59) authorize ANY Terra membership, so a notification-only recipient could gain clinical write/identity-lookup reach. Zero-grant seed is inert but intended grants activate this coupling. Holding DB seed/grants pending audit-general design ruling, tag db-enamel-ca-muw9hl452dh3; PM informed. No SQL change.
-
AUDIT DESIGN BLOCK (audit-general-ca-muw9jdjqhkpu): do not seed/activate/grant public.groups value=coordinacion as a usable subscription yet. An active Terra-owned groups row immediately appears in the Enamel grant picker; zero grants at seed time is not structural containment. Current ordinary Terra UI requires PRACTICA_ROLES/PACIENTE_CREATE_ROLES, so this is not a claim that coordinacion-only reaches the normal UI. The shared DB createTerraPractica gate still accepts any live Terra membership for the named actor, and future subscription grants would pass it. Choices: separate notification subscription relation with no auth membership, or inactive/ungrantable DB-enforced hold until clinical writer predicates are narrowed and all any-member gates audited. COORDINATION_EMAILS remains. No group seed or grant applied. TERRA-277 carries clinical gate work.
-
PM correction pmmaster-evolutiva-cc-muw9annd3v8g: do NOT add lookupOptions coordinacion value. recipients.ts reads vUserGroups.group from public.groups, so lookupOptions would have no consumer. DB half is scoped public.groups value plus userGroups grants; interim COORDINATION_EMAILS remains until grants exist. Prior option A lookupOptions object was wrong.
-
CORRECTION to db-terra-ca event 2026-10-06T06:02:18Z: groups is the correct object type, but audit-general-ca design BLOCK muw9jdjqhkpu and PM's TERRA-277 gate SUPERSEDE any active coordinacion seed/grant now. An active terra-owned public.groups row immediately enters Enamel's grant picker; zero grants does not structurally contain it because clinical DB writers accept any Terra membership. DO NOT seed, activate or grant coordinacion until TERRA-277's clinical-write membership gate and audit release condition land. COORDINATION_EMAILS interim remains. No DB write authorized by this row.
decision
5w ago by wi-cli-venus
1w ago