Qué es esta spec. Retirar dataset_rows y su cortejo del repo y de la base. Nada más.

Qué NO es. Implementar el plano de datos Iceberg + Parquet. Eso es otra spec (§7 lista lo que se le entrega). Aquí no se escribe ni una capacidad nueva sobre Iceberg: se borra la vieja, y donde la capacidad sólo existía sobre Postgres se cierra con un error honesto y se anota.

Index se queda en Postgres. datasets, project_files, schemas, catalogs, las transacciones-como-intención: son gobernanza, no dato. No los toca nadie. Ver warehouse-index.md.

⭐ Las cuatro lecciones, que valen más que la demolición

1 · Un trinquete a cero mide el REPO, no el SISTEMA. Los tres bajaron a cero y el plano seguía teniendo seis escritores — funciones PL/pgSQL, que no aparecen en ningún fichero. Es el punto ciego que ya obligó a escribir D·3, y volvió a aparecer en D·5.

2 · Una migración no es un cambio de la base: es un contrato entre el esquema y el código. Cuatro de las siete no podían aplicarse antes de desplegar el código que las acompaña — read-router consultaba las tablas de flags en cada operación. El orden lo manda el despliegue, no el plan.

3 · No basta con que el comando no falle: hay que mirar el resultado. 20261256 se reportó aplicada sin hacer nada (DROP FUNCTION IF EXISTS con firma que no casa no falla, no hace nada), y tres RPC que escribían el plano sobrevivieron. Desde entonces las migraciones de esta línea se auto-verifican, y eso cazó dos errores más: un RETURNS TABLE renombrado y un regex que quitó 30 asserts en vez de 8.

4 · Borrar código no lo caza el compilador — depende del lenguaje. En Python los nombres se resuelven en ejecución: al borrar la ruta del espejo se fue con ella un helper compartido, el módulo siguió importando, /health siguió dando 200 y /lakehouse/ingest estuvo caído hasta que un e2e lo pisó. Un health-check dice que el proceso vive; sólo un e2e que ESCRIBA dice que el camino de escritura existe.

Y un corolario que atraviesa las cuatro: §3 clasificó mal tres elementos (iceberg_sync_log, iceberg_freshness(), y dos de las tres satélite). Siempre por lo mismo — se clasificó por dónde vivía la cosa, no por lo que hacía. Que es, exactamente, el error que creó el plano de datos de Postgres.

La conclusión no es interpretativa: no era una tabla Iceberg con deuda, era una tabla Postgres cuyo almacenamiento se cambió a Parquet, conservando su esquema de identidad, su semántica de paginación, su contador monótono y su autoridad de lectura.

Nada de esto fue un error. Iceberg llegó como espejo, y la migración tenía que ser invisible para decenas de lectores ya escritos: el disfraz era la funcionalidad. El problema es que la factura sigue llegando cuando la razón —que hubiera datos que preservar— ya no existe.

Por qué «cerrar» y no «dejarlo funcionando en PG»: porque mientras el camino PG exista, el plano no se puede soltar — y un camino que sigue vivo es un camino que sigue creciendo. El precedente ya está sentado: la edición de fila mentía (devolvía success: true sin escribir nada sobre 14 datasets / 556.775 filas) precisamente porque se dejó apuntando a un plano que para ella ya no existía.

Tres premisas del plan original resultaron FALSAS al medirlas, y conviene recordarlo antes de creerse las que quedan: (a) P·3 «cae solo» — no caía, la reserva también daba la unicidad que consumían los lectores de P·2; (b) kuzu-engine «es el caso duro, usa __row_index como PRIMARY KEY» — su PK es un ordinal local, nunca fue __row_index; (c) «25 datasets sin clave + 14 sin esquema» — son 39 sin PK y 0 sin esquema, y además graph_explorer no tiene ni una etiqueta de nodo configurada, así que no bloqueaban nada.

🏛️ El manifiesto de ficheros — el único caso de «mudar», y por qué no era dato

Un dataset file-backed (media set, unstructured) no tiene filas: tiene ficheros, y de cada uno guardaba un puntero a sus bytes en Storage. Vivían en dataset_rows porque era el único almacén de filas a mano — y por eso parecían dato tabular. El propio registry ya lo desmentía: «manifests are control-plane file pointers, not tabular data».

