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): Pest (>90%), PHPStan max, Pint, Infection (MSI>80%), Composer lock e Docker alpine non-root.rust.md): Cargo test, Clippy (-D warnings), rustfmt, cargo-mutants, llvm-cov e Docker scratch estático.shell.md): ShellSpec com kcov, ShellCheck, shfmt determinístico e resolução nativa XDG.javascript.md): Biome/Prettier, Playwright E2E, c8 e lockfiles imutáveis.r.md): testthat, covr, lintr, styler e gestão hermética de dependências com renv (Twelve-Factor R).Nenhuma alteração é iniciada ou finalizada sem rastreabilidade. O fluxo formal divide-se em 5 etapas sequenciais:
Abertura do ticket formalizando o problema, a nova funcionalidade ou refatoração no issue tracker.
Formalização prévia do comportamento e interfaces esperadas antes de codificar.
docs: specify auth endpoint contracts (ref #42)
Criação do teste automatizado reproduzindo o bug ou atestando 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 para fazer o teste passar.
feat: implement token expiration validation (ref #42)
Revisão final dos guias, atualização do changelog e encerramento 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.
Critérios objetivos: teste falho histórico comprovado, código verde, cobertura > 90%, zero mutantes críticos, docs atualizadas e CI verde.
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, Doc, Test, Do): Execução estrita das 5 etapas DD-TDD com commits separados de documentação preliminar e teste falho.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.
O ecossistema Lumen implementa a norma GOST com os seguintes serviços e convenções:
lumenpink/<repo>.cccp com validação de tickets obrigatórios (ref #N / closes #N) e versionamento.src/domain/, src/adapters/ em Rust e src/Domain/, src/Infrastructure/ em PHP) com In-Memory Fakes para testes herméticos.KEY=VALOR, Dockerfile multi-stage com scratch (Rust) e alpine non-root (PHP).site/<lang>/ e roteador cliente em site/index.html.scripts/generate_og_image.py e simulação em site/card_preview.html.shellspec com cobertura via kcov.cargo test, cobertura via cargo-tarpaulin/llvm-cov (>90%) e mutação com cargo-mutants.pest --coverage --min=90 e mutação com infection.playwright para navegação e cenários de interface.clippy -D warnings, cargo fmt, phpstan max, pint e shellcheck.wrangler.jsonc servindo subdomínios *.2lp.in (com fallback no Codeberg Pages).~/src/catalog.json.Consulte o documento completo em profiles/lumen.md no repositório.