Nombres, etiquetas y nombres de host

Airframe deriva casi cada nombre del lugar de un producto en el catálogo, así que un nombre dice a qué pertenece una cosa sin tener que buscarlo. Esta página enumera las formas que usa la plataforma para proyectos, identidades, estado, repositorios y grupos, las etiquetas que lleva cada recurso, y el nombre de host que recibe un producto en cada entorno, con los pocos nombres de host que son públicos.

Cómo leer las tablas

Un producto se identifica por su ruta, <journey>/<domain>/<context>/<product>. Un nombre es único solo entre sus hermanos, así que un nombre que vive en un espacio más amplio que los propios proyectos del producto lleva los niveles que tiene por encima. Dentro de los proyectos de un producto basta con el nombre del producto, porque el proyecto es el espacio de nombres.

<rnd> son cuatro letras minúsculas y dígitos, sorteados una vez al crear un proyecto o un bucket y nunca elegidos a mano. <iid> es el número de un merge request. Los ejemplos vienen de una organización de demostración, una tienda en línea ficticia cuyo código es lk.

Las tablas describen la plataforma en la versión de la plataforma 2026.10.01-1, tal como están el 2026-10-01 los contratos y el código que crea cada nombre. Donde difieren, la tabla sigue al código. Una fila marcada como diseñado es una forma que los contratos especifican y que nada crea todavía.

Nombres

Proyectos de producto

Forma: lk-<domain>-<product>-<rnd> y lk-<domain>-<product>-np-<rnd>
Ejemplo: lk-billing-invoicing-np-7q2m
Significado: Los proyectos de producción y de no producción de un producto, creados por la fábrica de proyectos de su dominio. El recorrido no está en el identificador; las etiquetas dicen de qué recorrido es. El paquete de políticas rechaza un identificador de proyecto con cualquier otra forma.
Fuente: landing-zone roots/project-factory/; control-plane policy/airframe/naming.rego

Proyectos de la plataforma

Forma: lk-<service>-<rnd>, o lk-<service>-np-<rnd>
Ejemplo: lk-runtime-np-k3d8
Significado: Los proyectos propios de la plataforma, uno por servicio: network, runtime, observability, ci, catalog, audit, pact, eventcatalog, website o analytics. Los sufijos de la fábrica de la plataforma están registrados en catalog.yaml.
Fuente: landing-zone docs/contracts.md 2, roots/project-factory/platform/; control-plane policy/airframe/naming.rego

Playgroundsdiseñado

Forma: Proyecto lk-play-<name>-<rnd>; repositorio projectairframe/playground/<name>
Ejemplo: lk-play-router-experiment-x1c4
Significado: Un experimento breve de un equipo, con presupuesto y fecha de vencimiento. El esquema del catálogo describe los playgrounds, pero ninguna raíz los crea todavía.
Fuente: landing-zone docs/contracts.md 2; catalog schema/playground.schema.json

Identidades de plan y de apply

Forma: <product>-plan@ en cada proyecto del producto; <product>-apply@ en producción y <product>-np-apply@ en no producción
Ejemplo: invoicing-apply@lk-billing-invoicing-7q2m.iam
Significado: Las identidades con las que se ejecuta el Terraform de un producto. La identidad de plan lee; la de apply cambia el proyecto. El ejecutor puede actuar como cada identidad de plan y cada identidad de apply de no producción, y como ninguna de producción. El proyecto es el espacio de nombres, así que basta con el nombre del producto.
Fuente: landing-zone roots/project-factory/

Identidades de ejecución

Forma: <product>-<name>@ en el proyecto del entorno, con -sandbox o -eph-<iid> agregado en un sandbox o una vista previa
Ejemplo: invoicing-api@
Significado: Una identidad por servicio en ejecución, con el nombre de la llamada al módulo, que tiene exactamente lo que usa ese servicio.
Fuente: golden-path modules/cloud-run-service/main.tf

Identidades de las raíces de la plataforma