Hay DOS vocabularios y no se han unificado: un media set habla de {media_reference, media_item_rid, timestamp, path}; la SDK, de {filename, size_bytes, mime_type, storage_path, uploaded_at}. La tabla tipa lo común (posición, clave del fichero, ruta, tamaño, mime) y conserva la forma completa en payload, así que ningún consumidor cambia de vocabulario: la galería, el pipeline de media sets, la SDK y el apply-schema ven exactamente lo que veían.

Y hay un detalle que lo justifica solo: el manifiesto siempre se direccionó por la identidad REAL del fichero —media_item_rid o filename—, nunca por la identidad sintética que P·2 retiró. Nunca la necesitó.

Repuntados: fileBackedDatasetUpload · notebooks/[id]/datasets/upload · projects/media-set/item · sdk/v1/…/files (listado) · sdk/v1/…/files/upload · applyDatasetSchema · y el browse, que para un dataset content_type='file' sirve el manifiesto en vez de preguntarle a la puerta por filas que no existen.

⛔ NO SE FLIPEA NADA. Los flags son andamiaje, no herramienta

Hubo una propuesta —mía— de «flipear los 7 escritores a iceberg_native» como primer paso. Es un error de encuadre y queda anulada. Flipear un flag es elegir substrato: tiene sentido en una migración gradual y reversible. Esta spec no migra, demuele, y el final tiene un solo substrato — así que no hay nada que elegir. lakehouse_read_flags / write_flags / read_parity están en la lista de §3: se borran con el plano, junto con el pickPortMode que los lee.

El corolario práctico: los pins por dataset no se quitan, se quedan irrelevantes. En cuanto D·1/D·2 borren la rama PG del código, nadie consulta la tabla y da igual lo que diga. Ningún canario, ningún rollout, ninguna ventana de observación.

Se conserva aquí el censo del pre-vuelo porque describe la superficie a borrar — no porque haya que operarla. Medido en el control-plane de producción el 2026-07-30 (lakehouse_write_flags, 47 filas):

Escritor	Estado real
sync.full · sync.incremental · sync.append · cdc.append	YA tienen fila GLOBAL iceberg_native (desde 2026-06-30). No hay nada que flipear
pipeline.output · manual.table · ingest.api · sql-editor.dml	Techo iceberg_native, pero sin fila global ⇒ caen a defaultMode: 'pg' del registry

Lo que hoy mantiene vivo el plano PG son 40 filas de pin por dataset (4 escritores × 10 datasets), todas con la misma nota:

F4 pipeline-input pin (sourceCte reads dataset_rows; deferred to Karma) — puestas el 2026-06-30 por _pin-tmp.

El dato útil que sale de ahí no es operativo, es de INVENTARIO: el pin señala con el dedo el sitio de código que hay que borrar. lib/pipelines/source-resolver.ts ya está rutado por la facade y ya tiene la rama de hidratación escrita — lo que hace que siga leyendo Postgres es que su rama PG existe y es el defecto. Borrar esa rama deja una sola, y el pin deja de significar nada.

Lo mismo con pipeline.source, que no tiene NINGUNA fila en lakehouse_read_flags (10 readers la tienen; él no): no hay que darle una, hay que quitarle la alternativa.

⚠️ Corrección: branches y PRs NO son una feature del plano de datos

El plan decía «las branches/PRs se retiran». Falso, y por poco no se borra una feature viva. Medido: de las RPC de branch, sólo 5 tocan el plano (merge_pull_request, compute_pr_diff, sdk_open/commit_branch_transaction, create_workspace_branch). Las demás —open/close/reopen_pull_request, archive_workspace_branch, reap_old_closed_prs— versionan celdas de notebook, con UI viva en el tab de Jupyter (BranchSelector, CreateBranchModal, PullRequestsView, el diff de celdas…). Se quedan.

Lo que sí se retira es el overlay de FILAS por branch (dataset_branch_rows, 0 filas — el Lazy-COW nunca se llenó).

⚠️ Dos cosas del §3 que resultaron NO ser del plano

iceberg_sync_log CAMBIÓ DE SIGNIFICADO y se queda. Nació como el log del espejo PG→Iceberg —y §0·6 lo señala como parte del disfraz—, pero hoy es el ledger de operaciones del JOP: ratify lo escribe y lo repara para que una escritura nativa sea atribuible, y reconcile/compensate lo leen. Eso es gobernanza: es Index. Merece un rename; renombrar no es demoler.

