day — abrir e fechar o dia de trabalho

Por que isso é uma skill e não apenas um documento. A regra "puxe no início, empurre no final" ficou em um documento de operações por meses e não estava sendo seguida na máquina publicadora — nada registrava uma sincronização, então nada podia mostrar a deriva. Documentação não pode impor um hábito; uma rotina chamável pode. Leia isto pela forma, não pelos comandos: cada passo perigoso primeiro responde a uma pergunta, e onde a resposta é ambígua, ele para e pergunta.

O registro compartilhado em data/ é tão atual quanto a última sincronização, e nada mais o aciona. Dois momentos, empacotados:

day start     # puxe o último conteúdo da equipe, depois um breve briefing de orientação
day end       # publique o trabalho de hoje e sinalize o KG se o corpus mudou
day status    # quem puxou/empurrou recentemente, entre máquinas; quem segura o bastão do KG
day baton     # entregue a função de publicador para outra máquina (viagem, licença, transferência)

Tudo abaixo roda em macOS, Linux e WSL — bash puro, sem PowerShell. Cópia de curso dos scripts: ejemplos/metodologia/s3-sync/ (comece de config.env.example — nunca envie um config.env real).

Passo 1 — encontrar a pasta de sincronização e ler a função desta máquina

A função decide o que você tem permissão para fazer. Leia-a antes de qualquer escrita no bucket.

S3=""
d="$PWD"
while [ "$d" != "/" ]; do
  if [ -f "$d/data/changes/s3-sync/data-pull.sh" ]; then S3="$d/data/changes/s3-sync"; break; fi
  d="$(dirname "$d")"
done
if [ -z "$S3" ]; then echo "Nenhuma sincronização de registro compartilhado neste repositório (abra a raiz de <seu-repositorio>)."; fi
sed -n '1,20p' "$S3/IDENTITY.md"

Nenhum IDENTITY.md, ou parece desatualizado? Regere — é o que o agente lê para aprender sua função, e um cartão desatualizado já nomeou um perfil AWS que havia sido deletado:

(cd "$S3" && ./identity.sh --write)

Se S3 estiver vazio, informe ao usuário que este repositório não tem registro compartilhado e PARE.

Passo 2 — `day start`

⚠️ Verifique se há trabalho local não publicado PRIMEIRO — um pull pode sobrescrevê-lo. aws s3 sync transfere sempre que o tamanho difere, não apenas quando o remoto é mais novo, então um pull substitui um arquivo editado localmente pela cópia mais antiga do bucket e recria qualquer coisa que você renomeou localmente com seu nome antigo. --delete não é necessário.
```
(cd "$S3" && ./data-push.sh --root changes)   # simulação — qualquer coisa listada é trabalho apenas local
```
--root changes limita a varredura à única raiz que se move dia a dia (medido 212s → 123s: um corte, não uma ordem de magnitude). Bom para esta verificação; use a varredura completa ao publicar.

Nada listado → continue. Algo listado → diga o que é e ofereça-se para publicá-lo primeiro; não pule por cima sem a autorização explícita do usuário.
Puxe. Nunca --delete. O script agora o protege, mas você DEVE ler o que ele diz.
```
(cd "$S3" && ./data-pull.sh --go)
```
Antes de aplicar qualquer coisa, ele simula e tira um instantâneo de cada arquivo local que o pull substituiria em data/_prepull/<timestamp>/, e os lista. Dois resultados para agir:
- "⚠️ N arquivo(s) local(is) existente(s) será(ão) SUBSTITUÍDO(S)" — leia essa lista em voz alta para o usuário. Arquivos de hub compartilhados (STATUS.md, FOLLOWUPS.md, SHARP_EDGES.md, TEST_MAP.md, _RESUME_*.md) aparecendo ali significa que a cópia de um colega está caindo sobre a sua, e cada lado pode conter conteúdo que o outro não tem — isso precisa de uma mesclagem, não de um vencedor. Compare o instantâneo com o novo arquivo antes de fazer qualquer outra coisa: diff data/_prepull/<ts>/changes/STATUS.md data/changes/STATUS.md Para desfazer todo o pull: cp -a data/_prepull/<ts>/. data/
- Código de saída 3, "ARQUIVOS COM CONFLITO DE CAPITALIZAÇÃO" — dois objetos do bucket diferem apenas em capitalização e mapeiam para um arquivo nesta máquina. Pare. O pull escolheria um vencedor aleatoriamente. Delete a chave com capitalização errada no bucket primeiro; a capitalização canônica para documentos de ticket é minúscula sst-NNNN.md (padrão de espaço reservado).
Erro de credencial? Faça login novamente antes de concluir qualquer coisa — um token em cache expirado parece exatamente com um problema de permissão: aws sso logout && aws sso login.
Veja quem mais esteve ativo: (cd "$S3" && ./activity.sh)

