Padrão universal para arquitetura de repositórios, ciclo de desenvolvimento e documentação pública.
O GOST orienta a criação de software livre com clareza jurídica e técnica desde o primeiro commit.
Todo repositório deve presumir dedicação direta ao domínio público (CC0-1.0 Universal), eliminando atrito para cópia, reuso e evolução coletiva com salvaguarda jurídica internacional.
Projetos com salvaguarda explícita contra mercantilização predatória ou fechamento de código adotam a GNU GPLv3.
Todo repositório aderente à especificação mantém uma base uniforme previsível:
.
├── GOSTVER # Declaração da norma e perfil (ex: GOST_VERSION="1.0.0")
├── LICENSE # Licença declarada (CC0-1.0 como padrão)
├── VERSION # Versão SemVer pura em texto simples (ex: 0.1.0-dev.1)
├── CHANGELOG.md # Histórico no padrão Keep a Changelog
├── README.md # Resumo executivo e instrução de partida
├── .gitignore # Regras de higiene de arquivos
├── .editorconfig # Configuração canônica de formatação
├── site/ # Portal estático de documentação pública
│ ├── index.html # Interface de visualização da documentação
│ └── _headers # Cabeçalhos HTTP de segurança obrigatórios
└── .forgejo/ / .github/ # Workflows declarativos de CI/CD
└── workflows/ci.ymlAplicações que adotam o GOST não copiam a norma técnica. Elas utilizam seu próprio SPEC.md para descrever as regras de negócio e interfaces do projeto (criado na Etapa 2 do DD-TDD), enquanto declaram conformidade com o GOST através do arquivo GOSTVER na raiz.
Para não poluir o repositório nem sobrecarregar o contexto de agentes de IA com regras de stacks não utilizadas, o GOST provê especificações técnicas modulares isoladas em specs/languages/:
php.md): PHP 8.5+ com suporte reverso a 8.2, Pest (>90%), PHPStan max, Pint, Infection (MSI>80%), Composer lock e Docker alpine non-root.rust.md): Rust 1.99 (Edição 2024), Cargo test, Clippy (-D warnings), rustfmt, cargo-mutants, llvm-cov e Docker scratch estático.shell.md): POSIX /bin/sh e Bash 5.2+, ShellSpec com kcov (>90%), ShellCheck zero warnings, shfmt determinístico e XDG.javascript.md): Node.js 24 LTS, ESM nativo, TypeScript 5.8+, Biome canônico, Vitest/Playwright e c8.r.md): testthat, covr, lintr, styler e gestão hermética de dependências com renv (Twelve-Factor R).Nenhuma alteração de código ocorre sem ticket e documentação prévia. O fluxo formal divide-se em 9 etapas sequenciais e indivisíveis:
Abertura do ticket formalizando o problema, a nova funcionalidade ou refatoração no issue tracker. Proibido alterar arquivos.
Criação da branch dedicada a partir de develop ou main no padrão padronizado.
git checkout -b feat/42-auth-jwt
Formalização antecipada do contrato, interfaces e diagramas. Zero código de produção nesta etapa.
docs: specify auth endpoint contracts (ref #42)
Criação do teste automatizado reproduzindo o bug ou comprovando a falta da feature. O teste deve falhar.
test: add failing integration test for token expiration (ref #42)
Desenvolvimento da solução estritamente necessária e suficiente para fazer a suíte passar no verde.
feat: implement token expiration validation (ref #42)
Refatoração do código de produção visando Clean Code, nomes expressivos e zero warnings no linter. Testes continuam 100% verdes.
refactor: optimize token expiration validation (ref #42)
Execução de testes de mutação para blindar asserções e introduzir testes até exterminar 100% dos mutantes críticos.
test: eliminate surviving mutants in token validation (ref #42)
Auditoria local rigorosa: linters com -D warnings, formatação determinística e cobertura mantida comprovadamente ≥ 90%.
Revisão final dos guias e vitrine, consolidação do changelog e encerramento formal do ticket.
docs: update authentication documentation (closes #42)
Cláusula pétrea: nenhum commit existe sem issue aberta. Commits intermediários exigem (ref #N) e o final exige (closes #N). Hooks locais bloqueiam commits soltos.
Proibido commitar na main. Desenvolvimento sempre em branches dedicados: feat/<id>-slug ou fix/<id>-slug.
A fase de documentação/contrato precede qualquer código. Na etapa de doc, é expressamente proibido alterar código de produção.
Para mitigar ações não autorizadas e acelerar o fluxo entre humanos e agentes autônomos, o GOST padroniza comandos operacionais diretos:
DCPD (Do, Commit, Push, Deploy): Execução completa de ponta a ponta com testes, commit com (closes #N), push, merge na main e deploy contínuo.DCP (Do, Commit, Push): Implementação e push restrito à branch da feature, mantendo o PR aberto no Codeberg para revisão humana prévia.PLAN (Plan & Propose): Diagnóstico e formulação de proposta sem modificar arquivos de código e sem commitar.TDD (Ticket, Branch, Doc, Red, Green, Refactor, Mutate, Gate, Close): Execução sequencial estrita das 9 fases DD-TDD com isolamento em branch, contratos prévios, testes de mutação e auditoria local.AUDIT (Audit & Check): Auditoria passiva de linters (-D warnings), testes, cobertura (≥90%), mutantes e segurança.FIX (Fix & Clean): Saneamento técnico de avisos de análise estática e formatação sem alteração de regra de negócio.RELEASE (Release & Tag): Bump semântico no VERSION, consolidação do changelog e publicação de tags Git via cccp.A norma exige validação automatizada em camadas com asserções rigorosas e cobertura permanentemente mantida:
Isolamento total de dependências externas para execução instantânea. Validação de regras e contratos de domínio.
Validação de persistência, banco de dados (SQLite), IPC e daemons com fixtures isoladas e auto-destrutivas.
Jornadas completas do usuário em navegadores headless (Chromium, Firefox, WebKit) via Playwright.
Piso obrigatório de 90% com bloqueio imediato no CI para qualquer regressão. Meta ativa de 100% no core.
Validação da eficácia real dos asserts (evitando testes cosméticos) através de injeção sintética de falhas. Execução estritamente hermética no CI, sem dependência de rede pública externa.
A integridade do código exige severidade máxima de linters e formatação determinística antes mesmo dos testes:
Linters e compiladores rodam com tratamento de warnings como erros fatais (-D warnings). Avisos quebram o build imediatamente.
Zero discussões de estilo em code review. Formatadores oficiais estritos no CI (rustfmt, pint, shfmt, prettier/biome com --check).
Arquivo .editorconfig canônico na raiz de todo projeto para impor UTF-8, LF e indentação homogênea entre editores.
Dependências mínimas e justificadas. Auditoria contínua de vulnerabilidades e verificação de hiperlinks quebrados (lychee).
Todo projeto mantém seu portal estático publicado na borda via pipeline de CI. O arquivo site/_headers deve assegurar:
/*
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-originA pasta ./site publicada em *.2lp.in destina-se exclusivamente a documentação e vitrine pública. Segredos e portas dinâmicas nunca são expostos na vitrine.
Serviços locais/daemons utilizam Tailscale (rede privada criptografada ponto a ponto) ou Cloudflare Tunnel autenticado sob subdomínio dedicado.
Aplicações sob sinal oscilante adotam fila assíncrona com idempotência (client_id) e short polling leve contra quebras de conexão.
A norma GOST exige cobertura e paridade de 100% nas 10 línguas oficiais tanto no aplicativo completo (UI, CLI, logs e erros de runtime) quanto na documentação pública (./site). A língua primária é definida no .cccprc e atua como fallback em tempo de execução:
en (English), pt (Português), es (Español), fr (Français), de (Deutsch), it (Italiano), ru (Русский), zh (中文), ja (日本語), ar (العربية).
Declarada via agent_var_lang no .cccprc. Fonte canônica para triagem de tickets e fallback mandatório de strings.
Redirecionamento estático na raiz da documentação via localStorage e navigator.language.
Suporte bidirecional mandatório (dir="rtl") no aplicativo e na documentação para o árabe.
Banners de compartilhamento (Open Graph / Twitter Card) são gerados em 1200x630 com proteção central contra cortes móveis:
Todo conteúdo crítico (título, logo, badge, rodapé) fica confinado no miolo central. Sangrias laterais de 180px a 240px blindam contra o recorte 1:1 (quadrado) do WhatsApp.
og:title: 50 a 65 chars (máx 70).og:description: 120 a 155 chars (máx 160).
Badge na imagem: máx 35 chars.
Título na imagem: máx 40 chars.
O GOST orienta a construção de software com foco no isolamento rigoroso do Core em relação a subsistemas de I/O, hermeticidade em testes e rejeição ao overengineering cerimonial:
O Core (regras e use cases) nunca depende de banco, rede ou frameworks. Interfaces/traits definem as portas de entrada e saída. Dependências apontam sempre para dentro.
Testes de domínio executam em microssegundos em memória pura. Preferência absoluta por Fakes leves em vez de frameworks pesados de mocks dinâmicos frágeis.
Validação estrita na borda externa (adaptadores/controllers). O Core opera com primitivos confiáveis, eliminando Value Objects vazios e anêmicos sem comportamento real.
Proibição de tipos fracos (strings mágicas) para máquinas de estado e transições de ciclo de vida. Uso de enum nativo da linguagem com exaustividade no linter.
A complexidade estrutural deve ser proporcional ao escopo. Micro-ferramentas CLI e scripts simples mantêm estrutura direta sem camadas artificiais; serviços e aplicações complexas segregam Core e Adaptadores.
O GOST impõe conformidade com convenções maduras do ecossistema Unix/Linux e da computação em nuvem para máxima previsibilidade e portabilidade:
Proibição de arquivos soltos na $HOME. Fallbacks canônicos obrigatórios: config em ~/.config, data em ~/.local/share, state/logs em ~/.local/state e runtime sockets em /run/user/$UID.
Hierarquia estrita: Flags CLI > Variáveis de Ambiente > .env local > Config do repositório > XDG Config > /etc > Defaults. Formato plano KEY=VALOR amigável a shell.
Aplicação dos princípios do 12-Factor em qualquer software: dependências explícitas, config no ambiente, processos stateless, port/socket binding, logs como fluxos contínuos e descartabilidade com graceful shutdown.
stdout exclusivo para saída de dados útil encadeável em pipes. stderr para logs, avisos e progresso. Aderência ao padrão NO_COLOR e detecção automática de TTY.
Banimento expresso de SSL/TLS < 1.2 (RFC 8996). Negociação QUIC/HTTP3 > HTTP/2 TLS 1.3. Preferência mandatória por UNIX Domain Sockets para IPC local entre daemons.
Multi-stage builds obrigatórios com bases mínimas (scratch/alpine). Execução estritamente não-root (USER 1000:1000), banimento de :latest, .dockerignore e compose.yaml.
Cabeçalho Authorization: Bearer <key>, suporte à injeção via env ou sufixo _FILE para Docker Secrets e validação timing-safe obrigatória contra ataques de temporização.
A norma GOST estabelece princípios e metas de engenharia rigorosos de forma agnóstica a provedores de nuvem, forjas de código e ecossistemas proprietários. Para operacionalizar essas regras, cada organização ou mantenedor declara suas escolhas concretas de infraestrutura em um Perfil de Implementação:
cccp, husky) com bloqueio estrito de commits sem ticket.act).*.2lp.in.Consulte o modelo canônico de perfil em profiles/template.md e o guia de criação em profiles/README.md.
Para automação do ecossistema, o repositório disponibiliza os utilitários de linha de comando scripts/gost-init.sh (inicialização de projetos) e scripts/gost-conform.sh (auditoria e adequação idempotente), projetados também para incorporação direta no CLI cccp.