**Estado atual (em 2026-09-22): o código de rollout está implementado e
testado ao longo de todo o percurso — genesis → fencing → registry → broker → PEP →
supervision → translator → deployment.** Cada pacote `src/` traz a sua
própria suite de testes (testes unitários/de integração em Go, Python para o
tooling de auditoria e medição), e `deploy/selftest/` executa os guias de
deployment de ponta a ponta (**82 controlos, 0 falhas** — um guia que se
desvia do código quebra aí, não nas mãos do operador). Nenhum PR está aberto
contra este repositório neste momento — o backlog que estava em curso (T25
degradação controlada, T38 durabilidade do registry bounded-async, T26 medição
da qualidade do translator) já foi todo merged. Dois itens permanecem abertos
e acompanhados deliberadamente, nenhum deles bloqueando o piloto: a tradução
para inglês da documentação francesa restante ([#83](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/83),
em curso — a maior parte de `deploy/` e `docs/` já tem versões primárias em
inglês, ver "Note on language" acima), e a camada inter-domínio
(spec §13 — adiada pela própria spec, acompanhada em
[#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33) para que
"adiado" permaneça visível em vez de silenciosamente ausente). O que
deliberadamente **não** está aqui ainda para além disso: os corpora nativos
do translator por linguagem (a constituir no piloto, §15 — o pipeline que os
reproduz e faz gate sobre eles está construído) e o caminho de escalonamento
para arbitragem humana (o brokerd v1 aceita apenas o translator `structured`).
Não faça deploy de `config/` tal como está — todos os ficheiros aí o dizem
explicitamente, vale a pena repeti-lo aqui também. O protocolo contra o qual
este código de rollout governa também não é um esqueleto: `tbp4.2.1/` inclui
o core funcional (HSM signer, Merkle audit chain, OPA policy engine, testes,
processo de revisão adversarial) in-tree via git submodule, fixado a um commit
específico — presente aqui sem ser copiado ou duplicado.

## Orientação de configuração — por onde começar

Com base na sequência de implementação (§13) e no âmbito do piloto P1 (§13,
§9.1: 1 VLAN de servidor, router Debian, 2 células, 802.1X, registry central,
regressão medida da experiência do utilizador = 0):

1. **Genesis e chaves** (§7.2, §3.2) — antes de tudo o resto: uma cerimónia
   de genesis assinada pelo quórum do controller (m-de-n, HSM), ancorada
   out-of-band. [`scripts/genesis/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/scripts/genesis) fornece o tooling
   de epoch-0 (caminho de dev incluído); a cerimónia em si permanece
   procedimental, não código — nada neste repo a substitui.
2. **Cluster fencing** (§7, §13 passo 2) — emissão e rotação de epoch,
   quórum do controller (k-de-n) para ações de classe-W, promoção
   mirror/canary. Necessário antes de qualquer deployment multi-célula,
   incluindo o piloto P1 de 2 células abaixo — uma única célula pode adiar
   isto, um piloto não pode. Implementado em [`src/cluster/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/cluster)
   (epoch tracker de autoridade única, quórum, promoção por prova de
   receção — nenhuma chave privada guardada aí) e ligado ao broker
   ([`src/broker/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/broker)).
3. **OPA + registry** — instalar OPA, gerar `policies/capabilities.json`
   seguindo [`policies/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/policies/README.md) (remover
   `http.send` e `time.now_ns` antes de qualquer deployment, nunca depois;
   `validate_determinism.go` e o gate de determinismo da CI impõem isto),
   iniciá-lo com `lab/docker-compose.yml` para iterar nas regras localmente.
   O manifesto atestado e o measured boot (§6.3, §13 passo 3) — o próprio
   estado de uma célula tem de ser provável antes de as suas decisões o
   serem — estão implementados em [`src/registry/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/registry) a par do
   cell log, backpressure e anchoring.
4. **PEP** — o primeiro perímetro genuinamente governado (§13), implementado
   em [`src/pep/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep): validação de token (CWT/COSE, Ed25519),
   anti-replay fail-closed com memória limitada, modo degradado de estado do
   relógio, quotas de execução, e o gate plan-as-contract (§4.2, §13 passo 4
   — a validação de token por si só governa uma única ação, não o plano
   multi-passo que um operador realmente assina). Leia
   [`src/pep/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/README.md), e
   [`config/nftables/pep-redirect.nft`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/nftables/pep-redirect.nft)
   para o redirecionamento de rede do lado Debian. **Faça deploy primeiro em
   modo monitor** (registar, sem bloquear) — nunca `closed` no primeiro
   rollout (doutrina §5.3); o procedimento de mudança de postura é
   [`deploy/monitor-to-closed.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/deploy/monitor-to-closed.md). Para
   PostgreSQL, o PEP in-process de dois hooks vive em
   [`src/pep/postgres-extension/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/postgres-extension) (§4.4).
5. **NAC em paralelo** — [`config/freeradius/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/freeradius):
   802.1X/EAP-TLS reutilizando a mesma PKI que o handshake (§3), fail-closed
   imposto ao nível do switch (não apenas do lado do RADIUS), sem VLAN
   atribuída por RADIUS na v1. As suites netns em `lab/tests/` exercitam os
   caminhos fail-closed, MAB/IoT-VLAN e remediação OCSP.
6. **Hardening do host** — [`config/sysctl/99-tbp-hardening.conf`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/sysctl/99-tbp-hardening.conf)
   em todas as máquinas que executam um componente TBP (broker, PEP, registry).
7. **Translator por último** (§13) — quando tudo o resto estiver estável.
   Entregue em [`src/translator/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/translator): hardening de runtime
   (non-root, cap-drop, seccomp — distinto de `dm-verity`, que protege a
   imagem em repouso, não o runtime), a máquina de estados de degradação
   controlada (apenas structured, sem fallback para a cloud), e medição de
   qualidade (`measure.py` reproduz o corpus e faz gate da CI na regressão
   de FNR/FPR, `tmetrics` inscreve o resultado como folha do registry, T26,
   §4.5) — os corpora em si são constituídos no piloto, não enviados aqui.
8. **Deployment multi-máquina** — [`deploy/apercu.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/deploy/apercu.md)
   é o ponto de entrada (o quê, onde, porquê, pré-requisitos); sintetiza
   os guias por função (router, célula, servidor, supervisor) e as suas
   checklists de aceitação por máquina. `deploy/selftest/` **executa**
   os guias (`bash deploy/selftest/selftest.sh`, 82 controlos,
   fail-closed) — execute-o antes de tocar numa máquina real.

Em cada passo, meça contra o orçamento de fricção (§9.1) — ver
[`tests/p1_friction/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/tests/p1_friction) para os limiares exatos e o
harness executável. O piloto falha se a latência ou a taxa de arbitragem
excederem estes limiares, mesmo que tudo o resto funcione.

## Roadmap: escalas de deployment à medida

O TBP é um sistema de governação complexo e de escala completa — cluster
fencing, quórum, um supervisor independente, um translator endurecido, um
handshake inter-entidade. Nem todos os deployments precisam de tudo isto.
Um pequeno negócio de servidor único que quer "nenhum agente de IA age sem
uma razão provável e registada" não precisa de failover de duas células
mais do que uma rede doméstica precisa de um SOC. O plano é empacotar o que
já existe neste repositório em **quatro escalas de deployment**, cada uma
um superconjunto estrito da anterior — as mesmas primitivas em todo o lado
(fail-closed, folhas apenas com hash, monitor antes de closed), mais delas
ligadas entre si à medida que a escala sobe, e a postura de segurança — e a
complexidade operacional que isso compra — aumentando em conformidade:

- **Escala 1 — Máquina única.** Um host, um perímetro governado: `pepd`
  à frente do serviço, um sidecar OPA local, um registry `CellLog` único.
  Sem cluster fencing (nada para cercar com uma célula), sem NAC (nada para
  admitir numa rede — é uma só caixa), sem daemon broker ou supervisor.
  O genesis colapsa para um único keypair de operador, documentado como tal
  em vez de fingir uma cerimónia de quórum que não é uma. Menor complexidade
  operacional: acertar as regras OPA, fazer deploy em modo monitor, vigiar
  o orçamento de fricção, conquistar `closed`.
- **Escala 2 — Equipa pequena / site único.** Um punhado de máquinas numa
  LAN atrás de um `brokerd`, ainda um registry único (sem fencing ainda —
  uma célula autoritativa ainda é suficiente a esta dimensão), NAC
  adicionado (`config/freeradius/`, 802.1X no switch) para admitir máquinas
  no segmento, hardening do host aplicado em todo o lado. Mais um daemon,
  mais um subsistema, o mesmo modelo de registry que a escala 1.
- **Escala 3 — Multi-célula resiliente.** O que já está totalmente
  construído e documentado como o deployment piloto P1 acima: 2+ células,
  cluster fencing (emissão/rotação de epoch, quórum k-de-n para ações de
  classe-W, promoção mirror/canary), um supervisor independente com uma
  consola read-only, o translator endurecido com degradação controlada, a
  sequência completa de guias `deploy/` e o seu selftest de 82 controlos.
  Para organizações que não toleram uma célula única em baixo, ou cujos
  agentes governados justificam as máquinas extra.
- **Escala full — Multi-entidade.** O handshake inter-entidade (§3):
  provar política, continuidade de histórico e liveness através de
  fronteiras organizacionais, não apenas entre células da mesma organização
  — federação entre deployments TBP governados independentemente que têm de
  confiar uns nos outros sem confiar uns nos outros. Deliberadamente ainda
  não iniciado; acompanhado em [#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33)
  (T32) para que permaneça visível como uma fase posterior e distinta em vez
  de silenciosamente ausente. Este é genuinamente trabalho de protocolo
  novo, não apenas mais máquinas a executar o que já existe.

**Honestidade sobre onde isto está**: a escala 3 é entregue hoje sob o nome
piloto-P1 usado ao longo deste README. As escalas 1 e 2 ainda não estão
empacotadas como guias próprios — são alcançáveis hoje fazendo deploy de um
subconjunto do que está documentado (saltar o cluster fencing e o NAC para a
escala 1, adicionar NAC mas manter uma célula para a escala 2), mas esse
caminho ainda não está escrito, e nada impede atualmente alguém de o ligar
corretamente por sua conta, sujeito à mesma doutrina. A escala full requer
código novo real (as três provas da §3), não apenas guias novos.

### Próximo trabalho planeado

Dois fluxos de trabalho, acompanhados como issues separadas porque são
tipos de esforço diferentes:

1. **Guias de deployment por escala, mais tooling de administração
   dimensionado para cada escala** ([#86](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/86)).
   Transformar as escalas acima em `deploy/scale-1.md` /
   `deploy/scale-2.md` — a escala 3 já tem a sua sequência de guias, é
   `deploy/apercu.md` e os guias por função que sintetiza — é metade
   disto: um caminho documentado e coberto por selftest por escala em vez
   de "o guia do piloto, menos o que descobrir para saltar". A outra metade
   é tooling virado para o operador, que hoje é uma API JSON read-only
   (`src/supervision/console.go`: `/v1/arbitration`,
   `/v1/epoch`, `/v1/indicators`) mais ficheiros em bruto e CLIs (políticas
   Rego editadas à mão, `policies/gen_capabilities.sh` /
   `validate_determinism.go` para validar e remover antes do deploy; o
   registry lido pelo scan verificado do `ChainWatcher`, exercitado em
   testes e selftest mas sem UI de navegação). Três ferramentas dedicadas
   estão planeadas por cima do que já existe, cada uma dimensionada para o
   que uma dada escala realmente precisa (um operador de escala 1 não
   precisa de vistas de arbitragem multi-célula; um de escala 3 precisa):
   - um **dashboard de supervisão** por cima da consola read-only
     existente — virado para humanos, ainda read-only por construção (§7.1
     "o supervisor vê tudo, não toca em nada" mantém-se inalterado, D81);
   - um **editor de regras/políticas** para o bundle OPA Rego — editar,
     testar contra os mesmos gates de determinismo e remoção de capacidades
     que `validate_determinism.go` já impõe, e comparar com o que está
     deployed, antes de algo chegar à produção;
   - um **navegador de auditoria** para o registry — pesquisar e filtrar o
     histórico de folhas (`KindDecision`, `KindTelemetry`, `KindQuorum`, …)
     com a mesma prova de checkpoint verificável por terceiros que o
     `ChainWatcher` já faz programaticamente, tornada legível para um
     auditor humano em vez de uma asserção de teste.
2. **Alinhamento com standards — de um modelo de política proprietário
   para um interoperável** ([#87](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/87)).
   A taxonomia de regras do TBP (classes F/I/W/OUT, §5.3),
   o seu audit trail (folhas Merkle-logged apenas com hash, §6.2), e o seu
   conjunto de controlos (fail-closed, monitor-before-closed, quórum para
   ações de alto risco) são hoje específicos do TBP — internamente
   consistentes e testados, mas não mapeados para nenhum framework externo
   que um auditor ou um regulador já reconheceria. O trabalho é identificar
   a que standards existentes (e emergentes) isto se mapeia, e onde estão
   as lacunas — não assumir que algum destes se aplica, ou que o TBP já os
   satisfaz, sem fazer esse mapeamento primeiro. Candidatos que vale a pena
   avaliar como ponto de partida: **ISO/IEC 42001** (standard de sistema de
   gestão de IA — o encaixe mais próximo para uma alegação de "governação
   de IA"), o **NIST AI Risk Management Framework**, as obrigações de
   logging e supervisão humana do **EU AI Act** para sistemas de alto risco
   (a folha-por-decisão da §4.1 e a arbitragem plan-as-contract da §4.2
   estão estruturalmente próximas do que os Artigos 12/14 pedem — não
   verificado, precisa de um mapeamento real, não de uma assunção),
   **NIST SP 800-207** (Zero Trust Architecture — a spec já posiciona o
   TBP face ao Zero Trust na §3.3, uma comparação formal controlo-a-controlo
   é o próximo passo natural), e **OSCAL** (o formato de controlo/avaliação
   legível por máquina do NIST — um alvo de exportação plausível para que o
   próprio audit trail do TBP possa alimentar tooling de conformidade
   standard em vez de exigir um leitor à medida).
   Isto é trabalho de investigação e especificação antes de ser código: o
   produto é uma análise de lacunas e, onde existe um mapeamento real, ou
   código adaptador ou equivalência documentada — não uma reescrita do
   motor de regras.

## Licenciamento

Licença dupla, por subárvore:
- **`docs/` e `figs/`**: [CC BY 4.0](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/docs/LICENSE) — livre para partilhar e
  adaptar com atribuição.
- **Todo o resto** (`config/`, `src/`, `policies/`, `lab/`, `tests/`,
  `deploy/`, `scripts/`, `.github/`): [Apache 2.0](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/LICENSE) — a mesma licença
  que o protocolo core em
  [Responsible-Alliance-Protocol](https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol).
  Este código teve licença fechada durante uma fase piloto inicial; essa
  fase terminou — o projeto não é viável construído sozinho, e um
  protocolo de governação cuja própria doutrina é "nunca por confiança,
  sempre por prova verificável" não deve pedir confiança na sua própria
  implementação.

Ver [`CONTRIBUTING.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/CONTRIBUTING.md) para saber como contribuir — código
incluído agora, não apenas documentação — e as regras a seguir ao editar a
spec (normalização de terminologia, citações verificadas, changelog).