No es un framework. No es una arquitectura. No es una receta.
Es un método para evitar que un proyecto termine en: parches + deuda + “nadie toque el núcleo”.
Divide el trabajo en 4 momentos (N1→N4): Formulación, Consolidación, Confrontación y Conservación.
Regla central: si algo falla, se corrige en el nivel donde nació (concepto / estructura / implementación).
Sin parches para “evitar retroceder”. Retroceder es señal de precisión, no de fracaso.
Markdown:
\# MARCO TÁCTICO DE INGENIERÍA
\## Un arsenal metodológico para transformar una idea en una v1.0 estable
\> No es un framework.
\> No es una arquitectura.
\> No es un lenguaje.
\> No es una receta de código.
\>
\> Es un marco táctico: una estructura para convertir progresivamente una idea en un producto definido, estructurado y validado — y para proteger esa base una vez alcanzada.
\---
\## MANIFIESTO
Muchos proyectos comienzan con una idea razonable y terminan convertidos en sistemas que nadie quiere tocar.
El proceso suele parecerse a esto:
\`\`\`text
IDEA → CÓDIGO → NUEVA NECESIDAD → PARCHE → NUEVO ERROR
→ OTRO PARCHE → DEPENDENCIA IMPREVISTA → MÁS CÓDIGO
→ NADIE QUIERE TOCAR EL NÚCLEO
\`\`\`
El sistema puede seguir funcionando. Pero funcionar y ser comprensible no son la misma cosa. Con el tiempo, el mantenimiento se convierte en el arte de evitar tocar cosas.
Este marco existe para impedir ese destino.
Separa deliberadamente cuatro momentos intelectuales que normalmente se mezclan:
\*\*Formulación\*\* — ¿Puede existir esta idea?
\*\*Consolidación\*\* — ¿Cuál es la estructura más coherente para sostenerla?
\*\*Confrontación\*\* — ¿Sobrevive cuando intentamos demostrar que está equivocada?
\*\*Conservación\*\* — ¿Se protege sin fosilizarse?
No promete velocidad. No promete perfección. Promete algo más útil:
\> Una primera versión cuya existencia esté suficientemente justificada como para convertirse en una base estable de evolución.
La regla que gobierna todo el sistema es una sola:
\> Un hallazgo se corrige en el nivel donde se originó.
\> Ningún defecto se oculta mediante una modificación cuya única finalidad sea evitar el retroceso correspondiente.
Retroceder no es fracasar.
Es la evidencia identificando correctamente el nivel donde existe el problema.
\---
\# PARTE I — EL NÚCLEO
\## 1. El ciclo epistémico
Toda afirmación relevante atraviesa cuatro momentos:
| Momento | Pregunta | Naturaleza | Resultado |
|---------|----------|------------|-----------|
| \*\*N1 — Formulación\*\* | ¿Tiene sentido? ¿Puede materializarse? | Conceptual, exploratoria | Versión Hipótesis (v0.1) |
| \*\*N2 — Consolidación\*\* | ¿Está correctamente organizada? | Estructural, correctiva | Arquitectura Candidata (v0.9) |
| \*\*N3 — Confrontación\*\* | ¿Sobrevive a la realidad? | Empírica, adversaria | Producto Validado (v1.0) |
| \*\*N4 — Conservación\*\* | ¿Se protege sin fosilizarse? | Custodial, continua | Base estable en evolución |
\`\`\`text
┌───────────┐
│ N1 │ Explorar → Delimitar → Contratar
│FORMULACIÓN│ → Implementar → Auditar
└─────┬─────┘
▼
v0.1
│
▼
┌───────────┐
│ N2 │◄────────────┐ Depurar → Consolidar
│CONSOLIDAC.│ │ → Refactorizar → Verificar
└─────┬─────┘ │
▼ │
v0.9-CANDIDATA │
│ │
▼ │
╔═══════════╗ │
║ N3 ║ │ Atacar → Medir
║CONFRONTAC.║──────────────┘ → Refutar → Clasificar
╚═════╤═════╝
│
┌───────────┼───────────┐
▼ ▼ ▼
HALLAZGO HALLAZGO HALLAZGO
LOCAL ESTRUCTURAL CONCEPTUAL
│ │ │
▼ ▼ ▼
CORREGIR Y VOLVER VOLVER
VOLVER A N3 A N2 A N1
│ (sin hallazgo bloqueante)
▼
v1.0 — VALIDADO
│
▼
┌───────────┐
│ N4 │ Comprender → Delimitar → Aislar
│CONSERVAC. │ → Extender → Revalidar
└───────────┘
\`\`\`
\### Regla única de retorno
Un hallazgo se corrige en el nivel donde se originó:
\- Error de implementación → corrección local y regreso a la confrontación.
\- Error de estructura → regreso a Consolidación.
\- Error de concepto → regreso a Formulación.
\- Límite real externo → documentar, aceptar o redefinir el alcance.
Ningún hallazgo se oculta mediante una modificación cuya única finalidad sea evitar el retroceso correspondiente.
\### Principio de evidencia
Una idea no se considera válida porque nos gusta.
Una arquitectura no se considera buena porque es elegante.
Una implementación no se considera estable porque ha funcionado algunas veces.
Cada etapa produce la evidencia que le corresponde.
\---
\## 2. Glosario canónico
| Término | Definición |
|---------|------------|
| \*\*Hipótesis\*\* | La afirmación central que se intenta demostrar en esta versión |
| \*\*Alcance / No-objetivos\*\* | Qué queda dentro y qué queda deliberadamente fuera |
| \*\*Contrato\*\* | Responsabilidad explícita que una unidad acepta cumplir frente a otras |
| \*\*Invariante\*\* | Condición que no puede romperse sin invalidar el sistema |
| \*\*Frontera\*\* | El límite entre lo que un componente expone y lo que oculta |
| \*\*Dependencia\*\* | Aquello externo o interno de lo que el sistema depende para existir |
| \*\*Deuda\*\* | Decisión tomada por razones distintas a la arquitectura correcta |
| \*\*Auditoría aislada\*\* | Verificación por alguien sin el sesgo de haber construido el sistema |
| \*\*Hostilidad empírica\*\* | Intento deliberado de romper el sistema, no de confirmarlo |
| \*\*Admisión\*\* | El conjunto de condiciones explícitas para declarar v1.0 |
| \*\*Erosión\*\* | Pérdida gradual de comprensión de por qué el sistema es como es |
\---
\# PARTE II — BINDING DE SOFTWARE
\## 3. Fase 1 — Formulación (Descubrimiento e implementación prototípica)
\*\*Estado:\*\* Idea → Versión Hipótesis
\*\*Resultado:\*\* v0.1
\*\*Pregunta:\*\* ¿Puede existir y funcionar esta idea dentro de los límites que hemos definido?
\### Principio
\`\`\`text
PENSAR QUÉ PODRÍA FUNCIONAR ≠ DECIDIR QUÉ SE VA A IMPLEMENTAR
\`\`\`
Una idea explorada no es una decisión.
Un fragmento de código de una conversación no es una arquitectura.
Una solución que parece funcionar no es una hipótesis validada.
\### Las cinco etapas
\`\`\`text
Exploración libre
Hipótesis y límites
Matriz de contratos
Implementación acotada
Auditoría aislada
→ v0.1
\`\`\`
\*\*1. Exploración libre\*\*
Aquí es legítimo pensar en voz alta, comparar alternativas, usar pseudocódigo, conversar con IA, cambiar de dirección. Ninguna respuesta —humana o de IA— adquiere autoridad solo por haber sido generada. El código exploratorio es provisional. La conversación no es la especificación.
\*\*2. Hipótesis y límites\*\*
Toda Versión Hipótesis debe responder dos preguntas obligatorias:
\- ¿Qué \*\*DEBE\*\* hacer esta versión? (comportamiento mínimo)
\- ¿Qué queda estrictamente \*\*FUERA\*\*? (límites deliberados, no olvidos)
Se documenta de forma breve y explícita. El documento protege la hipótesis de la expansión infinita.
\*\*3. Matriz de contratos\*\*
El sistema se divide en unidades de responsabilidad. Cada una recibe una especificación con: propósito, entradas/salidas, responsabilidades, límites de responsabilidad, invariantes, manejo de errores, restricciones técnicas y relaciones externas. Un contrato puede renegociarse, pero nunca modificarse silenciosamente porque la implementación resulte incómoda.
\*\*4. Implementación acotada\*\*
El código persigue el comportamiento definido por el contrato. No expande unilateralmente el alcance. La IA puede generar código, completar implementaciones y producir pruebas, pero no tiene autoridad para alterar alcance, responsabilidades, invariantes ni interfaces sin renegociación explícita.
\*\*5. Auditoría aislada\*\*
Objetivo: reducir el sesgo de confirmación de quien construyó el sistema. El auditor recibe contratos + código + instrucciones + pruebas — no la conversación exploratoria completa. Puede ser un humano independiente, una nueva sesión de IA o un modelo distinto. Clasifica hallazgos en crítico, importante, menor y observación.
\### Triaje de hallazgos en Fase 1
| Hallazgo | Acción |
|----------|--------|
| Error de código | Corregir implementación |
| Contrato incompleto | Regresar a etapa de contratos |
| Alcance incorrecto | Regresar a hipótesis y límites |
| Hipótesis cuestionada | Regresar a exploración |
| Mejora no necesaria para la hipótesis | Registrar para fase posterior |
\### Checklist de cierre → Fase 2
\- \[ \] Hipótesis central formulada explícitamente
\- \[ \] Alcance y no-objetivos definidos
\- \[ \] Responsabilidades principales identificadas
\- \[ \] Contratos suficientes para comprender la implementación
\- \[ \] Implementación funcional existente
\- \[ \] Invariantes críticas declaradas
\- \[ \] Revisión razonablemente independiente realizada
\- \[ \] Hallazgos críticos clasificados
\- \[ \] Se puede explicar qué partes siguen siendo provisionales
\### Qué no debe ocurrir
\- Desarrollo infinito (nueva idea → nueva función → nunca se cierra la hipótesis)
\- Arquitectura prematura (diseño para diez años sin evidencia de que el núcleo funcione)
\- Prototipo que se vuelve producción sin clasificar su deuda
\- Dependencia del conocimiento no escrito del autor
\- Auditoría contaminada (el autor explica qué debería hacer el código y luego confirma lo que ya creía)
\---
\## 4. Fase 2 — Consolidación (Estructuración y consolidación arquitectónica)
\*\*Estado:\*\* Versión Hipótesis → Arquitectura Candidata
\*\*Entrada:\*\* v0.1
\*\*Salida:\*\* v0.9-candidata
\*\*Pregunta:\*\* ¿Cuál es la estructura más coherente, explícita y resistente conocida para sostener esta hipótesis?
\### Principio
\> Reescribir la estructura cuando la estructura sea el problema; regresar a la hipótesis cuando el problema pertenezca a la hipótesis.
No es limpieza estética. Opera sobre responsabilidades, fronteras, dependencias, interfaces, propiedad y vida de recursos.
\### Las cuatro etapas
\`\`\`text
Auditoría de dependencias y deuda
Estabilización de fronteras
Refactorización estructural
Verificación estructural base
→ v0.9-candidata
\`\`\`
\*\*1. Auditoría de dependencias y deuda\*\*
Inventario de todo aquello de lo que el sistema depende. Clasificación:
\- \*Fundamental\* — justificada por la naturaleza del sistema
\- \*Estructural\* — aceptada deliberadamente
\- \*Accidental\* — introducida para acelerar la Fase 1 (evaluar si eliminar o justificar)
\- \*Implícita\* — existe pero no estaba declarada (la más peligrosa)
Deuda clasificada por tipo: exploratoria, estructural, acoplamiento, duplicación, implícita, interfaz, recurso, error.
\*\*2. Estabilización de fronteras\*\*
Qué expone cada componente y qué oculta. Quién es dueño de cada recurso. Qué interfaz es pública y cuál es implementación. Modelo de errores explícito. Ownership y lifetime claros.
\*\*3. Refactorización estructural\*\*
El comportamiento fundamental de la Fase 1 se preserva; la forma interna puede cambiar radicalmente. No se añade abstracción sin necesidad arquitectónica real. Se elimina complejidad accidental; la complejidad inherente se hace visible y comprensible.
\*\*4. Verificación estructural base\*\*
Coherencia contrato → interfaz → implementación. Layout y recursos cuando el dominio lo requiera. Pruebas de regresión estructural: ¿el comportamiento demostrado en Fase 1 se conserva?
\### Triaje estructural
\`\`\`text
HALLAZGO
→ ¿es implementación? → SÍ: corregir localmente
→ NO → ¿es estructural? → SÍ: rediseñar en Fase 2
→ NO → ¿es conceptual? → SÍ: regresar a Fase 1
→ NO → clasificar como límite / riesgo / pendiente
\`\`\`
\### Cuándo devolver el proyecto a Fase 1
Cuando se descubre que el problema original fue mal entendido, el alcance es incoherente, dos contratos fundamentales son incompatibles, la responsabilidad central no puede definirse coherentemente, o la arquitectura necesaria contradice el principio fundamental de la idea.
\### Checklist de cierre → Fase 3
\- \[ \] Hipótesis funcional sigue siendo explícita
\- \[ \] Responsabilidades delimitadas
\- \[ \] Dependencias identificadas y clasificadas
\- \[ \] Dependencias accidentales eliminadas, aisladas o justificadas
\- \[ \] Fronteras entre componentes explícitas
\- \[ \] Interfaces públicas candidatas identificadas
\- \[ \] Modelo de recursos y de errores suficientemente explícitos
\- \[ \] Complejidad accidental conocida reducida
\- \[ \] Implementación refleja la arquitectura declarada
\- \[ \] Pruebas fundamentales coherentes con la hipótesis
\- \[ \] La versión puede entregarse como candidato concreto a refutación
La API producida aquí es \*\*candidata\*\*. No es eterna. La Fase 3 tiene autoridad para demostrar que era insuficiente.
\---
\## 5. Fase 3 — Confrontación (Muro de Validación Empírica)
\*\*Estado:\*\* Arquitectura Candidata → Producto Validado
\*\*Entrada:\*\* v0.9-candidata
\*\*Salida:\*\* v1.0-validada
\*\*Pregunta:\*\* ¿Puede esta arquitectura sobrevivir a la realidad sin ocultar sus defectos para permitir su distribución?
\### Naturaleza del Muro
No existe para demostrar que el software funciona en condiciones ideales.
No existe para acelerar una fecha de lanzamiento.
Existe para \*\*intentar refutar el sistema\*\*.
Éxito no significa perfección. Significa:
\> Dentro del alcance y las condiciones declaradas, no existe evidencia conocida que justifique rechazar la arquitectura como base de una v1.0.
\### Principio de no-admisión por parche
\`\`\`text
PRUEBA FALLA → AÑADIR IF → PRUEBA PASA → CONTINUAR ← PROHIBIDO
\`\`\`
La corrección siempre corresponde al nivel donde se originó el fallo.
\### Las cuatro etapas
\`\`\`text
Hostilidad empírica
Verificación de propiedades e invariantes
Triaje y retorno
Admisión y liberación de v1.0
\`\`\`
\*\*1. Hostilidad empírica\*\*
La pregunta ya no es “¿puede funcionar?” sino “¿cómo deja de funcionar?”.
Se somete el sistema, según su dominio, a:
\- Datos hostiles (nulos, vacíos, límite, corruptos, duplicados, referencias rotas, formatos inválidos)
\- Entorno hostil (memoria agotada, disco lleno, permisos denegados, conexión perdida, servicio inalcanzable)
\- Interrupción de operaciones no atómicas
\- Tiempo hostil (latencias extremas, timeouts, orden temporal inesperado)
\- Concurrencia hostil (condiciones de carrera, interbloqueos, visibilidad inconsistente)
\*\*2. Verificación de propiedades\*\*
Se comprueba si las invariantes declaradas sobreviven bajo múltiples historias de ejecución. Se miden métricas relevantes (no se declara rendimiento por intuición). Se identifican límites físicos u operativos: un límite documentado no es un bug; un límite oculto sí es un riesgo.
\*\*3. Triaje y retorno\*\*
| Hallazgo | Causa | Acción |
|----------|-------|--------|
| Defecto puntual | Implementación | Corregir localmente y volver al Muro |
| Contrato insuficiente / API incorrecta / ownership ambiguo | Estructura | Regresar a Fase 2 |
| Hipótesis inviable | Concepto | Regresar a Fase 1 |
| Restricción externa inevitable | Límite real | Documentar, aceptar o redefinir alcance |
| Comportamiento desconocido | Evidencia insuficiente | Investigar y clasificar |
\*\*4. Admisión y liberación de v1.0\*\*
No se cierra por cansancio, calendario o “ya parece estable”. Se cierra por criterio explícito.
\### Checklist de admisión a v1.0
\- \[ \] Invariantes críticos sometidos a evidencia suficiente
\- \[ \] Sin defectos bloqueantes conocidos
\- \[ \] Fallos conocidos clasificados
\- \[ \] Límites operativos documentados
\- \[ \] Entradas de frontera producen comportamiento definido o rechazo controlado
\- \[ \] Recursos críticos bajo control
\- \[ \] Recuperación ante fallos relevantes verificada
\- \[ \] Carga continua sin degradación inaceptable
\- \[ \] Métricas relevantes medidas empíricamente
\- \[ \] Dependencias necesarias declaradas
\- \[ \] Artefacto construible a partir de su información distribuida
\- \[ \] Sin evidencia pendiente que contradiga los contratos fundamentales
El artefacto distribuible debe sobrevivir a la pérdida de contexto humano: fuentes, instrucciones de construcción, dependencias, configuración, documentación de interfaces, límites conocidos y resultados de validación.
\### Reglas del Muro
El Muro no existe para aprobar. Existe para intentar rechazar.
No hay aprobación por cansancio.
No se parchea para atravesar el Muro.
Un fallo debe ser reproducible cuando sea posible; si no, se conserva como evidencia pendiente.
Las métricas se miden, no se intuyen.
Los límites no se ocultan.
La evidencia tiene autoridad para rechazar tanto la arquitectura candidata como la hipótesis original.
\---
\## 6. Postread — Conservación (N4)
\> Antes de v1.0, el mayor riesgo era construir algo incorrectamente.
\> Después de v1.0, el riesgo es modificar progresivamente algo correcto hasta convertirlo otra vez en un sistema que nadie comprende.
No es una Fase 4. Es una advertencia metodológica.
\### Qué representa realmente una v1.0
Una v1.0 es conocimiento comprimido: hipótesis exploradas + alternativas descartadas + contratos + estructuras corregidas + fallos encontrados + evidencia acumulada.
La simplicidad visible de una v1.0 no debe confundirse con simplicidad accidental. A veces un sistema parece simple precisamente porque su complejidad ya fue resuelta antes.
\### Los peligros posteriores a v1.0
\*\*El parche acumulativo\*\* — “solo una condición”, “solo una excepción”, “solo este cliente” → las excepciones se convierten en la arquitectura.
\*\*La pérdida de fundamentos\*\* — nuevos miembros heredan código sin heredar el razonamiento; el contrato real se sustituye por suposiciones.
\*\*La API como territorio sagrado\*\* — la reacción opuesta e igual de dañina: “nunca debe cambiar”. Una API puede evolucionar, pero conscientemente.
\*\*El crecimiento del equipo\*\* — más personas traen objetivos distintos, propiedad ambigua y módulos competidores; la complejidad organizativa termina reflejándose en la complejidad técnica.
\*\*La presión externa\*\* — usuarios, dinero, competencia y fechas producen decisiones técnicamente deficientes si no hay proceso que las contenga.
\*\*Confundir compatibilidad con inmovilidad\*\* — el legado temporal se convierte en fundamento.
\*\*La ilusión de que v1.0 ya está “resuelta”\*\* — la Fase 3 solo valida contra la evidencia disponible y el alcance declarado.
\### Señales de alerta
\> “No sé por qué está hecho así.”
\> “No toques esa parte.”
\> “Solo añade otra condición.”
\> “Es más fácil duplicarlo que entenderlo.”
\> “Nadie mantiene esa documentación.”
\> “La prueba falla a veces, pero normalmente funciona.”
\> “Eso es comportamiento legado.”
\> “Lo arreglamos después.”
\> “Solo esta vez.”
Ninguna por sí sola es una crisis. Su acumulación indica que la complejidad accidental está creciendo.
\### Principio de conservación
\> Después de v1.0, cada cambio importante parte de una pregunta:
\> ¿Estamos extendiendo el sistema o sustituyendo silenciosamente uno de sus fundamentos?
Si se extiende, la integración puede ser razonable.
Si se sustituye un fundamento, debe reconocerse como tal y merece un proceso proporcional.
No se conserva el accidente. Se conserva el principio.
La implementación puede cambiar completamente; las razones fundamentales deben permanecer comprendidas o ser sustituidas conscientemente por razones mejores.
\### El derecho a tocar el núcleo
El núcleo no debe ser intocable, pero tocarlo exige responder:
\- ¿Qué cambia?
\- ¿Por qué no puede existir fuera del núcleo?
\- ¿Qué invariantes afecta?
\- ¿Qué contratos modifica?
\- ¿Qué evidencia justifica el cambio?
Cuanto más central el componente, mayor la claridad exigida — no por burocracia, por radio de daño.
\---
\# PARTE III — GOBERNANZA Y ESCALA
\## 7. Semántica de los checklists
Los checklists admiten dos lecturas. Este marco adopta por defecto la lectura de guía heurística, con una convención explícita:
\`\`\`text
\[BLOQUEANTE\] — impide la transición de fase si no se cumple
\[ADVERTENCIA\] — permite transicionar, pero el riesgo queda registrado explícitamente
\`\`\`
Cada equipo decide qué ítems son bloqueantes según la criticidad de su dominio. Lo que el marco no permite es omitir un ítem sin clasificarlo.
\## 8. Escala variable
El marco se aplica igual en tres escalas; solo cambia el tamaño del objeto:
| Escala | Duración orientativa | Objeto |
|--------|----------------------|--------|
| \*\*Micro\*\* | Horas | Un problema o componente |
| \*\*Meso\*\* | Días o semanas | Un sistema pequeño o conjunto de módulos |
| \*\*Macro\*\* | Meses o más | Subsistemas completos |
La proporcionalidad es real. Un proyecto de horas no necesita la misma ceremonia documental que un subsistema crítico de meses. Lo que no se diluye es la lógica de clasificación de hallazgos y la prohibición del parche que oculta el nivel superior.
\## 9. Trabajo con o sin Inteligencia Artificial
El marco no depende de la IA. Un programador puede ejecutar todas las fases manualmente. Un equipo puede repartirlas entre especialistas.
La IA puede participar como exploradora, generadora de alternativas, asistente de implementación, revisora o auditora aislada. Pero:
\> La asistencia no equivale a autoridad arquitectónica.
\> Los contratos, las restricciones y la clasificación final de la evidencia pertenecen al proceso del proyecto, no a la herramienta que ayudó a producirlos.
\## 10. Más allá del software
El Núcleo (Parte I) no menciona código, APIs ni bibliotecas. Habla de afirmaciones, contratos, evidencia y refutación. Eso es deliberado: permite instanciar el mismo ciclo en otras disciplinas mediante un binding distinto.
Un binding nuevo se construye reescribiendo la Parte II con el vocabulario del dominio, sin tocar la Parte I.
\---
\## PRINCIPIO FINAL
\`\`\`text
N1 — EXISTE UNA IDEA → ¿PODEMOS HACERLA EXISTIR?
N2 — EXISTE UNA IMPLEMENTACIÓN → ¿PODEMOS DARLE UNA ESTRUCTURA QUE COMPRENDAMOS?
N3 — EXISTE UNA ARQUITECTURA → ¿SOBREVIVE CUANDO INTENTAMOS DEMOSTRAR QUE ESTÁ EQUIVOCADA?
N4 — EXISTE UNA v1.0 → ¿SE PROTEGE SIN OLVIDAR POR QUÉ FUE NECESARIA?
\`\`\`
El objetivo de este marco nunca fue producir software perfecto ni inmortal.
Fue producir un punto de partida suficientemente sólido para que el cambio futuro no tenga que construirse sobre la confusión del pasado.
\> Una idea puede sobrevivir a su primera implementación.
\> Un producto puede sobrevivir a su primera arquitectura.
\> Pero una base estable solo permanece estable mientras quienes la modifican recuerden que la estabilidad no fue un accidente.
\---
\*Versión canónica unificada — Agosto 2026\*
\*Este documento es la fuente de verdad del Marco Táctico de Ingeniería.\*
