Cuaderno

Reportador vs. narrativo:

• MAL (reportador): "Implemente deteccion dual de picos. Detecte 9 picos. Cinco confirman eventos anotados."
• BIEN (narrativo): "Volvi a mirar la deteccion de picos. Uso z-score combinado con find_peaks. El metodo detecta 9 picos, pero solo 5 coinciden con eventos anotados y son los que tienen sentido narrativo."

Cronologico y razonado: El cuaderno muestra el proceso de pensamiento. No solo QUE se hizo sino POR QUE. Si tome una decision metodologica, explicar el razonamiento. Si algo fallo, documentar que se intento antes de llegar a la solucion.

Microestructura narrativa

Titulado de secciones internas. Cuando una entrada tiene sub-secciones dentro de \paragraph{Trabajo realizado.}, usar \subparagraph{} con titulo conversacional que nombre el tema, no el paso del pipeline.

• PROHIBIDO: \subparagraph{Paso 1: ...}, \subparagraph{Etapa 2: ...}, \subparagraph{Analisis N: ...}.
• CORRECTO: \subparagraph{Los datos.}, \subparagraph{Calidad.}, \subparagraph{Engagement: colas pesadisimas.}, \subparagraph{Problema: nuestro dataset no tiene seguidores.}, \subparagraph{Trazando los 40 medios de Juana en Instagram.}.
• Prueba: si el titulo sugiere "pipeline ejecutado", esta mal; si sugiere "tema sobre el que estoy pensando", esta bien.

Objetivo y metodo al abrir cada \subparagraph. Cada subparagraph debe abrir con una oracion que diga QUE se esta investigando y, acto seguido, otra que explique COMO se aborda (metodo/tecnica/datos). No zambullirse en resultados sin contextualizar. Modelo bueno (keywords): "El dataset que nos entrego MCL esta filtrado por una query de keywords que no nos compartieron; antes de cruzar engagement con 'de quien habla cada post' queria entender que tan bien puedo reconstruir esa query desde afuera. La idea del ejercicio es buscar en el dataset las keywords que yo usaria y medir que posts quedan afuera." Modelo malo: "Arme tres tiers de keywords. Tier 1 usa combinaciones AND-based..." (empieza en el metodo sin decir para que).

Prohibicion de sub-sub-estructura:

• PROHIBIDO usar \emph{(a) ...}, \emph{(b) ...}, \emph{(c) ...} para enumerar puntos dentro de un subparagraph. Si tenes 3-4 puntos, son 3-4 parrafos conectados por prosa, no una lista disfrazada.
• PROHIBIDO usar \emph{Titulo breve.} al comienzo de un parrafo como sub-sub-titulo. Si el contenido merece titulo propio, promoverlo a \subparagraph{}; si no, conectarlo al parrafo anterior con transicion narrativa.
• PROHIBIDO incluir "sintesis" con formato (i), (ii), (iii) al final de una seccion. Las sintesis son un parrafo de prosa.

Uso de listas (itemize, enumerate):

• PERMITIDO solo en: Preguntas abiertas, Proximos pasos, Decisiones pendientes, Opciones (alternativas de decision futura), Limitaciones.
• PROHIBIDO en el cuerpo descriptivo o en secciones de resultados. Una enumeracion de eventos/picos/cuentas/hallazgos descriptivos es prosa conectada, aun si son 4-5 items.
• Regla operativa: si cada \item tiene mas de 1-2 lineas de texto, probablemente deberia ser prosa.

Integracion de resultados e interpretacion. Los numeros y cifras se mezclan con la interpretacion en la misma oracion o parrafo, no se separan en bloques distintos. Modelo: "Para likes: mediana = 277, media = 3,888 --- catorce veces mayor. La desviacion estandar (44,710) es once veces la media. No hay forma de tratar esto como una distribucion normal."

Precision cuantitativa --- tres errores recurrentes:

• Entidades distintas, nombres distintos: cuando un conteo tiene matices (ej. "medios trazados" vs "cuentas unicas en Instagram"), usar terminos distintos y definirlos una vez explicitamente. Ejemplo que hubo que corregir: "31 medios confirmados" (ambiguo cuando 4 aliases de marca comparten cuenta con medios ya contados) --> "35 medios trazados sobre 31 perfiles unicos". No reutilizar el mismo numero si representa dos cosas distintas a lo largo del texto.
• Dimension de los porcentajes: siempre aclarar si un porcentaje se computa sobre POSTS o sobre CUENTAS (el dataset casi siempre tiene las dos dimensiones disponibles y el resultado cambia). Ejemplo que hubo que corregir: "las cuentas business son mayoria (51.7%)" --> "los posts provienen mayoritariamente de cuentas business (51.7%)". En la dimension cuentas, business no era mayoria.
• Ambiguedad de campos categoricos del MCL: cuando se segmenta por un campo como post_owner.type (business/creator/personal), discutir explicitamente si esa categorizacion es significativa para la pregunta analitica. Business/creator reflejan la configuracion de herramientas de perfil del titular, no su rol editorial: @barackobama es creator, @michelleobama es business, Newsmax es creator, NYT es business. Si la segmentacion mezcla "medio", "politico" y "creador viral", hay que decirlo en el texto y usar una capa externa (como la lista de Juana) para separar.
• No asumir causa unica para anomalias: cuando se diagnostica un conjunto chico de casos raros (outliers, edge cases, posts "Neither"), inspeccionar CADA caso individualmente antes de categorizar. No extrapolar de 3-5 ejemplos al patron global: el caso modal suele esconder estructura categorica. Ejemplo real: en 2026-04-09.tex (primera iteracion) diagnostique los 42 posts "Neither" no-story como "ofuscacion Unicode + stories" a partir de 3-4 ejemplos; la auditoria profunda en el commit 58d9f16 revelo que eran 5 categorias estructurales con root causes completamente distintos (Unicode 13, redacted 3, username 1, drift 20, residual 5). Regla: si hay menos de 100 casos, enumerarlos exhaustivamente antes de afirmar "el patron es X". Si son mas, muestrear por cuantiles de una metrica relevante en vez de agarrar los primeros que aparecen.

Referencia a figuras con fluidez. "En la Figura~\ref{fig:X} se ve el panorama completo de nulidad por columna" (bien). No: "La Figura X muestra Y. Se observa Z." (mal, robotizado). Si hace falta interpretar, hacerlo en la misma oracion o inmediatamente despues, no en un bloque aparte.

Que va en el cuaderno y cuanto espacio merece

Analisis y resultados (ESTO ES LO PRINCIPAL --- merece todo el espacio que necesite): Narrativa cronologica y analitica. "Analice este dataset, con esta metodologia, obtuve estos resultados. La Figura~N muestra tal cosa. De esto se puede inferir que...". Incluir figuras con numeracion automatica (\begin{figure}, \caption{}, \label{fig:...}), citas con \cite{}, y ecuaciones en entornos LaTeX cuando corresponda. Si un script genero los resultados, marcar con \texttt{@src/scripts/nombre.py} y nada mas.

Explicar pipelines de datos: flowchart + cascada. Cuando la narrativa de un subparagraph es "aca esta lo que cambie en el pipeline y por que importa" (multiples fixes encadenados), combinar dos visualizaciones complementarias: (1) un flowchart que muestra COMO funciona el pipeline, con los pasos nuevos resaltados; (2) una barra en cascada que muestra el IMPACTO de cada fix sobre los datos (por ejemplo 42 -> 29 -> 28 -> 25 -> 5 Neither posts, una barra por fix). Cada visualizacion responde una pregunta distinta: el flowchart solo no muestra impacto, la cascada sola no explica como funciona el pipeline. Juntas cubren las dos. Ejemplo real: el commit 3c1973c agrega keywords_pipeline_flowchart y keywords_recovery_cascade para la auditoria del validador de keywords en 2026-04-09.tex.

