Estructura de Repositorios GitLab

Resumen Ejecutivo

HERA implementa una taxonomía Product-Centric en GitLab diseñada para garantizar la continuidad operativa y la gobernanza a largo plazo.

• Identidad Permanente: El producto es el eje central de la jerarquía, asegurando que las URLs y la infraestructura persistan independientemente de cambios en proveedores o versiones.
• Gobernanza por Herencia: Utiliza una estructura de 5 niveles que permite propagar automáticamente políticas de seguridad, permisos y pipelines desde el nivel raíz.
• Trazabilidad Total: Vincula cada repositorio con metadatos de negocio (dominio, marca, criticidad), facilitando la gestión de activos y la atribución de costos FinOps.

La estructura de repositorios en HERA sigue una Jerarquia centrada en producto (Product-Centric Hierarchy): el producto digital es la entidad permanente, las versiones son reemplazables, y la operacion productiva no se rompe al cambiar de equipo, tecnologia o partner.

Principio Rector

El producto existe más allá de su código. Un partner puede cambiar, una versión puede reescribirse desde cero, pero la identidad del producto, su URL productiva y su infraestructura base permanecen intactas.

---

Problemas que Resuelve por Rol

HERA resuelve las preocupaciones de 5 roles con esta jerarquía:

Rol	Problema que resuelve
Arquitecto de Soluciones	Estructura predecible para microservicios, contratos entre productos y evolución tecnológica sin deuda estructural
Ingeniero DevOps	Herencia de pipelines, flujo de ambientes claro y templates CI/CD reutilizables desde un punto central
Líder de Seguridad	Control de acceso por capa, compliance heredado, clasificación de datos y secret scanning uniforme
Líder de Proyecto	Trazabilidad equipo-producto-versión, SLAs contractuales y ciclo de vida documentado
Administrador GitLab	Grupos jerárquicos con herencia de permisos, push rules y approval rules propagadas automáticamente

---

Jerarquía Completa de Grupos

HERA organiza la taxonomía en 5 niveles bajo el root group grupo-herdez/, con tres pilares de primer nivel: productos, plataforma y partners.

Jerarquía de Grupos GitLab

HERA Standard

Estructura de 5 niveles: Root → Dominio → Producto → Versión → Repos

ROOT NIVEL 1 DOMINIO PRODUCTO VERSIÓN REPO SHARED CONFIG

grupo-herdez/ ROOT GROUP
│
├── products/ NIVEL 1 — Agrupador de productos digitales
│   │
│   ├── ecommerce/ DOMINIO — Dominio de negocio
│   │   │
│   │   ├── tienda-herdez/ PRODUCTO — Identidad del producto
│   │   │   ├── v1-partner-alpha/ VERSIÓN — Built by Partner Alpha
│   │   │   │   ├── frontend REPO
│   │   │   │   ├── bff-api REPO
│   │   │   │   └── .gitlab-ci.yml CONFIG
│   │   │   │
│   │   │   ├── v2-partner-beta/ VERSIÓN — Built by Partner Beta ★ activo
│   │   │   │   ├── frontend-next REPO
│   │   │   │   ├── graphql-gateway REPO
│   │   │   │   └── checkout-service REPO
│   │   │   │
│   │   │   └── _shared/ SHARED — Recursos compartidos
│   │   │       ├── iac-infra REPO
│   │   │       └── product-manifest.yml CONFIG
│   │   │
│   │   └── marketplace-b2b/ PRODUCTO
│   │
│   ├── marketing/ DOMINIO
│   └── supply-chain/ DOMINIO
│
├── platform/ NIVEL 1 — Infraestructura transversal
│   ├── iac/ IAC CORE
│   ├── ci-cd/ PIPELINES
│   └── docs/ DOCUMENTACIÓN
│
└── partners/ NIVEL 1 — Registro de Partners
    ├── partner-alpha/ PARTNER
    └── partner-beta/ PARTNER

Mensaje clave 5 niveles: grupo-herdez → dominio → producto → versión → repositorios. El producto es la entidad permanente.

---

Producto como Entidad Primaria

El producto es la unidad fundamental de la taxonomía. No es un repositorio ni un namespace temporal — es la identidad permanente que:

• Tiene una URL productiva asignada (ej. tienda.herdez.com).
• Posee un namespace de Kubernetes fijo en cada ambiente.
• Acumula historial de versiones, decisiones arquitectónicas y documentación.
• Sobrevive a cualquier cambio de partner, tecnología o equipo.

Producto como Entidad Primaria

