@ingeniomaps/cauce 0.3.0 → 0.4.0

package/CHANGELOG.md

@@ -8,6 +8,36 @@ esa operación sea confiable en vez de sólo cómoda: acá se lee qué cambió a
 un cambio en el protocolo, en las reglas del sistema o en un guard es visible para el usuario y sube
 minor aunque no toque una sola línea de código.
 
+## [0.4.0] - 2026-08-15
+
+### Cambiado
+
+- **Ni el catálogo de cargos ni los equipos se copian al proyecto.** Son definiciones que consume el
+  motor: se resuelven desde la dependencia npm, o desde `.ops/` cuando el repo no usa npm. Las reglas
+  y decisiones de `planning/*/system/` sí siguen materializadas, porque la empresa las lee y las cita
+  en su propio repositorio.
+- **El catálogo de cargos ya no se copia al proyecto.** Se resuelve desde la dependencia npm, o desde
+  `.ops/agents/` cuando el repo no usa npm. Una instancia pasa de ~950 KB a ~480 KB y su `git diff`
+  muestra sólo lo que la empresa escribió.
+- El ciclo mensual de aprendizaje dejó de distribuirse: investiga cómo evoluciona una profesión, y eso
+  es igual para todas las empresas. Corriéndolo en cada instalación, cuatro empresas producían cuatro
+  investigaciones casi idénticas del mismo tema, cada una peor que una hecha bien. Ahora vive sólo en
+  el repositorio del toolkit y llega actualizando la dependencia.
+- `learn` y `learn --proposal` fallan con explicación si se corren sobre un cargo del catálogo dentro
+  de una instancia: escribirían en el paquete y se perderían en el próximo `npm ci`.
+- Las fuentes `local://` salieron de los 47 cargos. Lo que un cargo debe saber de una empresa vive
+  ahora en `organization/roles/<slug>.md`, y los 47 lo citan.
+
+### Corregido
+
+- `upgrade` no actualizaba el catálogo de cargos, o sea el 75% del paquete: un cargo nuevo o mejorado
+  nunca llegaba a un proyecto ya inicializado. Ahora se refresca como el resto del sistema, con una
+  excepción precisa: `learning/` dentro de cada cargo es del proyecto y no se toca, porque los
+  informes acumulados son lo único que no se puede reponer desde el paquete.
+
+- El `$schema` de `ops.config.json` apuntaba siempre a `.ops/engine/`, una ruta que no existe cuando el
+  motor viene como dependencia. Ahora se escribe según dónde quedó el motor.
+
 ## [0.3.0] - 2026-08-15
 
 ### Añadido

package/README.md

@@ -155,7 +155,7 @@ Cada colección adaptable separa lo que actualiza el toolkit de lo que escribe e
 | `planning/adr/` | `OPS-NNN` | las decisiones de la empresa |
 | `planning/rules/` | proceso, forma del cambio, commits | las convenciones propias |
 | `teams/` | composiciones que vienen con Cauce | los equipos propios |
-| `agents/<tipo>/` | los cargos que trae Cauce | los cargos propios |
+| `agents/<tipo>/` | *(en el paquete, no se copia)* | los cargos propios |
 
 `automatization/hooks/` y `automatization/runners/` no tienen `system/`: son runtime que se reemplaza
 entero. No hace falta, porque lo que un proyecto necesita ya funciona sin editarlos — un guard propio
@@ -166,6 +166,21 @@ Un archivo propio con el mismo nombre o ID que uno de `system/` lo reemplaza: el
 `check` lo reporta como override explícito. Así una mejora del proceso no obliga a forkear el archivo,
 y actualizar no exige resolver conflictos: se reemplaza `system/` entero y nada más se toca.
 
+### Dónde vive cada cosa del catálogo
+
+Los cargos que trae Cauce **no se copian al proyecto**: se resuelven desde la dependencia, o desde
+`.ops/agents/` cuando el repo no usa npm. Evolucionan como profesión, y esa evolución es la misma para
+todas las empresas: investigarla una vez y bien es mejor que repetirla en cada instalación.
+
+| Qué | Dónde | Quién lo mantiene |
+|---|---|---|
+| El cargo como profesión | el paquete | el toolkit, con `agent-learn` en **este** repositorio |
+| Lo que el cargo debe saber de tu empresa | `organization/roles/<slug>.md` | la empresa |
+| Un cargo propio, o una versión propia de uno del catálogo | `agents/roles/<slug>/` | la empresa |
+
+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 mensual de aprendizaje tampoco se distribuye — vive sólo acá.
+
 ### Versionado
 
 Como `upgrade` reemplaza `system/` sin pedir confirmación, un cambio en el protocolo, en una regla del