Ejemplos cualitativos --- mini-tablas y blockquotes. Cuando un hallazgo es cualitativo (casos edge, outliers, ejemplos de un fenomeno, posts "Neither", etc.), la descripcion en prosa debe ir acompanada de una mini-tabla con 3-5 ejemplos representativos (\begin{table}[!ht] con \small o \footnotesize, columnas minimas, 3-5 filas). Ejemplo real: los cinco posts Neither de la entrada 2026-04-09 (2 stories de @christalhayes, @hiphopwired, @kamalaformi, @tagesschau) en una tabla de columnas username / tipo / contenido / match_type / comentario. Cuando hay UN caso canonico que amerita citarse integro (un mensaje especifico, un caption clave), usar \begin{quote}...\end{quote} con el texto limpio --- no parafrasear.

Una mini-tabla por categoria, no una tabla grande plana. Cuando el hallazgo tiene N categorias estructurales con caracteristicas distintas, usar N mini-tablas (una por categoria) con 2-3 ejemplos cada una, en vez de una sola tabla plana de 5 filas que mezcla todo. La tabla plana es enganosa: oculta que cada categoria tiene un root cause distinto y colapsa el argumento per-categoria. Cada mini-tabla lleva \footnotesize + columnas p{Ncm} para que no desborde el ancho. Ejemplo real: en la primera iteracion de 2026-04-09.tex habia una tabla grande de ejemplos Neither; al profundizar la auditoria aparecieron 5 categorias estructurales (Unicode, redacted, username, drift, residual) y cada una paso a su propia mini-tabla en el commit b913e8b. Prueba: si el analisis discute las categorias por separado en el texto, la tabla tambien debe estar separada por categorias.

Insights de lecturas (solo si hay insight concreto --- 4-5 oraciones): La bibliografia SOLO entra al cuaderno cuando genera un insight que impacta en como voy a hacer la tesis: una conexion nueva, una limitacion que no habia considerado, una tecnica que resuelve un problema. "Al leer X, entendi que Y, lo cual implica Z para nuestro enfoque" SI va. "Lei 5 papers de BERTopic" NO va. Si no hay insight, no mencionar la lectura.

Reuniones con directores (dentro de la entrada del dia --- foco en decisiones): Fecha, quienes participaron, y sobre todo: que se decidio, que feedback recibi, que cambio en el rumbo del trabajo. No es una minuta completa.

Derivaciones matematicas (el espacio que necesiten): Ecuaciones en equation/align, numeradas si son importantes para referenciar despues.

Problemas y soluciones (solo si el razonamiento es interesante): Que problema surgio, que se intento, que funciono. Documentar la logica, no solo el fix.

Ideas y preguntas abiertas (breve): Hipotesis para explorar, preguntas para directores, conexiones con otros trabajos.

Implementacion de codigo sin ciencia nueva (1-2 oraciones maximo): "Implemente el pipeline de recoleccion de datos (\texttt{@src/scripts/scraper.py}). Permite filtrar por medio y rango temporal." FIN. No describir funciones, no poner snippets de codigo, no explicar la arquitectura del script.

Limitaciones (integradas en el texto --- seccion final solo residual): Lo normal es que cada limitacion se mencione inline, en el mismo parrafo donde se discute el hallazgo al que afecta ("la metrica completa seria $#L/(#P\times#S)$ pero no tenemos $#S$", "el substring matching falla con ofuscacion Unicode"). La seccion \paragraph{Limitaciones} al final NO debe repetir lo que ya dice el cuerpo: se reserva solo para el punado de limitaciones transversales que no cupieron inline, y se escribe como un parrafo corto de prosa (dos o tres oraciones), no como itemize. Si toda limitacion ya aparece en el texto, omitir la seccion final.

