Découvert le 2026-08-09 en marge de #368 (hors rayon d'impact de cette PR, donc déposé plutôt que corrigé).
Symptôme
Sur cette machine, python -m mcp_server.hooks.agent_briefing sort systématiquement :
[cortex-agent-briefing] skip: agent 'engineer' not a specialist
et n'émet aucun briefing, quel que soit le spécialiste passé.
Cause
_load_specialist_agents() (mcp_server/hooks/agent_briefing.py:132-157) scanne
~/.claude/agents/*.md + genius/*.md et ne retombe sur _FALLBACK_AGENTS
(:98-111) que si le répertoire est absent :
root = Path.home() / ".claude" / "agents"
if not root.is_dir():
return _FALLBACK_AGENTS
...
return frozenset(names) if names else _FALLBACK_AGENTS
Depuis la migration des agents vers le plugin, ~/.claude/agents/ existe mais ne
contient plus qu'un dispatch.md — les agents réels vivent dans le plugin. Le
roster vaut donc {"dispatch"} : non vide, donc pas de repli, et tout
spécialiste (engineer, tester, …) est rejeté. Le mécanisme est câblé mais
inatteignable.
Pourquoi la CI ne l'attrape pas
En CI, ~/.claude/agents/ n'existe pas → premier return → _FALLBACK_AGENTS
contient engineer → vert. Les deux tests concernés passent en CI et échouent
en local :
tests_py/hooks/test_hook_receipts.py::test_agent_briefing_emits_receipt_with_marker
tests_py/hooks/test_hook_receipts.py::test_agent_briefing_skips_superseded_prior_work
Vérifié préexistant à #368 : mêmes deux échecs avec le facteur de confiance
remis à l'identité (git stash de retrieval_dispatch.py). Suite complète au
même moment : 7412 passés, ces 2 échecs.
C'est la forme d'un échec silencieux : le seul environnement où le hook est
réellement exercé est celui où il ne peut pas fonctionner, et le seul
environnement où les tests le déclarent sain est celui où le répertoire est
absent.
Pistes (à trancher, pas une décision)
- Découvrir les agents là où ils vivent maintenant (répertoires du plugin) en
plus de ~/.claude/agents/.
- Traiter un roster qui ne contient que
dispatch comme un roster vide
(fusionner avec le repli au lieu de le remplacer).
- Rendre la source du roster injectable, pour que les tests l'exercent sans
dépendre du $HOME de la machine.
Toute correction devrait s'accompagner d'un test qui échoue quand le roster
résolu ne contient aucun spécialiste — sinon la CI restera aveugle au même
mode de panne.
Découvert le 2026-08-09 en marge de #368 (hors rayon d'impact de cette PR, donc déposé plutôt que corrigé).
Symptôme
Sur cette machine,
python -m mcp_server.hooks.agent_briefingsort systématiquement :et n'émet aucun briefing, quel que soit le spécialiste passé.
Cause
_load_specialist_agents()(mcp_server/hooks/agent_briefing.py:132-157) scanne~/.claude/agents/*.md+genius/*.mdet ne retombe sur_FALLBACK_AGENTS(
:98-111) que si le répertoire est absent :Depuis la migration des agents vers le plugin,
~/.claude/agents/existe mais necontient plus qu'un
dispatch.md— les agents réels vivent dans le plugin. Leroster vaut donc
{"dispatch"}: non vide, donc pas de repli, et toutspécialiste (
engineer,tester, …) est rejeté. Le mécanisme est câblé maisinatteignable.
Pourquoi la CI ne l'attrape pas
En CI,
~/.claude/agents/n'existe pas → premierreturn→_FALLBACK_AGENTScontient
engineer→ vert. Les deux tests concernés passent en CI et échouenten local :
tests_py/hooks/test_hook_receipts.py::test_agent_briefing_emits_receipt_with_markertests_py/hooks/test_hook_receipts.py::test_agent_briefing_skips_superseded_prior_workVérifié préexistant à #368 : mêmes deux échecs avec le facteur de confiance
remis à l'identité (
git stashderetrieval_dispatch.py). Suite complète aumême moment : 7412 passés, ces 2 échecs.
C'est la forme d'un échec silencieux : le seul environnement où le hook est
réellement exercé est celui où il ne peut pas fonctionner, et le seul
environnement où les tests le déclarent sain est celui où le répertoire est
absent.
Pistes (à trancher, pas une décision)
plus de
~/.claude/agents/.dispatchcomme un roster vide(fusionner avec le repli au lieu de le remplacer).
dépendre du
$HOMEde la machine.Toute correction devrait s'accompagner d'un test qui échoue quand le roster
résolu ne contient aucun spécialiste — sinon la CI restera aveugle au même
mode de panne.