Forma: platform-<root>@ en el proyecto de ejecución de la plataforma; la fábrica de proyectos de un dominio es factory-<journey>-<domain>@
Ejemplo: platform-catalog@
Significado: Una identidad por raíz de la plataforma, que solo puede obtener un job del main protegido de su repositorio, en el entorno platform/<root>.
Fuente: landing-zone roots/wif/main.tf

Buckets de estado

Forma: lk-tfstate-platform-<rnd> y lk-tfstate-prod-<rnd> en el proyecto de ejecución; lk-tfstate-np-<rnd> en el proyecto de ejecución de no producción
Ejemplo: lk-tfstate-platform-ivww
Significado: Donde Terraform guarda el estado: el de las raíces de la plataforma, el de producción y el de no producción, cada bucket cifrado con una clave que tiene la plataforma.
Fuente: landing-zone roots/state/main.tf

Prefijos de estado de un producto

Forma: <journey>/<domain>/<context>/<product>/ seguido de prod, grafana, np, sandbox o eph/<iid>
Ejemplo: settle/billing/invoicing/invoicing/eph/42
Significado: Donde cada raíz de un producto guarda su estado: prod y grafana en el bucket de producción, el resto en el de no producción. Cada identidad de apply puede escribir los prefijos de su propio producto y ningún otro.
Fuente: landing-zone roots/project-factory/; golden-path template/.gitlab-ci.yml.jinja

Prefijos de estado de la plataforma

Forma: platform/<repository>/<root>
Ejemplo: platform/landing-zone/network
Significado: El estado de cada raíz de la plataforma, en el bucket de la plataforma. La identidad de cada raíz lee y escribe su propio prefijo.
Fuente: landing-zone roots/wif/grants.tf

Repositorios de producto

Forma: projectairframe/<journey>/<domain>/<context>/<product>; en el grupo restringido de un dominio, projectairframe/<journey>/<domain>/<context>/restricted/<product>
Ejemplo: projectairframe/shop/store/ordering/orders
Significado: Los crea la raíz de GitLab del dominio, como la cuenta de fábrica del dominio. La ruta de un producto eliminado no se reutiliza nunca.
Fuente: control-plane modules/product-repositories/main.tf; landing-zone roots/project-factory/

Repositorios de un producto repartido en variosdiseñado

Forma: projectairframe/<journey>/<domain>/<context>/<product>/<repo>
Ejemplo: projectairframe/fulfil/shipping/tracking/tracking/api
Significado: Un repositorio por aplicación, bajo el grupo propio del producto, cada uno con su estado, sus imágenes y su nombre de host de vista previa.
Fuente: landing-zone docs/contracts.md 2, docs/adr/0017-multi-repository-products-and-adoption-by-moving-the-group.md

Grupo de usuarios

Forma: lk-<journey>-<domain>-<context>-<product>-users@projectairframe.dev
Ejemplo: lk-shop-store-ordering-orders-users@
Significado: Las personas que pueden llegar al producto detrás del inicio de sesión único: hoy los miembros activos de su equipo.
Fuente: landing-zone roots/groups/main.tf

Grupo del equipo

Forma: lk-team-<team>@projectairframe.dev
Ejemplo: lk-team-store-core@
Significado: Los miembros activos de un equipo, con acceso de lectura a los proyectos de los productos del equipo.
Fuente: landing-zone roots/groups/main.tf, roots/project-factory/

Grupos de líderes

Forma: lk-journey-<journey>-leads@, lk-<journey>-<domain>-leads@ y lk-<journey>-<domain>-<context>-leads@, en projectairframe.dev
Ejemplo: lk-shop-store-leads@
Significado: Los líderes de cada nivel de la jerarquía, tal como los nombra el catálogo.
Fuente: landing-zone roots/groups/main.tf

Grupos de la plataforma

