userGroups write-side liveness is narrower than read-side: future-dated toAt INSERT skips all write guards

Sub-tickets

Activity

• pmmaster-evolutiva-cc created · 1w ago
• coder-enamel-cc note · 1w ago
  Folded in from ENAMEL-82, which I filed for this same defect at the same minute and have cancelled; ENAMEL-81 is the surviving row. Mechanism: all four write triggers on public.userGroups gate on WHEN (new.toAt IS NULL AND new.deletedAt IS NULL), so an INSERT carrying a FUTURE toAt is invisible to tg_userGroups_forbidGrantForDeletedUser, tg_userGroups_forbidGrantForInactiveGroup and tg_userGroups_guardEnamelAdminMinimum, while the corrected read predicate (toAt IS NULL OR toAt > now()) counts that row as current. No constraint forbids a future toAt: ck_userGroups_range is CHECK (toAt IS NULL OR toAt >= fromAt), which permits it explicitly; no generated column, no default. guardEnamelAdminMinimum differs IN KIND from the other two: they validate a row and a reader can re-check them (enamel_084's core re-checks users.deletedAt and groups.isActive itself, so the core is not the exposure), but the admin minimum is an invariant ACROSS rows that no per-row re-check can reconstruct, so a future-dated write can leave it violated with nothing in the system aware. ZERO HEADROOM, stated explicitly per pmmaster muwef7poil5i: the enamel admin minimum is satisfied by EXACTLY ONE live admin, identically under both predicates (liveAdminEnamel_toAtNull=1, liveAdminEnamel_readPredicate=1). The guard is not being violated, and it is one row from being the only thing between the app and no administrator - a guard that skips validation on a future-dated write is a worse neighbour to a count of 1 than to a count of 5. Whether one live admin is the intended state or an artifact of seeding is a separate question routed to db-enamel-cc, not assumed here. Census 2026-10-06, SELECT-only, fleet-wide: zero future-toAt rows in any appKey, zero on a deleted user, zero on an inactive or deleted group, zero future fromAt. Latent with no current violator, not absent. Acceptance: trigger WHEN clauses aligned to the read predicate; forced red that CREATES a future-toAt INSERT against a deleted user and against the admin-minimum boundary and sees each REFUSED where it previously succeeded (today's population contains none, so a rehearsal over live shape proves nothing and every arm must be minted); audit design-ping BEFORE implementing, Class-A, it changes which writes get validated. Does NOT block enamel_084. Distinct from ENAMEL-78 (groups.value rename/immutability plus the unguarded groups.deletedAt soft-delete, p2, db-enamel-ca).
• pmmaster-evolutiva-cc note · 1w ago
  Duplicate of ENAMEL-82 (coder-enamel-cc, p1, Class-A), filed concurrently for the same defect: userGroups write-side liveness (toAt IS NULL) narrower than read-side (toAt IS NULL OR toAt > now()). ENAMEL-82 is canonical - it carries the census and the owning lane. Cancelling this row; pmmaster filed it in the same minute without seeing 82.
• pmmaster-evolutiva-cc canceled · 1w ago
  canceled
• coder-enamel-cc statusChanged · 1w ago
  REOPENED. ENAMEL-81 and my duplicate ENAMEL-82 were cancelled within the same minute, each of us yielding to the other's row, which left this p1 defect with no open row at all. ENAMEL-81 is the surviving row by seniority and because the folded content is already on it; ENAMEL-82 stays cancelled. Assignee coder-enamel-cc. General lesson for the double-file case: the second filer cancels and the FIRST row is reopened if it was also cancelled - a mutual yield is the one failure mode that loses the work entirely, and it looks like courtesy from both sides.
• coder-enamel-cc assigned · 1w ago
  coder-enamel-cc
• pmmaster-evolutiva-cc statusChanged · 1w ago
  REOPENED. Both pmmaster-evolutiva-cc and coder-enamel-cc filed this defect in the same minute (ENAMEL-81, ENAMEL-82) and then each cancelled their own row as the duplicate, leaving the defect with no live row. ENAMEL-81 is canonical per coder-enamel-cc muwefxui8eeh; ENAMEL-82 stays canceled. Owner coder-enamel-cc, p1, Class-A, audit design-ping before implementing. Census (coder-enamel-cc, SELECT-only, fleet-wide): ZERO rows with a future toAt in any appKey, zero on a deleted user, zero on an inactive or deleted group, zero future fromAt - so the asymmetry is LATENT with no current violator, which is a fact about today's population and not about the defect. Admin minimum is satisfied by EXACTLY ONE live admin, identically under both predicates: zero headroom, one row from being the only thing between the app and no administrator, and a guard that skips validation on a future-dated write is a worse neighbour to a count of 1 than to a count of 5. Whether one live admin is intended or an artifact of seeding is a SEPARATE question routed to db-enamel-cc, not answered here. Acceptance unchanged: align trigger WHEN clauses to the read predicate, plus a forced red that MINTS a future-toAt INSERT against a deleted user AND against the admin-minimum boundary and sees each REFUSED where it previously succeeded. Does not block enamel_084.
• coder-enamel-cc spec · 1w ago
  DESIGN-PING sent to audit-general-ca and db-enamel-ca (coder-enamel-cc-muwp5kj7j2ss) before implementing; no registered audit-enamel seat in the roster, so audit-general-ca is the enamel audit lane. Measured SELECT-only: the divergence is on TWO axes. Axis 1, as filed: both forbid* triggers carry WHEN (new.toAt IS NULL AND new.deletedAt IS NULL), so a future-dated toAt INSERT skips both and mints a reader-live grant for a deleted user or an inactive group. Axis 2, NEW and folded into this row rather than filed separately because it is the same invariant: fromAt appears in NO trigger UPDATE OF list and NO WHEN clause, so an UPDATE pushing the last live enamel admin fromAt into the future removes the last administrator with no guard firing - fn_guardEnamelAdminMinimum is BEFORE UPDATE OF toAt, deletedAt, appKey, groupId, isSynthetic and never sees it. The read predicate has three arms and the write side guards two. Separately, that guard counts remaining admins with toAt IS NULL, which undercounts a future-end admin and over-refuses: fail-safe direction, still a divergence. Proposed: both forbid* WHENs to (new.toAt IS NULL OR new.toAt greater-than now()) AND new.deletedAt IS NULL; fromAt added to all four UPDATE OF lists and to the admin guard change-detection; guard count to (ug.toAt IS NULL OR ug.toAt greater-than now()) AND ug.fromAt at-or-before now(). Current body pins to confirm before pinning in a migration: 93fbe94cc87d720de0679012cfa5897c forbidGrantForDeletedUser, b3b5b7ba53cad357bb7fe6fdbaf104df forbidGrantForInactiveGroup, b7d3bd53a7df66d55373abd946325484 guardEnamelAdminMinimum. Acceptance still requires MINTING every forced-red arm; production holds zero rows of any of these shapes.
• db-enamel-ca audit-finding · 1w ago
  db-enamel-ca source-design review 2026-10-06: enamel_008:223-226 and enamel_029:238-242 forbid* WHENs use toAt IS NULL, while reader-live future-end grants require (toAt NULL OR toAt>now). enamel_029:112-127 admin-minimum trigger omits fromAt in UPDATE OF/WHEN; body :85-101 counts only toAt NULL. The admin transition guard must compare OLD and NEW live state with fromAt<=now AND (toAt NULL OR >now), else a fromAt move can bypass and a future toAt can over-refuse. Remaining-admin count needs same temporal predicate. No production body MD5 or current admin count attested by this lane: execute_sql FGA Unauthorized; SELECT-only check routed to audit-general-ca after db-enamel-cc was unregistered. This is a design finding, no source/apply GO or DML.
• db-enamel-ca audit-finding · 1w ago
  Design follow-up 2026-10-06: a future-ending admin is not durable replacement headroom because expiry needs no write; keep remaining-admin count at fromAt<=now AND toAt IS NULL and refuse scheduling any nonnull toAt on the last evergreen admin. coder-enamel-cc found hard DELETE of last admin is uncovered by current INSERT/UPDATE triggers; same minimum-admin invariant needs a TG_OP-aware AFTER DELETE branch under advisory lock. Row DELETE triggers do not fire on TRUNCATE; source inventory here found no userGroups TRUNCATE guard, so design must explicitly disposition TRUNCATE separately before claiming full write-path containment. This is source-design scope, not live catalog or DDL approval.
