Nomes, rótulos e nomes de host

O Airframe deriva quase todo nome do lugar de um produto no catálogo, então um nome diz a que uma coisa pertence sem precisar consultar nada. Esta página lista as formas que a plataforma usa para projetos, identidades, estado, repositórios e grupos, os rótulos que cada recurso leva, e o nome de host que um produto recebe em cada ambiente, com os poucos nomes de host que são públicos.

Como ler as tabelas

Um produto é identificado pelo seu caminho, <journey>/<domain>/<context>/<product>. Um nome é único só entre os seus irmãos, então um nome que vive num espaço maior que os próprios projetos do produto leva os níveis acima dele. Dentro dos projetos de um produto basta o nome do produto, porque o projeto é o namespace.

<rnd> são quatro letras minúsculas e dígitos, sorteados uma vez quando um projeto ou um bucket é criado e nunca escolhidos à mão. <iid> é o número de um merge request. Os exemplos vêm de uma organização de demonstração, uma loja on-line fictícia cujo código é lk.

As tabelas descrevem a plataforma na versão da plataforma 2026.10.01-1, como estão em 2026-10-01 os contratos e o código que cria cada nome. Onde eles diferem, a tabela segue o código. Uma linha marcada como projetado é uma forma que os contratos especificam e que nada cria ainda.

Nomes

Projetos de produto

Forma: lk-<domain>-<product>-<rnd> e lk-<domain>-<product>-np-<rnd>
Exemplo: lk-billing-invoicing-np-7q2m
Significado: Os projetos de produção e de não produção de um produto, criados pela fábrica de projetos do seu domínio. A jornada não está no identificador; os rótulos dizem de qual jornada ele é. O pacote de políticas recusa um identificador de projeto em qualquer outra forma.
Fonte: landing-zone roots/project-factory/; control-plane policy/airframe/naming.rego

Projetos da plataforma

Forma: lk-<service>-<rnd>, ou lk-<service>-np-<rnd>
Exemplo: lk-runtime-np-k3d8
Significado: Os projetos da própria plataforma, um por serviço: network, runtime, observability, ci, catalog, audit, pact, eventcatalog, website ou analytics. Os sufixos da fábrica da plataforma ficam registrados em catalog.yaml.
Fonte: landing-zone docs/contracts.md 2, roots/project-factory/platform/; control-plane policy/airframe/naming.rego

Playgroundsprojetado

Forma: Projeto lk-play-<name>-<rnd>; repositório projectairframe/playground/<name>
Exemplo: lk-play-router-experiment-x1c4
Significado: Um experimento curto de um time, com orçamento e data de validade. O esquema do catálogo descreve os playgrounds, mas nenhuma raiz os cria ainda.
Fonte: landing-zone docs/contracts.md 2; catalog schema/playground.schema.json

Identidades de plan e de apply

Forma: <product>-plan@ em cada projeto do produto; <product>-apply@ na produção e <product>-np-apply@ na não produção
Exemplo: invoicing-apply@lk-billing-invoicing-7q2m.iam
Significado: As identidades com que o Terraform de um produto roda. A identidade de plan lê; a de apply muda o projeto. O executor pode agir como cada identidade de plan e cada identidade de apply de não produção, e como nenhuma de produção. O projeto é o namespace, então basta o nome do produto.
Fonte: landing-zone roots/project-factory/

Identidades de execução

Forma: <product>-<name>@ no projeto do ambiente, com -sandbox ou -eph-<iid> acrescentado num sandbox ou numa prévia
Exemplo: invoicing-api@
Significado: Uma identidade por serviço em execução, com o nome da chamada ao módulo, que tem exatamente o que esse serviço usa.
Fonte: golden-path modules/cloud-run-service/main.tf

Identidades das raízes da plataforma

Forma: platform-<root>@ no projeto de execução da plataforma; a fábrica de projetos de um domínio é factory-<journey>-<domain>@
Exemplo: platform-catalog@
Significado: Uma identidade por raiz da plataforma, que só um job da main protegida do seu repositório, no ambiente platform/<root>, consegue obter.
Fonte: landing-zone roots/wif/main.tf

Buckets de estado

Forma: lk-tfstate-platform-<rnd> e lk-tfstate-prod-<rnd> no projeto de execução; lk-tfstate-np-<rnd> no projeto de execução de não produção
Exemplo: lk-tfstate-platform-ivww
Significado: Onde o Terraform guarda o estado: o das raízes da plataforma, o de produção e o de não produção, cada bucket criptografado com uma chave que a plataforma detém.
Fonte: landing-zone roots/state/main.tf

