Cortadel Doctor

Que fait Cortadel Doctor ?

Diagnostic d'installation de bout en bout. Exécutez chaque vérification ci-dessous et signalez-les toutes — ne vous arrêtez pas à la première erreur. N'utilisez jamais le helper api() de cortadel-plugin/scripts/lib.mjs pour cela : il avale tous les échecs (non-2xx, timeout, erreur réseau) en null, ce qui est exactement le contraire de ce qu'il faut pour un diagnostic dont le seul travail est de distinguer un 401 d'un résultat nul. Utilisez curl brut (ou les outils MCP directement) pour que les vrais codes de statut et corps d'erreur restent visibles.

Exécution

Vérification 1 — Résolution de configuration

Résolvez les mêmes valeurs requises que les hooks du plugin résolvent (base_url, user_id, api_key), d'abord par le niveau CLAUDE_PLUGIN_OPTION_<KEY>, puis par le niveau des variables d'environnement CORTADEL_* — cela reproduit la précédence de cfg()/readOption() de cortadel-plugin/scripts/lib.mjs :

for pair in "CLAUDE_PLUGIN_OPTION_BASE_URL:CORTADEL_URL" \
            "CLAUDE_PLUGIN_OPTION_USER_ID:CORTADEL_USER_ID" \
            "CLAUDE_PLUGIN_OPTION_API_KEY:CORTADEL_API_KEY"; do
  opt="${pair%%:*}"; fallback="${pair##*:}"
  val="${!opt:-${!fallback:-}}"
  if [ -n "$val" ]; then echo "$fallback: résolu"; else echo "$fallback: NON DÉFINI"; fi
done

RÉUSSI si les trois se résolvent en une valeur non vide ; ÉCHEC — et signalez les vérifications restantes comme « ignorées, pas de configuration » — si l'une est vide. N'affichez jamais la valeur réelle de la clé API, seulement si elle a été résolue.

Mise en garde, dite clairement à l'utilisateur si pertinent : CLAUDE_PLUGIN_OPTION_* est documenté comme étant injecté dans les sous-processus des hooks spécifiquement. Que cela soit également visible dans l'exécution shell d'une compétence n'est confirmé par rien dans ce dépôt — vérifiez les deux niveaux et signalez lequel a réellement résolu chaque valeur, plutôt que de supposer que le niveau du marché est accessible ici.

Vérification 2 — Santé du serveur (non authentifié)

GET /api/health ne nécessite aucune information d'identification — c'est le bon premier test réseau, indépendant du fait que votre propre clé API soit valide :

curl -s "$CORTADEL_URL/api/health"

Signalez le status de niveau supérieur (ok ou degraded) et, s'il est présent, la carte checks (par exemple checks.memgraph.ok, checks.embeddings.ok). Une réponse degraded/503 est un résultat normal et non exceptionnel à signaler — pas une raison pour arrêter d'exécuter les vérifications restantes.

Vérification 3 — Authentification

curl -s -o /tmp/cortadel-doctor-auth.json -w "HTTP %{http_code}\n" \
  -H "Authorization: Bearer $CORTADEL_API_KEY" \
  "$CORTADEL_URL/api/v1/memories?user_id=$CORTADEL_USER_ID&size=1"

• 200 → RÉUSSI.
• 401 → ÉCHEC — clé API manquante ou invalide.
• 403 → ÉCHEC — la clé est valide mais ne correspond pas à user_id.
• autre → ÉCHEC — signalez le code de statut et le corps de la réponse.

Vérification 4 — Lecture en direct

Si la vérification 3 a renvoyé 200, lisez /tmp/cortadel-doctor-auth.json : confirmez qu'il s'analyse comme JSON et qu'il a un tableau items et un compteur total (la forme de MemoryListPagedResponse). Signalez total comme le nombre de mémoires de l'installation — c'est le seul chiffre agrégé que le serveur expose ; il n'y a pas de point d'accès stats séparé, donc c'est toute l'étendue des « statistiques » disponibles.

Si le serveur MCP cortadel est également connecté dans cette session, appelez en plus mcp__cortadel__search_memory({ topK: 1 }) (pas de query — mode navigation) comme second chemin de lecture en direct indépendant via la surface MCP plutôt que REST. Signalez-le séparément : un échec REST avec un échec MCP (ou l'inverse) permet de déterminer quelle moitié de l'installation est réellement cassée. Ignorez cette sous-vérification — ne la faites pas échouer — si l'outil MCP n'est pas disponible dans la session actuelle.

Affichage

Signalez les quatre vérifications ensemble, RÉUSSI/ÉCHEC/ATTENTION par vérification, par exemple :

Résolution config   RÉUSSI  base_url, user_id, api_key tous résolus (niveau CORTADEL_*)
Santé serveur       RÉUSSI  status=ok
Authentification    RÉUSSI  HTTP 200
Lecture en direct   RÉUSSI  total=142 mémoires ; MCP search_memory : RÉUSSI

Si une vérification échoue, ajoutez des étapes concrètes reflétant la section Dépannage de docs/plugin.md : 401 → vérifiez CORTADEL_API_KEY ; 403 → vérifiez que CORTADEL_USER_ID correspond à l'utilisateur de la clé ; santé dégradée → pointez vers l'entrée checks.* qui a échoué.