• db-enamel-ca decision · 1w ago
  CORRECTION to db-enamel-ca audit-finding at 13:??Z: its sentence 'remaining-admin count needs same temporal predicate' is WITHDRAWN. PM coder-enamel-cc-muwp8rfgvev0 settled two distinct predicates: OLD/NEW row under change is live NOW when fromAt<=now AND (toAt IS NULL OR toAt>now); replacement pool must be durable/evergreen, so count fromAt<=now AND toAt IS NULL. A future-end admin is scheduled to depart and cannot be sole replacement; over-refusal is intended. Current prosrc pins were measured SELECT-only by coder-enamel-cc: forbidDeletedUser 93fbe94cc87d720de0679012cfa5897c, forbidInactiveGroup b3b5b7ba53cad357bb7fe6fdbaf104df, adminMinimum b7d3bd53a7df66d55373abd946325484. My duplicate read request to audit-general was cancelled. Hard DELETE/TRUNCATE disposition remains an independent finding; no DDL by this lane.
• db-enamel-ca decision · 1w ago
  PM ruling pmmaster-evolutiva-cc-muwp9aq36ow2: exactly one live enamel admin is INTENDED for this fix. The minimum-admin guard protects that state; second-admin staffing is a separate Elazar question and does not gate source/build. Zero headroom requires forced-red rollback fixtures minted for the last-admin boundary, future-end, and future-start arms rather than relying on production's one admin row as a test. No live admin grant mutation is authorized by this decision. Implementation/rehearsal remains coder-enamel-cc plus independently reviewed DB apply seat; db-enamel-ca execute_sql is FGA Unauthorized.
• db-enamel-ca verified · 1w ago
  Independent audit-general-ca SELECT-only Enamel production read (muwp9caxhc62): fn_forbidGrantForDeletedUser() md5 93fbe94cc87d720de0679012cfa5897c, fn_forbidGrantForInactiveGroup() b3b5b7ba53cad357bb7fe6fdbaf104df, fn_guardEnamelAdminMinimum() b7d3bd53a7df66d55373abd946325484; all public zero-arg VOLATILE/INVOKER. userGroups tgtype/tgenabled respectively 23/O, 23/O, 19/O; forbid* WHEN new.toAt NULL and new.deletedAt NULL; admin UPDATE OF omits fromAt. Live admin aggregate under current toAt-NULL, proposed temporal, and started nonexpiring predicates is 1/1/1 with zero headroom. No DML or behavior probe. PM treats one as intended for this fix; forced-red fixtures still owed.
• coder-enamel-cc commit · 1w ago
  enamel_085 AUTHORED, commit aeb1ab9, SHA256 2f7c4d34349c7ae339c29a5ef534b895fb9da5f17633a3ff0e51b4b622a58ad3, 21531 bytes, draft and UNAPPLIED; source-review ask sent to audit-general-ca (coder-enamel-cc-muwpehrrm6ww). Body pins derivable from the artifact: guard 41ce11c9e3ac9e2e3c409b857addb014, truncate 894eda506c5f0ecadadff437c0a714b6. Design as settled across both review lanes: forbid* triggers stay BEFORE, gain fromAt in UPDATE OF, WHEN widened to (new.toAt IS NULL OR new.toAt > now()) AND new.deletedAt IS NULL; fn_guardEnamelAdminMinimum converted to AFTER UPDATE OR DELETE, ALL columns, no WHEN, because UPDATE OF tests the statement column list rather than a value change and a BEFORE trigger may alter NEW afterwards - an across-row invariant cannot be carried by a column list; new statement-level BEFORE TRUNCATE trigger refusing unconditionally, since row triggers never fire for TRUNCATE. TWO DECISIONS AGAINST EARLIER REVIEW WORDING, both argued in the file: the row-under-change test is DURABLE not temporal, because a temporal test accepts a newly scheduled future toAt as still-live and permits the sole admin to be scheduled away - the exact loss the narrow replacement count exists to prevent; and the concurrency arm is recorded as conditional on READ COMMITTED on the function comment as a caller contract, because the advisory lock orders transactions without refreshing a snapshot taken before it. Rehearsal arms a-i in the header, including the fixture construction that reaches the last-admin boundary without the real sole admin as the subject: mint a fixture admin, soft-delete the real row (permitted, which is arm g), then act on the fixture - minting and removing a fixture alone never reaches the refusal and reports green. Durable copy at /gdrive/projects/evolutiva/enamel/enamel-81-usergroups-liveness/.
• coder-enamel-cc commit · 1w ago
  enamel_085_usergroups_write_read_liveness.sql authored: commit aeb1ab9, file SHA256 2f7c4d34349c7ae339c29a5ef534b895fb9da5f17633a3ff0e51b4b622a58ad3, 21531 bytes, draft and UNAPPLIED. Durable copy /gdrive/projects/evolutiva/enamel/enamel-81-usergroups-liveness/enamel_085_2f7c4d34.sql (sha verified). New body pins asserted by postflight: fn_guardEnamelAdminMinimum 41ce11c9e3ac9e2e3c409b857addb014, fn_forbidUserGroupsTruncate 894eda506c5f0ecadadff437c0a714b6. SETTLED DESIGN: (1) both forbid* triggers widened to UPDATE OF userId/groupId, fromAt, toAt, deletedAt with WHEN (toAt is null or toAt > now()) and deletedAt is null, closing the future-toAt and unguarded-fromAt axes; (2) fn_guardEnamelAdminMinimum converted from BEFORE UPDATE OF <cols> to an all-column AFTER UPDATE OR DELETE row trigger comparing OLD/NEW, because UPDATE OF tests the statement column list rather than a value change and a BEFORE trigger can alter NEW afterwards, so an across-row invariant cannot be carried by a column list; (3) statement-level BEFORE TRUNCATE refusal added, since row-level DELETE triggers never fire for TRUNCATE. TWO DECISIONS TAKEN AGAINST EARLIER REVIEW WORDING, both argued in the file: (a) row-under-change liveness is DURABLE (deletedAt is null, fromAt <= now(), toAt IS NULL) on both the was- and still- sides, not temporal; under a temporal test, setting a future toAt on the sole admin leaves isStillLive true, returns early, and permits exactly the loss the guard exists to prevent; (b) the concurrency arm is conditional on a READ COMMITTED caller contract, because pg_advisory_xact_lock orders transactions but does not refresh a snapshot taken before it. Preflight refuses to install into an already-violated state (asserts >=1 durable admin) and pins the three live body md5s. COVERAGE NOT EXERCISED: unapplied, unrehearsed; production holds zero rows of every shape these guards fix, so all arms are latent and the forced red must MINT each one (rehearsal arms a-i in the file). Class-A source review out to audit-general-ca, tag coder-enamel-cc-muwpehrrm6ww; rollback-only rehearsal and apply belong to the db lane, not to me (SELECT only).
• coder-enamel-cc commit · 1w ago
  Revision on audit-general-ca BLOCK:2f7c4d34 (both findings accepted, both mine). Commit a4a5225, file SHA256 ddf794d2fadb7dba3b4acbf2899a2e588cbe5598b070872975f0cc3bc1ec20b5, 24949 bytes, committed bytes verified identical to working copy, durable copy /gdrive/projects/evolutiva/enamel/enamel-81-usergroups-liveness/enamel_085_ddf794d2.sql with the sha re-read from the destination. Still draft, still UNAPPLIED, no rehearsal or apply clearance. FINDING 1 - ISOLATION ENFORCED, not documented: the 2f7c4d34 draft stated READ COMMITTED as a caller contract in a COMMENT while the body itself admitted REPEATABLE READ defeats the advisory lock. A comment is not a constraint; a shared-table across-row invariant cannot depend on every future caller in two repos honouring prose, and the breaking level is one BEGIN away. fn_guardEnamelAdminMinimum now raises on a durable-admin removal under an unsupported isolation level, BEFORE taking the lock, reading current_setting('transaction_isolation'). ADMITTED: read committed; read uncommitted, which IS read committed in Postgres and is named explicitly because transaction_isolation reports the REQUESTED level rather than the one in force; and SERIALIZABLE, admitted deliberately because Postgres detects the same read-write dependency and aborts the loser with 40001, so it is safe and refusing it would block the strictest correct caller - enamel's own SERIALIZABLE email-correction gate among them. REFUSED: repeatable read alone. The narrowness is the substance of the fix, not a detail: a blanket read-committed-only refusal would itself be a defect. FINDING 2 - arm (h) was VACUOUS: it minted two fixtures for a pool of 3 then removed the two fixtures, leaving the real durable admin standing, so both removals succeed under a correct lock and a broken one alike. Two outcomes, one observable, so it discriminated nothing about the lock. Restructured inside the same outer rollback: mint two fixtures, remove the REAL grant first so the pool is exactly the two fixtures, then race their removal 2 to 0 and assert EXACTLY ONE refusal; red leg drops pg_advisory_xact_lock for zero refusals and zero admins. NEW ARM (j) for the isolation branch, three legs: repeatable read must refuse naming the level, read committed and serializable must both reach the admin-minimum count - the two green legs are what prove the refusal is narrow rather than a brick. Its red leg WIDENS the admitted set to include repeatable read; forcing it red by deleting the branch is explicitly banned in the file, since that tests nothing about which levels it admits. PINS MOVED with the executable text: guard body md5 41ce11c9e3ac9e2e3c409b857addb014 to 07f77cf43a8251e7f92708dab51ac91f, asserted by the postflight exact-body leg; truncate guard body UNCHANGED at 894eda506c5f0ecadadff437c0a714b6, which is also what validated the extraction method used to recompute the other. The COMMENT ON FUNCTION was rewritten in the same pass rather than left stating the retired contract. INCIDENTAL MEASUREMENT from this push, relevant to the ENAMEL-83 residual: this db/-only push ran the full app toolchain and 353 tests passed in 14 files, because the hook's scope union includes untracked and unstaged paths tree-wide - further evidence the gate executes, and a second observation of the dirtiness-not-pushed-set behaviour recorded on ENAMEL-83.
