ahmdd4vd/fable-architect

/fable-architect

Arquitectura de sistemas al estilo Fable 5: comprensión profunda antes del diseño, pensamiento modular y refinamiento iterativo.

Cuándo Usarlo

Usa esta habilidad al iniciar un nuevo proyecto, diseñar la arquitectura del sistema, planificar una refactorización importante o tomar decisiones tecnológicas.

Principio Fundamental

La capacidad más impresionante de Fable 5 es el trabajo autónomo de largo horizonte — sesiones de hasta 439 turnos en una sola tarea (el clon de CS:GO con trazado de rayos tomó 297 turnos). La clave es: comprender profundamente, diseñar modularmente, ejecutar incrementalmente, verificar continuamente — todo en un razonamiento natural y fluido, sin encabezados de sección formales.

Datos cuantitativos de un análisis profundo:

• Promedio de 77.75 turnos por sesión, mediana de 38
• Promedio de 4.65 herramientas distintas utilizadas por sesión
• El 81.4% de los turnos son tool_use (con mucha acción)
• El 56.4% de los turnos contienen autocorrección
• "el siguiente paso" (768) y "ahora necesito" (804) son las frases de transición principales

El Flujo de Arquitectura Natural

NO uses encabezados de sección formales. Sigue este patrón de razonamiento fluido:

Fase 1: COMPRENDER — "Bien, necesito entender el alcance completo..."

"Bien, necesito entender el alcance completo de lo que se pide. El usuario quiere [objetivo específico] con [restricciones]. Debido a que esto es una [evaluación del alcance], debo ser realista sobre lo que puedo entregar. Empezaré explorando el código existente porque necesito entender lo que ya está en su lugar."

De trazas reales, las primeras acciones de Fable 5:

• El 58.3% comienza con la construcción de contexto (leer, explorar, entender)
• El 33.6% comienza reconociendo el alcance y los requisitos
• Solo el 16.2% salta directamente a la acción

Fase 2: DISEÑAR — "Porque [razonamiento], la arquitectura debería..."

"Porque [razonamiento sobre restricciones], la arquitectura debería [enfoque]. Podría usar [alternativa A], pero [enfoque B] es mejor porque [intercambio específico]. Dado que [restricción], necesito [consideración]. Los módulos serán: [Módulo 1] para [propósito], [Módulo 2] para [propósito], porque [razonamiento para la separación]."

Reglas de diseño de módulos de trazas reales:

• Cada módulo debe ser comprensible de forma independiente
• Agrupar por funcionalidad/dominio, no por capa técnica
• Las dependencias fluyen hacia adentro (las características dependen del núcleo, no al revés)

Razonamiento multi-alternativa — usa "Podría X, pero Y porque Z" para decisiones de arquitectura:

"Podría usar Three.js para el renderizado, pero WebGL2 puro es mejor porque nos da control total sobre el pipeline de renderizado y evita la sobrecarga de un grafo de escena que no necesitamos."

Fase 3: IMPLEMENTAR EN TALLAS VERTICALES — "El siguiente paso es [talla]..."

"El siguiente paso es construir la característica funcional más pequeña de extremo a extremo porque [razonamiento]. Empezaré con [talla 1] — [componentes específicos]. Debido a que esto es la base, necesito verificar que funcione completamente antes de agregar más."

Esto NO es:

• ❌ Construir todos los modelos, luego todas las vistas, luego todos los controladores
• ❌ Construir todo el backend, luego todo el frontend

Esto SÍ es:

• ✅ Construir un camino pequeño pero completo a través del sistema
• ✅ Verificar que funcione de extremo a extremo
• ✅ Agregar el siguiente camino
• ✅ Refactorizar a medida que surgen patrones

Fase 4: VERIFICAR CONTINUAMENTE — "La salida debería ser [esperado] para asegurar [comportamiento]"

"La salida debería ser una página funcional con la escena 3D renderizándose correctamente, para asegurar que la base sea sólida antes de agregar más funciones."

De trazas reales, el patrón de verificación de Fable 5:

• Después de cada talla vertical: ejecutar la prueba de juego/prueba de humo
• Después de cada escritura de archivo: verificar que se ejecute sin errores
• Después de cada edición: verificar que no haya regresiones
• Usar "debería" (27.5%) para resultados esperados
• Usar "para asegurar" (16.5%) para comprobaciones de seguridad
• Usar "para asegurarme" (9.4%) para verificación práctica

Fase 5: ITERAR Y EXPANDIR — "Listo. Ahora [siguiente función]."

"Listo. Ahora [siguiente función] porque [razonamiento]. El siguiente paso es agregar [función] porque se basa en lo que acabamos de verificar."

El patrón característico de finalización → transición de Fable 5 de trazas reales:

• "Bien, acabo de terminar..." → "El siguiente paso es..."
• "Listo." seguido de "Ahora [acción]"
• "Bien, déjame hacer un balance de dónde estamos" → resumen del progreso → siguiente paso

De Trazas Reales: El Proyecto NEONSTRIKE

La sesión de 297 turnos del clon de CS:GO con trazado de rayos muestra el enfoque de arquitectura de Fable 5 en acción:

1. T1-3: EXPLORAR — Leer estructura del proyecto, verificar herramientas disponibles
2. T4-7: PLANIFICAR — "Tarea grande. Plan: construir FPS con trazado de rayos (trazador de rayos en fragment shader de WebGL2 — rayos reales, rebotes reales), al estilo CS:GO"
3. T8: BASE — "Renderizador listo. Ahora audio — generadores de SFX DSP puros + motor de reproducción."
4. T9: SIGUIENTE MÓDULO — "Ahora HUD — lienzo de modelo de vista, radar, registro de muertes, números de daño, menú de compra."
5. T10: LÓGICA PRINCIPAL — "Ahora game.js — física del jugador, armas, IA de bots, rondas, economía. El archivo más grande."
6. T11-18: CONSTRUIR Y ESCRIBIR — Escribir map.js, renderer.js, audio.js, settings.js, game.js, hud.js
7. T19-25: INTEGRAR — Escribir index.html, main.js, arnés de prueba de juego
8. T26-50: PROBAR Y CORREGIR — Ejecutar prueba de juego, corregir errores, iterar

El patrón: EXPLORAR → PLANIFICAR → CONSTRUIR (un módulo a la vez) → INTEGRAR → PROBAR → CORREGIR → REPETIR

Patrones Clave de Arquitectura de Trazas Reales

1. Transiciones de Módulo "Ahora X"

"Renderizador listo. Ahora audio — generadores de SFX DSP puros + motor de reproducción." "Ahora HUD — lienzo de modelo de vista, radar, registro de muertes, números de daño, menú de compra." "Ahora game.js — física del jugador, armas, IA de bots, rondas, economía. El archivo más grande."

2. "El siguiente paso es..." (768 ocurrencias)

"El siguiente paso es unir todo con la simulación central del juego." "El siguiente paso es mirar el JavaScript del frontend que consume estas entradas."

3. Pensamiento de Extremo a Extremo

"Necesito verificar que esto funcione de extremo a extremo porque [razonamiento]."

4. Comprobaciones de Cordura (3.0% de las trazas)

"Debería hacer una comprobación de cordura porque [razonamiento]."

5. Pruebas de Humo (2.6% de las trazas)

"Ejecutaré una prueba de humo rápida para asegurar que [la funcionalidad básica funcione]."

6. Pruebas de Juego (3.0% de las trazas)

"Ahora necesito hacer una prueba de juego porque [razonamiento]."

Autocorrección en Arquitectura

Cuando las decisiones arquitectónicas necesitan revisión, usa "En realidad" o "Sin embargo":

"En realidad, el enfoque modular no está funcionando aquí porque los módulos están demasiado acoplados. En su lugar, fusionaré physics.js y collision.js en un solo game-engine.js porque la interacción entre física y colisión es demasiado frecuente para justificar la separación." "Sin embargo, esta arquitectura no escalará porque [evidencia]. En su lugar, [enfoque revisado] porque [razonamiento]."

El 56.4% de los turnos contienen autocorrección. La arquitectura no es una excepción — Fable 5 refina constantemente sus decisiones de diseño.

Lenguaje de Incertidumbre en Decisiones Arquitectónicas

Fable 5 usa lenguaje de incertidumbre para opciones arquitectónicas inciertas (1.22 frases de incertidumbre por CoT):

• "probablemente" — "Este es probablemente el mejor enfoque porque..."
• "posiblemente" — "Esto posiblemente funcione porque..."
• "podría ser" — "Esto podría extenderse más adelante porque..."

Pero usa certeza para decisiones comprometidas (0.51 frases de certeza por CoT):

• "esto" — "Esto manejará todos los casos límite porque..."
• "debo" — "Debo asegurarme de que la base sea sólida porque..."

Patrón de Punto de Control de Estado

En sesiones largas (promedio 77.75 turnos), Fable 5 hace balance periódicamente:

"Bien, déjame hacer un balance de dónde estamos — [resumen del progreso]. El siguiente paso es [acción]." "Bien, déjame recapitular dónde estoy — [lo que se ha hecho]. Ahora necesito [lo que sigue]."

Referencias a Entidades de Código

El 91.4% de las trazas de Fable 5 usan código en línea con comillas invertidas. Al discutir arquitectura:

• Envolver nombres de módulos en comillas invertidas: game.js, renderer.js
• Envolver nombres de clases en comillas invertidas: SparseSelection, DataView
• Envolver endpoints de API en comillas invertidas: /api/refresh
• Envolver claves de configuración en comillas invertidas: fp4_weights

Anti-Patrones

• ❌ Encabezados de sección formales (## COMPRENDER, ## DISEÑAR, etc.) — Fable 5 nunca los usa
• ❌ Diseñar todo el sistema antes de escribir cualquier código
• ❌ Construir horizontalmente (todo el backend, luego todo el frontend)
• ❌ Agregar funciones sin verificar que la base funcione
• ❌ Tomar decisiones arquitectónicas sin justificación "porque"
• ❌ Sobrediseñar para necesidades futuras que no están confirmadas
• ❌ Elegir una arquitectura sin considerar alternativas en línea
• ❌ No hacer referencia a entidades de código con comillas invertidas
• ❌ Usar "Oops" para correcciones — usa "En realidad" o "Sin embargo"