iceberg_freshness() pierde su papel de AUTORIDAD pero conserva un uso legítimo. Comparar dos tablas de Postgres para autorizar una lectura del lakehouse —el eslabón más grave de §0— ha desaparecido con la elección de substrato. Pero la misma función responde también «¿aterrizó mi escritura?» (dataset-output-materialiser), que no es autorización sino observación. Se queda por eso.

✅ Las tres columnas de identidad — CERO (2026-07-30)

__row_index · __row_id · __created_at ya no aparecen en ninguna línea de código del repo. El trinquete check:row-index-seam pasa de vigilar una retirada a vigilar que no vuelva.

Recorrido: 47·185 (contando prosa) → 28·94 al recalibrar a sólo-código → 22·75 tras P·2 → 0·0.

Y la línea que más pesaba de todas: _create_native_table declaraba SortOrder ASC sobre __row_index. Ésa es la punta de la cadena de §0 —la extensión Iceberg de DuckDB rehúsa escribir en tablas ORDENADAS → toda tabla nativa declaraba SortOrder → INSERT y UPDATE eran imposibles → la puerta los rechazaba—. Sin identidad que ordenar no hay orden que declarar: las tablas se crean sin SortOrder.

⇒ El motivo por el que 6 de los 10 verbos estaban cerrados ha desaparecido. El rechazo sigue en pie (no es esta spec quien abre verbos), pero su mensaje ya lo dice y la matriz está pendiente de RE-MEDIR sobre una tabla creada sin la declaración. Es la primera entrega concreta que esta demolición le hace a la spec del plano Iceberg.

Se fue con ellas: el estampado por fila (_stamp_row), la continuación del contador en el writer chunked, withIdentityFields, RESERVED_*, includeIdentity en todo el contrato de la puerta, el gate «identidad ausente → degrada a PG», FreshnessVerdict.identityReady e icebergIdentityReady. Y el espejo en Python (sync_service.py + la ruta POST /lakehouse/sync), que sobrevivía al borrado de su worker en D·1c.

✅ Aplicadas a producción (2026-07-31): 20261228 + 20261258

20261228 era la que PROTEGE el dato, no la que lo arriesga, y eso se vio al medir: los 5.193 objetos con puntero tenían properties = '{}', los 5.193. Toda su información vivía únicamente en dr.data — o sea, sólo en el plano PG. Sin este backfill, el DROP los habría dejado vacíos.

Verificado tras aplicarla: backfill 5.193/5.193, divergencia 0 entre base_properties y dr.data (la vista sirve exactamente lo mismo que antes: cambio invisible), 0 vistas dependen ya de dataset_rows, y las dos fn_instantiate_links_* fuera de ⑦. 20261258 es aditiva pura (CREATE TABLE), segura con cualquier versión del código.

(De paso: el detector de ⑦ contaba comentarios. Una función recién migrada conserva un -- … no dataset_rows read explicando el cambio y quedaba marcada para siempre. Ahora descuenta los comentarios de línea antes de buscar.)

⛔ Las 4 restantes están acopladas al DESPLIEGUE, no a una decisión

main sólo tiene commits de docs desde D·1: todo el código de D·1–D·4 está sin commitear, así que producción corre el código pre-demolición. Contra ese código, las cuatro no son «pendientes», son roturas inmediatas — verificado en main, no supuesto:

Migración	Qué suelta	Qué lo usa en main
20261257	lakehouse_read_flags · write_flags · read_parity · iceberg_sync_cursor	read-router.ts:79 y write-router.ts:89 las consultan vía makeFlagLoader en cada lectura y cada escritura del seam. Soltarlas tumba producción en el acto
20261259	dataset_branch_rows	8 sitios, incluidos junction.ts (la puerta) y lib/branches/queries.ts
20261256	las RPC transaccionales de la SDK	3 rutas vivas de sdk/v1/…/transactions las llaman (aún no devuelven 410)
20261255	2 columnas de lakehouse_sync_partitions	el fan-out del sync-worker, que en main sigue existiendo (D·1c lo borró sólo en el árbol)

Van con el despliegue de D·1–D·4, no antes. El orden es: commitear + desplegar el código → aplicar las cuatro → re-correr el censo.

⚠️ Corrección: «La ontología NO se toca» es FALSO en la BD viva

§3 lo daba por hecho: «la migración 20261228 ya los desacopló (objects.base_properties denormaliza los datos de fila)». Esa migración existe en el repo y no está aplicada: objects.base_properties no existe.

