ousterhout-build-deep

SKILL.md

---
name: ousterhout-build-deep
description: Usa mientras escribes o modificas código, antes de dar por terminada la tarea, siempre que el cambio añada un nombre exportado o importable, cree un módulo, clase, componente, helper, hook, servicio o wrapper, o centralice código repetido. Lista de verificación en tiempo de autor para construir módulos profundos: nombra la decisión que oculta el límite, pasa las pruebas de profundidad e invariante, arregla problemas en lugar de reubicarlos, nunca dividas solo por tamaño y termina con una nota de diseño breve. Compañero compacto de ousterhout-quality-program, que sigue siendo la lente completa de revisión.
---

# Construir en profundidad (Ousterhout, author-time)

Estás escribiendo código, no revisándolo. Ejecuta esto en tu propio cambio antes de
llamar a la tarea terminada.

## 1. Puerta

¿El cambio añade un nombre exportado/importable, crea un módulo, clase,
componente, helper, hook, servicio o wrapper, o centraliza código repetido?
Si no, omite esta habilidad. Renombramientos, codemods, ediciones de configuración/datos y arreglos de una línea están exentos.

## 2. Antes de escribir el límite

- Encuentra cómo este repositorio ya resuelve un problema de esta forma y síguelo
  a menos que puedas explicar por qué no. Lee la documentación y tipos actuales de la dependencia: una API recordada de memoria es una afirmación, no una fuente.
- Escribe primero el comentario de la interfaz: qué promete, qué oculta. Si
  no puedes nombrar la decisión oculta (un formato, una política, una regla, una
  elección de esquema), el límite no debería existir. Incrústalo.
- Nómbralo en lenguaje del dominio. Si el único nombre honesto es `utils`,
  `helpers` o `manager`, el corte está en el lugar equivocado.

## 3. Dos pruebas

- **Profundidad.** La interfaz debe ocultar sustancialmente más de lo que expone. Un
  wrapper que reenvía sus argumentos es un costo sin beneficio; elimínalo.
- **Invariante.** Extrae código compartido solo cuando protege una regla compartida.
  La evidencia es el co-cambio: las copias fueron corregidas o cambiadas juntas en
  la historia. Similares que cambian independientemente permanecen duplicados.

## 4. Una corrección debe eliminar el problema, no reubicarlo

- Seis casts movidos a un helper genérico de cast siguen siendo seis casts. Escribe
  el mapper tipado que los casts estaban encubriendo.
- No añadas un parámetro o bandera que empuje una decisión a los llamadores a menos que
  los llamadores realmente sepan algo que tú no. Absorbe el caso difícil dentro.
- Prefiere semánticas donde el caso de error no pueda surgir en lugar de hacer que cada
  llamador lo maneje.
- Mover complejidad esencial del dominio a otro archivo no es simplificación.

## 5. Bajo presión de "limpia esto" o "este archivo es muy grande"

Nunca dividas solo por tamaño. Un módulo de 400 líneas que oculta una decisión vence
cuatro módulos de 100 líneas que filtran las mismas uniones. Pregunta qué decisión
oculta cada división; si ninguna, no dividas.

## 6. Seguridad

Código existente: fija el comportamiento actual con un test antes de profundizarlo.
Código nuevo: escribe el test que define el comportamiento previsto.

## 7. Reporte

Si la puerta se activó, termina tu mensaje final con una nota de diseño de 2-4 líneas:
cada límite que añadiste y la decisión que oculta; duplicación que dejaste a propósito y por qué;
cualquier cosa superficial que aceptaste y por qué.

Para una llamada disputada o una revisión completa, carga `ousterhout-quality-program`.

Tags