package/agents/roles/system/ai-governance-lead/SKILL.md

@@ -10,6 +10,8 @@ Hacer visible qué IA existe, quién responde, a quién afecta, qué evidencia s
 ## Construir contexto
 
 1. Leer `AGENTS.md`, `ops.config.json`, `organization/`, políticas, risk appetite, inventarios, contratos, data maps, incidentes y jurisdicciones de la empresa.
+   Leer también `organization/roles/ai-governance-lead.md` si existe: son las restricciones reales de
+   esta empresa para este cargo.
 2. Capturar IA desarrollada, comprada, embebida, configurada, experimental, open source, general-purpose, agentic y “shadow AI”.
 3. Identificar lifecycle role por mercado/caso —developer, provider, deployer, importer, distributor, operator u otro— sin asumir que una etiqueta es global.
 4. Mapear owners, autoridad y autorización requerida de negocio, Product, Engineering/ML, Data, Security, Privacy, Legal, Compliance, Procurement, People y representantes afectados.

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

@@ -6,11 +6,9 @@ rules:
   require_corroboration_for_major_change: true
   reject_unsourced_claims: true
   automatic_apply: false
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/ai-governance-lead.md dentro de cada instalación.
 sources:
-  - name: Company AI policy inventory risk appetite approvals incidents and jurisdiction register
-    url: local://ai-governance-context
-    tier: company-primary
-    topics: [ai-policy, inventory, risk, approvals, incidents, jurisdictions]
   - name: NIST Artificial Intelligence Risk Management Framework 1.0
     url: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
     tier: government-primary

package/agents/roles/system/ai-product-manager/SKILL.md

@@ -10,6 +10,8 @@ Resolver problemas reales con el nivel mínimo de IA necesario. Diseñar el prod
 ## Construir contexto
 
 1. Leer `AGENTS.md`, `ops.config.json`, `organization/`, estrategia, investigación, métricas, AI inventory, políticas, incidentes, contratos y decisiones.
+   Leer también `organization/roles/ai-product-manager.md` si existe: son las restricciones reales de
+   esta empresa para este cargo.
 2. Definir usuario afectado, job/problem, alternativa actual, outcome, business model, owners, autoridad, jurisdicciones y stakes.
 3. Mapear datos, contenido, providers, modelos, tools/actions, personas, feedback, decisiones downstream y lifecycle completo.
 4. Identificar grupos y contextos de uso/no uso, errores previsibles, severidad, reversibilidad, detectabilidad, abuso y afectados indirectos.

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

@@ -6,9 +6,9 @@ rules:
   require_corroboration_for_major_change: true
   reject_unsourced_claims: true
   automatic_apply: false
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/ai-product-manager.md dentro de cada instalación.
 sources:
-  - {name: Company strategy research AI inventory policies incidents contracts and approved metrics, url: "local://ai-product-context", tier: company-primary, topics: [strategy, research, inventory, policies, incidents, metrics]}
-  - {name: Approved model and provider official documentation terms and change notices, url: "local://approved-ai-provider-documentation", tier: vendor-primary, topics: [model, provider, terms, versions, changes]}
   - {name: NIST AI RMF 1.0 and status, url: "https://www.nist.gov/itl/ai-risk-management-framework", tier: government-primary, 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: government-primary, topics: [generative-ai, risk, evaluation]}
   - {name: ISO IEC 42001 AI management systems, url: "https://www.iso.org/standard/42001", tier: standards-primary, topics: [ai-management, governance, improvement]}

package/agents/roles/system/analytics-engineer/SKILL.md

@@ -10,6 +10,8 @@ Convertir datos gobernados en modelos y métricas comprensibles, reproducibles y
 ## Construir contexto
 
 1. Leer `AGENTS.md`, `ops.config.json`, `organization/`, glosario, catálogo, contratos, métricas, políticas y decisiones.
+   Leer también `organization/roles/analytics-engineer.md` si existe: son las restricciones reales de
+   esta empresa para este cargo.
 2. Identificar decisión, consumidores, business/data owners, fuentes, destino, SLA y autoridad.
 3. Definir grain, entidades, claves, timestamps, timezone, moneda, historia, población y exclusiones antes de transformar.
 4. Mapear lineage, clasificación, acceso, calidad, volumen, costo, freshness y dependencias.

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

@@ -6,8 +6,9 @@ rules:
   require_corroboration_for_major_change: true
   reject_unsourced_claims: true
   automatic_apply: false
+# 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: Company glossary metrics contracts catalog platform policies and decisions, url: "local://analytics-engineering-context", tier: company-primary, topics: [glossary, metrics, contracts, platform]}
   - {name: ISO IEC 25012 data quality model, url: "https://www.iso.org/standard/35736.html", tier: standards-primary, topics: [data-quality, measures, evaluation]}
   - {name: ISO 8000-61 data quality management, url: "https://www.iso.org/standard/63086.html", tier: standards-primary, topics: [data-quality, process, maturity]}
   - {name: W3C RDF Data Cube Vocabulary, url: "https://www.w3.org/TR/vocab-data-cube/", tier: standards-primary, topics: [measures, dimensions, metadata]}

package/agents/roles/system/backend-engineer/SKILL.md

@@ -10,6 +10,8 @@ Actuar como responsable de servicios correctos, seguros, confiables y observable
 ## Construir contexto
 
 1. Localizar la raíz operativa y leer `AGENTS.md`, `ops.config.json` e instrucciones del servicio.
+   Leer también `organization/roles/backend-engineer.md` si existe: son las restricciones
+   reales de esta empresa para este cargo.
 2. Identificar lenguaje, framework, runtime, base de datos, versiones, package manager y comandos reales. No asumir tecnología.
 3. Leer aceptación, modelo de dominio, contratos de API, esquemas, políticas de seguridad y privacidad relevantes.
 4. Inspeccionar fronteras, patrones, migraciones y pruebas existentes antes de crear capas o dependencias.

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

@@ -6,11 +6,9 @@ rules:
   reject_unsourced_claims: true
   automatic_apply: false
 
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/backend-engineer.md dentro de cada instalación.
 sources:
-  - name: Project manifests and official stack docs
-    url: local://service-manifest
-    tier: project-primary
-    topics: [runtime, framework, database, migrations]
   - name: RFC Editor HTTP
     url: https://www.rfc-editor.org/rfc/rfc9110.html
     tier: primary-standard

package/agents/roles/system/business-operations-manager/SKILL.md

@@ -10,6 +10,8 @@ Diseñar cómo fluye el valor y cómo se toman decisiones entre funciones. Reduc
 ## Construir contexto
 
 1. Leer `AGENTS.md`, `ops.config.json`, estrategia, estructura, políticas, procesos y fuentes de datos.
+   Leer también `organization/roles/business-operations-manager.md` si existe: son las restricciones reales de
+   esta empresa para este cargo.
 2. Identificar outcomes, clientes/stakeholders, procesos críticos, entidades, jurisdicciones, owners, autoridad y restricciones.
 3. Mapear flujo end-to-end, entradas/salidas, handoffs, sistemas, proveedores, capacidad, tiempos, controles, excepciones y fallos.
 4. Confirmar definiciones, grain, source of truth, calidad, frecuencia, acceso y owner de cada métrica.

package/agents/roles/system/business-operations-manager/learning/sources.yaml

@@ -6,11 +6,9 @@ rules:
   require_corroboration_for_major_change: true
   reject_unsourced_claims: true
   automatic_apply: false
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/business-operations-manager.md dentro de cada instalación.
 sources:
-  - name: Company strategy governance processes systems policies and approved metrics
-    url: local://business-operations-context
-    tier: company-primary
-    topics: [strategy, governance, processes, systems, policies, metrics, decisions]
   - name: ISO 9001 quality management systems
     url: https://www.iso.org/standard/62085.html
     tier: standards-primary

package/agents/roles/system/business-strategist/SKILL.md

@@ -10,6 +10,8 @@ Actuar como responsable de convertir ambición en un conjunto coherente de elecc
 ## Construir contexto
 
 1. Localizar la raíz operativa y leer `AGENTS.md`, `ops.config.json`, contexto de empresa, producto, clientes y planificación.
+   Leer también `organization/roles/business-strategist.md` si existe: son las restricciones
+   reales de esta empresa para este cargo.
 2. Identificar etapa, geografía, sector, modelo de ingresos, canales, capacidades, restricciones, gobierno y horizonte. No asumir tipo de empresa.
 3. Leer evidencia de clientes, producto, ventas, soporte, finanzas, operaciones, mercado y decisiones previas.
 4. Verificar definiciones, periodos, moneda, fuentes y comparabilidad antes de usar cifras o benchmarks.

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

@@ -6,15 +6,9 @@ rules:
   reject_unsourced_claims: true
   automatic_apply: false
 
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/business-strategist.md dentro de cada instalación.
 sources:
-  - name: Company strategy customer product sales finance and operations
-    url: local://business-strategy-context
-    tier: company-primary
-    topics: [goals, customers, capabilities, economics, decisions]
-  - name: Official market and sector sources
-    url: local://market-primary-sources
-    tier: market-primary
-    topics: [market, regulation, competitors, benchmarks]
   - name: OECD Strategic Foresight
     url: https://www.oecd.org/strategic-foresight/
     tier: primary-practice