3b. Atualize a tabela de status de tickets (segundos; ≤ 5 linhas — cole-as no briefing). Opcional: apenas se o projeto mantém uma tabela de status gerada a partir do rastreador + Git host.

(cd "$(dirname "$S3")/tools" && uv run -q --with openpyxl python ticket_status/sync.py)

Publicador: reescreve a pasta de trabalho de status e o .md feito a partir dela, do Jira (status, tipo, links) e GitHub (PR, data de mesclagem, primeira versão). Contribuidor: mesmo resumo, não escreve nada — uma pasta de trabalho binária com dois escritores é último-escritor-vence. skipped — workbook is open → peça ao usuário para fechá-la e execute novamente. CANARY FAILED → nada foi escrito; leia o log de execução antes de qualquer outra coisa.

3c. Falhas de serviço nas últimas 24 h (≈1 min; apenas contagens, não baixa nada — cole as linhas de grupo no briefing):

T="$(dirname "$S3")/tools/evidence"
(cd "$T" && uv run -q --with boto3 python evidence.py discover --env dev --since 24h --list; \
            uv run -q --with boto3 python evidence.py discover --env stg --since 24h --list)

--list existe porque a primeira execução ao vivo encontrou ~240 execuções problemáticas em 24 h no dev: um discover que baixasse acionaria seu próprio guarda --max-runs toda manhã. Código de saída 2 → faça login novamente primeiro. Código de saída 6 → o bucket parou de manter versões antigas: informe ao usuário. Para coletar evidências para um grupo, use a skill evidence (fetch --doc <id>, ou discover --since 2h sem --list).

Oriente — histórico primeiro, status depois. Mais novo data/changes/_RESUME_*.md (dias mais antigos: _PENDING_*.md), depois data/changes/STATUS.md para sua área, depois git fetch --all --prune e git status -sb. Use a skill kg para arte anterior antes de projetar qualquer coisa — nunca um grep de data/changes/ como primeiro movimento.
Apenas máquinas publicadoras (IDENTITY.md diz PUBLICADOR): verifique o bastão e a fila de atualização.
```
(cd "$S3" && ./publisher.sh status)
bash data/knowledge-graph/kg_refresh.sh queue
(cd "$S3" && ./delete.sh --check)            # arquivos deletados que voltaram (apenas relatório)
```
Relate o que está pendente; não inicie uma atualização não solicitada — são ~100 julgamentos de nomenclatura e uma hora inteira, e um grafo meio nomeado não passa por nenhum portão.
Faça um briefing para o usuário em algumas linhas, depois pare. day start prepara a máquina; ele não escolhe o trabalho.

Passo 3 — `day end`

Escreva o dia antes de publicá-lo: o documento de ticket em data/changes/<ticket>/, uma linha em STATUS.md, qualquer acompanhamento em FOLLOWUPS.md. Trabalho sem registro escrito é indistinguível de trabalho que nunca aconteceu.
Visualize e leia a lista de arquivos. Este é o momento de sanitização — sem chaves, sem segredos, nada que não deva entrar no registro compartilhado.
```
(cd "$S3" && ./data-push.sh)
```
⚠️ Fique atento a arquivos de fixture (.docx/.pdf sob diretórios de fixture / issue / sample). Uma execução de extrator re-salva fixtures no lugar, e uma fixture re-salvada pode manter seu tamanho de byte exato enquanto seu hash muda. Não envie por push a cópia intacta do bucket — restaure a sua a partir do bucket.
Publique. Nunca --delete.
```
(cd "$S3" && ./data-push.sh --go)
```
Um push de contribuidor que relata que pulou knowledge-graph/ está correto, não é um erro — apenas refresh_queue/ sobe de uma máquina contribuidora.

