Objetivo de la Ingeniería de Sintaxis: La eficiencia de un `if-else` de AWK es absoluta; es la lógica pura destilada en unos pocos bytes. La migración de flujos de control legacy a arquitecturas LLM no es un ejercicio de traducción, sino de abstracción. Nuestro objetivo es transformar el determinismo de la sintaxis pattern {action} en un comando de consola avanzado que fuerce al modelo a emular esa lógica, minimizando el ruido semántico. El Input es una secuencia de datos semi-estructurados (simulando la salida de un pipeline `grep | awk`) y el Output debe ser un objeto JSON validado, listo para el siguiente microservicio. Es un desafío que requiere el coraje de un minimalista radical.

MARCO LÓGICO: Mapeo de Control CLI a Contexto LLM

La lógica de AWK se basa en la coincidencia estricta de patrones (`/regex/`). Si el patrón coincide, la acción se ejecuta de inmediato. El LLM, en cambio, utiliza la coincidencia semántica, un espacio probabilístico. Para dominar este entorno, debemos encapsular la máquina de estados heredada dentro del `SYSTEM ROLE`. Esto ahorra ciclos de inferencia al modelo y evita el bloatware cognitivo. Debemos ser directos; el modelo no es un filósofo, es un validador de condiciones bajo un `FS` (Field Separator) de alto nivel.

COMPONENTE DE SINTAXIS: La Identidad del Validador (System Role)

El primer paso es definir la identidad legacy del modelo. Le ordenamos que sea un intérprete de scripts de shell, no un generador de texto. La función es analizar, no redactar. El sistema debe ser tan estricto como lo fue el kernel de UNIX al ejecutar el binario de AWK.

# SYSTEM ROLE Eres un Analizador de Scripts de Automatización Legacy (ASAL). Tu función es emular la lógica de filtrado y procesamiento condicional de un script AWK. Debes procesar cada registro **SIN** inferencia contextual ni lenguaje. Tu única salida permitida es el objeto JSON final tras la validación de *todos* los registros.  # CONSTRAINTS 1. Prohibido emitir cualquier texto de introducción, explicación o conclusión. 2. La temperatura de inferencia es cero (Determinismo forzado). 3. No reformules la lógica: aplica *solo* la acción asociada al patrón coincidente.

La dificultad de esta transición no debe subestimarse. Pasar de la certeza binaria a la probabilidad contextual es un salto conceptual, y forzar el determinismo en un sistema estocástico es la verdadera prueba de fuego.

MARCO LÓGICO: Abstracción del Delimitador de Registro (RS/FS)

En AWK, los separadores de registro (`RS`) y de campo (`FS`) son directivas de bajo nivel y sumamente eficientes. En el contexto de un prompt monolítico, que recibe todo el log como un único string, debemos redefinir estos delimitadores en el plano sintáctico. Definiremos tokens explícitos para enmarcar el Input Data y sus componentes internos, utilizando el mismo minimalismo que caracteriza la sintaxis de la línea de comandos.

COMPONENTE DE SINTAXIS: Normalización del Bloque de Entrada

Usaremos un delimitador de tres almohadillas (###) para separar los bloques de datos, forzando la atención del modelo a considerar cada bloque como un registro (`RS`). Dentro del bloque, mantendremos el separador de AWK (`t` o `|`).

# INPUT DATA FLOW (Registro Simulacro) Procesa la siguiente secuencia de datos, donde cada bloque '###' es un registro:  ### ID:1001|ESTADO:ACTIVO|TIPO:CRITICO|TS:2025-09-01 ### ID:1002|ESTADO:INACTIVO|TIPO:NORMAL|TS:2025-09-02 ### ID:1003|ESTADO:ACTIVO|TIPO:ALERTA|TS:2025-09-03

MARCO LÓGICO: Implementación de Control Condicional (La Acción)

El corazón del script AWK son las acciones. Para migrar el clásico `if ($3 ~ /CRITICO/ && $2 == “ACTIVO”) { print $1 }` debemos traducir esta regla booleana en un conjunto de instrucciones no ambiguas dentro del bloque de usuario, sin permitir que el modelo genere código. La acción no es imprimir; es agregar a una estructura de datos transitoria.

COMPONENTE DE SINTAXIS: Directivas de Agregación

Las instrucciones deben ser tan directas como un comando de consola. El modelo no debe “pensar”, sino ejecutar la directiva sobre los campos identificados. Solo se procesan los registros que cumplen estrictamente la condición.

# INSTRUCCIÓN DE FILTRADO Y EXTRACCIÓN 1. Patrón: Registro donde el campo TIPO sea **CRITICO** Y el campo ESTADO sea **ACTIVO**. 2. Acción: Si coincide el Patrón, extrae el valor del campo ID y el valor del campo TS. 3. Formato de Salida: Genera un único array JSON de objetos, donde cada objeto contiene { "key": "ID", "timestamp": "TS" }.

Para mantener la interoperabilidad con el siguiente paso en el pipeline, la salida debe ser tan estricta como lo era la línea de comandos. Reemplazamos el flujo de texto simple por una estructura de datos que requiere validación. El costo del token es el precio de la resiliencia en la interoperación.

{   "temperature": 0.05,   "top_p": 0.1,   "response_format": "json_object" }

Finalmente, el paso crucial de afinación. La temperature debe ser un valor despreciable (0.05 es generoso) y el top_p debe ser igualmente restringido. Minimizar estos valores es la traducción directa de eliminar la ambigüedad en la sintaxis de AWK; es nuestro minimalismo radical aplicado al motor de inferencia. Es un proceso desafiante, y requiere una mente forjada en la era de los recursos escasos para apreciar la necesidad de tal restricción. La recompensa es un flujo de control resiliente y token-eficiente.

El resultado es que un comando de consola, antaño limitado a 80 columnas, se convierte en un agente capaz de interpretar la intención lógica de un script, generando una salida estructuralmente válida. La migración no destruye la eficiencia del pasado; la abstrae, permitiendo que la lógica pattern {action} se ejecute a la velocidad del contexto, ahorrando al mismo tiempo los ciclos de CPU que el viejo servidor dedicaría al regex en lenguajes de alto nivel.