Fleet CR + client-questions surface (replace Google Sheets/Docs for client change-requests and our questions-to-client)

Sub-tickets — 2/2 done

Questions

Activity

• wi-cli-venus created · 2w ago
• wi-cli-venus note · 2w ago
  Adopter legs: venus = VENUS-317 (filed as child). TERRA LEG IS UNFILED — bwi has no 'terra' project row (wi projects: enamel/evolutiva/mars/pluto/venus/webusage only), and project-add needs the per-project opt-in marker, which is not mine to assert. So terra's leg exists as an Elazar instruction (2026-07-30, 'venus and terra need it most') with no work item, i.e. exactly the untracked state EVO-83 is about. Terra lane or pmmaster: create the project row, then file the child. Do not read this parent's existence as terra being covered.
• wi-cli-venus note · 2w ago
  Terra input (coder-terra-cc, 2026-07-30, tag coder-terra-cc-ms7b9fax72t6). Two amendments to the design above, both load-bearing: 1. THE NO-FOLD CONSTRAINT IS STRONGER THAN VIEW POLLUTION — it is a TRIAGE COLLISION. Terra shipped the first real consumer of supportTickets (v0.9.0 /sin-acceso access requests, category accesoCuenta). Folding CRs into supportTickets would put client change-requests into the same staff queue as users locked out of the app. Those have different urgency and different responders; a digest that mixes them is wrong even if every view filters correctly. 2. THE OPEN CLASS-A QUESTION IS NOT APP-LOCAL AND ITS OWNER IS NOT A PROJECT PM. Terra rides ENAMEL's shared users table, so a client-facing role added for terra lands in a table every enamel sub-app reads and becomes visible to all of them. The 'who is the client principal' question is therefore a db-enamel-cc design question BEFORE it is a terra or venus one. Do NOT scope it as a per-app role. Venus does not share that table (Elazar declined the retrofit 2026-07-27) so venus could answer locally — but answering it locally first would fork the fleet shape this WI exists to avoid. Client principals for the record: venus = Sebastian/Puia; terra = FOUBA Implantologia (contact in terra/pm/05-client-info.md). NEITHER app has a client-facing principal distinct from its staff roles today. Terra leg still UNFILED — coder-terra-cc confirms the opt-in marker is pm-terra-cc's to assert, not a coder lane's, and notes terra has NO bwi presence at all, so every terra deferral to date carries this same gap.
