@andresmassello/uscha 1.40.1

package/uscha-kit/CHANGELOG-1.23.0.md

@@ -0,0 +1,75 @@
+# dev-loop-kit 1.23.0 — rubric layer: el ACCEPTANCE de lo no-testeable (2026-07-03)
+
+Origen: evaluación del concepto "rubrics" de Claude Code (Outcomes/graders) contra
+el método. Veredicto: la ARQUITECTURA no aporta nada nuevo (maker≠checker con
+contexto aislado ya existe); el edge real es **el artefacto** — criterio cualitativo
+versionado. Entra con el acople corregido respecto de la propuesta original:
+**advisory-first**, jamás dimensión ponderada del readiness (un grade LLM es guess
+estructurado, no hecho medido — doctrina 1.10.0). Smoke suite: 139/139.
+
+## Restricción de diseño: cero dependencia de un agente específico
+
+Tres capas de acople decreciente — pedido explícito del humano:
+
+1. **Núcleo (engine stdlib, cero LLM)**: `RUBRIC.md` + `spec-check --rubric` +
+   `rubric-ingest` + advisory en readiness + doctor. Un humano puede llenar el JSON
+   del grader a mano y todo funciona — **el smoke T43 lo prueba ejecutablemente**
+   (el grader.json del test se llena a mano, sin ningún LLM).
+2. **Interfaz**: el contrato JSON
+   `{"criteria":[{"id","verdict":"pass|fail","evidence","note"}]}` — la ÚNICA
+   superficie entre el método y cualquier grader. IDs normalizados por número
+   (RB-01 == RB_1 == rb1, mismo criterio que AC-n).
+3. **Graders pluggables**: `templates/rubric-grader-prompt.md` (markdown plano,
+   corre pegado en Codex, Gemini CLI, Cursor, un curl, o un humano) + la skill
+   `specloop-rubric` como adapter FINO de Claude Code (documentado como adapter).
+
+## Qué hace
+
+- **`RUBRIC.md`** (template en `templates/`): criterios `- [ ] RB-01 (peso 3) — …`
+  con anchor-pass/anchor-fail (calibran al grader, el engine no los parsea),
+  criterios negativos `RB-NEG-nn` (si aparecen, restan su peso) y `threshold: 0.NN`.
+- **`spec-check --rubric`**: estructura = HECHO (archivo ausente, cero criterios
+  positivos, IDs duplicados normalizados, threshold ausente o fuera de (0,1] →
+  exit 1).
+- **`rubric-ingest`** (subcomando 23): valida el contrato (IDs desconocidos =
+  error — el grader no inventa criterios), aplica **evidence-or-nothing** (un
+  veredicto que afecta el score sin cita `file:line` NO puntúa y se lista como no
+  sustentado), computa el score ponderado vs threshold y persiste un registro
+  `rubric:grade` en el ledger. **Advisory por default**: BELOW no gatea. Con
+  `--gate` o `defaults.rubric.gate: true` (procedencia: declaración humana), un
+  BELOW escribe registro gateado → bloquea convergencia y capea readiness ≤65 por
+  la maquinaria existente; un grade limpio posterior lo levanta (latest-wins).
+- **readiness**: muestra el último grade por repo como línea advisory — NO es
+  dimensión con peso (measured beats narrated).
+- **doctor**: si `defaults.rubric.file` está declarado, chequea existencia y
+  estructura (aviso con remedio).
+- **`specloop-rubric`** (7ma skill): el adapter de Claude Code — contexto aislado
+  (solo diff + rúbrica, jamás el razonamiento del maker), sesgo a `fail` ante la
+  duda, y prohibido declararse el gate a sí misma.
+
+## Hardening (review fresco pre-commit, 4 hallazgos aplicados)
+
+- `threshold: 0.8.0` (malformado) crasheaba con ValueError cruda → se trata como
+  ausente y bloquea con mensaje.
+- Entradas no-dict en `criteria` crasheaban → contrato roto, error explícito.
+- **IDs duplicados en el reporte** (RB-01 y RB-1 del mismo criterio): el último
+  pisaba al primero en silencio — vector de gaming del grader → contrato roto,
+  un veredicto por criterio.
+- El check de smoke "convergencia bloqueada por el gate" era VACUO (converged ya
+  salía 1 en ledger virgen por 'no agent steps') → el fixture ahora converge
+  ANTES, y se verifica además que un grade limpio LIBERA la convergencia
+  (latest-wins).
+
+## La ventaja (por qué entra al método)
+
+El criterio cualitativo (convenciones, ergonomía de API, sanidad del error
+handling, calidad de docs) hoy vivía en la cabeza de cada pase de QA. Ahora es
+**versionado, diffeable, auditable** (cada veredicto con evidencia al ledger) y
+**portable** (viaja en el repo; cualquier humano/agente hereda el estándar).
+Anchors + negativos bajan la varianza del grader.
+
+## Límite honesto
+
+Nicho más chico que en la era en que se evaluó la idea: el acceptance trazable
+(1.10.0) ya cierra lo testeable — esta capa cubre SOLO lo genuinamente cualitativo,
+y siempre como guess estructurado: nunca reemplaza un gate duro.

package/uscha-kit/CHANGELOG-1.24.0.md

@@ -0,0 +1,50 @@
+# dev-loop-kit 1.24.0 — plugin de Claude Code (2026-07-03)
+
+El kit ahora se distribuye como **plugin instalable** para Claude Code — el repo es
+su propio marketplace. Los schemas se verificaron contra los docs oficiales
+(code.claude.com/docs: plugins, plugins-reference, plugin-marketplaces,
+discover-plugins) ANTES de escribir una línea — formato de tool real jamás se
+inventa. Smoke suite: 140/140.
+
+## Instalación (Opción C, la recomendada para Claude Code)
+
+```
+/plugin marketplace add andresmassello/SPEC-LOOP
+/plugin install specloop@specloop
+```
+
+- Las 7 skills quedan como `specloop:specloop-*` (el namespace del plugin se suma
+  al prefijo propio — mismo patrón que sonarqube:sonar-*).
+- **El hook INV-GOLDEN-01 se auto-registra** (`hooks/hooks.json` con
+  `${CLAUDE_PLUGIN_ROOT}`): desaparece la edición manual de settings.json que la
+  instalación global requería. Linux: el hook sigue siendo PowerShell — pwsh +
+  ajuste del comando (el doctor lo señala con remedio).
+- Updates versionados: el plugin declara `version`, así que `/plugin update`
+  solo actualiza con bump de release.
+- **Cero reestructuración**: `plugin.json` soporta path custom de skills
+  (`"skills": "./.claude/skills/"`) — el layout canónico del kit no cambió, y
+  las Opciones A (por proyecto) y B (global copy/junctions) siguen intactas
+  para Codex/Gemini/Cursor. El plugin es EMPAQUETADO, no dependencia: el
+  agnosticismo no se negocia.
+
+## Qué se agregó
+
+- `dev-loop-kit/.claude-plugin/plugin.json` — manifest (name `specloop`,
+  skills path custom, hooks auto-registrados, MIT).
+- `dev-loop-kit/hooks/hooks.json` — registro PreToolUse del hook del golden
+  vía `${CLAUDE_PLUGIN_ROOT}`.
+- `.claude-plugin/marketplace.json` (root del repo) — el marketplace `specloop`
+  con source relativo `./dev-loop-kit`.
+- **doctor**: tercer modo de instalación detectado (`plugin`, path bajo
+  `~/.claude/plugins/`); en modo plugin el hook cuenta como registrado si
+  `hooks/hooks.json` existe (auto-registro — settings.json ya no participa).
+  JSON expone `plugin_install`.
+- **Smoke T44 — el sync de versión ahora es un HECHO**: VERSION =
+  config.version = plugin.json.version = marketplace.version, o la suite falla.
+  La regla 6 del repo pasa de triple a **quíntuple** (con CHANGELOG).
+
+## Nota para la máquina del autor
+
+Los junctions de la Opción B y el plugin no deben convivir (skills duplicadas):
+la máquina donde se desarrolla el kit se queda con junctions (siempre al día con
+main); el plugin es el canal para las demás máquinas y terceros.

package/uscha-kit/CHANGELOG-1.25.0.md

@@ -0,0 +1,55 @@
+# dev-loop-kit 1.25.0 — anti-ceremonia: Lean sobre el propio método (2026-07-04)
+
+Origen: el kit llegó a 23 subcomandos, 7 skills, hooks y una CONSTITUTION de 7
+invariantes. El riesgo #1 dejó de ser un gate malo — es la **suma** de gates buenos
+volviendo `/dev-loop` una auditoría. Eso es *over-processing*, muda de ceremonia
+(Poppendieck cap. 4). Este release aplica Lean a la herramienta misma: una
+meta-invariante que gobierna qué gate futuro entra, y el cambio de UX que la hace
+real — **un veredicto único**. Smoke suite: 148/148.
+
+## Qué hace
+
+- **Meta-invariante "Anti-ceremonia"** (`templates/CONSTITUTION.md`): la prueba ácida
+  que TODO gate futuro debe pasar antes de entrar — (1) corre sin que el humano tipee
+  nada, (2) habla solo cuando importa, (3) colapsa en `readiness`, (4) un cambio
+  trivial lo saltea. Es principio + criterio de review, no un check del engine.
+- **Veredicto único en `readiness`** (la regla 3, mecanizada): por default `readiness`
+  es UNA pantalla — la línea de veredicto, los warnings condicionales que sí dispararon
+  (habla solo cuando importa) y una línea `--- gates:` que **colapsa** cada fact gate
+  persistido (`gate:*`, `rubric:grade`, `blocker:*`) en `N ok · M bloqueando
+  (repo/gate…)`. `--verbose` abre la tabla de dimensiones, el resumen
+  acceptance/coverage/churn y el desglose por repo.
+- **`readiness --json`** gana una sección `"gates"` aditiva (la consume sys-doc/CI).
+
+## Decisión de acople: presentación, no re-peso
+
+El rollup **lee hechos ya persistidos en el ledger — jamás recomputa el score**. Un
+gate es "bloqueando" sii su último registro gateó ≥1 finding (`gated_reported > 0`),
+que es exactamente la señal que ya alimentaba el cap ≤65. Consecuencia dura: el número
+de readiness es **idéntico** al de 1.24.0 — el smoke lo prueba (las ~30 aserciones de
+readiness previas siguen verdes sin tocarse). No entra como dimensión ponderada: plegar
+sub-scores al peso rompería el anti-Goodhart (la dimensión dominante es measured-
+acceptance a propósito).
+
+## Qué NO entra (y por qué)
+
+- **Perfiles de riesgo A–E mecanizados**: la regla ácida 4 ("un cambio trivial lo
+  saltea") es principio hasta que exista el clasificador. Los perfiles hoy son doctrina
+  (CONSTITUTION/SKILL), no máquina — el engine no tiene `--profile`. Mecanizarlos es su
+  propio ADR (¿por tamaño de diff? ¿por paths? ¿por declaración?), release aparte.
+- **`rebuild` en el rollup**: es eje de completitud (COVERS/PARTIAL/DIVERGE), no un
+  gate pass/fail; no tiene `--kind` en `log-gate` y queda fuera a propósito.
+
+## Smoke (T45, 8 checks nuevos)
+
+Ledger fresco aislado: default emite el veredicto y **colapsa** dimensiones y by-repo;
+`--verbose` los expande; un `log-gate --kind simplicity --verdict fail` aparece nombrado
+en la línea de gates; un grade limpio posterior (latest-wins) la libera; `--json`
+expone `gates[]` con `blocking` correcto.
+
+## Límite honesto
+
+El rollup mejora la **legibilidad**, no cambia qué se mide: los mismos hechos, una sola
+pantalla. La meta-invariante es disciplina — su valor depende de que se aplique al
+admitir cada gate futuro (empezando por `waste-check`, que por eso entrará
+advisory-first y default-quiet, no como BLOCKER).

package/uscha-kit/CHANGELOG-1.26.0.md

@@ -0,0 +1,70 @@
+# dev-loop-kit 1.26.0 — REUSE-FIRST: la muda que el gate no veía (2026-07-04)
+
+Origen: el handoff anti-ceremony+reuse+compliance, ítem 2. La muda dominante del
+código IA —**duplicación / reinvención en vez de reuso**— caía en el punto ciego del
+kit: `simplicity-check` puntúa el diff en AISLAMIENTO, nunca contra lo que ya existe.
+Evidencia: GitClear *Maintainability Gap* (2026): +81% de duplicación desde 2023,
+código refactorizado/movido en 3,8%. Entra con el acople corregido respecto del
+handoff original: **advisory-first**, no BLOCKER-por-default. Smoke suite: 157/157.
+
+## Qué hace
+
+- **`qa_ledger.py waste-check`** (subcomando 24): detección determinística de clones
+  Type-1/Type-2 del diff **vs el repo** (stdlib, sin LLM, sin red).
+  - Input igual que `simplicity-check` (`--diff` · `--from-git [--base]` · stdin) +
+    `--repo-root` para escanear lo existente.
+  - Ventana de `W=5` líneas normalizadas (strip + colapso de whitespace, se descartan
+    blancas y comment-only; una línea < `min_line_len` u sólo-puntuación no es
+    significativa). Métricas: `dup_windows_vs_repo` (la señal dominante),
+    `dup_windows_internal`, `dup_ratio`, `call_density` (informativo).
+  - Bandas `LEAN ≥85 · ACCEPTABLE ≥65 · WASTEFUL <65`. Flags accionables que nombran
+    el `archivo:linea` a reusar. `--json` con el contrato completo.
+  - Excluye tests (como simplicity) y **los archivos que el diff toca** (no auto-match):
+    captura el caso dominante — clon en archivo nuevo / desde archivos no tocados.
+- **`log-gate --kind waste`**: persiste el veredicto → entra al veredicto único de
+  `readiness` (1.25.0) como línea `gate:waste` y, si gateado, capea ≤65 / bloquea
+  convergencia por la maquinaria existente.
+- **`defaults.waste`** en config: `window_size`, `max_dup_windows_vs_repo`,
+  `max_dup_ratio`, `min_line_len`, `allow_paths` (boilerplate legítimo), `gate`.
+- **CONSTITUTION**: invariante **REUSE-FIRST** framed honesta (ver abajo).
+- **SKILL** Fase 2c: corre `waste-check` junto al simplicity gate; en perfil A (trivial)
+  no corre.
+
+## Decisión de acople: advisory-first (corrige el handoff)
+
+El handoff proponía `WASTEFUL → exit 1` + hard cap POR DEFAULT. Eso viola la
+meta-invariante anti-ceremonia (1.25.0) regla 2: un detector Type-1/2 *habla siempre*
+(boilerplate, DTOs, SQL/JSON embebido) → si bloquea por falsos positivos, se desactiva
+y muere. Split honesto: el **HECHO** (un bloque de 5+ líneas ya existe en `X:linea`) es
+medido; el **VEREDICTO** "wasteful" es heurística. Por eso: **avisa por default** (exit
+0 con flags), gatea SOLO con `defaults.waste.gate: true` o `--gate` (procedencia 1.17.0:
+el config commiteado ES la declaración). Un WASTEFUL declarado-gate persiste registro
+bloqueante; sin declarar, sólo aconseja.
+
+Nota: esto ELIMINA la dependencia de los perfiles A–E (que no están mecanizados): un
+advisory default-quiet no necesita el perfil-skip para no ser ceremonia.
+
+## Desviaciones honestas del handoff
+
+- **`connectivity` NO puntúa** — se reporta informativa (como `new_functions` en
+  simplicity). "Densidad de llamadas a símbolos existentes" es un proxy que
+  false-positivea entre lenguajes; scorearlo sería ruido. Peso movido a
+  `repo_reuse 55 · internal_dup 45`.
+- **`max_dup_windows_vs_repo: 0` por default** es seguro PRECISAMENTE porque es
+  advisory: cualquier clon vs repo baja el score y avisa, sin bloquear. Quien gatea
+  sube el budget o usa `allow_paths`.
+
+## Smoke (T46, 9 checks)
+
+Repo sintético `wrepo/` + 4 fixtures: LEAN (código único → 0 clones), clon-vs-repo
+(→ WASTEFUL, advisory exit 0, flag nombra el original; con `--gate` exit 1), clon
+interno (`dup_windows_internal ≥ 1`), clon en archivo de TEST (excluido). Más:
+determinismo (misma entrada → mismo score) y `log-gate --kind waste` visible en el
+veredicto único de readiness.
+
+## Límite honesto
+
+Proxy Type-1/Type-2 sobre líneas normalizadas, NO detección semántica (Type-3/4:
+renombres/reordenamientos) ni CC por AST. Es la definición operativa de GitClear —
+suficiente para AVISAR, no para probar equivalencia semántica. El escaneo del repo es
+O(archivos·líneas); en un monorepo enorme es un one-shot, no corre en cada pase.

package/uscha-kit/CHANGELOG-1.27.0.md

@@ -0,0 +1,45 @@
+# dev-loop-kit 1.27.0 — First-Time Yield: el KPI Lean que ya estaba en los datos (2026-07-04)
+
+Origen: el handoff anti-ceremony+reuse+compliance, ítem 3 (parte pasiva). FTY
+(First-Time Yield) es la métrica Lean clásica de calidad de proceso: qué fracción
+del trabajo salió bien **al primer intento**, sin reprocesos. El ledger ya tenía los
+datos (ciclos, regresiones, escalaciones) — sólo faltaba leerlos. Smoke suite: 161/161.
+
+## Qué hace
+
+- **`summary` reporta `first_time_yield`**: % de repos que pasaron QA **en el primer
+  ciclo** — sin segundo pase, sin regresiones nuevas, sin escalación (resuelta o no: una
+  intervención humana significa que NO salió a la primera). Derivado 100% de hechos ya
+  en el ledger (`node["iterations"]` con su número de ciclo, `new_regressions`,
+  `ledger["escalations"]`).
+- Aparece en `summary` (texto + `--json` con `by_repo` detallado). Va en la
+  retrospectiva.
+
+## Por qué pasivo e informativo (NO gatea)
+
+Cumple la meta-invariante anti-ceremonia (1.25.0): **cero paso humano nuevo** (sale de
+datos ya registrados) y **no es otra pantalla** (una línea en el summary que ya existía).
+Y es explícitamente **informativo, jamás gate ni dimensión del readiness**: FTY mide el
+PROCESO (¿cuánto reproceso hubo?), no el ESTADO del resultado. Meterlo al readiness
+confundiría las dos cosas — readiness reporta si el resultado está listo, FTY reporta
+qué tan limpio fue el camino. Son ejes distintos y se reportan aparte (como churn).
+
+## Definición (de hechos del ledger)
+
+Un repo cuenta como *first-time yield* sii: entró a QA (tiene iteraciones) **y** su ciclo
+máximo es 1 **y** cero `new_regressions` **y** no tuvo escalación. `pct = first_time /
+repos_que_entraron_a_QA`. Repos que nunca entraron a QA no cuentan en la base.
+
+## Smoke (T47, 3 checks)
+
+Dos repos: uno limpio al ciclo 1 (first-time), otro que necesitó 2 ciclos → FTY 50%,
+visible en texto y `--json`. Y una escalación sobre el repo limpio lo saca del yield
+(→ 0%), probando que la intervención humana cuenta como reproceso.
+
+## Nota: compliance-map DIFERIDO
+
+El ítem 3 del handoff traía también `compliance-map` (tabla requisito↔gate para dominios
+auditados). Se DIFIERE: es tooling de auditoría sin consumidor auditado real todavía —
+construirlo ahora sería especulativo (choca con el YAGNI del propio kit). Entra cuando
+haya un consumidor que lo pida; el diseño (proyección del ledger, genérico, "trazabilidad"
+no "compliance") ya está pensado en el handoff.

package/uscha-kit/CHANGELOG-1.28.0.md

@@ -0,0 +1,35 @@
+# dev-loop-kit 1.28.0 — acceptance medido: el "% terminado" que el kit puede firmar (2026-07-05)
+
+Origen: la pregunta del humano — "¿se puede computar un % de proyecto terminado?".
+Análisis: un % ponderado por etapa es progreso NARRADO y gameable (choca measured-beats-
+narrated + anti-Goodhart). El único "% terminado" honesto es el **acceptance medido**:
+criterios cerrados por un test verde name-tagged / total. El ledger ya lo tenía; faltaba
+superficiarlo. Smoke suite: 177/177.
+
+## Qué hace
+
+- **`readiness` reporta `acceptance.measured_pct`**: el % de criterios AC cerrados MEDIDO
+  (`measured_closed / total`), NO el ratio de checkboxes. En `--json` (campo aditivo) y en
+  la **vista default** como una línea: `acceptance medido: 33.3% (1/3 criterios cerrados
+  por test verde — medido, no gatea)`.
+- **Honesto por construcción**: la línea aparece SOLO con trazabilidad AC-n
+  (`acc_traceable and total`). Sin AC-IDs no hay % honesto → no se muestra nada (un %
+  sobre checkboxes sin test sería narrado, justo lo que el kit rechaza). `measured_pct`
+  es `null` en ese caso.
+- **Informativo, jamás gatea**: es una lectura del hecho ya medido, no un gate ni una
+  dimensión nueva. Cumple la meta-invariante anti-ceremonia (1.25.0): un número medido
+  que "habla cuando importa" (hay criterios trazables), colapsado en readiness.
+
+## Por qué NO un % ponderado por etapa
+
+Se descartó explícitamente: asignar pesos a discovery/build/QA/… y mostrar una barra es
+un burndown — progreso narrado ("en fase 5 de 8" no dice si lo hecho está correcto) y
+gameable (tildar etapas mueve el número = el "done" prematuro que el método combate). El
+"dónde estamos" ya lo da `phase` (FSM derivada); el "cuánto del spec está probado" lo da
+este acceptance-%. Dos ejes medidos, ninguno narrado.
+
+## Smoke (T29 extendido, 3 checks)
+
+Sobre el fixture AC-trazable existente (AC-01 verde, AC-02 rojo, AC-03 sin marcar):
+`measured_pct == 33.3` en `--json`; la línea `acceptance medido: 33.3%` visible en la
+vista default; y —clave— con un ACCEPTANCE sin AC-IDs la línea NO aparece (honesto).

package/uscha-kit/CHANGELOG-1.29.0.md

@@ -0,0 +1,20 @@
+# uscha-kit 1.29.0 — rebrand: spec-loop -> Uscha (2026-07-05)
+
+La metodologia se renombra a **Uscha**. Rebrand completo: la marca, las 7 skills
+(specloop-* -> uscha-*, comandos /uscha-discovery etc.), el plugin (specloop -> uscha),
+el kit (dev-loop-kit -> uscha-kit), el config (dev-loop.config.json -> uscha.config.json)
+y el paper (docs/paper/uscha-paper.*). Cambio BREAKING: los slash-commands cambian de
+prefijo.
+
+## Que NO cambio
+- Los subcomandos de qa_ledger.py (readiness, waste-check, gate-check, ...) y el propio
+  qa_ledger.py: nombres neutros, sin marca.
+- El hook block-approved-writes.ps1: nombre neutro.
+- Los CHANGELOGs historicos y audits/: registro, se dejan verbatim.
+- El remoto GitHub (SPEC-LOOP) y la carpeta local del checkout: fuera de alcance (rename
+  de repo/filesystem es otra operacion).
+
+## Verificacion
+- Smoke 177/177 (la suite y sus paths se actualizaron al nuevo kit).
+- Sync quintuple 1.29.0 (T44).
+- rg --hidden 'spec.?loop' sin colgados fuera de los historicos protegidos.

package/uscha-kit/CHANGELOG-1.3.0.md

@@ -0,0 +1,74 @@
+# dev-loop-kit 1.3.0 — "facts block, wired" (2026-07-01)
+
+Release temático: el kit ahora **cumple su propio principio de cabecera**. Dos auditorías
+adversariales (7 lentes de metodología + fidelidad doc↔código↔idea, 231 agentes) encontraron
+que los fact-gates existían pero no alimentaban ni convergencia ni readiness, mientras que
+los números auto-reportados del agente sí. 1.3.0 invierte eso de vuelta: *under-claim,
+then wire, then re-claim*.
+
+## Engine (qa_ledger.py)
+
+### Nuevo
+- **`log-gate`** — persiste el veredicto de un fact gate (golden-diff / gate-check /
+  pit-check / simplicity) como record static-gate-shaped: `fail` → BLOCKER que capea
+  readiness ≤65 y bloquea convergencia; `pass` → limpia el gate (latest-per-tool);
+  `not-run` → evento registrado que NUNCA lee como verde (la ausencia no es evidencia).
+- **`flag-blocker [--resolve]`** — violación de CONSTITUTION/invariante como BLOCKER de
+  primera clase por la MISMA plomería que un BLOCKER de linter. El enforcement "capea ≤65 y
+  bloquea convergencia" ahora es real una vez registrada la violación.
+- **`resolve-escalation`** — cerrar el gate humano es un evento registrado (`resolved_at`),
+  no una implicación.
+
+### Endurecido
+- **readiness**: un repo linteable cuyo static gate nunca corrió puntúa UNMEASURED (0.0),
+  no 1.0 — *el silencio no es éxito*. La dimensión agregada es el promedio per-repo (que ya
+  codifica UNMEASURED). El cap de escalación es independiente de converged y se sostiene
+  hasta `resolve-escalation`.
+- **converged**: con `qa_tools_order` exige el último step POR HERRAMIENTA (rellenar la
+  ventana con steps limpios ya no esconde findings) y un snapshot rojo MEDIDO veta el verde
+  narrado del agente (`--tests-passed`).
+- **gate-check**: borrado de archivo de test entero (`+++ /dev/null`) ya no es invisible;
+  thresholds bajados O borrados se detectan cross-hunk por keyword; con `--repo` compara los
+  totales de tests ejecutados entre snapshots (caída medida → REVIEW).
+- **golden-diff**: cero fixtures = **NOT-RUN (exit 2)**, nunca CLEAN — también en `--json`
+  (antes reportaba CLEAN con 0 comparaciones).
+- **simplicity-check**: min-floor en dims pesadas — un diff >1.5× del presupuesto de
+  tamaño/crecimiento no se promedia a ACCEPTABLE con dims baratas verdes.
+- **spec-check**: veredictos partidos por la propia regla del kit — los 2 chequeos
+  ESTRUCTURALES (falta out-of-scope / sin criterios de aceptación) son HECHOS y bloquean
+  (exit 1); la prosa (vagos/EARS/stack) sigue advisory (`--strict` gatea).
+- **oscillation**: detecta por Jaccard ≥0.8 sobre finding_ids (períodos 2-3) — un finding-ID
+  corrido ya no esconde el loop; fallback al fingerprint exacto.
+
+## Hook (block-approved-writes.ps1)
+- Bloquea CUALQUIER comando Bash que referencie un path `.approved` (la co-ocurrencia de
+  keywords era bypasseable vía `python -c "open(p,'w')"` / paths por variable / dd).
+
+## Skill dev-loop (SKILL.md)
+- Línea de audiencia arriba de todo: *un operador, un cambio con riesgo, ledger, human gate*
+  — y disclaimer NOT-for-trivial.
+- Contrato de dos tiers explícito: medido (puede bloquear) vs auto-reportado (narración).
+- **El golden ahora es alcanzable desde el camino principal**: captura en Phase 1 (perfil E,
+  vía `characterize`/`reverse-discovery`), `golden-diff` + `gate-check` persistidos con
+  `log-gate` en cada pass de Phase 3 (3b), hook + `.gitattributes` en Setup.
+- Convergencia documentada como es: per-tool + fact gates + snapshot veta narración.
+- CONSTITUTION: se registra con `flag-blocker` (obligación del agente), enforcement del
+  engine después del registro — se eliminó el "by construction" sin mecanismo.
+- readiness: sin `--section` en el llamado documentado (un heading mismatch cereaba la
+  dimensión más pesada en silencio); UNMEASURED documentado.
+- sys-doc degradado a reporting opcional (era la instancia más clara de scope creep).
+- `improve-deep` → `improve` (la skill real); protocolo tracked-md generalizado.
+
+## Kit
+- `dev-loop.config.json`: version 1.3.0, `qa_tools_order` con `improve`, repos de ejemplo
+  genéricos (`backend-api`/`mobile-app` — antes traía repos del proyecto del autor).
+- `templates/CONSTITUTION.md`: enforcement honesto (flag-blocker), CWE-1124 para anidación
+  (era 1121), tag CWE-1074 removido de YAGNI (no mapea).
+- `README.md`: las SEIS skills (faltaban `characterize` y `reverse-discovery` — justo donde
+  vive el flujo golden), on-ramp de migración, subcomandos nuevos, audiencia, generalización.
+- `workbench-doctor.sh`: sonda characterize/reverse-discovery/improve (sin improve-deep).
+- `VERSION`: 1.3.0.
+
+## Deferido (consciente, no olvidado)
+- rebuild: densidad de asserts por test-file en la firma (anti tests-preservados-destripados).
+- Perfiles A-E mecanizados en config (`--profile`). Hoy: heurística de proceso, marcada como tal.

package/uscha-kit/CHANGELOG-1.30.0.md

@@ -0,0 +1,46 @@
+# uscha-kit 1.30.0 — gate de dependencias: supply-chain hecho visible (2026-07-05)
+
+Origen: intake de research (SLR de agentic-AI arXiv:2605.15245 + survey de seguridad de
+agentes). De los 4 papers, la única mejora genuina y doctrina-pura: el modelo de amenaza
+"el agente mete una dependencia sin vetear (o envenenada)" — que Uscha no cubría. La
+CONSTITUTION ya dice "0 dependencias nuevas sin aprobación", pero como **prosa**. Esto la
+hace visible. Smoke suite: 181/181.
+
+## Qué hace (mínimo, sin overengineering)
+
+- **`gate-check` flaguea dependencias nuevas** como señal **BLANDA** (avisa; gatea con
+  `--strict`), NO como subcomando nuevo: una dep nueva es exactamente la categoría que
+  `gate-check` ya cubre ("el cambio hace algo que necesita sign-off humano" — tests
+  borrados, thresholds bajados, secretos). Reusa toda la maquinaria: cero config nuevo,
+  cero subcomando.
+- Detecta líneas AGREGADAS con forma de dependencia en los manifests de los 9 stacks
+  (`package.json`, `requirements*.txt`, `pyproject.toml`, `Cargo.toml`, `go.mod`,
+  `pom.xml`, `build.gradle(.kts)`, `Gemfile`, `Podfile`, `*.csproj`). En `--json`:
+  campo `new_dependencies`.
+- **Advisory por default**: verdict `REVIEW`, exit 0. Con `--strict`, la señal blanda
+  (deps + supresiones + asserts removidos) gatea exit 1.
+
+## Por qué así (decisiones de la doctrina)
+
+- **NO subcomando nuevo** — hubiera sido fragmentación/ceremonia. Extender `gate-check`
+  es el tamaño correcto: mismo concepto (integridad del cambio), misma maquinaria.
+- **Blando, no BLOCKER** — agregar una dependencia suele ser legítimo; solo necesita que
+  un humano la vea. Bloquear por default mataría el gate (se desactiva). El humano
+  declara `--strict` si su dominio lo exige (procedencia, misma doctrina que 1.17.0).
+- **Heurística honesta** — matcheo de líneas por manifest, no un resolver semántico de
+  dependencias. Un falso positivo (bump de versión, key no-dep) es benigno porque es
+  advisory. Documentado en el código.
+
+## Lo que NO entró del intake (anti-overengineering)
+
+- **Ruteo de modelo por perfil de riesgo** (de ALMAS, arXiv:2510.03463): diferido —
+  depende de mecanizar los perfiles A–E (que no existen) y vive en la capa de
+  orquestación, no en el engine model-agnostic.
+- **Meta-RAG / índice de repo**: diferido — no hay problema de perf medido en el walk del
+  waste-check; índice especulativo = YAGNI.
+
+## Smoke (T7b, 4 checks)
+
+Dep nueva en `package.json` → `REVIEW` + listada en `new_dependencies`; sin `--strict`
+exit 0 (advisory); con `--strict` exit 1; y un diff de código normal NO flaguea dep
+(sin falso positivo).

package/uscha-kit/CHANGELOG-1.31.0.md

@@ -0,0 +1,59 @@
+# uscha-kit 1.31.0 — freshness de evidencia + gate de doc-version (2026-07-05)
+
+Origen: review externo (Codex) que encontró al kit fallando su **propia** regla de
+truth-pass. Dos findings reales, un aprendizaje meta: *lo que no mecanizás, deriva*.
+Smoke suite: 185/185.
+
+## #3 — Freshness de evidencia (el que ataca el core)
+
+`gate-check`/`readiness` cerraban o vetaban un AC por el testcase JUnit sin chequear si
+el reporte estaba **vigente**. Un `TEST-*.xml` viejo (surefire/gradle no lo limpian sin
+`clean`) podía mantener un AC en falso-verde o vetarlo en falso-rojo. Evidencia stale
+no es evidencia — atacaba directo "la evidencia decide".
+
+- **`_ac_tags` descarta reportes STALE**: un reporte más viejo que el código fuente del
+  repo (correlación `mtime(fuente) > mtime(reporte)`) se DESCARTA. Un AC respaldado solo
+  por reportes stale queda **UNMEASURED** — el mismo patrón honesto que el engine ya usa
+  para coverage/static que no corrió, nunca falso-verde ni falso-rojo.
+- **Por qué correlación con la fuente y no advisory** (a diferencia de waste/deps): acá
+  honrar evidencia stale rompería el núcleo del método. La correlación no tiene falso
+  positivo en el flujo real (editar → testear deja el reporte como lo más nuevo) y sí
+  detecta el caso peligroso (tests no re-corridos). Sin fuente que correlacionar (repo
+  sin código) → nunca marca stale (evita falso positivo).
+- Campo `stale_reports` en `readiness --json` + advisory en la vista default.
+- **Scope honesto**: `junit_test_count` (el conteo *aproximado*) mantiene el límite —
+  su blast radius es menor (no cierra ACs). Diferido, documentado en el código.
+
+## #1/#2 — Doc drift + gate de doc-version (el meta-fix)
+
+El README raíz declaraba v1.24.0 / 23 subcomandos / 139 smoke mientras el engine estaba
+en 1.30.0 / 24 / 181; el README del kit copiaba un `uscha-devloop.config.json` inexistente
+y decía "6 skills" (son 7). El sync era QUÍNTUPLE pero solo cubría 5 archivos-máquina;
+los README se truth-passeaban por **disciplina, no por máquina** — y la disciplina derivó.
+
+- **READMEs corregidos** (raíz + kit): versión, conteo de subcomandos, cadena de
+  changelog, filename del config, conteo de skills, y el título `# dev-loop kit` →
+  `# uscha-kit` (miss del rebrand).
+- **`gate de doc-version` mecanizado** (smoke T52): un marcador invisible
+  `<!-- uscha:version -->` en la línea canónica de versión de cada README; el smoke
+  verifica que coincida con `VERSION`. Robusto sin falso positivo: la cadena de changelog
+  lista todas las versiones históricas legítimamente, así que solo se gatea la línea
+  marcada. Esto extiende el T44 (sync quíntuple) a los docs.
+
+## Lo que NO entró del review (con criterio)
+
+- **#4 CONSTITUTION detección-por-agente**: by-design y documentado; muchos invariantes ya
+  se mecanizan (simplicity/waste/gate/golden/pit). Un evento "constitution reviewed" es
+  candidato futuro, no urgente.
+- **#5 contrato de QA vendor-neutral** + **#8 acoplar cierre de AC ↔ pit-check**: válidos,
+  doctrina-consistentes; van al backlog (el mecanismo #8 ya existe — falta el acople).
+- **#6 separar spec canónica del adapter Claude**: higiene de docs, no defecto.
+- **#7 partir `qa_ledger.py`**: NO. Partir un archivo estable con 185 smoke checks es el
+  "refactor de lo que no está roto" que el propio CLAUDE.md prohíbe; YAGNI hasta que la
+  concentración cause un bug real.
+
+## Smoke (T51 + T52, 4 checks)
+
+T51: reporte fresco → AC-1 cierra medido, `stale_reports` vacío (sin falso positivo);
+código más nuevo → reporte STALE descartado, AC-1 UNMEASURED; advisory visible.
+T52: los dos READMEs declaran la versión actual (drift de docs = exit 1).

package/uscha-kit/CHANGELOG-1.32.0.md

@@ -0,0 +1,50 @@
+# uscha-kit 1.32.0 — /mirador: vista bird's-eye + `dashboard --json` (2026-07-05)
+
+La 8va skill (`uscha-mirador`) y un subcomando nuevo (`dashboard`, el 25º) que pinta el
+estado del proyecto de un vistazo. **Read-only, determinista, cero narración del LLM.**
+Smoke suite: 189/189.
+
+## Pieza 1 — `qa_ledger.py dashboard [--json]`
+
+Agrega SOLO estado que el ledger YA tiene al contrato `DATA` del template mirador
+(readiness, subscores, phases, specs, adrs, inv, capas, loops, snapshots, evidence).
+`--json` imprime el objeto; sin flags, un veredicto de una línea.
+
+**Truth-pass estricto — under-claim, then wire.** Un campo sin fuente en el ledger sale
+`null`/`[]` (el template degrada), **nunca se inventa**. La honestidad primero:
+
+- **Real hoy**: `readiness` (score/band, reusando `readiness --json` VERBATIM — mismo KPI,
+  sin drift), `subscores.coverage`, `subscores.{simplicity,waste,rebuild,golden}` desde
+  los gates persistidos (`_gate_rollup`; `val` = null porque el ledger guarda pass/fail,
+  no un score 0-100), `loops` (iters + estado por repo), `inv` (7 nombres fijos; status
+  del gate donde mapea, si no null), `project`, `phases` (proyección determinista del
+  readiness sobre los 8 nodos).
+- **`null`/`[]` por diseño** (el engine no lo trackea): `specs` (trackea `AC-nn`, no
+  `SPEC-nnn`), `capas` (no puntúa las 6 capas de verdad), `evidence` (steps[] es log
+  plano). Cada uno destraba un panel el día que exista la fuente — quedan en el backlog.
+
+## Add-ons aprobados (baratos y honestos)
+
+- **ADRs** (`adrs`): glob read-only de `docs/adr/*.md` (`--adr-dir` configurable) — id de
+  un token `ADR-<n>`, título del primer heading, status de una línea `Status:`. `[]` si no
+  hay dir.
+- **Time-lapse prospectivo** (`snapshots`): `readiness --record` (opt-in) persiste el
+  readiness del momento en `ledger.readiness_history`. `readiness` sigue **read-only por
+  default**; el historial se llena **solo hacia adelante** (no se backfillea). El dashboard
+  lo consume, nunca escribe. `reached` = proyección determinista del score (como la band).
+
+## Pieza 2 — skill `uscha-mirador`
+
+`SKILL.md` + `mirador.template.html`. Flujo: corre `dashboard --json` → inyecta ese JSON
+en el template reemplazando la región entre `/*MIRADOR_DATA_START*/` y
+`/*MIRADOR_DATA_END*/` → escribe `mirador.html` en la raíz del proyecto → lo abre
+best-effort (`start`/`open`/`xdg-open`), sin fallar en headless/CI. El demo del template
+queda como **fallback offline**. El skill cablea, no calcula: los números vienen del ledger.
+
+## Smoke (T53, 4 checks)
+
+Contrato completo con las 12 claves; `specs`/`capas` `[]` (truth-pass); `adrs` del glob
+(accepted→done, proposed→prog); `readiness` del dashboard == `readiness --json` (sin
+drift); `snapshots` vacío hasta `readiness --record`, luego poblado (add-on prospectivo);
+`inv` mapea el gate persistido por su kind REAL (`pit-check`→Tests efectivos, no un typo
+mudo — hallazgo del review fresco).

package/uscha-kit/CHANGELOG-1.33.0.md

@@ -0,0 +1,46 @@
+# uscha-kit 1.33.0 — mirador session telemetry (tokens / time / model, per-model) (2026-07-05)
+
+The mirador gains a **session-telemetry** strip: how many tokens, how much wall time, which
+model(s), at what effort — with a **per-model breakdown** (so you can see if the expensive
+model is being burned on cheap work). Smoke suite: 190/190.
+
+**The engine is UNTOUCHED.** `qa_ledger.py` stays model-agnostic and never sees a token —
+this is vendor telemetry (Claude Code), and it enters ONLY through the mirador skill (the
+vendor adapter). No new subcommand; 25 stays 25.
+
+## What ships (all in the `uscha-mirador` skill)
+
+- **Segregated strip in `mirador.template.html`**: labeled *"Claude Code · session telemetry —
+  vendor-reported, narrated not measured"*, dashed border, at the foot — **visually apart** from
+  the measured panels. Shows totals (tokens in/out, wall time, effort, sessions) and, when more
+  than one model was used, a **per-model row** (`opus-4-8  240k → 41k · 1.3h`).
+- **`telemetry-extract.py`** (shipped in the skill folder, stdlib, standalone): parses a Claude
+  Code session transcript (`*.jsonl`) — each assistant turn's `usage` (`input_tokens` +
+  `cache_*` + `output_tokens`) and `model` — sums per model, computes wall time from the
+  timestamps, and appends ONE line to the sidecar. Best-effort: bad/old schemas degrade, never
+  crash; no usage → nothing appended.
+- **Sidecar contract** `.uscha/telemetry.jsonl` (append-only, one JSON object per session, with a
+  `by_model` breakdown). Portable, greppable, git-ignorable. Chosen over `localStorage` because a
+  real inspectable artifact is coherent with the doctrine — you can audit where the number came
+  from. The skill reads it, aggregates across lines (merging `by_model` per model), and merges a
+  `telemetry` object into `DATA` before injection.
+
+## The doctrinal boundary (non-negotiable)
+
+Telemetry is **narrated by the vendor, not measured by the engine**. It is neither a fact-gate
+nor a guess-advisor — so it is **shown, never gated, never fed into readiness**, and rendered in
+a strip kept apart from the measured panels. Telemetry answers *"what did it cost"*; the measured
+panels answer *"is it correct"*. Mixing them would dilute *measured beats narrated* — so they stay
+apart. The mirador template also degrades: no sidecar → no strip (verified running the page's JS
+under Node, with and without telemetry).
+
+## Also
+
+- The `mirador.template.html` UI is now in **English** (it was the last Spanish-only product HTML;
+  the ES/EN decks stay bilingual by design).
+
+## Smoke (T54)
+
+A synthetic 2-model transcript → `telemetry-extract.py` → the sidecar line sums tokens
+(input + cache) and output correctly, computes wall time from the timestamps, and carries a
+2-entry `by_model` breakdown; a corrupt line is skipped, not fatal.