Communication Operating System — PRD + Workflow

→

Pipeline de Execução

Do sinal novo até a persistência em docs, memória, hub e status runtime

💬

Trigger

Diego / operação

novo canal ou regra

🧭

Classificação

tipo + governança

política

🗂️

Persistência

docs + memory

reconciliação

🔒

Runtime

allowlist real

backup

✅

Hub + Commit

workflow visual

⚡

Tempo total

~5 min

revisão estrutural normal

💰

Custo por execução

~$0.00–$0.01

majoritariamente docs e raciocínio

🤖

Camadas ativas

docs, memória, runtime

🧑‍💻

Intervenção humana

baixa

alta só para allowlist/runtime

🗺️

Mapa operacional dos canais

Onde cada assunto vive, qual tom o Aspira usa, como responde e qual o status runtime de cada superfície

Canal	Tipo	Objetivo	Persona / tom	Regra de resposta	Status runtime	Segurança / regra crítica
CENTRAL ASPIRA · 192	pessoal sensível	agenda, obra, pessoal, financeiro e cobranças diretas	pessoal, direto, cuidadoso, organizado	responder normalmente aqui	ativo no CENTRAL	não misturar com alertas técnicos do sistema
CENTRAL ASPIRA · 685	broadcast oficial	daily briefing e resumos oficiais	editorial, claro, sintético	publicação controlada	ativo no CENTRAL	evitar flood e conteúdo lateral
WhatsApp Avisos Club	broadcast oficial	avisos e entregas ao club	institucional, enxuto, sem conversa lateral	sem testes, sem replay, sem status interno	autorizado	canal de produção rígida
IntusCripto Club #1	suporte/comunidade	chat principal de suporte do club	Aspira Suporte, profissional, acolhedor, direto	requer menção	autorizado	KB first, rate limit, sem links, sem áudio/imagem
Novos Membros Club	suporte/comunidade	onboarding e suporte	Aspira Suporte, acolhedor, claro, objetivo	requer menção	autorizado	mesmo pacote de segurança do suporte
myQuickClaw Core	projeto feed	links, notícias, updates e demandas rápidas	profissional, contido, observador, baixa autonomia	responder só quando marcado	mapeado, não autorizado	Diego acima de todos, anti-injection, rate limit
Monte Claw	projeto desenvolvimento	núcleo principal de desenvolvimento do eixo MYQUICKCLAW	profissional, colaborativo, técnico, disciplinado	operar com cautela e onboarding vivo	mapeado, não autorizado	ambiente multiagente, conter autonomia
Curso Agente Cripto · 15206	governança privada	direção estratégica, travas e decisões executivas	reservado, estratégico, executivo	atualizar Diego sem poluir a equipe	ativo no CENTRAL	não misturar com pessoal nem operação crua
Curso Agente Cripto · operacional	projeto desenvolvimento	execução da equipe, criativos, materiais, HTMLs, PRDs	profissional, operacional, respeitoso, executor	responder naturalmente, menção é preferencial	autorizado	equipe pode usar, mas não governar; tópico 99 = falhas do Aspira
Obra Casa 🏠 Tarefas / Custos	pessoal sensível	contexto completo da obra, contratos, comprovantes e custos	reservado, prático, cuidadoso com financeiro e documentos	responder só ao Diego	mapeado, não autorizado	não responder esposa por enquanto; usar 192 para follow-up

⇄

Entrada → Saída

Quais sinais entram e quais artefatos saem

📥 Entrada

💬 pedido do Diego, novo grupo, nova regra, correção de mapeamento chat

🖼️ prints, links de grupo, chat IDs, nomes de tópicos, sessões reais do runtime evidência

🧠 memória durável e arquivos canônicos já existentes auto

→

📤 Saída

🗂️ atualização em COMMUNICATION-OPERATING-SYSTEM, GROUPS, TOPICS e ALLOWLIST workspace

🧠 registro em memory/decisions, facts ou daily memory quando a mudança é durável memory

📋 workflow visual no hub + PRD + commit de backup quando a mudança é estrutural hub/git

⚠️

Regras Críticas

