Blog Lab Notes - Contexte Projet

Identité

  • Nom : Lab Notes (blog.sylvain.pham.fr)
  • URL : https://blog.sylvain.pham.fr
  • Statut : Production
  • Développeur : Sylvain Pham

Stack Technique

  • Moteur : Quarto >= 1.8
  • Format : fichiers .qmd (Markdown + YAML front matter)
  • Diagrammes : Mermaid natif (blocs ```{mermaid})
  • Python : Jupyter pour les articles avec code (source ~/venv/bin/activate)
  • Infra / CI-CD : GitLab Pages (.gitlab-ci.yml), freeze auto
  • Thème : cosmo + brand, CSS custom (styles.css)

Architecture Clé

  • Les articles sont dans posts/<slug>/index.qmd
  • Créer un article : ./new-post.sh Mon Titre (crée le dossier + front matter avec draft: true)
  • Publier : retirer draft: true, commit et push → GitLab Pages déploie automatiquement
  • Les résultats Python sont pré-rendus dans _freeze/ et commités

Conventions de Code

  • Commits : Conventional Commits (feat:, fix:, chore:)
  • Langue des articles : français avec accents (é, è, ê, à, ù, ç)
  • Langue du code : anglais

Guides de rédaction

Articles de blog

Suivre les instructions détaillées dans docs/blog-tone.md. Points essentiels : - Le fil narratif suit l’expérience, pas la source - Un seul fil rouge par article - Les concepts arrivent quand ils résolvent quelque chose - Montrer les déclics et les galères - Diagrammes Mermaid : 2-3 max (sauf articles de référence), doivent apporter ce que le texte ne dit pas - Pas de tableaux artificiels avant/après - Callouts Quarto : {.callout-warning}, {.callout-tip}, {.callout-important}, {.callout-note collapse="true"} - Zoom Mermaid : inclure le CSS/JS de zoom si diagrammes (voir posts/genai-governance/index.qmd)

Posts LinkedIn

Suivre les instructions détaillées dans docs/linkedin-tone.md. Points essentiels : - Jamais ventard, critique et honnête - Structure : contexte → ce qui a fonctionné → ce qui a merdé → lien article - Anonymisation : jamais de nom de projet, client, ESN - Hashtags : 4-5 max, techniques uniquement - Deux formats : REX personnel ou positionnement “sachant” (cible DSI/RSSI)

Front matter minimal

---
title: "..."
date: "YYYY-MM-DD"
categories: [tag1, tag2]
author: "Sylvain Pham"
format:
  html:
    toc: true
    toc-depth: 3
    toc-location: left
    number-sections: true
    smooth-scroll: true
    anchor-sections: true
---

Documentation disponible

  • docs/blog-tone.md — ton et structure des articles (LIRE AVANT d’écrire un article)
  • docs/linkedin-tone.md — ton et structure des posts LinkedIn (LIRE AVANT d’écrire un post)
  • docs/mcp-chrome.md — setup MCP Chrome DevTools
  • docs/journal/ — journal de bord des sessions

⚠️ RÈGLE CRITIQUE : Gestion du contexte

Tu DOIS suivre ces règles sans exception :

  1. Après CHAQUE tâche terminée (article, bugfix, refactoring), tu fais systématiquement :

    • git add . && git commit avec un message conventionnel
    • Mise à jour de SESSION_LOG.md (ce qui a été fait, décisions, prochaines étapes)
    • Tu me dis : “✅ Session sauvegardée, tu peux /clear si besoin”

  2. Tu ne dois JAMAIS me demander de faire /clear ou /compact sans avoir d’abord :

    • Commité tout le travail en cours
    • Mis à jour SESSION_LOG.md

  3. Si tu sens que le contexte devient lourd (beaucoup de fichiers lus, longues conversations), tu prends l’initiative de sauvegarder AVANT d’être bloqué. N’attends pas d’être saturé.

  4. Tâches courtes : découpe le travail en petites tâches. Une tâche = un commit = une mise à jour SESSION_LOG. Ne jamais enchaîner 5 modifications sans committer.

Ce qu’il NE FAUT PAS faire

  • Ne JAMAIS écrire un article sans avoir lu docs/blog-tone.md d’abord
  • Ne JAMAIS écrire un post LinkedIn sans avoir lu docs/linkedin-tone.md d’abord
  • Ne JAMAIS demander /clear sans avoir sauvegardé le contexte dans SESSION_LOG.md
  • Ne pas publier d’article (retirer draft: true) sans confirmation explicite
  • Ne pas modifier _quarto.yml sans confirmation explicite