day — ouvrir et fermer la journée de travail

Pourquoi ceci est un skill et pas simplement un document. La règle « tirer au début, pousser à la fin » est restée dans un document opérationnel pendant des mois sans être suivie sur la machine de publication — rien n'enregistrait de synchronisation, donc rien ne pouvait montrer la dérive. La documentation ne peut pas imposer une habitude ; une routine exécutable le peut. Lisez ceci pour la structure, pas pour les commandes : chaque étape dangereuse répond d'abord à une question, et lorsque la réponse est ambiguë, elle s'arrête et demande.

L'enregistrement partagé sous data/ n'est aussi récent que la dernière synchronisation, et rien d'autre ne l'incite à se mettre à jour. Deux moments, sous forme de paquets :

day start     # tirer les dernières mises à jour de l'équipe, puis un court briefing d'orientation
day end       # publier le travail d'aujourd'hui, et signaler le KG si le corpus a bougé
day status    # qui a tiré/poussé récemment, sur toutes les machines ; qui détient le témoin du KG
day baton     # passer le rôle d'éditeur à une autre machine (voyage, congé, passation)

Tout ce qui suit fonctionne sur macOS, Linux et WSL — bash simple, pas de PowerShell. Copie des scripts : ejemplos/metodologia/s3-sync/ (commencez par config.env.example — ne livrez jamais un vrai config.env).

Étape 1 — trouver le dossier de synchronisation et lire le rôle de cette machine

Le rôle détermine ce que vous avez le droit de faire. Lisez-le avant toute écriture dans le 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 "Aucune synchronisation d'enregistrement partagé dans ce dépôt (ouvrez la racine <votre-depot>)."; fi
sed -n '1,20p' "$S3/IDENTITY.md"

Pas de IDENTITY.md, ou il semble obsolète ? Régénérez-le — c'est ce que l'agent lit pour connaître son rôle, et une carte obsolète a un jour nommé un profil AWS qui avait été supprimé :

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

Si S3 est vide, dites à l'utilisateur que ce dépôt n'a pas d'enregistrement partagé et ARRÊTEZ.

Étape 2 — `day start`

⚠️ Vérifiez d'abord la présence de travail local non publié — un pull peut l'écraser. aws s3 sync transfère lorsque la taille diffère, pas seulement lorsque le fichier distant est plus récent, donc un pull remplace un fichier modifié localement par la copie plus ancienne du bucket et recrée tout ce que vous avez renommé localement sous son ancien nom. Pas besoin de --delete.
```
(cd "$S3" && ./data-push.sh --root changes)   # dry run — tout ce qui est listé est un travail local uniquement
```
--root changes limite la recherche à la seule racine qui bouge de jour en jour (mesuré 212s → 123s : une réduction, pas un ordre de grandeur). Suffisant pour cette vérification ; utilisez l'analyse complète lors de la publication.

Rien de listé → continuez. Quelque chose de listé → dites ce que c'est et proposez de le publier d'abord ; ne tirez pas par-dessus sans l'accord explicite de l'utilisateur.
Tirez. Jamais --delete. Le script vous protège désormais, mais vous devez LIRE ce qu'il dit.
```
(cd "$S3" && ./data-pull.sh --go)
```
Avant d'appliquer quoi que ce soit, il effectue un dry-run, sauvegarde chaque fichier local que le pull remplacerait dans data/_prepull/<timestamp>/, et les liste. Deux résultats à traiter :
- "⚠️ N fichier(s) local(aux) existant(s) seront REMPLACÉS" — lisez cette liste à voix haute à l'utilisateur. Les fichiers hub partagés (STATUS.md, FOLLOWUPS.md, SHARP_EDGES.md, TEST_MAP.md, _RESUME_*.md) qui apparaissent signifient qu'une copie d'un collègue atterrit sur la vôtre, et chaque côté peut contenir du contenu que l'autre n'a pas — cela nécessite une fusion, pas un vainqueur. Comparez la sauvegarde avec le nouveau fichier avant de faire quoi que ce soit d'autre : diff data/_prepull/<ts>/changes/STATUS.md data/changes/STATUS.md Pour annuler tout le pull : cp -a data/_prepull/<ts>/. data/
- Code de sortie 3, "FICHIERS EN CONFLIT DE CASSE" — deux objets du bucket ne diffèrent que par la capitalisation et correspondent à un seul fichier sur cette machine. Arrêtez. Le pull choisirait un vainqueur au hasard. Supprimez d'abord la clé avec la casse incorrecte dans le bucket ; la casse canonique pour les documents de ticket est en minuscules sst-NNNN.md (motif générique).
Erreur d'identification ? Reconnectez-vous avant de conclure quoi que ce soit — un jeton en cache expiré ressemble exactement à un problème de permissions : aws sso logout && aws sso login.
Voyez qui d'autre a été actif : (cd "$S3" && ./activity.sh)