Forma: lk-platform@ y lk-breakglass@, en projectairframe.dev
Ejemplo: lk-platform@
Significado: El equipo de plataforma, cuyos miembros aprueban cada concesión administrativa, y el grupo de break-glass, cuyos miembros pueden solicitar la mayoría de las concesiones cuando el camino normal no funciona.
Fuente: landing-zone roots/pam/main.tf

Secretos

Forma: El nombre que le da el archivo de secretos del producto, en el proyecto del entorno
Ejemplo: secret-key
Significado: El repositorio de un producto enumera sus secretos por nombre en su archivo de secretos, nunca con un valor. El módulo de secretos del golden path crea cada uno, y un mantenedor agrega el valor en Secret Manager.
Fuente: golden-path modules/secrets/main.tf

Tópicos y suscripciones de Pub/Subdiseñado

Forma: Tópico <domain>.<product>.<noun>.<verb-past> en el proyecto del publicador; suscripción <consumer-product>-<name> en el del consumidor
Ejemplo: store.orders.order.placed
Significado: Ningún módulo los crea todavía. Los campos topics y consumes del catálogo ya usan los nombres de los eventos.
Fuente: landing-zone docs/contracts.md 2; golden-path modules/

Las raíces de Terraform de un producto

Forma: infra/prod, infra/np, infra/sandbox, infra/eph e infra/grafana
Ejemplo: infra/eph
Significado: Producción; no producción; el sandbox; una vista previa, que aplica el ejecutor; y los tableros propios del producto, aplicados con la identidad de apply de producción en el entorno grafana.
Fuente: golden-path template/infra/, template/.gitlab-ci.yml.jinja

Entornos de GitLab

Forma: prod, np y grafana en un repositorio de producto; platform/<root> en un repositorio de la plataforma; platform/audit, el del informe de deriva, en ambos; executor en control-plane
Ejemplo: platform/network
Significado: El entorno es uno de los datos que comprueba la federación de identidades de carga de trabajo, así que un job obtiene una identidad solo en su propio entorno. Un job propio de un producto no puede declarar ninguno.
Fuente: golden-path template/.gitlab-ci.yml.jinja; control-plane .gitlab-ci.yml, templates/drift-report/template.yml, policy/airframe/pipeline.rego

Nombres de llamadas a módulos

Forma: Un slug de 2 a 14 caracteres
Ejemplo: api, worker-mail
Significado: El name de una llamada a un módulo del golden path. El módulo deriva de él los nombres de sus recursos, como el servicio de Cloud Run <product>-<name>, y rechaza un nombre con cualquier otra forma.
Fuente: golden-path modules/cloud-run-service/variables.tf, modules/cloud-sql/variables.tf

Recursos sueltos en una raíz de producto

Forma: <product>-<name>, con -<rnd> agregado para un nombre que Google mantiene global
Ejemplo: orders-exports-k3d8
Significado: Un recurso que un producto declara por sí mismo, fuera de los módulos del golden path. El paquete de políticas advierte sobre cada recurso así, y también cuando su nombre no empieza con el del producto.
Fuente: control-plane policy/airframe/naming.rego

Grafana

Forma: Una carpeta por cada nivel de la ruta del producto; los tableros <product> service, <product> SLO y <product> cost en la carpeta del producto; un punto de contacto por equipo
Ejemplo: orders service
Significado: Los crea la raíz de Grafana de operations a partir del catálogo.
Fuente: operations roots/grafana/main.tf, roots/grafana/pack.tf

Etiquetas de Google Cloud

Cada proyecto y cada recurso llevan etiquetas que dicen a qué pertenecen: la fábrica de proyectos las pone en los proyectos y los módulos del golden path en los recursos. El paquete de políticas rechaza un recurso que declara etiquetas pero no tiene alguna de estas seis: managed_by, tenant, domain, product, env y criticality (aplicado, en el código y en el plan). Un recurso que no declara ninguna etiqueta pasa esa regla.

`managed_by`

Valores: airframe
Significado: La plataforma gestiona el recurso. La exige el paquete de políticas.
Fuente: landing-zone docs/contracts.md 7; control-plane policy/airframe/naming.rego