package/agents/roles/system/cloud-architect/SKILL.md

@@ -10,6 +10,8 @@ Traducir outcomes y restricciones en una arquitectura operable, segura, resilien
 ## Construir contexto
 
 1. Leer `AGENTS.md`, `ops.config.json`, `organization/`, estrategia, catálogo, arquitectura, políticas, contratos, SLO, RTO/RPO, presupuesto y decisiones.
+   Leer también `organization/roles/cloud-architect.md` si existe: son las restricciones reales de
+   esta empresa para este cargo.
 2. Definir workload, usuarios, owners, criticidad, demanda, datos, jurisdicciones, dependencias, skills, plazos y autoridad.
 3. Inventariar proveedores, organizaciones/cuentas/proyectos, regiones, redes, identidad, servicios, quotas, compromisos, soporte y deuda.
 4. Cuantificar baseline y escenarios de disponibilidad, latencia, throughput, crecimiento, recuperación, costo unitario y carbono cuando sea material.

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

@@ -6,9 +6,9 @@ rules:
   require_corroboration_for_major_change: true
   reject_unsourced_claims: true
   automatic_apply: false
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/cloud-architect.md dentro de cada instalación.
 sources:
-  - {name: Company strategy inventory architecture SLO policies costs contracts and approved telemetry, url: "local://cloud-architecture-context", tier: company-primary, topics: [strategy, inventory, architecture, slo, policy, costs]}
-  - {name: Approved provider official documentation pricing SLA quotas and status, url: "local://approved-cloud-provider-documentation", tier: vendor-primary, topics: [services, pricing, sla, quotas, regions]}
   - {name: NIST SP 800-145 cloud definition, url: "https://csrc.nist.gov/pubs/sp/800/145/final", tier: government-primary, topics: [cloud, service-models, deployment-models]}
   - {name: ISO IEC 27017 cloud security controls, url: "https://www.iso.org/standard/43757.html", tier: standards-primary, topics: [cloud-security, customers, providers]}
   - {name: ISO IEC 27017 edition 2 status, url: "https://www.iso.org/standard/82878.html", tier: standards-primary, topics: [cloud-security, revision-status]}

package/agents/roles/system/community-manager/SKILL.md

@@ -10,6 +10,8 @@ Crear condiciones para que miembros reales obtengan valor, construyan confianza
 ## Construir contexto
 
 1. Leer `AGENTS.md`, `ops.config.json`, `organization/`, estrategia, producto, marca, privacidad, seguridad, código de conducta, canales y procesos de incidentes.
+   Leer también `organization/roles/community-manager.md` si existe: son las restricciones reales de
+   esta empresa para este cargo.
 2. Definir propósito, audiencia, membership boundary, necesidades, idiomas, regiones, accesibilidad, canales y relación con Support, Success, DevRel y Marketing.
 3. Mapear journey: descubrimiento, ingreso, orientación, primera interacción, primer valor, contribución, reconocimiento, liderazgo, pausa y salida.
 4. Identificar owners y autoridad para publicar, moderar, investigar, sancionar, escalar, organizar eventos, otorgar beneficios y manejar crisis.

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

@@ -6,11 +6,9 @@ rules:
   require_corroboration_for_major_change: true
   reject_unsourced_claims: true
   automatic_apply: false
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/community-manager.md dentro de cada instalación.
 sources:
-  - name: Company community policies channels product members and approved metrics
-    url: local://community-management-context
-    tier: company-primary
-    topics: [community, policies, channels, product, members, metrics]
   - name: Contributor Covenant 3.0
     url: https://www.contributor-covenant.org/version/3/0/code_of_conduct/
     tier: practitioner-primary

package/agents/roles/system/content-specialist/SKILL.md

@@ -10,6 +10,8 @@ Actuar como responsable de ayudar a una audiencia específica a comprender o hac
 ## Construir contexto
 
 1. Localizar la raíz operativa y leer `AGENTS.md`, `ops.config.json`, contexto de empresa, marca, producto y planificación.
+   Leer también `organization/roles/content-specialist.md` si existe: son las restricciones
+   reales de esta empresa para este cargo.
 2. Identificar audiencia, necesidad, etapa, canal, formato, idioma, geografía, objetivo, owner y flujo de aprobación. No asumir voz ni plataforma.
 3. Leer guías de estilo, terminología, posicionamiento, claims aprobados, investigación, analytics, inventario y contenido relacionado.
 4. Verificar capacidades y fuentes primarias antes de describir producto, resultados, cifras, normas o terceros.

package/agents/roles/system/content-specialist/learning/sources.yaml

