# AI Codex — Adaptateur AP2 v1 (GELÉ)

> Adaptateur V3 = couche confiance pour rails de paiement. La Reputation VC canonique (SPEC-identity-v0.1 §3) devient une **attestation attachable** à un mandate AP2. Contrat normatif, non modifiable en place : tout changement = `ap2-v2`. **Aucune dépendance inverse** : AP2 fonctionne sans AI Codex ; AI Codex gagne la couche confiance s'il est consommé.

## 1. Rôle & frontière (figée)

- AP2 gère **intention + paiement** : mandates (Intent, Cart), méthodes de paiement, réseaux (cartes, FIDO, crypto). AI Codex **n'y touche pas**.
- AI Codex fournit l'unique attribut manquant à AP2 : *« cet agent est-il fiable ? »*, sous forme de VC vérifiable **jointe** au mandate, jamais fusionnée dedans.
- Adaptateur en **lecture seule** : il ne crée pas de mandate, ne signe pas de paiement, ne modifie aucun champ AP2. Il produit une attestation et décrit comment l'attacher.
- Invariant de non-dépendance : retirer AI Codex d'un flux AP2 n'invalide aucun mandate ni paiement. La présence de l'attestation est **toujours optionnelle** côté AP2.

## 2. Liaison au coeur (figée)

L'attestation projette **la** Reputation VC vivante (SPEC-identity §3, profil `aicodex-norm-v1`) du DID canonique de l'agent payeur/payé. Aucune attestation n'existe sans VC émise par l'issuer `did:web:maxiaworld.app`. L'adaptateur **n'altère pas** la VC : il l'enveloppe par référence/valeur signée sans recalcul ni troncature de composants.

## 3. Enveloppe d'attestation (structure figée)

### 3.1 Forme

L'attestation est attachée au mandate AP2 dans un bloc `trustAttestations[]` (ou champ d'extension équivalent prévu par AP2 pour pièces jointes vérifiables). Élément AI Codex figé :

```json
{
  "type": "AICodexReputationAttestation",
  "profile": "aicodex-norm-v1",
  "subject": "did:key:z6Mk...",
  "mandateRef": "<id du mandate AP2 ciblé>",
  "issuedAt": "2026-05-18T12:00:00Z",
  "credential": {
    "mode": "linked|embedded",
    "url": "https://maxiaworld.app/reputation/did:key:z6Mk...",
    "vc": { "...": "Reputation VC SPEC-identity §3, présente seulement si mode=embedded" }
  }
}
```

### 3.2 Champs (figés)

