PTENES
Saltar al contenido
MÓDULO 4.4

🧪 Laboratorio y proyecto final

Primero, el lugar adecuado para la ingeniería inversa: el laboratorio, con fecha y etiqueta. Después, el proyecto final: un sistema tuyo sin API se convierte en un puente, un equipo de tres roles trabaja en él y la verificación demuestra que quedó listo.

6
Temas
~35
Minutos
runtime/
Entregable
Proyecto
Tipo
0 de 60%
1

Vuelve a la escalera antes del laboratorio

Las ganas de "abrir el programa por dentro" aparecen cuando algo parece imposible. Antes de eso, una regla de LEIA-ME.md y del AGENTS.md: sube la escalera y prueba cada nivel con un comando.

El laboratorio es el escalón 7. Solo se llega a él después de que los seis anteriores respondan «no», con evidencia. Muchas veces la vía existe y solo faltaba documentarla.

1 · API 2 · MCP 3 · CLI 4 · SDK 5 · computadora 6 · puente local 7 · ing. inversa laboratorio cada nivel: un comando de prueba detente en la primera vía que funcione

Cómo leer el diagrama: la escalera baja desde el nivel más estable (ámbar) hasta el más frágil. La línea roja discontinua separa los seis peldaños de producción del peldaño 7, que queda solo en el laboratorio.

🎯 Objetivo: tener evidencia de cada nivel antes de pensar en el laboratorio

Abre claude (o codex) en la carpeta del kit y pega, reemplazando el nombre del sistema:

Leia runtime/LEIA-ME.md e suba a escada das vias para o <meu sistema>. Para cada nível, de API até ponte local, diga qual comando ou menu testa esse nível e o que você encontrou. Não conclua "não dá" sem mostrar o teste de cada nível.
Cómo verificar: la respuesta tiene seis niveles, cada uno con una prueba y un resultado. Si algún nivel aparece sin prueba, vuelve a pedir solo ese.
🪜
Escalera

la más alta que exista

🧾
Evidencia

una prueba por nivel

📤
Exportar

casi siempre existe

🧪
Nivel 7

solo después de los seis

2

Trata la ingeniería inversa como un laboratorio

A POLITICA.md indica en una línea: la ingeniería inversa es un laboratorio: anota en LIMITES.md y no lo uses en producción. Laboratorio significa una máquina de prueba, datos de prueba y una fecha de vencimiento.

El objetivo del laboratorio es responder una pregunta: «¿por dónde se comunica este programa?». Cuando encuentres la respuesta, vuelve a la escalera y busca la vía oficial que hace lo mismo.

🆕 ¿Eres nuevo aquí? Máquina de prueba y etiqueta «frágil»

Máquina de prueba es una computadora (o máquina virtual) sin tus datos reales ni tus cuentas con sesión iniciada. Si algo sale mal, no se pierde nada de valor. Etiqueta «frágil» es escribir, junto al hallazgo, que podría dejar de funcionar con la próxima actualización y en qué fecha se probó.

1

Separa la máquina

Nada de probar en la computadora de la clínica de Clara ni en el ERP de producción del cliente de Sônia.

2

Anota antes de empezar

Una línea en runtime/LIMITES.md: fecha, qué intentaste, qué lo bloqueó, alternativa y estado.

3

Etiqueta el hallazgo

"Frágil, probado el <data>". Sin fecha, nadie sabe si todavía sirve.

4

Vuelve a la escalera

El hallazgo se convierte en pregunta: "¿existe una exportación, CLI o MCP que haga esto?". La respuesta se incluye en el CAPACIDADES.md; el truco, no.

📄 Ejemplo de fila en el runtime/LIMITES.md (lo que escribiría Sônia)
| data | o que tentei | o que barrou | contorno | status |
|---|---|---|---|---|
| <data> | achar por onde o ERP grava as vendas (máquina de teste, frágil) | sem API nem CLI | exportação CSV de vendas, ponte local (nível 6) | aceito |
Qué revisar: la columna «alternativa» apunta a una vía de la escalera, no al truco del laboratorio.

