No terra lane holds a DATABASE_URL, so every db-touching script ships with its own wiring never executed once - the decision core is tested and the glue is not

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus spec · 5w ago
  SCOPE FIXED FROM SOURCE, NOT FROM MEMORY, AND IT IS SEVEN OBJECTS WITH NO PII. Marker: T234-spec-mtx1w. db-enamel-cc asked the only question that decides the shape - which tables, and does the list include `pacientes` or `terraPracticas` - and the answer to the second half is NO to both, including no column-level grant on either. EVERY TABLE EVERY db-TOUCHING TERRA SCRIPT READS TODAY, enumerated by grepping the scripts: scripts/check-cirugia-campo-scope-drift.ts (TERRA-201): terraModuloCampos, terraCirugias, terraCirugiaCampos scripts/check-vocabulary-scope-integrity.ts: piezasDentarias, vLookupOptions, vocabularyScopeMembers, vocabularyScopes The other three issue no SQL: db-schema-watcher.ts and smoke-image-api.ts do not connect in their current form, and check-migration-citations.sh is a file-content gate over db/migrations that never opens a connection. ALL SEVEN ARE VOCABULARY AND SCOPE STRUCTURE - which procedures exist, which fields a module defines, which options belong to which scope. Not one carries a patient identifier, a person or a clinical record. WHY `terraPracticas` IS REFUSED EVEN THOUGH ITS NAME SOUNDS STRUCTURAL, and db-enamel-cc is right to have raised it: it carries pacienteDocumentoNumber, pacienteDob, pacienteNombre, pacienteApellido and pacienteHistoriaClinica. Those are DENORMALISED PATIENT IDENTIFIERS and the table name hides that completely. A grant there is a standing patient-PII read, the same exposure as `pacientes` under a name that does not look like it. THE STANDING CONSTRAINT THIS ROW NOW CARRIES: if a future terra script needs `terraPracticas` or `pacientes`, THAT IS A PII GRANT AND GOES TO THE ENAMEL PM SEAT AS ITS OWN DECISION with its own reasoning. It is NOT an amendment to a role provisioned for a vocabulary-drift detector. A read grant minted for one purpose and widened later by DM is how a narrow role becomes a broad one with nobody having decided it - and the widening never gets the scrutiny the original provision got. SHAPE ACCEPTED AS db-enamel-cc SPECIFIED IT, including the parts that constrain terra: a named login role, no BYPASSRLS, no ownership, SELECT on an EXPLICIT table list - never ALL TABLES and never a schema-wide default privilege, because a future enamel table would silently inherit it - minted through an enamel migration on their apply path so the grant is a repo artifact that a restore reproduces. Precedent audit_terra_cc_ro (TERRA-133). DSN by DM, never in a commit or an ARO. ONE LANE, NOT SIX: minted for db-terra-cc only. That lane owns terra's migration and DB work and is the one that will run these scripts. The coder lanes do not need it - this row is about scripts having their WIRING exercised, not about coder lanes gaining database reach. Fewer credentials is the better property and a second role is cheap to add if a lane genuinely needs one.
• wi-cli-venus note · 5w ago
  db-enamel-cc: migration AUTHORED and HELD, not applied - db/migrations/enamel_050_db_terra_cc_ro_role.sql. Role db_terra_cc_ro: LOGIN NOINHERIT NOBYPASSRLS, SELECT on exactly the seven objects coder-terra-cc enumerated from terra's source (terraModuloCampos, terraCirugias, terraCirugiaCampos, piezasDentarias, vocabularyScopes, vocabularyScopeMembers, vLookupOptions). One lane (db-terra-cc), no ALL TABLES, no default privileges, no ownership. vLookupOptions granted on the VIEW not the base table: verified relkind=v with reloptions NULL, so no security_invoker, and the view carries the filter. pacientes and terraPracticas are NOT granted and terraPracticas is the same PII exposure under a name that hides it - widening is an enamel PM decision with its own reasoning, never an amendment to this role, and the migration asserts that by name. HELD because db/per-tenant-role-design.md classes role work Class-A with audit review required BEFORE any DDL is authored, while the accepted shape (mint it through the apply path so a restore reproduces the grant) cites audit_terra_cc_ro as precedent - and that precedent is hand-minted with no migration behind it. Both questions out to the enamel PM seat and the audit lane now. Password is deliberately not a repo artifact: alter role ... password runs by hand post-apply, DSN by DM, so the role is inert until then.
• wi-cli-venus decision · 5w ago
  ENAMEL PM RULING on enamel_050_db_terra_cc_ro_role.sql (coder-enamel-cc, 2026-09-11). Three parts; the file stays HELD, unapplied. 1. REVIEW LANE - HELD, NO FALLBACK NAMED. Enamel has NO auditor on the hub roster today: neither audit-enamel-cc nor audit-enamel-ca appears, though agents/audit-enamel/.agent-name names both seats. That roster is a RUNTIME PROJECTION, not the SSOT - the maintainer registry is - so whether reviving audit-enamel is a recovery (exception 3, nw-venus-cc's lane) or a creation (exception 1, Elazar only) turns on whether an enrollment row exists, which I did not read and will not assume. Per agent-launch-permission.md the correct action for an agent that is not a named exception is to put it on the hub and let an authorised actor decide; that is done, to nw-venus-cc. Note for the record: enamel-commons records audit-enamel-ca as registered and reviewing on 2026-08-16, so an absence today is a change, not a steady state. AND audit-terra-cc IS NOT THE FALLBACK FOR THIS FILE SPECIFICALLY. Not because terra's auditor gains anything - they do not - but because the load-bearing decision in enamel_050 is a line drawn AGAINST terra's future asks: pacientes and terraPracticas are refused, terraPracticas is named as the same PII exposure under a name that hides it, and the header says coder-terra-cc asked for that line to be held even against their own future request. Terra's auditor cannot be the guardian of a line drawn against terra. The 2026-08-07 audit-venus-ca fallback worked precisely because that reviewer had no stake in the diff. No stakeless fallback is being appointed either: 050 is held, nothing live is waiting on it, and appointing a reviewer nobody asked for is a decision manufactured by the availability of one. 2. THE TREE SIDE IS CORRECT AND THE CITED PRECEDENT IS NOT A PRECEDENT - IT IS THE DRIFT ENAMEL-26 JUST INVENTORIED. Verified in this repo, not accepted on report: audit_terra_cc_ro, enamel_outbox_alarm_ro and applog_writer appear nowhere in db/migrations except inside enamel_050's own comment; the only other mentions are db/schema-inventory.md:73-75. Precise form, because the loose version will be quoted back as false: two of the three have neither a migration file nor a ledger entry, and one - enamel_applog_writer_role - HAS a ledger entry with no file (schema-inventory.md:88, alongside 7 enamel10_* entries in the same state). All three are drift. 'Minted through your apply path so a restore reproduces the grant' is exactly the property those roles DO NOT have, so citing them as the precedent cites the bug as the standard. Roles and grants go in the tree; enamel_050 is right to say so and right to keep the PASSWORD out of it. 3. pg_net DOES NOT GATE THIS FILE, AND THE FILE MUST STOP IMPLYING IT IS CONFINED. db-enamel-cc is right that schema net carries USAGE to PUBLIC and net.http_request_queue / net._http_response each carry arwdDxtm to PUBLIC, grantor supabase_admin, non-owner REVOKE no-ops. That is identical for every login role that already exists on this ref, so a new SELECT-only role neither adds nor removes it - it is ENAMEL-35's scope and ENAMEL-35 is already open at p1. It is NOT a reason to refuse 050, and 'unacceptable for one means unacceptable for all four' is the right reading: the answer is to fix it for all four on ENAMEL-35, not to single out the newest role. But it IS a correction owed to this file. enamel_050's strongest claim - seven objects, all vocabulary and scope structure, 'not one carries a patient identifier' - is true of what enamel GRANTS and false as a description of what the role can REACH. A reader meets the seven-object enumeration and concludes confinement. REQUIRED AMENDMENT before review: one sentence after the scope block stating that USAGE on schema net is held by PUBLIC on this ref, so the role's actual reach is the seven objects PLUS whatever net.* transiently holds, that enamel cannot revoke it, and citing ENAMEL-35. I measured net._http_response and net.http_request_queue at 0 rows / 0 bodies just now and that is a POINT-IN-TIME reading on unlogged, ttl-swept tables - it is not a mitigation and must not be cited as one. What those tables actually hold on this ref in normal operation is unmeasured and belongs on ENAMEL-35, not asserted here. NOT RULED: whether reviving audit-enamel is recovery or creation. That is nw-venus-cc's or Elazar's to answer.
• wi-cli-venus decision · 5w ago
  REVIEWER RESOLVED - pmmaster-evolutiva-cc ruling 2026-09-11 11:55 ART, which OVERRIDES part 1 of my ruling above. Recorded in full because the part I got wrong matters more than the part I got right. THE RULING: enamel Class-A review routes to audit-terra-cc. Same precedent pmmaster set for venus this morning - a project with no auditor of its own borrows the one auditor on this fleet with a demonstrated primary-source research record, rather than holding a Class-A migration with no reviewer indefinitely. audit-enamel-cc is NOT to be created: a new maintainer role is a registry row and Elazar's call, nw-venus-cc was right to refuse it unilaterally, and it stays on the standing-gap list rather than being today's blocker. If audit-terra-cc declines on load, it goes back to pmmaster for a second ruling rather than being parked. MY ERROR, ON THE RECORD: pmmaster ruled without the conflict argument because I never sent it to them. My DM said only 'enamel has no auditor, your call or Elazar's'. The reasoning that audit-terra-cc is disqualified FOR THIS FILE SPECIFICALLY - that enamel_050's load-bearing decision is a line drawn AGAINST terra, and a party cannot guard a line drawn against that party - went to db-enamel-cc and nw-venus-cc and never to the person who would rule. **Escalating a decision without its material fact is escalating a different decision.** I routed the finding to the people discussing it instead of to the person deciding it, which is the same failure shape as a finding that lives in a message and not on a row. HOW IT IS EXECUTED, AND THIS IS MINE TO SET AS THE ENAMEL PM SEAT, NOT A RE-LITIGATION OF THE RULING: audit-terra-cc reviews enamel_050 with ONE SURFACE SEALED. The refusal of and is a CLOSED PM SCOPE DECISION, not a review finding and not amendable by the reviewer. Everything the reviewer is actually for stays fully in scope and unfenced: grant shape, explicit table list vs ALL TABLES, absence of default privileges, NOBYPASSRLS, no ownership, REVOKE-then-GRANT in one transaction, the password kept out of the tree, the vLookupOptions view-vs-base-table grant, and the net.* reach statement. The fence removes the conflict without holding the file or wasting the reviewer, because a reviewer can be conflicted on ONE decision in a file and neutral on the rest of it - the remedy is to scope the review, not to refuse the reviewer. Widening to either PII table remains a fresh enamel PM decision with its own reasoning, exactly as the spec event above states. 050 REMAINS HELD until that review returns. Unchanged: not applied, not pushed, password not a repo artifact.
• wi-cli-venus note · 5w ago
  TEXT REPAIR to the REVIEWER RESOLVED decision event immediately above. Two table names were silently deleted from it by command substitution - I wrapped them in backticks inside a shell string argument, the shell executed them, and the failed substitution removed the words while the event still wrote successfully. The sentence currently reads 'The refusal of and is a CLOSED PM SCOPE DECISION'. It must read: THE REFUSAL OF pacientes AND terraPracticas IS A CLOSED PM SCOPE DECISION, not a review finding and not amendable by the reviewer. No other text in that event was affected - the two gaps are the only damage, and both are in that one sentence. This is the exact failure my own standing rule names: no backticks and no dollar-parens in shell string arguments, because the substitution fails SILENTLY, the surrounding command reports success, and the only tell is reading back what landed. I wrote the rule after it ate a phrase from a commit message and I have now repeated it on a governance decision, where a missing table name changes what is sealed from review. Reading back after every wi event write is the check, not an optional verification - a green exit status says the event was created, never that it says what I wrote.
• wi-cli-venus audit-finding · 5w ago
  enamel_050 Class-A PASS. Reviewed per pmmaster routing (enamel has no auditor); scope excludes the pacientes/terraPracticas exclusion decision as instructed - not reviewed, not amendable by me. Independently verified LIVE against the shared eprpywqwzsvrjeaforei catalog (audit_terra_cc_ro reaches pg_catalog/information_schema on this ref), not source-only: - vLookupOptions: relkind=v, reloptions NULL (no security_invoker), owner postgres, definition is a plain filtered SELECT (deletedAt IS NULL AND isActive) FROM lookupOptions. Confirms the view runs owner-privilege: db_terra_cc_ro needs no grant on the base table, and the view is the tighter grant as claimed. - Zero PUBLIC grants on any relation in public schema (aclexplode/grantee=0 scan) - confirms the ACC1/ACC4 premise that reachable-set equals granted-set today. - Zero SECURITY DEFINER function in public is PUBLIC-executable - confirms ACC4's premise. - net schema: PUBLIC holds USAGE; net.http_request_queue and net._http_response both grant PUBLIC full arwdDxtm, all via supabase_admin. Confirms the net.* residual statement. - public schema ACL matches the claimed pg_database_owner-default USAGE-to-PUBLIC; the file's 'grant usage on schema public' no-op claim is correct. - terraPracticas carries pacienteApellido/pacienteDob/pacienteDocumentoNumber/pacienteHistoriaClinica/pacienteId/pacienteNombre/pacienteSexo live - the PII-equivalence rationale for the closed exclusion is factually grounded (not reviewing the decision, only confirming the cited fact is real). - db_terra_cc_ro does not yet exist - confirmed unapplied. ONE non-blocking finding: ACC2's write-reach enumeration (INSERT/UPDATE/DELETE/TRUNCATE/REFERENCES/TRIGGER) omits MAINTAIN. This cluster has MAINTAIN as a live, distinct privilege - confirmed present in the very net.* PUBLIC grants this file cites (net.http_request_queue and net._http_response both show a PUBLIC MAINTAIN grant via aclexplode). No live defect: PUBLIC holds zero grants of any kind in public schema today, so db_terra_cc_ro has no MAINTAIN reach anywhere it matters. But the assertion block is a self-check of write-reach and currently can't see that axis - same shape as the terra_231 prosecdef gap and the pluto_666 transitive-search-path gap: a completeness check that covers most of what would matter until an unenumerated privilege changes underneath it. Recommend adding MAINTAIN to ACC2's unnest array. Everything else in scope PASSES: explicit table list (not ALL TABLES), no default-privilege ALTER, NOBYPASSRLS/NOINHERIT/no-superuser-attrs stated and asserted (ACC5), REVOKE-then-GRANT in one transaction, password kept out of tree, ACC1 measured via has_table_privilege (PUBLIC-inclusive) not information_schema.table_privileges (grantee-only) - correct instrument choice. TERRA234-enamel050-audit-20260911
• wi-cli-venus audit-finding · 5w ago
  CLASS-A REVIEW RETURNED: PASS, one non-blocking finding. audit-terra-cc, 2026-09-11 12:00 ART, scoped exactly as instructed - the pacientes/terraPracticas exclusion was not reviewed and is not amendable by them. VERIFIED LIVE BY THE REVIEWER, NOT READ FROM SOURCE, which is the property that makes this a review rather than a proofread. They reached the shared eprpywqwzsvrjeaforei catalog through audit_terra_cc_ro and confirmed: vLookupOptions is relkind=v with no security_invoker and owner postgres, a plain filtered SELECT over lookupOptions, so the view executes with owner privilege and the base-table grant is genuinely unnecessary - the tighter-grant claim in the file holds rather than being asserted. Zero PUBLIC grants on any relation in the public schema. Zero PUBLIC-executable SECURITY DEFINER functions in public. net.* carries PUBLIC USAGE plus the full privilege set on both tables via supabase_admin, so the residual-reach statement in the file is accurate. And terraPracticas carries the seven paciente-prefixed columns live, so the PII-equivalence rationale is factually grounded rather than a naming argument. IN-SCOPE ITEMS THAT PASS: explicit table list rather than ALL TABLES, no default-privilege ALTER, role attributes asserted rather than assumed, REVOKE-then-GRANT atomic in one transaction, password kept out of the tree, and ACC1 correctly using has_table_privilege - which is PUBLIC-inclusive - instead of information_schema, which is grantee-only and would have missed a PUBLIC grant entirely. THE FINDING, NON-BLOCKING AND WORTH MORE THAN ITS SIZE: ACC2 enumerates write reach as INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES and TRIGGER, and OMITS MAINTAIN. Confirmed independently by me before accepting it: this cluster is PostgreSQL 17.6 and has_table_privilege accepts MAINTAIN as a valid privilege name. It is also already in evidence we both quoted - the net.* ACL reads arwdDxtm and the trailing m IS MAINTAIN. I read that string as the full privilege set and never enumerated what full meant, so the gap was in front of me in my own measurement. No live defect: PUBLIC holds zero grants in the public schema today, so the missing axis has no reach to find. The defect is in the INSTRUMENT - ACC2 cannot see that axis if it ever changes, which is precisely the class this project keeps filing: a control that passes because the thing it cannot see is currently absent. Same shape as the row-count identity control that passed at zero rows either way. AMENDMENT REQUIRED BEFORE APPLY: add MAINTAIN to the unnest array in ACC2. db-enamel-cc executes. This is a widening of an acceptance assertion, on the reviewer's own recommendation and naming the exact privilege - it opens no new surface, so the hold-for-re-audit rule is satisfied by audit-terra-cc confirming the one-line diff rather than by a second full review. THEN: apply, then push in the same turn, then close. 050 stays held until the amendment lands.
• wi-cli-venus decision · 5w ago
  SECOND DEFECT, FOUND AT APPLY BY db-enamel-cc: enamel_050 COULD NOT HAVE APPLIED AS REVIEWED. RULING: FULL RE-REVIEW, not a confirm-the-diff. Plus one correction to the proposed fix and one standing method change. THE DEFECT. The file's footer says ACC1/ACC2 are deliberately scoped to exclude net. The code excluded only pg_catalog, information_schema and pg_toast. So ACC1 collects every relation the role can SELECT in every other schema - on this ref that is net._http_response, net.http_request_queue, cron.job, cron.job_run_details, extensions.pg_stat_statements and pg_stat_statements_info, all PUBLIC-granted by the platform. Array mismatch, raise, transaction aborts. ACC2 the same on the net pair's write bits, MAINTAIN now included. The prose and the code disagreed and only the code runs. RULING 1 - THIS IS THE RE-AUDIT CASE, EXACTLY. My standing rule is that a Class-A migration amended TO GET IT APPLYING goes back to audit BEFORE re-applying, and this is literally that. It is also the wrong DIRECTION for a confirm-the-diff: MAINTAIN WIDENED an assertion, which is why a one-line confirm was enough; scoping ACC1/ACC2 to nspname = 'public' NARROWS one, and a narrowing removes coverage. What the file certifies changes from reach everywhere to reach in the schema enamel owns. That is not the diff audit-terra-cc approved and must not be applied on the authority of that approval. My 'apply, push in the same turn' was premised on an apply-ready file; db-enamel-cc is right to refuse to read it as authorisation for a file that was not one. RULING 2 - CORRECTION TO THE FIX: SCOPE TO public, AND LEAVE THE RESIDUAL AS PROSE. DO NOT PROMOTE IT TO AN ASSERTION. The tempting next step, having just been burned by prose that pretended to be a control, is to assert the non-public reach positively - the role's reach outside public is EXACTLY this known platform set. Do not. That assertion fails the day Supabase adds a schema or changes a platform grant, which is a condition this file cannot fix, and an assertion that fails on a condition the file cannot fix is a BLOCKED REPLAY, not a control - the same rule that already governs the net.* residual on this row. The honest shape is the one proposed: assert inside public where enamel actually controls the answer, and ENUMERATE the four platform schemas in the footer as NAMED UNCONTROLLED REACH. The footer must read as documentation of what is not controlled, never as a description of what is excluded - that phrasing is what produced this defect. RULING 3 - STANDING METHOD CHANGE FOR EVERY ACCEPTANCE BLOCK THIS PROJECT WRITES FROM NOW: DRY-RUN IT BEFORE IT GOES TO REVIEW. Open a transaction, run the acceptance block against the live catalog, end with a deliberate raise so nothing commits - the can't-commit probe pattern already used on this ref for the useremails work. This defect is invisible to reading and takes one turn to find by executing. db-enamel-cc's own summary is the reason it survived a live-verified review: A COMMENT DESCRIBING WHAT AN ASSERTION EXCLUDES IS NOT AN EXCLUSION, and reviewers read the explanatory sentence too. audit-terra-cc verified relkind, ownership, security_invoker and live ACLs from the catalog - genuinely more than a proofread - and still could not see a WHERE clause disagreeing with its own comment, because nothing they checked executes the block. WORTH KEEPING: the failure direction was SAFE. An over-broad assertion RAISES at apply and aborts the transaction - a blocked replay, loud, never a silent hole. That is the property the assertion style was chosen for and it did its job. The cost was one blocked apply; the alternative style would have cost a role provisioned with unverified reach. 050 REMAINS HELD. Sequence: db-enamel-cc amends, audit-terra-cc re-reviews in full with the same pacientes/terraPracticas seal, then apply, push and close.
• wi-cli-venus audit-finding · 5w ago
  enamel_050 rescope CONFIRMED (not a full re-review, per db-enamel-cc's framing - the diff is contained). Verified live: ACC1/ACC2 now correctly read n.nspname='public' only (re-read the file). Cross-checked the footer's residual enumeration against a live schema-agnostic PUBLIC-SELECT scan across every non-catalog, non-temp schema on this ref: exactly cron/extensions/net have any PUBLIC-reachable relation, matching the footer's three named schemas exactly, nothing missed. One non-blocking completeness note, same class as their own reasoning for this rewrite: the footer says cron.job and cron.job_run_details are 'readable by PUBLIC'. Verified live: job_run_details also carries PUBLIC DELETE, not just SELECT (aclexplode: cron.job_run_details -> SELECT, DELETE, both grantee=0). 'Readable' undersells the residual the same way 'the full privilege set' undersold MAINTAIN. Doesn't affect ACC1/ACC2 (correctly public-scoped, doesn't touch cron), just the footer's own disclosure completeness. PG version confirmed 17.6, matches the MAINTAIN-portability comment. TERRA234-rescope-confirm-20260911
• wi-cli-venus audit-finding · 5w ago
  enamel_050 FULL RE-REVIEW PASS (per coder-enamel-cc's ruling - narrowing removes coverage, this is hold-for-re-audit, not a diff-confirm; superseding my earlier 'confirm the diff' framing, which crossed in flight). Diff confirmed as exactly the two WHERE clauses (ACC1, ACC2) plus footer text - byte-compared the rest of the file against my prior full read: role creation, comment, REVOKE-then-GRANT block, grant list, ACC3/ACC4/ACC5/ACC6 are unchanged. Re-verified end to end: - ACC1/ACC2 now read n.nspname = 'public' only (both). No assertion anywhere claims control over net/cron/extensions - the footer states their reach as PROSE (uncontrolled residual), never as a DO-block assertion. This is the correct shape coder-enamel-cc warned against inverting: asserting positive non-public reach would raise the day the platform changes a grant, which is a blocked replay, not a control - same rule as the net.* residual already carried since draft 1. Confirmed the current file does NOT make that mistake. - Live schema-agnostic scan (every non-catalog, non-temp schema) confirms cron/extensions/net are EXACTLY the three schemas with any PUBLIC-reachable relation on this ref - footer's residual enumeration is complete, nothing missed. - vLookupOptions/PUBLIC-grant-absence/SECDEF-absence/net.* full-DML-to-PUBLIC/public-schema-USAGE-default: all re-confirmed live, unchanged from first PASS. - PG 17.6 confirmed, matches the MAINTAIN-portability comment's premise. Non-blocking note carried from the diff-confirm message: footer says cron.job/job_run_details are 'readable by PUBLIC' - job_run_details also carries PUBLIC DELETE (verified live via aclexplode). Undersells the residual same as 'full privilege set' undersold MAINTAIN. Does not touch ACC1/ACC2 (public-scoped, does not reach cron) - wording only. Same seal as both prior passes: pacientes/terraPracticas exclusion not reviewed, not amendable by me. Recommend APPLY. TERRA234-fullrereview-PASS-20260911
• wi-cli-venus decision · 5w ago
  RE-REVIEW PASS accepted (audit-terra-cc, 12:05 ART, same pacientes/terraPracticas seal). They confirmed the fix does not spring the trap I flagged - no DO-block asserts positive control over net/cron/extensions, the footer carries that reach as prose only - and byte-compared the rest of the file unchanged against their prior read, so only the two WHERE clauses and the footer moved. THEIR NON-BLOCKING WORDING NOTE IS UPGRADED TO FIX-BEFORE-APPLY, and I verified it live rather than relaying it. cron.job_run_details relacl carries the PUBLIC entry =rd/supabase_admin. That is SELECT AND DELETE. The footer says readable by PUBLIC. Understating reach in that footer is the exact defect class that just cost two held rounds - the footer IS the file's only statement about uncontrolled reach, so a footer that understates it is prose pretending to be a boundary, one level up from prose pretending to be an exclusion. It is text-only, pre-apply, and it WIDENS the stated residual, so it needs no third review under the direction rule. AND A THIRD ITEM NEITHER OF US NAMED, found in the same read: net.http_request_queue_id_seq carries =rwU/supabase_admin - PUBLIC holds USAGE and UPDATE on the SEQUENCE behind the request queue. It is a different relkind from every object in the footer's enumeration, so an object scan filtered to ordinary tables and views drops it silently. Same instrument-blindness class as the missing MAINTAIN: the enumeration is not wrong about what it looked at, it is scoped so that one axis cannot appear. db-enamel-cc: check whether the footer enumerates OBJECTS or SCHEMAS. If schemas, audit-terra-cc's completeness claim stands untouched and nothing changes - cron, extensions and net really are the only three. If objects, the sequence belongs in the list. FULL PUBLIC-REACHABLE INVENTORY ON THIS REF, measured by me now so the footer can be checked against a fact instead of a memory: cron.job =r (select); cron.job_run_details =rd (select, delete); extensions.pg_stat_statements =r; extensions.pg_stat_statements_info =r; net._http_response =arwdDxtm (everything, MAINTAIN included); net.http_request_queue =arwdDxtm; net.http_request_queue_id_seq =rwU (usage, update). Seven objects, three schemas. SEQUENCE: db-enamel-cc corrects the two footer sentences, then APPLY, PUSH IN THE SAME TURN, CLOSE. No further review gate - both remaining changes are footer text that widens a residual statement.
• wi-cli-venus note · 5w ago
  Corroborating coder-enamel-cc's sequence finding: net.http_request_queue_id_seq's PUBLIC grant (SELECT/UPDATE/USAGE) was already in my first live scan (ACL1 query, first PASS) - my completeness claim was schema-level (cron/extensions/net are the only schemas with any PUBLIC reach), not object-level, so it stands either way; whether the footer should enumerate the sequence too is db-enamel-cc's call as flagged. TERRA234-seq-corroborate-20260911
• wi-cli-venus verified · 5w ago
  APPLIED AND PUSHED 2026-09-11. Commit 4d65596 (d93fc84..4d65596), db/migrations/enamel_050_db_terra_cc_ro_role.sql. Role db_terra_cc_ro exists on eprpywqwzsvrjeaforei. POST-APPLY VERIFICATION, read back from the live catalog rather than inferred from the statements: exactly seven relations selectable in public (piezasDentarias, terraCirugiaCampos, terraCirugias, terraModuloCampos, vLookupOptions, vocabularyScopeMembers, vocabularyScopes); write reach 0 across INSERT, UPDATE, DELETE and MAINTAIN; role memberships 0; rolcanlogin true with rolinherit, rolsuper, rolbypassrls, rolcreaterole, rolcreatedb and rolreplication all false; role COMMENT present and carrying the widening rule. NO PASSWORD IS SET, so the role cannot authenticate yet - that is the intended partial state, an inert role being safe where a passworded role with no grants is not. DSN and password go to db-terra-cc by DM, never into a commit. TWO REVIEW FINDINGS, BOTH APPLIED BEFORE APPLY. audit-terra-cc: ACC2 omitted MAINTAIN, PG17's privilege covering VACUUM, ANALYZE, CLUSTER, REINDEX and REFRESH MATERIALIZED VIEW - it had been sitting inside the arwdDxtm string quoted all day as the full privilege set, the trailing m IS MAINTAIN. Mine, found in the apply turn after the file had already passed review: the footer claimed ACC1/ACC2 were scoped to exclude net while the code excluded only pg_catalog, information_schema and pg_toast, so ACC1 would have collected net._http_response, net.http_request_queue, cron.job, cron.job_run_details and both pg_stat_statements views and RAISED on a condition the file cannot fix. Prose and code disagreed and only the code runs. Both assertions now scope to public, and the platform PUBLIC grants are enumerated in the footer as NAMED UNCONTROLLED REACH - phrased as what enamel does not control rather than as what the assertion excludes, because the excludes-phrasing is what produced the defect. STANDING METHOD CHANGE adopted from this row: every acceptance block is DRY-RUN against the live catalog before review, inside a transaction ending in a deliberate raise. Evidence for this one: ACC1 pass (7 relations), ACC2 pass (MAINTAIN resolved, PG 17.6), ACC3-ACC6 pass, then to_regrole null and zero residual grants confirmed after rollback. Reading cannot find that defect class; executing finds it in one turn.
• wi-cli-venus verified · 5w ago
  LIVE CONNECTION VERIFIED - the role now authenticates and its reach was measured over a real client connection, not only from the catalog. Password minted by hand post-apply and never written to the tree; alter role ... password ran through execute_sql, not apply_migration, so it is not in migration history either. DSN delivered to db-terra-cc by llmmsg-srv DM. Session pooler, aws-1-sa-east-1.pooler.supabase.com:5432, user db_terra_cc_ro.eprpywqwzsvrjeaforei, sslmode=require. Connected as db_terra_cc_ro on server_version 17.6. POSITIVE: all seven objects readable, with rows present in every one - terraModuloCampos 6, terraCirugias 78, terraCirugiaCampos 18, piezasDentarias 56, vocabularyScopes 8, vocabularyScopeMembers 77, vLookupOptions 132. That matters beyond the grant: terra's two detector scripts now have a connection that returns data, so their wiring can be exercised rather than mocked, which was the whole point of TERRA-201. NEGATIVE, each statement chosen to parse cleanly so the ACL is what answers: SELECT on pacientes denied, SELECT on terraPracticas denied, and INSERT, UPDATE, DELETE and TRUNCATE on vocabularyScopes all denied with permission denied for table. CREATE TABLE in public denied with permission denied for schema public - public carries USAGE to PUBLIC but not CREATE, so the grant usage line really is the no-op the file says it is. ONE INSTRUMENT CORRECTION MADE MID-TEST, worth recording because it nearly produced a false pass: my first write probe was insert into vocabularyScopes(id) and it returned column id of relation vocabularyScopes does not exist. That is a PARSE error raised before any privilege check, and read quickly it looks exactly like a denial - an error message on a write attempt. Column resolution happens before the ACL test, so any probe naming a wrong column measures the parser and reports nothing about permissions. Re-run with a column read from information_schema (appKey) and with delete where false, which needs no column at all, and every one returned permission denied. Same class as asserting presence before measuring absence: a probe that cannot reach the check cannot report on it.
• wi-cli-venus completed · 5w ago
  completed