Skip to content

Contrats gold : contexte des records (couverture et 2e extrême distinct) - #11

Merged
citarf merged 2 commits into
mainfrom
citarf/contexte-des-records
Aug 2, 2026
Merged

Contrats gold : contexte des records (couverture et 2e extrême distinct)#11
citarf merged 2 commits into
mainfrom
citarf/contexte-des-records

Conversation

@citarf

@citarf citarf commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

Déclare sur les datasets records des trois contrats gold le contexte qui rend un record de température vérifiable par son consommateur.

Dépendance aval : infoclimat-labs/chom-poc-data#36, qui produit ces colonnes et les publie. Cette PR-ci se fusionne en premier — le portail lit ces contrats pour générer openapi.json et llms-full.txt, donc sa suite de tests échoue tant qu'ils ne déclarent pas les colonnes.

Le problème

/ic/records ne renvoyait que l'extrême et sa date. Un tnn_min à 0 °C sur une station tropicale était indétectable côté client — il a fallu ouvrir une issue pour s'en apercevoir.

Les six propriétés

Ajoutées au dataset records de gold-ic, gold-climato-v2 et gold-statIC :

Propriété Type Rôle
n_jours_tn, n_jours_tx BIGINT Le socle : sur combien de jours mesurés l'extrême est calculé
premiere_obs, derniere_obs DATE Les bornes de la période couverte par ce mois calendaire
tnn_min_suivant, txx_max_suivant DOUBLE La valeur distincte suivante en valeur

Trois points de rédaction à retenir

_suivant désigne le suivant en VALEUR, pas dans le temps. C'est le seul défaut connu de ce nom, retenu pour qu'il porte sa sémantique plutôt qu'un _2 muet. Les descriptions le disent explicitement — c'est le prix assumé, il n'est pas optionnel.

BIGINT et non INTEGER pour les compteurs : count() rend un int64 sous DuckDB. Publier INTEGER aurait rejoué le défaut de sérialisation de #9, où un type physique mal déclaré ressortait en chaîne JSON.

Deux compteurs et non un. max(tx) ignore les tx nuls : un compteur unique surestimerait le socle d'un record de tn là où tn est plus lacunaire que tx — il mentirait exactement sur la question posée.

Ordre des propriétés

Le second commit réaligne l'ordre déclaré sur l'ordre physique de la table (txx_max_suivant suit txx_max_date, tnn_min_suivant suit tnn_min_date). Un contrat qui décrit ses colonnes dans un ordre que la table n'a pas est une petite verrue ; celui-ci est désormais verrouillé par un test côté producteur.

🤖 Generated with Claude Code

citarf added 2 commits August 2, 2026 14:31
…inct

Six colonnes sur les datasets records des trois familles canoniques, pour
qu'un record soit vérifiable par son consommateur (chom-poc-data#13).

Le suffixe _suivant désigne le suivant EN VALEUR, pas dans le temps : les
descriptions le disent explicitement, c'est le prix de ce nom.
… kernel

Le contrat doit décrire la table dans l'ordre où elle existe : txx_max_suivant
suit txx_max_date, tnn_min_suivant suit tnn_min_date — comme produit par le
kernel — au lieu d'être groupés en fin de bloc après tnn_min_date.

Aucun changement de nom, de physicalType ni de description.
@citarf
citarf merged commit 8eb302f into main Aug 2, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant