Aller au contenu

P1.5F — Production Read-only Baseline

Status: CLOSED_PASS / LIVE CERTIFIED / GIT RECORDED

Objet

P1.5F établit la première baseline quantitative du VPS de production sans mutation contrôlée.

Le scénario S0 a été exécuté en production sur la révision certifiée, puis ses preuves live ont été revues et enregistrées dans Git. P1.5F est CLOSED_PASS. Cette fermeture établit une baseline read-only du système CURRENT ; elle ne certifie ni plafond de capacité ni seuil SLO.

Clôture live — 19 septembre 2026

Autorité machine-readable de clôture :

benchmarks/capacity/p1-5f-s0-live-closure.json

Révision/configuration certifiée :

git_sha    6327c15bb86548e75763ca1eb18312ebeab967bf
git_tree   cd9762db195a7c7601dd1f7320ed4ec9f32bf079
dataset    prod-s0-5c61c33fdaeb16e2
offers     700
products   678
merchants  2
feeds      acer,samsung

Exécution officielle :

CCX_P1_5F_CERTIFIER=PASS
warmup                    1 PASS
measured                  3 PASS
observation_seconds       300 par run
change_percent            0
workers                   1
median_duration_ms        305481
worst_duration_ms         305650
business_correctness      PASS
identity_capacity_verdict SKIPPED_NOT_DEPLOYED
recovery                  NONE

Preuves conservées hors dépôt :

certification session
/mnt/data/cmonchoix-benchmarks/p1-5/certification/20260919T135756Z-6327c15bb865

benchmark result
/mnt/data/cmonchoix-benchmarks/p1-5/S0/20260919T135759Z-6327c15bb865

dataset preflight
/mnt/data/cmonchoix-benchmarks/p1-5/preflight/20260919T135758Z-6327c15bb865

Fingerprints enregistrés :

certification.env  bc8bfaa090cb5d1b25b6b005182170f8b1e146b05872ecf43f9aa47624159c27
manifest.env       d1d5f15d93bef7b2489e2af6b69c7354ffc238b6c7d63627adb120d7d8af3017
runs.tsv           aacadc6fb3f8731fbcfbc73f270e68175138d594711bc2a38e985a4a15818b31
summary.env        8bf8add556014d1d8c20a88f01a5623580d6458e83dc6febd22eb45b024f4e2e

Les sept containers suivis par le certifier sont restés identiques pendant toute la fenêtre, avec restart_count=0 et aucun OOMKilled. Prometheus utilisait l'autorité de règles de la release 6327c15bb86548e75763ca1eb18312ebeab967bf ; les 18 séries universellement applicables étaient finies et numériques, tandis qu'Identity restait exactement sous le gate SKIPPED_NOT_DEPLOYED.

La tentative S0 précédente du 19 septembre reste FAILED_EVIDENCE_RETAINED et n'a été réutilisée dans aucun run de cette certification.

Autorités

Contrat S0 :

benchmarks/capacity/p1-5f-s0-contract.json

Harness :

scripts/capacity-benchmark-harness.sh

Version contractuelle :

benchmark_harness_version=p1.5e-v2

S0 interdit --recovery-script. Le manifest de chaque run porte explicitement recovery_script=NONE, recovery_script_sha256=NONE et recovery_rc=0.

Workload read-only :

scripts/capacity-workloads/p1-5f-s0-read-only.sh

Business verifier :

scripts/capacity-verifiers/p1-5f-s0-read-only.sh

Dataset preflight read-only :

scripts/capacity-preflight/p1-5f-s0-dataset.sh

Résultats hors dépôt :

/mnt/data/cmonchoix-benchmarks/p1-5

Invariants S0

Le scénario CURRENT exige :

scenario=S0
change_percent=0
workers=1
warmups>=1
measured_runs>=3

Le workload n'exécute :

  • aucune sync ;
  • aucun rebuild ;
  • aucune maintenance ;
  • aucun restart ;
  • aucune commande docker compose up/down/restart ;
  • aucune écriture SQL.

Il observe l'état courant pendant 300 secondes par répétition et vérifie avant/après que les containers nécessaires sont running et non OOMKilled.

Le raccourci CCX_P1_5F_SMOKE=1 existe uniquement pour le smoke CI. Il n'est pas accepté par le verifier et ne constitue jamais une certification live.

Business verifier