Proximos pasos (siempre al final, telegrafico y ESTRATEGICO): 2-4 items concretos. Deben ser estrategicos (features a implementar, consultas con directores, analisis a correr, proximos hitos de NLP/modelado), no tacticos (fixes de regex, correcciones de una linea, TODOs de implementacion). Los items tacticos pertenecen como comentarios en el codigo o TODOs en los scripts, no al final de una entrada del cuaderno. Modelo bueno: "Feature 'de quien habla cada post'", "Consulta con Sebastian sobre normalizacion Unicode", "Scraping de seguidores con Selenium", "NLP y modelo de espacios latentes". Modelo malo: "Corregir substring matching con regex \b en validate\_keywords.py".

Que NUNCA va en el cuaderno

• Codigo fuente: NUNCA. Ni snippets, ni funciones, ni bloques. Solo \texttt{@ruta/archivo.py, lineas XX-YY} si es relevante saber donde esta algo.
• Listas de papers como inventario: No listar todo lo que se leyo. Solo lo que genero insight.
• Informacion duplicada: Si ya esta en un README, en el CLAUDE.md, o en docstrings del codigo, no repetirla. Solo referenciar: "Organice la bibliografia en 6 categorias tematicas (ver \texttt{bibliografia/})".
• Duplicacion entre entradas del cuaderno: si un tema pertenece logicamente a una entrada anterior (porque ahi se introdujo el contexto, la figura base, el analisis original), actualizar la entrada vieja en lugar de redesarrollar el tema en la nueva. En la entrada nueva dejar una sola linea de referencia: "(Nota: tambien actualice X en la entrada del 3 de abril, ver \ref{entry:2026-04-03}.)". Ejemplo real: la discusion de picos temporales pertenece a la entrada del 3 de abril donde se introdujo la serie temporal, no a una entrada posterior sobre otro tema.
• Infraestructura: Instalaciones, configuraciones, setup de entorno --- una oracion como maximo, nunca es el foco.
• Tamano en memoria/disco del dataset: No es relevante para el cuaderno de laboratorio.
• Relleno: Si no hubo pensamiento nuevo, no generar entrada. Decirle al usuario "No veo material suficiente para una entrada del cuaderno. Hay algo que quieras registrar que no este en los commits?"

Conocimiento de base sobre el dataset MCL

Hipotesis validada sobre el matcher de keywords de MCL. La auditoria del commit 8193284 revelo con alta probabilidad dos caracteristicas del matcher interno con el que Meta construyo nuestro dataset, que no son obvias sin inspeccionar los casos Neither:

1. Normalizacion NFKD + strip de marcas combinantes: MCL aplica unicodedata.normalize("NFKD", text) y elimina caracteres en el rango U+0300-U+036F (combining marks) antes de buscar keywords. Esto explica que posts ofuscados con math-italic/bold/script o con tildes sinteticas (U+0337 despues de cada letra, como el caption aleman de @tagesschau) aparezcan en el dataset a pesar de que un substring match ingenuo sobre post_text no los captura.
2. Busqueda sobre post_owner.username + post_owner.name: MCL matchea tambien el texto del dueno de la cuenta, no solo post_text. Esto explica que @kamalaformi ("Kamala for Michigan") este en el dataset aunque ninguno de sus posts individuales contenga una keyword Tier 1 en el caption.

Implicacion operativa para futuros analisis. Cualquier validador, matcher o pipeline que compare "que capturo MCL" contra "que capturariamos nosotros" tiene que replicar ambas cosas desde el vamos. El dataset MCL NO es "substring match crudo sobre post_text" --- es un match normalizado y aumentado con owner text. El baseline upgrade esta en src/analysis/candidate_classification/validate_keywords.py (helper _normalize() + columnas owner_{col} OR-eadas en cada Tier). Cuando una entrada futura discuta discrepancias entre nuestro matching y el de MCL, arrancar desde este baseline y no desde substring crudo, o el diagnostico va a ser incorrecto.

Regla de proporcionalidad

