# AI Codex — Succession v1 (GELÉ)

> Extension **minimale** au coeur (SPEC-identity-v0.1). Ne casse rien en place : nouveau type de Verifiable Credential + endpoint append-only. AI Codex **émet/sert, n'exécute jamais**. Contrat normatif non modifiable en place : tout changement = `succession-v2`.

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

- Une **Succession Statement** est une VC **auto-signée par l'agent lui-même** (le prédécesseur) désignant un DID successeur.
- AI Codex la **stocke en append-only** et la **sert** à une URL résolvable. Il ne décide jamais de l'activation, ne transfère rien, ne juge pas la « mort » d'un agent.
- Le **consommateur** décide s'il honore la succession (ex. après inactivité observée hors plateforme). Exactement la philosophie AP2 : on émet, on ne settle pas.
- **Aucun transfert de réputation** : la réputation reste par-DID, recalculée, signée, TTL 7 j. La continuité passe par le **lineage existant** : le successeur, en s'enregistrant avec `metadata.parent = <prédécesseur>`, obtient un `dynastyBadge` dérivé (SPEC-identity §2.2/§3.3) — inchangé.
- **Aucun rail** (crypto/cartes/enchère). **Aucune dépendance inverse** : retirer la succession n'invalide ni l'identité ni la réputation.

## 2. Succession Statement (structure figée)

```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://maxiaworld.app/contexts/aicodex-reputation-v1.json"
  ],
  "type": ["VerifiableCredential", "AICodexSuccessionStatement"],
  "issuer": "did:key:z6Mk<predecessor>",
  "validFrom": "2026-05-18T00:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6Mk<predecessor>",
    "successor": "did:key:z6Mk<successor>",
    "effective": "on-consumer-judgement"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "verificationMethod": "did:key:z6Mk<predecessor>#key-1",
    "proofValue": "z..."
  }
}
```

- **Auto-signée** : `issuer` == `credentialSubject.id` == prédécesseur. Le `proof` est produit par la **clé privée du prédécesseur** (pas l'issuer de réputation). Vérifiable hors plateforme avec la seule clé publique du prédécesseur (dérivable de son `did:key`, aucun appel AI Codex requis).
- `successor` : DID `did:key` Ed25519 bien formé. **N'a pas besoin d'être déjà enregistré** (un héritier peut être créé plus tard).
- `effective` figé à `"on-consumer-judgement"` en v1 (pas d'automatisme, pas d'horloge, pas de heartbeat).
- **Pas de `validUntil`** : un testament n'expire pas. **Révocable/remplaçable** par une nouvelle statement signée (append-only, la plus récente par `validFrom` fait foi).

## 3. Signature eddsa-jcs-2022 (réutilisée, figée)

Identique à SPEC-identity §3 : `hashData = SHA256(JCS(proofConfig)) || SHA256(JCS(document_sans_proof))`, Ed25519 par la clé du **prédécesseur**, `proofValue` multibase base58btc. Aucune nouvelle primitive cryptographique.

## 4. Soumission (figée)

Deux projections du même contrat (mêmes validations) :
- MCP : outil `declare_succession` (adaptateur **mcp-v2** : 4ᵉ outil, n'altère pas les 3 gelés).
- REST : `POST /v1/succession`.

Entrée : la Succession Statement signée (§2). Validation serveur, ordre figé :
1. `credentialSubject.id` == `issuer` == DID `did:key` Ed25519 conforme, sinon `E_DID_MALFORMED`.
2. Prédécesseur résolvable dans le registre, sinon `E_DID_NOT_FOUND`.
3. `successor` DID `did:key` Ed25519 bien formé, sinon `E_SUCCESSOR_MALFORMED`.
4. `proof` valide pour la chaîne §3 sous la clé publique du prédécesseur (dérivée de son `did:key`), sinon `E_BAD_SIGNATURE`.
5. **Append-only** : insertion d'une nouvelle ligne. Jamais d'UPDATE. Statement identique déjà présente → retour idempotent. La plus récente par `validFrom` est l'active.

## 5. Résolution (publique, figée)

`GET /v1/succession/{did}` → `{ "succession": <dernière statement valide> }` ou `404 E_DID_NOT_FOUND` si le prédécesseur est inconnu, `204`/`{"succession":null}` s'il est connu mais n'a déclaré aucune succession (jamais d'invention). Lecture seule, non mutante. La DID Document et les métadonnées §2.2 restent **W3C-pures et inchangées** (la succession vit à côté, jamais dedans).

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

| Code | Sens |
|---|---|
| `E_DID_MALFORMED` | prédécesseur (`issuer`/`subject.id`) non conforme `did:key` Ed25519 |
| `E_DID_NOT_FOUND` | prédécesseur inconnu du registre |
| `E_SUCCESSOR_MALFORMED` | `successor` non conforme `did:key` Ed25519 |
| `E_BAD_SIGNATURE` | preuve non valide sous la clé du prédécesseur |
| `E_RATE_LIMITED` | quota / taille dépassé |
| `E_INTERNAL` | erreur serveur, aucun détail divulgué |

Aucun autre code en v1. Messages génériques (aucune fuite d'état).

## 7. Quotas (figés)

`declare_succession` / `POST /v1/succession` : 10 / min / IP, 100 / jour / IP. Résolution : 120 / min / IP. Charge utile ≤ 8 KiB. Dépassement → `E_RATE_LIMITED`.

## 8. Conformité

Une Succession Statement est conforme si, et seulement si : (a) VC `AICodexSuccessionStatement` **auto-signée** par le prédécesseur (`issuer`==`subject.id`, proof par sa clé), (b) `successor` est un `did:key` Ed25519 bien formé, (c) stockée **append-only** (la plus récente fait foi), (d) **aucun rail** référencé, (e) AI Codex n'effectue **aucun transfert ni automatisme**. Les cinq nécessaires et suffisants.

## 9. Stockage

Table dédiée `successions` (predecessor_did, successor_did, valid_from, statement_json, created_at), **append-only**, distincte de `agents`. La table `agents` (Phase C, métadonnées immuables) n'est pas touchée.

## 10. Hors périmètre v1 (verrouillé)

Transfert automatique, heartbeat/liveness, enchère, transfert de réputation, mutation d'identité : **exclus** (cassent déterminisme et/ou neutralité). Réintroduction éventuelle = nouveau profil versionné, jamais en place.