Le verifier interroge l'autorité Prometheus live et exige un échantillon numérique fini pour les 18 recording rules ccx_capacity_* universellement applicables au runtime CURRENT. ccx_capacity_identity_products_per_second est deployment-gated : elle est numérique obligatoire lorsque IDENTITY-001 et IDENTITY-002 sont applied avec leurs deux tables présentes ; elle vaut explicitement SKIPPED_NOT_DEPLOYED uniquement lorsque les deux migrations sont pending, sans drift, et que les deux tables sont absentes. Tout état partiel, failed, running, drifté ou physiquement incohérent échoue fermé.

Il vérifie également :

  • ccx_capacity_total_offers = nombre d'offres déclaré dans le manifest ;
  • mémoire worker strictement positive ;
  • CPU worker non négatif ;
  • ratio HTTP 5xx compris entre 0 et 1 ;
  • containers applicatifs/DB/worker/observabilité running ;
  • aucun de ces containers en état OOMKilled ;
  • état Identity lu via l'autorité read-only wp ccx migrations status --component=identity-resolution et présence physique des deux tables ;
  • aucune exécution de migration Identity par S0.

Le statut SKIPPED_NOT_DEPLOYED ne signifie pas « débit nul ». Il signifie que le sous-système Identity terminal est volontairement absent du runtime déployé. S0 n'a aucune autorité pour transformer ce statut de déploiement en activation fonctionnelle.

Les champs products et merchant_count restent des métadonnées versionnées du dataset. S0 ne prétend pas les reconstruire depuis un proxy métrique non contracté.

Dataset preflight obligatoire

Avant le --plan, P1.5F doit figer les métadonnées du dataset CURRENT avec :

bash scripts/capacity-preflight/p1-5f-s0-dataset.sh \
  --expected-git-sha <exact-deployed-sha>

Ce préflight est strictement read-only et refuse un worktree sale ou un SHA différent de la révision déployée.

Les autorités sont :

offers
  ccx_offers_norm_v2 COUNT(*)

products
  ccx_canonical_products_v1 COUNT(*)

merchants
  CCX_ACTIVE_FEEDS
  normalisé et identique dans ccx-wordpress + ccx-platform-worker

source dataset
  dernier ccx_feed_files.file_hash SHA-256 valide par feed actif

Le nombre de marchands n'est donc pas dérivé d'un COUNT(DISTINCT source_feed) : l'autorité reste la configuration de déploiement.

Le préflight vérifie aussi :

ccx_capacity_total_offers == COUNT(ccx_offers_norm_v2)

afin de prouver que la matérialisation Prometheus utilisée par S0 reflète bien l'autorité canonique des offres avant le benchmark.

Il écrit hors dépôt :

/mnt/data/cmonchoix-benchmarks/p1-5/preflight/<timestamp>-<sha>/
  dataset-canonical.txt
  feed-evidence.tsv
  preflight.env

dataset-canonical.txt contient uniquement des autorités reproductibles :

active_feeds
merchant_count
offers
products
feed.<feed>.sha256

Le SHA Git, l'heure d'observation et les downloaded_at sont conservés comme preuves hors fingerprint. Le même contenu source et les mêmes cardinalités gardent donc le même dataset_sha256 même après un redéploiement ou un retéléchargement identique.

Puis :

dataset_sha256 = SHA256(dataset-canonical.txt)
dataset_id     = prod-s0-<16 premiers hex du dataset_sha256>

Le timestamp d'observation est conservé dans preflight.env mais n'entre pas dans le fingerprint canonique.

Certifier opérateur unique

Le point d'entrée recommandé pour une exécution production est désormais :

bash scripts/capacity-certify-p1-5f-s0.sh \
  --expected-git-sha <exact-deployed-sha>

Le certifier ne remplace aucune autorité existante. Il orchestre uniquement, dans cet ordre :

dataset preflight
→ harness --plan
→ fingerprint des 7 containers requis
→ harness --execute
→ 1 warm-up + 3 measured runs
→ nouveau fingerprint des 7 containers
→ validation des artefacts

Les métadonnées dataset_id, dataset_sha256, offers, products et merchants sont lues depuis le preflight.env généré par le préflight. Elles ne sont donc plus recopiées manuellement entre les étapes.

Le certifier exige :

  • le SHA Git exact et un worktree propre ;
  • les scripts préflight/harness/workload/verifier suivis par Git ;
  • les sorties hors dépôt ;
  • exactement 1 warm-up et 3 runs mesurés ;
  • business_correctness=PASS ;
  • recovery_script=NONE et recovery_rc=0 pour S0 ;
  • les fingerprints workload/verifier exacts dans le manifest ;
  • les sept containers requis running et non OOMKilled ;
  • le même container ID, restart_count et started_at avant et après l'ensemble de la baseline.