La extension debe ser proporcional al contenido real, no al "tipo de dia" abstracto. La referencia operativa es cuantas figuras, tablas y hallazgos concretos tiene la entrada.

Reglas duras:

• Nunca rellenar para alcanzar un target. Si una idea cabe en 40 lineas y el target sugiere 80, quedarse en 40.
• Nunca recortar contenido sustantivo para meterlo en un target. Si hay 10 figuras con interpretacion real, 80 lineas no alcanzan.
• Arriba de 300 lineas: preguntarse "?`cada seccion merece estar, o estoy duplicando un README / una entrada anterior / explicando codigo?". Recortar lo redundante.
• Arriba de 500 lineas: obligarse a parafrasear el arco narrativo en 3-4 oraciones (prueba del hilo). Si cuesta, fragmentar en dos entradas del mismo dia con \bigskip.

Template de entrada

Las secciones aparecen SOLO cuando hay contenido relevante. No incluir secciones vacias.

\subsection{DD de Mes de YYYY --- Descripcion breve de lo realizado}
\label{entry:YYYY-MM-DD}

\paragraph{Objetivo.}
% 1-2 oraciones naturales. NO formato "Ejecutar los action items X, Y, Z" que suena a ticket.
% Si el dia arranca con una reunion que define las direcciones, puede ser mejor OMITIR el Objetivo
% formal y empezar directamente con \paragraph{Reunion con [nombre].} seguido de una introduccion
% narrativa que enmarca las direcciones acordadas.
% Ejemplos buenos:
%   "Revisar la tesis de Juana para evaluar si su metrica es aplicable a nuestro dataset."
%   "EDA completo del dataset MCL de Instagram para caracterizar los datos antes de NLP."
% Ejemplo malo:
%   "Ejecutar los cuatro analisis propuestos en la reunion del 4 de abril: identificacion
%   de medios, validacion de keywords, engagement normalizado y deteccion de picos."

\paragraph{Trabajo realizado.}
% Narrativa cronologica y razonada. Prosa conectada, NO listas de items.
% Aca van las figuras si las hay:
%
% \begin{figure}[!ht]
%   \centering
%   \includegraphics[width=0.8\textwidth]{../src/plots/nombre.png}
%   \caption{Descripcion completa en espanol.}
%   \label{fig:etiqueta}
% \end{figure}
% IMPORTANTE: el bloque \begin{figure} va INMEDIATAMENTE despues del
% parrafo que referencia la figura (no al final de la seccion). Cada
% figura es ATOMICA: un PNG por \begin{figure}, con su propio \label.
% Nunca combinar varios paneles en un mismo bloque (dificulta discutir
% paneles individualmente y controlar el placement).
% Generado por \texttt{@src/scripts/script.py}
%
% Aca van las ecuaciones si las hay:
% \begin{equation} ... \end{equation}
%
% Aca van las citas si corresponde: \cite{key}

% SOLO si hubo reunion:
\paragraph{Reunion con [nombre].}
% Decisiones, feedback, cambios de rumbo.

% SOLO si hay preguntas/ideas nuevas:
\paragraph{Preguntas abiertas.}

\paragraph{Proximos pasos.}
% 2-4 items telegraficos.

Convenciones LaTeX

