M5 · La metadata desde Index — approach

⚠️ 0 · Lo primero, porque cambia la naturaleza del milestone

M5 estaba escrito como higiene: «ninguna llamada al motor por metadata» + «el filtrado por privilegios tiene test». Medido, una de las tres cosas que da por supuestas es falsa y otra es una indisponibilidad viva.

0.1 · La indisponibilidad, con su número

buildInfoSchemaRows enriquece la relación llamando a duckColumns → /columns → DuckEngine.columns_for. Y columns_for hace un SELECT * FROM <tabla> LIMIT 0 por tabla —el catálogo Iceberg REST es lazy, no aparece en information_schema hasta que se la toca— sobre _run_locked, que es el mismo threading.Lock que serializa todas las queries del servicio (duck.py:762, call-sites :1054, :1061, :1146).

Medido contra el duck-server de producción (scripts/duckdb/m5-columns-cost.ts):

lote    1 tablas →   1.298 ms ·   9 columnas
lote    5 tablas →   2.858 ms ·  41 columnas      (≈ 572 ms/tabla)
lote   20 tablas →  11.858 ms · 148 columnas      (≈ 593 ms/tabla)
lote   92 tablas →  65.656 ms · 830 columnas      (≈ 713 ms/tabla)

Lineal, ~700 ms por tabla, sin tope de tablas por debajo de MAX_TABLES = 200. Y el lock de espera de los demás es de 20 s (lock_timeout_s), mientras el timeout de query es de 120 s — o sea, la llamada de 65 s no se corta, y todo el que llegue detrás recibe engine_busy tras esperar sus 20 s.

Y lo que compra ese minuto, Databricks lo publica como NULL. Los tres campos que justifican el enriquecimiento:

Ni un solo dato de los 65 s es irreducible. character_maximum_length no lo rellena ni Databricks; numeric_precision/scale son una función pura del tipo. Lo único que Index no sabe hoy es la precisión de sus 51 columnas DECIMAL(38,9) — y eso lo sabe el catálogo (§2.4), no hace falta el motor.

0.2 · Consecuencia sobre el orden

M5 deja de ser el milestone «de limpieza» del final. La fase que corta el motor del plano de metadata cierra una indisponibilidad medida y no depende de ninguna decisión de producto — va primera y se puede desplegar sola.

1 · Lo que hace Unity Catalog — y las cinco lecciones transferibles

Medido en documentación oficial el 2026-08-01. Index se parece a Unity Catalog por construcción (warehouse-index.md §1), así que aquí el cotejo no es inspiración: es leer el manual del sistema que ya elegimos imitar.

Las cinco lecciones, y qué implican aquí

1. La visibilidad es una cadena por nivel, no un booleano. Un objeto es visible si lo son su catálogo, su esquema y él. Hoy nuestra «cadena» tiene un solo eslabón: created_by = yo.
2. ⭐ Ver no es leer. BROWSE existe porque el descubrimiento tiene valor sin el dato — es lo que permite «veo que existe gold_finance y pido acceso». Nosotros no tenemos esa distinción, y es exactamente la que hace falta cuando el filtro pasa de dueño a workspace: al ver más objetos, hay que poder ver sin poder leer.
3. La metadata es un espejo, no un objeto concedible. Corolario duro y útil: el filtro de la relación debe DERIVARSE del mismo predicado que autoriza la lectura. Si son dos reglas distintas, tarde o temprano divergen — es la lección de M2 con los parsers y la de F4a con los dos catálogos, un piso más arriba.
4. Lo que cuesta y no aporta se publica como NULL, declarado. No es dejadez: es contrato. Databricks lo escribe en su doc y nosotros ya tenemos el sitio donde escribirlo (la superficie generada de F5).
5. El vocabulario de tipos es del catálogo, no del motor. Databricks publica STRING/BIGINT/TIMESTAMP en information_schema aunque por debajo haya Parquet con otros nombres. Nuestra deriva medida (§2.3) no es un bug de datos: es que no hemos decidido qué vocabulario publica Carbon SQL.

2 · Lo medido antes de diseñar

Tres scripts nuevos, todos de sólo lectura, contra la BD y el duck-server reales.

2.1 · La tenencia — el delta es CERO, y la ventana se cierra sola

