@ingeniomaps/cauce 0.70.0 → 0.71.0

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

@@ -1,3 +1,6 @@
 # Historial de cambios aprobados
 
-Registrar únicamente cambios aprobados, con fecha, evidencia, evaluación 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/project-manager/learning/sources.yaml

@@ -21,6 +21,6 @@ sources:
     tier: standard
     topics: [scrum, empirical, iterative, product-delivery]
   - name: Government Functional Standard GovS 002
-    url: https://projectdelivery.gov.uk/govs-002-project-delivery-functional-standard/
+    url: https://www.gov.uk/government/publications/project-delivery-functional-standard
     tier: regulation
     topics: [governance, assurance, planning, control, benefits, change]

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

@@ -67,8 +67,8 @@ Revalidar outcome y facts, detener trabajo que no protege valor, reconstruir for
 ## Fundamento externo
 
 - [ISO 21502:2020](https://committee.iso.org/sites/tc258/home/projects/published/iso-21502.html): guía aplicable a cualquier tipo de proyecto y enfoque predictivo, iterativo, adaptativo o híbrido.
-- [PMI — PMBOK Guide](https://www.pmi.org/standards/pmbok): principios, dominios, valor, adaptación y accountability; verificar edición vigente.
+- **PMI — PMBOK Guide** (sin enlace: `pmi.org` bloquea): principios, dominios, valor, adaptación y accountability; verificar edición vigente.
 - [Official Scrum Guide](https://scrumguides.org/download.html): Scrum cuando el contexto justifique ese framework; la versión oficial vigente indicada es noviembre de 2020.
-- [Government Functional Standard GovS 002](https://projectdelivery.gov.uk/govs-002-project-delivery-functional-standard/): gobierno, planificación, control, assurance y entrega; aplicar sólo dentro de su alcance o como referencia.
+- [Government Functional Standard GovS 002](https://www.gov.uk/government/publications/project-delivery-functional-standard): gobierno, planificación, control, assurance y entrega; aplicar sólo dentro de su alcance o como referencia.
 
 Adaptar el método a la empresa; ninguna fuente sustituye gobierno, políticas ni autoridad reales.

package/agents/roles/system/qa-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-16 | — (hallazgo de `evaluations/results/2026-08-15.md`, caso 06) | Aplicado | Manuel Pinzon | `SKILL.md` § Aprender sin reescribirse: «descartar no es verificar». El contrato enseñaba a rechazar contenido externo y no a verificar su fuente, alcance y versión aplicable, así que el cargo lo descartaba en bloque. Verificado volviendo a correr el caso 06: pasa, con cita en los cuatro comportamientos. |

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

@@ -13,11 +13,10 @@ sources:
     url: https://www.istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/
     tier: profession
     topics: [testing-principles, techniques, risk, defects]
-  # iso.org devuelve 403 desde el 2026-08-16; la ficha legible es la del IEC Webstore
-  # —https://webstore.iec.ch/en/publication/90024—. Es ficha de catálogo: el texto de la norma no se
-  # leyó (informe 2026-08-22, H1 y H2).
-  - name: ISO IEC 25010 product quality model
-    url: https://www.iso.org/standard/78176.html
+  # Es ficha de catálogo: dice qué norma es y de qué edición, y el texto de la norma no se leyó
+  # (informe 2026-08-22, H1 y H2).
+  - name: ISO IEC 25010:2023 product quality model
+    url: https://webstore.iec.ch/en/publication/90024
     tier: standard
     topics: [product-quality-model]
   - name: OWASP Web Security Testing Guide
@@ -47,20 +46,19 @@ sources:
   # Edición 2.0 del 2025-09-24, que **reemplaza** a ISO/IEC 40500:2012 — la identidad ISO de
   # WCAG 2.0—. Por eso el nombre lleva el año: «ISO/IEC 40500» a secas es ambiguo entre dos
   # documentos que dicen cosas distintas, y un contrato que exige uno no se satisface con el otro.
-  # iso.org devuelve 403 desde el 2026-08-16, así que lo legible es la ficha del IEC Webstore
-  # —https://webstore.iec.ch/en/publication/109927—, corroborada contra el anuncio de W3C del
-  # 2025-10-21. Es ficha de catálogo: el texto de la norma no se leyó (informe 2026-08-22, H1).
+  # La edición que declara la ficha está corroborada contra el anuncio de W3C del 2025-10-21. Es ficha
+  # de catálogo: el texto de la norma no se leyó (informe 2026-08-22, H1).
   - name: ISO IEC 40500:2025
-    url: https://www.iso.org/standard/91029.html
+    url: https://webstore.iec.ch/en/publication/109927
     tier: standard
     topics: [accessibility, conformance, iso-identity]
   # Extensión de 25010 para sistemas de IA. La única edición publicada es la de 2023 y su comité
-  # es SC 42 —no SC 7—; ficha legible en https://webstore.iec.ch/en/publication/86756.
+  # es SC 42 —no SC 7—.
   # El estado de la revisión en curso **no está corroborado en fuente primaria** y no se afirma.
   # Cuidado al buscarlo: el «ISO/IEC DIS 25059:2022» que aparece en catálogos de revendedores es el
   # DIS de la primera edición, no el de la revisión (informe 2026-08-22, H2).
   - name: ISO IEC 25059:2023
-    url: https://www.iso.org/standard/80655.html
+    url: https://webstore.iec.ch/en/publication/86756
     tier: standard
     topics: [ai-quality-model, product-quality-model]
   # Página de la certificación, no el anuncio: el syllabus vigente es v2.0 GA del 2026-04-17, y

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

@@ -109,12 +109,12 @@ Comunicar hechos, inferencias y desconocidos por separado. La recomendación pue
 Modelo sintetizado con fuentes revisadas en agosto de 2026:
 
 - [ISTQB Certified Tester Foundation Level](https://www.istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/): principios, proceso, técnicas, pruebas basadas en riesgo y gestión de defectos.
-- [ISO/IEC 25010](https://www.iso.org/standard/78176.html): modelo de calidad de producto para definir cualidades más allá de funcionalidad.
+- [ISO/IEC 25010](https://webstore.iec.ch/en/publication/90024): modelo de calidad de producto para definir cualidades más allá de funcionalidad.
 - [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/): estructura y escenarios para pruebas de seguridad web autorizadas.
 - [W3C WCAG 2.2](https://www.w3.org/TR/WCAG22/): criterios verificables de accesibilidad para contenido web.
 - [OWASP Top 10:2025](https://owasp.org/Top10/2025/0x00_2025-Introduction/): modelo de riesgo
   web vigente, incluidas cadena de suministro y manejo de condiciones excepcionales.
-- [ISO/IEC 25059](https://www.iso.org/standard/80655.html): extensión del modelo de calidad
+- [ISO/IEC 25059](https://webstore.iec.ch/en/publication/86756): extensión del modelo de calidad
   para sistemas basados en IA.
 - [ISTQB CT-AI v2.0](https://istqb.org/istqb-releases-certified-tester-ai-testing-ct-ai-syllabus-version-2-0/):
   pruebas de datos, modelo y sistema; dificultad de definir oráculos en sistemas probabilísticos.

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

@@ -1,6 +1,6 @@
 # Historial de cambios aprobados
 
-Registrar únicamente cambios aprobados, con fecha, evidencia, evaluación 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/sales-representative/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/sales-representative/learning/sources.yaml

@@ -9,7 +9,7 @@ rules:
 # El contexto de la empresa no es una fuente de la profesión: vive en
 # organization/roles/sales-representative.md dentro de cada instalación.
 sources:
-  - name: ICC Marketing Communications Code
+  - name: ICC Advertising and Marketing Communications Code
     url: https://iccwbo.org/business-solutions/the-icc-advertising-and-marketing-communications-code/
     tier: standard
     topics: [honesty, substantiation, identity, direct-marketing]
@@ -22,6 +22,6 @@ sources:
     tier: regulation
     topics: [commercial-email, opt-out, identity]
   - name: OECD Consumer Protection E-commerce
-    url: https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0422
+    url: https://legalinstruments.oecd.org/public/doc/422/422.en.pdf
     tier: standard
     topics: [fair-practices, disclosures, confirmation, redress]

package/agents/roles/system/sales-representative/references/operating-model.md

@@ -74,6 +74,6 @@ Modelo sintetizado con fuentes revisadas en agosto de 2026:
 - [ICC Advertising and Marketing Communications Code](https://iccwbo.org/business-solutions/the-icc-advertising-and-marketing-communications-code/): identidad, honestidad, sustento, datos y marketing directo responsable.
 - [UK ICO Direct Marketing Guidance](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/): llamadas, email, mensajes, preferencias y protección de datos; aplicar según jurisdicción.
 - [FTC CAN-SPAM Compliance Guide](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business): requisitos oficiales estadounidenses para email comercial; aplicar donde corresponda.
-- [OECD Recommendation on Consumer Protection in E-commerce](https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0422): prácticas comerciales justas, información, confirmación y resolución.
+- [OECD Recommendation on Consumer Protection in E-commerce](https://legalinstruments.oecd.org/public/doc/422/422.en.pdf): prácticas comerciales justas, información, confirmación y resolución.
 
 Añadir autoridades, políticas comerciales y reglas sectoriales de cada geografía y canal real.

package/agents/roles/system/security-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-17 | `learning/proposals/2026-08.md` | Aprobada | Manuel Pinzon | Aditivo en cuatro archivos: nombra «proceso automático con credenciales» como actor —una viñeta en `SKILL.md` § Reglas de construcción, y en `references/operating-model.md` una viñeta de revisión, la sección «Automatización y agentes con credenciales», dos preguntas de control de calidad y una fuente de fundamento—; la conducta prohibida `post_hoc_check_as_containment_for_credentialed_agent` con su caso `07-agent-in-ci.md`; y 4 fuentes nuevas en `sources.yaml` (avisos de Node.js, GitHub Advisory Database, GitHub Changelog, OWASP Agentic Top 10, ésta registrada como marco no leído). Ninguna línea existente reescrita, sin desviaciones. Las 8 recomendaciones operativas del informe quedaron fuera: no son contrato y el cargo no tiene autoridad sobre el pipeline en el que corre. |

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

@@ -22,7 +22,7 @@ sources:
     tier: advisory
     topics: [weaknesses, causes, mitigations]
   - name: CISA Known Exploited Vulnerabilities
-    url: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
+    url: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
     tier: advisory
     topics: [known-exploitation, prioritization]
   - name: Node.js Security Releases

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

@@ -86,7 +86,7 @@ Modelo sintetizado con fuentes revisadas en agosto de 2026:
 - [NIST Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final): prácticas de preparación, protección, producción y respuesta a vulnerabilidades.
 - [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/): requisitos verificables de seguridad para aplicaciones y servicios.
 - [MITRE CWE](https://cwe.mitre.org/): taxonomía de debilidades para describir causas y mitigaciones sin confundirlas con vulnerabilidades concretas.
-- [CISA Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog): evidencia de explotación conocida para priorización basada en riesgo.
+- [CISA Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json): evidencia de explotación conocida para priorización basada en riesgo.
 - [OWASP Top 10 for Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/): riesgos de sistemas autónomos —uso de herramientas, identidad, ejecución de código y agencia excesiva—. Citado como marco: el documento no fue leído, así que no se atribuye ningún identificador de categoría a un hallazgo.
 
 Verificar siempre versiones, avisos oficiales y contexto real de cada empresa.

package/agents/roles/system/site-reliability-engineer/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/software-architect/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/software-architect/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/software-architect.md dentro de cada instalación.
 sources:
-  - name: ISO IEC IEEE 42010 architecture description
-    url: https://www.iso.org/standard/74393.html
+  - name: ISO IEC IEEE 42010:2022 architecture description
+    url: https://webstore.iec.ch/en/publication/80194
     tier: standard
     topics: [architecture-description, stakeholders, viewpoints]
   - name: C4 model

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

@@ -71,7 +71,7 @@ Comparar opciones mediante escenarios, restricciones y costo total: construcció
 
 Modelo sintetizado con fuentes revisadas en agosto de 2026:
 
-- [ISO/IEC/IEEE 42010](https://www.iso.org/standard/74393.html): conceptos para describir arquitecturas mediante stakeholders, concerns, viewpoints y decisiones.
+- [ISO/IEC/IEEE 42010](https://webstore.iec.ch/en/publication/80194): conceptos para describir arquitecturas mediante stakeholders, concerns, viewpoints y decisiones.
 - [C4 model](https://c4model.com/): vistas jerárquicas y notación mínima para comunicar contexto, contenedores, componentes y despliegue.
 - [SEI Architecture Tradeoff Analysis Method](https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/): análisis de decisiones a partir de atributos de calidad y trade-offs.
 - [arc42](https://arc42.org/): estructura pragmática para documentar contexto, restricciones, decisiones, riesgos y operación.

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

@@ -1,3 +1,6 @@
 # Historial de aprendizaje
 
-Registrar fecha, propuesta, fuentes, 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/solutions-engineer/learning/sources.yaml

@@ -9,12 +9,12 @@ rules:
 # El contexto de la empresa no es una fuente de la profesión: vive en
 # organization/roles/solutions-engineer.md dentro de cada instalación.
 sources:
-  - name: ISO IEC IEEE 42010 architecture description
-    url: https://www.iso.org/standard/74393.html
+  - name: ISO IEC IEEE 42010:2022 architecture description
+    url: https://webstore.iec.ch/en/publication/80194
     tier: standard
     topics: [architecture, concerns, viewpoints, decisions]
-  - name: ISO IEC 25010 product quality model
-    url: https://www.iso.org/standard/78176.html
+  - name: ISO IEC 25010:2023 product quality model
+    url: https://webstore.iec.ch/en/publication/90024
     tier: standard
     topics: [quality, requirements, evaluation, acceptance]
   - name: NIST Cybersecurity Framework 2.0

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

@@ -54,8 +54,8 @@ Teardown, borrado y handoff:
 
 ## Fundamento externo
 
-- [ISO/IEC/IEEE 42010:2022](https://www.iso.org/standard/74393.html): conceptos y estructura para describir arquitectura desde concerns y viewpoints; verificar aplicabilidad y acceso a la edición vigente.
-- [ISO/IEC 25010:2023](https://www.iso.org/standard/78176.html): modelo de nueve características para especificar y evaluar calidad de productos ICT.
+- [ISO/IEC/IEEE 42010:2022](https://webstore.iec.ch/en/publication/80194): conceptos y estructura para describir arquitectura desde concerns y viewpoints; verificar aplicabilidad y acceso a la edición vigente.
+- [ISO/IEC 25010:2023](https://webstore.iec.ch/en/publication/90024): modelo de nueve características para especificar y evaluar calidad de productos ICT.
 - [NIST Cybersecurity Framework 2.0](https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20): lenguaje de outcomes para entender y comunicar riesgo de ciberseguridad; no certifica una solución.
 - [OpenAPI Specification](https://spec.openapis.org/oas/latest.html): contrato agnóstico al lenguaje para describir APIs HTTP; comprobar la versión soportada por producto y tooling.
 

package/agents/roles/system/tech-lead/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/technical-program-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/technical-program-manager/learning/sources.yaml

@@ -9,7 +9,7 @@ rules:
 # El contexto de la empresa no es una fuente de la profesión: vive en
 # organization/roles/technical-program-manager.md dentro de cada instalación.
 sources:
-  - {name: ISO 21503 programme management, url: "https://www.iso.org/cms/%20render/live/en/sites/isoorg/contents/data/standard/08/28/82868.html", tier: standard, topics: [programme, roles, responsibilities, practices]}
+  - {name: ISO 21503 programme management, url: "https://committee.iso.org/standard/82868.html", tier: standard, topics: [programme, roles, responsibilities, practices]}
   - {name: ISO 21502 project management, url: "https://committee.iso.org/sites/tc258/home/projects/published/iso-21502.html", tier: standard, topics: [project, adaptive, predictive, hybrid]}
-  - {name: ISO 31000 risk management, url: "https://www.iso.org/standard/65694.html", tier: standard, topics: [risk, principles, process]}
+  - {name: ISO 31000 risk management, url: "https://committee.iso.org/standard/65694.html", tier: standard, topics: [risk, principles, process]}
   - {name: PMI standards and Program Management Fifth Edition, url: "https://www.pmi.org/standards/", tier: profession, topics: [program, benefits, collaboration, principles]}

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

@@ -33,9 +33,9 @@ Verificar producto/capability, integración, datos, seguridad, privacidad, perfo
 
 ## Fundamento externo
 
-- [ISO 21503:2022](https://www.iso.org/cms/%20render/live/en/sites/isoorg/contents/data/standard/08/28/82868.html): guía vigente y transversal para conceptos, roles, responsabilidades y prácticas de gestión de programas.
+- [ISO 21503:2022](https://committee.iso.org/standard/82868.html): guía vigente y transversal para conceptos, roles, responsabilidades y prácticas de gestión de programas.
 - [ISO 21502:2020](https://committee.iso.org/sites/tc258/home/projects/published/iso-21502.html): guía adaptable a enfoques predictivos, iterativos, incrementales, adaptativos o híbridos para componentes/proyectos.
-- [ISO 31000:2018](https://www.iso.org/standard/65694.html): principios y proceso de gestión de riesgo; confirmada en 2023 aunque ISO indica futura revisión.
-- [PMI Standard for Program Management — Fifth Edition](https://www.pmi.org/standards/): estándar 2024 basado en principios, beneficios y colaboración entre componentes.
+- [ISO 31000:2018](https://committee.iso.org/standard/65694.html): principios y proceso de gestión de riesgo; confirmada en 2023 aunque ISO indica futura revisión.
+- **PMI Standard for Program Management — Fifth Edition** (sin enlace: `pmi.org` bloquea): estándar 2024 basado en principios, beneficios y colaboración entre componentes.
 
 Estas fuentes orientan el sistema de coordinación; la gobernanza, autoridad, delivery approach y contexto de cada empresa prevalecen.

package/agents/roles/system/technical-writer/learning/HISTORY.md

@@ -1,3 +1,6 @@
 # Historial de cambios aprobados
 
-Registrar únicamente cambios aprobados, con fecha, evidencia, evaluación 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/treasury-analyst/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/ui-designer/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 | `agents/roles/system/ui-designer/learning/proposals/2026-08.md` | Aprobada | Manuel Pinzon | `agents/roles/system/ui-designer/SKILL.md` |

package/agents/roles/system/ui-designer/learning/sources.yaml

@@ -14,11 +14,11 @@ sources:
     topics: [contrast, focus, targets, responsive, accessibility]
   - name: Apple Human Interface Guidelines
     url: https://developer.apple.com/design/human-interface-guidelines/
-    tier: platform
+    tier: standard
     topics: [layout, typography, color, components, accessibility]
   - name: Material Design
     url: https://m3.material.io/
-    tier: platform
+    tier: standard
     topics: [tokens, components, color, typography, motion]
   - name: GOV.UK Design System
     url: https://design-system.service.gov.uk/

package/agents/roles/system/user-researcher/learning/HISTORY.md

@@ -1,6 +1,6 @@
 # Historial de aprendizaje
 
-Registrar únicamente cambios aprobados y aplicados al agente.
+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/user-researcher/learning/sources.yaml

@@ -17,7 +17,7 @@ sources:
     tier: profession
     topics: [methods, usability, synthesis]
   - name: UK Government Social Research Ethics
-    url: https://www.gov.uk/government/publications/government-social-research-framework-for-research-ethics
+    url: https://www.gov.uk/government/publications/ethical-assurance-guidance-for-social-research-in-government
     tier: regulation
     topics: [ethics, harm, consent]
   - name: Interaction Design Foundation

package/agents/roles/system/ux-designer/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/ux-designer/learning/sources.yaml

@@ -13,7 +13,7 @@ sources:
     tier: standard
     topics: [accessibility, wcag, cognitive-accessibility]
   - name: ISO Human-centred Design
-    url: https://www.iso.org/standard/77520.html
+    url: https://committee.iso.org/standard/77520.html
     tier: standard
     topics: [human-centred-design, lifecycle]
   - name: Nielsen Norman Group

package/agents/roles/system/ux-designer/references/operating-model.md

@@ -79,7 +79,7 @@ Diseñar para que la experiencia sea perceptible, operable, comprensible y robus
 
 Modelo sintetizado con fuentes revisadas en agosto de 2026:
 
-- [ISO 9241-210:2019](https://www.iso.org/standard/77520.html): integrar diseño centrado en las personas durante el ciclo de vida de sistemas interactivos.
+- [ISO 9241-210:2019](https://committee.iso.org/standard/77520.html): integrar diseño centrado en las personas durante el ciclo de vida de sistemas interactivos.
 - [WCAG 2.2](https://www.w3.org/TR/WCAG22/): criterios comprobables para contenido perceptible, operable, comprensible y robusto.
 - [Nielsen Norman Group: heurísticas de usabilidad](https://media.nngroup.com/media/articles/attachments/Heuristic_Summary1_A4_compressed.pdf): principios para inspeccionar feedback, control, consistencia, prevención y recuperación.
 - [GOV.UK Design System Patterns](https://design-system.service.gov.uk/patterns/): patrones documentados para tareas concretas, adaptables al contexto.

package/automatization/workflows/autobuild.js

@@ -40,8 +40,12 @@ const ROADMAP = `${P}/roadmap`
 // Estado de planning tal como lo emite `ops context --json`; ningún modelo parsea BACKLOG ni WIP.
 const CONTEXT = {
   type: 'object', additionalProperties: false,
-  required: ['blocked', 'hasTask', 'wipActive', 'queued', 'cast'],
+  required: ['blocked', 'hasTask', 'wipActive', 'queued', 'cast', 'readOk'],
   properties: {
+    // Si el comando salió con error no hay estado que reportar, y `hasTask: false, queued: 0` es
+    // exactamente lo que un modelo completa cuando no tiene qué poner. Sin este campo esa invención se
+    // lee igual que una cola terminada, y Pick la toma como permiso para promover.
+    readOk: { type: 'boolean' },
     blocked: { type: 'string' }, hasTask: { type: 'boolean' }, wipActive: { type: 'boolean' },
     queued: { type: 'integer' }, slug: { type: 'string' }, hito: { type: 'string' },
     service: { type: 'string' }, acceptance: { type: 'string' }, epic: { type: 'string' },
@@ -73,10 +77,6 @@ const CLAIM = {
   type: 'object', additionalProperties: false, required: ['claimed'],
   properties: { claimed: { type: 'boolean' }, details: { type: 'string' } },
 }
-const EXPANSION = {
-  type: 'object', additionalProperties: false, required: ['expanded'],
-  properties: { expanded: { type: 'boolean' }, hito: { type: 'string' }, reason: { type: 'string' } },
-}
 const READY = {
   type: 'object', additionalProperties: false, required: ['ready', 'needsHuman'],
   properties: {
@@ -229,8 +229,16 @@ const CLASSIFICATION = {
 
 const CONTRACT = {
   type: 'object', additionalProperties: false,
-  required: ['project', 'workspaceRoots', 'maxTaskHours', 'commitPerTask', 'humanCheckpoint', 'contracts'],
+  required: ['project', 'workspaceRoots', 'maxTaskHours', 'commitPerTask', 'humanCheckpoint', 'contracts',
+    'rootOk'],
   properties: {
+    // `ROOT` viaja escrito en el workflow y es relativo al cwd de los agentes: si la sesión abrió en otra
+    // carpeta, todas las rutas resuelven a `<raíz>/<raíz>/…` y ninguna existe. Nada lo comprobaba, y el
+    // recorrido gastaba Triage entero sobre archivos ausentes antes de parar más abajo por otra causa,
+    // nombrando el planning en vez de la raíz de la que ese planning cuelga.
+    //
+    // Se pregunta acá porque acá ya se leen los cuatro archivos: cuesta un campo y ningún agente más.
+    rootOk: { type: 'boolean' },
     project: { type: 'string' }, workspaceRoots: { type: 'array', minItems: 1, items: { type: 'string' } },
     // La puerta que el proyecto declara, si la declara. Viaja con la raíz porque es de la base de código
     // y no del runner: un monorepo tiene una por servicio, y uno solo tiene una sola.
@@ -289,7 +297,9 @@ phase('Triage')
 // subagente como «Límites del proyecto» eran sólo los genéricos del toolkit.
 const contract = await agent(
   `${BASE}\n\nLeé ${ROOT}/AGENTS.md, ${ORG}/workspace.md, ${CONFIG} y ${P}/PROTOCOL.md una sola vez y no ` +
-  `leas nada más. Reportá los ` +
+  `leas nada más. Poné rootOk en true sólo si los cuatro existieron y los pudiste leer; si alguno no ` +
+  `estaba, rootOk en false y el resto en sus valores vacíos, sin deducirlos de otra fuente. ` +
+  `Reportá los ` +
   `valores de configuración textualmente: project, workspaceRoots como entradas "nombre → ruta", ` +
   `runner.maxTaskHours, runner.commitPerTask y runner.humanCheckpointBetweenMilestones como humanCheckpoint. ` +
   `En gates poné una entrada "ruta → comando" por cada workspaceRoot que declare \`verify\`, y ninguna por ` +
@@ -301,6 +311,12 @@ const contract = await agent(
   { schema: CONTRACT, label: 'contract-digest' },
 )
 if (!contract) return stop('contract-unavailable', `no se pudo leer ${CONFIG} ni ${P}/PROTOCOL.md`)
+// Falla acá y nombrando la raíz, que es lo que hace falta para arreglarlo: parar más abajo mandaba a
+// revisar el planning, y el planning está bien — lo que no existe es la carpeta de la que cuelga.
+if (!contract.rootOk) {
+  return stop('root-unreadable', `${ROOT} no se pudo leer entero. Es una ruta relativa a la carpeta `
+    + `donde se abre la herramienta: comprobá desde dónde estás corriendo el recorrido.`)
+}
 
 const bounds = contract.boundaries || []
 const limits = bounds.length ? ` Límites del proyecto: ${bounds.join('; ')}.` : ''
@@ -329,12 +345,17 @@ const readContext = () => read(
   `de task.tier; copiá slug, ` +
   `hito, service, acceptance, ` +
   `epic y cast de task, y epicContext de epic.context —vacío si no hay épica—. El comando es la fuente de ` +
-  `verdad: no abras archivos de planning para completarlo.`,
+  `verdad: no abras archivos de planning para completarlo. Poné readOk en true sólo si el comando salió ` +
+  `con código 0 y devolvió JSON; si falló, readOk en false y el resto en sus valores vacíos, sin ` +
+  `deducir el estado de ninguna otra fuente.`,
   { schema: CONTEXT, label: 'planning-context' },
 )
 
 let planning = await readContext()
 if (!planning) return stop('context-unavailable', `no se pudo leer el estado de ${P}`)
+// Que el agente conteste no significa que haya leído: el schema se completa igual con ceros. Parar acá
+// cuesta una corrida; seguir sobre una lectura fallida escribe en el BACKLOG, y eso no se revierte solo.
+if (!planning.readOk) return stop('context-unavailable', `${P} no se pudo leer; revisá la ruta y el cwd`)
 if (planning.blocked) return stop('awaiting-human-review', `${GATE} tiene un checkpoint humano sin resolver`)
 
 let currentMilestone = planning.wipActive ? planning.hito : ''
@@ -350,18 +371,15 @@ const classified = new Set()
 
 while (rounds++ < MAX_TASKS) {
   phase('Pick')
-  if (!planning.hasTask && !planning.queued) {
-    const expansion = await write(
-      `Leé ${ROADMAP}. Expandí sólo la próxima épica abierta y aprobada en un hito nuevo de ${BACKLOG}, ` +
-      `conservando el slug de cada historia, sus referencias a criterios y su servicio. Nunca promuevas ` +
-      `${P}/INBOX.md. Reportá si escribiste algo.`,
-      { schema: EXPANSION },
-    )
-    if (!expansion) return stop('agent-unavailable', 'Pick no devolvió resultado')
-    if (!expansion.expanded) break
-    planning = await readContext()
-    if (!planning) return stop('context-unavailable', `no se pudo releer el estado de ${P}`)
-  }
+  // Sin tarea y con la cola vacía, la corrida termina. **No expande la próxima épica**, y eso no es una
+  // limitación sino la regla: 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 que hacía esto 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.
+  //
+  // `context` nombra la que sigue, igual que nombra una recurrencia vencida y por el mismo motivo: la
+  // máquina calcula y la persona encola.
   if (!planning.hasTask || (currentMilestone && planning.hito !== currentMilestone)) break
   const task = {
     id: planning.slug, hito: planning.hito, service: planning.service,

package/engine/agents/learning-seal.js

@@ -12,6 +12,8 @@ const path = require('node:path')
 const { atomicWrite } = require('../core/files')
 const { isoDate, proposalFiles, proposalState, assertWritable, lastOfPeriod } = require('./learning-files')
 const { section } = require('../planning/parser')
+// La misma identidad con la que se reclama una tarea: quién es la persona, no qué runner corre.
+const { owner } = require('../planning/claims')
 
 // El cuerpo sin sellar, en los dos estados que produce el ciclo: «pendiente» lo escribe el molde y
 // «aprobada» la firma. Lo lee la guarda de más abajo y lo reemplaza el sello, así que vive una vez.
@@ -102,22 +104,51 @@ function archive(root, agent, period = '', kind = 'agent') {
       + 'Archivar es para lo que se miró y no cambia nada.',
     )
   }
+  // Quién archivó, que es la mitad que faltaba. Sellar saca el responsable del documento —lo escribió la
+  // firma— y archivar no pasa por firma, así que sale de la identidad de quien corre el comando: la misma
+  // que `claim` usa para decir de quién es una tarea. Sin esto la propuesta quedaba en «por definir» y no
+  // había forma de distinguir una decisión de un olvido.
+  const responsible = owner(root) || 'sin identificar'
   atomicWrite(file, text
     .replace(/^status:\s*\S+\s*$/m, 'status: archived')
     .replace(/^-[ \t]*Estado:[ \t]*pendiente[ \t]*$/mi, '- Estado: archivada')
+    .replace(/^-[ \t]*Responsable:[ \t]*por definir[ \t]*$/mi, `- Responsable: ${responsible}`)
     .replace(/^-[ \t]*Fecha:[ \t]*por definir[ \t]*$/mi, `- Fecha: ${isoDate(new Date())}`))
+  // La fila va para los dos tipos, y no sólo para los recorridos como en `seal`: allá los cargos los
+  // registra `agent-promote` al aplicar, y archivar no pasa por ningún workflow que lo haga.
+  // La raíz del cargo, que es `<cargo>/learning/proposals/<archivo>` sin sus tres últimos tramos:
+  // `appendHistory` agrega `learning/` por su cuenta.
+  //
+  // La celda del cambio lleva el criterio y no queda vacía. Es el único que este comando admite —archivar
+  // *es* decidir que no cambia nada— así que decirlo evita que la fila se lea como un registro a medias.
+  // Archivar por otra razón, como posponer, necesitaría un campo que hoy no existe.
+  appendHistory(path.dirname(path.dirname(path.dirname(file))), file, responsible,
+    'Se miró y no cambia nada.', 'archivada')
   return { file, already: false }
 }
 
-// Una fila por propuesta aplicada. El cambio va en una línea: el documento entero está a un enlace, y
-// una tabla que lo repite entero deja de leerse.
-function appendHistory(target, file, responsible, change) {
+// Una fila por propuesta cerrada, cualquiera sea el destino. El cambio va en una línea: el documento
+// entero está a un enlace, y una tabla que lo repite entero deja de leerse.
+//
+// La decisión es un parámetro y no la constante `aplicada` porque la columna de la tabla se llama
+// «Decisión» y hay dos: aplicar y archivar. Archivar no dejaba fila, así que una propuesta mirada y
+// descartada era indistinguible de una que nadie miró — y eso lo pagaban los informes siguientes, que
+// gastaban su recomendación explicando el estado en vez de su profesión.
+const HISTORY_HEADER = '| Fecha | Propuesta | Decisión | Aprobó | Cambio aplicado |\n|---|---|---|---|---|\n'
+
+function appendHistory(target, file, responsible, change, decision = 'aplicada') {
   const history = path.join(target, 'learning', 'HISTORY.md')
   if (!fs.existsSync(history)) return
+  const previous = fs.readFileSync(history, 'utf8')
   const line = change.split('\n').map((one) => one.trim()).filter(Boolean)[0] || ''
-  const row = `| ${isoDate(new Date())} | \`${path.basename(file)}\` | aplicada | ${responsible} `
+  const row = `| ${isoDate(new Date())} | \`${path.basename(file)}\` | ${decision} | ${responsible} `
     + `| ${line.slice(0, 160)} |\n`
-  fs.appendFileSync(history, `${fs.readFileSync(history, 'utf8').endsWith('\n') ? '' : '\n'}${row}`)
+  // Dieciséis de los cincuenta y tres cargos tienen el archivo sin la tabla, sólo con su párrafo de
+  // encabezado, y la fila quedaba pegada ahí: en markdown eso no es una tabla sino texto con barras, y
+  // nadie lo veía porque el archivo se lee dos veces al año. Se agrega la cabecera antes de la primera
+  // fila en vez de exigir que ya esté, que es pedirle a cada cargo que se acuerde.
+  const cabecera = /^\|\s*Fecha\s*\|/m.test(previous) ? '' : `\n${HISTORY_HEADER}`
+  fs.appendFileSync(history, `${previous.endsWith('\n') ? '' : '\n'}${cabecera}${row}`)
 }
 
 module.exports = { seal, archive }