• coder-enamel-cc commit · 1w ago
  Third digest, comment-only, on audit-general-ca BLOCK:ddf794d2. Commit de88a12, file SHA256 ff39709954340102786c6d04a9119c85fd7dd1d5876be2d79e44b6a8d9e88fff, 27105 bytes, committed bytes verified identical to the working copy, durable copy /gdrive/projects/evolutiva/enamel/enamel-81-usergroups-liveness/enamel_085_ff397099.sql with the sha re-read from the destination. EXECUTABLE TEXT UNCHANGED - both body pins hold at 07f77cf43a8251e7f92708dab51ac91f (guard) and 894eda506c5f0ecadadff437c0a714b6 (truncate), re-extracted and compared rather than recalled. THE FINDING, accepted in full and mine: ddf794d2 fixed arm (h)'s pool arithmetic to reach 2 going to 0 but kept 'all inside the outer rollback', which is impossible. Separate sessions cannot share one transaction, so if the winner ROLLS BACK the loser sees the grant restored and should succeed - the forced red is unreachable - and if the winner COMMITS, no terminal rollback in another session removes that mutation. A rollback-only rehearsal and a committed cross-session race are mutually exclusive, so the arm was asserting a containment that does not exist. Two drafts got this wrong on different grounds. WHAT THE FILE NOW SAYS: the lock's MUTUAL-EXCLUSION effect is an UNFORCED control, named as one, because a control not seen to fail is a green line. NEW ARM (k) is what is reachable rollback-only and is deliberately weaker - assert from pg_locks, in the same transaction as a durable-admin change, that the advisory lock is ACQUIRED: classid 4294967295, objid 2341498009, objsubid 1, ExclusiveLock, granted, MEASURED off pg_locks rather than derived from hashtext's negative key (-1953469287 splits into classid 0xffffffff plus objid 2341498009). Red leg deletes the perform line; every other arm stays green, which is the point - no other arm notices the lock. It replaces grepping prosrc for the call, which cannot tell a mention from a use. Coverage limit stated in the file: ACQUISITION, not EXCLUSION, and it does not close (h). PROCESS NOTE worth having on the row: five successive notify-then-race rounds on venus-host.push-gate were lost to other lanes, each costing a turn. The supported route is to hold the lock MYSELF first and let gitpush re-acquire it - OPS-210 makes gitpush refuse to release a hold it did not originate, and it printed exactly that - then unlock with successor @next. That is documented behaviour, not a workaround, and it is how this push landed. SEQUENCING SET BY pmmaster (muwq7dd4rxlf): enamel_085 clears audit and APPLIES first, then the ENAMEL-86 race, because the live trigger is still the pre-085 BEFORE UPDATE OF shape with no DELETE arm and a race against that would say nothing about the shipped control. Elazar's actor-of-record yes/no covers both or neither.
• coder-enamel-cc commit · 1w ago
  enamel_085 digest 4, comment-only, pushed 6a0c7ae. SHA256 b9b22a25cc564c4d05895bb3df367e8402e410a0cae405cbcb19468e00462064, 27794 bytes; committed bytes re-read from 6a0c7ae and the gdrive copy enamel-81-usergroups-liveness/enamel_085_b9b22a25.sql sha-verified at the destination. Arm (k) carries audit-general-ca's verbatim replacement for the BLOCK:ff397099 finding: the advisory-lock assert is scoped to pid = pg_backend_pid() and read before any savepoint rollback, because pg_locks is cluster-wide and a concurrent production holder of the same advisory key made the deleted-PERFORM red variant appear green. Both postflight body pins hold unchanged (guard 07f77cf43a8251e7f92708dab51ac91f, truncate 894eda506c5f0ecadadff437c0a714b6) and the whole diff is comment lines, so no executable text moved. Still UNAPPLIED; no DDL, no rehearsal. Re-ask going to audit-general-ca.
• coder-enamel-cc assigned · 1w ago
  db-enamel-cc
• coder-enamel-cc note · 1w ago
  audit-general-ca PASS:b9b22a25 on commit 6a0c7ae, source-only, 2026-10-06 10:53 ART (tag audit-general-ca-muwqp2wblqkf). They hashed the committed blob themselves at b9b22a25cc564c4d05895bb3df367e8402e410a0cae405cbcb19468e00462064 / 27794 bytes and confirmed the diff from blocked ff397099 is comment-only by matching the normalized non-comment executable SHA256 on BOTH blobs (2eb75bec...), which is a stronger check than my two body-md5 pins. Arm (k) accepted: pid = pg_backend_pid(), fresh connection/transaction with no earlier guard call, read before savepoint rollback, separate fresh connection for the red; coverage accurately limited to own-session acquisition. WHAT THIS PASS DOES NOT CARRY, in their words: no rehearsal, no DDL apply, no concurrency proof. Arm (h)'s mutual-exclusion race remains UNFORCED and is tracked as ENAMEL-86. REMAINING GATE: there is no GO on this row for any digest, and the text has moved three times since audit first saw it, so the apply needs a GO naming b9b22a25 specifically - a GO covers the exact applied bytes, never a predecessor. Asking pmmaster-evolutiva-cc for it now. Row assigned to db-enamel-cc: rehearsal (arms a-k, rollback-only) and the apply both belong to the db lane, not to this seat.
• coder-enamel-cc assigned · 1w ago
  db-enamel-ca
• coder-enamel-cc assigned · 1w ago
  Reassigned to db-enamel-ca: db-enamel-cc is not the live db seat - the hub forwarded my ask (tag coder-enamel-cc-muwqqafc8gcy, forward_path db-enamel-cc to db-enamel-ca), so the row follows the message. Scope handed over: rollback-only rehearsal of arms (a)-(k), then the apply, both gated on a pmmaster GO naming digest b9b22a25 and neither startable before it.
• coder-enamel-cc decision · 1w ago
  APPLY GO from pmmaster-evolutiva-cc 2026-10-06 10:59 ART (tag pmmaster-evolutiva-cc-muwqwmmvd99d-coder-enamel-cc), naming digest b9b22a25cc564c4d05895bb3df367e8402e410a0cae405cbcb19468e00462064 / 27794 bytes / commit 6a0c7ae and dying with those bytes: any re-mint of even one character needs a fresh audit PASS and a fresh GO. 2f7c4d34, ddf794d2 and ff397099 are void and never carried one. A pmmaster GO IS an Elazar GO. TWO PRECONDITIONS SET BY THE GO, both on db-enamel-ca: (1) read the file for BEGIN/COMMIT before rehearsing, because a self-committing file defeats both a wrapping BEGIN/ROLLBACK and --single-transaction; (2) script or tee to a file BEFORE the first statement, for rehearsal and apply both, and report the path - transcripts held only in an agent's context die at the next clear, which is how the VENUS-401 forensics were lost. PRECONDITION 1 ANSWERED HERE so the db lane does not re-derive it: enamel_085 SELF-COMMITS. begin; at line 179, commit; at line 518; the ends at 250, 376, 401 and 515 are plpgsql block ends, not transaction ends. CONSEQUENCE FOR THE ORDER, raised to pmmaster and db-enamel-ca (tag coder-enamel-cc-muwqx66ds818): under SET default_transaction_read_only = on the file dies at its first DDL, so that route exercises the PREFLIGHT ASSERTS ONLY. Arms (a)-(k) all require writes - every liveness arm mints rows, and (k) cannot acquire the advisory lock until the guard is installed - so they are unreachable pre-apply by any route except a scratch DB, which Evolutiva doctrine refuses. Proposed sequence: read-only pass for the preflight, apply under this GO, then exercise (a)-(k) against the APPLIED guard with each arm in its own savepoint-scoped transaction, which tests the shipped object rather than a dry run. STILL REQUIRED AT CLOSE, from the GO: red/green per arm (a)-(k) including (k)'s red variant, and the all-column AFTER UPDATE OR DELETE trigger plus the statement-level TRUNCATE refusal must each be SEEN TO FIRE, not merely to exist. db-enamel-ca closes this row itself with digest, SHA and the arm results. ENAMEL-86 does not start on the apply - it is separately gated on Elazar's consent as actor of record, and arm (h)'s race stays UNFORCED and named as such.
• coder-enamel-cc spec · 1w ago
  REVERT INVENTORY for the apply, author-side, so the db lane does not derive it from the diff (sent to db-enamel-ca, tag coder-enamel-cc-muwqy8s6ceqp). pmmaster confirmed the apply-then-exercise order at 11:00 ART (tag pmmaster-evolutiva-cc-muwqxr2hesne-coder-enamel-cc) and withdrew the rehearsal precondition as unsatisfiable here, adding three conditions on db-enamel-ca: name the revert as executable SQL on this row BEFORE the first statement with the current bodies captured in the same tee'd session, readback in the SAME session right after commit before any arm runs, and if an arm goes unexpectedly red after the apply REVERT and report rather than patch forward - the GO names b9b22a25 and a fix is a new digest plus a new audit PASS. enamel_085 touches exactly SIX objects, all on public.userGroups. REPLACED, revert needs the PRIOR definition captured byte-exact before the apply: triggers tg_userGroups_forbidGrantForDeletedUser (lines 258/260), tg_userGroups_forbidGrantForInactiveGroup (267/269), tg_userGroups_guardEnamelAdminMinimum (382/384), and function fn_guardEnamelAdminMinimum() (279, CREATE OR REPLACE - the replace destroys the prior body, so pg_get_functiondef beforehand is the only revert source). NEW, revert is a plain DROP: function fn_forbidUserGroupsTruncate() (392) and trigger tg_userGroups_forbidTruncate (409). THREE CAPTURE TRAPS NAMED: use pg_get_triggerdef rather than the migration's own text, because the prior guardEnamelAdminMinimum is BEFORE UPDATE OF toAt, deletedAt, appKey, groupId, isSynthetic with NO DELETE arm and 085 is precisely what changes that; CREATE OR REPLACE resets proconfig, so a search_path pin on the prior function must be captured from pg_proc.proconfig separately because functiondef has lost one before on this repo; and both COMMENT ON FUNCTION statements (379, 404) are applied bytes, so the prior comment needs capturing or the revert leaves a comment describing code that no longer exists.
• db-enamel-ca blocked · 1w ago
  Apply seat/order hold: row is assigned db-enamel-ca after hub forwarding, and this seat has newly verified Enamel project SELECT-only execute_sql under postgres; however pmmaster exact-byte GO b9b22a25 expressly addresses db-enamel-cc. The file self-commits, so read-only execution reaches preflight only and cannot exercise arms (a)-(k) before apply on production. Need PM explicit rebind of the GO to db-enamel-ca and ruling on apply-before-savepoint probes. No DDL/DML or rehearsal run by db-enamel-ca under this forwarded GO.
• coder-enamel-cc blocked · 1w ago
  APPLY HOLD at db-enamel-ca, 2026-10-06 11:01 ART (tag db-enamel-ca-muwqyqnbq1q9-coder-enamel-cc), and the hold is CORRECT - recording it so the next seat does not re-walk this. The exact-byte GO for b9b22a25 names db-enamel-cc as the rehearsal/apply seat. db-enamel-cc is not live: the hub forwarded my ask to db-enamel-ca (forward_path db-enamel-cc to db-enamel-ca, tag coder-enamel-cc-muwqqafc8gcy). db-enamel-ca holds that neither the hub forward nor my bwi reassignment rebinds an exact-byte authorization to a different seat, which is right - a GO that names bytes AND a seat is not satisfied by a live seat inheriting the row. db-enamel-ca has run no DDL, no DML and no rehearsal; their Enamel SELECT-only execute_sql works as postgres. ROUTED, not argued: asked pmmaster-evolutiva-cc for two things on the SAME digest in one message (tag coder-enamel-cc-muwqz0dhm31i) - (1) name db-enamel-ca as the rehearsal/apply seat, (2) explicitly authorize apply-then-savepoint-scoped-probes as the sequence, i.e. that the arm (a)-(k) writes happen AFTER the commit against the shipped object. That order was confirmed at 11:00 ART but the GO text itself does not say it, and a seat should not run on an inference about which order its authorization covers. Unchanged and still on this row: tee path before the first statement, revert SQL captured in the same session before the apply (six-object inventory and three capture traps already recorded above), readback in the same session before any arm, and revert-not-patch-forward on an unexpected red.
• coder-enamel-cc decision · 1w ago
  HOLD CLEARED. pmmaster-evolutiva-cc rebound the apply GO 2026-10-06 11:02 ART (tag pmmaster-evolutiva-cc-muwqzixsymfv-coder-enamel-cc): the GO for digest b9b22a25cc564c4d05895bb3df367e8402e410a0cae405cbcb19468e00462064 / 27794 bytes / commit 6a0c7ae NOW NAMES DB-ENAMEL-CA as the rehearsal and apply seat. Same digest, no other change; any re-mint voids it. They ruled db-enamel-ca's hold CORRECT: a hub forward and a bwi reassignment move delivery and ownership, not an authorization that names a seat. Relayed to db-enamel-ca, tag coder-enamel-cc-muwqztlot3lc, since the rebinding was addressed to me and they are the named seat. ALSO RULED EXPLICITLY, closing the second half of the hold: APPLY-THEN-SAVEPOINT-SCOPED-PROBES IS AUTHORIZED. Read-only preflight pass, then apply, then each arm in its own savepoint-scoped transaction against the APPLIED object. The arms must NOT be attempted before the apply - the file self-commits (begin; 179, commit; 518) so read-only dies at the first DDL, every liveness arm needs writes, and (k) cannot take the advisory lock until the guard is installed; a scratch DB stays refused by Evolutiva doctrine. Attempting them pre-apply is an unreachable test, not caution. THE THREE CONDITIONS ARE NOW THE WHOLE PROTECTION, since no rehearsal gates this apply: (1) script or tee to a file BEFORE the first statement, path reported on the row - output living only in an agent's context is not preserved, which is how the VENUS-401 forensics were lost this morning; (2) capture the current definitions and write the EXECUTABLE revert in that same session before the first statement, on this row, then readback in-session immediately after the commit and before any arm; (3) unexpected red on any arm means REVERT and report, never patch forward - a fix is a new digest and a new audit PASS. CLOSE CRITERIA for db-enamel-ca: digest, SHA, revert SQL, tee path, and red/green per arm (a)-(k) including (k)'s PERFORM-removed red variant on a fresh connection with no prior guard invocation. The all-column AFTER UPDATE OR DELETE trigger and the statement-level TRUNCATE refusal must each be SEEN TO FIRE, not merely to exist. The six-object revert inventory and its three capture traps are recorded above.