scripts/dataspaces/m5-metadata-census.ts:

datasets totales        : 106
workspaces con datasets : 1          creadores distintos : 1
sin workspace_id        : 0          sin created_by      : 0

EL DELTA de `created_by` → `workspace_id`:   GANA 0 · PIERDE 0
roles en workspace_members: owner=3 · viewer=3 · admin=6

Lo que esto decide. M3 aplazó el cambio de sujeto con un motivo correcto —«cambia lo que la gente ve» (§7.3)—. Medido, hoy no cambia nada para nadie: hay un solo creador y un solo workspace con objetos. Es el momento más barato que va a existir, y cada creador nuevo lo encarece: el día que dos personas creen tablas en el mismo workspace, subir el filtro les cambia el árbol de golpe.

Y hay 12 miembros repartidos en otros workspaces (3 owner, 3 viewer, 6 admin) — o sea, la multi-tenencia existe en el producto; lo que no tiene todavía es datasets. El viewer es la prueba de que la lección nº2 hace falta: un rol que puede view pero no write ya está definido, y hoy el catálogo no lo distingue de un owner.

2.2 · El coste del motor — §0.1

2.3 · La deriva Index ↔ lago — de VOCABULARIO, no de estructura

scripts/duckdb/m5-column-drift.ts sobre 15 tablas:

tablas comparadas          : 15
tablas CON deriva          : 15 (100%)
columnas que Index no sabe : 0
columnas que Index inventa : 0
tipos que NO coinciden     : 50

traducciones observadas (Index → lago):
  STRING    → VARCHAR                      35
  TIMESTAMP → TIMESTAMP WITH TIME ZONE      9
  LONG      → BIGINT                        6

La buena noticia es la primera línea de los ceros: el conjunto de nombres de columna coincide al 100 %. La copia de Index no ha perdido ni inventado una sola columna, así que servir information_schema.columns desde Index no pierde estructura.

La mala es que hay tres vocabularios a la vez, y el censo lo enseña entero:

Index dice CHARACTER VARYING y TEXT para lo mismo que llama STRING; dice TIMESTAMP donde el lago tiene TIMESTAMP WITH TIME ZONE; dice NUMERIC/DECIMAL sin precisión donde el lago tiene DECIMAL(38,9). No es que la copia haya derivado: es que nunca hubo un vocabulario. Y —dato que ordena la decisión— el de Index está más cerca del de Databricks que el del motor: STRING, TIMESTAMP y DECIMAL ya son los nombres correctos; lo que hay que normalizar es LONG→BIGINT, CHARACTER VARYING/TEXT→STRING y la variante TIMESTAMP WITHOUT TIME ZONE.

Y dos huecos que ninguna consulta enseña hoy:

• 14 de 106 objetos (13 %) no tienen esquema en Index → hoy no salen en information_schema.columns, y nadie lo dice.
• La única vista tiene 0 columnas en Index → una vista nunca aparece en information_schema.columns. Databricks sí las lista. Es la cola schema-id que M4 mandó aquí, vista desde el otro lado.

2.4 · La tercera vía existe, y ya está construida

El plan planteaba dos fuentes para la metadata de columnas: el motor (hoy) o la copia de Index. Hay una tercera, que es la única que satisface el invariante de Index («lo que el catálogo sabe, se le pregunta — no se copia»), y ya tiene primitiva:

/lakehouse/table-status (N·2b, lakehouse.py:566) hace catalog.load_table() con pyiceberg y hoy devuelve columns = list(table.schema().column_names) — sólo los nombres. El objeto table.schema() que ya tiene en la mano lleva los tipos Iceberg completos, decimal(38,9) incluido. Es una llamada REST al catálogo, sin escanear datos y sin tocar el lock de DuckDB.

2.5 · ⚠️ Hay un TERCER camino a la misma metadata, y no filtra nada

La lección de Trino #14000 —«not all tables from system.metadata are access control aware»— que M3 citó para H·B, vuelve a aplicar, y esta vez fuera del SQL Editor:

app/api/datasets/route.ts:258   supabaseAdmin.from('datasets').select(…)
                                 ← sin .eq('workspace_id'), sin .eq('created_by')