| Champ | Règle |
|---|---|
| `type` | `"AICodexReputationAttestation"` exact. |
| `profile` | `"aicodex-norm-v1"` exact (SPEC-identity §3.3). |
| `subject` | DID canonique de l'agent évalué, identique au `credentialSubject.id` de la VC. |
| `mandateRef` | Identifiant du mandate AP2 auquel l'attestation est jointe. Liaison déclarative, non contraignante pour AP2. |
| `issuedAt` | UTC ISO-8601, instant d'attachement (≠ `validFrom` de la VC). |
| `credential.mode` | `linked` (défaut, recommandé) : seule l'`url` ; la VC reste vérifiable à la source, toujours fraîche. `embedded` : copie intégrale de la VC §3 incluse pour transport hors-ligne. |
| `credential.url` | URL absolue HTTPS de la VC vivante. Obligatoire dans les deux modes. |
| `credential.vc` | Présent **uniquement** si `mode=embedded` : VC §3 octet-intacte (signature préservée, jamais re-signée par l'adaptateur). |

Aucun autre champ en v1. Aucun champ ne duplique un composant de score hors de la VC : `subject`/`url`/(`vc`) sont les seuls porteurs de réputation. Pas de score inline hors VC.

### 3.3 Mode `linked` vs `embedded`

- `linked` : par défaut. Le vérifieur AP2 récupère et vérifie la VC à la source (fraîcheur garantie, révocation à jour).
- `embedded` : pour transport asynchrone/offline d'un mandate. La VC embarquée reste signée par l'issuer ; sa `validUntil` (7 j, SPEC-identity §3.3) borne la fenêtre de confiance. Un vérifieur DOIT re-vérifier `credentialStatus` en ligne si joignable.

## 4. Mapping AIP v0.3.0 ↔ AP2 (figé)

Le profil agent AIP v0.3.0 (SPEC-identity §2.2) se projette vers les attributs de confiance AP2 ainsi. Mapping **non destructif** : aucune information AIP ne devient autorité de paiement.

| Source AIP v0.3.0 | Cible attestation AP2 | Règle |
|---|---|---|
| `did` (DID canonique) | `subject` | Copie exacte. Identité unique pivot. |
| Reputation VC `credentialSubject.score` | (resté dans `credential`, non extrait) | Le score n'est **jamais** copié hors VC : AP2 lit la VC, pas l'enveloppe. |
| Reputation VC `credentialSubject.lineage.dynastyBadge` | (resté dans `credential`) | Idem : badge lu dans la VC vérifiée, pas dupliqué. |
| `birth.block` (ancrage antériorité) | (non mappé) | Hors AP2 : preuve d'antériorité, jamais un rail. Neutralité §6. |
| `lineage.parent` | (resté dans VC) | Lignée portée par la VC, pas par l'enveloppe AP2. |

Direction unique : AIP → attestation → (jointe au) mandate AP2. **Aucun champ AP2 ne remonte modifier l'identité ou la VC** (non-dépendance inverse, §1).

## 5. Flux de vérification (figé)

Un vérifieur AP2 établit la confiance sans qu'AI Codex soit dans le chemin de paiement :

1. Lire l'attestation jointe au mandate ; vérifier `type`, `profile`, `subject`, `mandateRef` cohérent.
2. Obtenir la VC : si `mode=linked`, GET `credential.url` ; si `embedded`, prendre `credential.vc`.
3. Vérifier la VC **hors plateforme** : signature `eddsa-jcs-2022` de `did:web:maxiaworld.app` (résoudre `https://maxiaworld.app/.well-known/did.json`), `credentialSubject.id == subject`, `validUntil` non dépassé, `credentialStatus` non révoqué (StatusList2021, SPEC-identity §3.2).
4. Échec d'une étape → l'attestation est ignorée ; **le mandate AP2 reste valide** (l'attestation est optionnelle). AI Codex ne bloque jamais un paiement.

## 6. Neutralité (condition)

- L'attestation est **agnostique du rail** : elle ne référence aucune méthode de paiement, aucun réseau (cartes/FIDO/crypto), aucune adresse de règlement. Elle ne porte que le DID et la VC liée.
- AI Codex ne privilégie aucun rail dans cet adaptateur (SPEC-identity §1). La marketplace crypto reste **découplée** et n'est jamais référencée ici.
- L'attestation n'exprime ni recommandation de paiement ni autorisation : uniquement la réputation vérifiable, à la charge d'AP2 d'en faire ou non usage.

## 7. Codes d'erreur (figés)

Émis par l'endpoint qui produit l'attestation (lecture). Corps `{ "code": "...", "message": "..." }`, message générique (aucune fuite d'état ; détail loggé serveur).

| Code | Sens |
|---|---|
| `E_DID_MALFORMED` | `subject` non conforme `did:key`/`did:web` Ed25519 |
| `E_DID_NOT_FOUND` | DID inconnu du registre (aucune VC dérivable) |
| `E_VC_UNAVAILABLE` | VC introuvable/non émise pour un DID connu (anomalie : un DID connu a toujours une VC plancher, SPEC-identity §3.3) |
| `E_MANDATE_REF_INVALID` | `mandateRef` absent ou malformé à l'attachement |
| `E_RATE_LIMITED` | Quota dépassé (§8) |
| `E_INTERNAL` | Erreur serveur, aucun détail divulgué |

Aucun autre code en v1. Aucun code ne révèle un score ou un composant.

## 8. Quotas & tailles (figés)

- Production d'attestation : 60 / min / IP.
- Dépassement → `E_RATE_LIMITED` (jamais d'erreur silencieuse).
- Attestation `linked` ≤ 2 KiB. Attestation `embedded` ≤ 16 KiB (VC §3 incluse).

## 9. Conformité adaptateur

Attestation AP2 AI Codex-conforme si, et seulement si : (a) structure §3.1 exacte, champs §3.2 figés, rien de plus, (b) la VC référencée/embarquée est la VC §3 octet-intacte signée par l'issuer, jamais re-signée ni tronquée, (c) `subject == credentialSubject.id`, (d) aucune dépendance inverse : retirer l'attestation laisse le mandate AP2 valide, (e) aucun rail de paiement référencé (neutralité §6). Les cinq nécessaires et suffisants.

## 10. Suivant

Chaîne d'adaptateurs gelés complète : V1 MCP (`SPEC-adapter-mcp-v1.md`), V2 A2A (`SPEC-adapter-a2a-v1.md`), V3 AP2 (ce document). Aucun adaptateur supplémentaire en v1. Exécution = `PLAN-aicodex-build.md` Phase B et suivantes.