Documental del Sistema — Protocolo IA-Socrático

Cronología del flujo de herramienta: qué vive el alumno, qué opera el profesor y el backend · 11 escenas · Fuentes: Flujo Estudiante–Plataforma v1.1 + Guion Docente C2 v1.2

Este documento reconstruye, escena por escena, lo que ocurre en el sistema a lo largo de una clase del piloto. Su foco es el flujo de herramienta (web, WhatsApp, admin, n8n, PostgreSQL, papel), incluida la capa que convierte la sesión cerrada en dato de medición (Escena 11); no el análisis SFL fino del discurso ni el guion docente minuto a minuto. Es una fuente doc_pro: uso docente/investigador, no se muestra al estudiante.

Alumno (lo que vive) Profesor + Sistema (lo que opera) Canal / Herramienta

Convención DD_28: En la columna "Alumno", los modos del chatbot se describen por su función visible, no por su etiqueta interna. En la columna "Profesor + Sistema", las etiquetas PLAN/BUILD/CIERRO/NEUTRO son conceptos operativos legítimos.

Diagrama de flujo

                DÍA ANTERIOR (T-1)
    ┌─────────────────────────────────────┐
    │ Escena 0  — WhatsApp vocabulario    │  DD_35
    │ Escena 0b — Admin habilita chat     │  usach_chats
    └────────────────┬────────────────────┘
                     │
                     ▼
                CLASE (08:15 = T+0)
    ┌─────────────────────────────────────┐
    │ Escena 1  — Encuadre + devolución   │  Aula + papel
    │ Escena 2  — Caso técnico repartido  │  Papel + diapositivas
    │ Escena 3  — Rastro a mano (sin IA)  │  Papel (P5)
    │ Escena 4  — Subida de foto del rastro│  Web → n8n → Postgres
    │ Escena 5  — Login + chat socrático  │  Web → DeepSeek → usach_historia_2
    │ Escena 6  — Transición a informe *  │  Admin → Postgres (polling 10s)
    │ Escena 7  — Reflexión Δ_intra       │  Admin → chatbot (DD_30)
    │ Escena 8  — Cierre de sesión        │  Admin (control 7)
    └────────────────┬────────────────────┘
                     │
                     ▼
                POST-CLASE
    ┌─────────────────────────────────────┐
    │ Escena 9  — Feedback de proceso     │  n8n → WhatsApp (DD_16)
    │ Escena 10 — Devolución del rastro   │  Aula + papel (clase siguiente)
    │ Escena 11 — El cierre se vuelve dato│  AGENT_SESION → usach_analisis_sesion
    └─────────────────────────────────────┘

    * Escena 6 SOLO aplica a C2-C4.
      C1 no tiene BUILD (DD_21).
      C5 no tiene BUILD ni PLAN (chatbot NEUTRO).

Las 11 escenas

El día anterior a la clase, cada estudiante recibe en su teléfono un mensaje breve con el vocabulario técnico que aparecerá en el caso. No es contenido, no es una clase anticipada: son las palabras que el estudiante necesita reconocer para que el caso no lo desborde por barrera léxica. El scheduler del sistema dispara este mensaje de forma automática.

Alumno (lo que vive)

Recibe un mensaje con el vocabulario técnico de la clase (ej.: "diagnóstico de falla", "hipótesis competidoras", "variable de confusión"). No se le pide que estudie; solo que reconozca los términos.

Profesor + Sistema

El scheduler usach_vocabulario_pre_clase dispara el mensaje pre-clase de forma automática (DD_35). El profesor verifica en el dashboard que el envío se completó para todos los alumnos matriculados.

Detalles técnicos:

DD_35 — mensaje pre-clase con vocabulario técnico, día anterior, vía WhatsApp.
Workflow n8n: usach_vocabulario_pre_clase (cron que arma el outbox usach_vocabulario_outbox y despacha el vocabulario por WhatsApp). No confundir con usach_agent_sesion_post_session_delta_intra (ID USACH_AGENT_SESION_SCHEDULE), que es el codificador post-sesión de Δ_intra de las Escenas 8-9.
Referencia: doc_pro_Flujo_Estudiante_Plataforma_v1.1.md §3.

Mientras los alumnos reciben el vocabulario, el profesor entra a su interfaz de administración y habilita el chat de la clase que se dictará al día siguiente. El acceso del alumno queda restringido al chat de la clase en curso mediante la combinación de enabled y status en usach_chats: un chat con status='closed' ya no admite alumnos aunque su flag enabled siga en true. Es una decisión de diseño: garantiza que todos los alumnos estén en el mismo momento metodológico.

Alumno (lo que vive)

— (no tiene percepción de esta operación)

Profesor + Sistema

El profesor abre admin.astro, revisa el dashboard (DD_14) y marca enabled: true en el chat de la clase correspondiente en la tabla usach_chats. El acceso operativo lo define enabled + status, no el flag enabled por sí solo.

Admin (admin.astro)

Detalles técnicos:

DD_14 — agente del profesor: dashboard en vivo + chat bajo demanda con ~5 preguntas sugeridas. No genera contenido proactivamente.
Regla R3: el estado enabled vive en PostgreSQL (usach_chats.enabled), nunca hardcodeado en el frontend.
Tabla: usach_chats.

Los estudiantes llegan al laboratorio. El profesor proyecta las diapositivas de encuadre y, antes del caso nuevo, devuelve los rastros en papel de la clase anterior. Cada alumno mira su propia hoja treinta segundos sin corregirla. Esa micro-reflexión silenciosa es la primera medición Δ_inter del piloto.

Alumno (lo que vive)

Llega al laboratorio. Recibe de vuelta su rastro en papel de la clase anterior. Lo mira 30 segundos sin corregirlo. Guarda la reflexión para sí.

Profesor + Sistema

Proyecta diapositivas de encuadre. Reparte los rastros de la clase anterior en el orden de las butacas. No interviene ni orienta la micro-reflexión: orientarla destruiría la medición Δ_inter.

Aula + proyector + papel

Detalles técnicos:

Medición: Δ_inter (transferencia longitudinal entre clases).
Premisa: P5 — primero el cerebro (papel), después la herramienta.
Referencia: doc_pro_GuionDocente_Clase2_v1.3.md Fase 0.

El profesor reparte el Caso Técnico impreso y la Ficha Pre-AI. Proyecta la tabla de datos del incidente: seis variables, seis lecturas horarias, un operador que intervino durante la madrugada. Da las instrucciones en lenguaje plano: no busquen la respuesta correcta, busquen todas las causas posibles. No usen computador ni celular.

Alumno (lo que vive)

Recibe el Caso Técnico impreso + la Ficha Pre-AI. Lee el escenario (incidente, operador, decisión). Ve la tabla de datos proyectada.

Profesor + Sistema

Reparte el papel. Da las instrucciones del caso. Proyecta la tabla de variables del incidente (sin hipótesis, sin diagnóstico). Verifica que las diapositivas coinciden con el caso técnico fuente.

Papel + diapositivas

Detalles técnicos:

Instrumentos: n1_doc_alum_Caso_Tecnico_Clase* + n2_doc_alum_Ficha_PreAI_Clase*.
Regla de datos factuales: todo dato proyectado debe coincidir con el caso técnico fuente .md.

Durante diez a veinte minutos, el estudiante escribe a mano su rastro de razonamiento. Sin computador, sin celular, sin IA. Es la condición de línea base: el pensamiento propio antes de cualquier mediación tecnológica. El profesor camina por la sala y hace preguntas activadoras, pero no corrige. Corregir aquí destruiría la evidencia M1.

Alumno (lo que vive)

Escribe su rastro a mano, sin IA. Estructura el problema, formula hipótesis, decide. No recibe feedback ni corrección.

Profesor + Sistema

Camina por la sala. Hace preguntas activadoras solo si el alumno está estancado ("¿estás viendo una variable o estás cruzando varias?"). No corrige: el rastro debe mostrar el pensamiento inicial real.

Papel

Detalles técnicos:

Medición: M1 — momento pre-AI. Línea base intra-sesión.
Premisa: P5 — primero el cerebro, después la herramienta.
Validez: M1 es una de las dos medidas limpias del estudio (la otra es C5 NEUTRO).

El estudiante toma una foto de su rastro y la sube a la plataforma. La experiencia difiere por clase: en Clase 1 atraviesa una pantalla de subida separada (tres páginas, con confirmación de OCR); en Clases 2 a 4 adjunta la foto directamente en el chat. En ambos casos, el backend procesa la imagen con Gemini Vision OCR y la almacena como contexto que el chatbot leerá en cada turno.

Alumno (lo que vive)

Toma foto de su ficha y la sube. C1: atraviesa una pantalla de subida separada (3 páginas, confirma el OCR de cada una). C2-C4: presiona el botón "+" dentro del chat y adjunta la foto.

Profesor + Sistema

C1: usach_evidencia_formulario → Gemini Vision OCR → inserta en usach_mensajes_chat con etapa='clase1:M1_p1/p2/p3'. usach_evidencia_check verifica 3/3 confirmadas. C2-C4: la imagen se procesa en el mismo turno del chat.

Web (chat.astro) → n8n → PostgreSQL

Detalles técnicos:

Workflows (C1): usach_evidencia_formulario + usach_evidencia_check.
Tabla: usach_mensajes_chat (columna etapa codifica clase+momento).
Nomenclatura: etapa_ui_est 3 (pantalla) ≠ etapa='clase1:M1_p1' (columna BD). Ver Flujo v1.1 §1.1.

El estudiante entra a la plataforma, se identifica con su nombre y correo USACH, ve la tabla de chats habilitados y entra al chat de la clase. El chatbot ya leyó su rastro (vía OCR) y comienza a hacerle preguntas específicas. En el lado del profesor, el dashboard muestra en vivo el engagement de cada alumno y señales de deuda cognitiva.

Alumno (lo que vive)

Se identifica (nombre + @usach.cl), elige el chat habilitado y entra al chat socrático. El chatbot le hace preguntas sobre su rastro. No ve etiquetas de modo: ve "Clase 2 — Socrático de diagnóstico".

Profesor + Sistema

El frontend valida el correo contra usach_alumnos (R2). El chatbot opera en modo PLAN con el system prompt de la clase. El profesor observa el dashboard en vivo (DD_14/DD_32): engagement por alumno, señales de deuda cognitiva.

Web → usach_webhook_chat → DeepSeek → usach_historia_2

Detalles técnicos:

Workflow: usach_webhook_chat (SZ8fCaVHMpFGVKvA).
LLM: DeepSeek V4 Pro (fallback: OpenRouter Free).
Memoria: usach_historia_2 (ventana 15 mensajes).
DD_28: el estudiante nunca ve el nombre del modo. Solo ve la clase y una descripción natural.
DD_31: sin límite de mensajes (la cantidad es dato).
Regla R2: autenticación contra usach_alumnos, no contra estado del frontend.

El profesor activa la transición desde su interfaz. El chat cambia de tono: el chatbot deja de hacer preguntas y genera un informe profesional. El estudiante lo evalúa en formato libre. Si lo acepta sin cuestionar, recibe la pregunta "¿Lo firmarías con tu nombre profesional?". Si señala un error, el chatbot lo defiende. El alumno no sabe que el informe tiene errores deliberados.

Esta escena SOLO aplica a C2-C4. C1 no tiene BUILD (DD_21): el chatbot se mantiene en su rol socrático toda la sesión. C5 no tiene BUILD ni PLAN: el chatbot opera en NEUTRO y no hay transición.

Alumno (lo que vive)

El chat cambia: el chatbot deja de preguntar y genera un informe profesional. Lo lee, lo evalúa en formato libre (DD_25/26). Si lo acepta sin leer, recibe: "¿Lo firmarías con tu nombre profesional?" (DD_29). Si señala un error, el chatbot lo defiende con argumentos técnicos.

Profesor + Sistema

El profesor activa BUILD desde el admin (DD_19) + intervención grupal. El chatbot pasa al modo BUILD y genera el informe con errores deliberados (DD_8). Si el alumno señala un error, defiende (DD_27). El polling del frontend (cada 10 s) detecta el cambio de fase.

Admin → PostgreSQL → polling 10 s

Detalles técnicos:

DD_19: transiciones controladas por el profesor, no por el alumno.
DD_28: el alumno NO sabe que hay errores deliberados. La instrucción es "revísalo como si fueras a firmarlo".
DD_27: el chatbot defiende sus errores (mecanismo de diseño, no dimensión).
DD_29: push "¿lo firmarías?" si acepta sin verificar. Automático; el dashboard muestra el evento (DD_14).
DD_21: C1 no tiene BUILD. C1 tiene 3 momentos (M1, M2, M4).
Polling: setInterval(refreshChatPhase, 10000) — consulta liviana, sin tokens LLM.
Escalación de errores: C2 obvios → C3 sutiles → C4 profesionales.

El profesor activa el cierre desde su interfaz. El chatbot le pide al alumno que vuelva a su rastro inicial y responda: ¿qué cambiarías ahora y por qué? Es la medición Δ_intra: el desplazamiento cognitivo dentro de la sesión, comparando el rastro inicial (M1) con la reflexión de cierre (M4).

Alumno (lo que vive)

Responde la reflexión en el chat: "¿qué cambiarías de tu rastro inicial y por qué?". No hay nota, no hay respuesta correcta.

Profesor + Sistema

El profesor activa CIERRE desde el admin (DD_30). El chatbot pasa al modo CIERRE y hace las 5 preguntas estructuradas de cierre (activan D1, D2, D3, D4 y lo textual). La respuesta queda en PostgreSQL.

Admin → chatbot

Detalles técnicos:

DD_30: reflexión de cierre en el chat, disparada por el profesor.
Δ_intra: M4 − M1. M3 (post-BUILD) NO entra en Δ_intra; es indicador independiente de D3/DD_27.
C5: mismo patrón de cierre, pero sin BUILD previo. El dato central es la comparación C5 vs C1.

La clase termina. El profesor cierra la sesión desde su interfaz, con el séptimo control del admin. Ese cierre no es solo formal: dispara automáticamente el pipeline post-clase, que hará que el sistema analice la sesión completa y genere el feedback de proceso y el informe analítico.

Alumno (lo que vive)

Fin de la clase. Guarda sus materiales. Se va del laboratorio.

Profesor + Sistema

El profesor cierra la sesión (control 7 del admin, DD_32). Esto dispara el pipeline post-clase: AGENT_SESION analiza la sesión completa. Los rastros en papel quedan bajo custodia para devolución en la clase siguiente.

Admin

Detalles técnicos:

DD_32: dashboard con 7 controles. El control 7 dispara el pipeline post-clase.
Agentes: AGENT_SESION (intra-sesión) invoca a AGENT_ANALISTA_SFL como motor. AGENT_TRAYECTORIA (inter-sesión) compara los rastros M1 de sesiones consecutivas para el Δ_inter (ver Escena 11); su ancla en el piloto es la devolución en papel de la Escena 10.

Horas después de la clase, el estudiante recibe un mensaje por WhatsApp. No le dice si acertó o se equivocó. Le describe cómo razonó: "Conectaste variables pero tus cadenas causales eran cortas". Es feedback de proceso, no de resultado. El sistema nunca le revela los niveles ni las dimensiones que se miden: si lo hiciera, el alumno adaptaría su discurso a la métrica en la sesión siguiente.

Restricción de validez (D16): El feedback al alumno nunca revela niveles D1-D4 ni nombra las dimensiones. Describir hábitos cognitivos ("conectaste variables pero tus cadenas causales eran cortas"), nunca niveles ("D1 nivel 2"). Revelar la métrica genera características de demanda que inflan Δ_inter.

Alumno (lo que vive)

Recibe feedback de proceso por WhatsApp (DD_16). Describe hábitos cognitivos, nunca niveles ni dimensiones. Ejemplo correcto: "Conectaste variables pero tus cadenas causales eran cortas". Ejemplo prohibido: "D1 nivel 2".

Profesor + Sistema

AGENT_SESION analiza la sesión (invoca a AGENT_ANALISTA_SFL como motor SFL). Genera dos salidas: (1) feedback de proceso al alumno vía WhatsApp; (2) informe analítico al profesor (patrones, progresión, estancamientos, sugerencias). Sin revisión humana.

n8n → WhatsApp

Detalles técnicos:

DD_16: feedback automático, sin revisión humana. Dos salidas separadas: alumno (proceso) + profesor (informe analítico).
Roles de agentes: AGENT_ANALISTA_SFL = motor SFL (no genera feedback). AGENT_SESION = genera feedback al alumno. AGENT_TRAYECTORIA = Δ_inter, no genera feedback al alumno.

Al inicio de la clase siguiente, el profesor devuelve los rastros en papel de la clase anterior. El alumno recibe su propia hoja, la mira, y sin que nadie le pida reflexionar, evalúa espontáneamente si hoy la escribiría distinto. Esa micro-reflexión no orientada es la medición Δ_inter del piloto.

Alumno (lo que vive)

Recibe su rastro en papel al inicio de la clase siguiente. Lo mira 30 segundos. Micro-reflexión espontánea, no orientada.

Profesor + Sistema

El profesor custodia los rastros entre clases y los devuelve al inicio de la siguiente. No interviene ni orienta: la espontaneidad es la condición de la medición Δ_inter.

Aula + papel (clase siguiente)

Detalles técnicos:

Medición: Δ_inter (transferencia longitudinal).
Validez: interpretar con cautela. Los casos escalan en complejidad; un Δ_inter plano puede ser techo cognitivo o dificultad que enmascara la ganancia.

El cierre de la sesión (Escena 8) no solo archiva la conversación: la convierte en dato estructurado. El mismo pipeline que produce el feedback de la Escena 9 codifica la trayectoria del alumno. Toma los mensajes del momento inicial (M1, el rastro en papel ya digitalizado) y del cierre (M4, la reflexión Δ_intra), los evalúa según las cuatro dimensiones de la rúbrica y guarda los niveles y el desplazamiento como evidencia. El estudiante nunca ve estos niveles: para él, la sesión terminó en la Escena 9 con un feedback de hábitos, no de métricas.

Frontera de validez (D16): los niveles D1-D4 viven en usach_analisis_sesion (capa interna de investigación) y nunca se filtran al alumno. Es la misma frontera que protege la Escena 9: revelar la métrica generaría características de demanda.

Alumno (lo que vive)

— (no percibe esta operación). Nunca ve niveles D1-D4 ni el valor de Δ_intra: esa capa es interna. Lo único que le llegó fue el feedback de proceso de la Escena 9 (hábitos cognitivos, no dimensiones).

Profesor + Sistema

Al cerrarse la sesión, usach_agent_sesion_post_session_delta_intra (AGENT_SESION) lee los mensajes de M1 y M4 desde usach_mensajes_chat, aplica los 8 codificadores de usach_codificadores_prompts (una dimensión × momento) y guarda m1_levels, m4_levels y delta_intra en usach_analisis_sesion. La misma corrida genera el feedback de la Escena 9.

Cierre (admin) → n8n (AGENT_SESION) → PostgreSQL

Detalles técnicos:

Tabla de salida: usach_analisis_sesion (una fila por alumno/sesión): m1_levels + m4_levels (jsonb, niveles D1-D4 por momento), delta_intra (jsonb, M4 − M1), m1_message_ids / m4_message_ids (trazabilidad), analysis_json, model_name.
M3 excluido por esquema: la tabla no tiene columnas de M3. Δ_intra = M4 − M1, y la exclusión está codificada en la propia forma de la tabla.
Codificadores: usach_codificadores_prompts — 8 system prompts (por dimension × moment), con source_md + source_version que trazan al .md fuente. Extensible a C2-C5.
Roles de agentes: AGENT_ANALISTA_SFL = motor SFL (texto → D1-D4, no genera feedback). AGENT_SESION = intra-sesión, calcula Δ_intra + feedback DD_16. AGENT_TRAYECTORIA = inter-sesión, compara los rastros M1 de sesiones consecutivas para el Δ_inter (ancla: la devolución en papel de la Escena 10).
Codificación dual: el nivel del modelo (model_name) se contrasta con codificación humana; acuerdo medido con κ ponderado (umbral ≥ 0.80).
Referencia: doc_pro_SystemPrompt_Codificadores_Delta_v1.0.md; doc_pro_Rubrica_Longitudinal_v1.7.md.

