@ingeniomaps/cauce 0.69.0 → 0.71.0

package/CHANGELOG.md

@@ -14,6 +14,272 @@ desde este repositorio no va, porque el que lee no puede actuar sobre eso. Cuand
 unas pocas líneas casi siempre es porque cuenta cómo se descubrió el problema o por qué se eligió el
 diseño — eso vive en el commit y en el código.
 
+## [0.71.0] - 2026-09-09
+
+### Cambiado
+
+- **`planning/PROTOCOL.md` pide contrastar la línea de una tarea contra su propia descripción.** La línea
+  declara cuatro cosas —qué hace, en qué carril, quién entrega y revisa, con qué se comprueba— y las
+  cuatro las escribe la misma mano en el mismo acto, así que nada las cruzaba después. Releerlas no
+  encuentra el hueco: una aceptación incompleta se lee perfecta porque todo lo que dice es cierto.
+
+  La pasada vive al escribir la tarea y no en una fase, y la razón es que cualquier fase donde viviera es
+  una que el carril puede saltar — una tarea mal marcada `express` es justamente la que se salta la fase
+  donde alguien lo notaría.
+
+  **Lo que te pide algo**: cuesta minutos por tarea al promover un hito. En el caso que originó esto, seis
+  correcciones sobre cinco tareas, todas antes de escribir una línea de código.
+
+### Corregido
+
+- **`autobuild` comprueba su raíz en la primera fase, y lo dice nombrándola.** `ROOT` viaja escrito en
+  el workflow y es relativo a la carpeta donde se abre la herramienta: si la sesión abrió en otra, todas
+  las rutas resuelven a `<raíz>/<raíz>/…` y ninguna existe. Nada lo comprobaba, así que la corrida
+  gastaba Triage entero sobre archivos ausentes y paraba más abajo mandando a revisar el planning — que
+  está bien; lo que no existe es la carpeta de la que cuelga.
+
+- **`learning/HISTORY.md` dice lo mismo en los 53 cargos, y su fila entra en una tabla.** El encabezado
+  tenía trece redacciones distintas y nueve contradecían la tabla que llevan debajo —«registrar únicamente
+  cambios aprobados», cuando la columna se llama «Decisión» y hay dos—. Y dieciséis archivos no tenían
+  tabla: la fila que escribe el ciclo quedaba pegada al párrafo, que en markdown es texto con barras.
+
+  Los tres cargos con una exigencia propia —país, jurisdicción, revisión de Legal— la conservan como línea
+  aparte. Ninguna se cumplía, y aun así no se borraron: dos son de cargos regulatorios.
+
+- **`autobuild` ya no promueve épicas: nombra la que sigue y para.** Cuando se le acababa la cola,
+  expandía la próxima épica del roadmap al BACKLOG. El roadmap llama `open` a «candidata editable que aún
+  no fue promovida al backlog», así que pegarla en la cola es promoverla — y BR-OPS-002 deja una propuesta
+  fuera de la cola hasta que la apruebe una persona. El prompt pedía «la próxima épica abierta y
+  aprobada», y «aprobada» no correspondía a ningún dato: una épica declara `epic`, `title`, `status` y
+  `service`, y ninguno registra una aprobación.
+
+  Ahora `ops context` nombra la próxima épica sin promover —`EPIC 003: … — sin promover`, y el campo
+  `nextEpic` en `--json`— igual que ya nombraba una recurrencia vencida, y por el mismo motivo: la máquina
+  calcula, la persona encola.
+
+  **Lo que te pide algo**: si usabas `autobuild` desatendido esperando que encadenara épicas, ahora se
+  detiene al terminar el hito y hay que pegar el siguiente en `BACKLOG.md`. `context` te dice cuál es.
+
+- **El chequeo semanal de fuentes mira también `references/` y `SKILL.md`, y deja de dar por rotas las
+  páginas sanas.** Miraba sólo `sources.yaml`: las 207 URLs que un cargo cita en su método no las
+  comprobaba nadie, y 29 no servían —dos de ellas 404 de páginas movidas hacía meses—. `evaluations/`
+  queda afuera a propósito: un caso adversarial inventa dominios y comprobarlos mide el fixture.
+
+  Y el chequeo se equivocaba en las dos direcciones sobre lo que sí miraba. Se identificaba como
+  `cauce-learning/1.0`, que no es con lo que el cargo lee: las tres páginas de `ftc.gov` del catálogo dan
+  403 a ese `User-Agent` y 200 con miles de palabras a uno de navegador. Y veinte segundos no alcanzan
+  para un PDF grande —el instrumento de la OCDE que cita `sales-representative` llega pasados los
+  treinta—. Ahora lo que falla se reintenta una vez, con más tiempo y como navegador, y el resumen dice
+  cuántas lo necesitaron: que un dominio nos rechace es un dato suyo y se pierde si el reintento lo tapa.
+
+  El aviso nombra además el archivo donde está escrita cada URL, porque eso decide quién la arregla.
+
+- **Las URLs rotas del catálogo se arreglaron, no sólo se reportaron.** Veintitrés reemplazos
+  comprobados uno por uno. Casi ninguna estaba muerta: cuando un dominio bloquea suele haber otra forma
+  publicada del mismo documento —el PDF donde el HTML tiene Cloudflare (`acm.org`, los instrumentos de la
+  OCDE), otro sitio del mismo organismo (`oecd.ai`, `gov.uk`), o el feed que la propia CISA distribuye—.
+  Las cuatro que no tienen ninguna —`pmi.org`, `fatf-gafi.org`— se quedan como fuente y pierden el enlace
+  en `references/`, conservando el nombre: un 403 ahí sólo le hace perder un clic a quien lee.
+
+- **Las normas ISO del catálogo se citan por una ficha que se puede leer.** `www.iso.org` devuelve 403,
+  y 41 entradas de 22 cargos apuntaban ahí: para todas ellas la investigación semanal producía el mismo
+  informe «sin novedades» que produciría una norma que no cambió. Ahora una ISO/IEC se cita por su ficha
+  del IEC Webstore y una ISO sola por la de `committee.iso.org`, que sirve el mismo número de catálogo.
+
+  La edición pasó al nombre de las ISO/IEC —`ISO IEC 25010:2023 product quality model`— porque la ficha
+  del webstore es de una edición concreta: buscar «ISO/IEC 25010» ahí devuelve primero la de 2011.
+  Cada ficha se comprobó contra su `<title>` antes de anotarla, y `cloud-architect` pasó a declarar la
+  edición 2 de ISO/IEC 27017, publicada el 2026-07-27 — su modelo operativo decía «no tratarla como
+  publicada» y eso dejó de ser cierto. Los `references/` de esos cargos enlazaban las mismas normas a las
+  mismas URLs muertas y también se cambiaron: 40 enlaces en 22 archivos.
+
+  **Lo que te pide algo**: si forkeaste alguno de esos 22 cargos, tu copia sigue con las URLs viejas y
+  `check` te avisa que el original cambió río arriba. Vale traerlas: las viejas no responden.
+
+- **El ciclo semanal comprueba que las fuentes declaradas de un cargo respondan, y anota las que no.** Una
+  fuente ilegible y una que no cambió producían el mismo informe —«sin novedades»— y no son lo mismo: la
+  primera no se comprobó. Ahora el resumen del job dice cuántas fuentes declara el cargo y cuáles no
+  respondieron, con su código, y sale una anotación cuando hay alguna. Avisa y no falla: un 403 de una
+  semana puede ser temporal, y lo que decide una cadencia es el patrón sostenido.
+
+  Mide además **el texto que la página trae**, no sólo que responda: por debajo de 50 palabras fuera de
+  etiquetas se reporta igual que un 403, porque una aplicación renderizada por cliente devuelve su título y
+  poco más. El umbral sale de medir las 255 fuentes del catálogo — catorce caen debajo y sólo dos entre 50
+  y 200, así que no parte ningún grupo. Y un `202` se reporta aparte: es «aceptado, vuelve más tarde», que
+  es lo que contestan las seis normas europeas que el catálogo cita.
+
+- **El lector de fuentes era ciego para uno de los dos formatos del catálogo.** `sources.yaml` admite la
+  entrada repartida en varias líneas y la escrita en una sola, y sólo se leía la primera: en los seis
+  cargos que usan la segunda se veían **cero** fuentes. De ahí sale la validación que rechaza una URL
+  declarada dos veces con nombres distintos, así que esos seis nunca la tuvieron — y no fallaba nada,
+  porque no encontrar duplicados y no mirar producen el mismo silencio.
+
+- **Archivar una propuesta ahora deja quién lo decidió y cuándo.** Antes quedaba con «Responsable: por
+  definir» y ninguna fila en `learning/HISTORY.md`, así que una propuesta que alguien miró y descartó se
+  leía igual que una que nadie tocó. El responsable sale de `CAUCE_OWNER` o de `git config user.email` —la
+  misma identidad con la que se reclama una tarea— y la fila usa la columna «Decisión» que la tabla ya
+  tenía, con el valor `archivada`.
+
+- **`ops context` y `ops tree` sobre un planning que no existe ahora fallan, en vez de contestar como una
+  cola terminada.** Antes devolvían `queued: 0` con código 0, así que una ruta equivocada se propagaba
+  como dato y no como error. Ahora salen con código 2 y nombran la **ruta resuelta**, que es la que hace
+  falta para ver el problema: en `sidecar`, `<empresa>-ops/planning` escrito desde adentro de la raíz
+  apunta a `<empresa>-ops/<empresa>-ops/planning`, y las dos formas se ven razonables.
+
+  **Lo que te pide algo**: si tenías un script que trataba la salida vacía como «nada que hacer», ahora
+  recibe un error. Es deliberado y va en la misma dirección que el cambio de código de salida de
+  `upgrade` en 0.67.0 — un comando que no pudo leer no responde como si hubiera leído.
+
+- **`autobuild` no expande una épica sobre una lectura que falló.** La fase Pick tomaba «sin tarea y cola
+  en cero» como permiso para promover la próxima épica al BACKLOG, y ese es exactamente el estado que
+  devolvía un planning ilegible. Una corrida real escribió seis historias que ninguna persona aprobó
+  —lo que BR-OPS-002 prohíbe— y el `check` posterior dio verde, porque once tareas en cola es un estado
+  válido.
+
+  El arreglo del CLI no alcanzaba solo: el esquema se completa igual, y ceros es lo que un modelo escribe
+  cuando no tiene qué poner. Así que el informe de estado ahora declara si de verdad leyó, y expandir
+  exige esa lectura afirmada en vez de la ausencia de tarea. Parar cuesta una corrida; promover escribe en
+  el repositorio.
+
+## [0.70.0] - 2026-09-08
+
+### Agregado
+
+- **`planning/claims/`: quién tomó qué, para que dos runners no construyan lo mismo.** Un archivo por tarea
+  tomada, con el slug de la tarea como nombre: `ops claim planning <tarea>` lo crea y `ops release` lo borra.
+  `ops context` deja de ofrecer una tarea con reclamo ajeno —antes le entregaba la misma a los dos y ninguno
+  se enteraba—, nombra quién la tiene y devuelve antes lo que vos reclamaste que lo que está libre.
+
+  Es un archivo por tarea y no uno por persona a propósito: así dos personas en tareas distintas no tocan
+  nunca el mismo archivo, y dos que toman la misma chocan en git, que es donde el choque significa algo.
+  `check` rechaza el reclamo que nombra una tarea que no existe, avisa a los tres días de tomada y avisa
+  cuando hay dos reclamos sobre el mismo `service:` — avisa y no frena, porque frenar serializaría a un
+  equipo entero sobre un servicio.
+
+  El reclamo distingue `owner` —la persona, a quién preguntarle— de `runner` —el agente que la hace—, y
+  lo segundo es lo que decide de quién es una tarea. Con varios agentes en una máquina la persona es la
+  misma y el árbol de trabajo no: sin esa distinción, el segundo agente tomaría por propia la tarea del
+  primero. Se crea con exclusión —el archivo se abre en modo exclusivo, así que dos reclamos simultáneos
+  no se pisan— y un runner lleva una tarea a la vez.
+
+  **Lo que te pide algo**: el reclamo hay que commitearlo y empujarlo — sin eso, el otro runner lee lo
+  que hay en su copia y la reserva no existe para nadie más—. Y si corrés varios agentes en la misma
+  máquina, cada uno exporta `CAUCE_RUNNER` con un valor propio.
+
+- **`autobuild` reserva la tarea antes de construirla y la suelta al cerrarla.** Es lo que hace que dos
+  corridas en paralelo dejen de trabajar lo mismo: entre preguntar qué toca y reservarlo hay una ventana, y
+  perder esa carrera no frena la corrida — relee y sigue con la que quedó libre.
+
+- **El aviso de reclamo viejo mira si la rama avanzó, no cuánto hace que se tomó.** El tiempo transcurrido
+  no distingue una tarea larga de una abandonada, y equivocarse cuesta en los dos sentidos: apurar a quien
+  está trabajando, o dejar bloqueada para siempre la tarea de quien se fue. Ahora `check` mira el último
+  commit **propio** de `task/<tarea>` —los que no están en el tronco, porque una rama recién creada hereda
+  su historia entera y sin esa distinción toda rama parecería haber avanzado el día que se creó—: tres días
+  sin ninguno avisan, y una tarea que recibe commits no se apura nunca
+  aunque lleve semanas tomada. Sin repositorio resoluble el aviso vuelve a mirar sólo la fecha — degrada a
+  lo que había, no rompe.
+
+- **`ops context --hito <slug>` acota la cola a un hito.** Es la forma más barata de que dos personas o dos
+  agentes no se crucen: en hitos distintos casi nunca dependen entre sí ni tocan los mismos archivos. Lo
+  que se acota es qué se ofrece, no qué se sabe — una dependencia que vive en otro hito se sigue juzgando
+  igual—, y un hito mal escrito lo dice en vez de contestar «sin tarea disponible», que es indistinguible
+  de un hito terminado.
+
+- **El plan en vuelo es uno por runner: `planning/wip/<runner>.md`.** Con `mode: sidecar` hay un solo
+  `planning/` por máquina, así que un plan compartido lo escribían todos los agentes que corren ahí: el
+  segundo pisaba el del primero, y `ops context` le entregaba la tarea que el primero estaba construyendo
+  —con el plan ajeno adentro y diciéndole que estaba libre—. `context` honra sólo el tuyo y `check` los
+  recorre todos.
+
+  **Lo que te pide algo**: `planning/WIP.md` se retiró. Mové tu plan a `planning/wip/<runner>.md` —el
+  nombre sale de tu `CAUCE_RUNNER`, aplanado; `ops context --json` lo dice en `wipFile`— y borrá el
+  archivo viejo, que mientras esté `ops check` lo nombra. El `.gitignore` nuevo excluye `planning/wip/*.md`
+  y conserva su README; si venías con la línea de `planning/WIP.md`, cambiala.
+
+- **Un `service:` ambiguo entre varias raíces se nombra en vez de elegirse.** Con más de un
+  `workspaceRoots`, un servicio que existe en dos —`.` existe en todas— resolvía al primero: el árbol de
+  trabajo terminaba en el repositorio que no era, y el aviso de avance miraba las ramas de otro. Ahora
+  `ops worktree` nombra los candidatos y se niega, y el aviso degrada a mirar sólo la fecha.
+
+- **`ops worktree` avisa cuando la instancia está embebida.** Con `mode: embedded` cada árbol se lleva su
+  propia copia de `planning/`, así que los reclamos de un agente no los ve el otro hasta mergear y la
+  coordinación entre varios deja de existir sin que nada falle. No lo frena: un árbol por rama con un solo
+  agente es un uso legítimo.
+
+- **`ops runners <planning>`: qué runners tienen trabajo abierto, para que un agente pueda preguntar.**
+  Elegir con qué runner se arranca es lo primero de una sesión y `ops context` no lo contesta: responde
+  «qué hago» para un runner ya elegido. Sin esa lista, un agente se inventa un id y deja huérfano el
+  trabajo de ayer, o se lo pisa a otro que sigue corriendo.
+
+  **Lo que te pide algo**: nada, y es el punto. `AGENTS.md` le dice al runner que mire esa lista al abrir
+  la sesión, que **pregunte** cuál se retoma o si arranca uno nuevo, y que **exporte el id él mismo**. A
+  una persona no se le pide que escriba una variable de entorno.
+
+- **Tu propio reclamo desde otro runner se reconoce en vez de resolverse solo.** Volver al día siguiente
+  sin reponer `CAUCE_RUNNER` y correr un segundo agente tuyo se ven idénticos desde el archivo, y las dos
+  salidas automáticas rompen trabajo: retomar sola le saca la tarea al otro agente, y crear un runner
+  nuevo deja dos construyendo lo mismo. `ops claim` dice cuál es cuál y con qué id se retoma; `ops context`
+  marca esas tareas como «vos, desde otro runner».
+
+- **La evidencia de una tarea cerrada vive en su propio archivo: `planning/done/<slug>.md`.** Cerrar es lo
+  que más se hace, y mientras la evidencia se acumulaba en un `DONE.md` compartido, cerrar era agregarle
+  una entrada a algo que otro también estaba tocando. Ahora dos personas —o dos agentes— que cierran a la
+  vez escriben archivos distintos: no hay conflicto que resolver ni regla de merge que aplicar.
+
+  La entrada declara `fecha:`, la del cierre. Mientras vivían en un archivo, «la última» era la última del
+  archivo; con archivos sueltos el orden lo daría el listado del directorio, que es alfabético, y la
+  respuesta equivocada se leería igual de bien que la correcta. `ops evidence` sin `--task` ordena por ese
+  campo, y el contrato de una entrada está en `planning/done/README.md`.
+
+  **Lo que te pide algo**: `planning/DONE.md` se retiró. Pasá cada entrada a su propio
+  `planning/done/<slug>.md` con su `fecha:` y borrá el archivo — mientras esté, `ops check` lo dice en vez
+  de ignorarlo, porque un `DONE.md` que ya nadie lee deja a sus épicas sin poder cerrar y a sus historias
+  figurando sin evidencia.
+
+- **`ops archive <NNN>` se retiró; `ops archive human-actions` se queda.** Archivar una épica existía para
+  descongestionar un `DONE.md` que se hinchaba con una entrada por tarea; con un archivo por tarea no hay
+  nada que descongestionar, y mover esos archivos a una carpeta por épica sería reintroducir el movimiento
+  que esto vino a sacar. El comando lo dice, en vez de contestar «la épica debe ser NNN».
+
+- **`(depende: slug)` en una línea de tarea: lo que sigue no se le ofrece a otro.** El orden del BACKLOG
+  era la dependencia y alcanzaba mientras hubiera un runner; con dos, el segundo toma la que sigue mientras
+  el primero construye aquella de la que depende, y las dos ramas se pisan al integrar. Una tarea con
+  dependencias sin cerrar no se ofrece ni se puede tomar, y `context` la muestra con una línea `WAIT` que
+  nombra la dependencia y quién la tiene — una cola trabada no se lee como una cola vacía. `check` rechaza
+  la dependencia que no existe y nombra el ciclo entero cuando lo hay.
+
+- **`ops worktree <planning> <tarea>`: un árbol de trabajo por agente, sin clonar el repositorio.** Resuelve
+  en qué raíz de `workspaceRoots` vive el `service:` de la tarea, crea la rama `task/<slug>` y el árbol al
+  lado, y devuelve la ruta con el `export CAUCE_RUNNER` ya escrito. `git worktree` comparte el mismo `.git`
+  y el mismo historial, así que no hay una segunda copia del repositorio: lo que hay es un segundo
+  directorio de archivos fijado a su rama, y por eso **ningún agente hace `checkout`** sobre el trabajo de
+  otro. Repetirlo devuelve el árbol que ya existe.
+
+- **`.gitattributes`: `DONE.md` y `HUMAN_ACTIONS.md` se concatenan en vez de conflictuar.** Dos personas
+  cerrando trabajo el mismo día chocaban siempre, y ese conflicto no significaba nada: las dos entradas son
+  buenas y van las dos. Lo que `union` no hace es deduplicar, y esa falla ya la atrapa `DONE duplicado`.
+
+- **`planning/delivery/teamwork.md`**: qué comparte el equipo y qué no, por qué dos agentes necesitan un
+  `git worktree` cada uno, cómo repartir trabajo, y qué se rompe primero según el tamaño del equipo.
+
+- **BR-OPS-005 — una tarea, un runner.** La contracara de BR-OPS-001: aquélla impide que un runner lleve dos
+  tareas, ésta que dos runners lleven la misma.
+
+### Cambiado
+
+- **`planning/WIP.md` pasa a ser local y deja de viajar por git.** Existe para recuperar la sesión de quien
+  lo escribió —nadie más puede retomarla— y cambia en cada paso, así que compartirlo era un conflicto por
+  commit a cambio de nada. `check` deja de exigir que exista: ausente se lee como IDLE, que es lo que
+  significa, y un clon nuevo ya no falla por no traerlo.
+
+  **Lo que te pide algo**: el molde nuevo lo gitignorea, pero tu `.gitignore` es tuyo y `upgrade` no lo toca.
+  Para aprovecharlo, agregale `planning/WIP.md` y sacalo del índice con `git rm --cached planning/WIP.md`.
+  Sin hacer nada, todo sigue funcionando como antes.
+
+- **BR-OPS-001 se acota al runner.** Decía que WIP es el mutex sin decir de quién, y con equipo eso se leía
+  como «trabaja uno por vez». Ahora dice que un runner no toma dos tareas; que dos runners no tomen la misma
+  es BR-OPS-005.
+
 ## [0.69.0] - 2026-09-07
 
 ### Agregado

