833597c831fac49c2a6e2f1e0ea61268a8947a5f
La verificación adversarial detectó que, en PPTX (slide 16:9, corto), las columnas categóricas de ALTA cardinalidad NO id-like (Ticket, Cabin) ocupaban 3 slides cada una con el donut SEPARADO de su tabla: el top-k de 8 filas largas no cabía junto al donut y el keep-together partía la columna. (El PDF, en A5, ya estaba 1:1 correcto.) Arreglo SOLO en render_pptx_impl.py: - `_fit_group_blocks` (nuevo): para un Group con figura + DataTable que no cabe en el slide, reserva un alto mínimo para el donut (`_GROUP_MIN_FIG_H`) y recorta las filas de la DataTable a lo que queda, de modo que el gráfico se queda en el MISMO slide, junto a su tabla. No-op cuando ya cabe o no hay par figura+tabla (p.ej. columnas id-like, que ya omiten la top-k). - `_trim_data_table_to_budget` (nuevo): devuelve una COPIA de la DataTable con las filas que caben (al menos una) + nota honesta "top N de M categorías mostradas (recortado para caber en el slide; el PDF muestra más)". NUNCA muta el bloque original, que es compartido con el renderer PDF (el PDF sigue mostrando la tabla completa en A5). - `_place_group`: aplica `_fit_group_blocks` antes de `_shrink_group_figures`. Refuerzo de cat_distr_test.py: - `test_golden_pptx_una_slide_por_columna_con_su_grafico`: perfil con una columna categórica de alta cardinalidad no-id-like (40 valores largos sobre 5000 filas, 0.8% distinto) que reproduce el caso Ticket/Cabin. Asierta que CADA columna categórica aparece en EXACTAMENTE UN slide del capítulo y que ese mismo slide lleva su tabla (Cardinalidad/distintos) Y su donut (caption + shape Picture) — el gráfico nunca se separa de su tabla. Sustituye al laxo `n_slides >= 2`. Verificado con titanic_train.csv (render_automatic_eda run_models=True): 5 columnas categóricas (Name, Sex, Ticket, Cabin, Embarked); PDF 6 páginas y PPTX 6 slides del capítulo (intro + 1 por columna), cada columna con su donut junto a su tabla en una sola página/slide. Ticket y Cabin pasaron de 3 slides a 1. Suite verde (122 passed). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
fn-registry — Schema de documentación
Registry personal de código con búsqueda FTS. Diseñado para composición funcional y agentes.
Archivos
functions.md— Schema de la tabla functions (incluye pipelines y componentes React)types.md— Schema de la tabla typesintegrity.md— Reglas de integridad y referencias cruzadasarchitecture.md— Visión general del sistemasync_setup.md— Vincular una PC al serverregistry.organic-machine.com(env vars,fn sync, troubleshooting)adr/— Architecture Decision Records: decisiones de diseño (qué se decidió y por qué)../reports/— Reportes de trabajo: artefacto local (entregable de una tarea: qué se hizo, cómo se verificó, gaps). Gitignored salvo.gitkeep, NO sube a Gitea ni se versiona (como los vaults). Convención en.claude/rules/reports.md. Decisión: ADR 0006
Tablas
| Tabla | Descripción |
|---|---|
functions |
Funciones atómicas, pipelines y componentes React |
types |
Tipos algebraicos (product / sum) |
kind: valores posibles
| Valor | Descripción |
|---|---|
function |
Función atómica pura o impura |
pipeline |
Composición de funciones, siempre impura |
component |
Componente React, extiende el schema base |
fn-registry schema v1.0
Description
Languages
Python
51.7%
Go
18.5%
C++
15%
Shell
8.1%
C
3.4%
Other
3.2%