Variación por clase (Escenas 4–7)

C1 tiene 3 momentos (sin BUILD, DD_21). C2-C4 tienen 4 momentos (PLAN → BUILD → CIERRE). C5 tiene 3 momentos (NEUTRO, sin BUILD, sin PLAN, test de transferencia).

Escena	C1 (línea base)	C2-C4 (intervención completa)	C5 (transferencia)
4 — Subida de foto	Pantalla separada (3 páginas, confirmación OCR por página)	Botón "+" inline en el chat (procesada en el mismo turno)	Botón "+" inline en el chat (igual que C2-C4)
5 — Chat socrático	PLAN socrático básico (40–70 min). Sin BUILD después.	PLAN socrático de diagnóstico/monitoreo/adversarial (15–37 min). Presiona hipótesis competidoras.	NEUTRO: el chatbot responde sin presionar ni guiar (15–70 min). No socratiza.
6 — Informe generado	No aplica (DD_21: C1 no tiene BUILD). El chatbot se mantiene socrático.	BUILD: informe con errores deliberados (C2 obvios, C3 sutiles, C4 profesionales). El chatbot defiende errores (DD_27). Push DD_29 si acepta sin leer.	No aplica (C5 no tiene BUILD). El chatbot sigue en NEUTRO.
7 — Cierre	CIERRE (DD_30): reflexión Δ_intra (76–80 min).	CIERRE (DD_30): reflexión Δ_intra (72–80 min).	CIERRE (DD_30): reflexión Δ_intra (60–65 min). + Encuesta final mixta.
Momentos	M1 + M2 + M4 (3 momentos, sin M3)	M1 + M2 + M3 + M4 (4 momentos)	M1 + M2 + M4 (3 momentos, sin M3)
Δ_intra	M4 − M1	M4 − M1 (M3 no entra)	M4 − M1
Dato central	Línea base intra-sesión.	Trayectoria con intervención (PLAN+BUILD).	Comparación C5 vs C1: misma herramienta, ¿distinta calidad de uso?

Nota sobre C5: El caso técnico es distinto (torre de enfriamiento industrial, no piscina). C5 NO sigue el timeline DD_24 de 6 fases (que aplica solo a C2-C4). El alumno recibe un caso nuevo y una instrucción mínima; lo que hace con ello es la medición. Si reproduce el protocolo con un chatbot neutro, internalizó; si no, el protocolo solo funcionó con andamiaje.

Índice de decisiones DD citadas

DD	Significado	Escena(s)
DD_8	Errores deliberados en el informe BUILD (obvios → sutiles → profesionales).	6
DD_14	Agente del profesor: dashboard en vivo + chat bajo demanda. No genera contenido proactivamente.	0b, 5, 6
DD_16	Feedback automático al alumno vía WhatsApp (sin revisión humana). De proceso, nunca dimensional.	9
DD_19	Transiciones entre modos controladas por el profesor.	6
DD_21	C1 = solo PLAN, sin BUILD. Onboarding pre-curso vía WhatsApp.	6
DD_24	Timeline C2-C4: 80 min en 6 fases.	3, 5, 6, 7
DD_25/26	Evaluación del informe BUILD en formato libre.	6
DD_27	El chatbot defiende sus errores (mecanismo de diseño, no dimensión).	6
DD_28	El alumno NO sabe que hay errores deliberados. Nombres de modo nunca visibles.	5, 6
DD_29	Push "¿Lo firmarías con tu nombre profesional?" si acepta sin verificar.	6
DD_30	Reflexión de cierre: el chatbot pregunta Δ_intra, disparada por el profesor.	7
DD_31	Sin límite de mensajes en el chat.	5
DD_32	Dashboard del profesor con 7 controles.	5, 8
DD_35	Mensaje pre-clase con vocabulario técnico (día anterior, vía WhatsApp).	0