@@ -6,15 +6,9 @@ rules:
   reject_unsourced_claims: true
   automatic_apply: false
 
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/content-specialist.md dentro de cada instalación.
 sources:
-  - name: Company brand product claims research analytics and content inventory
-    url: local://content-context
-    tier: company-primary
-    topics: [brand, product, claims, audience, performance, inventory]
-  - name: Applicable official accessibility advertising and sector sources
-    url: local://content-official-sources
-    tier: legal-primary
-    topics: [accessibility, advertising, disclosures, sector]
   - name: W3C Writing for Web Accessibility
     url: https://www.w3.org/WAI/tips/writing/
     tier: primary-standard

package/agents/roles/system/customer-success-manager/SKILL.md

@@ -10,6 +10,8 @@ Actuar como responsable de convertir expectativas contratadas en resultados sost
 ## Construir contexto
 
 1. Localizar la raíz operativa y leer `AGENTS.md`, `ops.config.json`, contexto de empresa, producto y políticas de clientes.
+   Leer también `organization/roles/customer-success-manager.md` si existe: son las restricciones
+   reales de esta empresa para este cargo.
 2. Identificar segmento, modelo de servicio, contrato, alcance, lifecycle, owners, CRM, canales y autoridad comercial. No asumir high-touch o SaaS.
 3. Leer handoff de ventas, objetivos, stakeholders, uso, soporte, facturación, riesgos, compromisos y comunicaciones consentidas.
 4. Verificar capacidades, roadmap, SLA, seguridad, integraciones y datos antes de recomendar o prometer.

package/agents/roles/system/customer-success-manager/learning/sources.yaml

@@ -6,15 +6,9 @@ rules:
   reject_unsourced_claims: true
   automatic_apply: false
 
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/customer-success-manager.md dentro de cada instalación.
 sources:
-  - name: Company contracts handoffs usage support billing CRM and success policies
-    url: local://customer-success-context
-    tier: company-primary
-    topics: [outcomes, scope, adoption, support, health, renewal]
-  - name: Applicable customer consumer and sector authorities
-    url: local://customer-success-official-sources
-    tier: legal-primary
-    topics: [customers, complaints, service, privacy, sector]
   - name: ISO 10001
     url: https://www.iso.org/standard/71579.html
     tier: primary-standard

package/agents/roles/system/customer-support-specialist/SKILL.md

@@ -10,6 +10,8 @@ Actuar como responsable de reducir el esfuerzo y el riesgo del cliente mientras
 ## Construir contexto
 
 1. Localizar la raíz operativa y leer `AGENTS.md`, `ops.config.json`, producto, políticas de soporte, seguridad y escalación.
+   Leer también `organization/roles/customer-support-specialist.md` si existe: son las restricciones
+   reales de esta empresa para este cargo.
 2. Identificar canal, cliente/plan cuando esté autorizado, severidad, SLA, producto, versión, entorno, idioma, zona horaria y ownership. No asumir identidad o prioridad.
 3. Leer conversación completa, estado del servicio, documentación, incidentes, cambios, casos relacionados y acciones previas.
 4. Verificar capacidades, permisos, workarounds, límites y estado antes de responder.

package/agents/roles/system/customer-support-specialist/learning/sources.yaml

@@ -6,15 +6,9 @@ rules:
   reject_unsourced_claims: true
   automatic_apply: false
 
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/customer-support-specialist.md dentro de cada instalación.
 sources:
-  - name: Company product docs status incidents support policies SLA and knowledge
-    url: local://customer-support-context
-    tier: company-primary
-    topics: [product, support, sla, incidents, troubleshooting, knowledge]
-  - name: Applicable customer consumer accessibility and sector authorities
-    url: local://support-official-sources
-    tier: legal-primary
-    topics: [customers, complaints, accessibility, privacy, sector]
   - name: ISO 10002
     url: https://www.iso.org/standard/71580.html
     tier: primary-standard

package/agents/roles/system/data-analyst/SKILL.md

@@ -10,6 +10,8 @@ Actuar como responsable de producir evidencia útil, reproducible y honesta para
 ## Construir contexto
 
 1. Localizar la raíz operativa y leer `AGENTS.md`, `ops.config.json`, contexto de empresa, producto y planificación.
+   Leer también `organization/roles/data-analyst.md` si existe: son las restricciones
+   reales de esta empresa para este cargo.
 2. Identificar decisión, audiencia, fuentes, ownership, catálogo, permisos, herramientas, zona horaria y comandos reales. No asumir warehouse ni esquema.
 3. Leer contratos de eventos, modelos, definiciones métricas, transformaciones, dashboards y decisiones anteriores.
 4. Inspeccionar granularidad, claves, cobertura temporal, frescura, lineage y controles de calidad antes de consultar.

package/agents/roles/system/data-analyst/learning/sources.yaml

@@ -6,15 +6,9 @@ rules:
   reject_unsourced_claims: true
   automatic_apply: false
 
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/data-analyst.md dentro de cada instalación.
 sources:
-  - name: Company metric catalog schemas models lineage and decisions
-    url: local://analytics-context
-    tier: company-primary
-    topics: [metrics, schemas, lineage, quality, decisions]
-  - name: Official data platform and BI documentation
-    url: local://analytics-stack-docs
-    tier: platform-primary
-    topics: [sql, semantics, performance, visualization]
   - name: NIST Statistical Methods Handbook
     url: https://www.itl.nist.gov/div898/handbook/
     tier: primary-method

package/agents/roles/system/data-engineer/SKILL.md

@@ -10,6 +10,8 @@ Entregar datos correctos para un propósito declarado, con semántica, lineage y
 ## Construir contexto
 
 1. Leer `AGENTS.md`, `ops.config.json`, `organization/`, arquitectura, catálogo, políticas, contratos de datos, métricas y runbooks aprobados.
+   Leer también `organization/roles/data-engineer.md` si existe: son las restricciones reales de
+   esta empresa para este cargo.
 2. Identificar productores, consumidores, owners, decisiones, fuentes of truth, grain, claves, timestamps, zonas horarias, volúmenes, latencia y patrones de acceso.
 3. Clasificar datos, propósito, base/permiso, residencia, retención, borrado, sensibilidad, acceso y restricciones contractuales.
 4. Mapear source → ingest → raw → transform → serve, dependencias, ambientes, versiones, costos, failure domains y autoridad de cambio.

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

@@ -6,11 +6,9 @@ rules:
   require_corroboration_for_major_change: true
   reject_unsourced_claims: true
   automatic_apply: false
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/data-engineer.md dentro de cada instalación.
 sources:
-  - name: Company data contracts schemas catalog lineage policies metrics and runbooks
-    url: local://data-engineering-context
-    tier: company-primary
-    topics: [contracts, schemas, lineage, policies, metrics, operations]
   - name: ISO IEC 25012 data quality model
     url: https://www.iso.org/standard/35736.html
     tier: standards-primary

package/agents/roles/system/data-scientist/SKILL.md

@@ -10,6 +10,8 @@ Reducir incertidumbre sobre decisiones, no producir números decorativos. Empeza
 ## Construir contexto
 
 1. Leer `AGENTS.md`, `ops.config.json`, `organization/`, estrategia, decisiones, definiciones, experimentos previos, data contracts y políticas.
+   Leer también `organization/roles/data-scientist.md` si existe: son las restricciones reales de
+   esta empresa para este cargo.
 2. Definir población, unidad, exposición/treatment, outcome, horizonte, segmentos, decisión, alternativas y costo de errores.
 3. Mapear fuentes, grain, keys, timestamps, lineage, calidad, missingness, selección, cobertura, privacidad, consentimiento/base y owners.
 4. Separar pregunta descriptiva, diagnóstica, predictiva, causal y prescriptiva; declarar qué evidencia permitiría cambiar de decisión.

package/agents/roles/system/data-scientist/learning/sources.yaml

@@ -6,11 +6,9 @@ rules:
   require_corroboration_for_major_change: true
   reject_unsourced_claims: true
   automatic_apply: false
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/data-scientist.md dentro de cada instalación.
 sources:
-  - name: Company decisions metrics data contracts experiments policies and domain context
-    url: local://data-science-context
-    tier: company-primary
-    topics: [decisions, metrics, data, experiments, policies, domain]
   - name: ASA Ethical Guidelines for Statistical Practice
     url: https://www.amstat.org/your-career/ethical-guidelines-for-statistical-practice
     tier: professional-primary

package/agents/roles/system/database-administrator/SKILL.md

@@ -10,6 +10,8 @@ Proteger la integridad, disponibilidad, confidencialidad y recuperabilidad de ba
 ## Construir contexto
 
 1. Leer `AGENTS.md`, `ops.config.json`, `organization/`, catálogo de servicios, runbooks, arquitectura, clasificación, SLO, RTO/RPO y políticas.
+   Leer también `organization/roles/database-administrator.md` si existe: son las restricciones reales de
+   esta empresa para este cargo.
 2. Inventariar motor/edición/versión, topología, entorno, owner, criticidad, regiones, dependencias, clientes, ventanas y soporte.
 3. Identificar datos y obligaciones: clasificación, residencia, retención, cifrado, auditoría, accesos y segregación de funciones.
 4. Obtener evidencia segura de salud, capacidad, replicación, backups, restores, cambios, consultas y eventos; redactar secretos y datos.

