Git / CI workflow

Gouvernance minimale introduite en E11-T11. Complète naming-conventions.md (convention de nommage des fichiers/dossiers) — ne la duplique pas.

Branches#

• master est la source de vérité. Ne jamais y pousser directement de travail en cours ; passer par une branche feature/…, fix/…, chore/… puis une Pull Request.
• Une branche est supprimable (locale : git branch -d ; distante : git push origin --delete) uniquement si elle est entièrement fusionnée dans origin/master (git log origin/master..origin/<branche> vide) et non attachée à un worktree actif (git worktree list). Ne jamais utiliser -D (force) ni push --delete sans avoir vérifié ces deux conditions.
• Ne jamais supprimer : master, la branche courante, ou une branche listée par git worktree list.

Worktrees#

Le dépôt utilise des worktrees Git pour paralléliser du travail agent (.claude/worktrees/*) ou une ligne de travail dédiée (isnad-app-fr-e4-data). Avant toute suppression de branche, toujours vérifier git worktree list — une branche attachée à un worktree ne doit jamais être supprimée, même si elle apparaît « fusionnée ».

CI (.github/workflows/ci.yml)#

Déclenchée sur push/PR vers master. Trois étapes : npx tsc --noEmit, npm run test:ci (suite déterministe non-mutante, voir ci-dessous), puis npm run build. Permissions minimales (contents: read), aucun secret de production, aucune écriture DB possible.

npm run test:ci est l'entrée canonique automatisée — volontairement restreinte à une allowlist de tests locaux, déterministes, sans accès réseau/production : test:openiti-reading, test:book-workspace, test:silent-failure-guard, test:hadithrank, test:hadith-aggregate-writer-provenance, test:knowledge-s1-3-local. Ne jamais y ajouter un script qui lit .env.local, appelle supabase db query --linked, ou accède à la production (voir les scripts suffixés :live ou :sql, et la famille *-real.mjs de E4 — ceux-ci restent des outils d'investigation manuelle, jamais du CI).

Protection de branche recommandée pour master#

Non appliquée par cette tâche (accès gh api non authentifié dans cet environnement — voir planning/reports/e11-t11-git-ci-governance-report.md §13). Réglages recommandés, à activer manuellement dans GitHub (Settings → Branches → Branch protection rules) :

• Require a pull request before merging (au moins 1 review si l'équipe grandit).
• Require status checks to pass before merging → cocher le job CI (validate).
• Require branches to be up to date before merging.
• Do not allow force pushes.
• Do not allow deletions.

Commits#

Messages en anglais, format court type(scope): description (voir l'historique existant pour les préfixes déjà en usage : feat, fix, chore, refactor, docs, test, ci). Pas de git commit --amend sur un commit déjà poussé.