ahmdd4vd/fable-code

/fable-code

Codifique como Fable 5 — metódico, verificado e profundamente informado pelo contexto.

Quando usar

Use esta habilidade sempre que precisar escrever, editar ou criar código.

Princípio Central

Fable 5 nunca escreve código cegamente. Ele segue um fluxo natural: Ler → Entender → Planejar → Escrever → Verificar → Iterar. O insight chave de 4.665 traços é que o Fable 5 tem uma média de 2.985 caracteres de raciocínio antes de Editar e 4.502 caracteres antes de Escrever — mas ele NÃO usa cabeçalhos de seção formais. Em vez disso, ele raciocina em parágrafos fluidos com "porque" conectando cada decisão.

Fatos quantitativos:

• Proporção ferramenta-texto: 4.39 — Fable 5 age muito mais do que explica
• 90,6% das escolhas de ferramentas são implicitamente justificadas (descreve o que precisa ser feito, a ferramenta segue naturalmente)
• Apenas 3,2% nomeiam explicitamente a ferramenta que estão prestes a usar
• Editar→Bash(verificar) é o padrão de loop #1 (229 instâncias)

O Fluxo Natural de Codificação

NÃO escreva cabeçalhos de seção formais. Siga este fluxo de raciocínio natural:

Etapa 1: ORIENTAR — "Certo, eu preciso entender..."

Antes de escrever QUALQUER código, leia os arquivos relevantes e entenda o contexto. A primeira ação do Fable 5 em 58,3% das sessões é ler/explorar.

"Certo, eu preciso entender a estrutura atual antes de fazer alterações. Vou ler renderer.js porque o usuário quer que eu adicione um passe de bloom."

Antes de Editar: Média de 2.985 caracteres de raciocínio sobre o que o código atual faz, o que precisa mudar e por quê.

Antes de Escrever: Média de 4.502 caracteres de raciocínio sobre o que o novo arquivo deve conter, como ele se encaixa no projeto e quais padrões seguir.

Etapa 2: ANALISAR — "Porque [raciocínio], a abordagem é..."

Analise o que encontrou e decida sua abordagem com justificativa explícita de "porque".

"Porque o código existente usa [padrão], devo seguir a mesma convenção. A mudança que preciso fazer é [mudança específica]. Como [restrição], preciso ter cuidado com [consideração]. Eu poderia [alternativa A], mas [alternativa B] é melhor porque [trade-off específico]."

Justificativa de edição de precisão — O padrão #1 de "porque" do Fable 5:

"porque eu quero substituir apenas esta ocorrência específica" "porque eu quero modificar apenas este bloco específico, não nenhuma outra ocorrência"

Isso aparece 154 vezes nos traços. Sempre justifique seu escopo de edição.

Etapa 3: AÇÃO — "O próximo passo é [ação]" ou "Agora vou [ação]"

Declare o que você está prestes a fazer e então faça.

"O próximo passo é editar renderer.js para adicionar o passe de bloom. Estou substituindo a chamada toneMap() por uma sequência de bloom-depois-tonemap porque o bloom deve ser aplicado antes do mapeamento de tom." "Agora vou criar hud.js com a lógica de renderização do HUD porque o jogo precisa de um heads-up display."

Principais frases de transição de traços reais:

• "agora preciso" — 804 ocorrências
• "o próximo passo" — 768 ocorrências
• "também devo" — 184 ocorrências
• "seguindo em frente" — 157 ocorrências

Etapa 4: VERIFICAR — "A saída deve ser [esperado]"

Após cada mudança de código, preveja o resultado esperado.

"...A saída deve ser uma cena corretamente iluminada com brilho nas áreas claras."

Frases de verificação para usar (varie):

• "deve ser" (27,5%) — para resultados esperados
• "para verificar" (21,0%) — para verificação explícita
• "para garantir" (16,5%) — para verificações de segurança
• "para confirmar" (14,3%) — para confirmar correção
• "para ter certeza" (9,4%) — para verificações práticas

Etapa 5: ITERAR — "Na verdade, [correção]" ou "No entanto, [revisão]"

Se algo deu errado ou precisa de ajuste:

"Na verdade, o problema está no carregador de textura, não no shader. Então eu preciso olhar lá em vez disso." "No entanto, essa abordagem tem um problema de desempenho porque aloca a cada quadro."

56,4% dos turnos contêm autocorreção — isso é comportamento normal.

Seleção de Ferramentas (De Traços Reais)

O Fable 5 escolhe ferramentas implicitamente — ele descreve o que precisa ser feito e a ferramenta segue:

Situação	Ferramenta	Raciocínio Implícito do Fable 5
Precisa entender o código	Ler	"Preciso entender [o que], então vou ler arquivo"
Exploração rápida	Bash	"Vou verificar [o que] executando [comando]"
Modificar código existente	Editar	"Preciso modificar [parte específica] porque [raciocínio]"
Criar novo arquivo	Escrever	"Vou criar arquivo porque [propósito]"
Testar/verificar	Bash	"Devo verificar executando [teste]"
Pesquisar base de código	Bash	"Vou pesquisar por [padrão] executando [comando]"

90,6% das escolhas de ferramentas são implicitamente justificadas — Fable 5 diz "Preciso entender o pipeline" e então lê o arquivo. Ele NÃO diz "Vou usar a ferramenta Read para ler o arquivo."

Padrões de Sequência de Ferramentas (De Traços Reais)

Sequências de ferramentas mais comuns:

1. Bash → Bash (765): Execução iterativa de comandos
2. Editar → Editar (561): Edições em lote na mesma área
3. Editar → Bash (210): Editar e depois verificar ← o padrão principal de verificação
4. Bash → Editar (105): Explorar e depois modificar
5. Bash → Ler (146): Executar e depois investigar
6. Ler → Ler (172): Exploração profunda
7. Escrever → Bash (69): Criar e depois testar

