terra
TERRA-133
The audit lane holds no database connection, so every DDL PASS it issues is an evidence review of output supplied by the lane being audited - verdicts now state that, the missing capability is unresolved
Done normal
ataudit-terra-cc
STATED BY THE AUDIT LANE ITSELF, twice in one morning, unprompted: audit-terra-ca has NO DB CONNECTION configured in its checkout. TERRA_DSN, DATABASE_URL_SESSION and DATABASE_URL are all unset. It cannot execute a query against the database it is asked to gate. WHAT THAT MEANS FOR EVERY DDL PASS IT WILL EVER ISSUE. It can review SQL as text, and it does that well - terra_48's source PASS correctly characterised a bounded convergent ACL sweep, and its FAIL/BLOCK on provenance found something three other lanes had walked past. What it cannot do is verify that the database is in the state anyone claims. On terra_48 it issued an EVIDENCE-REVIEW pass over db02-terra-cc's supplied output and said so explicitly, refusing to let it be restated as direct audit execution. That refusal is the correct behaviour and it is also the whole problem: the gate's factual half is delegated, every time, to the lanes it is gating. THIS IS NOT A COMPLAINT ABOUT terra_48, WHICH ENDED CORRECT. It is that the arrangement produces a PASS whose strength depends on who supplied the evidence, and nothing in the verdict's NAME carries that. A reader six months out sees "audit PASS" on a migration and reasonably concludes the auditor looked. THE SHAPE IS ALREADY IN OUR CORPUS under a different name: a check that reads a different thing than it appears to. Here the check reads a TRANSCRIPT and appears to read a DATABASE. WHAT TO DECIDE, and it is not obviously "give audit a DSN". A read-only credential for the audit lane is the direct fix and it widens the number of lanes holding database access, which is a real cost on a shared production database - the fleet rule is that no agent queries a DB it does not own maintenance for. The alternative is to keep the delegation and make it VISIBLE: every audit verdict that rests on supplied evidence names the supplying lane in the verdict line, and no migration file may record "audit PASS" without that qualifier. That costs nothing and fixes the misreading rather than the capability. DO NOT RESOLVE THIS INSIDE A MIGRATION OR A COMMIT MESSAGE. It is a standing arrangement affecting every future DDL gate, and it needs Elazar's call on the credential question. Route it, do not settle it. RELATED AND SEPARATE: whether a peer lane's review can substitute for the audit gate at all. terra_48 went live on db02-terra-cc's peer review with no audit PASS routed, which is recorded on TERRA-123. That is about WHO reviews; this row is about what the reviewer can SEE.
Activity
-
The zero-cost half is SHIPPED as a standing terra-lane rule in shared/md/terra-commons.md, commit 44439f5. The credential half stays open and stays Elazar's, exactly as this row directs. New evidence, and it is the reason to write the rule rather than keep relying on good behaviour. On 2026-08-31 audit-terra-ca issued three verdicts and DID state its coverage precisely - what it read, what it ran, and that it exercised no authenticated browser, no live database, no Vercel and no direct server-action call. That is the behaviour this row asks for. It happened because I asked for it IN THAT ONE DISPATCH. So the compensating control was a sentence in one requester's phrasing. That disappears the moment somebody else dispatches the audit, or the moment I dispatch one in a hurry, and its absence is INDISTINGUISHABLE FROM FULL COVERAGE - an unqualified PASS reads stronger than a qualified one, so the failure direction is the reassuring one. A well-scoped verdict is not evidence the lane will scope the next one. That is the whole argument for a rule and it did not exist when this row was filed. The rule as written: every terra audit verdict names its coverage in the verdict itself - what was read, what was executed, and what was NOT exercised - and a verdict resting on evidence somebody else supplied names the supplying lane. WHAT IS DELIBERATELY NOT DONE. The rule is in terra-commons, not in shared/md/evolutiva-audit-commons.md, which is FLEET-WIDE and reaches the pluto, mars and venus audit lanes. The same blind spot plausibly exists in those lanes and I have not measured it, so I am not editing their commons on terra's evidence. A fix reaches the file, not its siblings - and the fleet-wide version is a change other PMs have to agree to. STILL OPEN AND STILL ROUTED: whether audit-terra-ca gets a read-only DSN. That widens the number of lanes holding access to a shared production database, against a standing fleet rule that no agent queries a DB it does not own maintenance for. Elazar's call, and this row stays open until he makes it. Do not close this on the rule alone: the rule fixes the MISREADING, not the capability, and the row was filed about both.
-
The half of this row that a terra agent can close is closed; the half that remains is a credential decision that is not mine to make, so this is blocked rather than in progress. DONE: every terra audit verdict must now name its own coverage - what was read, what was executed, what was NOT exercised, and the supplying lane where the verdict rests on evidence somebody else produced. Standing terra-lane rule in shared/md/terra-commons.md, commit 44439f5, and audit-terra-ca has read and adopted it. That fixes the MISREADING: an unqualified PASS from a lane holding no database connection will no longer be issued unqualified. BLOCKED ON: whether audit-terra-ca gets a read-only DSN. That is Elazar's, it widens the number of lanes holding access to a shared production database, and it runs against the standing fleet rule that no agent queries a database it does not own maintenance for. Nothing in terra can decide it and no further terra work advances it. Do not close this on the rule alone. The rule fixes how the verdict READS; it does not give the audit lane the capability, and this row was filed about both.
-
The audit lane holds no database connection, so every DDL PASS it issues is an evidence review of output supplied by the lane being audited - verdicts now state that, the missing capability is unresolved
-
SECOND CAPABILITY BOUND ON THE SAME LANE, measured 2026-09-01 00:05, and it is operational rather than architectural. audit-terra-ca is Ready and idle at 14 PERCENT CONTEXT LEFT, down from 23 percent earlier tonight after one narrow source-only audit of four files. Weekly quota 74 percent, so this is context exhaustion, not a rate limit. CONSEQUENCE, which is the part worth recording here rather than in a session note: the standing rule is that an audit PASS gates DDL. With the lane at 14 percent it cannot deliver a PASS that means anything - an audit that runs out of context mid-read returns a verdict over a fraction of the corpus and reads exactly like a verdict over all of it. So DDL gating is currently unavailable, and that is a DIFFERENT unavailability from the one this row is about: this row says the lane cannot READ THE DATABASE, and now the lane also cannot READ MUCH AT ALL. Two independent bounds on one verdict. I DID NOT RESTART IT. Relaunching a session is outside what I may do unilaterally; a restart would reset the window and is the obvious remedy, but it is Elazar or the launch policy that authorises it, not me noticing that it would help. Recording rather than acting is the whole point. WHAT I DID INSTEAD: assigned no further audit work this cycle and said so, rather than issuing a request the lane would answer badly. An auditor that accepts a job it cannot finish still returns a document.
-
LA BRECHA TIENE UN REMEDIO CONCRETO Y BARATO, Y HASTA HOY NADIE LA HABIA MEDIDO COMO UNA DIFERENCIA DE CONFIGURACION EN VEZ DE UNA PROPIEDAD DEL LANE. Lo que este row dice es que el lane de auditoria no tiene conexion a la base, asi que todo PASS que emite sobre DDL es una revision de evidencia PRODUCIDA POR EL LANE AUDITADO. Eso sigue siendo cierto. Lo nuevo es de donde sale exactamente la asimetria, medido hoy y no supuesto. MEDIDO. agents/audit-terra/.mcp.json declara UN solo servidor MCP: llmmsg-srv. Nada mas. agents/db-terra/.mcp.json declara dos, y el segundo es un servidor Supabase de tipo http cuyo endpoint lleva el token en la URL. O sea que la incapacidad del auditor no es una politica escrita en ningun lado ni una restriccion del rol: es un archivo de configuracion al que nunca se le agrego una entrada. Nadie decidio que el auditor no viera la base; simplemente nunca se le puso. Y HOY QUEDO PROBADO QUE EL OTRO LADO SI PUEDE, lo cual convierte la asimetria en algo verificado en vez de inferido. Persiguiendo el transcripto de TERRA-136 le pregunte a db-terra-ca directamente si podia ejecutar SQL, porque tres ciclos con el contexto plano en 36% sugerian que no. La respuesta fue que si, con prueba de esta misma sesion: ejecuto el CREATE TABLE y el CREATE FUNCTION del borrador de terra_52 dentro de un BEGIN..ROLLBACK y despues una fixture sintetica a traves de la funcion, con resultado active=1 y rollback. Conexion transaccional, ni de solo lectura ni limitada a una sentencia. El lane auditado tiene DDL transaccional; el auditor no tiene ni un SELECT. EL REMEDIO, y es una linea: agregarle a agents/audit-terra/.mcp.json una entrada de servidor Supabase igual a la de db-terra pero de SOLO LECTURA. El MCP de Supabase acepta el modo de solo lectura en la propia URL, asi que no hace falta credencial nueva ni rol nuevo en la base - la misma forma, con el flag puesto. Con eso el auditor puede leer pg_proc, pg_trigger, pg_parameter_acl y las tablas del catalogo por su cuenta, y un PASS sobre DDL pasa de ser una lectura de lo que le mandaron a ser una medicion propia. LO QUE EL REMEDIO NO ARREGLA, y conviene dejarlo escrito para que nadie cierre este row de mas: solo lectura no permite reproducir un dry run. El auditor podria verificar el ESTADO resultante y el catalogo, no re-ejecutar las arms de una transaccion revertida, porque eso necesita escribir y revertir. Asi que la evidencia de dry-run sigue viniendo del lane auditado; lo que cambia es que todo lo que es estado observable deja de depender de su palabra. NO LO APLIQUE. Es la configuracion de otro agente y sus credenciales, y audit-terra-ca esta hoy con 14% de contexto, asi que ni siquiera podria absorber el cambio y verificarlo en esta sesion. Queda como remedio nombrado y medido, listo para aplicar cuando ese lane arranque fresco, y esa es exactamente la condicion de desbloqueo que este row no tenia.
-
Desbloqueo nombrado y medido (2026-09-01): agregar a agents/audit-terra/.mcp.json una entrada de servidor Supabase igual a la de agents/db-terra pero en modo solo lectura. Medido: audit-terra declara UN solo MCP (llmmsg-srv) y db-terra declara dos, siendo el segundo un servidor Supabase http con el token en la URL - la incapacidad del auditor es una entrada que nunca se agrego, no una politica. No aplicado: es configuracion y credencial de otro agente, y audit-terra-ca esta en 14% de contexto. Aplicar cuando ese lane arranque fresco. No cierra el row del todo: solo lectura verifica estado y catalogo, no reproduce un dry run, asi que la evidencia de transaccion revertida sigue viniendo del lane auditado.
-
MEDICION NUEVA QUE ENDURECE EL DIAGNOSTICO: NO ES QUE LOS LANES DE VERIFICACION NO TENGAN BASE. DOS DE TRES LA TIENEN, Y EL AUDITOR ES EL UNICO SIN ELLA. Ya estaba medido que agents/audit-terra/.mcp.json declara un solo servidor, llmmsg-srv, mientras agents/db-terra/.mcp.json declara ademas un servidor Supabase de tipo http. Contra eso quedaba abierta una lectura benigna: que el lane con base es el que EJECUTA DDL y el que no la tiene es el que VERIFICA, y que la asimetria seguia alguna logica de separacion de funciones. Esa lectura no sobrevive. Lei hoy agents/db02-terra/.mcp.json y declara el MISMO servidor Supabase http contra el mismo project_ref eprpywqwzsvrjeaforei, con features docs, database, debugging, development, functions y storage. db02-terra-cc NO es un lane de aplicacion: es explicitamente de solo medicion y dry-run, cada accion suya va por execute_sql dentro de un BEGIN..ROLLBACK y apply_migration no es suyo nunca. O sea que un lane de verificacion sin autoridad de escritura YA TIENE la conexion que a este row le falta, y la tiene sin que eso lo convierta en aplicador. CONCLUSION: la incapacidad del auditor no separa funciones ni refleja ninguna politica. Es una entrada de configuracion que a un archivo se le puso y a otro no. Tres lanes tocan esta base conceptualmente y dos tienen la entrada; el tercero es justamente el que emite los PASS. EL REMEDIO NO CAMBIA Y AHORA TIENE UNA PLANTILLA EXACTA EN VEZ DE UNA DESCRIPCION: copiar a agents/audit-terra/.mcp.json la entrada supabase que ya esta en agents/db02-terra/.mcp.json, con el modo de solo lectura puesto en la URL. Misma forma, mismo project_ref, sin credencial nueva ni rol nuevo en la base. LO QUE SIGUE SIN ARREGLAR, y conviene dejarlo escrito para que nadie cierre este row de mas: solo lectura permite verificar ESTADO - pg_proc, pg_trigger, pg_parameter_acl, el catalogo - pero no re-ejecutar las arms de una transaccion revertida, porque eso necesita escribir y revertir. La evidencia de dry-run sigue viniendo de otro lane. Lo que cambia es que todo lo observable deja de depender de la palabra del auditado. SIGO SIN APLICARLO. Es la configuracion y las credenciales de otro agente, y audit-terra-ca esta al 14% de contexto, asi que ni siquiera podria absorber el cambio y verificarlo hoy. La condicion de desbloqueo es que ese lane arranque fresco.
-
Mandada a eq 76, topico terra-acceso-de-la-lane-de-auditoria, presentando las dos salidas que la propia fila enuncia: A, credencial de solo lectura para la lane de auditoria, que arregla la capacidad y amplia el numero de agentes con acceso a la base compartida de produccion, contra la regla de flota de que ningun agente consulta una base cuyo mantenimiento no le pertenece; o B, dejar la delegacion y hacerla visible, nombrando en la propia linea del veredicto a la lane que suministro la evidencia. ADOPTE B COMO INTERINO SIN ESPERAR LA RESPUESTA y lo dije en la eq, porque no cuesta nada y no condiciona el fallo: si sale A, B sigue siendo util; si sale B, ya esta andando. La razon de no esperar es que el costo de la espera no es cero - cada veredicto que se emita mientras tanto queda con el mismo defecto de lectura que la fila describe. Ya lo aplique en esta misma vuelta: el evento de verificacion de TERRA-131 nombra que db02-terra-cc suministro la corrida y que el residuo lo volvi a medir yo por otro transporte, y el de TERRA-98 nombra que la lane declaro que su propia consulta esta contada dentro de las 2796. Lo que sigue sin resolverse, y por eso la fila no se cierra con el interino, es la capacidad: B arregla como se LEE un veredicto, no lo que el auditor PUEDE VER.
-
Esperando eq 76: el fallo sobre la credencial de solo lectura. El interino B ya esta adoptado y en uso, asi que la espera no bloquea la emision de veredictos, solo la resolucion de la capacidad.
-
eq 77 filada bajo el mismo topico que la 76, asi que cualquiera de las dos que Elazar conteste resuelve las dos. LO QUE AGREGA: la 76 argumentaba un principio y ahora hay un caso medido, ocurrido hoy entre 03:20 y 03:35 en TERRA-178. La lane de auditoria censo siete estados de panel vacio, correctamente y con su limite declarado por iniciativa propia. La remediacion que ese censo señalaba se habria construido MAL, por dos hechos que solo existen en las filas: una categoria que abarca dos campos en modulos distintos con reglas de aplicabilidad opuestas, y tres de seis campos con alcance cero, que en este esquema es ABIERTO POR DEFECTO y no cerrado. EL RIESGO QUEDO MEJOR DESCRIPTO QUE EN LA FILA ORIGINAL: no es que la lane apruebe algo malo - eso lo maneja bien, declara su limite cada vez. Es que un analisis CORRECTO orienta la decision al lugar equivocado y nada avisa, porque el limite declarado puede decir 'no verifique la poblacion' y no puede decir 'la poblacion contradice la lectura natural de esto'. ESO CAMBIA EL PESO DE LAS DOS OPCIONES: la opcion B, hacer visible quien suministro la evidencia, arregla la mala lectura del veredicto y NO arregla esto. Sigo con B andando como interino porque no cuesta nada, pero ahora esta escrito que B no cubre esta clase. Lo agarre porque consulte la base yo; si no lo hubiera hecho, se construia mal y la suite pasaba en verde.
-
HALLAZGO LATERAL DE UNA PASADA SOBRE ESTA FILA, y va a fila propia: TERRA-197. audit-terra-ca fue a medir si le falta acceso y encontro de paso que a otras lanes les sobra. Confirmado por mi leyendo los .mcp.json: db-terra, db02-terra y CODER-terra tienen la misma entrada MCP de Supabase contra produccion, con features database/development/functions/storage y sin ninguna restriccion de solo lectura. audit nombro dos; la tercera - coder-terra, que no es carril de base - se le paso y es la que importa. audit-terra y coder02-terra tienen solo llmmsg-srv. O sea que el reparto no sigue ninguna linea: la lane de auditoria no tiene nada y la de codigo tiene todo. ESTO NO CONTESTA ESTA FILA NI LA CIERRA - la pregunta de si audit necesita credencial sigue viva y sigue siendo de Elazar, eq 76/77 - pero cambia el marco con el que se contesta: la opcion A ya no es 'ampliar el numero de agentes con acceso', porque el acceso ya esta ampliado y en una lane que no lo pidio. Lo que TERRA-197 pide decidir es lo contrario, que la capacidad coincida con el mandato. Sobre la parte que SI contesta esta fila: no existe ninguna entrada de solo lectura para audit-terra-ca, y las que existen no son demostrablemente de solo lectura. Eso es un BLOCK, no un pass.
-
EL REMEDIO DE ESTA FILA Y EL DE TERRA-197 SON EL MISMO PARAMETRO, y hasta hoy nadie lo habia notado porque las dos filas parecen opuestas. 2026-09-01 08:32. ESTA FILA DICE que la lane de auditoria no tiene conexion a la base, asi que todo PASS que emite sobre DDL es una revision de evidencia PRODUCIDA POR LA LANE QUE ESTA AUDITANDO. TERRA-197 dice lo contrario para otras lanes: tres carriles tienen MCP de Supabase con ESCRITURA contra produccion, incluido el carril de codigo de la app. Se leen como quejas opuestas - a uno le falta, a otros les sobra - y por eso las trate como dos problemas. SON EL MISMO PROBLEMA: la capacidad no sigue al mandato en ninguna direccion. Y desde hoy tienen el mismo instrumento, que medi contra la documentacion del proveedor y no deduje: el MCP hosteado de Supabase acepta read_only=true en la URL, con el efecto documentado de correr todas las consultas como usuario de Postgres de solo lectura. LO QUE ESO LE DA A ESTA FILA: la lane de auditoria puede tener conexion PROPIA sin poder escribir. Eso es exactamente lo que le falta - hoy no puede verificar un objeto de la base por si misma, tiene que creerle al transcript que le pasa la lane auditada, y un transcript es una afirmacion sobre una corrida, no la corrida. Con read_only=true podria mirar pg_proc, pg_trigger e information_schema directo y firmar un PASS sobre lo que VIO en vez de sobre lo que le contaron. DOS FRASES, PORQUE LA CORTA ES FALSA. La exacta: con read_only=true una escritura FALLA EN LA BASE porque el usuario no tiene permiso. La falsa, que es la que sobrevive al resumen: "las herramientas de escribir desaparecen". La documentacion NO dice eso; siguen cargadas y rebotan contra el permiso. Para esta fila la diferencia es menor - lo que importa es que no pueda escribir - pero la escribo igual porque es la frase que se va a citar sola. LO QUE NO CAMBIA: yo no toco ningun .mcp.json, es configuracion de agente, y la decision es de Elazar. Esta anotada en la eq 81 junto con la de TERRA-197, ahora como una sola eleccion por carril en vez de dos preguntas sueltas: sacar la entrada donde sobra, agregarla con read_only=true donde falta. Y LO QUE SIGUE SIENDO CIERTO MIENTRAS TANTO, sin importar la decision: los PASS que la lane de auditoria emitio hasta hoy sobre DDL siguen siendo revisiones de evidencia ajena. Un cambio de configuracion de aca en adelante no los convierte retroactivamente en verificaciones. Los veredictos ya dicen eso y tienen que seguir diciendolo.
-
coder02-terra-ca
-
coder02-terra-cc
-
audit-terra-cc
-
Role live-verified 2026-09-11: connected as audit_terra_cc_ro via session pooler, has_table_privilege('users','SELECT')=false, has_table_privilege("terraPracticas",'SELECT')=true - matches db-enamel-cc's granted/excluded sets. Credential in ~/.config/postgres/audit-terra-cc.env only. audit-terra-cc now has its own read-only DB connection; closes the row's DB-access gap. pg_net caveat (ENAMEL-35, EXECUTE to PUBLIC) noted - not an isolation boundary, table grants stand regardless.
-
cleared: Desbloqueo nombrado y medido (2026-09-01): agregar a agents/audit-terra/.mcp.json una entrada de servidor Supabase igual a la de agents/db-terra pero en modo solo lectura. Medido: audit-terra declara UN solo MCP (llmmsg-srv) y db-terra declara dos, siendo el segundo un servidor Supabase http con el token en la URL - la incapacidad del auditor es una entrada que nunca se agrego, no una politica. No aplicado: es configuracion y credencial de otro agente, y audit-terra-ca esta en 14% de contexto. Aplicar cuando ese lane arranque fresco. No cierra el row del todo: solo lectura verifica estado y catalogo, no reproduce un dry run, asi que la evidencia de transaccion revertida sigue viniendo del lane auditado.
-
completed
task
6w ago by wi-cli-venus
5w ago
2026-09-11 12:50