⚠️ Nunca en producción

Lo que se descubrió mediante ingeniería inversa se rompe con la próxima actualización del programa, sin aviso, y solo quien lo armó sabe cómo repararlo. Si el laboratorio no encontró una vía oficial, el hallazgo se queda en el laboratorio.

3

Respeta los términos de uso y las credenciales

Incluso en el laboratorio se aplican las tres reglas de integración de la POLITICA.md. Protegen tu cuenta, tus datos y tu acuerdo con quien proporciona la herramienta.

El punto más delicado es la credencial. El inicio de sesión de Claude Code es de Claude Code. El de Codex es de Codex. Copiar el token de uno dentro del otro o de un script es exactamente lo que prohíbe la regla.

📄 runtime/POLITICA.md, sección Integración (texto del kit)
- Só ferramentas oficiais pela assinatura (Claude Code, Codex CLI).
- Nunca passe credencial de uma ferramenta para outra.
- Engenharia reversa é laboratório: anote em LIMITES.md e não use em produção.

🆕 ¿Eres nuevo aquí? Credencial y token

Credencial es cualquier cosa que demuestra quién eres: contraseña, clave, cookie de sesión. Token es la credencial que un programa guarda después de iniciar sesión para no volver a pedir la contraseña. Quien tiene el token actúa como tú.

✓ Puede

  • ✓ Claude llama a Codex mediante el puente codex-exec.sh: cada uno con su propio inicio de sesión
  • ✓ Usar el codex login y el inicio de sesión de claude por suscripción
  • ✓ Inicias sesión en el sitio; el agente solo lee la página
  • ✓ Leer los términos de uso antes de automatizar un sitio

✗ No se puede

  • ✗ Copiar el token de una herramienta a otra
  • ✗ Usar la suscripción mediante un cliente no oficial
  • ✗ Pedirle al agente que guarde una contraseña
  • ✗ Poner en producción lo que salió del laboratorio

💡 El puente adecuado no lleva contraseñas

Fíjate en los puentes del kit: la codex-exec.sh llama al comando oficial de Codex, que usa su inicio de sesión. La mcp-modelo lee un archivo exportado. Ninguno de los dos guarda, copia ni reenvía credenciales. Usa esto como prueba para cualquier puente nuevo.

🏷️
Oficial

por suscripción

🔐
Credencial

se queda donde nació

📜
Términos

leídos antes

🙋
Inicio de sesión

depende de ti

4

Elige tu sistema y completa el mapa

Empieza el proyecto final. Elige un sistema de tu trabajo que no tiene API: una hoja de cálculo, un ERP antiguo, el sitio web de un proveedor. Cualquiera de ellos le ahorraría tiempo a un agente.

Sonia eligió el ERP del cliente. Clara, la agenda de la clínica. Vas a recorrer las mismas seis etapas que ellas, desde el mapa hasta la lección aprobada.

1 · sistemasin API 2 · mapaCAPACIDADES 3 · víala más alta 4 · puenteR3 o R5 5 · equipoR2 · N2 6 · entregaverificar OK+ 1 lección entregable: tu carpeta runtime/ completa

Cómo leer el diagrama: las cinco cajas azules representan trabajo; la caja ámbar es la prueba de que el trabajo quedó listo. Ninguna etapa se salta la anterior: sin una línea en el mapa, no hay puente; sin puente, el equipo no tiene nada que usar.

🎯 Objetivo: una línea probada en el CAPACIDADES.md para tu sistema

Abre claude en la carpeta del kit y pega (el prompt del README):

Lee runtime/LEIA-ME.md y ayúdame a completar CAPACIDADES.md para mi trabajo.

Ejemplo del propio kit (la línea de Sonia antes de la prueba):