El listado del árbol del Warehouse corre con supabaseAdmin (service-role, que salta RLS) y no aplica ningún filtro de tenencia. El guard de entrada es requirePermission('write'), que verifica el rol dentro del workspace propio y no acota la consulta. El parámetro ?scope= se lee (:86) y no se usa en ninguna parte.

Alcance real, dicho con precisión: hoy es latente, no explotable con consecuencias — hay un único workspace con datasets (§2.1), así que no hay dato ajeno que devolver. Pero es el mismo patrón que M3 cerró en el SQL Editor, en la superficie de al lado, y se activa solo el día que un segundo workspace cree su primera tabla.

✅ CERRADO el 2026-08-01 — y con dos correcciones a lo de arriba

El requisito se cumplió: visibility.ts exporta filtroDeTenencia(principal) (la forma EMPUJADA de puedeVer) y lo consumen los dos caminos — leerWarehouse y las tres ramas de lectura de app/api/datasets/route.ts (el listado, ?datasetId= y ?fileId=: acotar sólo el listado deja sin cubrir el camino que de verdad se enumera, porque el id lo elige el cliente). El ?scope= muerto, borrado. Regresión en app/api/datasets/route.test.ts (un segundo workspace construido a mano; verificada en la dirección de fallo: 4 de 8 sondas caen si se quita el predicado).

Dos cosas que este párrafo daba por ciertas y no lo eran, medidas antes de tocar nada:

1. El cliente no es service-role. La línea de import es supabaseRLS as supabaseAdmin — un alias con el nombre del cliente equivocado. Y RLS está activa en datasets (relrowsecurity = true, política datasets_workspace). Ningún caller de Clerk llegó a ver dato ajeno: el agujero era menos grave de lo escrito. Lección: un nombre importado bajo alias miente igual que un comentario rancio, y no lo caza el compilador.

2. Y aun así el arreglo NO era redundante, que es lo que se supondría de un filtro que duplica a RLS. La política concede workspace_id IN (user_workspace_ids()) = cualquiera de mis workspaces; la app quiere el activo. Un usuario con dos workspaces veía los dos mezclados en el listado. O sea: el fallo real no era el que estaba escrito, y sólo apareció al medirlo.

Sigue abierto, y es otro cambio: un caller con API key no tiene JWT de Clerk → supabaseRLS cae a la clave anónima → la política (TO authenticated) no le concede nada → lista vacía. Falla cerrado, así que no es un agujero, pero es un camino roto; el arreglo diseñado ya existe (dbForAuth(ctx)) y sólo es seguro porque el filtro de tenencia ya está puesto.

3 · El diseño

3.1 · La tesis

3.2 · Las cuatro piezas

        ┌──────────────────────────────────────────────────────────┐
        │ ① EL SUJETO — `Principal`, no `userId`                    │
        │   {userId, workspaceIds[], role} — lo que ya construye    │
        │   requireWorkspace(); deja de ser un string               │
        └───────────────────────┬──────────────────────────────────┘
                                ▼
        ┌──────────────────────────────────────────────────────────┐
        │ ② LA CADENA DE VISIBILIDAD — un predicado, UN sitio       │
        │   puedeVer(objeto, principal)  ← BROWSE                   │
        │   puedeLeer(objeto, principal) ← SELECT                   │
        │   exportadas: las consume `leerWarehouse` Y quien quiera  │
        └───────────────────────┬──────────────────────────────────┘
                                ▼
        ┌──────────────────────────────────────────────────────────┐
        │ ③ EL VOCABULARIO — `lib/warehouse/types.ts`               │
        │   tipo canónico Carbon (nombres Databricks) + precisión   │
        │   DERIVADA. Una función pura, con su tabla de traducción  │
        └───────────────────────┬──────────────────────────────────┘
                                ▼
        ┌──────────────────────────────────────────────────────────┐
        │ ④ LAS RELACIONES (F4a, ya existen) — filtradas DENTRO     │
        │   tables · views · schemata · columns                     │
        │   sin una sola llamada al motor                           │
        └──────────────────────────────────────────────────────────┘

① El sujeto. leerWarehouse(userId) pasa a leerWarehouse(principal). El Principal no se inventa: es lo que requireWorkspace() ya devuelve (userId, workspaceId, role). El cambio de firma es lo que impide que el filtro vuelva a ser un .eq() implícito.