`tenant`

Valores: lk
Significado: El código de la organización. La exige el paquete de políticas.
Fuente: landing-zone docs/contracts.md 7; control-plane policy/airframe/naming.rego

`journey`

Valores: El slug de un recorrido, o platform
Significado: El recorrido del producto, en sus proyectos y en los recursos cuyo módulo conoce la ruta del producto.
Fuente: landing-zone roots/project-factory/; golden-path modules/airframe-context/main.tf

`domain`

Valores: El slug de un dominio, o platform
Significado: El dominio del producto. La exige el paquete de políticas.
Fuente: golden-path modules/airframe-context/main.tf; control-plane policy/airframe/naming.rego

`context`

Valores: El slug de un contexto, o platform
Significado: El contexto del producto, puesto como journey.
Fuente: landing-zone roots/project-factory/; golden-path modules/airframe-context/main.tf

`product`

Valores: El slug de un producto, o platform
Significado: El producto. La exige el paquete de políticas, que también la lee para juzgar el nombre de un recurso suelto.
Fuente: golden-path modules/airframe-context/main.tf; control-plane policy/airframe/naming.rego

`component`

Valores: El slug de un componente, o main
Significado: La parte del producto a la que pertenece el recurso.
Fuente: golden-path modules/airframe-context/main.tf

`team`

Valores: El slug de un equipo
Significado: El equipo que gestiona el producto.
Fuente: landing-zone roots/project-factory/; golden-path modules/airframe-context/main.tf

`env`

Valores: prod, np, sandbox, eph-<iid>, platform o play
Significado: El entorno. La exige el paquete de políticas, y la leen las reglas del paquete sobre vistas previas.
Fuente: golden-path modules/airframe-context/main.tf; control-plane policy/airframe/naming.rego, cloud_run.rego

`criticality`

Valores: 1, 2, 3, o platform
Significado: La criticidad del producto. La exige el paquete de políticas.
Fuente: landing-zone roots/project-factory/; control-plane policy/airframe/naming.rego

`data_classification`

Valores: public, internal, confidential o restricted
Significado: Qué tan sensibles son los datos del producto, en los recursos que crean sus módulos.
Fuente: golden-path modules/airframe-context/main.tf

`root`

Valores: El prefijo de estado con cada / cambiado por -
Significado: Qué raíz de Terraform gestiona el recurso.
Fuente: golden-path modules/airframe-context/main.tf

`module`

Valores: El nombre del módulo y su versión mayor
Significado: Qué módulo del golden path creó el recurso, como cloud-run-service-0.
Fuente: golden-path modules/cloud-run-service/main.tf, modules/secrets/main.tf

`expires`

Valores: Una fecha
Significado: En los servicios de una vista previa: el fin de su tiempo de vida, que lee el recolector.
Fuente: golden-path modules/cloud-run-service/main.tf

Etiquetas de GitLab

La raíz de GitLab crea estas etiquetas en el grupo principal, así que cada repositorio las tiene, salvo lifecycle, que un merge request del catálogo lleva por su nombre. La mayoría las ponen personas; la tabla dice dónde algo pone o lee una.

`agent`

En: Merge requests
Significado: Escrito por un agente de código, cuyos commits también llevan un trailer Generated-by. Lo pone el autor; nada lo comprueba.
Fuente: control-plane roots/gitlab/locals.tf; landing-zone docs/contracts.md 7

`lifecycle`

En: Merge requests del catálogo
Significado: Un cambio del estado de ciclo de vida de un producto. La compuerta de aprobación se niega a juzgar un cambio así sin ella, y el job de ciclo de vida del catálogo la exige.
Fuente: control-plane gate/src/core/ownership.ts; catalog .gitlab-ci.yml, scripts/lifecycle-check.mjs

`warn`diseñado