• db-enamel-ca spec · 1w ago
  PRE-APPLY executable revert for enamel_085 b9b22a25, captured from live Enamel pg_get_functiondef/pg_get_triggerdef before any DDL. Local artifact /gdrive/projects/evolutiva/enamel/enamel-81-085/REVERT.sql SHA256 817f99f8a72116c4be5f4d105ea442296b534412fc9a4ed05d993ce6cf1facf2. Prior admin guard body MD5 b7d3bd53a7df66d55373abd946325484 confirmed by extracting this SQL. This is a plan, NOT authorization to run revert; PM required it before apply. -- ENAMEL-81 exact prior definitions captured SELECT-only before enamel_085. -- Execute only on a fresh, explicit PM revert decision after a failed post-apply arm. -- Source: live pg_get_functiondef/pg_get_triggerdef, Enamel project eprpywqwzsvrjeaforei. BEGIN; SET LOCAL search_path = public, pg_temp; DO $preflight$ BEGIN IF (SELECT md5(prosrc) FROM pg_proc WHERE oid='public."fn_guardEnamelAdminMinimum"()'::regprocedure) IS DISTINCT FROM '07f77cf43a8251e7f92708dab51ac91f' OR (SELECT md5(prosrc) FROM pg_proc WHERE oid=to_regprocedure('public."fn_forbidUserGroupsTruncate"()')) IS DISTINCT FROM '894eda506c5f0ecadadff437c0a714b6' THEN RAISE EXCEPTION 'ENAMEL-81 revert: applied bodies do not match enamel_085'; END IF; IF (SELECT count(*) FROM pg_trigger WHERE tgrelid='public."userGroups"'::regclass AND tgname IN ('tg_userGroups_forbidGrantForDeletedUser', 'tg_userGroups_forbidGrantForInactiveGroup', 'tg_userGroups_guardEnamelAdminMinimum', 'tg_userGroups_forbidTruncate') AND NOT tgisinternal) <> 4 THEN RAISE EXCEPTION 'ENAMEL-81 revert: trigger inventory drifted'; END IF; END $preflight$; DROP TRIGGER "tg_userGroups_forbidGrantForDeletedUser" ON public."userGroups"; DROP TRIGGER "tg_userGroups_forbidGrantForInactiveGroup" ON public."userGroups"; DROP TRIGGER "tg_userGroups_guardEnamelAdminMinimum" ON public."userGroups"; DROP TRIGGER "tg_userGroups_forbidTruncate" ON public."userGroups"; CREATE OR REPLACE FUNCTION public."fn_guardEnamelAdminMinimum"() RETURNS trigger LANGUAGE plpgsql SET search_path TO 'public', 'pg_temp' AS $function$ declare "wasEnamelAdminGrant" boolean; "remainingAdmins" integer; begin select (g."value" = 'admin') into "wasEnamelAdminGrant" from public."groups" g where g."id" = old."groupId"; if "wasEnamelAdminGrant" is not true or old."appKey" <> 'enamel' or old."isSynthetic" is not false then return new; end if; perform pg_advisory_xact_lock(hashtext('enamel-admin-minimum')); select count(*) into "remainingAdmins" from public."userGroups" ug join public."groups" g on g."id" = ug."groupId" where g."value" = 'admin' and ug."appKey" = 'enamel' and ug."isSynthetic" is false and ug."toAt" is null and ug."deletedAt" is null and ug."id" <> old."id"; if "remainingAdmins" < 1 then raise exception 'cannot remove the last live enamel admin grant (userGroups.id=%) -- enamel must always retain at least one', old."id"; end if; return new; end; $function$; COMMENT ON FUNCTION public."fn_guardEnamelAdminMinimum"() IS NULL; CREATE TRIGGER "tg_userGroups_forbidGrantForDeletedUser" BEFORE INSERT OR UPDATE OF "userId", "toAt", "deletedAt" ON public."userGroups" FOR EACH ROW WHEN (new."toAt" IS NULL AND new."deletedAt" IS NULL) EXECUTE FUNCTION public."fn_forbidGrantForDeletedUser"(); CREATE TRIGGER "tg_userGroups_forbidGrantForInactiveGroup" BEFORE INSERT OR UPDATE OF "groupId", "toAt", "deletedAt" ON public."userGroups" FOR EACH ROW WHEN (new."toAt" IS NULL AND new."deletedAt" IS NULL) EXECUTE FUNCTION public."fn_forbidGrantForInactiveGroup"(); CREATE TRIGGER "tg_userGroups_guardEnamelAdminMinimum" BEFORE UPDATE OF "toAt", "deletedAt", "appKey", "groupId", "isSynthetic" ON public."userGroups" FOR EACH ROW WHEN (old."toAt" IS NULL AND old."deletedAt" IS NULL AND (new."toAt" IS NOT NULL OR new."deletedAt" IS NOT NULL OR new."appKey" IS DISTINCT FROM old."appKey" OR new."groupId" IS DISTINCT FROM old."groupId" OR new."isSynthetic" IS TRUE)) EXECUTE FUNCTION public."fn_guardEnamelAdminMinimum"(); DROP FUNCTION public."fn_forbidUserGroupsTruncate"(); DO $postflight$ BEGIN IF (SELECT md5(prosrc) FROM pg_proc WHERE oid='public."fn_guardEnamelAdminMinimum"()'::regprocedure) IS DISTINCT FROM 'b7d3bd53a7df66d55373abd946325484' OR to_regprocedure('public."fn_forbidUserGroupsTruncate"()') IS NOT NULL THEN RAISE EXCEPTION 'ENAMEL-81 revert: function body/absence mismatch'; END IF; IF (SELECT count(*) FROM pg_trigger WHERE tgrelid='public."userGroups"'::regclass AND NOT tgisinternal AND tgenabled='O' AND ((tgname='tg_userGroups_forbidGrantForDeletedUser' AND tgtype=23) OR (tgname='tg_userGroups_forbidGrantForInactiveGroup' AND tgtype=23) OR (tgname='tg_userGroups_guardEnamelAdminMinimum' AND tgtype=19))) <> 3 OR EXISTS (SELECT 1 FROM pg_trigger WHERE tgrelid='public."userGroups"'::regclass AND tgname='tg_userGroups_forbidTruncate') THEN RAISE EXCEPTION 'ENAMEL-81 revert: trigger shape/absence mismatch'; END IF; END $postflight$; COMMIT;
• db-enamel-ca blocked · 1w ago
  Seat and order GO rebind recorded for db-enamel-ca on exact b9b22a25; apply-then-savepoint probes authorized. Revert SQL captured from live catalog and recorded in full as spec event before any DDL; /gdrive/projects/evolutiva/enamel/enamel-81-085/REVERT.sql SHA256 817f99f8a72116c4be5f4d105ea442296b534412fc9a4ed05d993ce6cf1facf2. Remaining execution primitive gap: this seat has Supabase execute_sql/apply_migration MCP calls but no persistent database session handle or production psql DSN, so cannot guarantee PM-required same-DB-session preapply capture, exact-byte apply, immediate post-commit readback and tee streaming. No production DDL/DML run; route to psql-capable apply seat or explicitly accept precreated durable MCP transcript plus immediate separate-call readback.
• coder-enamel-cc decision · 1w ago
  PRIMITIVE GAP ANSWERED AND ROUTE FIXED, 2026-10-06 11:07 ART (pmmaster tag pmmaster-evolutiva-cc-muwr6nczebb4-coder-enamel-cc; my measurement tags coder-enamel-cc-muwr6xouvooa and coder-enamel-cc-muwr74ums0fe). db-enamel-ca refused the same-session condition on a MISSING PRIMITIVE and was right: MCP execute_sql/apply_migration gives no persistent session handle and no live tee streaming. I checked whether a credential route existed before escalating. MEASURED ON VENUS: ~/.config/postgres holds 13 files and NONE is a db-enamel seat; shared/md/enamel-db-agents.md points the DB password at app/.env.local, which DOES NOT EXIST on this host, so that documented location is stale and needs its own row; my own ~/.config/postgres/coder-enamel-cc.env is PGHOST=127.0.0.1 PGDATABASE=enamel - a local cluster, NOT the Supabase project eprpywqwzsvrjeaforei - so it is not a prod path and was not treated as one. psql 17.11 IS installed; only the DSN is absent. ANSWER TO PM: no enamel seat holds a production psql DSN. No credential was provisioned. PM ACCEPTED THE MCP ROUTE and closed the drift gap instead of the session boundary, which is the right layer: the same-session rule existed only to guarantee the revert is byte-exact for the state being overwritten, and db-enamel-ca already holds that MORE durably as a file - /gdrive/projects/evolutiva/enamel/enamel-81-085/REVERT.sql SHA256 817f99f8a72116c4be5f4d105ea442296b534412fc9a4ed05d993ce6cf1facf2, prior prosrc md5 b7d3bd53 rechecked live. A file on disk beats a terminal transcript, which is this morning's venus lesson. AUTHORIZED SEQUENCE: (1) IMMEDIATELY BEFORE the apply, re-read prosrc md5 and confirm it is still b7d3bd53 - a mismatch means the function changed since capture, so ABORT and report, do not apply; (2) apply b9b22a25 exact bytes; (3) IMMEDIATELY AFTER, in the next call, read back the installed definitions and the trigger catalog rows; (4) then the arms, each in its own savepoint-scoped transaction against the applied object. EVIDENCE LABEL, mandated and not negotiable: 'separate-call MCP transcript with pre-apply hash recheck and immediate post-apply readback'. NEVER 'same-session'. db-enamel-ca was right to refuse relabelling and does not have to. Unchanged: unexpected red on any arm means REVERT from that file rather than patching forward; the all-column AFTER UPDATE OR DELETE trigger and the statement-level TRUNCATE refusal must each be SEEN TO FIRE; arm (k) on a fresh connection with no prior guard invocation plus its PERFORM-removed red variant. db-enamel-ca closes this row. Nothing further owed by coder-enamel-cc on ENAMEL-81.
• db-enamel-ca progress · 1w ago
  MCP route prep: durable transcript opened BEFORE read-only preflight at /gdrive/projects/evolutiva/enamel/enamel-81-085/TRANSCRIPT.md. SELECT-only BEGIN READ ONLY + exact source DO preflight (lines 181-251 of b9b22a25) + ROLLBACK returned preflight_pass; raw MCP response appended to transcript. No DDL/DML. Executable prior-definition revert already recorded as spec event and file SHA256 817f99f8. Awaiting coder-enamel answer on any production psql DSN before the exact apply call, per PM muwr6nczebb4.
• db-enamel-ca blocked · 1w ago
  b9b22a25 apply failed in postflight: SQLSTATE 42702 ambiguous tgtype at lines 462/482; transaction rolled back. Old admin body b7d3bd53 and trigger shapes 23/23/19 remain; new truncate objects and 085 registry row absent. New source digest, audit PASS, PM GO required.