② La cadena. Dos predicados exportados, no uno:

Que en v1 las dos reglas casi coincidan no las hace la misma: separarlas es lo que permite que los grants por catálogo/esquema/objeto entren después como una fila más, sin volver a tocar los seis comandos. Es la lección nº2, y es la diferencia entre M5 y un .eq() cambiado.

⚠️ Y hay una consecuencia inmediata, no teórica: el catálogo de resolución (catalogoDesde) se deriva de la misma lectura (F4a). Si leerWarehouse empieza a devolver lo que se puede ver, un objeto BROWSE-only entraría en el catálogo que resuelve FROM. La relación devuelve el objeto con su marca, y catalogoDesde filtra por puedeLeer. Sin eso, «ver» concede «leer» en silencio — que es justo el fallo que este milestone existe para impedir.

③ El vocabulario. Una función pura tipoCanonico(raw): {tipo, precision, escala}, con su tabla de traducción medida en §2.3 y su política declarada:

④ Las relaciones no cambian de forma: ya existen y ya derivan de una sola lectura. Ganan el filtro dentro y pierden el enriquecimiento.

3.3 · La regla que resuelve la cola de M4 — y una frontera que hay que escribir

M4 mandó aquí el schema-id de la vista con este motivo: «exige calcular el esquema de salida del cuerpo, que es preguntarle al motor». Eso choca de frente con el gate de M5 («ninguna llamada al motor por metadata»)… hasta que se le pone la frontera correcta:

No es una excepción de conveniencia: es lo que hace el Iceberg View Spec —el schema-id de una versión lo calcula el motor que la creó y viaja dentro de la versión inmutable— y es lo que separa un hecho derivado y sellado de una pregunta recurrente. Con esa frontera:

• el schema-id de la vista se calcula en CREATE VIEW (una vez, ya hay motor en el camino) y se guarda en la versión → cae la cola de M4 sin violar el gate;
• las 14 tablas sin esquema y la vista con 0 columnas dejan de ser invisibles;
• y el gate de M5 se enuncia con precisión: cero llamadas al motor en el camino de LECTURA de metadata (que es donde está el minuto de bloqueo).

4 · El contrato de visibilidad v1 — qué se declara

Se publica en la superficie generada (F5 de M3), con la misma regla: lo que no está, está escrito.

5 · Fases, con lo que cada una BORRA

N1 va primera y se despliega sola. Cierra la indisponibilidad de §0.1 y no depende de ninguna decisión de producto.

6 · Riesgos

7 · Decisiones del owner

1. ¿N1 se adelanta y se despliega sola? Recomendación: sí. Es una indisponibilidad medida, alcanzable por cualquier usuario autenticado, y su arreglo no toca producto ni permisos.
2. ⭐ ¿Qué vocabulario publica Carbon SQL en data_type? Recomendación: el canónico estilo Databricks (STRING/BIGINT/TIMESTAMP/DECIMAL(p,s)), normalizado desde lo que guarda Index. Es paridad, y es el que ya está más cerca. (La alternativa —publicar el tipo físico del lago— acopla el contrato al motor, que es justo lo que este pilar deshizo.)
3. ¿Se activa la elevación de DEFINER en M5? Recomendación: sí, y es el motivo de que puedeVer/puedeLeer sean dos. Con un solo predicado, una vista DEFINER es indistinguible de un agujero.
4. ¿row_count/size_bytes siguen saliendo de la copia de Index? Son extensiones nuestras a information_schema.tables (Databricks no las tiene). Derivarlas del catálogo son 92 llamadas REST. Recomendación: se quedan en Index en v1 y se declaran como «último valor conocido» en la superficie — es honesto y es gratis; derivarlas es del plan de retirada del andamio, no de Carbon SQL.
5. ¿N5 (F4b) entra en M5 o se vuelve a diferir? Recomendación: que entre, pero la última. Ya se difirió una vez «porque M5 reconstruye el contrato»; cuando N1–N4 estén, ese motivo se ha consumido y volver a diferirlo sería convertir «decisión» en «resto».

16 · N1 · lo entregado (2026-08-01)

El resultado, en tres números