En: Merge requests
Significado: Un hallazgo de nivel de advertencia que necesita la aprobación de la plataforma. La etiqueta existe; nada la pone, y una advertencia no detiene nada.
Fuente: control-plane roots/gitlab/locals.tf, templates/validate/template.yml

`exception::open`, `exception::accepted`, `exception::expired`diseñado

En: Merge requests e issues
Significado: Los estados del registro de excepciones. Las etiquetas existen; el registro no está construido.
Fuente: control-plane roots/gitlab/locals.tf; landing-zone docs/contracts.md 7

`preview::custom`diseñado

En: Merge requests
Significado: Un producto con su propio componente de vista previa. Nada la usa, como nada lee el campo preview del catálogo.
Fuente: control-plane roots/gitlab/locals.tf

`console-gap`

En: Issues
Significado: Alguien necesitó la consola o una concesión: la señal de que falta un reconciliador. Se pone a mano.
Fuente: control-plane roots/gitlab/locals.tf; landing-zone docs/contracts.md 7

`audit::drift`

En: Issues
Significado: Una raíz cuya infraestructura difiere de su código. El informe de deriva abre, reescribe y cierra estos issues en el pipeline programado de cada repositorio.
Fuente: control-plane templates/drift-report/template.yml

`audit::orphan`, `audit::duplication`, `audit::misconfiguration`, `audit::cost`, `audit::keep`diseñado

En: Issues
Significado: Los hallazgos del agente de auditoría y lo que se decidió sobre ellos. Las etiquetas existen; el agente de auditoría no está construido.
Fuente: control-plane roots/gitlab/locals.tf; landing-zone docs/contracts.md 7

`violation::perimeter`diseñado

En: Issues
Significado: Una infracción de VPC Service Controls, con la regla que la permitiría. La etiqueta existe; nada abre estos issues, y los perímetros funcionan en modo de prueba.
Fuente: control-plane roots/gitlab/locals.tf; landing-zone roots/perimeters/

`postmortem`, `ops`, `adr`

En: Issues y merge requests
Significado: Trabajo de postmortem; un pedido de un job operativo; un merge request que agrega o reemplaza un registro de decisión. Se ponen a mano.
Fuente: control-plane roots/gitlab/locals.tf; landing-zone docs/contracts.md 7

Nombres de host

Cada recorrido tiene su propia zona DNS, <journey>.projectairframe.dev, y el dominio es una etiqueta dentro de ella. Los workers y los servicios internos no tienen nombre de host. Cada nombre de host está detrás del inicio de sesión único, mediante Identity-Aware Proxy, el de un producto para su grupo de usuarios, con tres excepciones: una ruta que un producto declara pública, que está diseñada; la compuerta de aprobación; y este sitio web. Grafana está en la dirección propia del proveedor.

Producción, la aplicación principal

Nombre de host: <product>.<domain>.<journey>.projectairframe.dev
Rutas: / y /api
Etiqueta de entorno: prod
Acceso: Inicio de sesión único.
Fuente: landing-zone docs/contracts.md 8, roots/network/modules/publications/main.tf; golden-path template/infra/prod/main.tf.jinja

Producción, otra aplicación

Nombre de host: <product>-<app>.<domain>.<journey>.projectairframe.dev
Rutas: /
Etiqueta de entorno: prod
Acceso: Inicio de sesión único. La raíz de red acepta la forma; el template no genera una segunda aplicación.
Fuente: landing-zone roots/network/modules/publications/main.tf

No producción

Nombre de host: <product>-np.<domain>.<journey>.projectairframe.dev
Rutas: / y /api
Etiqueta de entorno: np
Acceso: Inicio de sesión único.
Fuente: golden-path template/infra/np/main.tf.jinja; landing-zone roots/network/modules/publications/main.tf

Sandbox

Nombre de host: <product>-sandbox.<domain>.<journey>.projectairframe.dev, o <product>-<app>-sandbox para otra aplicación
Rutas: / y /api
Etiqueta de entorno: sandbox
Acceso: Inicio de sesión único.
Fuente: golden-path template/infra/sandbox/main.tf.jinja; landing-zone roots/network/modules/publications/main.tf

