EVO-83 terra leg: change-requests + client-questions surface, and settle who the terra client principal is
Terra leg of EVO-83 (fleet CR + client-questions surface). EVO-83 holds the full spec and every design constraint is already settled there - two tables not one, do NOT extend supportTickets, no enums in DB or TS (lookupOptions groups, terminality via lookupOptions.params.terminal exactly as supportTicketStatus does), English camelCase identifiers with Spanish UI copy, soft-delete plus vActive* view, updatedAt maintained by a BEFORE UPDATE trigger from the start, server-action auth gates rather than RLS, mutation-wrapper plus friction telemetry. Do not relitigate any of those; read EVO-83 and implement. TWO SURFACES, opposite directions of authorship: (1) CHANGE REQUESTS, the client writes and we triage - status, priority, our response, optional link to the implementing WI ref; (2) QUESTIONS, we write and the client answers - question text authored by staff, answer authored by client, answeredAt set when the client responds. THE ONE GENUINELY OPEN QUESTION, and it is Class-A because it is an auth surface: WHO IS THE CLIENT PRINCIPAL ON TERRA. EVO-83 records that venus has no client-facing role distinct from titular and parks the question there. Terra is not venus and may already have the answer in its own role model - so answer it FROM TERRA CODE rather than parking it again. Read terra existing roles and the practica/access-request gates, state which existing role is the client or that a new one is required, and put that in writing before any schema lands. audit-terra-cc is the Class-A design reviewer for this and must sign the principal decision specifically, not the feature as a whole. WHY YOU: coder03-terra-cc holds zero assigned work as of 2026-09-12 while coder-terra-cc and coder02-terra-cc each carry seven open items, and EVO-83 names terra as one of the two apps that need this most (Elazar, 2026-07-30). WHY NOW: EVO-83 has sat inProgress 23 days with a PM as its assignee, and a PM does not push code - the parent was never going to move without a coder on it. GO is given on Elazar behalf under his standing grant; no further confirmation needed. Definition of done is code pushed and working, not a design doc.
Activity
-
parent=EVO-83
-
CANCELLED BY ITS AUTHOR. I filed this against a standing Elazar ruling and coder03-terra-cc caught it before any DDL was written. Elazar ruled 2026-07-31 on EVO-83, verbatim via coder-venus-cc: '2 yes central'. ARCHITECTURE IS CENTRAL - store in enamel's DB, appKey-scoped rows, ONE portal UI, clinical apps carry a link and nothing else, and PER-APP COPIES ARE OFF. His cited precedent was the per-project SOP ticket copy: 'have to maintain 3 things that should work the same.' Terra's leg under that ruling is exactly 'row usable + link. No authoring surfaces', and TERRA-1 delivered precisely that and is done. So TERRA-243 as written - two local tables plus auth-gated CR and question routes in terra - is the second copy the ruling exists to prevent. HOW I GOT IT WRONG, recorded because this item's own event log warned about it: I read EVO-83's DESCRIPTION and not its EVENTS. The description still carries the 2026-07-30 framing in which the client principal is open and each app builds its own surface; the events carry four Elazar decisions from 2026-07-31 that supersede it, and the 2026-08-19 unblock states plainly that both TERRA-1 and VENUS-317 are done and only enamel's build remains. EVO-83's own durable note says it: a doc is authoritative about INTENT and never about STATE. A work item's description is a doc. The check is not whether the source is trustworthy but whether the claim asserts current state - and a stale description is worse than a stale doc because the current state is sitting in the same record, one command away. WHAT SURVIVES THIS ITEM: coder03-terra-cc closed the client-principal question from terra's code in minutes, and the answer stands independently of the cancellation - terra already has a dedicated 'client' group in public.groups, wired through auth.ts, nav.ts, route-access (client -> /panel, informes aggregate-only, roster and patient data refused) and confirm-actions role checks. No new role needed. Puia's terra row already holds it with userGroups.fromAt == users.createdAt. That matches the 2026-07-31 ruling exactly - a dedicated value carrying nothing else - and it is a live re-verification of TERRA-1's done state rather than a restatement of it. THE REAL GAP IS NOT TERRA: the enamel leg, which owns the build under the central ruling, never got a coder. Filed separately and assigned. That is the 23-day stall, and filing a terra copy would have hidden it rather than fixed it.