package/README.md

@@ -7,7 +7,7 @@ el contexto de cada empresa vive en su propia instancia.
 ## Qué resuelve
 
 - Una tarea tiene una sola fuente de verdad durante todo su ciclo de vida.
-- Una sesión interrumpida se recupera desde `WIP.md`, sin reconstruir la intención.
+- Una sesión interrumpida se recupera desde el plan del runner en `planning/wip/`, sin reconstruir la intención.
 - Las ideas del agente no entran solas a la cola: quedan en `INBOX.md` hasta promoción humana.
 - El trabajo que vuelve cada tanto se declara una vez en `RECURRING.md`; el CLI dice cuándo venció y
   nadie lo encola solo.
@@ -164,8 +164,8 @@ cualquiera de esas formas.
 ## Flujo
 
 ```text
-idea → INBOX → roadmap → BACKLOG → WIP → DONE → done/epic-NNN.md
-                    aprobación     ejecución      archivo histórico
+idea → INBOX → roadmap → BACKLOG → claim → WIP → done/<tarea>.md
+                    aprobación      reserva  ejecución    evidencia
 ```
 
 1. Captura ideas, deuda o lecciones en `INBOX.md`.
@@ -173,9 +173,9 @@ idea → INBOX → roadmap → BACKLOG → WIP → DONE → done/epic-NNN.md
    un recorrido —una etapa por dueño de decisión, con su exit gate— y dejar la épica candidata escrita;
    si falta evidencia o autoridad, para y registra la acción humana en vez de suponer.
 3. Promueve historias listas a un `## Hito` de `BACKLOG.md`.