| ERP sem API | Exportação CSV diária | 6 | ler ~/erp/export/*.csv | ler (N4) | pendente |
Cómo verificar: tu fila tiene las seis columnas. La última solo cambia "pendiente" por la fecha cuando pasa la prueba del puente (tema 5).

💡 Elige algo pequeño

Un sistema, una pregunta. "Total de ventas por cliente" es un buen proyecto final. "Automatizar toda la oficina" no lo es. Después de que pase el primero, el segundo lleva la mitad del tiempo.

🎯
Un sistema

sin API

🗺️
Una línea

en CAPACIDADES.md

⏳
Pendiente

hasta la prueba

📁
runtime/

el entregable

5

Construye el puente y ejecuta el equipo

La vía que elijas determina la receta. Si el sistema exporta archivos, se usa la R3 (puente MCP). Un sistema que solo existe como sitio web se gestiona mediante R5 (navegador con políticas).

Con el puente funcionando, el equipo de tres roles de R2 hace el trabajo. Aquí con una diferencia: política N2. El equipo lo pide antes de crear o modificar cualquier archivo.

Tu sistemaRecetaPrueba del puenteMódulo
Exporta CSV o una hoja de cálculoR3 · puente MCPnode runtime/pontes/mcp-modelo/server.mjs --selftest2.2 · 2.3
Solo existe como sitio webR5 · navegadoragent-browser open + agent-browser get title2.4
🎯 Objetivo: el puente responde y está conectado a Claude (ruta R3)

En la terminal, en la carpeta del kit, después de señalar PONTE_DADOS y cambiar las columnas (módulo 2.3):

node runtime/pontes/mcp-modelo/server.mjs --selftest
claude mcp list

Salida real (05/10/2026, con los archivos de ejemplo del kit):

tools: 2 (listar_horarios_livres, resumo_vendas)
2026-10-06 09:00 · Dra. Ana
2026-10-06 10:00 · Dra. Ana
2026-10-06 15:00 · Dr. Bruno
TOTAL: R$ 856.00

ponte-modelo: node runtime/pontes/mcp-modelo/server.mjs - ✔ Connected
Cómo verificar: con tus datos, los números cambian, pero el formato queda igual y la línea del puente termina en ✔ Connected. Ahora cambia “pendiente” por la fecha en el CAPACIDADES.md.
🎯 Objetivo: el equipo de tres roles trabaja en tu puente y pide permiso antes (N2)

Abre claude en la carpeta del kit y pega (ejemplo de Sônia; cambia la tarea por la tuya):

Usa el equipo: el planificador planifica, el ejecutor hace y el revisor verifica. Tarea: usa la tool resumo_vendas del ponte-modelo y guarda en resumo-vendas.md el total de cada cliente y el TOTAL. Política N2: antes de crear o modificar cualquier archivo, muestra lo que vas a hacer y espera mi OK. Termina con la respuesta del revisor.

Cuenta a mano de erp-vendas.csv, para que compruebes el resumen:

Mercado Sol  10×18,50 + 40×5,20 = 185 + 208 = R$ 393,00
Padaria Lua  25×5,20 + 12×18,50 = 130 + 222 = R$ 352,00
Empório Mar  6×18,50             =             R$ 111,00
TOTAL                                          R$ 856,00
Cómo verificar: Claude se detuvo y pidió tu OK antes de guardar el archivo; los totales coinciden con el cálculo manual; la respuesta termina con APROVADO.
🔌
R3

el archivo se convierte en herramienta

🌐
R5

sitio con política

👥
R2

planifica, hace, verifica

🚦
N2

pide antes

6

Entrega el trabajo con la verificación y una lección aprobada

"Listo" no significa que el agente diga que terminó. Es el verificar.mjs ejecutar tus criterios y mostrar todos OK. Escribe un goal con el formato del goal-exemplo.md, un criterio por línea.

Y el proyecto solo se cierra con el ciclo completo: algo que ocurrió se convierte en una línea en la tabla Aprendizaje de la POLITICA.md, y tú apruebas.

📋 Modelo de goal para copiar (guárdalo como meu-goal.md en la raíz del kit)
# Goal — ponte do <meu sistema>

## Resultado
O agente lê o <meu sistema> pela ponte, o time grava o resumo e o kit continua saudável.

## Critérios de pronto
- [ ] `node runtime/scripts/doctor.mjs` → `PRONTO`
- [ ] `node runtime/pontes/mcp-modelo/server.mjs --selftest` → `tools: 2`
- [ ] `node runtime/pontes/mcp-modelo/server.mjs --selftest` → `TOTAL: R$ <total conferido à mão>`
- [ ] `claude mcp list` → `✔ Connected`
- [ ] `cat <arquivo que o time gravou>` → `<texto que tem de aparecer>`

## Portões humanos
Enviar, apagar, gastar ou publicar: pare e me pergunte.
Qué revisar: cada criterio se aprueba solo si el comando termina sin errores y la salida contiene el texto entre comillas invertidas después de la flecha. Reemplaza todo lo que está entre < >.
🎯 Objetivo: ver que la verificación indique "todos OK"

En la carpeta del kit, ejecútalo primero con el goal de ejemplo. Después cambia la ruta por la de tu meu-goal.md:

node runtime/scripts/verificar.mjs runtime/exemplos/goal-exemplo.md

Salida real (05/10/2026, salida 0):

OK     node runtime/pontes/mcp-modelo/server.mjs --selftest
OK     node runtime/pontes/mcp-modelo/server.mjs --selftest
OK     node runtime/pontes/mcp-modelo/server.mjs --selftest
OK     node runtime/scripts/doctor.mjs

4/4 critérios OK
Cómo verificar: la última línea dice N/N critérios OK con los dos números iguales. Si falta alguno, pídeselo al agente con el prompt de R6: /goal Cumpra o goal em meu-goal.md. Depois de cada etapa rode node runtime/scripts/verificar.mjs meu-goal.md. Só pare com todos OK ou num portão humano do goal.
📄 Ejemplo de fila aprobada en la tabla Aprendizaje (runtime/POLITICA.md)
| data | o que aconteceu (com evidência) | proposta (1 linha) | status: proposto / aprovado / recusado |
|---|---|---|---|
| <data> | o resumo do time somou um cliente duas vezes; o revisor pegou (FALTA:) | o revisor sempre compara o TOTAL com a soma por cliente | aprovado |
Después: aprobado se convierte en una línea en la sección Lessons del AGENTS.md (módulo 4.2).

✅ Lista de entrega (tu carpeta runtime/)

  • ☐ CAPACIDADES.md con la línea de tu sistema, vía, nivel, política y fecha de la prueba
  • ☐ Puente funcionando: selftest y ✔ Connected (R3) o agent-browser leyendo el sitio (R5)
  • ☐ Equipo de tres roles ejecutado con política N2, que termina en APROVADO
  • ☐ meu-goal.md en el formato - [ ] `comando` → `esperado`, con puertas de aprobación humana
  • ☐ Salida de verificar.mjs con todos los criterios OK
  • ☐ Una línea con estado aprovado en la tabla Aprendizaje y la regla en las Lessons
  • ☐ Si hubo laboratorio: la línea en LIMITES.md con fecha y etiqueta "frágil"

Prueba rápida (opcional): ¿qué demuestra que tu proyecto final está listo?

🎓 Resumen del módulo

✓
Primero, la escalera — una prueba por nivel antes del "no se puede".
✓
La ingeniería inversa es laboratorio — máquina de prueba, LIMITES.md, frágil y fecha.
✓
La credencial se queda donde nació — solo herramientas oficiales mediante la suscripción.
✓
Un sistema sin API se convierte en un puente — R3 o R5, y el equipo R2 trabaja en N2.
✓
Listo es evidencia — verificar que todo esté OK y que haya una lección aprobada.

Fin del curso:

Tienes un puente, un equipo, un goal verificado y la primera regla aprendida. Repite el ciclo con el siguiente sistema.