Andres Massello Uscha · una página · v1.10.0

Uscha, destilado.

Uscha es una metodología spec-driven y tool-agnóstica para desarrollo con agentes de código LLM. Desarrollo asistido por IA con los pies en la tierra: la IA ejecuta, el humano gobierna, la evidencia decide. Sin ceremonia donde no la gana, con rigor donde las stakes lo justifican (caminos críticos, migraciones).

La regla que ordena todo: los gates que leen HECHOS bloquean; los que ADIVINAN sobre prosa, avisan.

El loop

hecho → bloquea prosa → avisa camino a producción exit 1 vuelve al dev-loop

Las 5 reglas (la columna)

No código sin SPEC + ACCEPTANCE. Si es una idea vaga, primero se modela — no se codea.
La verdad vive en archivos, no en el chat. SPEC/ADR/CONSTITUTION se leen antes de tocar código.
El humano aprueba el merge. Nunca auto-merge. Merge, deploy, schema, permisos, config-prod: siempre humano, sin importar la confianza del agente.
Los tests ASERTAN y no se debilita el gate. Coverage miente (mutation testing lo mide); borrar tests o bajar thresholds = BLOCKER.
Migraciones: golden antes de tocar. El comportamiento viejo se captura mecánicamente; el agente no authorea el árbitro que lo juzga.

Los gates: hechos vs prosa

Gate	Qué lee
golden-diff	byte-compare `.received` vs `.approved`; exit 0 CLEAN / 1 DIVERGE / 2 NOT-RUN (cero fixtures = NOT-RUN, nunca CLEAN)	BLOQUEA
pit-check	XML de PIT (mutation testing = ¿los tests asertan?) — tier programado/incremental, no inner-loop; si el report existe y falla, se persiste con log-gate	BLOQUEA
gate-check	estructura del diff (tests borrados/deshabilitados, thresholds bajados o borrados)	BLOQUEA
rebuild	snapshot ejecutado vs narrado; exit 1 salvo COVERS	BLOQUEA
spec-check · estructura	hechos del SPEC: falta out-of-scope, ACCEPTANCE ausente/vacío (exit 1)	BLOQUEA
simplicity-check	caps numéricos (+líneas/crecimiento neto/archivos/anidación/hunk mayor) = hecho	BLOQUEA
readiness	KPI 0-100 con caps duros (tests rojos ≤35, BLOCKER/CRITICAL ≤65) — reporta, siempre exit 0; no es un gate	REPORTA
simplicity · abstracciones	regex de "tipos nuevos" (falsos positivos con records/DTOs)	AVISA
spec-check · prosa	heurística sobre prosa del SPEC (términos vagos, EARS, naming de stack) — `--strict` para gatear	AVISA

Bloquean — leen hechos

Exit 1 duro, cortan la cadena. Objetivos, baratos, sin opinión. El agente los corre inline en /uscha-devloop y persiste cada veredicto con log-gate; un fact gate rojo bloquea la convergencia (readiness es un KPI 0-100 que reporta, no un gate).

golden-diff · pit-check · gate-check
rebuild · caps de simplicity · spec-check estructural

Avisan — adivinan sobre prosa

Reportan, no bloquean (salvo --strict). Un heurístico sobre lenguaje natural que bloquea genera falsos positivos → el dev lo desactiva → gate muerto.

spec-check · prosa (advisory)
abstracciones de simplicity

El día a día del developer

# los gates de hechos corren INLINE en /uscha-devloop y se persisten con log-gate
spec → código (agente) → /uscha-devloop corre los gates inline:
   simplicity · gate-check · pit · golden  # exit 0/1, log-gate persiste el veredicto
   readiness  # KPI 0-100: reporta con caps duros, no es exit 0/1
→ converge → FRENA en el merge gate → el humano LEE el diff → ship
# spec-check (prosa) y abstracciones corren como advisory: informan, no frenan

La consistencia es inferencial, no un lint

Lo que una regex no puede juzgar (¿cláusulas contradictorias? ¿está sobre-arquitecturado?) NO se finge determinístico: va al checker no-correlacionado (otra familia de agente, o al menos otro perfil — disciplina de proceso, no lo fuerza el código). Computacional adentro del archivo; inferencial cross-file.

Apéndice: el detalle completo — historia, sensores (Böckeler), anti gate-gaming (Osmani), golden testing, glosario y referencias — está en el doc largo: uscha-claude-code-doc.html. · Instalación: npx --yes @andresmassello/uscha@latest install · luego npx … init en el repo (kit 1.50.0). · Gobierno: la IA ejecuta, la metodología gobierna, la evidencia decide, el humano aprueba.