Blueprint e Program do Genesis
Blueprint e Program são explicações mantidas, não provas, propriedade ou um modelo semântico exaustivo.
Blueprint
genesis/blueprint.md é uma descrição curta, coesa e não técnica do que o
produto deve fazer. Prefira a intenção explícita do usuário. Não mencione frameworks,
pacotes, grafia de rotas, esquemas, arquivos fonte, planos de implementação, testes
ou arquitetura privada.
Atualize o Blueprint após a implementação apenas quando a mudança adiciona, remove ou altera intencionalmente o comportamento observável do produto. Nunca transforme um acidente, bug, escolha de design privada ou ambiguidade em intenção do produto.
Program
Organize o Program em diretórios legíveis; a associação é declarada apenas em
genesis/subsystems.md, independentemente dos nomes dos diretórios:
genesis/program/billing/invoices.md
genesis/program/authentication/sessions.md
Crie um módulo para cada operação pública significativa fornecida por um subsistema, independentemente da linguagem ou estrutura de origem. Operações públicas incluem funções ou métodos exportados, ações de API, comandos, operações de UI e outros pontos de entrada observáveis. Não espelhe arquivos fonte nem documente cada auxiliar.
Cada módulo contém:
# Nome de limite legível por humanos
Uma breve explicação de por que o limite existe.
## Fontes
- Principal: `caminho/exato/autoral/da/fonte/principal`
- `caminho/exato/autoral/de/suporte`
## Contrato público
Entradas, saídas, efeitos, falhas e garantias significativas.
Cada módulo requer exatamente um bullet - Principal: de fonte. Escolha a fonte
principal explicitamente como o lugar para começar a ler a implementação; não precisa
ser um ponto de entrada executável. Ela deve pertencer ao subsistema proprietário do módulo,
respeitando proprietários de diretórios aninhados mais específicos. Outras Fontes podem citar
bibliotecas compartilhadas em outros subsistemas. Nunca inferir o arquivo principal da ordem da lista de fontes,
imports ou nomeação de arquivos. Ao reconciliar módulos mais antigos, inspecione a fonte e
marque a âncora explicitamente; a indexação não atribui uma para você.
Um ## Mapa de implementação opcional pode nomear apenas auxiliares privados ou costuras que
materialmente ajudem um agente futuro a alterar, rastrear ou depurar a operação. É
informativo, não uma garantia pública. Testes são evidência e nunca Fontes de implementação.
Prefira menos módulos, mais claros. Remova explicações obsoletas e duplicadas. Uma fonte pode suportar várias operações; arquivos auxiliares e de cola podem não aparecer em nenhum módulo do Program.
Limites da tarefa
O solicitante determina se é descrição inicial, renovação completa do Program, reconciliação focada pós-mudança, trabalho apenas no Blueprint ou revisão somente leitura. Respeite o limite de edição do solicitante. Reporte ambiguidade em vez de inventar intenção.
Subsistemas
Mantenha genesis/subsystems.md junto com o Program em trabalho de descrição e
renovação. Trabalho apenas no Blueprint não altera o mapa; revisão permanece somente leitura.
O mapa é a autoridade de associação autoral, mas responsabilidades e referências de tabela
permanecem explicações falíveis do código-fonte e esquema da aplicação.
Use esta gramática exata de versão zero:
# Subsistemas
## `forms` Formulários
Possui renderização, validação e captura de submissão de formulários reutilizáveis.
### Fonte
- Diretório `packages/forms`
### Program
- `genesis/program/forms/render.md`
### Dados próprios
- Tabela `database` `default` `form_definitions`
### Dados usados
- Nada.
Use um id estável em minúsculas com hífen e um título legível por humanos por subsistema. Cada
entrada precisa de prosa de responsabilidade e as seções Program, Dados próprios e Dados usados.
A prosa de responsabilidade é a explicação completa do subsistema, não uma legenda de mapa.
Explique seu propósito, escopo, partes importantes e colaboração com outros proprietários.
Preserve descrições substantivas existentes; não as substitua por rótulos de uma linha
para adequar a uma visualização. Um consumidor pode encurtar a pré-visualização exibida.
Diretórios simples de suporte podem precisar apenas de uma explicação curta.
A seção Fonte requerida contém exatamente uma entrada - Diretório com um caminho entre acentos graves: um
diretório canônico relativo ao projeto, com . permitido para a raiz do projeto.
Cada subsistema tem uma raiz de diretório; nunca declare raízes dispersas ou múltiplas.
Regras de diretório pai empilhado descobrem raízes de subsistema padrão, mas não são
exaustivas. Um agente pode reconhecer e declarar outra raiz em outro lugar a partir de
responsabilidade real e evidência de origem. A declaração autoral persiste através de
indexação comum. O mapa autoral é a lista de proprietários canônica uma vez pronta; raízes da Stack são dicas
de adoção e nunca criam proprietários adicionais ou dividem um limite autoral. Cubra toda
fonte indexada, usando um proprietário de raiz do projeto para arquivos de suporte restantes, se necessário. Componentes de UI e código Engine podem
compartilhar uma raiz; projeção de UI não muda a propriedade. Seções
vazias dizem - Nada.; um mapa vazio novo contém apenas # Subsistemas e
- Nada.. Cada módulo do Program pertence a exatamente um subsistema. Nomes de diretório do Program não atribuem propriedade. Fontes podem citar bibliotecas de
outro subsistema sem dar à operação ou implementação dois proprietários.
Não use globs, operações duplicadas ou proprietários de tabela duplicados.
Ao regenerar ou deliberadamente dividir o mapa, reconcilie as explicações com os novos proprietários de diretório. Transfira a prosa de responsabilidade aplicável e as atribuições explícitas do Program juntas, preservando ids estáveis onde o limite não mudou. Reverifique a fonte principal necessária de cada Program contra seu proprietário atual, incluindo proprietários aninhados; referências de biblioteca mantêm sua própria propriedade. Use as declarações atuais em vez de nomes codificados de um consumidor anterior, layout de diretório ou lista em cache. Inspecione subsistemas e Program e resolva associação faltante/duplicada e âncoras principais inválidas antes de reivindicar conclusão.
Uma identidade de tabela são três valores separados exatos entre acentos graves: o id do recurso Stack declarado,
esquema e tabela. default significa o esquema padrão do recurso;
use um esquema explícito quando aplicável. Nunca registre um nome de banco de dados hospedeiro,
credencial, expressão SQL ou valor de ambiente. Dados usados referencia uma tabela
possuída por outro subsistema declarado. Um subsistema pode possuir dados sem operações do Program,
ou operações sem dados. Leia o esquema/migrações reais antes de
atribuir propriedade; reporte incerteza em vez de inventar associações.
Mantenha genesis/subsystems.md na mesma rodada de implementação quando uma mudança
adicionar, remover ou alterar uma responsabilidade de subsistema, associação do Program ou
propriedade/uso de dados. Leia o mapa antes de alterar código relacionado. Reutilize
subsistemas existentes a menos que uma responsabilidade distinta seja evidenciada. Declare cada módulo do Program
exatamente uma vez; pastas não determinam associação. Mantenha referências de tabela
fundamentadas em esquema/migrações; Genesis não inspeciona bancos de dados. Mudanças
em auxiliares privados não precisam de edição no mapa quando essas associações permanecem inalteradas.
Se genesis/subsystems.md estiver faltando, ou estiver vazio em uma aplicação
explicada existente, crie-o a partir da fonte real, esquema e Program
existente antes da implementação. Isso é adoção explicativa comum, não um bloqueio ou
uma razão para pedir permissão novamente. Preserve o Program e a fonte existentes;
inspecione as responsabilidades relevantes e complete o menor mapa verdadeiro.
A inicialização pode criar o arquivo vazio, mas apenas o agente autor sua significado.