Governação do Kshana

Este documento indica como o Kshana é governado: quem toma as decisões, como, e o que o projeto absorverá e não absorverá. É deliberadamente leve — proporcional à dimensão atual do projeto — e é honesto quanto à realidade atual de um único responsável e quanto ao caminho para uma governação mais ampla à medida que a comunidade crescer.

Missão e âmbito#

O Kshana é uma referência neutra, reprodutível e validada com honestidade para o desempenho e a resiliência de PNT híbrido quântico/clássico. A missão fixa o limiar para todas as decisões: correção, citações e reprodutibilidade acima da abrangência. O âmbito honesto está documentado em docs/CAPABILITY.md e o estado de validação em docs/VALIDATION.md; as propostas são avaliadas face a esse âmbito, não face ao número de funcionalidades.

Papéis#

Responsável pela manutenção. O Kshana é atualmente mantido pelo seu fundador, a Ashforde OÜ (contacto: contact@ashforde.org). O responsável pela manutenção é quem toma a decisão final sobre o âmbito, o projeto, as versões e o que é integrado. Este é um modelo de responsável benevolente, declarado com clareza em vez de disfarçado de um comité que não existe.
Contribuidores. Qualquer pessoa que abra uma issue ou um pull request. As contribuições são avaliadas pelo limiar de CONTRIBUTING.md — proveniência de cada parâmetro numérico, validação face a uma relação publicada e honestidade quanto à maturidade.
Futuros committers. Quando uma contribuição sustentada e de elevada qualidade o justificar, os direitos de commit serão alargados a contribuidores de confiança, e este documento será atualizado para um modelo de vários responsáveis (decisões por consenso tácito, com o grupo de responsáveis a resolver os desacordos). Até lá, o caminho é: contribuir, construir um historial e ser convidado.

Como se tomam as decisões#

Discussão aberta. As alterações substanciais começam como uma issue no GitHub, para que a justificação, as alternativas e os compromissos fiquem registados.
Consenso tácito. Uma proposta sem oposição sustentada após um tempo razoável, e que satisfaça o limiar técnico abaixo, avança.
O responsável decide em caso de desacordo. Quando não se chega a consenso, o responsável decide e regista o motivo. O desacordo é resolvido pela missão e pelo limiar técnico, não pela antiguidade nem pelo volume.

O limiar técnico (não negociável)#

Estes são invariantes rígidos, aplicados pela CI e pela revisão, que nenhuma decisão revoga:

Reproducibility. (scenario, seed, engine_version) tem de reproduzir uma execução bit a bit. Uma alteração que torne isto não determinista é um erro, não uma funcionalidade.
Proveniência. Sem constantes numéricas anónimas — cada parâmetro cita uma fonte.
Honestidade na validação. Cada capacidade é rotulada validated (face a uma referência independente externa) ou modelled / not modeled. Nada é afirmado para além da sua evidência. Ver a matriz verificada por máquina em src/verification.rs.
Higiene. Nenhuma atribuição de ferramentas automáticas em lado nenhum nos commits, no conteúdo ou no histórico (aplicado por scripts/check-no-attribution.sh).

Uma alteração que não consiga satisfazer o limiar é recusada, por mais útil que seja.

A fronteira entre o aberto e o fechado#

O Kshana tem núcleo aberto (open-core). Este repositório é, e continuará a ser, o motor AGPL-3.0 aberto completo — a referência neutra, com licenciamento duplo comercial pela Ashforde OÜ (ver LICENSING.md). O projeto não aceitará no repositório aberto:

Profundidade sujeita a controlo de exportação ou de dupla utilização — bibliotecas de ameaças reais, formas de onda de adversários ou parâmetros de desempenho antijamming/antispoofing. O repositório público limita-se a modelos e métodos genéricos e publicados (ver CONTRIBUTING.md → Controlo de exportações). Em caso de dúvida, pergunte antes de contribuir.
Dados ou calibração confidenciais de clientes ou parceiros.
Dependências com copyleft (GPL/AGPL/LGPL/MPL) — não porque entrem em conflito com a própria licença AGPL do motor (não entram), mas porque não podem ser relicenciadas na edição comercial: só podemos vender uma licença comercial sobre código que possuímos ou que seja permissivo. Uma dependência com copyleft contaminaria a edição comercial e quebraria o licenciamento duplo. As dependências mantêm-se, por isso, permissivas (Apache/MIT/BSD/ISC), o que é aplicado por deny.toml.

Inversamente, o projeto não esvaziará o núcleo aberto para empurrar valor proprietário: o motor validado, as âncoras públicas de validação, o registo de honestidade, o formato de intercâmbio/padrão e os canais de distribuição permanecem abertos. Estrangular o núcleo aberto é o único erro fatal do open-core, e está fora de questão.

Versões#

Semantic Versioning. Antes da 1.0, o esquema de cenários/resultados pode mudar; as alterações que quebram a compatibilidade são assinaladas, e a versão do esquema de intercâmbio (src/interchange.rs::SCHEMA_VERSION) é a única fonte de verdade para a compatibilidade dos artefactos.
Autoridade de publicação. Publicar (por exemplo, cargo publish) é um passo manual do responsável pela manutenção que exige um token de registo. A CI e o fluxo de trabalho Release, ativado por etiqueta, nunca publicam automaticamente em registos externos — limitam-se a voltar a executar todas as verificações e a anexar um artefacto de compilação. Ver CONTRIBUTING.md → Commits e versionamento.

Código de conduta e segurança#

A conduta é regida por CODE_OF_CONDUCT.md.
As questões de segurança seguem o processo de divulgação privada em SECURITY.md — não abra uma issue pública para uma vulnerabilidade.

Marca registada#

O nome e o logótipo do Kshana são marcas registadas da Ashforde OÜ. A licença (AGPL-3.0, ou uma licença comercial) abrange o código, não as marcas: um fork pode usar o código ao abrigo da licença, mas não o nome Kshana nem a identidade canónica de distribuição. Isto mantém a Ashforde como a fonte de verdade citada e faz parte da forma como o núcleo aberto se mantém uma referência neutra.

Alterar este documento#

As alterações à governação são elas próprias propostas como pull request e decididas pelo processo acima. À medida que a escala do projeto mudar, é de esperar que este documento ganhe um modelo de decisão com vários responsáveis; não reduzirá o limiar técnico.

Leve por conceção. Honesto quanto ao presente, com um caminho declarado para o futuro.