Prefixos de estado de um produto

Forma: <journey>/<domain>/<context>/<product>/ seguido de prod, grafana, np, sandbox ou eph/<iid>
Exemplo: settle/billing/invoicing/invoicing/eph/42
Significado: Onde cada raiz de um produto guarda o seu estado: prod e grafana no bucket de produção, o resto no de não produção. Cada identidade de apply pode escrever os prefixos do próprio produto e nenhum outro.
Fonte: landing-zone roots/project-factory/; golden-path template/.gitlab-ci.yml.jinja

Prefixos de estado da plataforma

Forma: platform/<repository>/<root>
Exemplo: platform/landing-zone/network
Significado: O estado de cada raiz da plataforma, no bucket da plataforma. A identidade de cada raiz lê e escreve o próprio prefixo.
Fonte: landing-zone roots/wif/grants.tf

Repositórios de produto

Forma: projectairframe/<journey>/<domain>/<context>/<product>; no grupo restrito de um domínio, projectairframe/<journey>/<domain>/<context>/restricted/<product>
Exemplo: projectairframe/shop/store/ordering/orders
Significado: Criados pela raiz de GitLab do domínio, como a conta de fábrica do domínio. O caminho de um produto removido nunca é reutilizado.
Fonte: control-plane modules/product-repositories/main.tf; landing-zone roots/project-factory/

Repositórios de um produto espalhado por váriosprojetado

Forma: projectairframe/<journey>/<domain>/<context>/<product>/<repo>
Exemplo: projectairframe/fulfil/shipping/tracking/tracking/api
Significado: Um repositório por aplicação, sob o grupo próprio do produto, cada um com o seu estado, as suas imagens e o seu nome de host de prévia.
Fonte: landing-zone docs/contracts.md 2, docs/adr/0017-multi-repository-products-and-adoption-by-moving-the-group.md

Grupo de usuários

Forma: lk-<journey>-<domain>-<context>-<product>-users@projectairframe.dev
Exemplo: lk-shop-store-ordering-orders-users@
Significado: As pessoas que podem chegar ao produto atrás do login único: hoje os membros ativos do seu time.
Fonte: landing-zone roots/groups/main.tf

Grupo do time

Forma: lk-team-<team>@projectairframe.dev
Exemplo: lk-team-store-core@
Significado: Os membros ativos de um time, com acesso de leitura aos projetos dos produtos do time.
Fonte: landing-zone roots/groups/main.tf, roots/project-factory/

Grupos de líderes

Forma: lk-journey-<journey>-leads@, lk-<journey>-<domain>-leads@ e lk-<journey>-<domain>-<context>-leads@, em projectairframe.dev
Exemplo: lk-shop-store-leads@
Significado: Os líderes de cada nível da hierarquia, como o catálogo os nomeia.
Fonte: landing-zone roots/groups/main.tf

Grupos da plataforma

Forma: lk-platform@ e lk-breakglass@, em projectairframe.dev
Exemplo: lk-platform@
Significado: O time de plataforma, cujos membros aprovam cada concessão administrativa, e o grupo de break-glass, cujos membros podem pedir a maioria das concessões quando o caminho normal não funciona.
Fonte: landing-zone roots/pam/main.tf

Segredos

Forma: O nome que o arquivo de segredos do produto lhe dá, no projeto do ambiente
Exemplo: secret-key
Significado: O repositório de um produto lista os seus segredos por nome no seu arquivo de segredos, nunca com um valor. O módulo de segredos do golden path cria cada um, e um mantenedor adiciona o valor no Secret Manager.
Fonte: golden-path modules/secrets/main.tf

Tópicos e assinaturas do Pub/Subprojetado

Forma: Tópico <domain>.<product>.<noun>.<verb-past> no projeto do publicador; assinatura <consumer-product>-<name> no do consumidor
Exemplo: store.orders.order.placed
Significado: Nenhum módulo os cria ainda. Os campos topics e consumes do catálogo já usam os nomes dos eventos.
Fonte: landing-zone docs/contracts.md 2; golden-path modules/

As raízes de Terraform de um produto

Forma: infra/prod, infra/np, infra/sandbox, infra/eph e infra/grafana
Exemplo: infra/eph
Significado: Produção; não produção; o sandbox; uma prévia, que o executor aplica; e os painéis próprios do produto, aplicados com a identidade de apply de produção no ambiente grafana.
Fonte: golden-path template/infra/, template/.gitlab-ci.yml.jinja

Ambientes do GitLab

Forma: prod, np e grafana num repositório de produto; platform/<root> num repositório da plataforma; platform/audit, o do relatório de desvio, nos dois; executor no control-plane
Exemplo: platform/network
Significado: O ambiente é um dos dados que a federação de identidade de carga de trabalho verifica, então um job obtém uma identidade só no seu próprio ambiente. Um job próprio de um produto não pode declarar nenhum.
Fonte: golden-path template/.gitlab-ci.yml.jinja; control-plane .gitlab-ci.yml, templates/drift-report/template.yml, policy/airframe/pipeline.rego

Nomes de chamadas a módulos

Forma: Um slug de 2 a 14 caracteres
Exemplo: api, worker-mail
Significado: O name de uma chamada a um módulo do golden path. O módulo deriva dele os nomes dos seus recursos, como o serviço do Cloud Run <product>-<name>, e recusa um nome em qualquer outra forma.
Fonte: golden-path modules/cloud-run-service/variables.tf, modules/cloud-sql/variables.tf

Recursos avulsos numa raiz de produto

Forma: <product>-<name>, com -<rnd> acrescentado para um nome que o Google mantém global
Exemplo: orders-exports-k3d8
Significado: Um recurso que um produto declara por conta própria, fora dos módulos do golden path. O pacote de políticas alerta sobre cada recurso assim, e também quando o seu nome não começa com o do produto.
Fonte: control-plane policy/airframe/naming.rego

Grafana

Forma: Uma pasta para cada nível do caminho do produto; os painéis <product> service, <product> SLO e <product> cost na pasta do produto; um ponto de contato por time
Exemplo: orders service
Significado: Criados pela raiz de Grafana do operations a partir do catálogo.
Fonte: operations roots/grafana/main.tf, roots/grafana/pack.tf

Rótulos do Google Cloud

Cada projeto e cada recurso levam rótulos que dizem a que pertencem: a fábrica de projetos os coloca nos projetos, e os módulos do golden path nos recursos. O pacote de políticas recusa um recurso que declara rótulos mas não tem algum destes seis: managed_by, tenant, domain, product, env e criticality (aplicado, no código e no plano). Um recurso que não declara nenhum rótulo passa por essa regra.

`managed_by`

Valores: airframe
Significado: A plataforma gerencia o recurso. Exigido pelo pacote de políticas.
Fonte: landing-zone docs/contracts.md 7; control-plane policy/airframe/naming.rego

`tenant`

Valores: lk
Significado: O código da organização. Exigido pelo pacote de políticas.
Fonte: landing-zone docs/contracts.md 7; control-plane policy/airframe/naming.rego

`journey`

Valores: O slug de uma jornada, ou platform
Significado: A jornada do produto, nos seus projetos e nos recursos cujo módulo conhece o caminho do produto.
Fonte: landing-zone roots/project-factory/; golden-path modules/airframe-context/main.tf

`domain`

Valores: O slug de um domínio, ou platform
Significado: O domínio do produto. Exigido pelo pacote de políticas.
Fonte: golden-path modules/airframe-context/main.tf; control-plane policy/airframe/naming.rego

`context`

Valores: O slug de um contexto, ou platform
Significado: O contexto do produto, colocado como journey.
Fonte: landing-zone roots/project-factory/; golden-path modules/airframe-context/main.tf

`product`

Valores: O slug de um produto, ou platform
Significado: O produto. Exigido pelo pacote de políticas, que também o lê para julgar o nome de um recurso avulso.
Fonte: golden-path modules/airframe-context/main.tf; control-plane policy/airframe/naming.rego

`component`

Valores: O slug de um componente, ou main
Significado: A parte do produto a que o recurso pertence.
Fonte: golden-path modules/airframe-context/main.tf

`team`

Valores: O slug de um time
Significado: O time que gerencia o produto.
Fonte: landing-zone roots/project-factory/; golden-path modules/airframe-context/main.tf

`env`

Valores: prod, np, sandbox, eph-<iid>, platform ou play
Significado: O ambiente. Exigido pelo pacote de políticas, e lido pelas regras do pacote sobre prévias.
Fonte: golden-path modules/airframe-context/main.tf; control-plane policy/airframe/naming.rego, cloud_run.rego

`criticality`

Valores: 1, 2, 3, ou platform
Significado: A criticidade do produto. Exigido pelo pacote de políticas.
Fonte: landing-zone roots/project-factory/; control-plane policy/airframe/naming.rego

`data_classification`

Valores: public, internal, confidential ou restricted
Significado: O quanto os dados do produto são sensíveis, nos recursos que os seus módulos criam.
Fonte: golden-path modules/airframe-context/main.tf

`root`