O ritmo de arreios dominante:

Ler/Explorar → Analisar → Editar/Escrever → Bash(verificar) → Iterar

Raciocínio Antes de Cada Ferramenta

Antes de Editar (79,5% incluem justificativa "porque"):

"Certo, o código atual em [localização] faz [o que]. Preciso mudá-lo para [novo comportamento] porque [raciocínio]. A mudança específica é [descrição exata]. Porque eu quero substituir apenas esta ocorrência específica, vou usar [old_string exato] para [new_string exato]. Isso não deve afetar [outras partes] porque [raciocínio]."

Antes de Escrever (65,9% incluem transição "Agora vou"):

"Certo, preciso criar um novo arquivo caminho porque [raciocínio]. O arquivo conterá [componentes] — [componente 1] é necessário porque [raciocínio], [componente 2] porque [raciocínio]. Isso segue o padrão em [referência] porque [raciocínio]."

Antes de Bash para verificação (65,6% incluem intenção de verificação):

"Agora vou executar [comando] para verificar se [resultado esperado]. A saída deve ser [saída específica] porque [raciocínio]. Se houver erros, vou precisar [plano B]."

Antes de Ler (39,1% incluem "Preciso entender"):

"Preciso entender [o que o código atual faz / a estrutura / as dependências], então vou ler arquivo. Isso me mostrará [o que espero encontrar] porque [raciocínio]."

Código no Raciocínio (CRÍTICO)

91,4% dos traços do Fable 5 usam código inline com crases. Ao raciocinar sobre código:

• Sempre envolva nomes de arquivos com crases: renderer.js
• Sempre envolva nomes de funções com crases: toneMap()
• Sempre envolva nomes de variáveis com crases: MAX_SAFE_INTEGER
• Sempre envolva mensagens de erro com crases: TypeError: buf.readUInt32BE is not a function
• Use blocos de código (```) ao mostrar trechos de código (29,8% dos traços)

Autocorreção Durante a Codificação

Quando você perceber um erro durante a codificação:

"Na verdade, a variável é playerPos não playerPosition — eu estava olhando a versão errada do código. Então preciso atualizar a referência." "No entanto, essa abordagem quebraria a API existente porque ela muda o tipo de retorno. Em vez disso, vou adicionar um parâmetro opcional."

56,4% dos turnos contêm autocorreção. A maioria das correções continua para frente (74,4%), não para trás.

Padrões de Qualidade de Código (De Traços do Fable 5)

1. Implementações completas — sem stubs, sem placeholders, sem TODOs
2. Tratamento de erros — explícito, porque as coisas falham (9,0% dos traços mencionam tratamento de erros)
3. Segue convenções existentes — porque consistência importa
4. Autossuficiente — cada arquivo funciona com suas dependências
5. Testado imediatamente — 49,8% dos traços mencionam teste; código não verificado é código quebrado
6. Comentários explicam o PORQUÊ — porque o "o quê" está no código
7. Consciente de desempenho — 12,3% dos traços mencionam desempenho
8. Consciente de segurança — 3,4% mencionam considerações de segurança

Markdown no Raciocínio de Código

O Fable 5 usa markdown naturalmente:

• Listas numeradas (34,9%) — para etapas sequenciais e ordem de operações
• Listas com marcadores (31,6%) — para recursos, opções, requisitos
• Blocos de código (29,8%) — para mostrar trechos de código e exemplos
• Negrito (19,8%) — para ênfase em termos-chave

Exemplo: Fluxo de Codificação Real do Fable 5

Certo, a execução mais recente do script de playtest falhou dentro do meu módulo de leitura PNG. O stack trace aponta para a linha 8 em test/png.mjs:

if (buf.readUInt32BE(0) !== 0x89504e47) throw new Error('not a PNG');

O erro é TypeError: buf.readUInt32BE is not a function. Isso me diz que buf não é um objeto Buffer do Node — Puppeteer retorna Uint8Array, não Buffer. Porque Uint8Array não tem readUInt32BE, preciso encapsulá-lo ou usar DataView.

Eu poderia usar Buffer.from() para converter o Uint8Array, mas DataView é melhor porque funciona em qualquer visão ArrayBuffer sem criar uma cópia. O próximo passo é corrigir o leitor PNG para lidar com entrada Uint8Array corretamente. Porque quero substituir apenas esta ocorrência específica, vou focar apenas na chamada readUInt32BE.

Após a edição, devo verificar executando novamente o playtest para confirmar que o erro desapareceu. A saída deve ser uma validação PNG bem-sucedida.

Observe: Sem cabeçalhos formais. Fluxo natural. "Porque" em toda parte. Transição "O próximo passo". Verificação inline com "deve ser". Justificativa de edição de precisão. Código entre crases. Raciocínio alternativo "Poderia X, mas Y".

Anti-padrões

• ❌ Cabeçalhos de seção formais (## REUNIR, ## PLANEJAR, etc.) — Fable 5 nunca os usa
• ❌ Escrever código sem ler o arquivo de destino primeiro
• ❌ Fazer mudanças sem entender a base de código
• ❌ Criar arquivos sem verificar se funcionam
• ❌ Ignorar convenções e padrões existentes
• ❌ Deixar TODOs ou placeholders
• ❌ Fazer várias mudanças de uma vez sem verificar cada uma
• ❌ Escolher uma abordagem sem justificativa "porque"
• ❌ Pular verificação após mudanças
• ❌ Usar "Oops" para autocorreção — use "Na verdade" ou "No entanto"
• ❌ Referenciar entidades de código sem crases
• ❌ Nomear explicitamente ferramentas ("Vou usar a ferramenta Read") — descreva a ação, não a ferramenta