• \subsection numerado (sin asterisco) para que aparezca en la tabla de contenidos. El titulo incluye la fecha seguida de --- y una descripcion breve (una oracion) de lo realizado ese dia. Ejemplo: \subsection{3 de abril de 2026 --- EDA completo del dataset MCL de Instagram}.
• Figuras con placement [!ht] (NO [htbp]) y ubicadas inmediatamente despues del parrafo que las referencia. Tablas tambien con [!ht]. El objetivo es que cada figura/tabla flote lo menos posible del texto que la discute. Excepcion: cuando un subparagraph acumula mas de 4 figuras, la regla se invierte --- ver regla de agrupamiento abajo.
• Agrupamiento de figuras cuando son >4 en un subparagraph. Si un subparagraph tiene mas de 4 figuras, NO intercalarlas con prosa: LaTeX con [!ht] reordena los floats y genera un efecto "muro de figuras" mas dificil de leer, no mas facil (error detectado al iterar sobre cuaderno/entradas/2026-04-09.tex, subparagraph "Engagement por cuenta" con 10 figuras en ~160 lineas, commit b913e8b). La regla correcta es dividir la prosa en 3-4 sub-bloques conceptuales, dejar que cada sub-bloque fluya sin interrupcion, y al final del sub-bloque agrupar sus 2-3 figuras con [htbp] (aca si [htbp], porque el objetivo deja de ser adyacencia y pasa a ser que el algoritmo natural de floats de LaTeX las ubique razonablemente). Patron de referencia:

  % MAL: intercaladas con [!ht], LaTeX las reordena, muro de figuras
  \subparagraph{Tema.}
  Primera discusion...
  \begin{figure}[!ht]...\end{figure}
  Segunda discusion...
  \begin{figure}[!ht]...\end{figure}
  
  % BIEN: agrupadas al final de cada sub-bloque con [htbp]
  \subparagraph{Tema.}
  Primera discusion de la distribucion, mencionando la Figura~\ref{fig:X}.
  Segunda discusion del ranking, mencionando la Figura~\ref{fig:Y}.
  
  \begin{figure}[htbp]...\label{fig:X}\end{figure}
  \begin{figure}[htbp]...\label{fig:Y}\end{figure}
  

• Figuras atomicas: un PNG por \begin{figure}, con su propio \caption y \label. Nunca agrupar varios paneles en un solo bloque "por ahorrar espacio" --- dificulta discutir paneles individualmente en el texto, obliga a captions generalistas y complica el placement. Si un script produce 3 paneles, son 3 \begin{figure} separados.
• Todas las figuras y entradas con \label para referencia cruzada.
• Citas con \cite{key} usando las claves de bibliografia/refs.bib.
• Escapar guiones bajos en paths: \texttt{src/scripts/mi\_script.py}.
• Ecuaciones numeradas si son para referenciar, sin numero (equation*) si son auxiliares.
• Fechas en espanol: "2 de abril de 2026". En \label: formato ISO entry:2026-04-02.
• NEVER write author names with years as plain text (e.g., "del Pozo et al. (2024)"). ALWAYS use Author et al.~\cite{key}. Before generating the entry, verify every citation key exists in bibliografia/refs.bib.

Convenciones del header / main.tex

El header del PDF dice "Cuaderno de Tesis", no "Cuaderno de Laboratorio". Si editas cuaderno/main.tex para agregar secciones o entradas nuevas, NO toques \fancyhead[L] a menos que sea para corregir un bug explicito.

Lecciones sobre layout LaTeX en el cuaderno

Problemas recurrentes de overfull hboxes y desbordes detectados al compilar entradas largas (ej. la iteracion 3 sobre 2026-04-09.tex, commit del header fix + 8 overfulls resueltos):

• No usar \verb|...| en el cuaderno: tiene cero puntos de ruptura y causa overfull hboxes con cualquier contenido largo. Preferir \texttt{} con \allowbreak en puntos naturales (., _, ,).
• Paths largos en prosa (mas de 20-25 caracteres) deben acortarse a filename-only (ej. validate_keywords.py en vez de src/analysis/candidate_classification/validate_keywords.py). Para los casos donde se necesita el path completo, envolver en \path{} del paquete url. main.tex ya carga url antes de hyperref.
• Tablas con columnas inflexibles (l) + contenido largo tienden a causar overfulls. Preferir p{...cm} en todas las columnas + \footnotesize cuando el contenido es denso. Calcular el ancho total para que no exceda el \textwidth de 16 cm (margen 2.5 cm en a4).
• Para \texttt{post_owner.type}, \texttt{post_owner.username}, \texttt{post_owner.name} y otros identificadores con punto, agregar \allowbreak despues del . (ej. \texttt{post\_owner.\allowbreak type}) para que LaTeX pueda romper la linea en ese punto.
• Subparagraph headings muy largos (>30 caracteres) + primera oracion densa pueden causar overfull porque LaTeX no tiene donde romper la primera linea. Preferir headings cortos (5-10 palabras).