package/agents/roles/system/database-administrator/learning/sources.yaml

@@ -6,9 +6,9 @@ rules:
   require_corroboration_for_major_change: true
   reject_unsourced_claims: true
   automatic_apply: false
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/database-administrator.md dentro de cada instalación.
 sources:
-  - {name: Company database inventory SLO RTO RPO runbooks policies and approved telemetry, url: "local://database-administration-context", tier: company-primary, topics: [inventory, slo, recovery, runbooks, policies]}
-  - {name: Database engine and provider official documentation, url: "local://approved-engine-documentation", tier: vendor-primary, topics: [engine, version, configuration, operations]}
   - {name: ISO IEC 27040 storage security, url: "https://www.iso.org/standard/80194.html", tier: standards-primary, topics: [storage, security, lifecycle]}
   - {name: ISO 22301 business continuity, url: "https://www.iso.org/standard/75106.html", tier: standards-primary, topics: [continuity, resilience, recovery]}
   - {name: NIST SP 800-34 Rev 1 contingency planning, url: "https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final", tier: government-primary, topics: [contingency, backup, recovery, exercises]}

package/agents/roles/system/developer-relations-engineer/SKILL.md

@@ -10,6 +10,8 @@ Reducir el tiempo desde intención hasta primer resultado correcto y producción
 ## Construir contexto
 
 1. Leer `AGENTS.md`, `ops.config.json`, `organization/`, producto, APIs/SDKs, versiones soportadas, políticas de publicación, seguridad, privacidad, marca, comunidad y open source.
+   Leer también `organization/roles/developer-relations-engineer.md` si existe: son las restricciones reales de
+   esta empresa para este cargo.
 2. Definir audiencia por rol, stack, experiencia, idioma, accesibilidad, contexto y job-to-be-done; no tratar “developers” como un segmento único.
 3. Mapear journey: descubrimiento, credenciales, primer request, primer valor, depuración, producción, actualización y contribución.
 4. Confirmar fuentes of truth, owners y autoridad de Product, Engineering, Docs, Support, Security, Legal, Marketing y Community.

package/agents/roles/system/developer-relations-engineer/learning/sources.yaml

@@ -6,11 +6,9 @@ rules:
   require_corroboration_for_major_change: true
   reject_unsourced_claims: true
   automatic_apply: false
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/developer-relations-engineer.md dentro de cada instalación.
 sources:
-  - name: Company public product docs APIs SDKs policies community and approved metrics
-    url: local://developer-relations-context
-    tier: company-primary
-    topics: [product, api, sdk, community, policies, metrics]
   - name: OpenAPI Specification latest published
     url: https://spec.openapis.org/oas/latest.html
     tier: specification-primary

package/agents/roles/system/devops-engineer/SKILL.md

@@ -10,6 +10,8 @@ Actuar como responsable de un camino de entrega repetible, seguro, observable y
 ## Construir contexto
 
 1. Localizar la raíz operativa y leer `AGENTS.md`, `ops.config.json`, instrucciones y límites de cada entorno.
+   Leer también `organization/roles/devops-engineer.md` si existe: son las restricciones
+   reales de esta empresa para este cargo.
 2. Identificar proveedor, runtime, infraestructura, CI/CD, registros, secretos, identidades, ramas y comandos reales. No asumir plataforma.
 3. Leer aceptación, arquitectura, dependencias, políticas, SLO, recuperación y responsabilidades de aprobación.
 4. Inspeccionar manifests, lockfiles, módulos, pipelines, estado remoto y convenciones existentes antes de crear herramientas o capas nuevas.

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

@@ -6,11 +6,9 @@ rules:
   reject_unsourced_claims: true
   automatic_apply: false
 
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/devops-engineer.md dentro de cada instalación.
 sources:
-  - name: Project manifests pipelines policies and runbooks
-    url: local://delivery-context
-    tier: project-primary
-    topics: [runtime, infrastructure, cicd, environments, recovery]
   - name: DORA Capabilities
     url: https://dora.dev/capabilities/
     tier: primary-research

package/agents/roles/system/engineering-manager/SKILL.md

@@ -10,6 +10,8 @@ Actuar como responsable del sistema en el que trabaja el equipo: claridad, segur
 ## Construir contexto
 
 1. Leer `AGENTS.md`, `ops.config.json`, contexto de empresa, producto, equipos y políticas de personas.
+   Leer también `organization/roles/engineering-manager.md` si existe: son las restricciones reales de
+   esta empresa para este cargo.
 2. Identificar misión, ownership, miembros, zonas horarias, seniority, capacidad, on-call, dependencias y autoridad. No asumir estructura.
 3. Revisar roadmap, carga operativa, incidentes, flujo, deuda, calidad, feedback y acuerdos vigentes.
 4. Usar datos agregados del sistema y evidencia autorizada; no inferir desempeño personal de commits, horas, presencia o actividad.

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

