Objetivo: ao final, o consultor sabe onde fixar cada tipo de contexto: instruções globais, instruções de pasta, Project ou o próprio pedido.
| Lugar | Escopo | O que vai |
|---|---|---|
| Instruções globais | Você, em tudo | Seu papel, como você quer que ele fale com você, suas preferências de estilo |
| Instruções de pasta | Aquela pasta | Terminologia do cliente, estrutura de diretórios, template, restrições, convenção de nomes |
| Instruções de Project | Aquele Project, no Chat | Contexto do cliente para conversas + base de conhecimento |
| O pedido | Aquela tarefa | O que é específico e não se repete |
Salve como COWORK.md na raiz da pasta conectada:
# Contexto — Meridiano, Rollout S/4 Fase 2
## Cliente e escopo
Meridiano, indústria de autopeças. Fase 2: Brasil e México.
Duas empresas (MRD1 Brasil, MRD2 México), quatro organizações de compras.
Sistema: MRD. Go-live 15/12/2026.
## Terminologia do cliente
Use sempre: "centro" (não plant), "organização de compras" (não purchasing
org), "liberação" (não release), "PCA" para pedido gerado por MRP,
"Fluxo Verde" para o fluxo de aprovação simplificado até R$ 5.000.
## Estrutura desta pasta
- `Entrada/Atas/` — atas de workshop. Somente leitura.
- `Entrada/Documentos/` — BBP, escopo contratado, org structure. Somente leitura.
- `Saida/` — tudo que você produzir vai aqui.
- `Templates/` — templates da Wayon a usar.
## Restrições
- O cliente vetou desenvolvimento Z para aprovação de compras.
- EWM e Ariba estão fora do escopo da Fase 2.
## Como produzir entregáveis
- Use o template correspondente em `Templates/`.
- Nomeie como `<Tipo>-<Modulo>-Fase2-v<N>.docx`.
- Nunca sobrescreva: incremente a versão.
- Onde a informação nas fontes for insuficiente, escreva INDEFINIDO
em vez de assumir.
- Toda afirmação sobre o sistema MRD precisa vir marcada como
"a confirmar no sistema".
Repare nos dois últimos itens: você fixou de uma vez, para todas as tarefas daquela pasta, as duas instruções de qualidade mais importantes do módulo.
Vou repetir isso amanhã?
| Resposta | Onde vai |
|---|---|
| Sim, em qualquer cliente | Instruções globais |
| Sim, neste cliente / nesta pasta | Instruções de pasta |
| Não, é só desta tarefa | O pedido |
Memória do Chat não transfere para o Cowork. São contextos separados:
| Vive em | Alcança | |
|---|---|---|
| Instruções de Project | Chat | Conversas dentro daquele Project |
| Instruções de pasta | Cowork | Pedidos naquela pasta |
Se você quer o mesmo contexto nos dois, escreva nos dois. Uma prática que funciona: mantenha o texto-fonte num único arquivo e cole nos dois lugares, para não divergirem.
Diferente de um Project, uma sessão de Cowork não é compartilhada com outra pessoa. O que você compartilha é:
A terminologia do Meridiano não vale no Aurora. Você criaria erro nos outros clientes.
Funciona e você repete todo dia. É o problema que as instruções de pasta resolvem.
Correto. Específico daquele cliente, e vale para toda tarefa naquela pasta.
Você teria que repetir em cada pasta de cada cliente.
Repetição diária de algo que nunca muda.
Correto. É sobre você, e vale em todos os clientes e todas as pastas.
Não está. Project e instruções de pasta são mecanismos separados.
Correto. É a pegadinha número um do Cowork.
A conversa do Project é Chat. Ela não vira sessão de Cowork.
É instrução de uma tarefa. Fixada na pasta, ela vai afetar todas as tarefas futuras, inclusive as que precisam de maio.
Você aplicaria uma regra sobre atas de maio do Meridiano a todos os seus clientes.
Correto. Específico daquela tarefa e não se repete.