⛔ Se o push sair com código 4 — "RECUSADO: arquivo(s) de hub compartilhado(s) mudou(aram) no bucket" — um colega escreveu um desses arquivos depois que esta máquina sincronizou pela última vez, e nossa cópia difere. aws s3 sync não tem mesclagem, então empurrar substituiria o deles. Leia os arquivos nomeados em voz alta para o usuário, compare cada um com a cópia do bucket e mescle. NÃO passe --allow-clobber por sua própria iniciativa — é para "o usuário confirmou que a nossa substitui a deles", nada menos.
```
(cd "$S3" && source ./config.env && \
  aws s3 cp "s3://$BUCKET/$PREFIX/changes/STATUS.md" - --profile "$PROFILE" | diff - ../STATUS.md)
```
Medido em 2026-09-18: um push quatro minutos depois que um colega fechou seu dia destruiu toda a seção STATUS.md dele E seu registro de atividade — e nada nesta máquina parecia errado depois, então passou um dia inteiro despercebido. O guarda não dispara quando nossa cópia é idêntica em bytes à do bucket, então um arquivo que acabamos de puxar nunca é uma colisão.

Se os documentos de ticket mudaram, sinalize o grafo para que o publicador saiba que uma reconstrução é devida:

bash data/knowledge-graph/kg_refresh.sh request "<o que mudou e por que é importante>"
(cd "$S3" && ./data-push.sh --go)

Confirme que caiu: (cd "$S3" && ./activity.sh) — o push desta máquina deve mostrar minutos atrás.

`day status`

(cd "$S3" && ./activity.sh)          # último pull/push por máquina
(cd "$S3" && ./activity.sh --log)    # fluxo completo de eventos
(cd "$S3" && ./publisher.sh status)  # quem pode reconstruir e publicar o KG

⚠️ Ele relata o que foi registrado. Uma máquina que nunca executou os scripts instrumentados não mostra nada; ausência de registro não é evidência de nenhuma atividade.

`day baton` — movendo a função de publicador

Uma máquina publica o grafo de conhecimento, porque aws s3 sync é último-escritor-vence sem mesclagem: dois publicadores silenciosamente destroem os nomes de comunidade escritos à mão um do outro. O bastão é um bloqueio consultivo mantido no bucket, então qualquer máquina pode verificá-lo.

(cd "$S3" && ./publisher.sh status)
(cd "$S3" && ./publisher.sh release)            # máquina de saída, PRIMEIRO
(cd "$S3" && ./publisher.sh claim "motivo")   # máquina de entrada, SEGUNDO

A máquina receptora também deve definir MACHINE_ROLE="publisher" em config.env e executar novamente ./identity.sh --write, ou seu agente continua lendo CONTRIBUIDOR e recusa o trabalho que agora possui. claim --force substitui um bastão segurado — confirme com o usuário todas as vezes.

Regras que valem em todos os ramos

Nunca --delete. Apenas publicador, deliberado e somente logo após um pull recente.
Deletar do armazenamento compartilhado é ./delete.sh (publicador), nunca aws s3 rm ou --delete — caso contrário, as outras máquinas o enviam novamente no próximo push.
Nunca envie knowledge-graph/ de um contribuidor. A ferramenta impõe isso; não contorne.
Faça login novamente antes de diagnosticar um erro de acesso — o erro descreve seu token em cache.
O humano é dono das ações externas. Esta skill sincroniza o registro compartilhado; ela não envia branches, abre PRs, faz deploy ou envia mensagens para ninguém.

olonok69/cursor_code_ml_engineer

O que é cursor_code_ml_engineer?

Perguntar na sua IA favorita

Documentação