• db-enamel-ca progress · 1w ago
  APPLY b9b22a25 failed with SQLSTATE 42702 in postflight (ambiguous tgtype) after DDL, before COMMIT. Supabase apply_migration returned error; independent separate reads: old fn_guardEnamelAdminMinimum prosrc MD5 b7d3bd53a7df66d55373abd946325484, original trigger tgtypes 23/23/19, no fn_forbidUserGroupsTruncate or trigger, no enamel_085 migration registry row. No arm probes run. Durable separate-call MCP transcript: /gdrive/projects/evolutiva/enamel/enamel-81-085/TRANSCRIPT.md; revert artifact remains /gdrive/projects/evolutiva/enamel/enamel-81-085/REVERT.sql SHA256 817f99f8a72116c4be5f4d105ea442296b534412fc9a4ed05d993ce6cf1facf2. Exact source must be revised and reaudited; old GO cannot cover new bytes.
• db-enamel-ca progress · 1w ago
  Failure containment: enamel_085 b9b22a25 has its postflight inside its own BEGIN/COMMIT transaction. The postflight's SQLSTATE 42702 exception at (lines 462/482) aborted the whole transaction before COMMIT, including the preceding DDL. Independent catalog/registry reads confirmed old admin MD5 b7d3bd53, trigger tgtypes 23/23/19, no truncate function/trigger, zero enamel_085 registry rows. Keep preflight AND postflight assertions inside each migration transaction; a separate verification pass would not provide this rollback. b9b22a25 GO spent; next source change is variable rename only, new committed digest, fresh exact audit PASS and GO.
• db-enamel-ca progress · 1w ago
  Failure containment: enamel_085 b9b22a25 has its postflight inside its own BEGIN/COMMIT transaction. The postflight SQLSTATE 42702 ambiguity in select tgtype into same-named variable (lines 462/482) aborted the whole transaction before COMMIT, including preceding DDL. Independent catalog and registry reads confirmed old admin MD5 b7d3bd53, original trigger tgtypes 23/23/19, no truncate function or trigger, and zero enamel_085 registry rows. Keep preflight and postflight assertions inside each migration transaction; a separate verification pass would not provide this rollback. b9b22a25 GO spent; next source change is variable rename only, new committed digest, fresh exact audit PASS and GO.
• coder-enamel-cc progress · 1w ago
  DEFECT FIXED, push queued behind the venus-host.push-gate (held by coder-terra-cc; asked for successor:@next since this is a p1 blocking a GO loop). THE DEFECT: the postflight DO block declared a PL/pgSQL local named tgtype, so 'select tgtype into "tgtype" from pg_trigger' at lines 462 and 482 was ambiguous against pg_trigger.tgtype and raised 42702 AT RUN TIME - not at create time, which is why no review caught it and why only an apply attempt could. Renamed to "observedTgtype" and NOTHING else, per pmmaster's constraint: 7 lines changed, rename only, both guard body pins unchanged at 07f77cf43a8251e7f92708dab51ac91f and 894eda506c5f0ecadadff437c0a714b6. New bytes 27850, SHA256 849f9aaa80e0e4b492a5e3c576c93c3da3cfb9961bdc84600d0b7fe085db12ba. I had drafted an 8-line comment warning against renaming it back and REMOVED it to honour 'do not touch any other line' - the lesson goes on the row and in the template row instead, where it is more useful anyway. WHY NINE OF TEN LOCALS WERE SAFE, which is the generalisable half: every other local in this file is quoted camelCase (bodyMd5, triggerCount, durableAdmins, wasAdminGrant, wasDurable, isStillDurable, remainingAdmins, guardOid, truncateOid) and matches no pg_catalog column. This one had copied the catalog's own spelling. The project's English-camelCase identifier convention was doing real work as a collision guard and nobody had noticed it was load-bearing. WHY THE FAILURE WAS A NON-EVENT, and pmmaster is right that this matters more than the bug: the postflight sits INSIDE the file's own transaction, so a postflight raise takes the whole apply down with it. THE SAME self-contained begin;/commit; that made a pre-apply rehearsal impossible is what made a failing postflight harmless - nothing committed, no residue, and db-enamel-ca's independent reads confirmed it rather than inferring it from the error (admin body still b7d3bd53, trigger tgtypes still 23/23/19, no truncate function or trigger, zero enamel_085 registry rows). That is the argument for keeping assertions inside the migration's transaction rather than in a separate verification pass. STILL UNEXERCISED, and this failure says nothing about them: every postflight assert after line 462 never executed, and arms (a)-(k) were never reached. b9b22a25's GO is spent and dead; the new digest needs its own audit-general-ca PASS and a fresh GO. Order, route (b) evidence shape, REVERT.sql at 817f99f8 and all eleven arm requirements carry over unchanged.
• coder-enamel-cc commit · 1w ago
  enamel_085 digest 5 pushed 8086011. SHA256 849f9aaa80e0e4b492a5e3c576c93c3da3cfb9961bdc84600d0b7fe085db12ba, 27850 bytes. Source review ask sent to audit-general-ca, tag coder-enamel-cc-muwrj8dkltf2, with the note that every postflight assert after line 462 and all of arms (a)-(k) remain unexercised so a PASS still rests on source only. ENAMEL-89's doc fix pushed in the same hold at a247c2d6. GATE MECHANICS WORTH KEEPING, since six lost races cost six turns today: take venus-host.push-gate YOURSELF before running gitpush.sh. It then prints 'NOT releasing - held it before this run (how_acquired=reacquired)', the hold survives, several pushes fit in one hold, and unlock({successor:'@next', successor_ttl:N}) transfers inside the unlock transaction. Once gitpush owns the acquire the transfer is unreachable to the pusher - it bare-releases inside the push and the hub has already broadcast a free-for-all, so a later unlock returns lock_held_by_other. The release DM is a notification, not a reservation: it fans out to every waiter and shortest turn-latency wins, which is how coder-apiimages-cc lost nine consecutive acquires. Handed the hold to them via @next. Corrected to coder-terra-cc, pmmaster, coder-apiimages-cc and bin-venus-cc at tag coder-enamel-cc-muwrjlc96xk4; the script-side fix is bin-venus-cc's surface and I did not file it for them.
• coder-enamel-cc note · 1w ago
  audit-general-ca PASS:849f9aaa80e0e4b492a5e3c576c93c3da3cfb9961bdc84600d0b7fe085db12ba on commit 8086011, source only, 2026-10-06 11:18 ART (tag audit-general-ca-muwrk4gklow3). They rehashed the committed blob at 27850 bytes and diffed it against the failed b9b22a25: exactly seven references rename the local tgtype to observedTgtype, no other line changes, both SELECTs now assign to a name distinct from pg_trigger.tgtype, the postflight's other locals do not collide with any selected column, and the guard body pins are unchanged. They state explicitly that NO APPLY AUTHORITY follows - the postflight after the 42702 and arms (a)-(k) remain unexercised. Fresh GO requested from pmmaster-evolutiva-cc on 849f9aaa / 8086011 / 27850 bytes (tag coder-enamel-cc-muwrkpx2rrzu). Everything else carries over: db-enamel-ca as the named seat, route (b) evidence shape with the pre-apply prosrc md5 recheck against b7d3bd53, REVERT.sql at 817f99f8, apply-then-savepoint-scoped-probes, and all eleven arm requirements including (k)'s fresh connection and its PERFORM-removed red variant.
• coder-enamel-cc decision · 1w ago
  APPLY GO ISSUED for digest 5, 2026-10-06 11:24 ART (pmmaster tag pmmaster-evolutiva-cc-muwrslir5ola-coder-enamel-cc), relayed to db-enamel-ca at tag coder-enamel-cc-muwrsze9r3p5 since it was addressed to me and they are the named seat. AUTHORIZED BYTES: SHA256 849f9aaa80e0e4b492a5e3c576c93c3da3cfb9961bdc84600d0b7fe085db12ba, commit 8086011, 27850 bytes, db/migrations/draft/enamel_085_usergroups_write_read_liveness.sql. SEAT: db-enamel-ca. Verdict cited: audit-general-ca PASS:849f9aaa, source only, tag audit-general-ca-muwrk4gklow3. Re-hash immediately before the apply and ABORT on mismatch; the GO dies with the digest, and a correction the seat believes is obviously right still voids it. CARRIED OVER UNCHANGED: route (b); pre-apply pg_proc.prosrc md5 recheck of the admin body against b7d3bd53 with abort on difference; REVERT.sql at 817f99f8 held ready before the first statement; apply-then-savepoint-scoped-probes; all eleven arms (a)-(k) including (k)'s fresh connection and PERFORM-removed red variant; in-session readback of every object the file claims to install; revert, never patch forward. TWO BOUNDS STATED BY THE GO AND WORTH KEEPING: (1) the GO is an AUTHORIZATION, not an event - nothing is true because it was written, so the close carries the live catalog readback rather than a restatement of the plan; (2) a raising postflight assertion rolls the whole DDL back inside the file's own transaction, which is a NON-EVENT reported as a failed apply with prod unchanged and the pre-state md5 re-verified, not an incident. ENAMEL-86 stays Elazar-gated and does not start on this apply landing - it needs actor-of-record consent, which is his to give. Nothing further owed by coder-enamel-cc; db-enamel-ca closes this row.
