Unificar, organizar e finalizar o repositório para entrega em 28/07/2026

[gm64x]

Objetivo

Preparar este repositório para a entrega final do projeto em 28/07/2026.

Tarefas

• Unificar a estrutura e os conteúdos com os demais repositórios do projeto (bcc-guy, guy-tex e guy-vscode).
• Organizar diretórios, arquivos, branches e documentação.
• Remover arquivos obsoletos, duplicados ou temporários.
• Revisar referências, links, submódulos e instruções de instalação/execução.
• Garantir que o conteúdo final esteja atualizado e consistente.
• Executar uma verificação final do repositório antes da entrega.

Prazo

28/07/2026

[gm64x]

Análise do repositório guy-vscode

Este é o repositório principal da implementação: extensão VS Code em TypeScript, webview com React Flow, geração de GFCs para Python e cálculo de métricas. O README.md está relativamente completo, mas há sinais de acabamento pendente no manifesto e nos testes.

Um ponto concreto: o package.json lista eventos de ativação para comandos de exportação (exportCfgAsMermaid, exportCfgAsDot, exportCfgAsAscii, copyCfgJson, exportCfgAsSvg e exportCfgAsPng), mas esses comandos não aparecem na seção contributes.commands nem no README. Isso precisa ser confirmado como funcionalidade implementada, removido como resíduo ou devidamente exposto/documentado. Além disso, o teste atual ainda é o teste de exemplo gerado pelo template do VS Code e não valida nenhuma funcionalidade do GUY.

Sugestão caso os repositórios permaneçam separados

Manter este repositório como produto de software independente e publicável, com:

• código da extensão;
• testes;
• scripts de build e empacotamento;
• exemplos Python;
• documentação de uso e desenvolvimento;
• release contendo o arquivo .vsix da versão entregue.

O bcc-guy deve apenas referenciar o commit/tag final deste repositório como submódulo. O relatório deve apontar para essa mesma versão para garantir rastreabilidade entre implementação, testes e resultados apresentados.

Sugestão caso tudo seja unificado

Mover o conteúdo integral para:

bcc-guy/app/

Preservar package.json, lockfile, configuração TypeScript, testes, assets e scripts dentro dessa pasta. Na raiz do monorepositório, podem existir comandos coordenadores, por exemplo:

npm run app:check
npm run app:test
npm run app:package

O histórico deve ser importado. Após validação, guy-vscode pode ser arquivado com aviso de migração.

Subproblemas

• Confirmar se todos os comandos listados em activationEvents realmente existem e são registrados pela extensão.
• Remover eventos de ativação obsoletos ou adicionar os comandos de exportação em contributes.commands, menus e documentação.
• Substituir o teste de exemplo por testes reais do gerador de GFC.
• Testar ao menos estruturas sequenciais, condicionais, laços, break, continue, return, funções aninhadas e código com erro de sintaxe.
• Criar testes para complexidade ciclomática, contagem de nós/arestas e componentes conectados.
• Validar a correspondência entre nós do grafo e linhas do código-fonte.
• Executar npm run check-types, npm run lint, npm run compile, npm test e npm run package em clone limpo.
• Confirmar que a versão exigida do VS Code (^1.120.0) está correta e disponível no ambiente de avaliação.
• Validar compatibilidade e empacotamento das dependências nativas tree-sitter e tree-sitter-python.
• Verificar se o .vsix instala e ativa corretamente em outra máquina.
• Definir se a versão 0.0.1 representa a entrega final ou se deve ser alterada para 1.0.0/0.1.0.
• Padronizar Guy e GUY no displayName, README, comandos e interface.
• Adicionar licença efetiva ao repositório, não apenas o campo "license": "MIT" no manifesto.
• Documentar limitações conhecidas de forma consistente com o relatório.
• Verificar se todos os recursos descritos no README estão implementados e acessíveis pela interface.
• Remover código morto, arquivos de template, logs, bundles e artefatos gerados indevidamente versionados.
• Criar CI para tipos, lint, build e testes.
• Criar uma release/tag final com o .vsix e instruções de instalação.
• Registrar capturas e resultados usados no relatório a partir da mesma versão final.
• Se houver unificação, adaptar caminhos de build e CI para a pasta app/.

Recomendação

Para o prazo de 28/07/2026, manter este repositório separado é a opção mais segura. O foco imediato deve ser corrigir inconsistências do package.json, criar testes reais mínimos e produzir um .vsix reproduzível. A migração para monorepositório pode ser feita depois da entrega sem comprometer a validação atual.