Product-Centric

El producto es la unidad fundamental: identidad permanente, URL fija, namespace propio. Las versiones son reemplazables.

PRODUCTO VERSION EXPERIENCE DOMAIN INTEGRATION PLATFORM SHARED CONFIG

grupo-herdez/products/ecommerce/tienda-herdez/ PRODUCTO
│
├── v1-partner-alpha/ VERSION — Primera version (archivada)
│
├── v2-partner-beta/ VERSION — Version activa ★
│   ├── frontend-web-store             EXP — Experience Layer
│   ├── bff-mobile-app                 EXP — Experience Layer
│   ├── experience-checkout-journey    EXP — Experience Layer
│   ├── backend-checkout-service       DOM — Domain Layer
│   ├── backend-inventory-service      DOM — Domain Layer
│   ├── data-catalog-search            DOM — Domain Layer
│   ├── integration-sap-orders         INT — Integration Layer
│   ├── event-consumer-orders          INT — Integration Layer
│   └── worker-loyalty-points          INT — Integration Layer
│
└── _shared/ CROSS-VERSION — Recursos que trascienden versiones
    ├── infra-terraform-modules        PLAT — Platform Layer
    ├── docs-architecture-decisions    PLAT — Platform Layer
    └── product-manifest.yml           META — Metadata del producto

URL productiva tienda.herdez.com

Namespace K8s tienda-herdez (permanente)

Version activa v2-partner-beta

Identidad Sobrevive cambios de partner y tecnologia

Mensaje clave El producto es permanente. Los partners y versiones cambian. La URL productiva nunca se rompe.

product-manifest.yml

Cada producto debe tener un archivo de manifiesto en _shared/ que declare: nombre canónico, dominio de negocio, owner (Tech Lead), URLs por ambiente, versión activa, clasificación de datos y SLAs contractuales.

---

Dominio de Negocio como Agrupador

Los productos se agrupan bajo dominios de negocio, no por tecnología ni por equipo. Esto refleja la estructura organizacional y facilita la gobernanza, el FinOps y la atribución de costos:

Dominio	Descripción	Productos ejemplo
ecommerce/	Comercio electrónico y venta digital	tienda-herdez, marketplace-b2b
marketing/	Presencia digital y campañas	sitio-corporativo, landing-campaigns
supply-chain/	Cadena de suministro y logística	portal-proveedores, tracking-app
sitios/	Sitios institucionales y de marca	sitio-barcel, sitio-donamaria
integracion/	APIs y servicios de integración	api-pagos, api-inventario
cms/	Gestores de contenido	cms-corporativo, cms-marcas
datos/	Productos de datos y analítica	datalake-ventas, bi-reportes
apps/	Aplicaciones móviles y de escritorio	app-vendedores, app-rrhh
shared-services/	Servicios compartidos cross-dominio	auth-service, notification-svc

Regla de Agrupación

Un producto siempre pertenece a un dominio de negocio. Si un nuevo producto no encaja en ningún dominio existente, se debe crear el dominio antes de crear el producto. Nunca se crean repositorios sueltos bajo products/ directamente.

---

Clasificación y Metadata de Repositorios

HERA clasifica cada repositorio con atributos obligatorios. El equipo registra esta metadata en el product-manifest.yml y el pipeline la replica como labels de GitLab en cada proyecto:

Atributos de Clasificación

Atributo	Valores permitidos	Propósito
Dominio	sitios, integracion, cms, ecommerce, datos, apps, shared-services, supply-chain, marketing	Agrupación por área de negocio
Tipo_Producto	sitio, api, cms, ecommerce, data-product, app, shared-service	Naturaleza del producto
Marca	grupo-herdez, barcel, donamaria, corporativo, interno	Marca propietaria
Partner_Equipo	interno, {nombre-partner}, partner-tecnologico	Quién construye/mantiene
Estado_Implementacion	candidate, active-dev, active-qa, active-prd, legacy, retired	Ciclo de vida actual

Atributos Técnicos

Atributo	Valores permitidos	Propósito
Repo_Tipo	frontend, backend, bff, cms, infra, helm, docs	Tipo técnico del repositorio
Criticidad	low, medium, high, critical	Nivel de impacto al negocio
Clasificacion_Datos	public, internal, confidential, restricted	Sensibilidad de datos manejados

Atributos de Infraestructura

