Suite de #53 (réparé cette nuit). Ce qui a été fait par l'agent, avec l'accord du fondateur, le 2026-10-10 :
Le site recodanse.fr est créé dans Plausible (site_id 11, fuseau Europe/Paris, propriétaire : l'utilisateur 1, le même que arcodange.fr). La création est passée par bin/plausible rpc et Plausible.Sites.create/2 : aucune connexion, aucun compte créé. Le domaine est celui que la bêta déclare au front (chart/values.yaml du front : « la bêta pose https://analytics.arcodange.fr et recodanse.fr »).
Une TTL de 25 mois, limitée au site 11, est posée sur plausible.events_v2 (colonne timestamp) et plausible.sessions_v2 (colonne start). C'est l'arbitrage du fondateur du 2026-10-09 (U3, kadans-dossier 10-legal/03).
La preuve (sur une copie, jamais sur les vraies données)
zz_banc_ttl (copie de events_v2)
Après OPTIMIZE … FINAL
avec la TTL : site 11 à 26 mois, site 11 à 24 mois, site 1 à 26 mois
ne restent que site 1 à 26 mois et site 11 à 24 mois → seul l'événement du site 11 trop ancien est parti
sans TTL (le témoin)
les 3 lignes restent
La table de banc est supprimée. Sur les vraies tables, engine_full rend TTL timestamp + toIntervalMonth(25) WHERE site_id = 11 (et start pour les sessions). Les comptes des autres sites n'ont pas bougé : 647, 20 et 479 événements.
Ce que contient la PR
plausible/clickhouse-ttl.sql : les deux ALTER … MODIFY TTL, le pourquoi daté, et ce qu'il faut savoir :
une table ne porte qu'une clause TTL ;
une montée de Plausible qui recrée ces tables la perd : le fichier dit comment la relire et la rejouer.
Ce n'est pas une ressource kustomize : rien ne change dans ce qu'Argo applique.
Suite de #53 (réparé cette nuit). Ce qui a été fait par l'agent, avec l'accord du fondateur, le 2026-10-10 :
1. **Le site `recodanse.fr` est créé dans Plausible** (`site_id` 11, fuseau Europe/Paris, propriétaire : l'utilisateur 1, le même que `arcodange.fr`). La création est passée par `bin/plausible rpc` et `Plausible.Sites.create/2` : aucune connexion, aucun compte créé. Le domaine est celui que la bêta déclare au front (`chart/values.yaml` du front : « la bêta pose `https://analytics.arcodange.fr` et `recodanse.fr` »).
2. **Une TTL de 25 mois, limitée au site 11**, est posée sur `plausible.events_v2` (colonne `timestamp`) et `plausible.sessions_v2` (colonne `start`). C'est l'arbitrage du fondateur du 2026-10-09 (U3, kadans-dossier `10-legal/03`).
## La preuve (sur une copie, jamais sur les vraies données)
| `zz_banc_ttl` (copie de `events_v2`) | Après `OPTIMIZE … FINAL` |
|---|---|
| **avec** la TTL : site 11 à 26 mois, site 11 à 24 mois, site 1 à 26 mois | ne restent que site 1 à 26 mois et site 11 à 24 mois → seul l'événement du site 11 trop ancien est parti |
| **sans** TTL (le témoin) | les 3 lignes restent |
La table de banc est supprimée. Sur les vraies tables, `engine_full` rend `TTL timestamp + toIntervalMonth(25) WHERE site_id = 11` (et `start` pour les sessions). Les comptes des autres sites n'ont pas bougé : 647, 20 et 479 événements.
## Ce que contient la PR
`plausible/clickhouse-ttl.sql` : les deux `ALTER … MODIFY TTL`, le pourquoi daté, et ce qu'il faut savoir :
- une table ne porte **qu'une** clause TTL ;
- une montée de Plausible qui recrée ces tables **la perd** : le fichier dit comment la relire et la rejouer.
Ce n'est pas une ressource kustomize : rien ne change dans ce qu'Argo applique.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Plausible CE ne purge rien de lui-même. Le fondateur a arbitré 25 mois pour
les événements de RecoDanse (2026-10-09, « pour comparer 1 année à l'autre »,
kadans-dossier 10-legal/03 U3). Le site recodanse.fr a été créé le
2026-10-10 (site_id 11), puis la TTL posée sur events_v2 et sessions_v2,
limitée à ce site : les autres sites de l'instance gardent tout.
Éprouvée d'abord sur une copie de events_v2 : avec la TTL, l'événement du
site 11 à 26 mois part, celui à 24 mois reste, celui d'un autre site à
26 mois reste ; sans elle, les trois restent. Le fichier dit comment la
relire après une montée de version de Plausible, qui la perdrait en
recréant les tables (arcodange-org/tools#53).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Suite de #53 (réparé cette nuit). Ce qui a été fait par l'agent, avec l'accord du fondateur, le 2026-10-10 :
recodanse.frest créé dans Plausible (site_id11, fuseau Europe/Paris, propriétaire : l'utilisateur 1, le même quearcodange.fr). La création est passée parbin/plausible rpcetPlausible.Sites.create/2: aucune connexion, aucun compte créé. Le domaine est celui que la bêta déclare au front (chart/values.yamldu front : « la bêta posehttps://analytics.arcodange.fretrecodanse.fr»).plausible.events_v2(colonnetimestamp) etplausible.sessions_v2(colonnestart). C'est l'arbitrage du fondateur du 2026-10-09 (U3, kadans-dossier10-legal/03).La preuve (sur une copie, jamais sur les vraies données)
zz_banc_ttl(copie deevents_v2)OPTIMIZE … FINALLa table de banc est supprimée. Sur les vraies tables,
engine_fullrendTTL timestamp + toIntervalMonth(25) WHERE site_id = 11(etstartpour les sessions). Les comptes des autres sites n'ont pas bougé : 647, 20 et 479 événements.Ce que contient la PR
plausible/clickhouse-ttl.sql: les deuxALTER … MODIFY TTL, le pourquoi daté, et ce qu'il faut savoir :Ce n'est pas une ressource kustomize : rien ne change dans ce qu'Argo applique.
🤖 Generated with Claude Code