3b. Rafraîchissez le tableau d'état des tickets (secondes ; ≤ 5 lignes — collez-les dans le briefing). Facultatif : uniquement si le projet tient un tableau d'état généré à partir du suivi + de l'hôte Git.

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

Éditeur : réécrit le classeur d'état et le .md qui en est issu, à partir de Jira (statut, type, liens) et GitHub (PR, date de fusion, première version). Contributeur : même résumé, n'écrit rien — un classeur binaire avec deux rédacteurs, c'est dernier écrit gagne. skipped — workbook is open → demandez à l'utilisateur de le fermer et de relancer. CANARY FAILED → rien n'a été écrit ; lisez le journal d'exécution avant toute chose.

3c. Échecs de service au cours des dernières 24 h (≈1 min ; uniquement les comptages, rien n'est téléchargé — collez les lignes de groupe dans le 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 car la première exécution en direct a trouvé ~240 exécutions problématiques en 24 h sur dev : un téléchargement de découverte déclencherait sa propre garde --max-runs chaque matin. Code de sortie 2 → reconnectez-vous d'abord. Code de sortie 6 → le bucket a cessé de conserver les anciennes versions : informez l'utilisateur. Pour collecter des preuves pour un groupe, utilisez le skill evidence (fetch --doc <id>, ou discover --since 2h sans --list).

Orientez-vous — l'historique d'abord, l'état ensuite. Le plus récent data/changes/_RESUME_*.md (jours plus anciens : _PENDING_*.md), puis data/changes/STATUS.md pour votre domaine, puis git fetch --all --prune et git status -sb. Utilisez le skill kg pour les travaux antérieurs avant de concevoir quoi que ce soit — jamais un grep de data/changes/ comme premier geste.
Machines éditeur uniquement (IDENTITY.md dit PUBLISHER) : vérifiez le témoin et la file d'attente de rafraîchissement.
```
(cd "$S3" && ./publisher.sh status)
bash data/knowledge-graph/kg_refresh.sh queue
(cd "$S3" && ./delete.sh --check)            # fichiers supprimés qui sont réapparus (rapport uniquement)
```
Rapportez ce qui est en attente ; ne lancez pas un rafraîchissement sans qu'on vous le demande — cela représente ~100 décisions de nommage et une heure complète, et un graphe à moitié nommé ne passe aucune porte.
Briefez l'utilisateur en quelques lignes, puis arrêtez-vous. day start prépare la machine ; il ne choisit pas le travail.

Étape 3 — `day end`

Écrivez la journée avant de la publier : le document de ticket sous data/changes/<ticket>/, une ligne STATUS.md, tout suivi dans FOLLOWUPS.md. Un travail sans trace écrite est impossible à distinguer d'un travail qui n'a jamais eu lieu.
Prévisualisez et lisez la liste des fichiers. C'est le moment de l'assainissement — pas de clés, pas de secrets, rien qui ne devrait pas entrer dans l'enregistrement partagé.
```
(cd "$S3" && ./data-push.sh)
```
⚠️ Surveillez les fichiers de fixtures (.docx/.pdf sous les répertoires fixture / issue / sample). Un extracteur qui s'exécute réenregistre les fixtures sur place, et une fixture réenregistrée peut conserver sa taille exacte en octets tandis que son hash change. Ne poussez pas par-dessus la copie vierge du bucket — restaurez plutôt la vôtre depuis le bucket.
Publiez. Jamais --delete.
```
(cd "$S3" && ./data-push.sh --go)
```
Un push de contributeur qui signale qu'il a ignoré knowledge-graph/ est correct, pas une erreur — seul refresh_queue/ monte depuis une machine contributeur.

⛔ Si le push se termine avec le code 4 — "REFUSÉ : fichier(s) hub partagé(s) modifié(s) dans le bucket" — un coéquipier a écrit l'un de ces fichiers après la dernière synchronisation de cette machine, et notre copie diffère. aws s3 sync n'a pas de fusion, donc pousser remplacerait les leurs. Lisez les fichiers nommés à voix haute à l'utilisateur, comparez chacun avec la copie du bucket et fusionnez. Ne PAS passer --allow-clobber de votre propre initiative — c'est pour "l'utilisateur a confirmé que notre copie remplace la leur", rien de moins.
```
(cd "$S3" && source ./config.env && \
  aws s3 cp "s3://$BUCKET/$PREFIX/changes/STATUS.md" - --profile "$PROFILE" | diff - ../STATUS.md)
```
Mesuré le 18/09/2026 : un push quatre minutes après qu'un collègue a fermé sa journée a détruit la totalité de sa section STATUS.md ET son registre d'activité — et rien sur cette machine ne semblait anormal par la suite, donc cela est passé inaperçu pendant une journée entière. La garde ne se déclenche pas lorsque notre copie est identique octet pour octet à celle du bucket, donc un fichier que nous venons de tirer n'est jamais une collision.

Si les documents de ticket ont changé, signalez le graphe afin que l'éditeur sache qu'une reconstruction est due :

bash data/knowledge-graph/kg_refresh.sh request "<ce qui a changé et pourquoi c'est important>"
(cd "$S3" && ./data-push.sh --go)

Confirmez qu'il a atterri : (cd "$S3" && ./activity.sh) — le push de cette machine devrait indiquer quelques minutes.

`day status`

(cd "$S3" && ./activity.sh)          # dernier pull/push par machine
(cd "$S3" && ./activity.sh --log)    # flux d'événements complet
(cd "$S3" && ./publisher.sh status)  # qui peut reconstruire et publier le KG

⚠️ Ce qui est rapporté correspond à ce qui a été enregistré. Une machine qui n'a jamais exécuté les scripts instrumentés n'affiche rien ; l'absence d'enregistrement n'est pas une preuve d'absence d'activité.

`day baton` — transfert du rôle d'éditeur

Une seule machine publie le graphe de connaissances, car aws s3 sync est basé sur le principe du dernier écrit gagne, sans fusion : deux éditeurs détruisent silencieusement les noms de communauté rédigés à la main l'un de l'autre. Le témoin est un verrou consultatif conservé dans le bucket, de sorte que chaque machine peut le vérifier.

(cd "$S3" && ./publisher.sh status)
(cd "$S3" && ./publisher.sh release)            # machine sortante, EN PREMIER
(cd "$S3" && ./publisher.sh claim "why")        # machine entrante, EN SECOND

La machine réceptrice doit également définir MACHINE_ROLE="publisher" dans config.env et ré-exécuter ./identity.sh --write, sinon son agent continue de lire CONTRIBUTOR et refuse le travail qu'elle possède désormais. claim --force ignore un témoin détenu — confirmez avec l'utilisateur à chaque fois.

Règles qui s'appliquent dans toutes les branches

Jamais --delete. Réservé à l'éditeur, délibéré, et uniquement immédiatement après un nouveau pull.
Supprimer du magasin partagé se fait avec ./delete.sh (éditeur), jamais avec aws s3 rm ou --delete — sinon les autres machines le téléchargeront à nouveau lors de leur prochain push.
Ne jamais pousser knowledge-graph/ depuis un contributeur. L'outil l'applique ; ne contournez pas cette règle.
Reconnectez-vous avant de diagnostiquer une erreur d'accès — l'erreur décrit votre jeton en cache.
L'humain est propriétaire des actions externes. Ce skill synchronise l'enregistrement partagé ; il ne pousse pas les branches, n'ouvre pas de PR, ne déploie pas et n'envoie pas de message à personne.

olonok69/cursor_code_ml_engineer

Qu'est-ce que cursor_code_ml_engineer ?

Demander à votre IA préférée

Documentation