Atributo	Valores permitidos	Propósito
Pipeline_Modelo	centralizado-hera-ci	Modelo de ejecución CI/CD
Pipeline_Template	/base/base-service.yml, /base/base-infra.yml, /base/base-docs.yml	Template CI/CD heredado
Sonar_Org	grupoherdez	Organización en SonarQube
Sonar_Project_Key	grupoherdez_<dominio>_<producto>_<implementacion>_<repo-name>	Project Key único en SonarQube — ver Convención de Project Key en SonarQube
GCP_Project_DEV	ghdz-<tenant>-<capability>-dev (ej. ghdz-grupo-ext-sites-dev)	GCP project del entorno DEV
GCP_Project_QA	ghdz-<tenant>-<capability>-qa	GCP project del entorno QA
GCP_Project_PRD	ghdz-<tenant>-<capability>-prd	GCP project del entorno PRD
Cluster_DEV	Cluster GKE dentro de GCP_Project_DEV	Cluster GKE de desarrollo
Cluster_QA	Cluster GKE dentro de GCP_Project_QA	Cluster GKE de pruebas
Cluster_PRD	Cluster GKE dentro de GCP_Project_PRD	Cluster GKE de producción

Obligatoriedad

Todo repositorio debe tener estos atributos configurados antes de su primer merge a develop. Los pipelines de HERA validan la existencia de estas labels en cada ejecución. Un repositorio sin clasificación completa no puede desplegarse.

Ejemplo de product-manifest.yml

_shared/product-manifest.yml

product:
  name: "tienda-herdez"
  domain: "ecommerce"
  brand: "grupo-herdez"
  owner:
    tech_lead: "jperez@grupoherdez.com"
    product_owner: "mgarcia@grupoherdez.com"

active_version: "v2-partner-beta"
partner: "partner-beta"
state: "active-prd"

classification:
  criticality: "critical"
  data_classification: "confidential"
  product_type: "ecommerce"

urls:
  dev: "tienda.dev.hera.cloudherdez.com"
  qa: "tienda.qa.hera.cloudherdez.com"
  prd: "tienda.herdez.com"

infrastructure:
  pipeline_template: "/base/base-service.yml"
  pipeline_model: "centralizado-hera-ci"
  sonar_org: "grupoherdez"
  # GCP projects por entorno
  gcp_project_dev: "ghdz-grupo-ext-sites-dev"
  gcp_project_qa:  "ghdz-grupo-ext-sites-qa"
  gcp_project_prd: "ghdz-grupo-ext-sites-prd"
  # Clusters GKE (según estándar gke-<capability>-<env>)
  cluster_dev: "gke-apps-dev"
  cluster_qa:  "gke-apps-qa"
  cluster_prd: "gke-apps-prd-01"
  # GCP Service Account (GSA) para Workload Identity
  gsa_name: "gsa-tienda-herdez-backend-checkout"
  # K8s namespace — invariante entre entornos, versiones y partners
  namespace: "tienda-herdez"

sla:
  response_time: "4h"
  resolution_time: "24h"
  availability: "99.9%"

---

Convención de Project Key en SonarQube

Cada servicio tiene un Project Key único en SonarQube que se deriva de los atributos del repositorio declarados arriba (Sonar_Org, dominio, producto, implementación y nombre del repo). Este Project Key es el identificador con el que el pipeline sube resultados de análisis y con el que se aplican los Quality Gates.

Formato

grupoherdez_<dominio>_<producto>_<implementacion>_<repo-name>

Componente	Descripción	Ejemplo
grupoherdez	Prefijo fijo del ecosistema (coincide con Sonar_Org)	grupoherdez
<dominio>	Dominio de negocio (ecommerce, marketing, supply-chain)	ecommerce
<producto>	Producto digital	tienda-herdez
<implementacion>	Versión + partner que la construye (subgrupo de GitLab)	v2-partner-beta
<repo-name>	Nombre del repo con su prefijo de tipo	backend-checkout-service

Ejemplos completos

grupoherdez_ecommerce_tienda-herdez_v2-partner-beta_backend-checkout-service
grupoherdez_ecommerce_tienda-herdez_v2-partner-beta_bff-mobile-app
grupoherdez_ecommerce_tienda-herdez_v2-partner-beta_frontend-web-store
grupoherdez_marketing_corporate-site_v1-internal-team_cms-corporate-site
grupoherdez_supply-chain_supplier-portal_v1-partner-alpha_integration-sap-orders

Beneficios de esta convención

• Filtrado por dimensión — encuentra todos los backend services del dominio ecommerce.
• Quality gates por tipo — define umbrales distintos para frontend vs. backend.
• FinOps por dominio — agrega costos de calidad por área de negocio.
• Auditoría multi-nivel — trazabilidad completa producto → versión → tipo → repo.

---

Versionamiento Explícito

Cada versión de un producto se representa como un subgrupo con la convención v{N}-{partner}:

Reglas de Versionamiento

1. Solo una versión activa a la vez por producto en producción.
2. Las versiones anteriores se archivan en GitLab (read-only) una vez completada la migración.
3. El nombre incluye el partner para trazabilidad contractual y auditoría.
4. La versión activa se declara en product-manifest.yml, no por convención de nombres.
5. El estado de implementación (candidate → active-dev → active-qa → active-prd → legacy → retired) se actualiza en el manifiesto conforme avanza el ciclo.

Ciclo de vida de una versión

Estado	Significado	Acciones permitidas
candidate	Versión propuesta, aún no iniciada	Creación de subgrupo y repos vacíos
active-dev	En desarrollo activo	Push, MR, CI a DEV
active-qa	En pruebas de calidad	CI a QA, no se aceptan features nuevas
active-prd	Versión en producción	CD a PRD con aprobación, solo hotfixes
legacy	Versión anterior, archivada	Read-only, consulta de código
retired	Dada de baja permanentemente	Archivado completo

Anti-patrón

Nunca mover repositorios entre subgrupos de versión. Si la v2 necesita código de v1, se hace fork o se copia — el historial de v1 debe permanecer inmutable como registro de auditoría.

---

Namespace = Identidad de Despliegue

El namespace de Kubernetes se deriva directamente de la identidad del producto, no de la versión:

Concepto	Valor	Permanencia
Namespace Kubernetes	tienda-herdez	Permanente
URL productiva	tienda.herdez.com	Permanente
Versión activa	v2-partner-beta	Cambia con cada rebuild
Branch de despliegue	main (del repo activo)	Por versión

Esto garantiza que cuando se migra de v1 a v2, la URL no cambia, el namespace no cambia, y los certificados TLS, DNS y balanceadores permanecen intactos.

---

Resolución del Flujo de Ambientes (DEV/QA vs PRD)

El flujo de ambientes se resuelve a nivel de rama + pipeline, no a nivel de grupo GitLab:

# Branch: develop  → Despliega a DEV y QA (automático)
# Branch: main     → Despliega a PRD (requiere aprobación)
#
# El namespace de K8s es el mismo en los 3 ambientes:
#   DEV: tienda-herdez (en GCP project ghdz-grupo-ext-sites-dev)
#   QA:  tienda-herdez (en GCP project ghdz-grupo-ext-sites-qa)
#   PRD: tienda-herdez (en GCP project ghdz-grupo-ext-sites-prd)

Ambiente	Trigger	GCP Project	Aprobación
DEV	Merge a develop	ghdz-<tenant>-<capability>-dev	Automático
QA	Merge a develop	ghdz-<tenant>-<capability>-qa	Automático
PRD	Merge a main	ghdz-<tenant>-<capability>-prd	Tech Lead + QA Lead + PO

Separación de Concerns

La infraestructura del producto (Terraform, secrets, networking) vive en _shared/iac-infra y se despliega independientemente del código aplicativo. Esto permite que la infra persista entre versiones.

---

Shared Resources Centralizados

A nivel de producto: _shared/

El subgrupo _shared/ dentro de cada producto contiene los recursos que trascienden versiones:

Recurso	Propósito	Persiste entre versiones
iac-infra	Terraform: namespace, secrets, ingress, DB	Si
docs	ADRs, runbooks, diagramas, post-mortems	Si
product-manifest.yml	Metadata completa del producto	Si

A nivel organizacional: platform/

El grupo platform/ contiene recursos transversales a todos los productos:

Subgrupo	Contenido	Consumidores
iac/	Módulos Terraform reutilizables, políticas GCP, configuraciones base Kubernetes	Todos los _shared/iac-infra
ci-cd/	Templates de pipelines, configuración de runners, scanners de seguridad	Todos los repositorios
observability/	Dashboards de Grafana/Datadog, reglas de alerting	SRE y Tech Leads
docs/	HERA Handbook, guías de onboarding	Toda la organización

---

Tipos de Servicio: Naming, Pipeline y Repo

HERA define 13 categorías oficiales de servicios agrupadas en 4 capas estratégicas. Esta tabla cubre los aspectos operativos (cómo nombrar el repo, qué pipeline usar). Para entender qué es cada categoría conceptualmente, cuándo usarla, ejemplos y beneficios, consulta la página dedicada:

➡️ Clasificación de Servicios — Referencia oficial

Convención de naming

<tipo>-<detalle>

No repetir el producto en el nombre del repo — la jerarquía del grupo GitLab ya lo provee.

Tabla de tipos por capa

Capa	Categoría	Convención de nombre	Pipeline template	Ejemplo
Experience	frontend	frontend-{detalle}	/base/base-service.yml	frontend-web-store
Experience	bff	bff-{canal}	/base/base-service.yml	bff-mobile-app
Experience	experience	experience-{journey}	/base/base-service.yml	experience-checkout-journey
Domain	backend	backend-{dominio}-service	/base/base-service.yml	backend-checkout-service
Domain	data	data-{dominio}-{función}	/base/base-service.yml	data-catalog-search
Domain	cms	cms-{tipo-contenido}	/base/base-service.yml	cms-marketing-content
Integration	integration	integration-{sistema}-{función}	/base/base-service.yml	integration-sap-orders
Integration	event	event-{rol}-{dominio}	/base/base-service.yml	event-consumer-orders
Integration	worker	worker-{función}	/base/base-service.yml	worker-loyalty-points
Platform	platform	platform-{capacidad}	/base/base-service.yml	platform-auth-service
Platform	edge	edge-{tecnología}-{función}	/base/base-edge.yml	edge-apigee-config
Platform	infra	infra-{tecnología}-{scope}	/base/base-infra.yml	infra-terraform-modules
Platform	docs	docs-{contenido}	/base/base-docs.yml	docs-architecture-decisions

Asignar categoría es obligatorio

No se crean repos sin categoría asignada. El campo service_type debe estar presente en el service-manifest.yml y debe ser uno de los 13 valores oficiales. Esto habilita: pipeline correcto, observabilidad por tipo, búsqueda en GitLab, y SLOs adecuados.

Naming sin redundancia

La jerarquía del grupo GitLab ya provee el contexto del producto. El repo no debe repetirlo:

• ✅ Correcto: grupo-herdez/products/ecommerce/tienda-herdez/v2-partner-beta/backend-checkout-service
• ❌ Incorrecto: grupo-herdez/products/ecommerce/tienda-herdez/v2-partner-beta/backend-tienda-checkout-service

Ver detalles en Convención de Naming.

Regla de Nomenclatura

Los nombres de repositorio siguen el formato <tipo>-<detalle> en kebab-case, sin repetir el producto (que ya está en la jerarquía del grupo). Ver detalles completos en Convención de Naming.

Servicios con base de datos — directorio `db/migrations/`

Todo servicio que sea dueño de una base de datos (típicamente las categorías backend, platform, worker, integration) debe incluir un directorio db/migrations/ en la raíz del repo con los archivos de schema migrations versionados.

backend-checkout-service/
├── src/
├── db/
│   ├── migrations/     # Schema migrations versionadas (obligatorio si el servicio tiene BD)
│   └── seeds/          # Datos de referencia no sensibles (opcional)
├── Dockerfile
└── service-manifest.yml

El pipeline aplica estas migrations vía el job db-migrate en el stage pre-deploy antes de actualizar la app. Las herramientas aprobadas por stack (Flyway, Alembic, node-pg-migrate, golang-migrate, EF Core, Doctrine) y las reglas duras (no SQL ad-hoc, no DROP sin aprobación DBA, no ORM auto-migration en PRD) están documentadas en Cloud SQL — Database as Code.

---

Control de Acceso por Nivel Jerárquico

Los permisos en GitLab se configuran por nivel de grupo y se heredan hacia abajo. Esta estrategia garantiza el principio de mínimo privilegio:

Nivel	Rol GitLab	Quién	Permisos clave
grupo-herdez/ (Root)	Owner	Administradores HERA	Configuración global, compliance, push rules
products/{dominio}/	Maintainer	Tech Lead del dominio	Gestión de productos del dominio, approval rules
{producto}/	Maintainer	Tech Lead del producto	Gestión de versiones, _shared/
{producto}/{version}/	Developer	Equipo de Desarrollo	Push a feature branches, crear MR
platform/	Maintainer	Equipo de plataforma HERA	IaC, templates CI/CD, observabilidad
partners/	Reporter	Partners de Desarrollo (solo lectura de su perfil)	Consulta de metadata y estándares

Herencia de Permisos

Los permisos se heredan de grupo padre a hijo. Un Developer a nivel de versión no puede modificar _shared/ ni la configuración del producto. Solo los Maintainers del producto tienen acceso a los recursos cross-versión.

---

Gobierno Operacional: El Compliance Framework

Cada producto hereda automáticamente las políticas de gobernanza HERA a través del Compliance Framework de GitLab:

Control	Implementación	Nivel de aplicación
Pipeline obligatorio	Template CI/CD vía include desde platform/ci-cd/	Producto
Branch protection	main protegida, merge solo vía MR aprobado	Repositorio
Approval rules	Mínimo 1 Tech Lead + 1 QA para merge a main	Repositorio
Secret scanning	Habilitado globalmente, bloquea push con secretos	Grupo root
SAST / SCA	Ejecutado en cada pipeline, Quality Gate obligatorio	Pipeline
Container scanning	Análisis de vulnerabilidades en imágenes Docker	Pipeline
Tagging obligatorio	Labels: domain, product_type, brand, criticality, data_classification	Proyecto
Push rules	Prohibido push a main y develop directamente	Grupo root
Clasificación de datos	Validada contra product-manifest.yml en cada despliegue	Pipeline

Herencia de Políticas

Las políticas se configuran a nivel del grupo grupo-herdez/ y se heredan automáticamente a todos los subgrupos y proyectos. Un equipo de producto no puede desactivar los controles de seguridad ni las reglas de aprobación.

---

Estrategia de Mantenibilidad: El Update Cycle

Cuando un partner entrega una nueva versión

1. Se crea el subgrupo vN-partner-nuevo/ con estado candidate.
2. El equipo desarrolla y el estado avanza: active-dev → active-qa → active-prd.
3. Se actualiza _shared/product-manifest.yml con la nueva versión activa.
4. Se ejecuta el pipeline de _shared/iac-infra para apuntar la infraestructura a los nuevos artefactos.
5. La versión anterior cambia a estado legacy y se archiva (read-only en GitLab).
6. El namespace, URL e ingress permanecen sin cambios.

Cuando un producto se da de baja

1. Se archivan todos los subgrupos de versión (estado retired).
2. Se ejecuta terraform destroy desde _shared/iac-infra para limpiar recursos cloud.
3. La documentación relevante se preserva en _shared/docs como registro histórico.
4. El grupo del producto permanece como archivo (nunca se elimina).

Principio de Inmutabilidad

En HERA, nada se elimina — se archiva. Esto garantiza trazabilidad completa para auditorías, cumplimiento regulatorio y resolución de disputas contractuales con partners.

---

Registro de Partners de Desarrollo

El grupo partners/ mantiene un directorio centralizado de todos los partners de desarrollo y equipos que participan en el ecosistema HERA:

partners/partner-beta/partner-profile.yml

name: "Partner Beta"
type: "external"
contact:
  tech_lead: "lead@partner-beta.com"
  account_manager: "cuenta@partner-beta.com"
  escalation: "cto@partner-beta.com"
contract:
  start_date: "2024-06-01"
  sla_response: "4h"
  sla_resolution: "24h"
  review_cycle: "trimestral"
products_assigned:
  - product: "grupo-herdez/products/ecommerce/tienda-herdez"
    version: "v2-partner-beta"
    state: "active-prd"
  - product: "grupo-herdez/products/supply-chain/portal-proveedores"
    version: "v1-partner-beta"
    state: "active-qa"
standards:
  coding_standards_repo: "partners/partner-beta/coding-standards"
  approved_languages: ["typescript", "python", "go"]
  approved_frameworks: ["next.js", "fastapi", "gin"]

---

Ventajas de Este Modelo bajo HERA

Dimensión	Beneficio
Continuidad operativa	Cambiar de partner no rompe URLs, namespaces ni infraestructura
Trazabilidad	Cada línea de código tiene contexto: producto, versión, partner, dominio y marca
Gobernanza	Políticas heredadas automáticamente — compliance by design
FinOps	Costos atribuibles por producto, dominio, marca y versión mediante labels de GCP
Seguridad	Clasificación de datos, secret scanning y SAST aplicados uniformemente
Escalabilidad	Agregar un nuevo producto o dominio es crear un subgrupo — sin reconfiguración
Auditoría	Historial inmutable: versiones archivadas, nunca eliminadas
Onboarding	Estructura predecible: cualquier ingeniero sabe dónde encontrar cualquier cosa
Multi-marca	Un mismo dominio puede contener productos de distintas marcas del grupo
Control de acceso	Permisos heredados por nivel jerárquico con principio de mínimo privilegio