chore(okf): corre el vigía del estándar, que llevaba 46 días sin mirar - #658
Merged
Conversation
El pre-commit avisaba `[OKF] Vigia del estandar STALE (46 d > 30 d)` en cada
commit. El vigia es la contraparte con red del guard offline: baja el SPEC.md
pineado, compara su hash contra el lock y refresca `checkedAt`; el hook lee ese
lock sin red y avisa cuando pasa de 30 dias. Correrlo apaga el aviso, y el guard
offline ya sale limpio (exit 0, sin salida).
Pero el aviso tapaba algo mas grande, y por eso este commit NO lo sella:
locked: b9655e60... (v0.1, revisado el 2026-07-08)
upstream: 26aa5da0... -> el SPEC declara ahora **Version 0.2**
El vigia sale con exit 10 ("cambio upstream y no ha sido reconocido"). Aqui solo
se mueve `checkedAt`; `sha256` y `reviewedAt` se quedan como estaban, que es
justo la senal de "mirado, no reconocido". Hacer `--accept` habria puesto todo
verde afirmando que alguien reviso un salto de version que nadie ha revisado —
el mismo falso verde que este guard existe para evitar.
Lo que queda por decidir (revision real, no un sello): la proyeccion del ADR-0105
apunta al contrato OKF v0.1 y el upstream va por v0.2. `knowledge-okf-project.mjs`
no parsea el SPEC en runtime — solo lo cita — asi que el cambio no rompe nada
mecanicamente; es una pregunta de conformidad. El SPEC no trae changelog, de modo
que hay que diffear las 61 secciones a mano contra lo que proyectamos.
Verificacion: `knowledge-okf-precommit-guard.mjs` pasa de emitir el aviso STALE a
exit 0 en silencio.
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 pre-commit avisaba en cada commit:
El vigía es la contraparte con red del guard offline: baja el
SPEC.mdpineado, compara su hash contra el lock y refrescacheckedAt; el hook lee ese lock sin red y avisa cuando pasa de 30 días. Correrlo apaga el aviso — y el guard offline ya sale limpio (exit 0, sin salida).El aviso tapaba algo más grande
Por eso este PR no lo sella:
lockedb9655e60…— v0.1, revisado el 2026-07-08upstream26aa5da0…— el SPEC declara ahora Version 0.2El vigía sale con exit 10 ("cambió upstream y no ha sido reconocido"). Aquí solo se mueve
checkedAt;sha256yreviewedAtse quedan como estaban, que es exactamente la señal de "mirado, no reconocido".Hacer
--accepthabría puesto todo verde afirmando que alguien revisó un salto de versión que nadie ha revisado — el mismo falso verde que este guard existe para evitar.Lo que queda por decidir (revisión real, no un sello)
La proyección del ADR-0105 apunta al contrato OKF v0.1 y el upstream va por v0.2.
knowledge-okf-project.mjsno parsea el SPEC en runtime — solo lo cita en un comentario — así que el cambio no rompe nada mecánicamente; es una pregunta de conformidad. El SPEC no trae sección de changelog, de modo que hay que diffear sus 61 secciones a mano contra lo que proyectamos.Cuando esa revisión se haga, se cierra con:
Verificación
knowledge-okf-precommit-guard.mjspasa de emitir el aviso STALE a exit 0 en silencio. Confirmado en la salida del hook de este mismo commit, donde el aviso ya no aparece.Before you submit
Signed-off-byline.Linked ADRs / Issues
🤖 Generated with Claude Code