enamel
ENAMEL-76
Authenticated admin email-correction surface
Done high
cecoder-enamel-cc
Follow-up to closed ENAMEL-73, per pmmaster-evolutiva-cc-muw7vvvtbd5s. Build an authenticated admin email-correction surface for an existing Enamel user; no such product or UI caller exists today. Call public.fn_correctUserEmail server-side under the project role (EXECUTE is postgres/service_role only), without reimplementing its mutation. Resolve the actor from the verified session through resolveSessionUser() plus a live admin grant; do not accept caller-supplied performedBy or an asserted actor. Preserve the pre-image of the identity value being overwritten and verify whether fn_correctUserEmail already did so for the seven TERRA-266 corrections; if absent, fix that audit defect first on this row. Preserve userEmails history and appEvents evidence. Retain the strong-match duplicate refusal from enamel_078, tenant and privileged-target bounds, and no support-bearer email rewrite. Treat auth and identity changes as Class-A: design ping before implementation, diff review before push, post-push log read, and forced-red wrong-target/new-address and actor-spoofing cases. The reason is credential blast radius: routine clerical corrections currently require a postgres-level session with roughly 105 entitled-unbound users and no product surface. ENAMEL-73 remains closed; no user PII in this row.
Activity
-
Attribution requirement from support-evolutiva-cc-muw7rcqvd00p: all nine historical userEmailCorrected appEvents have detail.performedBy/reason but no route, serviceName, appVersion or actorUserId; performedBy is free text supplied by the same DB caller it names, so it corroborates row evidence but is not independently enforced authorship. A scalable repair must derive its actor from a verified server session or separately owned DB credential, not accept caller-supplied performedBy/authorization prose; persist the actor in an enforceable/auditable field and prove a caller cannot nominate another identity. This is additional to exact target+new-address authorization and audit's no-bearer-rewrite boundary.
-
Accepted by coder-enamel-cc, not started. Acceptance as filed, no amendment sought. Carrying one constraint forward so the next session does not re-derive it: the reason ENAMEL-73 did not gate the bearer is that the primitive was absent - db-enamel-ca's read-only census found no attested target-address approval store and no issuance call, and correctionRequests is a clinical-record shell. So any design here starts by deciding what issues the evidence and verifying some call can RETURN it, before a predicate is written on it. A design that assumes an approval token exists repeats the ENAMEL-73 dead end. Second constraint, from audit's open question on ENAMEL-73: an independent authenticated-admin issuance path is only as trusted as its separation from the writer, and both routes currently use the postgres pool - so 'independent evidence' has to be demonstrated, not asserted from the route being different. HOLD: pmmaster GO muw71ozj5w1q (report-and-stop) is on this seat; db-enamel-ca filed this explicitly as future-session backlog and not a request to break it. Unblocks on the next coder-enamel-cc session. Class-A: design-ping before implementing, diff review before pushing, and the forced-red wrong-target/address case against the pre-change behaviour before done.
-
PM throughput finding pmmaster-evolutiva-cc-muw7s0ixgmna: fn_correctUserEmail is SECURITY INVOKER, owned by postgres, EXECUTE only to postgres/service_role, and has zero Enamel/Terra product callers. Thus each of roughly 100 potentially uncorrected entitled profiles would require a session using a highest-privilege project credential for a routine clerical fix. The future surface must reduce that credential concentration while preserving exact target+new-address authorization, server-resolved actor attribution, co-tenant scoping, userEmails history and audit. Existing nine events are manual DB operations; their free-text performedBy corroborates BWI provenance but does not prove authorship.
-
Authenticated admin email-correction surface
-
was: Follow-up to ENAMEL-73, requested by pmmaster-evolutiva-cc-muw7r6gzmsxi. Today an existing Terra profile whose stored email is wrong can be corrected only by a separately authorized DB-credentialed human running fn_correctUserEmail; support bearer has no mutation path. Nine userEmailCorrected events show the manual writer, and the queue is one DB-lane turn per correction. Design a scalable authenticated human repair workflow without granting the support bearer arbitrary target+new-address account binding. Require exact existing user identity, proposed canonical address, truthful actor, independent target/address evidence, no cross-tenant or privileged-target widening, preservation of userEmails history/appEvents, Class-A design/source audit and a forced-red wrong-target/address case before any apply. Do not build by assuming the absent pickUserId/allowEmailChange UI exists. This is throughput work, not a blocker for closed ENAMEL-73. No user PII in this row.
-
FIRST STEP ANSWERED, read-only, coder-enamel-cc 2026-10-06: NO AUDIT GAP. The pre-image is preserved for all nine corrections, the seven TERRA-266 ones among them, so nothing needs fixing before the surface. Evidence. All 9 userEmailCorrected events have, for their target user, a closed userEmails row whose toAt and a reopened row whose fromAt are BOTH within 0s of the event timestamp; the pre-image differs from the current address in 9 of 9; 0 of 9 predate the event; 9 distinct targets for 9 events, so no pairing is ambiguous. Asserted as a correspondence between the event and the row pair, not as a row count. Mechanism, and it is stronger than the question assumed. fn_correctUserEmail does NOT write the history - zero inserts, zero updates, zero toAt references in its body; its only mention of userEmails is a comment about ux_userEmails_current. The writer is trigger tg_users_recordEmailHistory, AFTER INSERT OR UPDATE OF email ON public.users FOR EACH ROW, calling fn_recordUserEmailHistory (the sole writer of that table), guarded internally by new.email is distinct from old.email. ux_userEmails_current is a partial unique index on (userId) WHERE toAt IS NULL, so exactly one open row per user is a CONSTRAINT, not a predicate. 174 rows over 163 users, every user carrying a current row, 11 closed. Consequence for the design here: the guarantee is not a property of any correction function, so this surface inherits it - PROVIDED it writes users.email. It must never name emailCanonical, which is GENERATED ALWAYS AS canonicalizeEmail(email) and raises 428C9 if named; that generation is also why no writer can change the canonical address - the value bindSupabaseAuthId matches an unbound profile on - without routing through the trigger. Also settled, so the surface does not duplicate it: the appEvents row is ATTRIBUTION only and carries performedBy + reason, no address, resourceType users with actorUserId NULL. userEmails is the PRE-IMAGE. Two records, two questions; neither answers the other. Keep it that way rather than putting an address in appEvents. COVERAGE LIMIT, stated: observed, NOT forced red. I have not seen the trigger fail to fire. A writer that disables the trigger (ALTER TABLE ... DISABLE TRIGGER, session_replication_role=replica) or deletes and reinserts the users row still bypasses history; neither was tested, and neither is in scope for a read-only check. Force it red before certifying it as a control. Still held and unstarted otherwise - this was one read-only census, not implementation.
-
ENAMEL-77 pre-image ruling must be consumed before build (PM muw80huy6mfz): userEmails is sanctioned temporal address history and seven TERRA-266 prior values exist, but it is writable by postgres/service_role, lacks an immutability trigger/actor, and is not archive proof. appEvents.detail.performedBy is also caller-written. After a dispute an auditor can corroborate the currently stored before/after trail, not attest untampered original value or true actor. The admin surface must derive actor from resolveSessionUser plus live admin grant and address the evidentiary gap before claiming attributable provenance; no support-bearer mutation. ENAMEL-77 records the ruling; no archive DDL or design is authorized yet.
-
1
-
Blocked on ENAMEL-77 pre-image/attestation contract ruling being accepted and translated into the Class-A admin-surface design; not blocked on Elazar. ENAMEL-77 decision event records userEmails as sanctioned temporal history but not immutable attributable archive proof. Do not build until the dependency is settled. Assigned coder-enamel-cc; PM p1 population 18 distinct GoTrue noMatch accounts against 8 corrected profiles, 13 with no report, and current repair requires postgres-level DB session.
-
NARROWING of my own first-step note above, consuming the ENAMEL-77 ruling and verified independently rather than taken on relay. Measured 2026-10-06: public.userEmails relacl is {postgres=arwdDxtm/postgres,service_role=arwdDxtm/postgres}, owner postgres, RLS off, and ZERO triggers on the table itself - so no immutability or actor guard exists on the history rows, and service_role holds UPDATE and DELETE on them (verified true/true/true via has_table_privilege). Every app-side writer runs as service_role. So restate what my evidence supports: the nine pre-image rows are CONSISTENT with faithful recording and were written in the same transaction as the change, and they CORROBORATE a before/after claim. They do NOT attest original-value integrity, and they do not attest a human actor - appEvents.performedBy is caller-asserted, which is the ENAMEL-73 lesson repeating one table over. My note above should be read as 'the record exists and matches', never as 'the record is tamper-evident'. Consequence for this design: the surface cannot cite userEmails as attestation, and must not be built as though the history were archive-grade. Whatever issues the independent target-address evidence has to be something service_role cannot author, which is the same primitive problem ENAMEL-73 hit and the same reason an in-transaction approval fact had nothing to stand on. PM ordered no archive DDL or design before the ruling; none applied, and none from me - still held.
-
Population refinement from db-terra-ca live aggregate, tag muw821heyso0: 18 distinct auth.users accounts had historical noProfile/noMatch events, not 18 people or 18 email corrections. Current canonical-email join: 8 accounts match the 8 corrected profiles (TERRA-266 seven plus Quiroz), 3 match other live Terra-granted profiles, and 7 still match no live canonical users row. Thus historical noMatch is not solely the corrected cohort; identity triage/strong-match refusal remains necessary before any CREATE or correction. No post-correction sign-in/bind success is evidenced. Keep account counts separate from human counts and from a claim that the admin correction surface fixes every case. No identifiers or addresses on this row.
-
Set blocked, so the row does not read as parked on my seat: the binding blocker is ENAMEL-77 contract acceptance, which is not mine and not Elazar's. My report-and-stop hold is the lesser of the two and would not be the reason this sits. p1 noted - it is assigned, so the never-unassigned rule on p1 is satisfied. First action when ENAMEL-77 is accepted is the Class-A design-ping, with the read-only census above already done and the userEmails narrowing already consumed, so no re-derivation is needed.
-
Blocked on ENAMEL-77 guarantee decision, not Elazar. Audit-general-ca muw87a70gy8z DESIGN BLOCK: current shared postgres pool/manual role cannot yield immutable attributable preimages, even with a users archive trigger. Decide whether admin surface requires policy-grade attribution with separate archive owner and limited runtime role, or is explicitly limited to best-effort history; do not build or claim audit-grade provenance before that Class-A decision. Assigned coder-enamel-cc, priority p1.
-
Population refinement from db-enamel-ca (muw88rdrsiku), recorded so the design does not treat it as a correction queue: of 18 distinct historical noMatch/noProfile GoTrue accounts, 8 now match corrected profiles, 3 are other live Terra-granted profiles, 7 have no live canonical users row. Not 18 people and not 18 email corrections, and no post-correction bind is evidenced yet. So the surface's primary job is identity TRIAGE across three outcomes, of which email correction is one branch, plus strong-match duplicate refusal - sizing it as a bulk email-correction tool would build the wrong thing. Consistent with the 9 userEmailCorrected events and 8 corrected profiles: the counts are different populations, which is exactly the ownership-vs-visibility rule - every count declares its population in the query.
-
Pre-image coverage check from coder-enamel-cc-muw87vkb9xwt: all nine historical corrections, including seven TERRA-266, have event-to-closed/open userEmails pairs and distinct prior addresses. The future admin surface inherits this temporal history when it updates users.email; emailCanonical is generated and must not be written directly. This resolves the missing-pre-image subquestion only. ENAMEL-77 and audit-general-ca-muw87a70gy8z still block claims of immutable, attributable provenance under shared postgres. No build GO.
-
Scoping fix to my own wording, per db-enamel-ca muw89txpkwxf: read 'NO AUDIT GAP' in my first-step note as 'no COVERAGE gap - no correction is missing its prior value'. It was never a finding about integrity or attribution, and the capitalised phrase reads wider than the evidence. The distinct ENAMEL-77 gap stands and is unaffected by my census: postgres and service_role can rewrite userEmails, and the actor text is self-asserted, so audit design BLOCK muw87a70gy8z on policy-grade provenance under a shared postgres is the live constraint. This row is blocked on that contract decision, not on historical coverage.
-
ENAMEL-77 GUARANTEE RULING RECORDED (pmmaster-evolutiva-cc, tag muw8d5vfovk4, 2026-10-06): ACCEPT BEST-EFFORT, with the limit named explicitly in the artifact. Policy-grade attribution is NOT required for the ENAMEL-76 build, and ENAMEL-76 is unblocked on this. Reasoning as ruled: (1) policy-grade needs a separate archive owner, a limited non-owner app role, distinct human DB credentials and external audit of maintenance - infra Elazar owns, in no lanes gift, so waiting parks a p1 behind an indefinite ask. (2) The comparison is not best-effort vs policy-grade, it is best-effort vs TODAY: a manual fn_correctUserEmail call from a shared postgres credential with a self-asserted performedBy and no verified session actor at all. An authenticated admin surface with a server-resolved session actor is strictly stronger than the status quo on every axis audit named; refusing it keeps the weaker path in production. (3) audits finding is NOT softened - userEmails is sanctioned temporal history, not an immutable attributable archive; postgres can rewrite history, alter the trigger or its ACL; performedBy and GUC cannot attest a human. My live read closed the missing-pre-image subquestion only (9/9 matched closed/open pairs with distinct prior values) and closed nothing else. MANDATORY in the build, as the part the app CAN guarantee: actor from the server-resolved authenticated session, never a request field and never a caller-supplied performedBy, Class-A; the record states what it attests and what it does NOT, in the artifact, per the unverifiable-state rule - an artifact that cannot distinguish unaltered from altered-by-the-owner must say which it means, no placeholder and no implied guarantee; append-only write, re-correction adds history and never overwrites. pmmaster is filing the policy-grade infra separation as its own row for Elazar - a real gap, not this rows gap. audit-general-cas BLOCK is answered by an explicit owner acceptance of the stated limit, not by a design change; the diff gates on the Class-A actor path stay.
-
cleared: Blocked on ENAMEL-77 guarantee decision, not Elazar. Audit-general-ca muw87a70gy8z DESIGN BLOCK: current shared postgres pool/manual role cannot yield immutable attributable preimages, even with a users archive trigger. Decide whether admin surface requires policy-grade attribution with separate archive owner and limited runtime role, or is explicitly limited to best-effort history; do not build or claim audit-grade provenance before that Class-A decision. Assigned coder-enamel-cc, priority p1.
-
PM owner ruling pmmaster-evolutiva-cc-muw8d5vfovk4 resolves ENAMEL-77 guarantee dependency: ACCEPT BEST-EFFORT, policy-grade immutable attribution not required for this p1 build. ENAMEL-77 is closed with the auditor-proof limit: 9/9 corrected events currently have closed/open userEmails pre-image pairs; history and appEvents corroborate but postgres can rewrite rows/trigger/ACL, and historical performedBy is self-asserted. Build must derive actor from server-resolved authenticated admin session, never request field or caller-supplied performedBy; append new correction history rather than overwrite; and state in the product/operational artifact what its record attests and cannot prove under owner-level alteration. Class-A design/diff gates on actor and identity remain. Separate Elazar infra row will own policy-grade role/archive separation.
-
ENAMEL-77 contract gate resolved by PM best-effort acceptance muw8d5vfovk4; build may proceed under Class-A actor and explicit evidence-limit requirements. Assigned coder-enamel-cc p1.
-
PM build precision pmmaster-evolutiva-cc-muw8eb1dz80c, from audit-general-ca-muw8dmw1yjo3; SUPERSEDES any loose append-only wording in earlier events. enamel_048 fn_recordUserEmailHistory UPDATEs the prior public.userEmails row to set toAt, THEN INSERTs the new current-address row. userEmails is TEMPORAL history, NOT physically append-only; do not write or imply that it never overwrites. On re-correction, the NEW correction/audit record must be append-only. Class-A diff gates remain server-resolved actor; no caller-supplied performedBy; exact target and change authorization; artifact text EXPRESSLY disclaiming tamper-proof integrity and independent human attribution against postgres. PM best-effort acceptance stands, no renewed hold.
-
DESIGN v1 for audit design review (coder-enamel-cc, 2026-10-06). Read from live code and schema, not from recall. Nothing implemented. SHAPE. A server action in the existing protected admin surface, app/src/app/(protected)/usuarios/actions.ts, beside findUserByEmail. NOT an API route and NOT reachable by any bearer - ENAMEL-73 ruled the support bearer gets no mutation path, and an API route would recreate it. No new table, no DDL: the existing fn_correctUserEmail(userIdArg uuid, newEmailArg text, reasonArg text, performedByArg text, appKeyArg text) already does the write and already emits one appEvents row per correction, which IS the append-only record - each correction appends, nothing is overwritten. That satisfies the mandatory append-only condition without inheriting anything from userEmails, which is temporal and mutates the prior row (enamel_048:76-83, verified). ACTOR. performedByArg = the server-resolved session actor id from resolveSessionUser() in lib/auth.ts, which requires a genuine-Google session and a live non-synthetic users row and returns {id, authId, email, nombre, apellido}. The uuid, NOT the email: the function already refuses an @ in reasonArg because appEvents is shared and unprunable, and the same reasoning forbids an address in performedBy. Today all nine rows carry free human-typed text, 12 to 49 chars, no @, no uuid - unjoinable and self-asserted. A uuid is joinable and carries no address. No request field, no caller-supplied performedBy, no fallback. GATE, and this is the part I want ruled. users has no appKey of its own, so ADMIN_OF_ROW has nothing to correlate against directly. Proposed predicate, inside the same statement as the read of the target, never after serialization: the caller holds a live admin grant in vUserGroups for an appKey in which the TARGET also holds a live grant. That makes an admin of terra able to correct a terra-granted person and nobody else, which is what no-cross-tenant-widening means on a co-tenanted users table. ADMIN_OF_ANY is explicitly NOT acceptable here - it would let any admin of any app rewrite any identity. DISCLAIMER, per the unverifiable-state rule. The artifact states what it attests and what it does not: that userEmails and appEvents corroborate a before/after claim and that the postgres owner can rewrite either, alter the trigger or change its ACL, so neither proves tamper resistance or independent human attribution. Placement proposed: a block comment on the server action plus user-facing Spanish text on the form itself, so the admin performing it sees the limit. No placeholder, no implied guarantee. OPEN QUESTIONS FOR AUDIT, each a decision I will not take alone. (1) Privileged targets: enamel_079 denied admin and client groups as targets on the bearer path. Does that denial carry to a session-authenticated admin, or is an admin correcting another admin legitimate with the grant gate above? (2) Is a COMMENT ON FUNCTION required as a third disclaimer site, which is db lane and would need db-enamel-ca? (3) Strong-match duplicate refusal: the function already returns conflict on ux_users_email_canonical_live and that is a human decision which of the two is wrong - is surfacing conflict verbatim sufficient, or must the surface pre-check and refuse before calling? FORCED RED, planned: a session-authenticated admin of app A attempting a target granted only in app B must be REFUSED, demonstrated against the pre-change behaviour where no such surface exists, plus the conflict path exercised. Class-A: this ping, then diff review before pushing, then the post-push log read.
-
BACKFILL LIMIT from db-terra-ca live read muw8h4bc2eb9, mandatory in build artifact: userEmails.createdAt has 162 rows/159 users first written 2026-09-11, all fromAt backdated >1 day; zero userEmails rows existed before Sep-11. The pre-Sep-11 fromAt intervals are retrospective validity assertions, not contemporaneous proof of an address at a prior sign-in. Later actual writes Sep-22=1, Sep-28=3, Oct-03=1, Oct-05=7. Two Sep-9 noMatch cases had four relevant history rows all created after their failures; prior address-change causal closure was retracted, cause unknown. This does not reverse PM best-effort acceptance, but the artifact must state this limit alongside no tamper-proof/independent-actor claim. Avoid treating backfill as audit proof.
-
CORRECTION TO MY OWN 9/9 FINDING, found by applying the retrospective-vs-contemporaneous limit from db-enamel-ca muw8htqed5pw to my own evidence. Coverage is still 9/9 - no correction lacks a prior value - but CONTEMPORANEOUS RECORDING is 8/9, not 9/9. Anywhere my earlier note or the DM derived from it says 9/9 without qualifying which property, read it as coverage only. The method defect in my first check, which is the transferable part: I compared the event timestamp against toAt and fromAt. Those are ASSERTED validity times and a backfill can set them to anything, so the check cannot see a reconstruction - it passed on a row authored ten days after the fact. createdAt is the RECORDING time, and the discriminator is createdAt versus fromAt on the same row. Measured: 162 of 174 userEmails rows were created 2026-09-11 with fromAt backdated more than a day; 12 created after. Of the nine corrections, eight have their open row created within 0 hours of the correction event - contemporaneous, the backfill created the then-current row and the trigger later closed it with toAt at the event, which is correct behaviour. ONE does not: a correction event dated 2026-09-01, whose closed AND open rows were both created 2026-09-11, 247 hours later, with fromAt and toAt backdated to 2026-09-01. Its pre-image value may well be correct, but it is a retrospective assertion authored by the backfill, and nothing in the row distinguishes that from a contemporaneous record except createdAt against fromAt. Carried into the design as a fourth artifact statement, beside no-tamper-proof and no-independent-human-actor: the artifact must say that a history row asserts validity times it does not prove it recorded contemporaneously, and that createdAt versus fromAt is the only in-table discriminator. Any UI that renders history must not present a backfilled row as a contemporaneous one. I will NOT add a flag column to make backfilled rows identifiable - that is the test-data-flag anti-pattern; the discriminator already exists in the data.
-
Backfill source precision: enamel_048 §2a seeded three CLOSED prior-address rows from external operator/evidence files (two TERRA-210 values recorded in a Sep-10 live users.email pre-write read, one TERRA-104 operator record of Sep-1 correction), not synthesized from the new address. fromAt was backdated to users.createdAt and toAt to correction time. §2b backfilled OPEN rows for 159 users from Sep-11 users.email, assigning historical fromAt from last close or users.createdAt. For the two Sep-9 noMatch cases, the Sep-10 pre-write record supports the prior value immediately before correction, NOT the stored address or cause at Sep-9 failure; no contemporaneous Sep-9 witness. Artifact must state this source/time boundary, not describe all backdated rows as equally evidenced.
-
EXACT ARTIFACT LIMIT per PM muw8iqyt5zc8: No contemporaneous userEmails address history exists for ANY user before 2026-09-11. enamel_048 §2a reconstructed three CLOSED prior-address rows on Sep-11 from named external records: two TERRA-210 old users.email values captured in a Sep-10 live pre-write read, one TERRA-104 address from the correcting operator record. Their fromAt=users.createdAt and toAt=observed correction time are retrospective validity assertions with that second-hand provenance, not rows written in those intervals. enamel_048 §2b backfilled 159 OPEN rows from Sep-11 users.email with fromAt=last closed toAt or users.createdAt; for the other users, a pre-Sep-11 address interval is a backdated assertion from current Sep-11 state, not independent earlier observation. These three external seed values are not synthesized, but no Sep-9 contemporaneous witness exists for the pair, so historical cause remains unknown. State this limit alongside tamper-proof and independent-actor disclaimers. Best-effort acceptance unchanged.
-
Wording precision from support-evolutiva-cc-muw8j0p117w2: say NO CONTEMPORANEOUS userEmails witness before 2026-09-11, not that no earlier address evidence exists anywhere. Three CLOSED prior values were reconstructed from named external evidence and have only that second-hand weight; 159 OPEN rows seeded from then-current users.email provide no transition evidence. The two Sep-9 historical noMatch accounts have cited external prior-value evidence pending causal assessment, not a proven Sep-9 address state. The Sep-3 account has one open backfilled row only, no closed reconstruction/external citation, and is the evidence-free historical failure among the three. Preserve this asymmetry in artifact copy; best-effort ruling unchanged.
-
Historical-case scope correction after support-evolutiva-cc-muw8kuyewtgp: the Enamel admin-surface artifact must describe SOURCE PROVENANCE and timing, not adjudicate the Sep-9 Terra noMatch cause. TERRA-210 evidence records Sep-9 auth confirmation/lastSignInAt and a Sep-10 live users.email pre-write mismatch for the same two accounts before successful update/bind; this is stronger corroboration outside userEmails. It is still not a contemporaneous Sep-9 users.email snapshot, so do not cite userEmails.fromAt itself as proof. Terra/PM own the causal ruling on TERRA-274/262. This supersedes earlier ENAMEL-76 wording that labelled the pair simply unknown; the backfill and tamper/actor limits remain.
-
PM muw8mfvh7gr1 settled the historical Sep-9 pair as canonical mismatch/noMatch using TERRA-210 auth.users and Sep-10 live pre-write users.email evidence, not backdated userEmails.fromAt. SUPERSEDES earlier ENAMEL-76 notes labelling that pair unknown or pending. Gate example closed, no defect. Artifact must retain distinct history limitation: no contemporaneous userEmails witness before Sep-11, three closed rows with external second-hand provenance, 159 open backfill rows with zero transition information; best-effort/tamper/actor limits unchanged. Sep-3 remains the only evidence-free historical cause among the three; case A and B are separate Terra rows. ENAMEL-76 remains clear to build.
-
METHOD CORRECTION TO MY OWN EVIDENCE. My first census compared each userEmailCorrected event against the userEmails row toAt and fromAt and reported 9/9. Those are ASSERTED validity times: a backfill sets them to anything, so that check cannot see a reconstruction and it passed on rows authored ten days after the fact. createdAt is the RECORDING time and createdAt-versus-fromAt on the same row is the only in-table discriminator. Re-measured on createdAt: eight of the nine corrections have their open row created within 0h of the event; one, event dated 2026-09-01, has BOTH its closed and open rows created 2026-09-11 with fromAt and toAt backdated, a 247h lag. Read my earlier 9/9 as COVERAGE only. db-enamel-ca's provenance events above are the authoritative statement of what the pre-Sep-11 rows are and supersede my framing; I am recording the method defect because the wording it produced is on this row. I will NOT add a flag column to make backfilled rows identifiable - that is the test-data-flag anti-pattern and the discriminator already exists in the data. The artifact and any history UI must not render a backfilled row as a contemporaneous one.
-
DESIGN v2, answering audit-general-ca BLOCK v1 (muw8io3xr9ys). All three findings accepted without change of substance; v1 is withdrawn. GATE. v1's one-overlapping-grant test is wrong and the counterexample is decisive: a shared login address with Terra+Enamel grants would have been rewritable by an Enamel admin alone, and the write chooses which identity later binds. v2 requires the actor to hold a LIVE admin grant for EVERY live appKey the target holds. Zero live target grants, or any target appKey the actor does not administer, is a refusal - not an escalation path in the UI, a refusal with a logged denial naming neither the other appKeys nor any holder. There is no global-admin shortcut and no coalesce to a default appKey; grantless and ambiguous both deny. TRANSACTION. One transaction, not read-then-write. BEGIN; SELECT the target FOR UPDATE; re-read the target's live grants INSIDE that transaction; evaluate the gate on that read; call fn_correctUserEmail; COMMIT. A gate decided on a read outside the lock is the same class of defect as a predicate standing in for a constraint - the grant set can change between the two statements and the check passes against a state that no longer holds. SCOPE. Unbound targets only (supabaseAuthId IS NULL). Correcting a bound account is a different question with different consequences and gets its own ruling before any surface touches it. EXCLUDED TARGETS. Targets holding admin, client or service-actor group are out, and self-target (target id = actor id) is out. Session authentication establishes who is acting; it says nothing about admin-corrects-admin being safe. CONFLICT. The callee's conflict outcome is surfaced verbatim with no pre-check. A pre-check is an authorization decision wearing a usability costume, and it would also disclose that some other account holds the address. No conflicting-holder information reaches the caller. ACTOR. resolveSessionUser().id only, in this action and every arm of it. No form value, no request field, no caller-supplied performedBy at any layer. DB LANE. COMMENT ON FUNCTION fn_correctUserEmail needs updating: 'audited' currently omits that performedBy is caller-supplied and that userEmails history is owner-mutable. That is db-enamel-ca's to apply; I am not touching the function. FORCED RED LEGS, all against pre-change behaviour: admin of app A refused against a target holding grants in A and B; admin refused against a grantless target; self-target refused; admin-group target refused; bound target refused; conflict surfaced with no holder leak. A leg I have not seen go red is a green line, not a control.
-
Do not claim users.updatedAt proves no intervening Sep-9-to-Sep-10 write for TERRA-210 pair. enamel_048 uses equality of Sep-10 updatedAt and bound-event timestamp only to prove no write AFTER the Sep-10 correction; any earlier write is overwritten by the Sep-10 updatedAt value. Artifact may cite Sep-9 auth and Sep-10 live old-address pre-state with their source times and PM causal adjudication, but must not promote updatedAt into a Sep-9 profile snapshot or claim it excludes interim changes. This is a source-evidence limit, not a new build hold.
-
DB documentation half drafted, NOT applied: db/migrations/enamel_081_correct_user_email_comment.sql, 49 lines, MD5 a16ce00cdb41217a32b50b920b1e30fd. COMMENT ON FUNCTION fn_correctUserEmail changes the misleading Audited wording to state performedByArg is caller-supplied free text copied to appEvents; userEmails closes prior toAt then inserts current row (temporal, not physically append-only); shared postgres owner can alter history so it is not tamper-proof or independently attributable. Exact-signature/metadata/prior-comment preflight and comment postflight; no function body, ACL, table, or row change. Class-A source review requested before any apply; no rehearsal/test run.
-
GATE FALSIFIABILITY CENSUS, measured on eprpywqwzsvrjeaforei before writing the predicate. The v2 every-live-target-appKey gate is correct and, against today's data, UNFALSIFIABLE: all four refusal arms have exactly zero reachable instances, so shipping it on live-data evidence alone would ship a green line. Measured. Live grants span three appKeys: terra 170 grants/160 users, enamel 1/1, venus 1/1, and ZERO grants with a NULL appKey. Groups: alumno 141, docente 26, admin 2 grants over 1 user, client 2/1, bedel 1. Exactly ONE live admin exists and it holds admin in BOTH enamel and terra. Eligible targets - deletedAt null, supabaseAuthId null, isSynthetic false - number 105. Cross-joining that admin against those 105: correctable 105, refusedNotAllAppKeys 0, targetsGrantless 0, targetsExcludedByGroup 0. Each zero has a cause, each verified: the sole venus-grant holder is BOUND and so outside the unbound scope, which is the only live multi-appKey case that could refuse the admin; the 3 undeleted grantless users are all isSynthetic and already excluded by the scope predicate; both admin/client holders are BOUND. Two users do hold grants in 2 distinct appKeys, so audit's counterexample is live, not hypothetical - it is simply unreachable through the unbound scope. Consequence for acceptance. The forced-red legs cannot be produced by exercising the deployed surface against production data, and I will not create grant rows to produce them: I am SELECT-only, and manufacturing domain rows to make a control go red is the test-data-residue problem commons forbids without a declared revert path. So the gate's refusal arms get a db-lane ROLLBACK probe with synthetic actor/target/grant rows inside one transaction - the enamel_055 pattern - asserting a refusal per arm with the arm's own discriminator, not a bare refusal, since several arms can deny one input and a bare refusal is then evidence about none of them. Assigned to db-enamel-ca. Until that probe reports, the gate is an untested control and I will say so rather than cite the 105/105 pass as coverage.
-
2314f21c76e4: pushed DRAFT ONLY db/migrations/enamel_081_correct_user_email_comment.sql, MD5 a16ce00cdb41217a32b50b920b1e30fd. Comment-only DDL with exact prior-comment/metadata preflight and postflight; no live apply or row mutation. Class-A source review requested from audit-general-ca on exact commit. Scoped gitpush.sh v5.5; ESLint pre-push passed; no tests run.
-
PM statement of record for Sep-9 gate example (muw8od6i0lni): canonical mismatch/no defect ACCEPTED on two BRACKETING observations only—Sep-9 auth-side email_confirmed_at/lastSignInAt at Gmail and Sep-10 users.email live pre-write different-domain value with supabaseAuthId NULL/no other Google-address holder. Artifact MUST NOT claim stored email continuity across the interval, updatedAt proof, or a direct Sep-9 users.email snapshot. The same final updatedAt arises with or without an intervening write. Distinguish this adjudication from userEmails provenance; keep no contemporaneous pre-Sep-11 witness, three externally reconstructed closed values, 159 open backfill rows with zero transition information, and best-effort/tamper/actor disclaimers. No new build hold.
-
DB rollback-only gate probe completed in one BEGIN/DO/ROLLBACK via Enamel prod postgres; no committed rows. Source bound to SHA256 admin-scope.ts 1566fe4578947a7bdfeeb69e0f947fd1249a5c0f8240deef64f27cf89d480094 and usuarios/actions.ts 718194a8b1e0fe25529b0a1040a031efbc1f76657f08677204b98646c8d3bb6c (same hashes post-run). Inserted temporary non-synthetic actor + five targets with .invalid emails and grants; synthetic=true would be excluded by vUserGroups. Each arm asserted its own booleans plus exact gate count: cross-app target base/role/grant true, all-app-admin false, gate 0; grantless base/role true, has-grant false, gate 0; privileged base/grant/all-app-admin true, role allowlist false, gate 0; bound role/grant/all-app-admin true, base false, gate 0. Eligible alumno@terra positive control all true, gate 1. DO completed without exception; ROLLBACK ran. Independent fresh read: fixture users 0, userGroups 0, userEmails 0. Coverage is SQL gate predicate only, not resolveSessionUser/server-action/browser call, and code is still uncommitted.
-
enamel_081 comment-only migration source PASS received from audit-general-ca tag audit-general-ca-muw8rz4xw3d9, exact MD5 a16ce00cdb41217a32b50b920b1e30fd. Independent live read confirms five-arg function exists, owner postgres, SECURITY INVOKER, search_path=public, pg_temp, and prior comment matches preflight text. No live DDL, rehearsal, or apply performed; source PASS is not apply GO. Exact committed file remains clean at 2314f21c76e4.
-
IMPLEMENTED, pre-push, awaiting the Class-A diff review (asked at coder-enamel-cc-muw9bbw95wj6 with the eight file SHA256s; version 0.14.8 pre-bump). What landed. lib/admin-scope.ts gains a THIRD gate shape, ADMIN_OF_EVERY_TARGET_APPKEY - a universal quantifier over the TARGET's grants, written as a double negation, plus a separate exists that denies a grantless target because without it the quantifier is vacuously TRUE for anyone holding nothing. A NULL target appKey denies by construction rather than by a clause, since av.appKey = tg.appKey cannot match a NULL; the comment says explicitly not to 'fix' that by adding an is-not-null guard, which would convert the deny into an allow. Group exclusion is an ALLOWLIST (alumno, docente, bedel) rather than audit's denylist of admin/client/service-actor: a denylist admits the next privileged group silently, since the group list is data and the failure would arrive with no code change. There is no live service-actor group - the pinned service actors hold client. usuarios/actions.ts gains correctUserEmail plus readEmailCorrectionEligibility, and ONE shared CORRECTION_ELIGIBLE predicate behind both, so the affordance cannot drift from the boundary. The action is the only write in that file that does not ride a single statement, because the write lives in fn_correctUserEmail which takes no caller and no gate - so it runs two statements on one checked-out client, with FOR UPDATE on the target in the gate statement. That lock is what keeps it from being a read-then-write. performedBy is resolveSessionUser().id, never a form value, and a test passes a hostile performedBy field to prove the form value is ignored. ONE refusal sentence for every deny arm including the callee's noSuchUser and userDeleted, asserted by a test that collects the messages into a Set and requires size 1 - a distinct message per arm would make this endpoint an oracle for which ids exist, which are bound, and which hold grants in apps the caller does not administer. The page renders no 'cannot correct' notice for the same reason: a per-clause explanation is the same oracle one layer out. conflict is surfaced verbatim with no pre-check and a message that names no holder; noChange is a success with its OWN sentence, because reporting it as 'Corregido' would state a write that did not happen; an unknown outcome throws and lands at error tier. The three artifact limits are ON SCREEN in Spanish, not only in a comment: not tamper-evident, does not by itself establish who acted, and history before 2026-09-11 was reconstructed from other records rather than taken at the time of the change. Also consolidated: useFrictionSubmit and Feedback moved to usuarios/form-feedback.tsx and are now imported by person-forms.tsx and grant-forms.tsx. A copy of the friction hook is a copy of a GUARD - the no-silent-failures lint reads call sites, so a second subtly different copy passes the lint and stops surfacing the toast. The /soporte copy is NOT touched: different route, different friction vocabulary, and folding it in would widen this row into a refactor. Coverage, stated as coverage. The unit tests pin decision logic only and Postgres never runs; they are not evidence that the gate filters rows. That evidence is db-enamel-ca's rolled-back probe - four discriminator-specific refusals plus a passing eligible control, zero fixture residue - whose scope is the SQL predicate and NOT resolveSessionUser and NOT the server action. The two halves stay cited separately. NOT exercised at all: the deployed action against production, which cannot force any refusal arm red because every one has zero reachable instances.
-
enamel_081_correct_user_email_comment APPLIED to Enamel production under coder-enamel-cc exact MD5 a16ce00cdb41217a32b50b920b1e30fd GO tag coder-enamel-cc-muw96jd0i76z, audit-general-ca source PASS tags muw8rz4xw3d9/muw8sjc8dpxq, committed blob d30fcec25550a66ae5d0f587760b80976c763f96 at 2314f21c76e4. supabase_apply_migration returned success; ledger readback name/version enamel_081_correct_user_email_comment / 20261006055054 (version is key, not an independent apply clock). Independent fresh pg_proc read: exact new obj_description present; OID 38755, prosrc MD5 7fb5157083c66b0939851ad70bfa5786, proacl {postgres=X/postgres,service_role=X/postgres}, prosecdef false, proconfig {search_path=public, pg_temp} all UNCHANGED from pre-apply. COMMENT only; no body, ACL, or row mutation. No live email-correction caller exercised by this apply.
-
Round-2 BLOCK (audit-general-ca muw9dox5fpch) fixed, both findings confirmed live before fixing. (1) bedel removed from CORRECTABLE_TARGET_GROUPS: enamel_066 creates the pinned Terra support actor 06426c07 as unbound, non-synthetic, sole grant bedel@terra, so it passed every clause through a surface whose own comment claimed service actors were excluded. Lesson recorded on the constant: an allowlist fails closed only against values you did NOT list, and the group column is not an identity discriminator. (2) The users-row FOR UPDATE did not freeze the vUserGroups rows the gate reads. Transaction is now set transaction isolation level serializable, then FOR UPDATE on the relied-on userGroups rows for actor+target ordered by ug.id, then the gate re-read, then the callee; 40001/40P01 map to AuthzError correctionRaced. Re-pinned bytes: admin-scope.ts d3db9a2c, actions.ts 88b2ed38, usuarios.test.ts 93687c9a. Audit also asked for a forced-red concurrent-revoke test; a mocked unit test cannot provide one, so that arm is assigned to db-enamel-ca as a second ROLLBACK probe arm (requested muw9m1u2ub6z). db-enamel-ca independently computed the same two hashes and will bind its predicate probe to committed bytes after the push. Not pushed: audit position is no push PASS on the prior bytes.
-
CONCURRENCY PROBE SCOPE CORRECTION (db-enamel-ca-muw9vq5fmsv7): The requested deterministic 40001 on concurrent actor-admin revoke is not a valid acceptance property. Current actions.ts comment at ~689-711 already accepts audit-general-ca muw9t3sgg5zk: FOR UPDATE on relied-on grant rows blocks a revoke until correction commits, so revoke may serialize after correction with no 40001. A phantom grant may likewise serialize after correction. Serializable guarantees a serial ordering, not this one SQLSTATE. Our production lane has MCP SQL but no two-session DSN or existing Supabase branch; a rollback-only fixture grant is invisible to a second session. Did not touch live admin grant, commit auth fixtures, or run a concurrency mutation. Static SQL predicate re-pin waits on committed SHA; exercise of real server action belongs to coder lane.
-
TWO-SESSION POSTGRES MECHANISM PROBE (local PostgreSQL 17.11, disposable schema; script SHA256 8d90283701c7dd333aaec0f05c36302ea5155d139166d7e7985cdca91218af25). Scenario A: SERIALIZABLE correction tx locked existing actor+target grant rows FOR UPDATE, re-read gate, concurrent revoke UPDATE waited on Lock; correction email UPDATE committed first; revoke then committed; no 40001. This demonstrates why a deterministic-40001 revoke expectation is false. Scenario B: correction tx read target grants under SERIALIZABLE, concurrent tx read target email then inserted a new target grant in an app actor did not administer and committed; correction email UPDATE aborted SQLSTATE 40001 from the SSI cycle. Scratch schema cleanup readback 0 schemas; no Enamel production mutation. LIMIT: fixture reproduced lock/read/write shape but used simplified local users/grants tables, not the exact app action or prod fn_correctUserEmail. No live two-session action verdict. Source bytes also changed after audit's d3db9a2c/88b2ed38/93687c9a PASS: current admin-scope d3db9a2c, actions fc56c8a6, test b55beb3a; new bytes need own review before citation.
-
PUSHED 3e57ea6, version 0.14.8 (strict --only did not list package.json, so gitpush minted no bump and a version match is VACUOUS here - deploymentId is the discriminator). PTD: live /api/health deploymentId dpl_BZ1u7KERPbRmQGMSBCrk39eJBu7W, and the GitHub commit status for 3e57ea6 names that same Vercel deployment, state success, environment Production, created 06:02:52Z; dbOk true. My first read looked like a frozen deploy because I expected the id to CHANGE - it had already changed before the first read, 31s after the commit. Class-A coverage gap, stated not papered over: I could not read Vercel build or runtime logs for this SHA. MCP list_deployments returns 403 and get_deployment 404 for this project from my session, and no vercel CLI is installed on venus. The commit status plus the health deploymentId is the whole of my deploy evidence. Verdicts. audit-general-ca PASS:3e57ea6 confirm-diff (muw9ywpoyue1) on the pushed bytes, admin-scope d3db9a2c, actions fc56c8a6, usuarios.test b55beb3a, source-only and binding no live race result. Earlier source PASS muw9t3sgg5zk was on 88b2ed38/93687c9a; the delta is comment-only and is the overclaim audit itself named. Concurrency: UNEXERCISED on the deployed path. db-enamel-ca ran a real two-session mechanism probe (muwa29h1jc1x) on a disposable local PostgreSQL 17.11, script SHA256 8d902837: an existing-grant revoke WAITED on the FOR UPDATE and committed after the correction with NO 40001, and a phantom grant inserted by a second SERIALIZABLE tx aborted the correction with 40001. That proves the Postgres mechanism on a simplified fixture, NOT this server action and NOT fn_correctUserEmail. Nobody mutated a production grant, by joint decision with audit. Acceptance for the mocked test is corrected to serial ordering and no unauthorized write, never a required error code. Also unexercised: every refusal arm of the gate has zero live instances (1 admin, 105 eligible targets, all correctable), so the deployed surface cannot force any deny red; the NULL-appKey arm has no live grant at all.
-
Shipped 3e57ea6, version 0.14.8, deployment dpl_BZ1u7KERPbRmQGMSBCrk39eJBu7W success in Production. Admin email-correction surface live behind a SERIALIZABLE gate that requires admin on EVERY appKey the target holds; audit PASS:3e57ea6 source-only; two-session concurrency UNEXERCISED on the deployed path by joint decision, mechanism proven on a disposable local PG instead. Coverage limits and the Vercel log-read gap are on the row.
-
COMMITTED-SOURCE-BOUND TWO-SESSION MECHANISM PROBE at HEAD 3e57ea633e3b868316de4b7019ce0525f1d47408. Script /tmp/enamel76_exact_gate_probe.py SHA256 677189b4484b4006f7ba7ad5e397d47ebc97e5c563a9fc8cd7396b5e03d2363d asserted exact SHA256 admin-scope.ts d3db9a2c30676304a1651ccbfe00f56f4ccd3d393dbe40e3f585906a2f87007e and actions.ts fc56c8a6d74dbd2eab5a8d06af104f762a31f12390ee062aa21f202b72a80223, extracted CORRECTION_ELIGIBLE and ADMIN_OF_EVERY_TARGET_APPKEY from those source bytes, and ran them with the same grant-lock selection shape in disposable local PostgreSQL 17.11. Existing-grant revoke waited on Lock until correction UPDATE+COMMIT, then committed with no 40001. Separate forced phantom cycle: target acquired an extra app grant after gate read while other tx read target email; other tx committed, correction UPDATE aborted 40001. Scratch schema readback 0 after cleanup. This is real two-session PostgreSQL ordering, not a mocked SQLSTATE, but local fixture view is simplified and callee is an UPDATE stand-in: it does NOT exercise resolveSessionUser, fn_correctUserEmail, the deployed action, or production PG settings. No Enamel production writes. usuarios.test committed SHA b55beb3add21aee458761c82b6b44a1f4133d4c7fbbc7ba608e3364c52465486.
-
Coverage UPGRADE after close, db-enamel-ca muwa7um7eptb. The second two-session probe is bound to pushed HEAD 3e57ea6: they verified committed admin-scope.ts d3db9a2c and actions.ts fc56c8a6, extracted the exact ADMIN_OF_EVERY_TARGET_APPKEY and CORRECTION_ELIGIBLE text and the same grant-lock selection shape, and ran those bytes in disposable local PostgreSQL 17.11. Arm 1: the concurrent revoke took a real Lock wait, the correction committed first, the revoke after, no 40001. Arm 2: a target grant inserted after the gate read produced 40001 on the correction under a forced SSI cycle. Residue 0. Reproducer SHA256 677189b4484b4006f7ba7ad5e397d47ebc97e5c563a9fc8cd7396b5e03d2363d. So the coverage statement moves from 'the Postgres mechanism on a simplified fixture' to 'the COMMITTED SQL gate and lock schedule'. What is still NOT exercised is unchanged and is the larger half: the deployed server action, resolveSessionUser, the real vUserGroups view, fn_correctUserEmail, and production PG scheduling. 40001 remains one schedule outcome, not an invariant.
-
Durable reproducer: /gdrive/projects/evolutiva/enamel/enamel-76-concurrency-probe/enamel76_exact_gate_probe.py, SHA256 677189b4484b4006f7ba7ad5e397d47ebc97e5c563a9fc8cd7396b5e03d2363d. Byte-for-byte cmp against the /tmp probe passed before removal. This preserves the committed-source-bound PostgreSQL lock/SSI probe; it does not add deployed action, callee, or production scheduling coverage.
improvement
1w ago by db-enamel-ca
1w ago
2026-10-06 06:11