Vista previa del merge request `<iid>`

Nombre de host: <product>-eph-<iid>.<domain>.<journey>.projectairframe.dev
Rutas: Como en producción
Etiqueta de entorno: eph-<iid>
Acceso: Inicio de sesión único, a través del enrutador de vistas previas del producto, que lee el número del merge request en el nombre de host. El certificado y el registro comodín del dominio cubren cada vista previa.
Fuente: golden-path modules/preview-substrate/main.tf, template/infra/eph/main.tf.jinja; landing-zone docs/contracts.md 8

Vista previa de un repositorio de un producto repartido en variosdiseñado

Nombre de host: <product>-<repo>-eph-<iid>.<domain>.<journey>.projectairframe.dev
Rutas: /
Etiqueta de entorno: eph-<iid>
Acceso: Inicio de sesión único.
Fuente: landing-zone docs/contracts.md 8, docs/adr/0017-multi-repository-products-and-adoption-by-moving-the-group.md

Alias de un producto adoptadodiseñado

Nombre de host: Cada nombre de host de hostnames en la entrada
Rutas: Como la ruta propia del producto
Etiqueta de entorno: prod
Acceso: Como la ruta propia del producto. El catálogo todavía no acepta el campo.
Fuente: landing-zone docs/contracts.md 8; catalog schema/product.schema.json

Una ruta de producto declarada públicadiseñado

Nombre de host: Uno de los nombres de host del producto
Rutas: La ruta de la ruta declarada
Etiqueta de entorno: prod
Acceso: Pública, sin inicio de sesión único, para una ruta llamada public en un producto cuya entrada dice external_ingress: true. La pieza para eso no está construida: hoy cada backend de producto tiene inicio de sesión único, y el paquete de políticas rechaza uno sin él.
Fuente: landing-zone docs/contracts.md 8; golden-path modules/cloud-run-service/main.tf; control-plane policy/airframe/cloud_run.rego

Playgrounddiseñado

Nombre de host: play-<name>.projectairframe.dev
Rutas: /
Etiqueta de entorno: play
Acceso: Inicio de sesión único.
Fuente: landing-zone docs/contracts.md 8

El catálogo de arquitectura

Nombre de host: catalog.projectairframe.dev
Rutas: /
Etiqueta de entorno: platform
Acceso: Inicio de sesión único, para todas las personas de la organización.
Fuente: landing-zone docs/contracts.md 8; operations roots/eventcatalog/edge.tf

La compuerta de aprobación

Nombre de host: gate.projectairframe.dev
Rutas: /
Etiqueta de entorno: platform
Acceso: Pública. La compuerta comprueba ella misma el token de cada llamador, y el paquete de políticas la incluye como un servicio que lo hace.
Fuente: landing-zone docs/contracts.md 8; control-plane policy/airframe/data.json, policy/airframe/cloud_run.rego

Este sitio web

Nombre de host: www.projectairframe.dev; projectairframe.dev redirige a él
Rutas: /
Etiqueta de entorno: platform
Acceso: Público. Es el único servicio que el paquete de políticas incluye como servicio público del borde.
Fuente: landing-zone docs/contracts.md 8, roots/network/edge.tf; control-plane policy/airframe/data.json

Otros servicios de la plataformadiseñado

Nombre de host: pact.projectairframe.dev, argocd.projectairframe.dev y argocd-np.projectairframe.dev
Rutas: /
Etiqueta de entorno: platform
Acceso: Inicio de sesión único. Los nombran los contratos; ninguno está construido.
Fuente: landing-zone docs/contracts.md 8

La página de vistas previas explica cómo el nombre de host de una vista previa llega a sus servicios, y la de límites de confianza qué protege el inicio de sesión único.

Dónde está

En el repositorio landing-zone:

En el repositorio golden-path:

modules/airframe-context/: las etiquetas que pone cada módulo