Lecciones sobre figuras

Observaciones de la iteracion 3 sobre el flowchart del pipeline de keywords (migracion matplotlib -> TikZ) y la barra en cascada del recovery de Neither posts:

• Flowcharts: preferir TikZ directo en el .tex para calidad publication-grade. Matplotlib FancyBboxPatch + FancyArrowPatch se ve amateur y no matchea la tipografia del body LaTeX.
• TikZ + babel-spanish: babel-spanish hace el caracter > activo, lo cual rompe >=Stealth en estilos de arrow. Fix: wrap el tikzpicture en \shorthandoff{>} ... \shorthandon{>}, o (mejor) usar syntax inline -{Stealth[length=6pt]} en lugar de ->, >=Stealth.
• Bar charts con cascades: incluir deltas explicitos en labels (29 (-13), 28 (-1)) para que la historia cuantitativa sea legible de un vistazo. No dejar que el lector tenga que calcular los deltas mentalmente.
• Archivos TikZ complejos conviene ponerlos en cuaderno/figuras/<nombre>.tex y hacer \input{figuras/<nombre>.tex} desde el entry, en lugar de embeberlos inline. Mantiene el entry legible y permite reutilizar el flowchart en beamer.
• Colores para TikZ en el cuaderno: definir thesisblue (#2C4770) y thesisterra (#C0614A) en el preamble de main.tex con \definecolor{...}{HTML}{...}, para matchear la paleta Python de plot_utils.py.

Workflow de polish narrativo para entries largas

• Entries de mas de 4000 palabras (1.5x la referencia del 03 de abril) tienden a acumular mega-parrafos, roadmaps duplicados, spoilers premature, y bullet-paragraphs disfrazados. Para pulirlas sin over-edit, usar un equipo de agentes: 2 proposers paralelos (uno flow + transiciones, otro verbosity + voice), 1 auditor sintetizador que flagea GREEN/YELLOW/RED, y un gate humano que decide que aplicar. Finalmente un executor y un post-exec auditor.
• El gate humano es critico para prevenir que los agentes reescriban de mas. Reglas del gate: aprobar todos los GREEN, revisar los YELLOW uno por uno, skip los RED salvo que algo parezca valioso.

Flujo de trabajo

1. Recoger contexto: git log desde cuaderno/.last_entry_hash, archivos modificados en src/, plots nuevos en src/plots/, y lo que el usuario diga al invocar el skill. Si no existe .last_entry_hash, mirar los ultimos 7 dias.

2. Evaluar relevancia: Hay material para una entrada? Si solo hubo cambios triviales y el usuario no agrega contexto, preguntar antes de generar: "No veo material suficiente para una entrada del cuaderno. Hay algo que quieras registrar que no este en los commits?"

3. Generar borrador: Siguiendo el template, las reglas de extension y los criterios de relevancia. Incluir solo secciones con contenido.

4. Auto-auditoria del borrador (antes del preview): correr este checklist y corregir cualquier fallo. Si fallan mas de 3 items, replantear la estructura global en vez de parche por parche.

   • Citas: escanear el borrador por patrones de texto plano Author YYYY o Author et al. YYYY y convertir todo a \cite{clave} con claves verificadas en bibliografia/refs.bib.
   • Voz pasiva: grep por "Se implement", "Se detect", "Se observ", "Se calcul", "Se obtuvo". Cero ocurrencias.
   • Subparagraphs numerados: grep por subparagraph{Paso, subparagraph{Etapa, subparagraph{Fase. Cero ocurrencias.
   • Sub-sub-labels prohibidos: grep por \emph{(a), \emph{(b), \emph{(c), \emph{(d) como sub-labels, y por patrones \emph{Titulo breve.} al comienzo de parrafo. Cero ocurrencias.
   • Listas en contextos descriptivos: si hay itemize/enumerate fuera de "Preguntas abiertas", "Proximos pasos", "Decisiones pendientes", "Opciones", "Limitaciones", revisar si deberia ser prosa.
   • Pensamiento expuesto: la entrada contiene al menos 2-3 marcadores conversacionales ("Lo primero que mire...", "Un dato que me llamo la atencion...", "No tengo claro...", "Me pregunte...", "?`Por que...?"). Si cero, el tono es reportador.
   • Prueba del hilo (manual, no se delega a grep): antes del preview, parafrasear el arco narrativo en 3-4 oraciones. Si cuesta, hay problema de conexion entre subparagraphs o sobra contenido.
   • Proporcionalidad: la extension cae en el rango esperado de la tabla de "Regla de proporcionalidad". Si se excede, validar que cada seccion justifica su espacio.
   • Figuras vs. prosa: cada figura referenciada tiene al menos 2-3 oraciones de interpretacion en el texto, no solo un caption + "La Figura X muestra Y".
   • Figuras atomicas: grep por \begin{figure} seguido de mas de un \includegraphics. Cada \begin{figure} debe tener exactamente un \includegraphics.
   • Placement segun densidad: contar \begin{figure} dentro de cada \subparagraph. Si son <=4, placement [!ht] y figura adyacente al parrafo que la referencia. Si son >4, dividir la prosa en sub-bloques conceptuales y agrupar 2-3 figuras al final de cada sub-bloque con [htbp] (ver regla de agrupamiento).
   • Objetivo y metodo explicitos: cada \subparagraph abre declarando QUE se investiga y COMO se aborda antes de mostrar resultados.
   • Dimension de porcentajes: buscar porcentajes ("51.7\%", "60.5\%") y verificar que el texto adyacente aclara si se computan sobre POSTS o sobre CUENTAS.
   • Proximos pasos estrategicos: los items del \paragraph{Proximos pasos} son features / consultas / analisis, no fixes de regex o correcciones de una linea.
   • Codigo ausente: cero snippets en el .tex. Solo \texttt{@src/...} como referencia a archivos.

5. MOSTRAR PREVIEW: Imprimir la entrada completa. Preguntar "Guardamos esta entrada? Queres modificar algo?". NUNCA guardar sin confirmacion explicita del usuario.

6. Al confirmar:

   • Guardar en cuaderno/entradas/YYYY-MM-DD.tex. Si el archivo ya existe (segunda entrada del mismo dia), appendear al final con \bigskip SIN repetir \subsection ni \label.
   • Agregar \input{entradas/YYYY-MM-DD.tex} antes de % === NUEVA ENTRADA AQUI === en cuaderno/main.tex (verificar que no este duplicado).
   • Escribir la fecha en cuaderno/.last_entry_date.
   • Escribir el hash de HEAD en cuaderno/.last_entry_hash.

7. Compilar PDF: Ejecutar cd cuaderno && latexmk -pdf -interaction=nonstopmode main.tex para regenerar el PDF. Si la compilacion falla, avisar al usuario pero no revertir los cambios en los archivos .tex. Nota: hay un hook PostToolUse que compila automaticamente, pero este paso sirve como respaldo.

8. Ofrecer commit: Preguntar "Hacemos commit de la entrada y el PDF actualizado?". Si el usuario acepta, ejecutar:

   git add cuaderno/entradas/YYYY-MM-DD.tex cuaderno/main.tex cuaderno/main.pdf cuaderno/.last_entry_date cuaderno/.last_entry_hash
   git commit -m "Add cuaderno entry for YYYY-MM-DD"
   

   Respetar las convenciones de commit del proyecto: ingles, imperativo. No commitear sin confirmacion explicita.