Aller au contenu

État runtime courant — 16 septembre 2026

Status: CURRENT / VERIFIED / 2026-09-16

Cette page remplace la certification du 12 septembre comme point d'entrée documentaire vers le runtime courant. Les documents antérieurs restent des preuves historiques et ne doivent pas être réécrits pour refléter le présent.

Autorités vérifiées

La vérification read-only du 16 septembre 2026 a établi :

GitHub main au contrôle       6f1ed070beaacb6c5f20c86c99129e54441c7a73
release authority vérifiée    /mnt/data/cmonchoix-release-authority/6f1ed070beaacb6c5f20c86c99129e54441c7a73
release HEAD                   6f1ed070beaacb6c5f20c86c99129e54441c7a73
worker RepoDigest              ghcr.io/neweden52/cmonchoix-platform-worker@sha256:5ff08f7d68a9bb13fe8ba81e3ab1795f48c256e9527cde91747ade0f617ac996
worker image ID                sha256:5ff08f7d68a9bb13fe8ba81e3ab1795f48c256e9527cde91747ade0f617ac996
active feeds                   samsung,acer
WordPress Core sur l'hôte      ABSENT
Runtime Guard v2               PASS / 0 failure / 0 warning

Le SHA GitHub ci-dessus est le SHA observé au moment du contrôle. main peut avancer après publication de cette page sans signifier que le worker a été redéployé. L'autorité runtime doit toujours être qualifiée par le worktree de release effectivement utilisé et le RepoDigest exécuté.

Le checkout /mnt/data/cmonchoix-platform n'est pas l'artefact de release. Il peut être en retard sur main sans constituer à lui seul un défaut de production. Les opérations de certification et de déploiement utilisent un worktree de release immuable sur un SHA complet.

Contrat de release

La chaîne d'autorité est :

GitHub main certifié
        ↓
release worktree détaché /mnt/data/cmonchoix-release-authority/<SHA>
        ↓
docker-compose.yml de cette release
        ↓
images immuables par RepoDigest
        ↓
Runtime Guard v2 exécuté depuis cette release

Ne pas utiliser le script runtime-readonly-guard.sh d'un checkout historique pour conclure qu'un runtime récent est invalide. Le guard et le Compose doivent provenir du même SHA de release.

Worker courant

Le worker de production est self-contained et utilise :

ghcr.io/neweden52/cmonchoix-platform-worker@sha256:5ff08f7d68a9bb13fe8ba81e3ab1795f48c256e9527cde91747ade0f617ac996

Le Runtime Guard v2 du SHA 6f1ed070... a validé le RepoDigest, l'image ID, les mounts, les réseaux, le filesystem embarqué, WordPress Core 7.1, le plugin actif, WP-CLI, le contrat DB, le registre marchand, l'autorité d'activation et les marqueurs SQL de finalisation.

Le worker conserve exactement deux bind mounts mutables : uploads et runtime-spool. Aucun WordPress Core, plugin, src/, vendor/, thème ou mu-plugin n'est bind-monté depuis l'hôte dans le worker.

Marchands actifs

L'autorité runtime observée est :

CCX_ACTIVE_FEEDS=samsung,acer

Cette variable est la seule autorité d'activation des feeds. Une option WordPress parallèle ne doit pas être recréée.

Au 16 septembre, les derniers runs contrôlés étaient réussis pour Samsung et Acer. La synchronisation de ces deux feeds est déclenchée par systemd vers l'entrée canonique WP-CLI du worker.

Scheduling courant

Les schedules installés sont :

Feed Timer Horaire de base Randomisation Persistent
Samsung ccx-samsung-sync.timer 03:15 UTC 10 min oui
Acer ccx-acer-sync.timer 04:15 UTC 10 min oui

Les services appellent uniquement :

docker exec ccx-platform-worker
  wp --allow-root --path=/var/www/html
  ccx sync start --feed=<merchant>

Ils ne contiennent ni URL marchande, ni credentials, ni SQL, ni mapping, ni classification.

Les unités canoniques sont versionnées sous operations/systemd/. Les copies /etc/systemd/system/ sont du runtime installé et doivent rester byte-identiques à la release certifiée.

Safe deploy multi-feed

Le safe-deploy worker ne doit plus traiter Samsung comme unique feed de contrôle. Avant un rollout, il lit CCX_ACTIVE_FEEDS depuis le worker courant, normalise et valide les identifiants puis exige pour chaque feed actif :

  • ccx sync doctor --feed=<feed> exécutable ;
  • aucun lock actif ;
  • aucune row claim active.

Après rollout, il exige pour chaque feed actif :

  • même autorité CCX_ACTIVE_FEEDS ;
  • ccx sync status --feed=<feed> --limit=1 valide ;
  • ccx sync doctor --feed=<feed> valide.

L'autorité est fail-closed : un CCX_ACTIVE_FEEDS vide, un identifiant invalide ou l'échec d'un seul feed bloque le déploiement.

Runtime Guard v2

Commande de certification officielle :

SHA=<SHA_COMPLET_CERTIFIE>
RELEASE=/mnt/data/cmonchoix-release-authority/$SHA

CCX_LIVE_ROOT=/mnt/data/cmonchoix-platform \
CCX_GUARD_COMPOSE_FILE="$RELEASE/docker-compose.yml" \
bash "$RELEASE/scripts/runtime-readonly-guard.sh" --runtime

Verdict attendu :

RUNTIME_GUARD_FAILURES=0
RUNTIME_GUARD_WARNINGS=0
RUNTIME_GUARD_STATUS=PASS
CCX_RUNTIME_GUARD_V2_RUNTIME=PASS

Invariants

  1. GitHub fournit la source versionnée ; le worktree de release sur SHA complet fournit l'autorité de déploiement.
  2. Le checkout live ne doit pas être reset ou transformé en artefact de release.
  3. WordPress Core reste absent du checkout hôte.
  4. Le worker reste épinglé par RepoDigest et self-contained.
  5. CCX_ACTIVE_FEEDS reste l'autorité unique des feeds actifs.
  6. Tout safe-deploy contrôle tous les feeds actifs, pas un marchand codé en dur.
  7. Les unités systemd marchandes installées restent dérivées de fichiers versionnés.
  8. Les anciennes certifications restent historiques ; elles ne redeviennent pas CURRENT par défaut.

Sujets encore ouverts après P0

Les sujets suivants sont volontairement séparés de la correction d'autorité P0 :

  • scheduler générique multi-marchands piloté par l'activation ;
  • snapshots/replay universels pour tous les feeds actifs ;
  • tests explicites de courses lock/claim avec plusieurs workers ;
  • version/génération commune pour la cohérence inter-projections ;
  • déplacement de logique merchant-specific hors du persister ;
  • gouvernance renforcée de main et checks requis.

Références