• db-enamel-ca unblocked · 1w ago
  Digest 5 849f9aaa applied under PM GO; separate-call MCP readback confirms migration 20261006142541, 27850 bytes, new admin/truncate body pins 07f77cf4/894eda50, trigger tgtypes 25/34 and widened forbid triggers. Post-apply rollback probes now running; no concurrency claim.
• coder-enamel-cc verified · 1w ago
  INDEPENDENT READ BY coder-enamel-cc, 2026-10-06 14:29:58Z, SELECT-only: enamel_085 IS APPLIED AND COMMITTED. Recorded because I had claimed it once from a trigger listing and a claim like that should not rest on one observation. DECISIVE, strongest first: fn_guardEnamelAdminMinimum body md5 is 07f77cf43a8251e7f92708dab51ac91f, the REVIEWED NEW body pinned in the migration - NOT b7d3bd53, the pre-state the GO said to abort on. fn_forbidUserGroupsTruncate exists. Triggers on public.userGroups read forbidGrantForDeletedUser:23, forbidGrantForInactiveGroup:23, forbidGroupAppKeyMismatch:23, forbidTruncate:34, guardEnamelAdminMinimum:25 - i.e. the post-085 shape, where the pre-state was 23/23/19. LABELLED WEAKER: 3 rows in supabase_migrations.schema_migrations matched a loose version-like-085-or-name-like pattern, which does not identify this migration on its own. The body md5 and the truncate function are what settle it, not the row count. THIS IS NOT THE READBACK AND IS NOT OFFERED AS ONE. db-enamel-ca still owes the close: full object inventory, arm-by-arm result for (a)-(k), and every arm they could not exercise NAMED as unexercised rather than folded into a pass. Also now owed on the row: what they ran and when. The GO's pre-apply b7d3bd53 recheck will fail by design from here, because the body it guarded is already replaced - so if the apply landed before my 11:28 read, that recheck either passed at the time or was not run, and which of the two it was is a fact the row needs. PM notified that the GO at 849f9aaa is spent if that apply was it (tag coder-enamel-cc-muwrzq9075ej).
• db-enamel-ca blocked · 1w ago
  Digest 5 849f9aaa applied and registered at 20261006142541, then REVERT.sql SHA256 817f99f8 executed under PM conditional revert instruction after arm c red variant failed unexpectedly. Probe design error: old BEFORE UPDATE OF trigger was paired with new AFTER-body function returning NULL, suppressing setup UPDATE; not a shipped-guard failure. Independent post-revert catalog confirms old admin body MD5 b7d3bd53, original trigger shapes/WHEN, no truncate function/trigger, ACL and search_path restored; fixture user/group residue 0. Migration registry remains consumed. Arms a/b/f green+red and c/d/e/g green ran; c red failed for probe design; d/e red, j/k not run; h UNFORCED. No further apply or probe under spent digest. Requires PM forward-route decision/new stem.
• db-enamel-ca progress · 1w ago
  Apply-seat report sent to PM tag db-enamel-ca-muwsdx1ojy93. Exact digest 849f9aaa applied 14:25:41Z after old-body MD5 b7d3bd53 passed at 14:25:11Z; separate-call reviewed-body/catalog readback 14:26:19Z. a,b,f green+red PASS; c,d,e green PASS; g benign PASS; c red probe-design failure; d/e red, h, j, k UNEXERCISED; i residue zero/admin count one. PM-conditional REVERT.sql SHA 817f99f8 executed 14:34:05Z, readback 14:34:55Z old admin body b7d3bd53, old trigger shapes, truncate objects absent. Registry version 20261006142541 remains consumed. Transcript /gdrive/projects/evolutiva/enamel/enamel-81-085/TRANSCRIPT.md. No further apply under spent GO.
• db-enamel-ca progress · 1w ago
  REGISTRY/CATALOG DIVERGENCE: supabase_migrations.schema_migrations version 20261006142541 is CONSUMED for enamel_085 SHA256 849f9aaa (27850 bytes), while live userGroups objects are at PRE-STATE after PM-directed revert: fn_guardEnamelAdminMinimum body MD5 b7d3bd53, triggers 23/23/23/19, no truncate trigger/function, old ACL/path/comment. The registry row means 085 applied once, not that its DDL remains installed. Do not re-run 085, delete or un-consume its row, or infer the guard from migration history. Forward remedy shape: NEW stem enamel_086 carrying reviewed DDL, new digest, audit-general-ca exact-byte PASS, fresh PM GO. Arm c red probe must restore prior FUNCTION BODY and prior BEFORE UPDATE OF trigger TOGETHER; mixed old trigger/new AFTER body is a third invalid state. d/e red and j/k NOT RUN; h UNFORCED. No current apply authority.
• db-enamel-ca progress · 1w ago
  enamel_086 forward migration and corrected arm-c prior-pair red probe committed as eb6fd6602e4acecbcc0db121b4147d7de7339ba2. Migration SHA256 fd0673cf5673002061d58ed16f99049513b5fc511a122f32a96528f0a2cf0132; probe SHA256 82b7dc64c1bbf92797d15530e7595989c26ffe4dc664bf62f6c614c453b1c26b. Exact-byte source review requested from audit-general-ca/PM/coder tag db-enamel-ca-muwsstzzdzsm. Source only; no 086 DDL, rehearsal, or probe run; no 086 GO. 085 registry remains consumed while live objects are reverted prestate.
• db-enamel-ca progress · 1w ago
  ENAMEL-88 migration stem enamel_086 claimed via claim-enamel-migration.py --adopt for the pre-existing committed draft. Immutable origin tag refs/tags/migration-claim/enamel_86 verified at OID cdd61eee1c7371f59655c94d03dfbd7ef05d5287, pointing to commit eb6fd6602e4acecbcc0db121b4147d7de7339ba2; annotation names ENAMEL-81, db-enamel-ca and exact draft path. Local and remote tag OIDs matched after push. Migration SHA256 remains fd0673cf5673002061d58ed16f99049513b5fc511a122f32a96528f0a2cf0132; no new stub or DDL created. Exact source review remains pending.
• db-enamel-ca verified · 1w ago
  REGISTRY/CATALOG DIVERGENCE after conditional revert: supabase_migrations.schema_migrations still contains consumed stem 20261006142541 for enamel_085 SHA256 849f9aaa80e0e4b492a5e3c576c93c3da3cfb9961bdc84600d0b7fe085db12ba (27850 bytes), while EVERY touched live object is at pre-state: admin body MD5 b7d3bd53a7df66d55373abd946325484, userGroups triggers 23/23/23/19, no truncate function or trigger, prior ACL/search_path/comment restored, zero fixture residue. Thus the registry asserts a landed migration that the current catalog contradicts. This is the observed 14:34:55Z post-revert readback, not an inference from a GO. Remedy is new stem enamel_086 carrying reviewed DDL and corrected arm-c red probe restoring old function BODY TOGETHER WITH old trigger; never replay enamel_085 or un-consume the row. No 086 DDL run.
• db-enamel-ca progress · 1w ago
  enamel_086 exact source revised after audit-general BLOCK:fd0673cf. New committed migration 0157c738098cdd1ea9c440bad6a15ab367ceb21b, SHA256 de56a7119fcc1aa4c9027eb46acd771a198ca29102f28ae635ec21dd167835c7. Postflight now requires four changed triggers present with exact enabled state, tgtype, watched columns/full definition and tgfoid bound to expected public function, plus exact five-trigger inventory; a missing CREATE or wrong binding can no longer pass by empty EXISTS. Reviewed guard DDL and arm-c probe SHA256 82b7dc64 remain unchanged. Fresh exact-byte source review requested tag db-enamel-ca-muwtakiu6pea. Removed-create/wrong-binding reds not executed, no 086 DDL/probe, no apply GO.
• db-enamel-ca progress · 1w ago
  Committed source-only postflight forced-red variants at e982b4a3e9e1f4a76016212f66b33438ad691368. Base enamel_086 migration SHA256 de56a7119fcc1aa4c9027eb46acd771a198ca29102f28ae635ec21dd167835c7. Missing-create variant db/probes/enamel_086_missing_create_red_rollback.sql SHA256 fd6c0b465fcfc37d5952572cb7f014b23e8366533689da3875e020cabaeee6ba; wrong-function-binding variant db/probes/enamel_086_wrong_binding_red_rollback.sql SHA256 b1e8e0cb9be2a41a84a03986a6f26341926b8787f4960087781a02d9e1a9aa6b. Both differ from base only by stated mutation, source header, and terminal ROLLBACK. Exact source review requested tag db-enamel-ca-muwtdplvw9kt. NOT RUN; no 086 DDL, rehearsal or apply GO. Expected postflight raise will require fresh zero-residue catalog readback if authorized to exercise.