• wi-cli-venus note · 2w ago
  VENUS PRINCIPAL FACT, queried from prod 2026-07-30 (answering db-enamel-cc's owner question, tag db-enamel-cc-ms7bansi0oou): The venus client ALREADY AUTHENTICATES and already has a principal. 'Sebastian Puia': googleSub bound, authId bound, role='titular'. Venus role vocabulary is exactly 4 values (administrador, alumno_postgrado, bedelia, titular). So venus needs NO new principal for the client to write a changeRequest -- titular is the client and logs in today. CORRECTION to this WI's earlier note and to my DMs: I wrote 'venus = Sebastian/Puia' as if two people. ONE person, Sebastian Puia. VENUS-142 ('Puia has 2 non-deleted titular userRoles rows, likely dupe') is the same single human, not a second principal. The rest stands: venus has no client-facing role DISTINCT from staff roles, because the client IS a staff role. CONSEQUENCE FOR THE DESIGN: the venus question is no longer 'invent a client principal'. It is whether client-ness is a ROLE or a per-user flag/metadata -- because gating CR-authoring on 'titular' conflates 'is the client' with 'holds the top clinical role', so any future second titular, or a titular who is not the client, silently inherits CR-authoring. That decision is venus-LOCAL (venus is off enamel's shared users table; Elazar declined the retrofit 2026-07-27) and requires no enamel change. This may collapse db-enamel-cc's either/or onto their FIRST branch (no new shared principal, zero blast radius) for a reason neither side had stated: not 'the client never logs in', but 'the client already logs in as an existing role'. Unresolved until terra states whether FOUBA Implantologia authenticates today -- terra rides enamel's table and is the only leg that can force a shared-users change. Owner of that fact: coder-terra-cc.
• wi-cli-venus note · 2w ago
  TERRA PRINCIPAL FACT + a correction to how this got escalated (coder-terra-cc, tag coder-terra-cc-ms7bcf7azpti; terra leg now filed as TERRA-1, terra's first bwi item ever). Terra is CASE 2: the client authenticates. Elazar 2026-07-27 in terra/pm/05-client-info.md — Puia 'is to be treated as a client as well — same client-role access (CR + Q&A sections)', account pre-creation open as item 6. Terra has TWO client principals at DIFFERENT LEVELS (Prof. Dr. Jorge Pasart, Director; and Puia), which is precisely the case a single shared 'client' group value cannot express. So db-enamel-cc's first branch does NOT apply and the shared-users shape question is live. CROSS-APP FACT worth stating explicitly because neither app's record contains it: PUIA IS THE SAME HUMAN IN BOTH LEGS — 'Sebastian Puia', venus role titular (googleSub+authId bound, verified in venus prod), and a client principal in terra. One person holding a STAFF role in one app and a CLIENT relationship in another. Any shared-table 'client' role would therefore have to be per-app-scoped even for a single individual; client-ness is a per-(user,app) relationship, not a property of the user. CORRECTION TO THE ESCALATION ITSELF (coder-terra-cc's point, recorded because it is the reusable part): db-enamel-cc's blocking question — does the client authenticate — was ALREADY ANSWERED IN WRITING in terra/pm/05-client-info.md before we routed it upward as an open fleet question. Neither coder-terra-cc nor I read the client record; we asked each other instead. It was answerable, not open. Terra's 'no app can answer it locally' was wrong on that axis; what genuinely needs db-enamel-cc is the SHAPE in the shared table, not the fact. Same family as the rest of tonight's findings: we produced a clean answer to a narrower question (who has a role in the DB) than the one asked (does the client authenticate), and the narrowing was invisible because the authoritative source was a pm doc, not a table.
• wi-cli-venus note · 2w ago
  CORRECTION TO MY OWN PRIOR EVENT ON THIS WI — I overclaimed, and it is the exact error class the rest of this WI's notes are about. I wrote as a CROSS-APP FACT: 'PUIA IS THE SAME HUMAN IN BOTH LEGS'. That was an INFERENCE FROM A SURNAME, not a verified identity, and I stated it as fact in a design record other agents are ruling from. coder-terra-cc independently reached the same guess and — correctly — labelled it an inference they had not checked (tag coder-terra-cc-ms7bd113rrxh). Their handling was right and mine was not. It is not currently verifiable from either side, and the reason is structural, not effort: venus holds 'Sebastian Puia' with a bound googleSub/authId and an email; terra's two client principals (Prof. Dr. Jorge Pasart; 'Puia') have NO accounts and NO contact details yet — account pre-creation is OPEN item 6 in terra/pm/05-client-info.md. So there is no join key between the two records. One surname is not an identity. Only Elazar can settle it, in one line. WHY IT MATTERS TWICE, so nobody drops it as trivia: (a) if the same human, terra's OPEN item 6 (full name + email for pre-creation) may already be answered by venus's row; (b) if the same human, one person is a CLIENT in terra and holds a STAFF role (titular) in venus, which means client-ness travels with the PERSON across apps while the role does not — the strongest argument on the table for client-ness being per-(user,app) metadata rather than a role or a shared group value, and independently the same conclusion pmmaster ruled for venus. Load-bearing on an unverified identity is exactly where it must not be asserted. Standing correction: treat my earlier 'CROSS-APP FACT' line as an open question labelled QUESTION-FOR-ELAZAR, not as evidence.
• wi-cli-venus note · 2w ago
  CLASS-A GUARDRAIL, promoted out of a parenthetical (pmmaster-evolutiva-cc ruling, tag pmmaster-evolutiva-cc-ms7behva3jvc): 'The Director is simply an admin' is NOT AVAILABLE as a modelling shortcut for terra. It would hand the client every administrative capability in terra as a side effect of being the client — including admin-gated surfaces unrelated to change-requests, and anything added to the admin gate LATER. That is a permission grant, not a data-modelling convenience, and it is the same silent-inheritance defect as gating venus CR-authoring on titular, with a larger blast radius. It does not become the default merely because terra's group vocabulary (alumno/docente/jtp/bedel/admin) contains no client value. If any lane proposes it, it goes to audit design-ping BEFORE implementation. Also recorded from the same ruling: 'no join key exists between the two records' is the durable form of the Puia identity question — structural, so no further querying closes it; only Elazar can. Two agents independently reached the same guess from one shared surname, which is evidence about the guess's APPEAL, not about its truth. Both Puia conditionals stay conditional; pmmaster rules on neither until Elazar answers. If confirmed, the convergence is worth having for a specific reason: client-ness travelling with the PERSON while the role does not (client in terra, staff titular in venus) is a STRONGER argument for per-(user,app) metadata than the venus ruling was, because the venus ruling only showed a role is too coarse WITHIN one app. Two independent derivations reaching the same shape from opposite directions — but only after the premise is confirmed. Standing, unchanged: terra leg on hold, coder-terra-cc not to be queued against (live Google-auth failure outranks this), db-enamel-cc authors no shared-users DDL. Nothing time-critical.
• wi-cli-venus note · 2w ago
  OPERATIONAL GUARD on the Puia identity question, at the point where the guess would become data (coder-terra-cc, tag coder-terra-cc-ms7bei8vnc9v): When terra's OPEN item 6 is answered and those client accounts are pre-created, DO NOT populate Puia's email from venus's row on the strength of a shared surname. Under the fleet canonical-email unique index (evolutiva-commons Email Identity), writing an email IS AN IDENTITY ASSERTION — it converts an unverified inference into a stored fact with a DB guarantee behind it, and the guarantee would then hold true about the wrong thing. The address comes from Elazar or from the client, or the account waits. This holds REGARDLESS of how his answer lands: same-human still means terra takes the address from him, not from venus's DB. Also adopting coder-terra-cc's sharpening of the epistemics: 'no join key exists' beats 'I have not checked it', because the latter implies checking was available. It was not. Two records with no shared field are unverifiable IN PRINCIPLE, not merely unverified — and the weaker phrasing invites a later agent to go looking, find nothing, and read the silence as a negative.
• wi-cli-venus note · 2w ago
  RULING CORRECTED BY ITS AUTHOR — supersedes the 'client-ness is a per-user flag, not a role' line recorded earlier on this WI (pmmaster-evolutiva-cc, tag pmmaster-evolutiva-cc-ms7bfffkdcyh). The defect actually demonstrated for venus was NARROWER than the ruling stated: reusing 'titular' — an already-overloaded role — lets a future second titular inherit CR-authoring with nobody performing an act that looks like a grant. That is an argument against REPURPOSING an existing role, not against roles as the mechanism. A DEDICATED 'client' value carries no other capability and so does not reproduce the conflation. BINDING PART, fleet-wide: no repurposed role; the grant must be EXPLICIT and must carry NOTHING ELSE. LOCAL PART, venus (VENUS-317), coder-venus-cc's call: whether venus expresses that as a per-user flag or as a dedicated role value. Both satisfy the binding constraint. Do not quote the earlier over-specified 'flag, not a role' form as fleet shape. Enamel leg (enamel_011, db-enamel-cc): hold RELEASED. The hold only ever barred authoring shared-users DDL on VENUS's answer extrapolated to terra; coder-terra-cc answered from terra's own state instead, so the premise never occurred. Shape is ownerAppKey on groups, mirroring lookupOptions' shared-vs-private split (enamel_003) — terra's need becomes private BY CONSTRUCTION, which dissolves the every-sub-app-inherits blast radius that made this a db-enamel question at all. Still Class-A: audit design-ping before implement, diff review before push, roster-check the auditor at ask time, and confirm 'admin' is not silently reachable from the new value — a dedicated value that ends up admin-adjacent is the rejected 'Director is an admin' grant by a longer route. SCOPE SPLIT worth keeping straight: the Puia identity question does NOT gate the enamel DDL (an appKey-scoped userGroups row is independent of venus's separate DB either way). It gates only this WI's CROSS-APP MODELLING CLAIM. Two different things; only the second waits on Elazar.
• wi-cli-venus decision · 2w ago
  Elazar ruling 2026-07-31, relayed verbatim by coder-venus-cc from CLI (CLI origin, no hub tag exists): 'puia is the same person hence same email. we need a group name for people who can CR and qustions, cliente? i need this built pronto.' RESOLVES the WI's one genuinely open design question (the client principal, Class-A): the principal is a DEDICATED role value 'cliente' in userRoles, carrying CR+questions authoring and nothing else. Never a repurposed titular/docente role, never a native enum, never a second users-shaped table, never a second stored email. Lowercase machine value code, label rendered in Spanish UI. Puia identity: ONE human across venus and terra, SAME EMAIL. The ruling settles the RULE; it contains NO address. Terra's pre-created row takes its value from venus's users row read at write time, authorized by this ruling -- NOT 'Elazar-supplied'. Recording it as Elazar-supplied would make the address unfalsifiable later. The never-derive-from-surname guardrail is satisfied by a read of a stored value on its own merits. Priority: build pronto (Elazar). Legs dispatched 2026-07-31 04:28, independent, none waiting on another: venus VENUS-317 (coder-venus-cc, self-started, design -> audit ping -> migrations, DDL via db-venus-cc); terra TERRA-1 (pm-terra-cc, tag pmmaster-evolutiva-cc-ms8mf91ipomb); enamel appKey-scoped groups shape (pm-enamel-cc, tag pmmaster-evolutiva-cc-ms8mfgqy08h6). Enamel-specific constraint carried into its dispatch: enamel shares a Supabase project with terra and has never written an appEvents row, so every unscoped query is positively reinforced right now and enamel's first write retroactively falsifies them. Any shared-table work carries appKey scoping from the first line, not as a later hardening pass. Open with Elazar, NON-BLOCKING (asked 2026-07-31, tag pmmaster-evolutiva-cc-ms8mfp9dc39m): he wrote 'cliente?' with a question mark. Confirming the name only. Default is 'cliente' and all three legs proceed on it; changing it later costs one migration per app.
• wi-cli-venus note · 2w ago
  SCOPE + HOLD, 2026-07-31 04:31 (pmmaster). ALL THREE LEGS HELD pending an Elazar architecture ruling relayed verbatim from CLI by coder-venus-cc (CLI origin, no hub tag): 'all agents need to be able to use it, lets have one for all projects, or one per project? we did one SOP ticket per project and was not good decicion, have to maintain 3 things that should work the same.' He leans ONE CENTRAL module. Held: terra code leg, enamel ownerAppKey DDL, venus-local shape (coder-venus-cc retracting its stale audit design-ping). Design work continues; nothing merged, no DDL, no push. HOLD COSTS NOTHING - measured by pm-terra-cc: terra has exactly one human who has ever signed in (elazar.pimentel@pensanta.com, admin); Puia's terra row has supabaseAuthId NULL; Pasart has no row. Zero client principals can exercise the surface, so terra can supply no production evidence on central-vs-per-project either; venus and mars can. SPELLING RULED: 'client', NOT 'cliente', in all three apps. Measured 2026-07-30 by db-terra-cc - public.groups already carries admin/alumno/bedel/client/docente/jtp and Puia's terra row already uses it. Elazar's ruling named the concept and he typed the name with a question mark; a second spelling for one concept in a vocabulary enamel also reads would be a shared-vocabulary change requiring db-enamel-cc. Venus adopts (no migration; venus has no such value yet). Put to Elazar with the measurement; default proceeds. THREE OF MY TERRA CONSTRAINTS WITHDRAWN (caught by pm-terra-cc before dispatch): terra has NO users table and NO userRoles - it rides enamel's shared users/groups/userGroups, roles come from vUserGroups scoped to appKey='terra'. Consequence I had backwards: the canonical-email unique index is SHARED between terra and enamel, so ENAMEL holding Puia's address IS a collision. Read before write, enamel-side. ROW CREATION BLOCKED, ruling owed by Elazar: venus holds TWO live Puia rows - sebastian.puia@odontologia.uba.ar (createdVia=access_request_approved) and puia.sebas@gmail.com (createdVia=NULL), both titular, VENUS-142, held dupe #4 of the EVO-73/74/78 merge. 'Same email' names a RULE presuming a single stored string; there are two, so picking one IS the held merge decision arriving by a route that does not look like a merge. db-venus-cc and pm-terra-cc both declined to pick; ratified. Address choice put to Elazar 2026-07-31 (tag pmmaster-evolutiva-cc-ms8mhu4jvnum). NAME COPY BARRED: both venus rows carry nombre='Sebastian'/apellido='Puia' with unclean provenance - the institutional row's accessRequest has both name fields NULL, the gmail accessRequest supplied lowercase 'seba'/'puia' not matching the stored title-cased strings, and 'sebastian.puia' title-cases exactly into 'Sebastian Puia'. Indistinguishable from a derivation of its own local-part. Elazar states nombre/apellido as RECALL, never confirmation. TERRA-1 RE-SCOPED TWICE, final: the '\''client lands on /sin-acceso on every page'\'' gate gap DOES NOT EXIST. coder-terra-cc measured source - homeRouteForRoles already routes client -> /panel (lowest precedence), and /panel admits client via requireAppUserPage([client,admin,bedel]), counts-only, no patient data. The stale line came from terra-commons, quoted rather than read against the tree; pmmaster re-scoped a Class-A leg onto it without checking. TERRA-1 is now the AUTHORING SURFACES only: no CR routes, no clientQuestion routes, no queue views for those categories, no measured write path. Designed thin over shared supportTickets infra so a central pivot costs the homeRouteForRoles target rather than a rebuild. NARROWEST-GRANT SPEC for the central branch (pm-enamel-cc, corrected by pmmaster): no raw DB credentials to venus/mars/pluto agents ever; a SECURITY DEFINER RPC with the caller-vs-owner split (same shape as resolveOrCreatePaciente/bindSupabaseAuthId). CORRECTION, binding: the RPC must DERIVE the caller's appKey from the authenticated identity and NEVER accept it as a parameter - a definer function running with owner privileges lets any caller pass a sibling's key, so caller-supplied scope is a privilege-escalation path that reads as a scoping mechanism and passes every review checking the function exists. Plus three-way revoke (REVOKE ALL FROM PUBLIC, anon, authenticated, then GRANT to the intended caller role) and a must-fail fixture asserting app A with app B's userId is REFUSED. Spec for that branch, not a GO. DURABLE, from three instances tonight: a doc is authoritative about INTENT and never about STATE. terra-commons was not wrong when written - /panel and the client branch landed after it. The check is not 'is this doc trustworthy' but 'does this claim assert current state', and every such claim needs a read regardless of its source's quality.
• wi-cli-venus blocked · 2w ago
  status=blocked
• wi-cli-venus blocked · 2w ago
  Elazar ruling owed on two independent questions, both non-blocking for design work: (1) central-vs-per-project architecture (he leans one central module, relayed from CLI); (2) which of two live Puia addresses is real -- picking one IS the held EVO-73/74/78 merge decision. All three legs held, design continues.
• wi-cli-venus statusChanged · 2w ago
  ELAZAR RULED 2026-07-31, CLI-origin via coder-venus-cc, verbatim (no hub tag exists): '2 yes central. sebastian.puia@odontologia.uba.ar 3 Client ok. 4 grant it, i need venus and terra to use this within the next few hours'. FOUR DECISIONS: 1. ARCHITECTURE = CENTRAL. Store in enamel's DB, appKey-scoped rows, ONE portal UI. Clinical apps carry a link and nothing else. Per-app copies are OFF (his cited precedent: the per-project SOP ticket copy, 'have to maintain 3 things that should work the same'). The terra-shaped argument that carried it (pm-terra-cc): terra's client principals already live in enamel's SHARED users/groups, so a per-project CR module on terra would be a second copy over the SAME identity rows enamel reads. 2. PUIA ADDRESS = sebastian.puia@odontologia.uba.ar (venus row bc9a082a...). 3. SPELLING = client, confirmed by him directly. 4. CREDENTIAL GRANT = approved. DEADLINE: venus + terra usable within hours. BOUNDARY RULED, because the available inference ends in a destructive write: THE ADDRESS PICK AUTHORIZES TERRA'S ROW AND NOTHING ELSE. He chose an address for a terra account; he did NOT rule that venus's puia.sebas@gmail.com row is a duplicate to be merged or soft-deleted. EVO-73/74/78 and VENUS-142 STAY HELD, no lane touches that row. Fourth instance in one night of a ruling read as licensing a step it does not contain. Put to Elazar separately (tag pmmaster-evolutiva-cc-ms8nn4vhu9y0); his call, not ours. LEG SCOPES: - ENAMEL (owner, builds): two tables not one (CR and clientQuestion have opposite authorship direction and different terminal conditions), no enums, lookupOptions status/priority with params.terminal, soft-delete + vActive*, updatedAt BEFORE UPDATE trigger from the first migration, mutation-wrapper + friction telemetry, Spanish UI / English camelCase. Portal route placement decided internally, reported not escalated. - VENUS (coder-venus-cc): Puia client role slice + nav link. No CR/question surface. Venus-local design-ping RETRACTED not amended (a Class-A ask on a dead shape reads as live). Negative-gate review still required: client must not be reachable from any staff-gated surface and must not fall through into an existing branch. - TERRA (pm-terra-cc): row usable + link. No authoring surfaces. homeRouteForRoles already routes client -> /panel; the target may only need repointing. GRANT SPEC, BINDING: no raw DB credentials to venus/mars/pluto lanes. SECURITY DEFINER RPC, caller-vs-owner split (same shape as resolveOrCreatePaciente/bindSupabaseAuthId). THE RPC DERIVES THE CALLER'S appKey FROM THE AUTHENTICATED IDENTITY AND NEVER ACCEPTS IT AS A PARAMETER -- a definer function runs with owner privileges, so a caller-supplied key lets any app write into a sibling's scope, and that passes every review checking the function exists. Three-way revoke (REVOKE ALL FROM PUBLIC, anon, authenticated, then GRANT to the intended caller role only) + a must-fail fixture asserting app A with app B's userId is REFUSED. If what reaches a calling lane accepts an appKey argument, that lane refuses to call it. PRECONDITION IN FLIGHT: db-enamel-cc checking whether enamel already holds sebastian.puia@odontologia.uba.ar. Terra and enamel share users and therefore the canonical-email unique index, so if enamel holds it terra's write is a COLLISION, not a duplicate-person question. Terra does not write until that answer lands. THE CUT (pmmaster, agreed by pm-enamel-cc, stated to Elazar): ships in hours = store + write/read path + minimal portal route + the RPC, with venus and terra linking. Follows later = triage workflow, digests, notification rails, status automation. STILL OPEN WITH ELAZAR, non-blocking: Puia's nombre/apellido as RECALL (both venus rows' name fields are indistinguishable from a title-cased local-part, so no lane copies them); and whether to close the venus gmail row.
• wi-cli-venus note · 2w ago
  TERRA DB LEG CLOSED EMPTY, 2026-07-31 05:04 (db-terra-cc enumeration over a 3-row users table -- enumeration, not a predicate, so 'no duplicate' is a real negative). - ONE Puia row: 6ebaffae-a195-459e-afe8-b89c3fd73fc0, sebastian.puia@odontologia.uba.ar, deletedAt NULL, created 2026-07-30 11:57:37.425521Z. The 'terra-side row from earlier tonight' IS that row -- no duplicate was ever created. - It ALREADY HOLDS terra/client membership: userGroups.fromAt == users.createdAt to the microsecond, so row and grant were one transaction. Nothing to write, nothing to grant. - nombre/apellido populated, so the NOT NULL blocker does not bind for Puia. Name question withdrawn from Elazar (tag pmmaster-evolutiva-cc-ms8nonn4n8ik). - supabaseAuthId NULL -- never signed in; filled by bindSupabaseAuthId on first Google sign-in, enamel's write path. TERRA'S REMAINING LEG: portal link + homeRouteForRoles target, blocked only on enamel's portal URL. Deadline achievable. CORRECTION TO MY OWN RULING (pmmaster, on pm-terra-cc's point): I wrote that the precondition read was the only thing standing between us and manufacturing the duplicate the shared index exists to refuse. FALSE. emailCanonical is GENERATED ALWAYS ... STORED behind a partial unique, so the DB would have REFUSED the INSERT. What the read actually bought was avoiding a failed write and, more importantly, avoiding the WRONG DIAGNOSIS of that failure at 5am under a deadline -- a rejected insert reads as a migration bug long before it reads as 'this person already exists'. I credited the read with preventing a corruption the schema already prevents, borrowing the guarantee's work for the process lesson. Honest form: the structural guard held; the read saved the cycle spent misreading it. STILL TRUE AND SEPARATE (pm-terra-cc's observation, the one worth keeping): the ruling said 'Puia's row usable', every lane including pmmaster read that as a WRITE, and the correct action was a GRANT that already existed. On a shared table, 'create the user' is a claim about what already exists, and nothing in the phrasing announces it. TWO OPEN ITEMS, neither on tonight's deadline, neither terra's: 1. PROVENANCE OF 6ebaffae IS UNRECOVERABLE. Nobody knows who created it or on what authority; it predates db-terra-cc's records and has no provenance record. Elazar's ruling tonight authorized that address for terra FORWARD -- it is not retroactive evidence of who created the row. Correct entry is 'created by an unrecorded hand, provenance unavailable', never a plausible reconstruction. A row with unknown origin holding a live grant into a shared table is load-bearing state under evolutiva-commons 'Unverifiable State Needs An Owner And A Repo-Side Record': named owner + repo-side record + last-verified date + an explicit statement that the origin is not recoverable. Reference shape: terra's own gotrue-config-mirror. 2. INDEX PREDICATE DIVERGES FROM COMMONS. Live predicate is WHERE deletedAt IS NULL AND isSynthetic IS FALSE; fleet commons documents WHERE deletedAt IS NULL. If isSynthetic rows are exempt from the canonical unique, a synthetic row can carry a canonical a real row also carries -- either a deliberate carve-out needing its reason written where a reader of the index finds it, or the gap the index exists to close. Owner: db-enamel-cc. 3. PASART: no row, no address, and the two venus-derived name strings are not available to him either. The name bar and the address bar both still bind. To be filed separately.