Fact-Check-X 统一入口
本技能只做编排，不内嵌三个业务层。它按以下顺序调用兄弟技能：
llm-answer-reference-compare：多平台回答、引用与现场存证采集。fact-check-x-knowledge-compare：本地知识点结构化对比，可选。fact-check-x-authoritative-verify：逐知识点并发权威核验与平台表现报告。
所有语义拆解和证据裁决由当前承载技能的智能体完成。脚本不调用任何模型 API。
Dépendances
Les quatre compétences peuvent être exécutées directement si elles se trouvent dans le même répertoire. Vous pouvez également définir :
export FACTCHECK_SKILLS_DIR="<chemin du répertoire parent des quatre compétences>"
Vérifier les dépendances :
python3 scripts/fact_check_x.py locate
Flux complet
Collectez d'abord results.json, puis préparez la comparaison des connaissances :
python3 scripts/fact_check_x.py prepare-comparison \
--results <results.json> \
--run-dir <run>
La commande génère de manière synchrone le rapport des réponses et citations originales, produit 01-capture-report.html à la racine du répertoire d'exécution et renvoie le chemin visible par l'utilisateur via deliverables. L'appelant doit d'abord envoyer le vrai lien Markdown vers ce fichier, puis continuer la comparaison des connaissances ; il est interdit d'afficher uniquement le chemin entre guillemets inversés.
En mode interactif par défaut, l'appelant, après avoir envoyé les artefacts de cette phase, doit demander à l'utilisateur de choisir entre "Continuer l'étape suivante", "Corriger le résultat actuel" ou "S'arrêter ici et conserver les artefacts". Il ne peut passer à l'étape suivante qu'après avoir reçu une instruction de continuer. L'exécution continue n'est autorisée que si l'utilisateur a explicitement demandé une exécution automatique complète dans la demande initiale, mais les artefacts de chaque phase doivent toujours être présentés progressivement.
L'agent en cours lit <run>/comparison-task.json, écrit <run>/comparison-analysis.json, puis exécute :
Lors du découpage, l'atomicité contraint à la fois les points de connaissance et les claim de chaque plateforme. Une phrase originale contenant plusieurs obligations, conditions, objets, valeurs ou conséquences indépendants doit être décomposée ; chaque claim ne conserve que le fait actuel. Les faits substantiels nouveaux propres à une plateforme doivent également être créés comme des points de connaissance sans point d'ancrage, et ne peuvent pas être fusionnés dans un point de connaissance large pour réutiliser un point d'ancrage de confiance déjà vérifié.
python3 scripts/fact_check_x.py complete-comparison \
--results <results.json> \
--run-dir <run>
La commande génère 02-comparison-report.html à la racine du répertoire d'exécution et renvoie le chemin via deliverables ; l'appelant doit le présenter à l'utilisateur comme un fichier indépendant cliquable. Le rapport doit contenir une ébauche globale clairement marquée comme "Non vérifiée". En mode interactif par défaut, l'utilisateur doit confirmer la continuation avant de passer à la vérification autoritaire.
Générer des requêtes cloud indépendantes pour chaque point de connaissance et effectuer des recherches concurrentes :
python3 scripts/fact_check_x.py prepare-authority --run-dir <run>
python3 scripts/fact_check_x.py search-authority --run-dir <run> --max-workers 12
S'il existe des points de connaissance non exemptés de vérification mais qu'aucune configuration de recherche de confiance n'est disponible localement, prepare-authority et search-authority renvoient status=configuration_required, userPrompt et configuration.command et se terminent avec un code non nul. L'appelant affiche d'abord une invite de connexion, puis exécute la commande au premier plan. L'utilisateur n'a qu'à se connecter sur la page Shenshen MaaS qui s'ouvre automatiquement ; le composant réutilise automatiquement toute clé existante, ou crée une clé dédiée Fact-Check-X si aucune n'existe, la vérifie et la sauvegarde dans ~/.fact-check-x/credentials/trusted-search-key. Les environnements Codex, Claude Code, WorkBuddy, etc. partagent cette configuration ; si une clé existe déjà, la connexion est automatiquement ignorée. Une fois la configuration réussie, l'appelant relance automatiquement prepare-authority ; il est interdit de demander à l'utilisateur de copier la clé, de modifier la configuration shell, de répondre "configuré", ou d'utiliser d'autres sources ou recherches classiques pour contourner la recherche de confiance.
Ce n'est que lorsque la recherche de confiance renvoie 401/403 que la clé existante est considérée comme invalide et que la configuration automatique est déclenchée. En cas de timeout, de panne réseau ou de service anormal, la configuration existante est conservée et une nouvelle tentative automatique est effectuée ; si la tentative échoue encore, l'exécution reste dans la phase de recherche et renvoie une erreur technique, sans demander à l'utilisateur de se reconnecter et sans passer à une vérification manuelle des faits.
prepare-authority écrit authority-gate.json. Ce n'est qu'après la fin normale du lot de recherche de confiance et que l'état du gate est devenu searched que finalize-authority est autorisé à s'exécuter ; l'écriture manuelle des preuves ou des résultats ne peut pas contourner cette condition.
L'agent en cours lit un par un les authority/requests et authority/evidence, écrit les verdicts dans authority/assessments/<ID-du-point-de-connaissance>.json, puis :
En mode exemption, trustedAnchor.officialAnswer est la conclusion autoritaire pour le point de connaissance actuel ; la liste des preuves d'ancrage est utilisée pour la traçabilité des sources, sans exiger que le titre ou les extraits tronqués répètent textuellement cette conclusion. Lorsque la revendication de la plateforme est sémantiquement cohérente avec officialAnswer ou peut en être directement déduite, le verdict est supported avec référence aux IDs de preuves d'ancrage valides. Ce n'est que lorsque la revendication de la plateforme ajoute un fait substantiel non pris en charge par la conclusion autoritaire, ou lorsqu'il est vraiment impossible de trancher, que insufficient est utilisé. La fidélité des citations dans la phase de comparaison des connaissances et l'exactitude factuelle dans cette phase sont conservées séparément ; l'incapacité d'une plateforme à citer correctement ne justifie pas de refuser de juger une revendication déjà confirmée par une conclusion autoritaire.
{
"authoritativeFinding": "Conclusion du point de connaissance soutenue par des preuves autoritaires",
"verdicts": {
"<ID de la plateforme>": {
"verdict": "supported",
"reason": "La revendication est cohérente avec E1",
"evidenceIds": ["E1"]
}
}
}
verdict ne peut utiliser que supported, contradicted ou insufficient ; les IDs de preuves doivent exister dans le fichier de preuves actuel. Les anciens champs de niveau supérieur verdict, officialAnswer, platformAssessment seront rejetés.
python3 scripts/fact_check_x.py finalize-authority --run-dir <run>
finalize-authority génère la réponse finale après vérification autoritaire : elle intègre les points de connaissance avec suffisamment de preuves dans la réponse définitive, et écrit les points de connaissance avec des preuves insuffisantes dans evidenceGaps, en les excluant de la réponse définitive et du dénominateur du taux de précision. Tant que la chaîne technique réussit, la commande renvoie status=completed, et l'appelant continue à la quatrième étape. Ce n'est que si la commande technique se termine avec un code non nul que l'exécution s'arrête et que la phase en cours est réessayée.
Après avoir terminé les verdicts, finalize-authority génère indépendamment 03-authority-report.html et renvoie le chemin via deliverables. L'appelant doit d'abord présenter ce rapport autoritaire ; en mode interactif par défaut, ce n'est que si l'état est completed et que l'utilisateur confirme la continuation que la commande suivante est exécutée :
python3 scripts/fact_check_x.py deliver --results <results.json> --run-dir <run>
Lorsque la recherche de confiance renvoie no_evidence, cela est enregistré comme insufficient_evidence : un résultat vide signifie seulement qu'aucun matériel exploitable n'a été obtenu pour ce réglage, et ne peut pas être interprété directement comme une "fabrication". Les rapports ultérieurs sont générés après la finalisation de l'enregistrement de la frontière des preuves.
deliver doit générer et renvoyer, dans le répertoire racine d'exécution, quatre rapports indépendants lisibles :
01-capture-report.html: Réponses originales, références bibliographiques et preuves de citation ;02-comparison-report.html: Comparaison structurée des connaissances ;03-authority-report.html: Conclusions autoritaires par point de connaissance, preuves officielles et verdicts par plateforme ;04-final-report.html: Performances des plateformes, indicateurs globaux, constats clés et preuves complètes.
Si l'un des rapports manque, le package 05-complete-report-package.zip ne doit pas être généré ni livré.
Conserver définitivement :
capture/results.json,capture/report.html,capture/report.md;comparison-task.json,comparison-analysis.json,comparison.json,comparison.html;- Pour chaque point de connaissance : request, evidence, assessment, result indépendants ;
authority/batch.json,verification.json,report.html,pipeline.json;- Les quatre rapports de phase et
05-complete-report-package.zip.
Ignorer la comparaison des connaissances
La comparaison des connaissances est une capacité optionnelle. Si des points de connaissance structurés existent déjà, vous pouvez créer directement des requêtes de points de connaissance individuels conformément au contrat de données du module de vérification autoritaire et appeler fact-check-x-authoritative-verify de manière indépendante. L'entrée unifiée ne force pas l'utilisateur à collecter d'abord plusieurs réponses d'IA.
Limites d'exécution
- La phase de collecte des réponses originales se limite à la collecte, sans vérification. La recherche de confiance peut compléter le texte intégral des sources déjà fournies par la plateforme avec des paramètres complets, mais ne doit pas ajouter ni remplacer de citations.
- La comparaison des connaissances se limite à comparer les réponses originales avec les sources fournies ; pas de recherche en ligne pour la vérité.
- La couche cloud ne reçoit que le point de connaissance actuel ; si les revendications sont identiques, ne pas télécharger ; ne télécharger que les différences.
- Si Shenshen possède déjà un point d'ancrage officiel qualifié, ne pas rechercher à nouveau.
- Le rapport final doit utiliser le moteur de rendu stable du module de vérification autoritaire.
Validation de livraison
python3 tests/smoke_test.py
python3 "${CODEX_HOME:-$HOME/.codex}/skills/.system/skill-creator/scripts/quick_validate.py" .
Les critères complets sont détaillés dans les Critères d'acceptation.