• db-enamel-ca progress · 1w ago
  ENAMEL-88 claim provenance: refs/tags/migration-claim/enamel_86 was minted via --adopt while that flag existed only in coder-enamel-cc uncommitted working tree. Reproduction gap is now closed by coder-enamel-cc commit 9a69684 on origin/main, which adds --adopt as a scoped recovery for one pre-existing draft and leaves the origin tag first-wins. Tag OID cdd61eee1c7371f59655c94d03dfbd7ef05d5287; no 086 DDL or apply inferred. The 086 migration remains SOURCE BLOCKed pending audit of later digest de56a711; two postflight red mutants are committed/source-only and NOT RUN.
• db-enamel-ca progress · 1w ago
  ENAMEL-086 source gate: audit-general-ca PASS:de56a711 on exact committed blob 0157c738, tag audit-general-ca-muwtc90sijfb. Reviewer hashed/diffed against fd0673cf: only postflight trigger assertions changed; count plus per-trigger enabled/tgtype/tgattr/tgfoid/exact-definition checks fail closed on missing, disabled, rebound or altered trigger; reviewed guard DDL/body pins unchanged. SOURCE ONLY. Missing-CREATE and wrong-binding mutants, 086 apply and arm-c runtime remain UNEXERCISED; no GO transfers from 085 or prior 086 bytes.
• db-enamel-ca blocked · 1w ago
  ENAMEL-086 forced-red execution capability refusal, 2026-10-06: PM requested missing-CREATE and wrong-function-binding mutants RUN ON SCRATCH before accepting control. db-enamel-ca lacks a verified Enamel scratch/prod psql DSN; only local coder-enamel-cc.env points to unrelated 127.0.0.1 cluster, and Enamel MCP execute_sql returns FGA Unauthorized. Mutants fd6c0b46 and b1e8e0cb are committed/source-only, NOT RUN; do not treat them as red evidence or run on production under scratch instruction. Expected trigger-definition provenance is already in de56 :451-453, captured from 085 post-apply readback. PM asked to route execution to verified scratch-capable seat. No DDL/probe by db-enamel-ca.
• db-enamel-ca audit-finding · 1w ago
  WITHDRAWN source PASS:de56a711. audit-general-ca correction tag audit-general-ca-muwtfgbfk0l6 accepts the fifth-trigger substitution counterexample: count=5 plus four identity rows permits tg_userGroups_forbidGroupAppKeyMismatch replacement. Live verdict is BLOCK:de56a711 until the fifth is pinned by identity and a substitution mutant forced red. Probe-file source PASSes fd6c0b46/b1e8e0cb were diff-scoped and do not authorize execution or rescue the blocked base. Previous ENAMEL-81 progress event recording PASS:de56 is superseded by this finding; no DDL/probe run.
• db-enamel-ca progress · 1w ago
  enamel_086 source-only revision committed: base SHA256 5a03f8375c8b360c281ab07d010bd952fcd18189b8cb917b58873d6738422011 at 3dd483c pins all five userGroups triggers by identity; unchanged fifth is measured public fn_forbidGroupAppKeyMismatch, tgtype 23/O, tgattr 3 4, exact pg_get_triggerdef under search_path "$user", public, extensions. Three rollback mutant files committed at b38cc59: missing identity adef0a09, fifth substitution 8eb9db37, same-name alternate-schema OID c800a46a. All SOURCE ONLY, NOT RUN; no verified scratch Enamel DB or production execute_sql credential. OID probe setup must first prove equal triggerdef and distinct tgfoid or its red is setup failure. No DDL/apply GO.
• db-enamel-ca blocked · 1w ago
  support-evolutiva-cc refused local disposable Enamel-schema Postgres: evolutiva-commons Database forbids local Postgres standing in for the Supabase project. Forced-red trigger mutations cannot be exercised by SELECT-only catalog reads; sanctioned execution environment/route remains unresolved. Old fd6c0b46/b1e8e0cb probes are superseded; new 5a03f837 base and three b38cc59 probes are source-only/unrun. Route decision owed by PM/Elazar, not a workaround.
• support-evolutiva-cc verified · 1w ago
  086 mutant arms (base 5a03f837, three b38cc59 probes) ruled UNEXERCISED, not blocked-pending-retry: forced-red requires transactional DDL + the installed postflight RAISEing, which SELECT-only catalog reads can inspect but not prove firing. support-evolutiva-cc declined a local disposable Enamel-schema Postgres under evolutiva-commons sec Database (restoring a dump into a local server to test against is barred regardless of schema-only scope); db-enamel-ca accepted the refusal, no local/production SQL run. Two-gate deadlock: forced-red needs an execution environment, no-local-Postgres forbids the only one proposed. Missing primitive is a sanctioned disposable environment - Elazar's call, routed via CLI by support-evolutiva-cc 2026-10-06. Partial read-only mitigation already landed separately (coder-enamel-cc, thread muwtx77gvrz2): scenario A (missing-create) on the EARLIER fd6c0b46/b1e8e0cb pair settled fully read-only; that pair is superseded by this base+probes set and was never run either.
• db-enamel-ca note · 1w ago
  Forced-red execution hold refined from support-evolutiva-cc muwtuj7zfcba: a postflight-only variant still requires restoring userGroups schema and trigger functions into local Postgres, barred by evolutiva-commons Database. db-enamel-ca also cannot obtain schema-only dump through execute_sql (FGA Unauthorized). Two missing primitives: a sanctioned disposable environment and a credentialed schema-dump source. Support is routing to Elazar via CLI; no local target, SQL execution, or production apply.
• db-enamel-ca note · 1w ago
  PM read-only alternative assessed against committed enamel_086 5a03f837 postflight: live catalog remains prestate with four noninternal userGroups triggers and fn_forbidUserGroupsTruncate absent. The actual postflight first requires count=5 (lines 464-468), then loops five expected identities and RAISEs on failure (469-503). A SELECT-only query over current live rows hits prestate, not missing-CREATE or wrong-binding of the prospective installed state. A synthetic CTE can re-express the Boolean predicate but cannot execute this DO block, observe which RAISE fires, or prove pg_get_triggerdef/tgfoid binding after the mutation. No live execute_sql credential here. Therefore actual forced-red evidence requires sanctioned transactional DDL environment; arms remain UNFORCED/NOT RUN pending Elazar route.
• db-enamel-ca note · 1w ago
  Read-only alternative update: coder-enamel-cc ran a SELECT/CTE simulation against OLD de56a711 four-trigger logic; it proves count and tgfoid conjuncts behave logically in synthetic tuples, not the current 5a03f837 five-trigger postflight or actual RAISE. Current three mutants adef0a09/8eb9db37/c800a46a remain unrun. Sent exact current postflight predicate and mutation shapes to PM/support; same-name earlier-schema tgfoid/pg_get_triggerdef isolation requires DDL to observe real binding, so no forced-red PASS.
• db-enamel-ca progress · 1w ago
  audit-general-ca exact SOURCE PASS (muwu9hjasfm3) on enamel_086 base SHA256 5a03f8375c8b360c281ab07d010bd952fcd18189b8cb917b58873d6738422011 and probes adef0a09 (missing identity), 8eb9db37 (fifth substitution), c800a46a (same-name OID). Whole postflight has count=5 plus five identity-pinned rows; probe diffs preserve base except injected defect/comments/COMMIT-to-ROLLBACK. OID setup requires equal rendered definition and different tgfoid; setup failure is not successful red. All three NOT RUN, no verified sanctioned scratch environment or apply GO. Exact rendering may false-red under changed search_path.
• db-enamel-ca decision · 1w ago
  PM muwuadf0vofb: enamel_086 review scope COMPLETE at exact SOURCE PASS on base 5a03f837 and probes adef0a09/8eb9db37/c800a46a (audit-general-ca muwu9hjasfm3). All three forced-red mutants ship UNEXERCISED by explicit ruling, not proven; no sanctioned DDL-capable environment exists, local Postgres testing barred, and no scratch Enamel DB. This is a named open execution gap (missing primitive: sanctioned DDL environment), not a blocker on ENAMEL-81. No 086 migration apply or production behavior claim follows from source PASS. Earlier blockedReason about spent 085 stem is historical; forward 086 is source-reviewed.
• db-enamel-ca unblocked · 1w ago
  PM ruled source review complete on 086 exact bytes; three mutants UNEXERCISED as a named open gap, not row blocker. Migration unapplied; await separate apply authorization.