docs: Genesis Engine + Quantum Computer Update Protocol

README.md

@@ -97,3 +97,18 @@ docs/        arquitetura e documentação
 ---
 
 Construído dentro da Virtuals Protocol. Base (8453).
+
+## Genesis Engine
+
+O motor que faz o processo completo num só fluxo guiado: **link Irys (metadata + arte 2D/3D)
+→ mint do iNFT (ICloneAgent, Base) → criação do agente via CLI da Virtuals (identidade,
+wallet + email, fund, offerings) → elo NFT ⇄ agente** — `ownerOf(tokenId)` controla o agente,
+e a TBA (ERC-6551) do token pode custodiar os ganhos. Vive no HUB e partilha o runner do
+iTerminal. Detalhe no whitepaper: [cloneframe.io](https://cloneframe.io) → HUB · workstation.
+
+## Quantum Computer Update Protocol
+
+Compromisso de migração pós-quântica **antes de 2029** (prazo de prontidão, não doomsday):
+crypto-agility via account abstraction, assinaturas híbridas ECDSA + ML-DSA (FIPS 204),
+rotação de chaves por hash-commit; a metadata na Irys já é quantum-safe (hash-based).
+Plano completo: [docs/QUANTUM.md](docs/QUANTUM.md).

docs/QUANTUM.md

@@ -0,0 +1,53 @@
+# Quantum Computer Update Protocol
+
+> Manter os iNFTs seguros contra computadores quânticos — completando a migração
+> pós-quântica **antes** de a janela de risco abrir, não depois.
+> Versão completa no whitepaper: [cloneframe.io](https://cloneframe.io) → Whitepapers → Quantum Update Protocol.
+
+## O problema, com honestidade
+
+As blockchains de hoje assinam com criptografia de curva elíptica (ECDSA em secp256k1).
+Um computador quântico suficientemente grande, a correr o algoritmo de Shor, poderia um dia
+derivar uma chave privada a partir de uma chave pública exposta. **Essa máquina ainda não
+existe** — os melhores sistemas de 2026 estão longe da escala necessária — mas a postura
+honesta é preparar cedo: migrações levam anos, e dados assinados hoje podem ser
+*colhidos agora para serem quebrados depois* (harvest now, decrypt later).
+
+## Porquê 2029
+
+Tratamos **2029 como prazo de prontidão, não como data de apocalipse.** Os roadmaps de
+hardware (IBM, Quantinuum) apontam marcos de tolerância a falhas para 2029–2030, e a
+investigação de 2025–2026 tem reduzido repetidamente o número de qubits necessários para
+um ataque criptográfico. Nada disto significa que as blockchains quebram em 2029 — significa
+que um projecto prudente deve estar **totalmente migrado antes** desse horizonte, em linha
+com as orientações do NIST e da indústria.
+
+## A base que adoptamos
+
+Standards NIST finalizados em 2024. Para assinaturas — a parte que importa à posse de NFTs —
+o standard primário é **ML-DSA (FIPS 204)**, com **SLH-DSA (FIPS 205)** como backup
+conservador baseado em hash. Adoptamos standards; não inventamos criptografia própria.
+
+## Como implementamos — quatro movimentos, application-first
+
+1. **Crypto-agility por design** — posse e acções do agente passam por autenticação de
+   smart-account (account abstraction), para que o esquema de assinatura seja actualizável
+   como módulo — sem migração de tokens.
+2. **Assinaturas híbridas** — ECDSA + ML-DSA em conjunto durante a transição: a segurança
+   mantém-se enquanto uma das pernas se mantiver. A perna clássica cai quando houver
+   confiança pós-quântica estabelecida.
+3. **Rotação de chaves por hash-commit** — publicar hoje um compromisso (hash) da futura
+   chave pós-quântica de cada owner; revelar e activar mais tarde. Guardians de social
+   recovery rodáveis para chaves PQC sem mudar o endereço.
+4. **Integridade já segura** — arte e alma seladas na Irys são endereçadas por hash; funções
+   de hash não são quebradas pelo algoritmo de Shor — a camada de metadata não precisa de
+   migração.
+
+## O que controlamos, o que herdamos
+
+A **camada de aplicação** (como um agente se autentica, como uma chave roda, como a posse
+se prova) é nossa — e será quantum-ready. A **camada de protocolo** (assinaturas de consenso
+de Ethereum/Base) não é nossa; aí seguimos o roadmap pós-quântico da Ethereum Foundation e
+adoptamos as suas actualizações. O Quantum Update Protocol é o compromisso de fechar a nossa
+metade desse fosso primeiro, e de manter a crypto-agility como propriedade permanente de
+cada iNFT.

docs/TRUSTLESS_AGENTS.md

@@ -0,0 +1,42 @@
+# Trustless Agents — identidade on-chain (ERC-8004)
+
+> Os agentes do CLONE FRAME estão registados como **Trustless Agents** (ERC-8004) na Base.
+> Versão completa no whitepaper: [cloneframe.io](https://cloneframe.io) → Whitepapers → Trustless Agents.
+
+## Registos (verificáveis por qualquer pessoa)
+
+| Agente | agentId | Prova on-chain |
+|--------|---------|----------------|
+| **iCLONE** | `55101` | [registry entry](https://basescan.org/nft/0x8004A169FB4a3325136EB29fA0ceB6D2e539a432/55101) |
+| **VEGETA** | `58099` | [registry entry](https://basescan.org/nft/0x8004A169FB4a3325136EB29fA0ceB6D2e539a432/58099) |
+
+Registry (singleton, Base 8453): `0x8004A169FB4a3325136EB29fA0ceB6D2e539a432`.
+Cada registo é um ERC-721 cujo `tokenURI` resolve para o cartão do agente — nome,
+descrição, endpoints e ofertas de trabalho atuais.
+
+## A pilha de confiança para agentes
+
+Quatro standards abertos, cada um a responder a uma pergunta:
+
+1. **ERC-8004 — Identidade.** Quem é o agente? Registo on-chain portátil + reputação. **Live na Base; estamos registados.**
+2. **ERC-8183 — Comércio.** Como se liquida o trabalho? Jobs com escrow e avaliador. O Agent Commerce Protocol (ACP) é a implementação de referência — os carris onde os nossos agentes já negoceiam.
+3. **ERC-8126 — Verificação.** É de confiança? Verificação por terceiros condensada num risk score 0–100 com provas de conhecimento-zero. Standard finalizado, infraestrutura de fornecedores ainda em formação — adotamos quando amadurecer; até lá não reclamamos score.
+4. **ERC-8196 — Execução.** Esta ação está autorizada? Carteiras de agente com políticas. Em fase de especificação.
+
+O CLONE FRAME é uma plataforma independente e adota cada camada à medida que amadurece —
+integra-se com a Virtuals Protocol, cujos carris ACP os nossos agentes já usam.
+
+## O contrato iNFT não muda
+
+O registo ERC-8004 é uma entrada separada que aponta para o agente. O `ICloneAgent`
+(ERC-721A + ERC-2981 + ERC-6551) mantém-se intocado. Quando o minting abrir, o
+`agentWallet` do registo pode apontar para a backpack ERC-6551 do agente — identidade
+de registo e conta token-bound como uma só unidade económica.
+
+## Onde isto encontra o Quantum Update Protocol
+
+A medida quântica opcional do ERC-8126 (QCV) cifra registos de verificação com AES-256 —
+um esquema **simétrico** — e as suas provas ZK (Groth16) são de curva elíptica, o que a
+própria especificação assinala como não pós-quântico. O lado das **assinaturas** desse
+fosso é exatamente o que o nosso [Quantum Update Protocol](./QUANTUM.md) cobre:
+FIPS 204/205, transição híbrida, crypto-agility como propriedade permanente.