Le dernier point ferme explicitement le critère « aucun restart inattendu » sur toute la fenêtre S0 et détecte aussi une recréation silencieuse de container.

Le mode :

bash scripts/capacity-certify-p1-5f-s0.sh \
  --expected-git-sha <exact-deployed-sha> \
  --plan-only

exécute uniquement le préflight et le plan. Il imprime CCX_P1_5F_CERTIFIER_PLAN=PASS mais ne constitue jamais une certification live.

Une exécution complète réussie imprime :

CCX_P1_5F_CERTIFIER=PASS

et produit dans son répertoire de session :

certification.env
status=LIVE_EVIDENCE_PASS_PENDING_GIT_CLOSURE

Le certifier ne s'auto-attribue donc jamais P1.5F=CLOSED_PASS. La fermeture de phase exige toujours la revue et l'enregistrement Git des preuves live conformément au présent contrat.

Le certifier reste sans autorité de mutation fonctionnelle :

  • aucun démarrage de sync ;
  • aucun rebuild ;
  • aucune écriture DB ;
  • aucune exécution de ccx migrations run ni activation implicite du sous-système Identity ;
  • aucun docker compose up/down/restart ;
  • aucune gestion de service systemd.

Plan obligatoire

Avant toute exécution :

bash scripts/capacity-benchmark-harness.sh \
  --plan \
  --scenario S0 \
  --dataset-id <dataset-stable-id> \
  --dataset-sha256 <64-hex> \
  --offers <offers> \
  --products <products> \
  --merchants <merchants> \
  --change-percent 0 \
  --workers 1

Le dataset id, son SHA-256 et ses cardinalités doivent être établis depuis les autorités production avant l'exécution.

Exécution de certification

L'exécution live doit utiliser le SHA exactement déployé :

bash scripts/capacity-benchmark-harness.sh \
  --execute \
  --scenario S0 \
  --dataset-id <dataset-stable-id> \
  --dataset-sha256 <64-hex> \
  --offers <offers> \
  --products <products> \
  --merchants <merchants> \
  --change-percent 0 \
  --workers 1 \
  --expected-git-sha <exact-deployed-sha> \
  --workload-script scripts/capacity-workloads/p1-5f-s0-read-only.sh \
  --verifier-script scripts/capacity-verifiers/p1-5f-s0-read-only.sh

Le harness impose un worktree propre, fingerprint les scripts/configs/dataset et exécute au minimum :

1 warm-up
3 measured runs

Critères de fermeture P1.5F

P1.5F ne devient CLOSED_PASS que si :

  1. le dataset preflight est PASS sur le SHA déployé et ses artefacts sont conservés ;
  2. le plan S0 est valide sur le SHA déployé ;
  3. les quatre répétitions minimales terminent PASS ;
  4. business_correctness=PASS ;
  5. les 18 séries universellement applicables retournent des valeurs numériques ; ccx_capacity_identity_products_per_second est numérique si Identity est déployé, ou explicitement SKIPPED_NOT_DEPLOYED uniquement sous le gate exact pending/pending + no drift + deux tables absentes ;
  6. aucun restart inattendu n'est observé ;
  7. aucun OOMKilled n'est observé ;
  8. les artefacts de benchmark sont conservés hors dépôt ;
  9. le manifest contient les fingerprints exacts Git/config/dataset/workload/verifier et les marqueurs recovery S0 à NONE ;
  10. la baseline mesurée est documentée sans transformer une observation unique en seuil de capacité.

Ce que P1.5F ne certifie pas

P1.5F est une baseline du système CURRENT, pas un stress test.

Elle ne certifie pas encore :

  • le débit maximum ;
  • la marge CPU/RAM maximale ;
  • la saturation DB ;
  • le nombre optimal de workers ;
  • la concurrence multi-marchands ;
  • un rebuild lourd ;
  • le frontend sous sync lourde ;
  • les seuils définitifs de production.

Ces preuves appartiennent à P1.5G, puis le certificat de capacité final à P1.5H.

État

P1.5A  measurement contract             CLOSED
P1.5B  runtime instrumentation          CLOSED
P1.5C  source materialization Git       CLOSED
P1.5D  dashboard + recording rules Git  CLOSED
P1.5E  benchmark harness Git            CLOSED

P1.5F  production read-only baseline    CLOSED_PASS
P1.5G  controlled live benchmark        CONTRACT READY / EXECUTION INPUTS REQUIRED
P1.5H  capacity certificate              FUTURE