OpenLinkSoftware/ai-agent-skills

Site a Partir do WebDAV

Use esta habilidade para pegar um site estático, já gerado HTML/CSS/JS — a saída de um pipeline RDF-Turtle + SHACL + Jinja2, como sites/openlink/rdf/build.py — e publicá-lo na raiz WebDAV do Virtuoso com uma rota pública mapeada. O modelo de conteúdo do site (ontologia, formas SHACL, ordenação) é criado e validado a montante desta habilidade; o trabalho desta habilidade começa em "aqui está uma pasta generated/ com HTML pronto, coloque-o ao vivo."

Isso é deliberadamente mais restrito que weblog-from-webdav ou osdi-inclusion-engine: essas habilidades renderizam conteúdo ao vivo a cada requisição (enumeração de coleção WebDAV dentro de um VSP personalizado, ou uma skin XSLT compartilhada envolvendo HTML do WebDAV). O conteúdo desta habilidade já está totalmente renderizado antes de chegar — publicá-lo é um simples PUT no WebDAV mais um VHOST_DEFINE de arquivo estático, sem execução de VSP e sem consulta SPARQL ao vivo. Veja references/webdav-website-engine-gate.md para saber por que essa escolha foi feita e quando ela mudará.

Portão de Bloqueio — Um Arquivo Local Não É uma Conclusão Válida

Quando o usuário pede para publicar, implantar ou "colocar ao vivo" um site gerado, uma descrição do que aconteceria, ou uma afirmação de que os arquivos existem localmente, não é uma conclusão válida a menos que o usuário peça explicitamente apenas uma verificação local/prévia. O resultado padrão é:

• um site ao vivo, verificado: a rota alvo retorna o mesmo conteúdo que a saída local de generated/, ou
• um pacote implantável completo: generated/*.html, os assets/ do site (site.css, theme.js), um templates/deploy-website-route.sql com caminhos substituídos e um README/arquivo de instruções — com scripts/validate_generated_website_bundle.py passando nele.

Leia references/webdav-website-engine-gate.md antes de reivindicar qualquer um deles. Se as credenciais de implantação (WebDAV e/ou isql) não estiverem disponíveis, pare no pacote implantável e diga claramente que a publicação ao vivo está bloqueada pela falta de acesso autenticado — não descreva sucesso hipotético.

Primeiras Decisões

Estabeleça estes itens antes de publicar qualquer coisa:

• Diretório fonte do pipeline (por exemplo, {LLM_ROOT}/Claude Generated/sites/openlink/) e se rdf/build.py precisa ser executado (ou reexecutado) primeiro, ou se generated/ já está atualizado.
• Coleção DAV de destino, por exemplo, /DAV/home/kidehen/sites/openlink/.
• Rota pública, por exemplo, https://linkeddata.uriburner.com/sites/openlink/.
• Modo de identidade: usuário/senha SQL, isql WebID-TLS, WebID-TLS com delegação, usuário/senha WebDAV, WebDAV mTLS, ou WebDAV mTLS com On-Behalf-Of.
• Se esta é uma configuração inicial de rota (isql + deploy-website-route.sql obrigatório) ou uma republicação de conteúdo em uma rota existente (apenas publicação WebDAV, conforme references/webdav-publish-mode.md — nunca toca na configuração de rota).

Fluxo de Trabalho

1. Confirme que a saída generated/ fonte está atualizada: se solicitado a (re)construir, execute o próprio rdf/validate_shacl.py do pipeline e depois rdf/build.py sem alterações — esta habilidade não reimplementa nem ignora essa validação. Veja references/rdf-content-mode.md.
2. Antes de escrever qualquer coisa, pesquise na memória/trabalho anterior por validate_generated_weblog_bundle, VHOST_DEFINE, DAV_RES_UPLOAD_STRSES_INT, website-from-webdav; reutilize correções comprovadas em vez de redescobri-las.
3. Determine se a rota alvo já existe (consulte DB.DBA.HTTP_PATH e WS.WS.SYS_DAV_RES para o caminho alvo via isql). Se não, configure-a: ajuste templates/deploy-website-route.sql com o caminho/rota/título DAV real e execute-o com isql. Veja references/isql-route-mode.md.
4. Valide o pacote com scripts/validate_generated_website_bundle.py antes de qualquer publicação. Isso é bloqueante.
5. Publique via WebDAV usando scripts/publish_static_bundle.py — faz PUT recursivo de generated/*.html e assets/*, verifica cada escrita com um GET/PROPFIND de acompanhamento. Veja references/webdav-publish-mode.md.
6. Verifique: busque a rota ao vivo, confirme que os bytes servidos correspondem ao arquivo generated/ local (permitindo apenas diferenças de espaços em branco/ordem de atributos, mesma tolerância que a verificação da Fase 1 do próprio pipeline usa), confirme que assets/site.css/theme.js carregam com tipos MIME corretos.
7. Relate exatamente o que aconteceu: rota configurada ou reutilizada, arquivos publicados com seus caminhos DAV, resultado da verificação — ou, se as credenciais estavam faltando, o local do pacote implantável e a declaração explícita de que a publicação ao vivo não ocorreu.

Referências de Modo

• Para configuração de rota e sintaxe isql TLS/WebID, leia references/isql-route-mode.md.
• Para publicação WebDAV e sua fronteira de escopo, leia references/webdav-publish-mode.md.
• Para a fronteira do pipeline (o que esta habilidade faz e não toca em rdf/), leia references/rdf-content-mode.md.
• Para saber por que a renderização ao vivo SPARQL/VSP não foi escolhida, leia references/webdav-website-engine-gate.md.
• Para operações acionáveis por agente, leia references/opal-tool-mode.md — não implementado na v1; documentado como ponto de extensão.

Salvaguardas Práticas

• Nunca execute a validação SHACL de rdf/build.py com avisos suprimidos ou atalhos do tipo --skip-validate; uma barreira falhando significa que o conteúdo não está pronto para publicar, não um obstáculo a ser contornado.
• DB.DBA.DAV_RES_UPLOAD_STRSES_INT (se usado para qualquer etapa que não seja de arquivo estático) precisa de um fluxo string_output() preenchido via http(content, stream), não uma string simples.
• Evite $1, $2 e tokens semelhantes em qualquer SQL carregado via isql; eles podem acionar substituição de macro.
• Um VHOST_DEFINE para arquivo estático usa is_dav=>1, is_brws=>0, def_page=>'index.html' — não defina def_page=>'index.vsp' a menos que um ponto de entrada VSP realmente exista; um def_page apontando para um recurso VSP inexistente serve código fonte bruto ou um 404, não o site.
• Exclua qualquer VHOST_DEFINE anterior conflitante para o mesmo host/caminho antes de redefini-lo, igual ao padrão de remover-rote-depois-redefinir de weblog-from-webdav.
• Trate a identidade portadora do certificado e o principal delegado como fatos separados: -X/--cert identifica o agente chamador, -W/On-Behalf-Of identifica o principal WebID cujos direitos ACL devem ser avaliados.
• Nunca escreva credenciais na habilidade, SQL gerado, logs ou arquivos commitados.
• Uploads e remoções remotas seguem a mesma ordem HTTP → WebDAV → iSQL e padrão PKCS#12 de principal (howto/remote-webdav-upload.ttl, howto/remote-resource-removal.ttl, Prefs Passos 215–216). Escritas/remoções no URIBurner vão para a porta 5443. Relate GET :5443 e GET público 443 separadamente após PUT; após DELETE, verifique a URL nomeada pelo usuário, variantes de barra, GET :5443 e a listagem da pasta antes de afirmar a remoção.

Saída de Erro Segura do ISQL Virtuoso

Sempre que este fluxo de trabalho invocar o cliente isql nativo do Virtuoso OpenLink, passe a opção COMMAND_TEXT_ON_ERROR=OFF, por exemplo isql {host}:{port} {user} {password} COMMAND_TEXT_ON_ERROR=OFF {script.sql}. Coloque-a antes da entrada SQL, argumentos de script ou -i. OFF mapeia para o valor interno 0 do cliente e impede que o cliente anexe o comando falho completo à saída de erro. O cliente aceita OFF/ON; o literal 0 é rejeitado. Não use -u para esta configuração (-u preenche a matriz de argumentos U). Isso não oculta segredos de diagnósticos do servidor, histórico do shell ou argumentos de processo, portanto mantenha credenciais fora do texto SQL e dos logs. Não aplique esta opção específica do Virtuoso a clientes isql unixODBC/iODBC.