chore(okf): revisa OKF v0.2 y reconoce el hash; el proyector no cambia - #659
Merged
Conversation
El vigía salia con exit 10 desde el 2026-07-24: el SPEC upstream paso de v0.1
(15 KB) a v0.2 (37,7 KB), una reescritura de 2,5x. Esta es la revision que el
guard pedia, y su conclusion es que NO hay que tocar la proyeccion.
Como se reviso. Recuperados los cuatro blobs del historial upstream y hasheados
para anclar los extremos: el lock apuntaba a ee67a5ca (b9655e60..., v0.1) y el
upstream es 62432a09 (26aa5da0..., **Version 0.2**). Con los dos textos delante,
el propio SPEC trae una seccion §13 "Changes from v0.1" con §13.1 Breaking
changes — no hace falta diffear a mano las 61 secciones. (Mi primer grep buscaba
"Changelog/History/Revision" y no la vio; el dato estaba ahi.)
Las dos roturas declaradas, contra lo que emitimos:
1. `timestamp` queda superseded por `generated: { by, at }`.
Nos afecta: emitimos `timestamp: '2026-07-28'`. Pero §13.1 dice que el
consumidor MAY caer al `timestamp` legado cuando falta `generated`, asi que
el bundle sigue siendo consumible por un lector v0.2.
2. El listado `# Citations` del cuerpo queda superseded por `sources`.
NO nos afecta: emitimos cero `# Citations` (verificado sobre el bundle).
Y lo que §13 declara explicitamente que NO cambia es justo aquello sobre lo que
se apoya el ADR-0105: estructura del bundle, nombres reservados, el `type`
obligatorio, los recomendados title/description/resource/tags, cross-linking,
index, logs y la conformidad permisiva. Nuestro validador solo exige `type` no
vacio, y `--check`/`--verify` pasan (15 ficheros, 0 violaciones). El ADR-0105 ya
habia previsto este caso en su seccion de riesgos ("OKF v0.1 is young... watched
by knowledge-okf-standard-watch"), y sus afirmaciones de v0.1 siguen siendo
exactas: proyectamos v0.1, a proposito.
Por eso el lock se acepta y el proyector no se toca. Queda como mejora OPCIONAL,
no como deuda: adoptar `generated: { by: human:@winston, at: ... }` haria que un
consumidor v0.2 clasifique el corpus como autorado por humano (§5.3 keys off the
`human:` prefix) en vez de caer al `timestamp` sin procedencia. Es un cambio del
bundle publicado y una decision sobre como representamos confianza, no una
correccion.
Aparte, un fallo del propio vigia encontrado al usarlo: `--accept` reconocia el
hash y acto seguido imprimia "NO ha sido reconocido... confirma con --accept", y
mostraba en `locked:` el hash VIEJO. Se lee como que el reconocimiento fallo.
Causa: `status` solo miraba si el upstream cambio, sin distinguir lo que hizo esa
corrida. Se anade `accepted` (no toca el vocabulario de `status`, que un test
fija) y el informe pasa a decir "Cambio upstream RECONOCIDO" con el hash nuevo.
Cubierto por dos tests: 8 -> 9 en verde.
Verificacion: --check 0 violaciones, --verify al dia, guard offline exit 0, el
vigia sin flag reporta `status: ok`, y el escenario de --accept reproducido de
extremo a extremo rebobinando el lock y restaurandolo (identico byte a byte).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: aarroyo <beyondnet.peru@gmail.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
📊 Bilingual Coverage ImpactPR Changes
Repository Coverage
✅ Good: All EN changes have ES counterparts. Generated by GitHub Actions |
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request Summary
El vigía salía con exit 10 desde el 2026-07-24: el SPEC upstream pasó de v0.1 (15 KB) a v0.2 (37,7 KB), una reescritura de 2,5×. Esta es la revisión que el guard pedía, y su conclusión es que no hay que tocar la proyección.
Cómo se revisó
Recuperados los cuatro blobs del historial upstream y hasheados, para anclar los extremos sin suposiciones:
ee67a5cab9655e60…← el del lock780fe9d30f02b43f…3fcbb9f85a3311d2…62432a0926aa5da0…← upstream hoyCon los dos textos delante, resulta que el propio SPEC trae una sección §13 "Changes from v0.1" con §13.1 Breaking changes. No hacía falta diffear a mano las 61 secciones. (Mi primer grep buscaba "Changelog/History/Revision" y no la vio — el dato estaba ahí, y eso hacía la tarea mucho más pequeña de lo que anuncié.)
Las dos roturas, contra lo que emitimos
timestamp→ superseded porgenerated: { by, at }timestamp: '2026-07-28'. Pero §13.1 dice que el consumidor MAY caer altimestamplegado cuando faltagenerated→ el bundle sigue siendo consumible por un lector v0.2.# Citations→ superseded porsources# Citations(verificado sobre el bundle).Y lo que §13 declara explícitamente que no cambia es justo aquello sobre lo que se apoya el ADR-0105: estructura del bundle, nombres reservados, el
typeobligatorio, los recomendadostitle/description/resource/tags, cross-linking, index, logs y la conformidad permisiva.Nuestro validador solo exige
typeno vacío;--checky--verifypasan (15 ficheros, 0 violaciones). El ADR-0105 ya había previsto este caso en su sección de riesgos ("OKF v0.1 is young… watched byknowledge-okf-standard-watch"), y sus afirmaciones de v0.1 siguen siendo exactas: proyectamos v0.1, a propósito.Por eso el lock se acepta y el proyector no se toca.
Mejora opcional, no deuda
Adoptar
generated: { by: human:@winston, at: … }haría que un consumidor v0.2 clasifique el corpus como autorado por humano (§5.3 keys off thehuman:prefix) en vez de caer altimestampsin procedencia. Es un cambio del bundle publicado y una decisión sobre cómo representamos confianza — no una corrección. Lo dejo a tu criterio.Aparte: un fallo del propio vigía, encontrado al usarlo
--acceptreconocía el hash y acto seguido imprimía "NO ha sido reconocido… confirma con--accept", mostrando además el hash viejo enlocked:. Se lee como que el reconocimiento falló.Causa:
statussolo miraba si el upstream cambió, sin distinguir lo que hizo esa corrida. Se añadeaccepted— no toca el vocabulario destatus, que un test fija — y el informe pasa a decir "Cambio upstream RECONOCIDO" con el hash nuevo.Verificación
--check: 0 violaciones ·--verify: conforme y al día (15 ficheros)knowledge-okf-precommit-guard.mjs: exit 0, en silenciostatus: ok, exit 0--acceptreproducido de extremo a extremo rebobinando el lock y restaurándolo (idéntico byte a byte)Before you submit
Signed-off-byline.Linked ADRs / Issues
🤖 Generated with Claude Code