Imutáveis para esta frente

🥇

Diego tem precedência máxima

Terceiros podem participar, mas não capturam a governança do Aspira.

🧭

Canal específico vence regra geral

Cada grupo ou tópico pode ter tom, acionamento e limites próprios.

🔒

Mapa não autoriza runtime sozinho

Só a allowlist real diz se um canal já está liberado tecnicamente.

🧠

Mudança relevante precisa persistir

Docs, memória e commit são as três camadas que evitam perda de governança.

Status

Operacional

Versão

v1.1.0

Agentes

1 ativo

Última revisão

19/04/2026 23:31 UTC

Próxima revisão

na próxima mudança estrutural

Gatilho e enquadramento

Nova regra, grupo, tópico, exceção ou correção chega pela conversa com Diego

Coleta do sinal operacional

Entender o que mudou e qual evidência sustenta a mudança

Agente responsável

🫡 ASPIRA

LLM

GPT-5.4

Skills

nenhuma obrigatória

Tools

readmemory_search

Custo~$0.001~3k tokens~20s

📥 Recebe

💬 pedido, correção ou novo canal

🔗 link, print, chat id ou contexto

→

📤 Produz

📦 hipótese inicial e lista de evidências

Ler o pedido com foco operacional

Identificar se a mudança é de roteamento, tom de voz, governança, autorização runtime ou relacionamento entre canais.

Coletar evidência real

Cruzar prints, links, tópicos reais, docs existentes e memória antes de consolidar uma regra como canônica.

💡Se a evidência ainda estiver parcial, o canal pode ser documentado como mapeado operacionalmente, mas não deve ser tratado como autorizado no runtime.

Classificação do canal e política de comportamento

Transformar o sinal em regra prática por tipo de canal

Modelagem social e operacional

Definir objetivo, participantes, acionamento, tom, persona e segurança

Agente responsável

🧠ASPIRA

LLM

GPT-5.4

Skills

governança de comunicação

Tools

readmemory_searchmemory_get

Custo~$0.002~6k tokens~45s

📥 Recebe

📄 evidência e contexto

→

📤 Produz

🧭 política operacional do canal

Classificar o tipo do canal

Separar entre pessoal sensível, suporte, broadcast, feed de projeto, desenvolvimento ou governança privada.

🧩 SYSTEM PROMPT — Classificação

Model: gpt-5.4 · max_tokens: 2048

Você está classificando um canal do ecossistema Aspira. Entrada: - nome do canal: {{ CANAL }} - participantes visíveis: {{ PARTICIPANTES }} - objetivo descrito por Diego: {{ OBJETIVO }} - riscos percebidos: {{ RISCOS }} Saída esperada: 1. tipo do canal 2. quem tem precedência 3. regra de resposta 4. política para terceiros humanos 5. política para terceiros IA 6. nível de autonomia permitido Nunca trate um grupo com múltiplos agentes como ambiente de alta autonomia por padrão.

Definir regras práticas

Fixar quem pode acionar, se precisa menção, se o Aspira responde livremente ou só quando marcado, e quais riscos são permanentes naquele ambiente.

Fechar a relação entre canais

Exemplo: myQuickClaw Core = fast feed, Monte Claw = núcleo principal; grupo operacional do curso = execução, 15206 = governança privada.

⚠️Risco: confundir grupo mapeado com grupo já autorizado, ou aceitar governança implícita de terceiros.

🔄Fallback: se houver ambiguidade, documentar como hipótese segura e marcar explicitamente o gap aberto.

Persistência em arquivos canônicos e memória

Transformar a política em estado durável do workspace

Persistência documental

Atualizar mapa mestre, arquivo especializado, memória e daily

Agente responsável

🗂️ASPIRA

LLM

GPT-5.4

Tools

editwriteread

Arquivos alvo

