Skip to content

Merge develop into main: enlace a los esquemas canónicos de artefacto (GAP-020) - #95

Merged
beyondnetPeru merged 3 commits into
mainfrom
develop
Aug 1, 2026
Merged

Merge develop into main: enlace a los esquemas canónicos de artefacto (GAP-020)#95
beyondnetPeru merged 3 commits into
mainfrom
develop

Conversation

@beyondnetPeru

Copy link
Copy Markdown
Contributor

Promueve develop a main con el cierre de GAP-020 (#94).

Qué faltaba

PhaseArtifactCatalog le dice a un tenant que un prd es obligatorio y no le decía a nadie qué debe contener: lleva ArtifactKind, Label y Required, y ninguna referencia a la forma canónica.

La ficha tampoco tenía alcance — su next step decía literalmente "define owner and remediation action before execution", y nadie lo había hecho. Se estableció con lo medido antes de escribir nada.

Qué aterriza

docs/artifacts/CORE_ARTIFACT_SCHEMAS.md (y su espejo en castellano) enlaza los 14 artefactos que tienen esquema canónico aguas arriba, lista los 3 que son salida de herramienta, y nombra los 7 que no tienen ninguno.

Se enlaza por $id y no por ruta, a propósito: una ruta es un hecho sobre dónde está un fichero en un repositorio en un momento; el $id es la identidad publicada del esquema y sobrevive a que lo muevan.

Los nombres no coinciden mecánicamentesecurity-scan-result ⇄ Security Scan Report, rollback-plan ⇄ Rollback Procedure, observability-readiness ⇄ Observability Validation. Una herramienta que emparejara por slug fallaría en los tres, así que la correspondencia se escribe como decisión.

Fuera de alcance, a propósito

Acoplar los vocabularios. Meter las clases de artefacto del Tracker —o los tipos de evidencia que declara el tenant— en una lista cerrada del Core es lo que T-056 rechaza: la validación de contenido es configuración del tenant, no código del motor. Esto enlaza a la forma canónica; no convierte al Core en autoridad sobre lo que un tenant puede registrar.

Verificación

validate-docs, check-bilingual-parity, doc-inventory --check y check-gap-registry (203 fichas / 203 filas) en verde.

🤖 Generated with Claude Code

beyondnetPeru and others added 3 commits August 1, 2026 16:10
…les no existen (GAP-020)

`PhaseArtifactCatalog` le dice a un tenant que un `prd` es OBLIGATORIO y no le dice a
nadie que debe contener: lleva `ArtifactKind`, `Label` y `Required`, y ninguna
referencia a la forma canonica. Este es ese enlace.

La ficha no tenia alcance —su next step decia literalmente «define owner and
remediation action before execution»— asi que primero se establece, con lo medido:

· El Core declara `requiredArtifacts[].schemaRef` para 10 de 24 artefactos
  obligatorios. Los otros 14 NO tienen esquema aguas arriba, y el documento lo dice
  explicitamente: una tabla que listara solo diez filas en silencio se leeria como si
  el catalogo estuviera cubierto entero.

· DEFECTO AGUAS ARRIBA, encontrado al delimitar esto y que pertenece al Core: esos
  `schemaRef` son rutas relativas ROTAS. `../schema/prd.schema.json` resuelve desde el
  directorio de gates a `reference/governance/sdlc/schema/`, que no existe; los
  ficheros estan en `src/rulesets/schema/`. No se pueden dereferenciar como rutas.
  Lo que si es estable es el `$id` publicado de cada esquema, y a eso se enlaza.

· Los nombres NO coinciden mecanicamente: `security-scan-result` ⇄ Security Scan
  REPORT, `rollback-plan` ⇄ Rollback PROCEDURE, `observability-readiness` ⇄
  Observability VALIDATION. Una herramienta que emparejara por slug fallaria en los
  tres, asi que la correspondencia se escribe como decision y no se deriva.

· Dos artefactos —Integration Evidence y On-Call Handoff— tienen esquema arriba y
  NINGUNA clase en el catalogo. Se listan igual: quien los busque debe enterarse de
  que existen en vez de concluir que no.

FUERA DE ALCANCE A PROPOSITO: acoplar los vocabularios. Meter las clases de artefacto
del Tracker —o los tipos de evidencia que declara el tenant (`ci-result`,
`regression`)— en una lista cerrada publicada por el Core es exactamente lo que
`T-056` rechaza: la validacion de contenido es configuracion del tenant, no codigo del
motor. Esto enlaza a la forma canonica; no convierte al Core en autoridad sobre lo que
un tenant puede registrar.

Verificado: `validate-docs`, `check-bilingual-parity`, `doc-inventory --check` y
`check-gap-registry` (203 fichas / 203 filas) en verde.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… arriba (GAP-020)

El documento se escribio con 10 artefactos cubiertos. `evolith_arch32#378` llevo esa
cifra a 14, declaro 3 mas como salida de herramienta y dejo 7 sin cubrir, asi que la
tabla y las dos secciones de cola quedaban desactualizadas.

Cambia:

· La tabla pasa de 10 a 14 filas — entran Discovery Canvas y Ballpark Estimation (que
  ya existian aguas arriba y solo faltaba cablearlos) y Bounded Context Map y
  Definition of Done Checklist (esquemas nuevos).

· La seccion de rutas ya no dice que esten rotas, porque se arreglaron. Dice que LO
  ESTUVIERON, con la referencia al PR que las corrigio, y por que este documento sigue
  enlazando por `$id` y no por ruta: una ruta es un hecho sobre donde esta un fichero
  en un repositorio en un momento; el `$id` es la identidad publicada del esquema y
  sobrevive a que el fichero se mueva.

· La seccion de «los que no tienen» se parte en dos, porque piden respuestas distintas:
  TRES son salida de herramienta y no llevan esquema a proposito (se declara el formato
  que emiten), y SIETE no lo tienen todavia.

· Se explica por que `adr.schema.json` NO se cablea a `ADR Registry` aunque los nombres
  lo inviten: un registro es una lista de ADRs y no un ADR, asi que la correspondencia
  daria cobertura en el papel y un falso negativo en la practica.

Ficha de GAP-020 marcada como hecha, con las cifras reales.

Verificado: `validate-docs`, `check-bilingual-parity` y `check-gap-registry`
(203 fichas / 203 filas) en verde.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
GAP-020: enlazar los esquemas canónicos del Core, y decir cuáles no existen
@beyondnetPeru
beyondnetPeru merged commit 4d47dfc into main Aug 1, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant