Pular para o conteúdo principal

Document Lifecycle Standard

Todo documento da biblioteca tem exatamente um estado, declarado no frontmatter (status). Documento antigo nunca pode parecer atual: o estado é explícito, não implícito.

1. Estados​

EstadoSignificadoPode ser citado como regra?
DRAFTEm construção. Conteúdo pode mudar sem aviso.Não
REVIEWConteúdo completo, aguardando revisão/aprovação humana.Não — apenas como proposta
APPROVEDAprovado pelo owner. É a regra/verdade vigente.Sim
SUPERSEDEDSubstituído por versão ou documento mais novo. Mantido como histórico.Não — apontar o sucessor
ARCHIVEDFora de uso, sem sucessor. Mantido por rastreabilidade.Não

2. Transições​

DRAFT → REVIEW        autor considera completo
REVIEW → APPROVED     somente com aprovação humana do owner (nunca automática, nunca por agente de IA)
REVIEW → DRAFT        revisão devolveu com mudanças estruturais
APPROVED → SUPERSEDED nova versão/documento aprovado assume; o novo linka o antigo
APPROVED → ARCHIVED   assunto deixou de existir; registrar motivo no commit

Regras:

  1. Nenhum agente de IA muda um documento para APPROVED. Agentes produzem DRAFT/REVIEW; aprovação é humana.
  2. Ao aprovar: definir version, atualizar last_reviewed, commit com descrição do que foi aprovado.
  3. Ao supersedar: o documento antigo recebe status: SUPERSEDED e canonical: false; o novo recebe canonical: true. Os dois se linkam.
  4. Documento SUPERSEDED/ARCHIVED não é apagado — Git e biblioteca preservam rastreabilidade.

3. Reopen / Revision Rule​

Um documento APPROVED não é "reaberto" sobrescrevendo silenciosamente a versão aprovada.

A última versão APPROVED continua sendo a versão canônica vigente até que a revisão seguinte seja aprovada.

Existem dois caminhos:

3.1 Non-material / editorial change​

Exemplos: typo; formatação; link quebrado; clareza textual sem alterar regra, obrigação, processo ou significado.

Ação:

  • qualquer alteração de conteúdo em documento APPROVED recebe no mínimo PATCH version bump (ex.: v1.1 → v1.1.1). Exceção: metadata puramente operacional que não altera conteúdo publicado, regra, interpretação ou navegação pode ser registrada apenas no Git;
  • revisão pelo document owner;
  • pode permanecer APPROVED após a alteração somente quando o owner confirmar explicitamente que não houve mudança normativa/semântica;
  • registrar a alteração no Git.

3.2 Material / normative change​

Exemplos: mudança de regra; processo; responsabilidade; Gate; estado; critério; permissão; source of truth; obrigação; comportamento operacional.

Ação:

  • criar a próxima versão em DRAFT ou REVIEW;
  • a versão APPROVED anterior continua canônica enquanto a nova está em revisão;
  • exigir aprovação humana;
  • após aprovação: nova versão → APPROVED; versão anterior → SUPERSEDED.

Versionamento:

  • MINOR normalmente: v1.1 → v1.2;
  • MAJOR quando houver mudança estrutural/incompatível: v1.x → v2.0.

3.3 Regra central​

EDITING ≠ APPROVED.

THE LAST APPROVED VERSION REMAINS CANONICAL UNTIL ITS SUCCESSOR IS APPROVED.

Se houver dúvida se uma alteração é editorial ou material: CLASSIFICATION=UNKNOWN e tratar como MATERIAL até decisão do owner.

4. Comportamento de SUPERSEDED​

SUPERSEDED significa:

  • não é mais a regra vigente;
  • permanece preservado para histórico/auditoria;
  • aponta para a versão sucessora quando possível;
  • não deve aparecer como documentação operacional vigente no Docusaurus (fica fora da navegação operacional padrão; acessível como histórico).

5. Comportamento de ARCHIVED​

ARCHIVED significa:

  • documento não é mais parte ativa do sistema;
  • não possui sucessor obrigatório;
  • permanece preservado para histórico;
  • não deve aparecer na navegação operacional padrão do Docusaurus.

6. Owner / Aprovação​

Enquanto a Régua tiver operação founder-led:

Document Owner = Founder / Régua, salvo definição explícita diferente.

A aprovação humana do owner é suficiente para documentos institucionais de baixo/médio risco.

IA pode: propor; editar; revisar; executar checks.

IA não pode tornar um documento APPROVED por conta própria.

High-risk documents​

Um documento é HIGH RISK para aprovação quando altera materialmente: segurança; privacidade/dados; produção; obrigação legal/regulatória; regra financeira crítica; source of truth; permission model; Gate institucional; ou política que possa causar impacto operacional irreversível ou difícil de reverter.

Para HIGH RISK:

  1. revisão independente deve existir antes da aprovação;
  2. findings críticos/importantes devem estar resolvidos ou explicitamente aceitos;
  3. Founder / Document Owner continua sendo o aprovador humano final;
  4. IA pode executar a revisão independente, mas não pode conceder APPROVED.

Sem comitê; sem segundo aprovador humano obrigatório neste estágio founder-led. Objetivo = review adicional, não burocracia.

Se houver dúvida: RISK_CLASSIFICATION=UNKNOWN → tratar como HIGH RISK até classificação do owner.

7. Estado atual da biblioteca (2026-09-17)​

  • Documentos de Governança v1.1, Método v1.0, Templates v1.0 e Visual System v1.0: APPROVED (governança re-aprovada via REGUA_DOCS_GOVERNANCE_PATCH_v0.1).
  • Documento Institucional v1.0: APPROVED, canonical: true (aprovação humana do Founder / Régua em 2026-09-17, após revisão de conteúdo).
  • Documento Fundador v0.1: SUPERSEDED pelo Documento Institucional v1.0.
  • Este Document Lifecycle Standard: APPROVED v1.0 (aprovação humana do Founder / Régua em 2026-09-17, registrada no commit correspondente).
  • Documentation Standard v1.0 e Naming & Versioning Standard v1.0: APPROVED, canonical: true (aprovação humana do Founder / Régua em 2026-09-17, condicionada e confirmada: apenas formalizam regras já aprovadas/enforçadas pelo docs:check).
  • Runbooks e páginas de navegação: REVIEW (fora do escopo do lock; evoluem pelo lifecycle).