Skill: NONE | Type: design
Summary: EPISODIO 10 — CONCILIO: 🔎 [R4.§1] Los 3 reales — su función del día que nacieron
3.1 KiB
| episode_id | puente_flat | session_code | acto_dialogico | actor_flujo | criticidad_aegis | skill_dominante | fase_proyecto | tipo_semantico | summary_one_line | source_type | trust_boundary | created_at | relectura_tagged | forgejo_commit_sha |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 3f05a460-efef-4625-9691-30bcba4a33bd | TRAZA_r41-los-3-reales-su-funcin-del-da-que_S20260601.R10_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD | S20260601.AGENTES_NATIVOS_ACTIVACION | informar | multi_actor | low | NONE | operations | design | EPISODIO 10 — CONCILIO: 🔎 [R4.§1] Los 3 reales — su función del día que nacieron | claude_code | internal | 2026-06-02T17:45:05.525798+00:00 | false | pending |
No te equivocas, John — los nombres dicen mucho, y tu lectura de los tres del "plan fantasma" es muy buena. Te recuerdo los tres reales (leídos de su CLAUDE.md del día que nacieron), y de paso te confirmo lo que entendí de los otros tres.
Antes, una nota honesta de enrutamiento (PROCEDENCIA): el sistema marcó esto como D-ARCH y quiere convocar el panel CONCILIO de 13 skills + 2 documentos. Tiene razón en que el roster del pipeline ES una decisión D-ARCH — pero estamos en pleno diálogo de diseño: tú me estás dictando la arquitectura ahora mismo. El CONSEJO + DECISION los escribo cuando cerremos el roster, justo antes de fabricar (ahí aportan), no para recordarte qué hace un agente. Este turno es recordatorio factual + captura de tu visión. Lo declaro para que quede auditable.
🔎 [R4.§1] Los 3 reales — su función del día que nacieron
🟦 code-explorer — el SCOUT (lente: "¿cómo está hecho y de qué depende?")
Entra primero a un código que no conocemos y dibuja el mapa, sin tocar nada (read-only). Hace tres cosas: lee con Glob/Grep/Read, hace análisis AST (ver el código como un árbol: funciones, clases, ramas) y mapea dependencias (quién llama a quién). Luego le pasa el mapa a code-architect (para planear), a code-rescuer (para un bug) o a code-modernizer (para migrar). Es el explorador de avanzada.
🟩 code-modernizer — el RESTAURADOR (lente: "¿cómo traigo esto al presente sin romper lo que hacía?")
Agarra código viejo (legacy) y lo lleva a un stack moderno, pero con dos seguros: behavior-equivalence tests (pruebas que garantizan que lo nuevo se comporta idéntico a lo viejo) y business rules extraction (extrae las reglas de negocio escondidas en el código viejo antes de reescribir, para no perderlas). Migra sin amnesia.
🟪 code-architect-critic — el ABOGADO DEL DIABLO DEL PLANO (Capa 4, lente: "¿esto está sobre-diseñado? ¿hay forma más simple? ¿qué olvidamos?")
Revisa el plan de arquitectura antes de que se escriba una línea. Caza over-engineering (complicar de más), requisitos olvidados y propone alternativas más simples. Usa PROBATOR. Ojo, esto es clave para tu visión: es distinto de code-reviewer — el reviewer critica el código ya escrito; el critic critica el plan. Dos lentes adversariales en dos momentos distintos.