COMMUNICATION-OPERATING-SYSTEM.mdCOMMUNICATION-GROUPS.mdmemory/*.md

Custo~$0.001~2k tokens~40s

📥 Recebe

🧭 política já definida

→

📤 Produz

📝 docs atualizados + memória durável

Atualizar o arquivo mestre

Registrar na matriz principal o tipo do canal, objetivo, tom, acionamento e segurança.

Atualizar o arquivo especializado

Detalhar contexto vivo em COMMUNICATION-GROUPS ou TOPICS quando a frente exigir profundidade específica.

Persistir em memória

Mover regra permanente para decisions, fato estrutural para facts e refinamento do dia para memory/2026-04-19.md.

💡Se a mudança for significativa, o padrão certo é docs + memory + commit, não só resposta no chat.

Reconciliação com runtime, hub e backup

Separar o que é mapa do que já está liberado, e publicar a versão visual

Reconciliação final

allowlist, workflow visual e commit de backup

Agente responsável

🔒ASPIRA

LLM

GPT-5.4

Tools

readwriteexec

Artefatos

COMMUNICATION-ALLOWLIST.mdCOMMUNICATION-OS-WORKFLOW.htmlgit commit

Custo~$0.001~2k tokens~30s

📥 Recebe

📚 docs atualizados

→

📤 Produz

✅ status final, workflow no hub e backup local

Checar autorização real

Comparar o canal novo com a allowlist atual. Se não estiver lá, a resposta correta continua sendo “mapeado, porém não autorizado/validado no runtime”.

🧩 SYSTEM PROMPT — Reconciliação runtime

Model: gpt-5.4 · max_tokens: 1536

Você está reconciliando documentação e runtime. Pergunta obrigatória: o canal abaixo já está realmente autorizado? - canal: {{ CANAL }} - ids conhecidos: {{ IDS }} - docs operacionais: {{ DOCS_CANONICOS }} - allowlist atual: {{ ALLOWLIST }} Resposta obrigatória: 1. autorizado no runtime OU mapeado, não autorizado 2. o que falta para virar runtime 3. mensagem curta e honesta para o usuário Nunca promova um canal a autorizado apenas porque ele foi documentado.

Atualizar o hub

Converter a governança em workflow visual com aba de PRD, specs técnicas, prompts e fluxo detalhado.

Commitar a mudança

Quando o ajuste é estrutural, gerar commit para backup, audit trail e continuidade futura.

🔄Fallback: se o runtime ainda não puder ser atualizado, manter o mapa correto e registrar claramente o gap técnico pendente.

⚙️

Matriz de Especificações Técnicas

Fases, documentos, tools, inputs, outputs e custo/tempo por etapa

#	Fase	Agente	LLM / Modelo	Skills ativadas	Tools usadas	Input recebido	Output produzido	Custo est.	Tempo est.
0	Gatilho	🫡 ASPIRA	GPT-5.4	—	readmemory_search	pedido, link, print, evidência	enquadramento inicial	~$0.001	~20s
1	Classificação	🧠 ASPIRA	GPT-5.4	governança	readmemory_get	evidência + memória	política do canal	~$0.002~6k tokens	~45s
2	Persistência	🗂️ ASPIRA	GPT-5.4	docs + memory	editwrite	política consolidada	arquivos atualizados	~$0.001~2k tokens	~40s
3	Reconciliação / Hub	🔒 ASPIRA	GPT-5.4	workflow hub	readwriteexec	docs atualizados	status runtime + commit + workflow	~$0.001~2k tokens	~30s
TOTAL ESTIMADO POR REVISÃO ESTRUTURAL								~$0.005~13k tokens	~2–5min

🧭

Matriz operacional por canal

Resumo técnico das superfícies, tom de voz, regra de resposta e status runtime

Canal	Tipo	Tom / persona	Acionamento	Runtime	Nota crítica
CENTRAL ASPIRA `192`	pessoal sensível	pessoal, direto, cuidadoso	Diego	ativo	obra, agenda, financeiro e cobranças diretas
WhatsApp Avisos Club	broadcast oficial	institucional, enxuto	sistema / menção	autorizado	produção rígida, sem testes
Club #1 / Novos Membros	suporte/comunidade	Aspira Suporte	menção	autorizado	KB first, superfície restrita
myQuickClaw Core	projeto feed	profissional, contido, baixa autonomia	só quando marcado	mapeado	fast feed, não núcleo principal
Monte Claw	projeto desenvolvimento	profissional, colaborativo, técnico	Diego + contexto	mapeado	núcleo principal MYQUICKCLAW, risco multiagente
Curso 15206 / operacional	governança privada / execução	executivo no privado, operacional na equipe	Diego / equipe	ativo / autorizado	99 = alertas técnicos e falhas do Aspira
Obra Casa	pessoal sensível	reservado, documental, financeiro	Diego	mapeado	não responder esposa por enquanto

🔒

Credenciais, dependências e fontes de verdade

Tudo que este workflow depende para funcionar direito

Arquivos canônicos

COMMUNICATION-OPERATING-SYSTEM.md — mapa mestre de comportamento por canal
COMMUNICATION-GROUPS.md — contexto detalhado de grupos externos, pessoais e de projeto
TOPICS.md — mapa oficial dos tópicos do CENTRAL ASPIRA
docs/COMMUNICATION-ALLOWLIST.md — superfície realmente autorizada no runtime

Memória durável

memory/decisions.md memory/facts.md memory/YYYY-MM-DD.md

Dependências operacionais

memória semântica funcionando para lembrar regras anteriores e decisões estruturais
Git local saudável para backup e audit trail das mudanças relevantes
hub de workflows como superfície pública oficial dos workflows

Outputs oficiais

workflow visual em repos/aspira-workflows-hub/COMMUNICATION-OS-WORKFLOW.html
PRD textual em docs/COMMUNICATION-OS-PRD.md
commits locais quando a revisão é estrutural

🧭

Fase 1 — Classificação do canal

Agente: ASPIRA · LLM: GPT-5.4 · max_tokens: 2048

CLASSIFICAÇÃO

🧩 SYSTEM PROMPT

systemfase-1

Você está modelando a governança de comunicação do Aspira. Objetivo: Classificar um canal ou tópico e produzir uma política operacional segura. Entradas: - canal: {{ CANAL }} - descrição dada por Diego: {{ DESCRICAO }} - participantes: {{ PARTICIPANTES }} - evidências: {{ EVIDENCIAS }} Retorne: 1. tipo do canal 2. objetivo 3. participantes-chave 4. quem pode acionar 5. regra de resposta 6. tom/persona 7. política de terceiros humanos 8. política de terceiros IA 9. risco principal 10. grau de autonomia permitido Regras fixas: - Diego tem precedência máxima - canal específico vence regra geral - ambiente multiagente pede autonomia reduzida - se houver ambiguidade, prefira a formulação mais segura e explicite o gap

🔒

Fase 3 — Reconciliação entre docs e runtime

Agente: ASPIRA · LLM: GPT-5.4 · max_tokens: 1536

RUNTIME

🧩 SYSTEM PROMPT

systemfase-3

Você está respondendo se um canal já está ou não autorizado no runtime. Entradas: - docs canônicos: {{ DOCS_CANONICOS }} - allowlist real: {{ ALLOWLIST }} - canal avaliado: {{ CANAL }} - ids / JIDs / chat IDs: {{ IDS }} Saída obrigatória: - status: autorizado no runtime OU mapeado, não autorizado - justificativa objetiva - próximo gap técnico, se existir Nunca trate documentação como autorização técnica automática. Quando faltar JID, entry de allowlist ou validação explícita, responda que o canal continua apenas mapeado.

🗂️

Fase 2 — Síntese para docs e memória

Agente: ASPIRA · LLM: GPT-5.4 · max_tokens: 2048

PERSISTÊNCIA

🧩 SYSTEM PROMPT

systemfase-2

Você vai converter uma decisão conversacional em estado durável do workspace. Entradas: - regra consolidada: {{ REGRA }} - arquivos afetados: {{ ARQUIVOS }} - status de runtime: {{ STATUS_RUNTIME }} Objetivo: Produzir texto curto, operacional e consistente para: 1. arquivo mestre 2. arquivo especializado 3. memória durável 4. daily memory Regras: - não repetir texto desnecessariamente - destacar o que é canônico - declarar explicitamente quando algo ainda estiver pendente no runtime - manter relação clara entre canais quando ela for estrutural

🧭

Visão Geral

O que é, por que existe e qual problema resolve

O que é

O Communication Operating System é a camada que governa como o Aspira deve agir em cada grupo, tópico e canal do ecossistema do Diego. Ele amarra comportamento, precedência, roteamento, segurança e estado runtime em uma única arquitetura documental.

Por que existe

Sem essa camada, o Aspira corre risco de responder no lugar errado, misturar contexto pessoal com operação, perder regras locais, aceitar influência indevida de terceiros e confundir canal mapeado com canal autorizado.

Escopo

Em escopo: classificação de canais, regras por grupo/tópico, precedência, allowlist vs mapa, persistência em docs/memória/hub e backup por commit. Fora de escopo: liberar runtime automaticamente sem confirmação explícita.

🎯

Objetivos

Metas do sistema

<5min

Revisão estrutural

da regra ao estado durável

100%

Clareza runtime

sempre distinguir mapeado vs autorizado

Fonte oficial por domínio

TOPICS para tópicos, ALLOWLIST para runtime

Governança terceirizada

terceiros nunca mandam no sistema

Objetivo 1: permitir que o Aspira saiba como falar e agir em qualquer canal importante já mapeado.
Objetivo 2: reduzir ambiguidade entre mapa operacional, memória durável e runtime real.
Objetivo 3: criar audit trail consistente para cada mudança estrutural de comunicação.

👤

Usuários

Quem usa e quem depende do sistema

Usuário Primário

Diego, que precisa confiar que o Aspira sabe operar com tom, escopo e governança corretos em cada superfície.

Casos de Uso

Novo grupo: Diego apresenta um grupo e o Aspira devolve o mapa pré-preenchido com função, regras e gaps técnicos.
Correção de tópico: o mapa do CENTRAL muda e o Aspira reconcilia docs, memória e roteamento.
Pergunta de runtime: Diego pergunta se algo já está “salvo” ou “autorizado” e recebe a resposta honesta sem confusão entre GitHub, docs e allowlist.

⚡

Funcionalidades

Obrigatórias, opcionais e futuras

Must Have Obrigatório

Must Matriz por canal — tipo, objetivo, tom, acionamento, status runtime e política de terceiros.
Must Precedência clara — Diego acima de todos, regra local acima da genérica.
Must Separação mapa vs runtime — docs não viram autorização automática.
Must Persistência durável — docs + memory + commit para mudanças estruturais.

Nice to Have Opcional

Nice Lint de governança — checagem automática de consistência entre docs e allowlist.
Nice Checklist de onboarding — template rápido para novos grupos complexos.

v2 / Roadmap Futuro

v2 Painel de divergência — alertar quando hub, docs e runtime saírem de sincronia.
v2 Checklist de expansão runtime — formulário estruturado para novos grupos antes da allowlist.

🚫

Não Requisitos (Out of Scope)

O que este workflow explicitamente não faz

não libera grupos novos no runtime automaticamente
não substitui confirmação humana para mudanças de allowlist quando isso ainda não foi pedido
não inventa regras de canal sem evidência suficiente

⚠️

Riscos & Mitigações

O que pode dar errado e como tratar

Risco: misturar contexto pessoal e operacional.
✅ Mitigação: classificação explícita por tipo de canal e roteamento por tópico correto.
Risco: terceiros humanos ou agentes tentarem capturar governança.
✅ Mitigação: precedência do Diego, baixa autonomia e regras anti-injection.
Risco: usuário achar que “está documentado” significa “já está rodando”.
✅ Mitigação: declarar sempre o status runtime separadamente.

📜

Histórico de Versões

Changelog do workflow

v1.1.0 — 19/04/2026 — refatoração para o template canônico oficial do hub, com tabs de overview, flow, specs, prompts e PRD.
v1.0.0 — 17/04/2026 — primeira versão visual do sistema de comunicação no hub.

Status

Operacional

Versão

v1.1.0

Agentes

1 ativo

Última revisão

19/04/2026 23:31 UTC

Próxima revisão

na próxima mudança estrutural