Campos de Native, tal como son
Donde el motor responde, los clientes muestran los nombres y valores de campo de Native, sin cambios: engine_version, native_directory_format, product_api_version, visible_csn, root_digest, directory_lineage, checkpoint_digest, max_sql_rows… Nada se renombra, redondea ni interpreta. Dos consecuencias:
- Todo lo que ves en el Studio se reproduce con
curlohcloudy se compara byte a byte. - El Cloud nunca se convierte en autoridad sobre los datos del motor por parafrasearlos.
HYPRSP01 y el único tipo que se decodifica
Sección titulada «HYPRSP01 y el único tipo que se decodifica»El /v2 de Native habla un sobre binario, application/vnd.hyphae.product-v1 (HYPRSP01). El Studio, hcloud y @hyphae/cloud decodifican exactamente un tipo: el kind 1, capabilities, con el formato publicado en el contrato de Native. La tabla decodificada muestra los nombres de campo del motor; los bytes crudos quedan a un clic. Cualquier otro tipo — incluidas las respuestas de /v2/sql — se muestra como bytes o se rechaza, nunca se adivina.
Por eso no hay editor SQL: /v2/sql solo acepta el sobre binario de peticiones de Native, y el Cloud no inventa una gramática encima. Usa el SDK oficial de Native a través del proxy del Cloud para trabajar con datos (@hyphae/cloud expone data(projectId, { key }).raw(path) para ello).