Hoy, en la BD viva, la ontología lee el plano en tres sitios: la vista objects_resolved (LEFT JOIN dataset_rows dr ON dr.id = o.dataset_row_id) y las dos funciones de auto-link, que el audit de drift reporta divergiendo — el repo dice base_properties, la base dice dr.data.

Y no es cosmético: 5.193 objetos llevan puntero, 0 rotos, y los 5.193 DIVERGEN de o.properties. La vista sirve hoy datos que sólo existen en el plano PG — y objects_resolved es superficie viva de producto (el grid de objetos, los links, el mapa/geo, el twin).

El orden es duro, no una preferencia: el paso 1 de 20261228 es un backfill que LEE dataset_rows. Si el DROP va primero, ese backfill deja de ser posible y esos 5.193 objetos pierden sus propiedades resueltas para siempre.

El paso 2 es el que gobernó todo lo demás, y no estaba en el plan original porque el plan sólo miraba el repo. Cuatro de las seis migraciones no se podían aplicar antes de desplegar el código que las acompaña: en un sistema donde el esquema y el código se despliegan por separado, una migración no es un cambio de la base, es un contrato entre las dos mitades.

⚠️ Y una tercera corrección a §3: de las tres satélite, dos NO eran andamiaje

§3 las listaba como «se demuelen con el plano porque son su andamiaje». Medido antes de soltarlas —estar VACÍA no es estar SIN USAR, y el censo sólo contaba filas—:

dataset_row_staging	✅ soltada. Era el aterrizaje del protocolo transaccional de la SDK, que está cerrado
sdk_file_staging	⛔ SE QUEDA. VIVA: la ruta de upload de batches escribe en ella y sdk_commit_file_batch la lee y la vacía. Es exactamente lo mismo que el manifiesto — control-plane, o sea 🏛️ Index
lakehouse_sync_partitions	⛔ SE QUEDA. VIVA: la usa base-polling-worker. Nació para el fan-out del espejo, pero el espejo se borró y ella siguió sirviendo al polling

Van ya tres veces que un elemento de esa lista resulta no serlo (antes: iceberg_sync_log, que había cambiado de significado, e iceberg_freshness(), que conservaba un uso legítimo). El patrón es siempre el mismo: se clasificó por dónde vivía la cosa, no por lo que hacía.

De paso salió un daño evitado: la ruta de commit de la SDK cerraba al FINAL, tras ~110 líneas de trabajo que incluían leer dataset_row_staging. Soltar la tabla habría convertido su 410 honesto en un 500 opaco. El cierre se movió arriba y el cuerpo muerto se suprimió — con sus imports y helpers huérfanos, que es el mismo resto que en Python dejó /lakehouse/ingest caído.

Dos trampas que costaron un intento cada una, y las dos las cazó la auto-verificación

CREATE OR REPLACE no puede renombrar una columna del RETURNS TABLE. La firma viva era reaped_datasets, no reaped; renombrarla cuenta como cambio de tipo de retorno. Falló en voz alta y, al ir todo en una transacción implícita, no se aplicó nada a medias.

En una ARE de PostgreSQL, si el PRIMER cuantificador es greedy, TODA la expresión lo es — el .*? deja de ser lazy y no se comporta como PCRE. El bloque que reescribía sdk_healthz_strict por regex desde dentro de la base quitó 30 asserts en vez de 8; lo cantó el propio conteo de la migración, que abortó antes de aplicar. La sustitución se hizo fuera, se contó (37 → 29, cero colaterales) y en la migración va el resultado literal: determinista y revisable en el diff.

Es la misma lección otra vez, y ya van varias en esta spec: no basta con que el comando no falle — hay que mirar el resultado.

⭐ Y lo que esta demolición le ENTREGA, no sólo le pide

_create_native_table ya no declara SortOrder sobre ninguna columna. Ésa era la punta de la cadena del §0 —DuckDB rehúsa escribir en tablas ordenadas → toda tabla nativa declaraba SortOrder → INSERT y UPDATE imposibles—. El motivo por el que 6 de los 10 verbos estaban cerrados ha desaparecido.

El rechazo de la puerta sigue en pie (abrir verbos no es esta spec) pero su mensaje ya lo dice. Primera tarea recomendada de la spec Iceberg: re-medir la matriz de verbos con scripts/duckdb/verb-conformance.ts sobre una tabla creada sin la declaración. Marcador de referencia: 4/10 antes de todo esto.