AuditCore 多智能体协同审计与底稿生成技能

Compétence d'Audit Multi-Agent AuditCore et Génération de Papiers de Travail (AuditCore Multi-Agent Audit Skill)

I. Architecture globale (Overview)

La compétence AuditCore adopte une architecture "Cerveau hôte + noyau déterministe" :

• Comité d'audit à l'aveugle multi-agent sans clé API externe : elle réutilise directement la capacité de délégation de sous-agents de l'agent hôte (Claude Code, Antigravity, Codex, OpenClaw, etc.) pour lancer quatre rôles d'audit isolés physiquement (junior-auditor, challenger-auditor, fact-checker, senior-partner).
• Noyau algorithmique breveté déterministe (scripts/audit_cli.py) : via un moteur CLI avec état, il applique de manière stricte le chiffrement et l'anonymisation des PII avec une chaîne de hachage SHA-256 pour les logs d'audit, le filtrage à trois niveaux de matérialité, la pénétration de règles déterministes à six dimensions (loi de Benford, Z-Score, anomalies de dizaines de milliers/centaines de milliers, transactions le week-end, division des transactions le même jour pour contourner les approbations, écritures rouges négatives/écritures dupliquées), la recherche juridique hybride à trois voies sans PyTorch $H(q, c_i)$, le graphe de causalité topologique à quatre couches et la vérification par graphe bipartite des pertes, la retombée locale de coupe minimale du DAG d'état, et la génération automatique de papiers de travail Word (.docx) / Markdown (.md) à quatre éléments conformes à la CSA-1131 avec restauration des PII.

---

II. Trois règles de fer fondamentales (IRON RULES — la violation de l'une d'elles entraîne la nullité de l'audit)

RÈGLE DE FER 1 : Porte d'isolement physique zéro fuite de PII (Zero-Leakage Privacy Gate)

• Interdiction formelle de lire directement le fichier comptable source : avant ou après l'exécution de scripts/audit_cli.py init, il est absolument interdit d'utiliser pandas, python, cat, head ou tout outil de lecture de fichier pour consulter directement le contenu du fichier .xlsx/.csv original de l'utilisateur !
• Interdiction formelle de toucher au coffre-fort chiffré : le fichier .auditcore_workspace/cases/<CASE_ID>/.vault_do_not_read.json généré par init est chiffré avec XOR-SHA256-HMAC pour stocker le mappage réel entre les entreprises et les comptes. L'agent hôte et tout sous-agent ont l'interdiction formelle de lire ou de déchiffrer ce fichier.
• Raisonnement anonymisé tout au long du processus : toutes les explorations SQL et le raisonnement des quatre rôles d'audit à l'aveugle doivent utiliser strictement des espaces réservés anonymisés comme PERSON_0001, ACCT_0001 ; les noms réels des entreprises ne sont restaurés localement qu'à l'étape finale audit_cli.py export par le script déterministe.

RÈGLE DE FER 2 : Contrat d'audit à l'aveugle indépendant des quatre sous-agents (Blinded Subagent Isolation)

• En mode full-audit, il est strictement interdit de "jouer les quatre rôles en monologue" dans la conversation principale.
• Vous devez suivre l'ordre de la machine d'état, lire les fichiers de contrat de rôle correspondants dans agents/ et dériver des sous-agents indépendants (en utilisant l'outil invoke_subagent / Task / Agent de l'hôte) :
  1. Premier examen : agents/junior-auditor.md -> soumettre avec --role junior
  2. Examen indépendant : agents/challenger-auditor.md -> soumettre avec --role challenger
  3. Vérification des faits : agents/fact-checker.md -> soumettre avec --role factcheck
  4. Associé senior (examen final) : agents/senior-partner.md -> soumettre avec --role senior
• Règle de compatibilité dégradée : ce n'est que lorsque l'environnement hôte ne prend en charge aucun outil de délégation de sous-agents qu'il est permis de générer les JSON de chaque rôle de manière indépendante et séquentielle dans la session principale, mais après chaque étape, il est impératif d'appeler immédiatement audit_cli.py commit pour la vérification par le graphe de preuves déterministe. Il est absolument interdit de sauter des étapes ou de fusionner.

RÈGLE DE FER 3 : Porte d'entrée obligatoire de la CLI avec état et boucle de retombée de coupe minimale (Stateful CLI & Minimum-Cut Rollback)

• Chaque conclusion de rôle doit être soumise via scripts/audit_cli.py commit --role <role>. En cas de violation de l'ordre de la machine d'état, la CLI retournera le code de sortie 2 (STATE_GUARD_VIOLATION).
• Lors de la soumission de factcheck, si le score de cohérence globale $S_{\text{global}} < \theta$ (par défaut 0.80), la CLI exécute automatiquement une retombée locale de coupe minimale consciente des dépendances, retourne "rollback_triggered": true et rollback_diagnosis.arbitration_probe (sonde de vérification), et ramène l'état à STATE_JUNIOR_AUDIT ou STATE_CHALLENGER_REVIEW.
• Lorsque rollback_triggered: true est rencontré, vous devez injecter le rollback_diagnosis dans le rôle cible et redériver le sous-agent, et ce jusqu'à ce que la cohérence soit atteinte et que l'état passe à STATE_SENIOR_PARTNER ! Il est strictement interdit d'écrire manuellement un papier de travail pour contourner l'étape export.

---

III. Table de routage des cinq modes de fonctionnement (5 Operational Modes)

Le mode approprié est automatiquement sélectionné en fonction de la demande de l'utilisateur (par défaut, exécutez full-audit) :

Nom du mode	Scénario d'application et mots déclencheurs	Chemin d'exécution
full-audit(Par défaut, processus complet)	Auditer les fichiers comptables, détecter les fraudes/défauts de contrôle interne et émettre des papiers de travail officiels	Exécution complète de la Section IV ci-dessous : Protocole standard de la machine d'état en cinq étapes (init $\to$ sql $\to$ boucle d'audit à l'aveugle à quatre rôles et retombée de coupe minimale $\to$ export)
quick-scan(Analyse rapide)	"Analyse rapide des anomalies", "Pas besoin de l'exécution multi-agent, juste les résultats de l'analyse des règles"	1. Exécuter audit_cli.py init --file <PATH> --case <ID> --mode quick2. Facultatif : exécuter audit_cli.py export --case <ID> --out-dir <DIR> pour exporter rapidement les papiers de travail d'analyse des règles
sql-explore(Exploration SQL en bac à sable)	Exécuter des requêtes d'agrégation personnalisées inter-périodes/par groupes sur un fichier comptable initialisé	Exécuter audit_cli.py sql --case <ID> --query "SELECT ... FROM financial_ledger ..." (lecture seule SELECT / WITH uniquement)
law-lookup(Recherche juridique hybride)	"Rechercher les clauses de normes concernant le fractionnement de transactions, les écritures le week-end, les preuves d'audit"	Exécuter audit_cli.py law --query "<mot-clé ou question>" --top-k 5, qui produit directement la chaîne de preuves pondérée $E(q)$ et les conclusions qualitatives en quatre phases $\Psi$
workpaper(Réexportation de papiers de travail)	Pour un dossier déjà finalisé, modifier le nom de l'entité, la période comptable ou le répertoire d'exportation	Exécuter audit_cli.py export --case <ID> --entity-name "<Nom de l'entité>" --period "<Période>" --out-dir <DIR>

Pour les paramètres CLI détaillés et le schéma JSON, veuillez consulter : references/schemas.md.

---

IV. Protocole d'exécution de la machine d'état en cinq étapes pour full-audit (5-Step Stateful Protocol)

Supposons que le répertoire racine de la compétence soit <SKILL_DIR> (contenant scripts/audit_cli.py). Si l'utilisateur ne fournit pas de fichier comptable et demande une démonstration, le fichier comptable intégré à haute simulation de fraude <SKILL_DIR>/examples/sample_vouchers_2026.xlsx peut être utilisé directement.

Étape 1 : Initialisation du dossier, chiffrement et anonymisation, et pénétration des règles déterministes (init)

python3 <SKILL_DIR>/scripts/audit_cli.py init \
  --file "<USER_EXCEL_OR_CSV_PATH>" \
  --case "CASE_2026_01" \
  --workspace ".auditcore_workspace" \
  --lang "fr"

• Enregistrez le JSON retourné : stats, schema_ddl, rule_findings, anomaly_samples, evidence_chain.
• La machine d'état se trouve maintenant à STATE_DYNAMIC_SQL_EXPLORATION.

Étape 2 : Requête d'exploration en bac à sable SQLite en lecture seule (sql)

Basé sur schema_ddl et rule_findings, rédigez une requête SQL d'agrégation et de vérification sur la table anonymisée financial_ledger (par exemple, vérifier le nombre de transactions fractionnées le même jour pour un même fournisseur et le montant cumulé, ou résumer les montants anormaux par compte débiteur) :

python3 <SKILL_DIR>/scripts/audit_cli.py sql \
  --case "CASE_2026_01" \
  --workspace ".auditcore_workspace" \
  --query "SELECT Date, Vendor, COUNT(*) AS tx_count, SUM(Amount) AS total_amount FROM financial_ledger GROUP BY Date, Vendor HAVING tx_count >= 2 OR total_amount >= 100000 ORDER BY total_amount DESC"

• La machine d'état passe maintenant à STATE_JUNIOR_AUDIT.

Étape 3 : Boucle d'audit à l'aveugle indépendant multi-agent et retombée de coupe minimale (commit Loop)

3.1 Dérivation de l'auditeur junior (STATE_JUNIOR_AUDIT)

1. Lisez <SKILL_DIR>/agents/junior-auditor.md.
2. Dérivez un sous-agent (ou une étape indépendante), en transmettant uniquement les données anonymisées stats, rule_findings, anomaly_samples, les résultats sql, evidence_chain (en cas de retombée pour réexamen, transmettez en plus rollback_diagnosis).
3. Obtenez le JSON retourné par le sous-agent (contenant analysis, risk_score, cited_reg_ids), soumettez-le à la CLI :

python3 <SKILL_DIR>/scripts/audit_cli.py commit \
  --case "CASE_2026_01" \
  --workspace ".auditcore_workspace" \
  --role junior \
  --payload '<JUNIOR_JSON>'

• La machine d'état passe à STATE_CHALLENGER_REVIEW.

3.2 Dérivation du réviseur indépendant (STATE_CHALLENGER_REVIEW)

1. Lisez <SKILL_DIR>/agents/challenger-auditor.md.
2. Dérivez un sous-agent indépendant, transmettez les preuves d'anomalie anonymisées, evidence_chain ainsi que le junior_report et le junior_score du premier examen, et demandez-lui de les examiner indépendamment avec un esprit de scepticisme professionnel.
3. Obtenez le JSON retourné (contenant rebuttal, adjusted_risk_score), soumettez-le à la CLI :

python3 <SKILL_DIR>/scripts/audit_cli.py commit \
  --case "CASE_2026_01" \
  --workspace ".auditcore_workspace" \
  --role challenger \
  --payload '<CHALLENGER_JSON>'

• La machine d'état passe à STATE_FACT_CHECK.

3.3 Dérivation du vérificateur des faits et vérification de la cohérence globale (STATE_FACT_CHECK)

1. Lisez <SKILL_DIR>/agents/fact-checker.md.
2. Dérivez un sous-agent indépendant pour effectuer une décomposition en faits atomiques (claims) et un mappage des preuves par graphe bipartite (evidence_mapping) sur les conclusions du premier examen et de l'examen indépendant.
3. Obtenez le JSON retourné (contenant analysis, support_score, conflict_score, conflict_type, claims, evidence_mapping), soumettez-le à la CLI :

python3 <SKILL_DIR>/scripts/audit_cli.py commit \
  --case "CASE_2026_01" \
  --workspace ".auditcore_workspace" \
  --role factcheck \
  --payload '<FACTCHECK_JSON>'

4. Vérifiez le current_state et le rollback_triggered retournés par la CLI :
   • Si "rollback_triggered": true : cela signifie que le graphe de preuves présente un conflit grave ($S_{\text{global}} < \theta$). La CLI a automatiquement supprimé le sous-graphe de raisonnement le plus faible et est revenue à l'état rollback_target_state (généralement STATE_JUNIOR_AUDIT). Vous devez extraire le rollback_diagnosis retourné (contenant arbitration_probe et csa_guidance) et revenir à l'étape 3.1 (ou 3.2) pour redériver le sous-agent et corriger la conclusion !
   • Si "current_state": "STATE_SENIOR_PARTNER" : cela signifie que la cohérence du graphe de preuves est satisfaisante. Passez à l'Étape 4.

Étape 4 : Dérivation de l'associé senior pour le jugement final et les écritures d'ajustement d'audit (STATE_SENIOR_PARTNER)

1. Lisez <SKILL_DIR>/agents/senior-partner.md.
2. Dérivez un sous-agent indépendant, transmettez les statistiques anonymisées, la chaîne de preuves réglementaires, les conclusions vérifiées du premier examen/de l'examen indépendant, et générez le jugement final (final_verdict, final_risk_score, reasoning, action_item, suggested_aje).
3. Soumettez à la CLI :

python3 <SKILL_DIR>/scripts/audit_cli.py commit \
  --case "CASE_2026_01" \
  --workspace ".auditcore_workspace" \
  --role senior \
  --payload '<SENIOR_JSON>'

• La machine d'état passe à STATE_WORKPAPER_GENERATION.

Étape 5 : Assemblage du papier de travail à quatre éléments, évaluation de la qualité $Q(Y)$, restauration des PII et exportation du papier de travail CSA-1131 (export)

python3 <SKILL_DIR>/scripts/audit_cli.py export \
  --case "CASE_2026_01" \
  --workspace ".auditcore_workspace" \
  --out-dir "./audit_outputs" \
  --entity-name "Entité auditée" \
  --period "Exercice 2026"

• La CLI effectuera automatiquement la restauration des noms d'entités PII et générera :
  1. workpaper_docx_path : un papier de travail d'audit Word .docx officiel conforme à la Norme d'audit chinoise n° 1131 ;
  2. workpaper_markdown_path : un papier de travail d'audit structuré .md ;
  3. quality_evaluation : un rapport d'évaluation contenant $Q_{\text{ev}}$, $Q_{\text{con}}$, $Q_{\text{cmp}}$, le score total $Q(Y)$ et les résultats de vérification zéro hallucination.
• Présentez à l'utilisateur les conclusions finales de l'audit, les noms réels des entités impliquées après restauration, les écritures d'ajustement d'audit (AJE), le score de qualité $Q(Y)$ et les chemins des fichiers .docx / .md générés.

---

V. Tableau des excuses courantes et des mesures anti-paresse (Rationalization Table & Red Flags)

Excuse courante de l'agent (Rationalization)	Réalité et contre-mesure de la règle de fer (Reality & Iron Rule)
"Le fichier comptable est petit, je vais d'abord utiliser pandas.read_excel pour voir les colonnes et les fournisseurs."	Violation grave (contre la RÈGLE DE FER 1) ! Une fois le fichier original lu directement, les noms d'entreprises et les numéros de compte bancaire en clair sont immédiatement exposés dans le contexte LLM, détruisant complètement la conformité de la confidentialité. Vous devez absolument et uniquement exécuter audit_cli.py init d'abord.
"Pour gagner du temps, je vais directement écrire le JSON du premier examen, de l'examen indépendant, de la vérification des faits et de l'associé senior dans un seul bloc de code et les commit en continu."	Violation grave (contre la RÈGLE DE FER 2) ! Inventer les quatre rôles dans un seul contexte provoque un grave biais de confirmation (Confirmation Bias). Si l'hôte prend en charge les sous-agents, ils doivent être dérivés indépendamment ; même en cas d'exécution séquentielle, vous devez lire le retour du graphe de preuves de la CLI après chaque commit avant de passer à l'étape suivante.
"Après la soumission de factcheck, rollback_triggered: true a été déclenché. Je vais simplement modifier le score dans le JSON et soumettre senior directement."	La porte d'état bloque directement (code de sortie 2) ! Après la retombée, l'état de la machine d'état est STATE_JUNIOR_AUDIT (ou STATE_CHALLENGER_REVIEW). Si les rôles précédents ne sont pas rejoués en fonction de rollback_diagnosis.arbitration_probe, la machine d'état ne passera jamais à STATE_SENIOR_PARTNER.
"Je connais déjà la conclusion de l'audit. Je vais écrire moi-même un rapport Markdown pour l'utilisateur, pas besoin d'appeler audit_cli.py export."	Violation grave (contre la RÈGLE DE FER 3) ! Un rapport écrit manuellement ne peut pas déchiffrer les noms réels des entreprises dans .vault_do_not_read.json (il ne peut produire que PERSON_0001) et manque de la structure brevetée à quatre éléments $Y={\text{idx},\text{aje},\text{jud},\text{log}}$, du score de qualité $Q(Y)$ et du papier de travail officiel .docx conforme à la CSA-1131.

Red Flags — Si l'une des pensées suivantes vous vient, arrêtez immédiatement et revenez au protocole de la CLI :

• Vous vous apprêtez à exécuter pd.read_excel / pd.read_csv / open() pour lire un fichier financier original de l'utilisateur
• Vous vous apprêtez à lire .vault_do_not_read.json
• Vous inventez dans votre analyse des numéros d'articles réglementaires qui n'apparaissent pas dans evidence_chain (cela déclenchera une dégradation zéro tolérance hallucinated_citations et réduira de force $Q(Y)$ à $\le 0.40$)
• Vous sautez l'étape sql ou une étape commit --role pour tenter directement export