Skip to content

v2.1.0 — The gate now says what it did not check

Latest

Choose a tag to compare

@juanklagos juanklagos released this 22 Jul 01:49
· 106 commits to main since this release

The gate used to be unable to tell "you may implement" apart from "nothing is approved, so there is nothing to implement". Both were green. This release fixes that, and makes the gate say out loud what it did and did not check.

What you see now

Every run ends with three lines, including the runs that pass. They cannot be suppressed:

Compuerta / Gate: CERRADA / closed — todavia no hay ninguna spec aprobada
Comprobado / Checked: politica, estructura de specs, estado de aprobacion, consentimiento, dependencias.
NO comprobado / NOT checked: si el codigo del proyecto corresponde a una spec aprobada.

That last line is the point. A green result can no longer mean "we did not look", because the gate tells you where its knowledge ends.

The verdict has three states instead of two. closed is no longer painted red — nothing approved yet is where every project starts, and colouring it as a failure teaches people to ignore the colour. Only blocked is red, and only errors produce it.

Exit codes are unchanged: 0 on success, 1 on errors. If you want the gate to actually fail your build when nothing is approved, pass the new --require-open and it exits 2. Nobody's existing CI turns red because of this release.

Four ways an unapproved spec could pass

  • A greedy regex read approved where the file said Pendiente. Both shell scripts carried their own copy of a sed that captures the last backtick pair on the line, so - Estado / Status: \Pendiente` (target: `approved`)` came back as approved in bash while TypeScript correctly read pending. There is one implementation now, and a test that compares both extractions over an adversarial table — the previous test pinned the regex constants and never the extraction, which is exactly how this survived.
  • The dashboard told users with zero approved specs that implementation was allowed, because it branched on a boolean that was true when nothing was approved and nothing was broken.
  • sdd_record_user_consent never accepted specId, though the underlying function always has. Every consent recorded through the MCP server landed as a markerless legacy entry, silently downgrading per-spec enforcement to a warning.
  • validate-sdd.sh --strict had never once run in CI. It compared git diff with no revision range, which only reports uncommitted changes; after a clean checkout there are none. It now resolves a real base ref, and the workflow needs fetch-depth: 0 for it to work.

If you started from "Use this template"

A copy of this repository arrives carrying the template's own specs and recorded approvals. They are not yours, and until you clear them your gate is reporting on somebody else's project. reset-template.sh --confirm now archives that inherited consent log instead of leaving it in place, and the gate warns you by name if you skipped it.

New: ## Ámbito de archivos / File scope

Specs can now declare which paths they govern. It is parsed and surfaced, and it enforces nothing — deliberately. The data needs to start accruing before the rule that consumes it exists, not after. A later spec will use it to check a pull request's diff against the specs that claim those files.

Full detail in the CHANGELOG. Rationale and the five rejected alternatives in the decision record.


Español

La compuerta no sabía distinguir «puedes implementar» de «no hay nada aprobado, así que no hay nada que implementar». Las dos cosas salían en verde. Esto lo arregla, y hace que la compuerta diga en voz alta qué comprobó y qué no.

Cada ejecución termina con tres líneas, también las que pasan, y no se pueden silenciar. La última es lo importante: un verde ya no puede significar «no miramos», porque la propia herramienta te dice dónde acaba lo que sabe.

El veredicto tiene tres estados. cerrada deja de pintarse en rojo: no tener nada aprobado es donde empieza todo proyecto, y pintarlo como fallo enseña a ignorar el color. Solo bloqueada es roja, y solo la producen los errores.

Los códigos de salida no cambian: 0 si va bien, 1 si hay errores. Si quieres que la compuerta tumbe tu build cuando no hay nada aprobado, pasa --require-open y sale con 2. A nadie se le pone el CI en rojo por actualizar.

Cuatro maneras en que una spec sin aprobar podía pasar: una expresión codiciosa que leía approved donde el archivo decía Pendiente; el dashboard afirmando «Implementación permitida» con cero specs aprobadas; el consentimiento por MCP cayendo siempre como línea heredada; y una comprobación de modo estricto que no se había ejecutado nunca en CI.

Si empezaste con «Use this template»: tu copia trae las specs del template y sus aprobaciones. No son tuyas. reset-template.sh --confirm ahora archiva ese registro heredado, y la compuerta te avisa por nombre si no lo hiciste.

Nuevo: ## Ámbito de archivos. Las specs pueden declarar qué rutas gobiernan. Se parsea y se muestra, y no obliga a nada, a propósito: los datos tienen que empezar a acumularse antes de que exista la regla que los usa, no después.