Valores: O prefixo de estado com cada / trocado por -
Significado: Qual raiz de Terraform gerencia o recurso.
Fonte: golden-path modules/airframe-context/main.tf

`module`

Valores: O nome do módulo e a sua versão principal
Significado: Qual módulo do golden path criou o recurso, como cloud-run-service-0.
Fonte: golden-path modules/cloud-run-service/main.tf, modules/secrets/main.tf

`expires`

Valores: Uma data
Significado: Nos serviços de uma prévia: o fim do seu tempo de vida, que o coletor lê.
Fonte: golden-path modules/cloud-run-service/main.tf

Rótulos do GitLab

A raiz de GitLab cria estes rótulos no grupo principal, então todo repositório os tem, exceto lifecycle, que um merge request do catálogo leva pelo nome. A maioria é aplicada por pessoas; a tabela diz onde algo aplica ou lê um deles.

`agent`

Em: Merge requests
Significado: Escrito por um agente de código, cujos commits também levam um trailer Generated-by. Aplicado pelo autor; nada o verifica.
Fonte: control-plane roots/gitlab/locals.tf; landing-zone docs/contracts.md 7

`lifecycle`

Em: Merge requests do catálogo
Significado: Uma mudança do estado de ciclo de vida de um produto. O controle de aprovação se recusa a julgar uma mudança assim sem ele, e o job de ciclo de vida do catálogo o exige.
Fonte: control-plane gate/src/core/ownership.ts; catalog .gitlab-ci.yml, scripts/lifecycle-check.mjs

`warn`projetado

Em: Merge requests
Significado: Um achado de nível de alerta que precisa da aprovação da plataforma. O rótulo existe; nada o aplica, e um alerta não segura nada.
Fonte: control-plane roots/gitlab/locals.tf, templates/validate/template.yml

`exception::open`, `exception::accepted`, `exception::expired`projetado

Em: Merge requests e issues
Significado: Os estados do registro de exceções. Os rótulos existem; o registro não está construído.
Fonte: control-plane roots/gitlab/locals.tf; landing-zone docs/contracts.md 7

`preview::custom`projetado

Em: Merge requests
Significado: Um produto com o seu próprio componente de prévia. Nada o usa, assim como nada lê o campo preview do catálogo.
Fonte: control-plane roots/gitlab/locals.tf

`console-gap`

Em: Issues
Significado: Alguém precisou do console ou de uma concessão: o sinal de que falta um reconciliador. Aplicado à mão.
Fonte: control-plane roots/gitlab/locals.tf; landing-zone docs/contracts.md 7

`audit::drift`

Em: Issues
Significado: Uma raiz cuja infraestrutura difere do seu código. O relatório de desvio abre, reescreve e fecha essas issues no pipeline agendado de cada repositório.
Fonte: control-plane templates/drift-report/template.yml

`audit::orphan`, `audit::duplication`, `audit::misconfiguration`, `audit::cost`, `audit::keep`projetado

Em: Issues
Significado: Os achados do agente de auditoria e o que foi decidido sobre eles. Os rótulos existem; o agente de auditoria não está construído.
Fonte: control-plane roots/gitlab/locals.tf; landing-zone docs/contracts.md 7

`violation::perimeter`projetado

Em: Issues
Significado: Uma violação do VPC Service Controls, com a regra que a permitiria. O rótulo existe; nada abre essas issues, e os perímetros rodam em modo de teste.
Fonte: control-plane roots/gitlab/locals.tf; landing-zone roots/perimeters/

`postmortem`, `ops`, `adr`

Em: Issues e merge requests
Significado: Trabalho de postmortem; um pedido de job operacional; um merge request que adiciona ou substitui um registro de decisão. Aplicados à mão.
Fonte: control-plane roots/gitlab/locals.tf; landing-zone docs/contracts.md 7

Nomes de host

Cada jornada tem a sua própria zona DNS, <journey>.projectairframe.dev, e o domínio é um rótulo dentro dela. Workers e serviços internos não têm nome de host. Todo nome de host fica atrás do login único, pelo Identity-Aware Proxy, o de um produto para o seu grupo de usuários, com três exceções: uma rota que um produto declara pública, que é projetada; o controle de aprovação; e este site. O Grafana fica no endereço próprio do fornecedor.

Produção, a aplicação principal

Nome de host: <product>.<domain>.<journey>.projectairframe.dev
Caminhos: / e /api
Rótulo de ambiente: prod
Acesso: Login único.
Fonte: landing-zone docs/contracts.md 8, roots/network/modules/publications/main.tf; golden-path template/infra/prod/main.tf.jinja

Produção, outra aplicação