① information_schema.columns  →  65.656 ms  ⇒  222 ms      (×296)
② columnas PERDIDAS                              0
③ tipos publicados que NO describen la tabla física   0 / 630

El gate (scripts/duckdb/m5-n1-gate.ts) cronometra la función de producción y contrasta su salida columna a columna contra el motor. Los 226 valores de precisión que antes venían de la red coinciden todos con los derivados.

⭐ Por qué esto no publica una copia: el mapeo ya existía

La pregunta que decidía N1 —¿puede Index decir la verdad sobre el tipo?— tenía una respuesta mejor que «sí, aproximadamente»: la traducción no hay que inventarla, porque es la misma función que escribió el tipo físico.

raw de Index ──resolveIcebergType──▶ token Iceberg ──ICEBERG_A_CARBON──▶ tipo Carbon
              (lib/types/iceberg-types.ts:                              (types.ts)
               lo que el worker aplicó ANTES
               de que ml-runner creara la tabla)

Publicar el resultado no es estimar: es reproducir una derivación que ya ocurrió. De ahí que el contraste dé 630/630 y no «casi todas». Y explica por qué la deriva medida en §2.3 era de vocabulario y no de estructura: los dos extremos siempre dijeron lo mismo con distintas palabras.

La precisión de los DECIMAL —el único dato que parecía exclusivo del motor— sale del mismo sitio: el writer manda todo decimal a decimal(38,9) (parquet_source.py:45, types.py:55). Publicar 38/9 describe la tabla real.

Las tres decisiones que se declaran en la superficie

1. data_type publica el vocabulario Carbon (nombres Databricks). Antes publicaba el tipo del sistema origen, que es un eco del adaptador: character varying, text y String eran tres nombres para la misma columna física.
2. character_maximum_length = NULL por contrato (Databricks: «Always NULL»).
3. numeric_scale de FLOAT/DOUBLE = NULL, regla de Databricks y de ANSI. DuckDB devuelve 0; son 11 columnas y la divergencia se publica, no se esconde.

Y una unificación que no estaba en el plan y había que hacer: DESCRIBE y SHOW COLUMNS publicaban el tipo crudo mientras la relación publicaba el canónico. Eran dos piezas que debían coincidir — el pecado de siempre — así que las tres pasan por nombreTipoCanonico.

⚠️ Corrección al plan: el endpoint /columns NO se borra

La fila de N1 decía «borra … el endpoint /columns y columns_for». Al ejecutarlo se vio el problema: §6 de este mismo documento promete un trinquete de deriva («si un día Index y el lago dejan de coincidir en nombres, salta»), y su única verdad de referencia posible es preguntarle al motor. Borrarlo dejaba la promesa sin instrumento.

Lo entregado en su lugar, que quita la indisponibilidad sin quitar la medida:

Es el mismo movimiento que F0 hizo con los reconocedores: lo que hay que medir no puede ser privado, pero tampoco tiene por qué estar en el camino caliente.

🔁 Y el gate falló antes de acertar — otra vez, y por lo mismo

La primera pasada dio tipo publicado ≠ tipo físico: 1 y señalaba bronze_customers.customer_id. La tentación era mirar el código de producción. El error era del instrumento: hay dos bronze_customers —main.test con 99.441 filas y main.default con 30, el hallazgo de M4— y el gate indexaba por nombre de tabla, así que comparaba las columnas de una contra el esquema de la otra. Con la coordenada en la clave: 630/630.

Van cuatro instrumentos seguidos en este pilar que fallan antes de acertar, y los cuatro se descubrieron mirando el caso concreto que señalaban, no razonando sobre el diseño.

Los gates

Pendiente: desplegar (Vercel para el corte en Node; Railway para el tope de duck-server, que es defensa en profundidad — el camino de producción ya no pasa por ahí).

Y una rancidez que se publicaba y ha caído de paso: la superficie generada declaraba «verbos de escritura: DELETE · MERGE — pendiente de RE-MEDIR (M6)». M6 cerró, y UPDATE entró por evidencia.

17 · N2 · lo entregado (2026-08-01)

⚠️ Lo que se encontró al abrir la route, y cambia el tamaño de N2

N2 estaba escrito como «subir el filtro de created_by a workspace». Al ir a hacerlo apareció que el filtro no era una frontera de tenencia: era un parámetro.

