OfficeCLI Word Form: campos preenchíveis sem linhas falsas

ANÁLISE EDITORIAL

OfficeCLI Word Form é uma Skill documental para orientar agentes na criação de formulários preenchíveis de verdade em arquivos DOCX. Em vez de desenhar linhas e caixas que apenas parecem campos, ela trabalha com controles de conteúdo, campos de formulário e proteção do próprio Word. A curadoria do Bastidores da IA fixou a origem, revisou o conteúdo distribuído e preparou um pacote mínimo. Os comandos descritos aqui não foram executados nem comparados em benchmark nesta publicação.

Aviso sobre a capa: Ilustração editorial exclusiva do Bastidores da IA. Não é captura de tela, documento real, benchmark, selo, certificação nem material oficial do OfficeCLI ou da Microsoft.

O que esta Skill faz de verdade

A Skill ensina um agente a produzir formulários do Word com elementos estruturados. O núcleo são os controles de conteúdo SDT, representados por <w:sdt> no WordprocessingML. Cada campo deve receber alias e tag, para que pessoas e automações consigam reconhecer sua função. A orientação cobre texto comum, data, lista suspensa e caixa de combinação. Para caixas de seleção, a própria fonte registra uma diferença importante: o caminho documentado usa o FormField legado com <w:ffData>, porque o tipo SDT checkbox não está implementado pelo fluxo apresentado.

Ela também aborda MERGEFIELD, útil quando o documento precisa receber dados por mala direta ou por uma etapa de preenchimento posterior. No fim, recomenda aplicar documentProtection com protection=forms, deixando os campos editáveis enquanto o restante do documento fica protegido. Essa proteção deve ser a última mutação estrutural. O objetivo não é decorar um DOCX, mas construir um artefato cujo comportamento possa ser consultado e validado.

O material original pode ser conferido no diretório da Skill fixado no commit e no SKILL.md auditado.

Para quem serve

Serve para equipes que geram contratos, fichas cadastrais, termos, questionários, checklists, relatórios padronizados ou modelos internos no Word. É especialmente útil quando o documento precisa continuar fácil de usar por uma pessoa, mas também precisa expor nomes de campo consistentes para um agente. Jurídico, RH, operações, atendimento, educação e consultorias podem se beneficiar, desde que mantenham revisão humana sobre linguagem, regras e dados.

Ela não substitui um advogado, um especialista em acessibilidade, um responsável por proteção de dados nem a homologação no Microsoft Word usado pela organização. Também não resolve sozinha integrações com assinatura eletrônica, banco de dados ou sistema de protocolo. O valor está em orientar a estrutura do formulário e em tornar a validação menos subjetiva.

Compatibilidade e pré-requisitos

A origem declara suporte do OfficeCLI para Windows, macOS e Linux e afirma que o binário é autocontido, sem exigir uma instalação local do Microsoft Office. Essa declaração está no README fixado. Ainda assim, a compatibilidade real do documento deve ser confirmada no Word, no visualizador e no fluxo de distribuição adotados pela equipe.

O pré-requisito funcional é o binário OfficeCLI obtido separadamente. O pacote local desta página não inclui executável. Ele contém exatamente três arquivos: SKILL.md, LICENSE e ORIGEM.md. Antes de usar, escolha uma pasta de teste, duplique o DOCX de origem, defina onde a saída será gravada e decida quais ferramentas o agente poderá chamar. Consulte a referência oficial de comandos e a referência oficial para Word.

Instalação recomendada

Para a Skill, use o instalador de Skills do seu agente apontando para o diretório fixado, depois revise os arquivos antes de habilitar qualquer ferramenta. Para o OfficeCLI, prefira baixar manualmente a versão aprovada pela página de release v1.0.148. Confirme o nome do ativo, a plataforma, a arquitetura, o editor e a integridade publicada. Faça análise antimalware conforme a política da organização. Evite executar diretamente no PowerShell um instalador remoto encaminhado por pipe, mesmo quando esse atalho aparece na documentação.

A lista oficial de releases ajuda a identificar uma atualização, mas atualizar automaticamente em produção elimina a chance de revisar mudanças. Fixe uma versão por ambiente, documente o hash do binário que sua equipe aprovou e promova a atualização primeiro em documentos descartáveis. O arquivo de segurança do projeto deve entrar na avaliação do fornecedor.

Configuração antes do primeiro uso

Comece escrevendo uma especificação pequena. Liste o nome visível, a tag, o tipo, a obrigatoriedade, os valores permitidos e o texto de ajuda de cada campo. Mantenha nomes de FormField com no máximo 20 caracteres, conforme o alerta da Skill. Evite reutilizar a mesma tag para finalidades diferentes. Para listas, defina opções explícitas e trate a ausência de resposta de forma consciente.

Determine também o modo de proteção. protection=forms restringe edição fora das áreas permitidas, mas não deve ser tratado como criptografia ou controle de acesso forte. Qualquer dado sensível dentro do DOCX continua exigindo armazenamento, compartilhamento e descarte adequados. O texto sobre controles de conteúdo no Word ajuda a entender o modelo, enquanto a estrutura de um documento WordprocessingML esclarece onde esses elementos vivem.

Primeiro uso seguro

Faça uma cópia do arquivo e nunca entregue o original ao processo de teste. A fonte alerta que o OfficeCLI altera documentos imediatamente. Por isso, um comando aparentemente exploratório pode não ser inofensivo. Comece com view forms para visualizar campos e com consultas de leitura. Em seguida, construa um formulário simples com um campo de texto e uma lista. Salve em uma saída nova.

Depois, abra o DOCX no Word e confirme navegação por teclado, rótulos, opções, impressão e comportamento da proteção. Só então adicione datas, caixas de seleção ou MERGEFIELD. Se o comando produzir WARNING: UNSUPPORTED e código de saída 2, pare. A Skill diz que o elemento pode ter sido criado enquanto uma propriedade foi silenciosamente ignorada. Isso é um resultado parcial, não uma aprovação.

Como o fluxo deve funcionar

Um fluxo confiável tem seis estágios. Primeiro, inventaria o documento e preserva uma cópia. Segundo, descreve os campos e seus identificadores. Terceiro, cria os SDTs com alias e tag, além dos FormFields ou MERGEFIELD necessários. Quarto, consulta a estrutura com query sdt e inspeciona o documento com view forms. Quinto, aplica documentProtection por último. Sexto, executa validate e get /, abre o resultado no Word e registra evidências.

A documentação de visualização, a página do comando validate e os workflows oficiais são referências para adaptar o procedimento. Não pule a abertura em um aplicativo real, porque validade estrutural e experiência correta não são a mesma coisa.

Resultado esperado

O resultado deve ser um DOCX que abre sem reparo, mostra cada campo no lugar previsto, permite edição somente onde foi planejado e preserva o restante do conteúdo. Os controles precisam ter identificadores legíveis, as listas devem oferecer as opções esperadas, as caixas devem alternar corretamente e os campos de mala direta devem continuar reconhecíveis.

O registro de entrega deve incluir arquivo de entrada, arquivo de saída, versão do OfficeCLI, commit da Skill, comandos executados, avisos, resultado do validate e teste manual. Se acessibilidade ou compatibilidade com versões específicas do Word for requisito, inclua uma matriz de teste. Para entender os componentes subjacentes, consulte o Open XML SDK.

Permissões, privacidade e riscos

O uso funcional lê e modifica documentos locais. Esses arquivos podem conter dados pessoais, cláusulas confidenciais, endereços, informações médicas, financeiras ou trabalhistas. Limite a ferramenta a uma pasta dedicada, não conceda acesso amplo a unidades compartilhadas e não envie documentos para serviços externos sem base, contrato e aprovação. Verifique também telemetria, retenção e logs do ambiente em que o agente roda.

raw-set é apresentado como escape para OpenXML avançado. Ele aumenta o poder e o risco, porque permite alterações de baixo nível que podem produzir um pacote válido apenas parcialmente ou incompatível com outro editor. Use somente com especificação, diff e revisão técnica. A proteção de formulário não impede que alguém tecnicamente capaz abra ou altere o XML. Ela melhora a experiência de preenchimento, mas não substitui criptografia, classificação da informação ou permissões do repositório.

O projeto lista componentes de terceiros em THIRD-PARTY-NOTICES. Essa revisão é relevante para uso corporativo e redistribuição.

Erros comuns

O primeiro erro é desenhar sublinhados e quadrados e chamar isso de formulário. Aparência não equivale a campo preenchível. O segundo é omitir alias ou tag, deixando o controle difícil de identificar. O terceiro é tentar caixa de seleção como SDT quando a própria Skill orienta FormField legado. O quarto é aplicar proteção cedo demais e impedir as mutações seguintes.

Também é comum ignorar WARNING: UNSUPPORTED, usar nomes de FormField longos, editar o único exemplar do documento, assumir que validate garante boa experiência e liberar raw-set sem revisão. Outro erro é instalar o binário por comando remoto sem inspecionar release e integridade. Se o modelo existente já usa macros, assinaturas, campos complexos ou extensões proprietárias, faça uma cópia e compare o pacote antes e depois.

Um teste prático deve separar defeito de estrutura, defeito visual e defeito de processo. Estrutura trata da presença dos elementos XML, dos nomes, das tags e da proteção. Visual trata de espaçamento, quebra de página, fonte, contraste e impressão. Processo trata de quem pode gerar, revisar, preencher, aprovar e arquivar o arquivo. Um documento pode passar na primeira camada e falhar nas outras duas. Por isso, registre cada classe de resultado em vez de resumir tudo como funciona ou não funciona.

Para modelos extensos, avance por blocos pequenos. Converta uma seção, consulte os controles, abra no Word e compare com o original. Depois repita na seção seguinte. Esse método torna mais simples localizar uma alteração que removeu estilo, deslocou tabela ou mudou cabeçalho. Também reduz a chance de atribuir ao último comando um defeito inserido várias etapas antes. Se o arquivo contiver macros, mantenha a extensão correta e confirme que o fluxo adotado preserva o conteúdo esperado antes de considerar qualquer entrega.

Campos obrigatórios merecem atenção extra. A aparência de um controle não garante que o Word impeça o envio de uma resposta vazia. Se a regra de negócio exige preenchimento, documente onde essa regra será realmente aplicada e como o erro será mostrado. O mesmo vale para datas, números e identificadores. Um campo pode aceitar texto livre mesmo quando sua etiqueta sugere um formato. Não confunda indicação visual com validação de dados.

Ao revisar uma lista suspensa, verifique ordem, grafia, valor padrão e alternativa para caso não previsto. Ao revisar uma caixa de combinação, determine se texto livre é permitido. Ao revisar checkbox, confirme nome interno, estado inicial e persistência depois de salvar e reabrir. Em MERGEFIELD, teste um conjunto sem valor, um valor longo e caracteres especiais. Esses casos revelam falhas que um exemplo perfeito costuma esconder.

A aprovação final deve comparar o arquivo resultante com critérios escritos antes da execução. Guarde a cópia de entrada, o hash da saída e um resumo dos testes. Se uma nova versão do OfficeCLI, do Word ou da Skill entrar no ambiente, repita a amostra de homologação. O fato de uma versão anterior ter funcionado não comprova que a combinação atual mantém o mesmo resultado. Atualização segura depende de evidência reproduzível, não apenas de confiança no nome do projeto.

Versão, licença e origem verificadas

A origem verificada é iOfficeAI/OfficeCLI, mantida pela organização iOfficeAI. A curadoria fixou o commit 0a450e43389531eadf05510dff209d541c1dec1e, associado à release v1.0.148. Na verificação de 08/09/2026, o repositório tinha 30.324 estrelas e 2.067 forks, não estava arquivado e usava licença Apache-2.0, confirmada no LICENSE fixado.

A Skill não declara versão semântica própria. Por isso, a identificação combina o commit da Skill com a release do projeto. Estrelas e forks são sinais de atenção, não evidência de segurança, adequação ou qualidade. O ZIP local tem SHA-256 6d3d673e1a0fc4c7b4df4a57b13e8114d32270cb363aff8b25377dc731f56475. Ele preserva somente documentação licenciada e o registro de origem, sem executáveis.

Checklist antes de automatizar

• Trabalhe em uma cópia e defina saída separada.
• Fixe commit da Skill e versão aprovada do OfficeCLI.
• Revise release, hash, licença e avisos de terceiros.
• Defina tipo, alias, tag, obrigatoriedade e opções de cada campo.
• Mantenha nomes de FormField com até 20 caracteres.
• Use FormField para checkbox no fluxo documentado.
• Trate WARNING: UNSUPPORTED e saída 2 como bloqueio.
• Aplique protection=forms somente no final.
• Rode view forms, query sdt, validate e get /.
• Abra o DOCX no Word e teste teclado, edição, impressão e proteção.
• Não exponha documentos sensíveis a rede, logs ou serviços não aprovados.
• Registre comandos, avisos, artefatos e aprovação humana.

Se você ainda está organizando o ambiente, veja o catálogo de Skills do Bastidores da IA e escolha um projeto de teste antes de conectar documentos reais.

Fontes primárias

• Repositório oficial OfficeCLI
• Diretório da Skill no commit auditado
• Instruções completas da Skill
• Release v1.0.148
• Comando Skills na wiki oficial
• Referência Microsoft para DocumentProtection