Os prompts seguintes são exemplos reconstruídos para a aula, não conversas originais de desenvolvimento. Não incluem código, chaves, configurações ou pormenores de implantação. Usar ferramentas disponíveis e autorizadas, ou papel. Sem IA, desenhar fluxos e critérios primeiro, sem esperar pelo docente. Reuniões também podem discutir exemplos fictícios.
Um percurso de desenvolvimento reutilizável
Pessoa e situação → fluxo mínimo → versão com material fictício → tarefa no dispositivo → obstáculos → uma revisão e novo teste → experiência voluntária → decisão por evidências.
É possível começar um protótipo com IA e recursos existentes antes de concluir o estudo de Android/iOS. Continua necessário aprender, conforme a tarefa, permissões e estados, API e custos, armazenamento e recuperação, autorização e verificação. Empacotamento, assinatura, instalação e disponibilidade do serviço precisam de testes reais. O caso usou experiência anterior, não nasceu instantaneamente sem conhecimento.
Tarefa 1 | Dar espaço à fala
«Ajuda-me a desenhar um protótipo mínimo de registo por voz. A pessoa quer falar devagar, sem começar por escrever um artigo. Usa uma pergunta quotidiana fictícia e só perguntar, responder, pausar e guardar. Explica estados e critérios antes da implementação. Sem contas reais, gravações privadas ou câmara automática. Assinala permissões, custos e falhas que preciso de confirmar.»
Verificar: ouve-se primeiro a pergunta? A pausa interrompe mesmo? O guardado reaparece? Uma falha explica a situação sem apagar conteúdo confirmado?
Tarefa 2 | Depois de a IA dizer que corrigiu
«Esperado: repetir lê só a pergunta atual. Observado: o telemóvel não emite som. Separa conhecido, desconhecido e três hipóteses testáveis. Propõe reprodução mínima e uma primeira verificação; espera pelo resultado antes de alterar. Não mudes vários módulos juntos. Depois, explica como repetir o teste e os riscos restantes.»
Não copiar logs reais: podem conter identificadores ou credenciais. Praticar reprodução, hipóteses, uma variável e novo teste, não sintaxe ou nomes de frameworks.
Tarefa 3 | Organizar comentários sem decidir por mim
«Resumo fictício: A quer tentar mas não instalou; B bloqueou na instalação; C quer editar e não encontra; D pede temas diários e depois encontra opções existentes. Classifica atitudes, comportamentos, obstáculos e possíveis necessidades. Marca falta de evidência. Sugere uma próxima tarefa observável por caso, sem inferir vendas, terapia ou necessidades de todas as pessoas.»
«Adicionar função» pode significar que uma existente não se encontra. Elogio não é transação; sugestão não confirma necessidade.
Responsabilidade do produto: dados e API
| Problema | O que o estudante deve explicar | Caso e próximo passo |
|---|---|---|
| O que sai do telemóvel | Para onde vão áudio, texto e configurações? Quem acede? | Só fluxo simplificado, sem configurações reais de serviço |
| Para que serve uma Key por pessoa | Ajuda na autorização, quotas e atribuição de custos; faturação separada depende do fornecedor e da conta | Não garante isolamento de registos; atribuir no registo exige tratar concorrência, falta de Keys e revogação |
| Porque não tratar credenciais de administração como definições comuns | O cliente pode ser analisado; ofuscação não é sigilo | A facilidade do teste interno deixa riscos; não é uma solução de segurança madura |
| Como cuidar de um teste pequeno | Dados mínimos, acesso limitado, autorização revogável, recuperação verificada e tratamento de falhas | Isolamento real exige serviços controlados, controlo de acesso, auditoria e outras medidas; não afirmamos ter resolvido tudo |
| Como controlar custos | Quem responde por chamadas, duração, falhas e orçamento? | Universitários usam um orçamento didático hipotético, sem inventar preços. Definir teto e depois testar |
Só responsabilidade e método, sem tabelas administrativas, configurações, credenciais Bot ou extração. Fechar o código é escolha de publicação; não pode ser a única defesa.
Perante ferramentas mais fortes de análise e reconstrução
Até 2026-10-23, só foram lidas descrições e licenças dos repositórios, sem instalação, execução ou teste.
Repositório oficial REA ↗: descreve apoio à análise de comportamento, binários e execução. Descrever capacidade não garante êxito em cada alvo.
Repositório oficial replica-skill ↗: organiza observação, reconstrução e testes como skill. O README defende reconstruir funções e fluxos com materiais próprios, sem copiar código, marca, texto ou conteúdo do alvo.
Ambos indicam atualmente licença MIT. Rever versão, dependências e licença antes de usar.Licença de ferramenta, direitos da app e autorização de acesso são coisas distintas. Slogans de repositórios não são licença legal ou garantia de segurança. Só discutir demonstrações próprias ou autorizadas. Sem conclusões jurídicas nem prática de engenharia inversa.
Quatro perguntas antes de decidir
Posso aceder e analisar? Uso um método, um componente licenciado ou conteúdo alheio? Como indico a origem e verifico? Mesmo com aparência igual, para quem faço, que valores escolho e pelo que respondo?
«O meu núcleo» não é desculpa nem obrigação de escrever todo o código de raiz. É responder pela direção, origem, verificação, pelo que se recusa fazer e pela entrega.