route.ts:132   const { userId, query, mode } = body;     ← el sujeto, del CUERPO
route.ts:*     grep de auth/clerk/requireWorkspace  →  0 resultados

La route no tenía ni una llamada de autenticación. Clerk (proxy.ts) garantiza que haya una sesión, pero la identidad con la que se construía el catálogo era la que el cliente escribiera. Y ese catálogo no gobierna sólo metadata —como H·A/H·B de M3—: gobierna la resolución de FROM, o sea el dato.

La cadena entera dependía de un valor del cliente:

body.userId → buildWarehouseCatalog(userId) → leerWarehouse → .eq('created_by', userId)
            → plan de lectura → binding → JWT de workspace → el motor lee

runQuery valida tenencia por tabla, pero lo que valida es que las tablas entre sí sean del mismo workspace — no que el que pregunta pertenezca a él, porque hasta N2 no había un «el que pregunta» que no viniera del body.

Y un segundo desajuste, que no es de seguridad sino de corrección: la unicidad de nombre se comprobaba en la app contra created_by (handlers.ts, dos sitios) mientras el índice de la BD es datasets_coordinate_unique sobre (workspace_id, schema_id, lower(name)). Tres ámbitos para la misma pregunta —dueño, workspace, coordenada— es la misma deuda que dos parsers, un piso más arriba.

Lo entregado

El gate

Lo que N2 NO hace, y hay que decirlo: el rol no se mira todavía. Un viewer y un owner del mismo workspace ven exactamente lo mismo — que es lo correcto para ver, y está por decidir para leer. Eso es N3 (puedeVer / puedeLeer), y el sitio donde se aplica ya está: una función.

Pendiente: la route no se ha podido ejercitar en vivo (hace falta una sesión Clerk real), así que el 403 de principal_mismatch y el camino de sesión están fijados por tipos y por tests, no medidos contra producción. Se verifica al desplegar.

18 · N3 · lo entregado (2026-08-01)

El riesgo que esta fase tenía que esquivar — y se midió antes de escribir nada

§6 lo dejó por escrito: «ver ≠ leer se queda en dos funciones que devuelven lo mismo», con la mitigación «el test exige un caso donde DIFIERAN; si no se puede construir, la separación no está hecha». Así que primero se contó (scripts/dataspaces/m5-n3-discriminadores.ts):

106 objetos
① sin coordenada física (iceberg_namespace NULL) : 14
② sin esquema en Index                            : 14   ← los MISMOS 14
③ estados presentes                               : active 106  (no discrimina)
④ vistas con ataduras rotas                       : 0
⑤ roles                                            : owner 3 · viewer 3 · admin 6
                                                     (los seis tienen `view`: no discrimina)

OBJETOS QUE SE VEN Y NO SE PUEDEN LEER : 14 / 106

El caso existe y no hay que inventarlo. Son objetos heredados del plano PG demolido: la fila de catálogo quedó, la tabla nunca se escribió. Y de los 14, uno es la única vista del sistema — que sí es legible, porque una vista no necesita coordenada física. Mirar sólo el namespace se la habría llevado por delante; es el error fácil de esta fase y tiene su sonda.

El «antes», medido en vivo

SELECT count(*) FROM "Transform path (1) (b60865d3)"
  → Table with name ds_b60865d3b627444cac941159503f668e does not exist!
    Did you mean "ds_51685d44068c4d06a761582b0c3ad53e"?

Dos cosas mal, y la segunda no es de UX: el mensaje es incomprensible (el usuario tecleó un nombre lógico) y filtra identidades físicas de otros objetos. El «después», verificado en vivo tras el cambio:

reason  = not-readable
mensaje = "Transform path (1) (b60865d3)" existe en tu Warehouse pero no tiene datos
          materializados — nunca llegó a escribirse una tabla para él.

La forma: el objeto se REGISTRA marcado, no se esconde

La tentación era filtrar los no legibles fuera del catálogo. Se descartó: eso produce «ese nombre no existe», que es falso y además peor mensaje. La cadena queda así:

Y el motivo se propaga desde dentro del cuerpo de una vista: una vista sobre una tabla sin materializar no es «una vista rota», y decirlo mandaría al usuario a arreglar lo que no es.

⚠️ La elevación de DEFINER NO se activa — y ahora con el motivo medido

La fila de N3 prometía activarla (venía de M4, que la aplazó «a M5, donde hay privilegios de verdad»). Al llegar aquí, la respuesta honesta es que no hay ningún caso al que aplicarla:

• elevar = leer a través de la vista algo que no puedes leer directamente;
• tras N2, la visibilidad es el workspace ⇒ ese caso sólo se da si la atadura apunta a otro workspace, y eso no es un privilegio que elevar: es tenencia, y debe seguir fallando;
• lo único que niega una lectura dentro del workspace es N3 (no materializado), y ninguna elevación conjura datos que no existen.

Así que la elevación no queda inerte por falta de trabajo, sino porque no hay a quién elevar mientras no existan grants por objeto. Queda escrito en el sitio del código donde se notaría (duck-plan.ts, la rama de la atadura). Fingirla habría sido abrir un agujero para nadie — que es exactamente lo que M4 se negó a hacer, y sigue valiendo.

Los gates

Lo que N3 no hace: el rol sigue sin mirarse, porque medido, no discrimina — los seis tienen view. Restringir la lectura por rol es una decisión de producto, no una deuda técnica, y entra por puedeLeer el día que se tome.

19 · N4 · lo entregado (2026-08-01)

El hueco era UNA fila — y lo confirmó el censo antes de tocar nada

tablas LEGIBLES      : 92  ·  sin columnas:  0
tablas NO legibles   : 13  ·  sin columnas: 13   ← correcto: sin tabla no hay columnas (N3)
VISTAS               :  1  ·  sin columnas:  1   ← el hueco entero

Así que N4 no era «rellenar metadata»: era el schema-id de la vista, la cola que M4 mandó aquí con su motivo escrito («exige calcular el esquema de salida del cuerpo, que es preguntarle al motor»).

La frontera que lo desbloquea sin romper el gate de M5

No es una excepción de conveniencia: es lo que hace el Iceberg View Spec, donde el schema-id lo calcula el motor que creó la versión y viaja dentro de la versión inmutable. Un hecho derivado y sellado no es una pregunta recurrente — y el gate de M5 es sobre el camino de lectura, que es donde estaba el minuto de bloqueo.

Entregado: migración 20261264 (aditiva y auto-verificada) con schema + schema_id en dataset_view_versions y view_schema_id en datasets; construirContrato sella el esquema; handleCreateView se lo pregunta al motor al crear; y el backfill de la única vista existente.

El schema-id comparte cuando la salida no cambia —dos versiones cuyo cuerpo se edita sin alterar lo que devuelve llevan el mismo schema-id—, que es la semántica del spec y tiene un uso concreto: un CREATE OR REPLACE que sólo toca el WHERE no debe invalidar a un consumidor pineado al esquema.

El backfill crea VERSIÓN, no hace UPDATE, porque el trigger de M4 lo impide: si la salida se sella con la versión, sellarla a posteriori es una versión. La vista quedó en v3, schema_id=3, 17 columnas — y el historial sigue contando la verdad (v1 nació sin atar, v2 sin esquema).

⛔ Y N4 destapó un DEFECTO VIVO: ninguna vista se podía LEER

Al pedirle al motor la forma del cuerpo saltó lo de verdad importante:

SELECT * FROM gold_order_risk_episodes   →  403 tabla_no_autorizada   (en producción)

La única vista del sistema no se podía consultar por la puerta. Y el diagnóstico costó cuatro mediciones porque las tres primeras hipótesis eran falsas:

Lo que quedaba era mirar qué manda Junction de verdad, y ahí estaba:

entrada = body.logical_sql or sql      # routers/query.py

En enforce se resolvía el SQL lógico —el que tecleó el usuario—, donde una vista aparece por su NOMBRE. Y el nombre de una vista nunca está en la rebanada, porque la rebanada son sus tablas base. Tres consecuencias, y la tercera es la peor:

1. toda lectura de una vista daba 403;
2. de haber estado el nombre, se habría ejecutado el lógico resuelto — o sea sin la expansión, contra una tabla que no existe físicamente;
3. como gobernanza estaba al revés: resolver el lógico deja las tablas de DENTRO del cuerpo de la vista sin comprobar, que es justo lo que la rebanada existe para comprobar (F4a).