@@ -5,11 +5,9 @@ rules:
   require_corroboration_for_major_change: true
   reject_unsourced_claims: true
   automatic_apply: false
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/engineering-manager.md dentro de cada instalación.
 sources:
-  - name: Company teams policies roadmap incidents and delivery data
-    url: local://engineering-management-context
-    tier: company-primary
-    topics: [teams, people-policies, delivery, quality, incidents]
   - name: DORA Capabilities
     url: https://dora.dev/capabilities/
     tier: primary-research

package/agents/roles/system/financial-controller/SKILL.md

@@ -10,6 +10,8 @@ Actuar como responsable de registros completos, exactos, oportunos, explicables
 ## Construir contexto
 
 1. Localizar la raíz operativa y leer `AGENTS.md`, `ops.config.json`, entidades, políticas, contratos y calendario financiero.
+   Leer también `organization/roles/financial-controller.md` si existe: son las restricciones
+   reales de esta empresa para este cargo.
 2. Identificar jurisdicciones, moneda funcional/presentación, marco contable, fiscalidad, sistemas, chart of accounts, materialidad, periodos y autoridad. No asumir IFRS, GAAP ni régimen tributario.
 3. Leer ledger, subledgers, bancos, facturación, nómina, contratos, aprobaciones, conciliaciones, presupuestos y reportes aplicables.
 4. Verificar source documents, corte, ownership, integridad de interfaces y cambios de configuración antes de concluir.

package/agents/roles/system/financial-controller/learning/sources.yaml

@@ -6,15 +6,9 @@ rules:
   reject_unsourced_claims: true
   automatic_apply: false
 
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/financial-controller.md dentro de cada instalación.
 sources:
-  - name: Company entities policies ledger contracts controls and approvals
-    url: local://financial-control-context
-    tier: company-primary
-    topics: [entities, policies, ledger, contracts, controls, approvals]
-  - name: Applicable accounting tax regulatory and audit authorities
-    url: local://finance-official-sources
-    tier: legal-primary
-    topics: [accounting, tax, regulatory, audit, effective-dates]
   - name: IFRS Accounting Standards
     url: https://www.ifrs.org/issued-standards/list-of-standards/
     tier: primary-standard

package/agents/roles/system/finops-engineer/SKILL.md

@@ -12,6 +12,8 @@ factura que baja porque el producto se usa menos no es un logro.
 ## Construir contexto antes de recomendar
 
 1. Leer `AGENTS.md`, `ops.config.json` y `organization/company.md` y `product.md`.
+   Leer también `organization/roles/finops-engineer.md` si existe: son las restricciones reales de
+   esta empresa para este cargo.
 2. Establecer la unidad de costo que le importa al negocio: por request, por usuario activo, por tarea
    procesada, por tenant. Sin unidad, el gasto sólo se puede comparar contra sí mismo.
 3. Reconstruir la atribución: qué servicio, entorno y equipo genera cada componente de la factura, y qué

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

@@ -6,15 +6,9 @@ rules:
   reject_unsourced_claims: true
   automatic_apply: false
 
+# El contexto de la empresa no es una fuente de la profesión: vive en
+# organization/roles/finops-engineer.md dentro de cada instalación.
 sources:
-  - name: Company billing tags budgets commitments and decisions
-    url: local://finops-context
-    tier: company-primary
-    topics: [billing, attribution, budgets, commitments]
-  - name: Official provider pricing and billing documentation
-    url: local://provider-pricing-docs
-    tier: platform-primary
-    topics: [pricing, regions, commitments, metering]
   - name: FinOps Foundation Framework
     url: https://www.finops.org/framework/
     tier: professional-primary

package/agents/roles/system/frontend-engineer/SKILL.md

@@ -10,6 +10,8 @@ Actuar como responsable de convertir experiencia y diseño aprobados en software
 ## Construir contexto
 
 1. Localizar la raíz operativa y leer `AGENTS.md`, `ops.config.json` y las instrucciones del servicio.
+   Leer también `organization/roles/frontend-engineer.md` si existe: son las restricciones
+   reales de esta empresa para este cargo.
 2. Identificar workspace, stack, versiones, package manager y comandos reales de test, lint, tipos y build. No asumir React, TypeScript ni otra tecnología.
 3. Leer aceptación, flujo UX, especificación UI, contratos de API y design system relevantes.
 4. Inspeccionar componentes y patrones existentes antes de crear abstracciones o dependencias.