Nome de host: <product>-<app>.<domain>.<journey>.projectairframe.dev
Caminhos: /
Rótulo de ambiente: prod
Acesso: Login único. A raiz de rede aceita a forma; o template não renderiza uma segunda aplicação.
Fonte: landing-zone roots/network/modules/publications/main.tf

Não produção

Nome de host: <product>-np.<domain>.<journey>.projectairframe.dev
Caminhos: / e /api
Rótulo de ambiente: np
Acesso: Login único.
Fonte: golden-path template/infra/np/main.tf.jinja; landing-zone roots/network/modules/publications/main.tf

Sandbox

Nome de host: <product>-sandbox.<domain>.<journey>.projectairframe.dev, ou <product>-<app>-sandbox para outra aplicação
Caminhos: / e /api
Rótulo de ambiente: sandbox
Acesso: Login único.
Fonte: golden-path template/infra/sandbox/main.tf.jinja; landing-zone roots/network/modules/publications/main.tf

Prévia do merge request `<iid>`

Nome de host: <product>-eph-<iid>.<domain>.<journey>.projectairframe.dev
Caminhos: Como na produção
Rótulo de ambiente: eph-<iid>
Acesso: Login único, pelo roteador de prévias do produto, que lê o número do merge request no nome de host. O certificado e o registro curinga do domínio cobrem cada prévia.
Fonte: golden-path modules/preview-substrate/main.tf, template/infra/eph/main.tf.jinja; landing-zone docs/contracts.md 8

Prévia de um repositório de um produto espalhado por váriosprojetado

Nome de host: <product>-<repo>-eph-<iid>.<domain>.<journey>.projectairframe.dev
Caminhos: /
Rótulo de ambiente: eph-<iid>
Acesso: Login único.
Fonte: landing-zone docs/contracts.md 8, docs/adr/0017-multi-repository-products-and-adoption-by-moving-the-group.md

Apelido de um produto adotadoprojetado

Nome de host: Cada nome de host de hostnames na entrada
Caminhos: Como a rota própria do produto
Rótulo de ambiente: prod
Acesso: Como a rota própria do produto. O catálogo ainda não aceita o campo.
Fonte: landing-zone docs/contracts.md 8; catalog schema/product.schema.json

Uma rota de produto declarada públicaprojetado

Nome de host: Um dos nomes de host do produto
Caminhos: O caminho da rota
Rótulo de ambiente: prod
Acesso: Pública, sem login único, para uma rota chamada public num produto cuja entrada diz external_ingress: true. A peça para isso não está construída: hoje todo backend de produto tem login único, e o pacote de políticas recusa um sem ele.
Fonte: landing-zone docs/contracts.md 8; golden-path modules/cloud-run-service/main.tf; control-plane policy/airframe/cloud_run.rego

Playgroundprojetado

Nome de host: play-<name>.projectairframe.dev
Caminhos: /
Rótulo de ambiente: play
Acesso: Login único.
Fonte: landing-zone docs/contracts.md 8

O catálogo de arquitetura

Nome de host: catalog.projectairframe.dev
Caminhos: /
Rótulo de ambiente: platform
Acesso: Login único, para todas as pessoas da organização.
Fonte: landing-zone docs/contracts.md 8; operations roots/eventcatalog/edge.tf

O controle de aprovação

Nome de host: gate.projectairframe.dev
Caminhos: /
Rótulo de ambiente: platform
Acesso: Público. O controle verifica ele mesmo o token de cada chamador, e o pacote de políticas o lista como um serviço que faz isso.
Fonte: landing-zone docs/contracts.md 8; control-plane policy/airframe/data.json, policy/airframe/cloud_run.rego

Este site

Nome de host: www.projectairframe.dev; projectairframe.dev redireciona para ele
Caminhos: /
Rótulo de ambiente: platform
Acesso: Público. É o único serviço que o pacote de políticas lista como serviço público da borda.
Fonte: landing-zone docs/contracts.md 8, roots/network/edge.tf; control-plane policy/airframe/data.json

Outros serviços da plataformaprojetado

Nome de host: pact.projectairframe.dev, argocd.projectairframe.dev e argocd-np.projectairframe.dev
Caminhos: /
Rótulo de ambiente: platform
Acesso: Login único. Os contratos os nomeiam; nenhum está construído.
Fonte: landing-zone docs/contracts.md 8

A página de prévias explica como o nome de host de uma prévia chega aos seus serviços, e a de limites de confiança o que o login único protege.

Onde fica

No repositório landing-zone:

No repositório golden-path:

modules/airframe-context/: os rótulos que cada módulo coloca