El arreglo: en enforce se resuelve el SQL que se va a ejecutar; logical_sql conserva su papel en sombra, que es donde sirve (M2c: sin él se mediría un no-op). Cinco tests de regresión en test_m5_vistas.py, incluido el invariante que faltaba: una tabla no autorizada escondida dentro del cuerpo de una vista se delata.

Los gates

Pendiente: el arreglo del 403 es de duck-server, así que la vista no se lee en producción hasta desplegar. Verificado en frío y por tests.

20 · N5 (F4b) · lo entregado (2026-08-01)

El mecanismo resultó más barato que el planeado — porque ya existía

M3 §12 midió una vía: mandar las filas como relación inline, que duck-server las inyecte en el cte_map del AST, y admitir un destino de un solo nivel en _split3. Todo eso era necesario antes de N4. Después, no:

• buildDuckReadPlan ya sabe anteponer CTEs — es como expande una vista;
• mergeViewCtes ya sabe fundirlas con un WITH del usuario (el bug que M2c mató era anteponer a ciegas, no esto);
• rewriteDottedFromRefs ya colapsa nombres punteados a un identificador;
• y desde N4 el motor gobierna el SQL que se ejecuta, donde una CTE es una CTE.

Lo entregado

inline-relation.ts materializa las relaciones que el SQL mencione como SELECT * FROM (VALUES …) AS _t(col, …), desde una sola lectura de Index —que aquí importa más que nunca: si tables y columns salieran de dos lecturas, un JOIN entre ellas podría no cuadrar consigo mismo—. El escapado de literales tiene su test: los nombres de tabla son datos del usuario, y un ' sin duplicar sería inyección por la puerta de atrás.

Tres piezas más: rewriteDottedFromRefs colapsa information_schema.<rel> al nombre entero citado (el prefijo no es una coordenada que se pueda ignorar); el rechazo declarado de F1 pasa a alMotor, que no es un 400 sino «esto lo contesta el motor»; y runQuery admite una lectura sin tablas base cuando hay relaciones inline — el punto que M3 §12 anotó como pendiente.

⚠️ Un hueco que N5 abría, cerrado en el mismo commit

Una lectura sólo-metadata llega con la rebanada vacía, y duck-server hacía if body.catalog_slice: — que en Python es falso con {}, así que se saltaba el resolutor entero. Pasa a is not None: una rebanada vacía significa «nada autorizado», no «no compruebes».

El gate — 4/5 en vivo, y el 5º explicado

✅ ② information_schema.tables ⋈ information_schema.columns
✅ ③ agregado libre (avg + group by) — lo que el evaluador cerrado NO hace
✅ ④ un WITH del usuario + la relación inline
✅ ⑤ una lectura normal sigue igual
❌ ① information_schema ⋈ una tabla REAL  → espera al despliegue de N4

① es el único que lleva rebanada no vacía, así que es el único que pasa por el resolutor del desplegado, que aún resuelve el lógico. Verificado en frío con el código actual sobre el SQL y la rebanada exactos: 0 sin resolver ⇒ en enforce daría 200. Y ②③④ ya demuestran lo que el rechazo de F1 quitaba: joins entre relaciones y agregados arbitrarios sobre la metadata.

Tamaño medido del literal: 86 KB para 647 columnas + 106 tablas. Tope declarado: TOPE_FILAS_INLINE = 20.000.

Pendiente: desplegar duck-server cierra ① y la lectura de vistas a la vez — es el mismo arreglo.

Fuentes

• Information schema · Databricks · INFORMATION_SCHEMA.COLUMNS · Privileges & securable objects · Unity Catalog
• trinodb/trino#14000 — not all tables from system.metadata are access control aware
• Iceberg View Spec — el schema-id lo sella quien crea la versión
• Mediciones propias (2026-08-01), todas de sólo lectura y reproducibles:
  • scripts/dataspaces/m5-metadata-census.ts — tenencia, vocabulario de Index, vistas, coordenadas
  • scripts/duckdb/m5-columns-cost.ts — el coste del enriquecimiento, contra el duck-server de producción
  • scripts/duckdb/m5-column-drift.ts — deriva Index ↔ lago, por tabla y por tipo