-4. Un runner toma una sola tarea y persiste su plan en `WIP.md`.
-5. Tras Build, Review, Verify y QA, mueve la entrada a `DONE.md` con evidencia.
-6. Al cerrar la épica, ejecuta `ops archive` para mover su evidencia a un histórico inmutable.
+4. Un runner reclama la tarea con `ops claim`, para que otro no la tome, y persiste su plan en `wip/<runner>.md`.
+5. Tras Build, Review, Verify y QA, escribe la evidencia en `done/<slug>.md` y suelta el reclamo.
+6. Al cerrar la última historia, la épica pasa a `closed`.
 
 Lo que vuelve cada tanto —actualizar dependencias, revisar accesos, mirar el gasto del mes— entra por
 un costado: se declara una vez en `RECURRING.md` con su cadencia, y `ops recurring planning` dice qué

package/agents/README.md

@@ -25,6 +25,44 @@ mejor que repetirla en cada instalación.
 Por eso `learn` falla si lo corrés sobre un cargo del catálogo dentro de una instancia: escribiría en el
 paquete y se perdería. El ciclo de aprendizaje de esos cargos tampoco se distribuye.
 
+## Las URLs que un cargo cita
+
+Un cargo cita URLs en dos lugares y los dos se comprueban cada semana: `sources.yaml`, que es lo que
+investiga, y `references/` más `SKILL.md`, que es el método que sigue. Las de `evaluations/` **no** —los
+casos adversariales inventan dominios a propósito—, y las de `learning/reports` tampoco, porque son
+evidencia fechada de lo que una corrida encontró.
+
+Cuando una responde 403, casi nunca está muerta. Tres cosas que conviene probar antes de darla por
+perdida, todas encontradas midiendo el catálogo:
+
+- **El documento en vez de la página.** Cloudflare protege el HTML y no el PDF: `acm.org/code-of-ethics`
+  bloquea y `acm.org/binaries/.../acm-code-of-ethics-booklet.pdf` no; lo mismo con los instrumentos de la
+  OCDE, que se leen enteros bajo `legalinstruments.oecd.org/public/doc/<n>/<n>.en.pdf`.
+- **Otro sitio del mismo organismo.** `oecd.org/en/topics/ai-principles.html` bloquea y `oecd.ai` no;
+  `projectdelivery.gov.uk` bloquea y la misma norma está publicada en `gov.uk`.
+- **La forma publicada del dato.** El catálogo KEV de CISA bloquea en HTML y su feed JSON, que la propia
+  CISA distribuye, no.
+
+Si aun así no hay ninguna que responda —`pmi.org`, `fatf-gafi.org`—, la fuente **se queda en
+`sources.yaml`**, porque sigue siendo lo que la profesión publica y el chequeo semanal tiene algo que
+decir sobre ella; lo que sale es el enlace en `references/`, donde un 403 sólo le hace perder un clic a
+quien lee. El nombre se conserva.
+
+## Por qué las normas no se citan en `iso.org`
+
+`sources.yaml` cita cada norma por una ficha de catálogo, y para ISO esa ficha **no es la de
+`iso.org`**: ese dominio devuelve 403 a todo el catálogo —31 URLs, ninguna legible— y una fuente que no
+se puede abrir produce el mismo informe «sin novedades» que una que no cambió. Las dos que sí responden:
+
+- **`webstore.iec.ch/en/publication/<n>`** para una ISO/IEC, que los dos organismos co-publican.
+- **`committee.iso.org/standard/<n>.html`** para una ISO sola. Es el mismo número de catálogo que
+  llevaba la URL vieja, servido por un host que no bloquea.
+
+La diferencia entre las dos importa al escribir una entrada nueva: el número del IEC Webstore es
+**suyo** y nombra una edición concreta —buscar «ISO/IEC 25010» ahí devuelve primero la ficha de 2011,
+no la de 2023—, así que se comprueba contra el `<title>` de la ficha antes de anotarla. El de
+`committee.iso.org` es el mismo de ISO y no hay edición que equivocar.
+
 ## Quedarse con una versión propia
 
 ```bash

package/agents/roles/system/accounting-specialist/learning/HISTORY.md

@@ -1,4 +1,6 @@
 # Historial de aprendizaje
 
+Una fila por propuesta cerrada: cuándo, cuál, qué se decidió —aplicarla o archivarla—, quién lo decidió y qué cambió.
+
 | Fecha | Propuesta | Decisión | Aprobó | Cambio aplicado |
 |---|---|---|---|---|

package/agents/roles/system/ai-governance-lead/learning/HISTORY.md

@@ -1,3 +1,8 @@
 # Historial de aprendizaje
 
-Registrar fecha, propuesta, fuentes/versiones/estado, revisión humana/Legal, cambios aplicados, evaluaciones y responsable.
+Una fila por propuesta cerrada: cuándo, cuál, qué se decidió —aplicarla o archivarla—, quién lo decidió y qué cambió.
+
+Para este cargo, la fila dice además si hubo revisión de Legal.
+
+| Fecha | Propuesta | Decisión | Aprobó | Cambio aplicado |
+|---|---|---|---|---|

package/agents/roles/system/ai-governance-lead/learning/sources.yaml

@@ -13,12 +13,12 @@ sources:
     url: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
     tier: standard
     topics: [ai-risk, govern, map, measure, manage]
-  - name: ISO IEC 42001 AI management system
-    url: https://www.iso.org/standard/81230.html
+  - name: ISO IEC 42001:2023 AI management system
+    url: https://webstore.iec.ch/en/publication/90574
     tier: standard
     topics: [ai-governance, management-system, accountability, improvement]
-  - name: ISO IEC 42005 AI system impact assessment
-    url: https://www.iso.org/standard/44545.html
+  - name: ISO IEC 42005:2025 AI system impact assessment
+    url: https://webstore.iec.ch/en/publication/107659
     tier: standard
     topics: [impact-assessment, individuals, groups, society, lifecycle]
   - name: OECD AI Principles updated 2024

package/agents/roles/system/ai-governance-lead/references/operating-model.md

@@ -34,8 +34,8 @@ Mantener fuente primaria, instrumento, artículo/sección, jurisdicción, actor/
 ## Fundamento externo
 
 - [NIST AI RMF 1.0](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10): marco voluntario y agnóstico con Govern, Map, Measure y Manage; NIST indica que está en revisión en 2026.
-- [ISO/IEC 42001:2023](https://www.iso.org/standard/81230.html): requisitos para establecer y mejorar un AI management system; certificación organizacional no aprueba cada sistema.
-- [ISO/IEC 42005:2025](https://www.iso.org/standard/44545.html): evaluación de impactos sobre individuos, grupos y sociedad durante el lifecycle.
+- [ISO/IEC 42001:2023](https://webstore.iec.ch/en/publication/90574): requisitos para establecer y mejorar un AI management system; certificación organizacional no aprueba cada sistema.
+- [ISO/IEC 42005:2025](https://webstore.iec.ch/en/publication/107659): evaluación de impactos sobre individuos, grupos y sociedad durante el lifecycle.
 - [OECD AI Principles](https://oecd.ai/en/ai-principles): principios intergubernamentales actualizados en mayo de 2024 sobre IA innovadora, trustworthy y respetuosa de derechos.
 - [EU AI Act — fuente oficial](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai): ejemplo jurisdiccional con obligaciones y calendario cambiante; verificar EUR-Lex, rol, alcance, modificaciones y fecha aplicable con Legal.
 

package/agents/roles/system/ai-product-manager/learning/HISTORY.md

@@ -1,3 +1,6 @@
 # Historial de aprendizaje
 
-Registrar fecha, propuesta, fuentes/versiones, evidencia, decisión humana, cambios, evaluaciones y responsable.
+Una fila por propuesta cerrada: cuándo, cuál, qué se decidió —aplicarla o archivarla—, quién lo decidió y qué cambió.
+
+| Fecha | Propuesta | Decisión | Aprobó | Cambio aplicado |
+|---|---|---|---|---|

package/agents/roles/system/ai-product-manager/learning/sources.yaml

@@ -11,7 +11,7 @@ rules:
 sources:
   - {name: NIST AI RMF 1.0 and status, url: "https://www.nist.gov/itl/ai-risk-management-framework", tier: standard, topics: [ai-risk, lifecycle, status, monitoring]}
   - {name: NIST Generative AI Profile AI 600-1, url: "https://www.nist.gov/itl/ai-risk-management-framework/ai-risk-management-framework-resources", tier: standard, topics: [generative-ai, risk, evaluation]}
-  - {name: ISO IEC 42001 AI management systems, url: "https://www.iso.org/standard/42001", tier: standard, topics: [ai-management, governance, improvement]}
-  - {name: OECD AI Principles, url: "https://www.oecd.org/en/topics/ai-principles.html", tier: standard, topics: [rights, transparency, robustness, accountability, sustainability]}
+  - {name: ISO IEC 42001:2023 AI management systems, url: "https://webstore.iec.ch/en/publication/90574", tier: standard, topics: [ai-management, governance, improvement]}
+  - {name: OECD AI Principles, url: "https://oecd.ai/en/ai-principles", tier: standard, topics: [rights, transparency, robustness, accountability, sustainability]}
   - {name: Anthropic API release notes, url: "https://docs.anthropic.com/en/release-notes/overview", tier: platform, topics: [modelos, parámetros, deprecaciones]}
   - {name: OpenAI API changelog, url: "https://platform.openai.com/docs/changelog", tier: platform, topics: [modelos, parámetros, deprecaciones]}

package/agents/roles/system/ai-product-manager/references/operating-model.md

@@ -30,7 +30,7 @@ Verificar outcome, evals, data rights, privacy, security, accessibility, transpa
 
 - [NIST AI RMF 1.0](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10): marco voluntario y agnóstico al sector para gestionar riesgos durante el ciclo de vida; NIST indica que está en revisión.
 - [NIST AI 600-1 Generative AI Profile](https://www.nist.gov/itl/ai-risk-management-framework): perfil 2024 para riesgos y acciones específicos de IA generativa.
-- [ISO/IEC 42001:2023](https://www.iso.org/standard/42001): sistema de gestión para desarrollar y usar IA responsablemente con mejora continua.
-- [OECD AI Principles](https://www.oecd.org/en/topics/ai-principles.html): principios intergubernamentales centrados en derechos, actualizados en 2024 para IA general-purpose y generativa.
+- [ISO/IEC 42001:2023](https://webstore.iec.ch/en/publication/90574): sistema de gestión para desarrollar y usar IA responsablemente con mejora continua.
+- [OECD AI Principles](https://oecd.ai/en/ai-principles): principios intergubernamentales centrados en derechos, actualizados en 2024 para IA general-purpose y generativa.
 
 Estas fuentes no sustituyen investigación de usuarios, evaluación técnica, expertise de dominio, obligaciones aplicables ni autoridad empresarial.

package/agents/roles/system/analytics-engineer/learning/HISTORY.md

@@ -1,3 +1,6 @@
 # Historial de aprendizaje
 
-Registrar fecha, propuesta, fuentes/versiones, evidencia, decisión humana, cambios, evaluaciones y responsable.
+Una fila por propuesta cerrada: cuándo, cuál, qué se decidió —aplicarla o archivarla—, quién lo decidió y qué cambió.
+
+| Fecha | Propuesta | Decisión | Aprobó | Cambio aplicado |
+|---|---|---|---|---|

package/agents/roles/system/analytics-engineer/learning/sources.yaml

@@ -9,8 +9,8 @@ rules:
 # El contexto de la empresa no es una fuente de la profesión: vive en
 # organization/roles/analytics-engineer.md dentro de cada instalación.
 sources:
-  - {name: ISO IEC 25012 data quality model, url: "https://www.iso.org/standard/35736.html", tier: standard, topics: [data-quality, measures, evaluation]}
-  - {name: ISO 8000-61 data quality management, url: "https://www.iso.org/standard/63086.html", tier: standard, topics: [data-quality, process, maturity]}
+  - {name: ISO IEC 25012:2008 data quality model, url: "https://webstore.iec.ch/en/publication/11246", tier: standard, topics: [data-quality, measures, evaluation]}
+  - {name: ISO 8000-61 data quality management, url: "https://committee.iso.org/standard/63086.html", tier: standard, topics: [data-quality, process, maturity]}
   - {name: W3C RDF Data Cube Vocabulary, url: "https://www.w3.org/TR/vocab-data-cube/", tier: standard, topics: [measures, dimensions, metadata]}
   - {name: W3C PROV-O, url: "https://www.w3.org/TR/prov-o/", tier: standard, topics: [provenance, lineage]}
   - {name: dbt Core upgrade notes, url: "https://docs.getdbt.com/docs/dbt-versions/core-upgrade", tier: platform, topics: [materializaciones, incremental, cambios incompatibles]}

package/agents/roles/system/analytics-engineer/references/operating-model.md

@@ -28,8 +28,8 @@ Definir unique key, watermark, late arrivals y equivalencia con full refresh. Un
 
 ## Fundamento externo
 
-- [ISO/IEC 25012:2008](https://www.iso.org/standard/35736.html): requisitos, medidas y evaluación de calidad de datos; confirmado vigente en 2025.
-- [ISO 8000-61:2016](https://www.iso.org/standard/63086.html): procesos para gestionar calidad y evaluar capacidad o madurez.
+- [ISO/IEC 25012:2008](https://webstore.iec.ch/en/publication/11246): requisitos, medidas y evaluación de calidad de datos; confirmado vigente en 2025.
+- [ISO 8000-61:2016](https://committee.iso.org/standard/63086.html): procesos para gestionar calidad y evaluar capacidad o madurez.
 - [W3C RDF Data Cube Vocabulary](https://www.w3.org/TR/vocab-data-cube/): observaciones, medidas, dimensiones y metadatos multidimensionales.
 - [W3C PROV-O](https://www.w3.org/TR/prov-o/): procedencia interoperable mediante entidades, actividades y agentes.
 

package/agents/roles/system/backend-engineer/learning/HISTORY.md

@@ -1,5 +1,7 @@
 # Historial de aprendizaje
 
+Una fila por propuesta cerrada: cuándo, cuál, qué se decidió —aplicarla o archivarla—, quién lo decidió y qué cambió.
+
 | Fecha | Propuesta | Decisión | Aprobó | Cambio aplicado |
 |---|---|---|---|---|
 | 2026-08-30 | `learning/proposals/2026-08.md` | Aprobada | @ingeniomaps (Manuel Pinzon) | Nada: el período se revisó y se decidió no cambiar ningún contrato. |

package/agents/roles/system/business-strategist/learning/HISTORY.md

@@ -1,4 +1,6 @@
 # Historial de aprendizaje
 
+Una fila por propuesta cerrada: cuándo, cuál, qué se decidió —aplicarla o archivarla—, quién lo decidió y qué cambió.
+
 | Fecha | Propuesta | Decisión | Aprobó | Cambio aplicado |
 |---|---|---|---|---|

package/agents/roles/system/business-strategist/learning/sources.yaml

@@ -18,7 +18,7 @@ sources:
     tier: regulation
     topics: [options, appraisal, costs, benefits, risk]
   - name: ISO 56002
-    url: https://www.iso.org/standard/68221.html
+    url: https://committee.iso.org/standard/68221.html
     tier: standard
     topics: [innovation, opportunities, learning]
   - name: Strategyzer Business Model Canvas

package/agents/roles/system/business-strategist/references/operating-model.md

@@ -71,9 +71,9 @@ Separar compromisos del núcleo, opciones adyacentes y experimentos. Ajustar tam
 
 Modelo sintetizado con fuentes revisadas en agosto de 2026:
 
-- [OECD Strategic Foresight](https://www.oecd.org/strategic-foresight/): escenarios y anticipación para decisiones robustas bajo incertidumbre.
+- **OECD Strategic Foresight** (sin enlace: `oecd.org` bloquea): escenarios y anticipación para decisiones robustas bajo incertidumbre.
 - [UK Government Green Book](https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government): definición de objetivos, opciones, costos, beneficios, riesgos y evaluación.
-- [ISO 56002 Innovation management](https://www.iso.org/standard/68221.html): enfoque sistemático para oportunidades, innovación, aprendizaje y mejora.
+- [ISO 56002 Innovation management](https://committee.iso.org/standard/68221.html): enfoque sistemático para oportunidades, innovación, aprendizaje y mejora.
 - [Strategyzer Business Model Canvas](https://www.strategyzer.com/library/the-business-model-canvas): lenguaje para relacionar propuesta de valor, clientes, canales, recursos, actividades, socios, ingresos y costos.
 
 Verificar siempre fuentes primarias del sector, datos internos y contexto real de cada empresa.

package/agents/roles/system/cloud-architect/learning/HISTORY.md

@@ -1,6 +1,6 @@
 # Historial de aprendizaje
 
-Registrar fecha, propuesta, fuentes/versiones, evidencia, decisión humana, cambios, evaluaciones y responsable.
+Una fila por propuesta cerrada: cuándo, cuál, qué se decidió —aplicarla o archivarla—, quién lo decidió y qué cambió.
 
 | Fecha | Propuesta | Decisión | Aprobó | Cambio aplicado |
 |---|---|---|---|---|

package/agents/roles/system/cloud-architect/learning/sources.yaml

@@ -10,8 +10,8 @@ rules:
 # organization/roles/cloud-architect.md dentro de cada instalación.
 sources:
   - {name: NIST SP 800-145 cloud definition, url: "https://csrc.nist.gov/pubs/sp/800/145/final", tier: standard, topics: [cloud, service-models, deployment-models]}
-  - {name: ISO IEC 27017 cloud security controls, url: "https://www.iso.org/standard/43757.html", tier: standard, topics: [cloud-security, customers, providers]}
-  - {name: ISO IEC 27017 edition 2 status, url: "https://www.iso.org/standard/82878.html", tier: standard, topics: [cloud-security, revision-status]}
+  - {name: ISO IEC 27017:2015 cloud security controls, url: "https://webstore.iec.ch/en/publication/23891", tier: standard, topics: [cloud-security, customers, providers]}
+  - {name: ISO IEC 27017:2026 cloud security controls, url: "https://webstore.iec.ch/en/publication/115400", tier: standard, topics: [cloud-security, revision-status]}
   - {name: FinOps Framework, url: "https://www.finops.org/framework/", tier: profession, topics: [value, cost, usage, accountability]}
   - {name: AWS What is New, url: "https://aws.amazon.com/new/", tier: platform, topics: [servicios, regiones, precios, deprecaciones]}
   - {name: Google Cloud release notes, url: "https://cloud.google.com/release-notes", tier: platform, topics: [servicios, regiones, deprecaciones]}

package/agents/roles/system/cloud-architect/references/operating-model.md

@@ -29,8 +29,8 @@ Descubrir dependencias y baseline; priorizar waves reversibles; preparar observa
 ## Fundamento externo
 
 - [NIST SP 800-145](https://csrc.nist.gov/pubs/sp/800/145/final): características esenciales y modelos de servicio/despliegue de cloud computing.
-- [ISO/IEC 27017:2015](https://www.iso.org/standard/43757.html): controles para clientes y proveedores cloud; en agosto de 2026 sigue publicada pero será sustituida por la edición 2, actualmente bajo publicación.
-- [ISO/IEC 27017 edición 2](https://www.iso.org/standard/82878.html): estado oficial de la revisión; no tratarla como publicada hasta que ISO lo confirme.
+- [ISO/IEC 27017:2026](https://webstore.iec.ch/en/publication/115400): edición 2, publicada el 2026-07-27 según su ficha; controles para clientes y proveedores cloud.
+- [ISO/IEC 27017:2015](https://webstore.iec.ch/en/publication/23891): la edición 1, que la de 2026 reemplaza. Un contrato firmado contra ella no se satisface con la nueva.
 - [FinOps Framework](https://www.finops.org/framework/): modelo operativo abierto para conectar valor, uso, costo y accountability entre ingeniería, finanzas y negocio.
 
 Verificar documentación, precios, SLA, quotas, regiones y estado del servicio para proveedor y fecha concretos antes de recomendarlo.

package/agents/roles/system/community-manager/learning/HISTORY.md

@@ -1,3 +1,6 @@
 # Historial de aprendizaje
 
-Registrar fecha, propuesta, fuentes/versiones, decisión humana, cambios aplicados, evaluaciones y responsable.
+Una fila por propuesta cerrada: cuándo, cuál, qué se decidió —aplicarla o archivarla—, quién lo decidió y qué cambió.
+
+| Fecha | Propuesta | Decisión | Aprobó | Cambio aplicado |
+|---|---|---|---|---|

package/agents/roles/system/community-manager/learning/sources.yaml

@@ -21,7 +21,7 @@ sources:
     url: https://www.w3.org/TR/WCAG22/
     tier: standard
     topics: [accessibility, inclusion, web, conformance]
-  - name: OECD privacy principles
-    url: https://www.oecd.org/en/topics/privacy-principles.html
+  - name: OECD Privacy Guidelines
+    url: https://legalinstruments.oecd.org/public/doc/188/188.en.pdf
     tier: standard
     topics: [privacy, collection, purpose, use, accountability]

package/agents/roles/system/community-manager/references/operating-model.md

@@ -35,6 +35,6 @@ Sintetizar tema, necesidad, segmento/contexto, frecuencia, severidad, impacto, e
 - [Contributor Covenant 3.0](https://www.contributor-covenant.org/version/3/0/code_of_conduct/): ejemplo adaptable de conductas, reporte, investigación privada y escala de medidas; requiere completar y aprobar el proceso propio.
 - [GitHub — Community management and moderation](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/about-community-management-and-moderation): herramientas y prácticas específicas de esa plataforma; verificar equivalentes en cada canal.
 - [W3C WCAG 2.2](https://www.w3.org/TR/WCAG22/): criterios de accesibilidad para superficies web; complementar con necesidades de eventos, idiomas y discapacidades no cubiertas totalmente.
-- [OECD Privacy Guidelines](https://www.oecd.org/en/topics/privacy-principles.html): limitación de recolección, propósito, uso, calidad, seguridad, apertura, participación y accountability.
+- [OECD Privacy Guidelines](https://legalinstruments.oecd.org/public/doc/188/188.en.pdf): limitación de recolección, propósito, uso, calidad, seguridad, apertura, participación y accountability.
 
 Estas fuentes orientan diseño y controles; las políticas aprobadas, plataforma, comunidad y jurisdicción reales determinan las acciones permitidas.

package/agents/roles/system/content-specialist/learning/HISTORY.md

@@ -1,4 +1,6 @@
 # Historial de aprendizaje
 
+Una fila por propuesta cerrada: cuándo, cuál, qué se decidió —aplicarla o archivarla—, quién lo decidió y qué cambió.
+
 | Fecha | Propuesta | Decisión | Aprobó | Cambio aplicado |
 |---|---|---|---|---|

package/agents/roles/system/customer-success-manager/learning/HISTORY.md

@@ -1,5 +1,7 @@
 # Historial de aprendizaje
 
+Una fila por propuesta cerrada: cuándo, cuál, qué se decidió —aplicarla o archivarla—, quién lo decidió y qué cambió.
+
 | Fecha | Propuesta | Decisión | Aprobó | Cambio aplicado |
 |---|---|---|---|---|
 | 2026-08-30 | `learning/proposals/2026-08.md` | Aprobada | Manuel Pinzon | `SKILL.md` (párrafo nuevo al final de «Construir contexto»); `learning/proposals/2026-08.md`. Dos desviaciones, escritas al final de «Aprobación humana» de la propuesta: (1) los ejemplos del párrafo se adaptaron al vocabulario del cargo —la propuesta autoriza adaptar la redacción y la licencia se usó sólo en esa lista: donde decía «Delighted, una herramienta de analítica», el `SKILL.md` dice «la encuesta de NPS o CSAT, el producto de analítica», porque Delighted es el proveedor del caso `07-nps-que-subio` y nombrarlo metía un caso de evaluación dentro del contrato del cargo—; el resto entró literal, incluida «abstenerse cubre lo que no se puede consultar, no lo que cuesta abrir una página», y en la ubicación que la propuesta fija; (2) no se re-corrió `07-nps-que-subio`, que la sección «Evaluación» pide como confirmación: esta aplicación se limitó a «Cambio propuesto», y hasta que exista ese veredicto el efecto del párrafo en este cargo no está medido. Sin caso adversarial nuevo: la propuesta acota el cambio al párrafo y nada más. |