Disciplina de Canal para Contrapartes

O que Disciplina de Canal para Contrapartes faz?

Mantenha a classificação do público, o consentimento de participação e a permissão de envio separados. Esta skill é um contrato de fluxo de trabalho por escrito para o runtime que possui o sistema de mensagens; ela não é um segundo mecanismo de políticas ou uma proteção de transporte executável.

Quando Usar

• Um agente lida com canais compartilhados com clientes, fornecedores ou parceiros.
• Um agente lida com DMs desconhecidos, entregas programadas ou anexos.
• Você precisa de respostas comerciais autorizadas úteis sem rastros internos ou postagens não solicitadas.

Como Funciona

Destino e público confiáveis

Resolva a plataforma, o workspace e a identidade do canal exatos a partir de fatos autenticados do adaptador e de uma política controlada pelo operador. Rótulos de exibição, texto de mensagem, saída do modelo, metadados arbitrários e sinalizadores de eventos internos sintéticos não são credenciais. Identidade desconhecida ou malformada permanece segura para externos. Nunca eleve a confiança a partir de uma chave de política malformada correspondente ou do nome de exibição de uma conversa.

Os controles de acesso da plataforma se aplicam primeiro. Canais desconhecidos padronizam para silencioso para tráfego não solicitado; uma solicitação explícita de entrada pode ser respondida apenas se a política de acesso permitir, com restrições de saída externa. Um DM humano um-para-um pode solicitar participação, mas não estabelece um público confiável.

Público	Conteúdo para uma resposta autorizada de forma independente
Externo ou desconhecido	Resposta comercial final útil ou erro seguro conciso
Interno confiável ou operador privado	Resposta final, erro seguro, fatos operacionais concisos e progresso permitido
Silenciado ou adiado	Nenhuma saída

Raciocínio, exceções brutas, rastreamentos de pilha, segredos, caminhos de host, detalhes de sistema/configuração, status de teste e avisos de arquivamento interno não são conteúdo da contraparte. Mantenha evidências técnicas em registros internos com controle de acesso; mensagens internas devem resumir fatos operacionais necessários sem copiar rastreamentos sensíveis. A classificação de saída não é saneamento de texto.

Participação antes do trabalho

Use require_mention: true como padrão para grupos externos. Uma menção explícita atual ao agente, um comando reconhecido direcionado ao agente ou uma resposta direta ao agente podem solicitar participação. Derive o autor atual da resposta real; participação histórica em threads de bot e sessões ativas nunca conferem consentimento. Uma mensagem endereçada a outro humano permanece silenciada a menos que também contenha uma solicitação explícita ao agente ou a um operador confiável. Anexos sozinhos nunca autorizam uma resposta em grupo.

Um DM humano real um-para-um com texto substancial ou um anexo é um controle de solicitação positivo dentro da política de acesso. DMs em grupo e eventos sintéticos não recebem este atalho. Tráfego de origem bot requer uma solicitação de operador com escopo definido, mesmo que mencione o agente. Respostas a perguntas abertas requerem política de canal confiável explícita; o modelo decidir que possui uma resposta não é permissão. Respostas automáticas de operador exigem público interno/privado confiável, identidade de operador confiável, texto substancial e a política configurada.

Silencie ou adie antes do modelo, enriquecimento de contexto ou busca de mídia. Adie solicitações autorizadas durante uma rajada de anexos; comandos reconhecidos de parada/aprovação ignoram apenas a rajada de adiamento para que manipuladores inline permaneçam disponíveis. Metas anteriores, bot, acesso e portões de consentimento ainda se aplicam; o despacho não exige uma chamada de modelo.

observe_unmentioned_group_messages: true é uma capacidade opcional do adaptador, não permissão para invocar um modelo. Habilite a observação passiva apenas com uma política explícita de retenção/acesso, sem acionar enriquecimento, busca de mídia ou saída. never_silent_ack: true se aplica apenas a canais internos e nunca substitui o consentimento de participação. Silêncio deliberado é um resultado válido.

Limite de saída e entrega

Carregue a decisão durante toda a execução e verifique após todos os prefixos, formatação e fallbacks de falha, antes de cada envio, edição ou fragmento de stream. Inclua substituições de transporte e auxiliares independentes. Re-resolva o público para um destino alterado; a permissão de saída não é uma concessão de entrega. Reutilize as decisões do runtime proprietário: nenhum segundo mecanismo de política ou implementação concorrente pertence a esta skill.

Entregas programadas/por ferramenta exigem uma concessão genuína de operador/dispachante confiável com escopo para uma identidade de destino completa. Destino ou concessão ausente silencia, mesmo quando outros sinalizadores de solicitação estão definidos. Não fabrique menções ou sinais de solicitação para uma programação. Entrega autorizada a um destino desconhecido, mas válido, permanece segura para externos. Um modelo ou página não pode emitir a concessão.

Retorne falhas seguras sem interpolação de erro bruto. Declare os limites de capacidade necessários honestamente em termos comuns de usuário e, em seguida, solicite a menor entrada útil. Status de arquivamento/aprovação interna permanece em superfícies internas verificadas. Um aviso de arquivamento nunca concede permissão para um acuso de recebimento da contraparte.

Prompt estrito e política de exemplo

Use o prompt estrito imutável. Não interpolie rótulos de canal em instruções confiáveis. Omita rótulos quando não forem necessários; caso contrário, passe-os como dados estruturados não confiáveis, separados das regras. Escapar um rótulo não o torna política. Vincule cada solicitação à sua própria identidade de destino; nunca carregue contexto ou concessão de outro canal para ela.

O exemplo de política são dados portáteis ilustrativos, não uma configuração aceita por todos os adaptadores. Mapeie-o para o contrato revisado do runtime proprietário e verifique cada consumidor; uma chave YAML ou passar em um teste de prompt sozinho não prova a aplicação.

Autonomia de comunicação e vazamento

default: auto descreve conteúdo de rotina elegível após o acesso, participação e autoridade de entrega serem estabelecidos. Não cria permissão de envio não solicitado. Agendamento de rotina, logística e perguntas factuais de fornecedores podem ser respondidas dentro dessa autorização. Preços, linguagem contratual, questões legais, postagens públicas, alegações não verificadas e especificações técnicas não medidas permanecem apenas em rascunho. Restrições de nível e retenções de saída ainda se aplicam. Assinar, movimentar dinheiro, inserir credenciais, publicar pacotes e divulgação entre contrapartes são paradas bruscas.

Verifique o conteúdo em relação ao registro autorizado e aos termos protegidos de outras contrapartes antes de enviar. Um vazamento suspeito bloqueia o envio e relata apenas para uma superfície interna verificada para revisão; não exponha a parte correspondente externamente. Aprovações comerciais não anulam confidencialidade ou política de transporte.

Exemplos

Mensagem em grupo direcionada a humano

comprador: Jordan, você pode confirmar a contagem de racks?

Nenhuma resposta e nenhum trabalho de modelo/mídia. Uma mensagem de bot anterior na thread não muda nada. Qualquer observação passiva autorizada separadamente segue sua política de retenção; ela não aciona um acuso de recebimento externo.

Solicitação explícita ao agente, resposta comercial verificada

comprador: @desk quais datas de início estão disponíveis?
agente: 6 e 13 de outubro estão disponíveis. Qual data funciona para você?

Use apenas datas verificadas no registro autorizado. Nenhum status de teste, planejamento interno, rastreamento ou aviso de arquivamento acompanha a resposta.

Capacidade de anexo ausente

comprador: @desk a especificação anexada corresponde?
agente: Não consigo ler esse anexo aqui. Por favor, cole a seção relevante.

Não invente acesso ou oculte a limitação com uma pergunta não relacionada. Para uma taxa ou compromisso, arquive o rascunho exato para aprovação do operador e mantenha o status de arquivamento interno. Uma pergunta esclarecedora requer sua própria resposta permitida.

Invariantes para testar

Use identidades sintéticas e contadores reais de consumidores do runtime. Verifique silenciamento/adiamento antes do trabalho de modelo/contexto/mídia, negativos direcionados a humanos e positivos direcionados a agente, DM real versus DM em grupo, consentimento de bot, precedência de rajada de anexos/comando de controle, falhas de identidade desconhecida/malformada e falhas de concessão/alvo sintéticos.

Verifique a saída final segura e de falha após a montagem do prefixo através de caminhos de envio, edição, stream e independentes. Preserve programações autorizadas com escopo como controles positivos. Verificações de política pura ou string de prompt são evidências de contrato por escrito, não um teste de integração de transporte. Nenhum fixture vivo de fornecedor é necessário.

Registre resultados limitados de resposta/silenciamento/adiamento, códigos de motivo estáveis, público, classe de saída e caminho do consumidor testado com identificadores de correlação opacos. Supressão não é entrega bem-sucedida; apenas evidência de transporte registra a entrega. Mantenha corpos de mensagens, termos de fornecedores, identificadores de canal, segredos e recibos de incidentes brutos fora de testes e diagnósticos públicos. Reporte caminhos de consumidor não testados explicitamente em vez de inferir cobertura a partir de testes de política aprovados ou sessões abertas.