in_time_scope 0.1.5 → 0.1.6

data/docs/de/index.md

@@ -0,0 +1,192 @@
+# InTimeScope
+
+Schreiben Sie das jedes Mal in Rails?
+
+```ruby
+# Before
+Event.where("start_at <= ? AND (end_at IS NULL OR end_at > ?)", Time.current, Time.current)
+
+# After
+class Event < ActiveRecord::Base
+  in_time_scope
+end
+
+Event.in_time
+```
+
+Das war's. Eine Zeile DSL, kein rohes SQL in Ihren Models.
+
+## Warum dieses Gem?
+
+Dieses Gem existiert, um:
+
+- **Zeitbereich-Logik konsistent zu halten** in Ihrer gesamten Codebasis
+- **Copy-Paste SQL zu vermeiden**, das leicht falsch geschrieben wird
+- **Zeit zu einem erstklassigen Domain-Konzept zu machen** mit benannten Scopes wie `in_time_published`
+- **Nullfähigkeit automatisch zu erkennen** aus Ihrem Schema für optimierte Abfragen
+
+## Empfohlen für
+
+- Neue Rails-Anwendungen mit Gültigkeitszeiträumen
+- Models mit `start_at` / `end_at` Spalten
+- Teams, die konsistente Zeitlogik ohne verstreute `where`-Klauseln wollen
+
+## Installation
+
+```bash
+bundle add in_time_scope
+```
+
+## Schnellstart
+
+```ruby
+class Event < ActiveRecord::Base
+  in_time_scope
+end
+
+# Klassen-Scope
+Event.in_time                          # Aktuell aktive Datensätze
+Event.in_time(Time.parse("2024-06-01")) # Zu einem bestimmten Zeitpunkt aktive Datensätze
+
+# Instanz-Methode
+event.in_time?                          # Ist dieser Datensatz jetzt aktiv?
+event.in_time?(some_time)               # War er zu diesem Zeitpunkt aktiv?
+```
+
+## Funktionen
+
+### Auto-optimiertes SQL
+
+Das Gem liest Ihr Schema und generiert das richtige SQL:
+
+```ruby
+# NULL-erlaubte Spalten → NULL-bewusste Abfrage
+WHERE (start_at IS NULL OR start_at <= ?) AND (end_at IS NULL OR end_at > ?)
+
+# NOT NULL Spalten → einfache Abfrage
+WHERE start_at <= ? AND end_at > ?
+```
+
+### Benannte Scopes
+
+Mehrere Zeitfenster pro Model:
+
+```ruby
+class Article < ActiveRecord::Base
+  in_time_scope :published   # → Article.in_time_published
+  in_time_scope :featured    # → Article.in_time_featured
+end
+```
+
+### Benutzerdefinierte Spalten
+
+```ruby
+class Campaign < ActiveRecord::Base
+  in_time_scope start_at: { column: :available_at },
+                end_at: { column: :expired_at }
+end
+```
+
+### Nur-Start-Muster (Versionshistorie)
+
+Für Datensätze, bei denen jede Zeile bis zur nächsten gültig ist:
+
+```ruby
+class Price < ActiveRecord::Base
+  in_time_scope start_at: { null: false }, end_at: { column: nil }
+end
+
+# Bonus: effizientes has_one mit NOT EXISTS
+class User < ActiveRecord::Base
+  has_one :current_price, -> { latest_in_time(:user_id) }, class_name: "Price"
+end
+
+User.includes(:current_price)  # Kein N+1, holt nur den neuesten pro Benutzer
+```
+
+### Nur-Ende-Muster (Ablauf)
+
+Für Datensätze, die aktiv sind, bis sie ablaufen:
+
+```ruby
+class Coupon < ActiveRecord::Base
+  in_time_scope start_at: { column: nil }, end_at: { null: false }
+end
+```
+
+### Inverse Scopes
+
+Datensätze außerhalb des Zeitfensters abfragen:
+
+```ruby
+# Noch nicht gestartete Datensätze (start_at > time)
+Event.before_in_time
+event.before_in_time?
+
+# Bereits beendete Datensätze (end_at <= time)
+Event.after_in_time
+event.after_in_time?
+
+# Datensätze außerhalb des Zeitfensters (vor ODER nach)
+Event.out_of_time
+event.out_of_time?  # Logische Umkehrung von in_time?
+```
+
+Funktioniert auch mit benannten Scopes:
+
+```ruby
+Article.before_in_time_published  # Noch nicht veröffentlicht
+Article.after_in_time_published   # Veröffentlichung beendet
+Article.out_of_time_published     # Derzeit nicht veröffentlicht
+```
+
+## Optionen-Referenz
+
+| Option | Standard | Beschreibung | Beispiel |
+| --- | --- | --- | --- |
+| `scope_name` (1. Arg) | `:in_time` | Benannter Scope wie `in_time_published` | `in_time_scope :published` |
+| `start_at: { column: }` | `:start_at` | Benutzerdefinierter Spaltenname, `nil` zum Deaktivieren | `start_at: { column: :available_at }` |
+| `end_at: { column: }` | `:end_at` | Benutzerdefinierter Spaltenname, `nil` zum Deaktivieren | `end_at: { column: nil }` |
+| `start_at: { null: }` | Auto-Erkennung | NULL-Behandlung erzwingen | `start_at: { null: false }` |
+| `end_at: { null: }` | Auto-Erkennung | NULL-Behandlung erzwingen | `end_at: { null: true }` |
+
+## Beispiele
+
+- [Punktesystem mit Ablaufdatum](./point-system.md) - Vollständiges Zeitfenster-Muster
+- [Benutzernamen-Historie](./user-name-history.md) - Nur-Start-Muster
+
+## Danksagungen
+
+Inspiriert von [onk/shibaraku](https://github.com/onk/shibaraku). Dieses Gem erweitert das Konzept mit:
+
+- Schema-bewusste NULL-Behandlung für optimierte Abfragen
+- Mehrere benannte Scopes pro Model
+- Nur-Start / Nur-Ende Muster
+- `latest_in_time` / `earliest_in_time` für effiziente `has_one` Assoziationen
+- Inverse Scopes: `before_in_time`, `after_in_time`, `out_of_time`
+
+## Entwicklung
+
+```bash
+# Abhängigkeiten installieren
+bin/setup
+
+# Tests ausführen
+bundle exec rspec
+
+# Linting ausführen
+bundle exec rubocop
+
+# CLAUDE.md generieren (für KI-Coding-Assistenten)
+npx rulesync generate
+```
+
+Dieses Projekt verwendet [rulesync](https://github.com/dyoshikawa/rulesync) zur Verwaltung von KI-Assistenten-Regeln. Bearbeiten Sie `.rulesync/rules/*.md` und führen Sie `npx rulesync generate` aus, um `CLAUDE.md` zu aktualisieren.
+
+## Beitragen
+
+Bug-Reports und Pull Requests sind willkommen auf [GitHub](https://github.com/kyohah/in_time_scope).
+
+## Lizenz
+
+MIT-Lizenz

data/docs/de/point-system.md

@@ -0,0 +1,295 @@
+# Beispiel: Punktesystem mit Ablaufdatum
+
+Dieses Beispiel zeigt, wie man ein Punktesystem mit Ablaufdaten unter Verwendung von `in_time_scope` implementiert. Punkte können vorab gewährt werden, um in der Zukunft aktiv zu werden, wodurch Cron-Jobs überflüssig werden.
+
+Siehe auch: [spec/point_system_spec.rb](https://github.com/kyohah/in_time_scope/blob/main/spec/point_system_spec.rb)
+
+## Anwendungsfall
+
+- Benutzer sammeln Punkte mit Gültigkeitszeiträumen (Startdatum und Ablaufdatum)
+- Punkte können vorab gewährt werden, um in der Zukunft aktiviert zu werden (z.B. monatliche Mitgliedschaftsboni)
+- Berechnung gültiger Punkte zu jedem Zeitpunkt ohne Cron-Jobs
+- Abfrage bevorstehender Punkte, abgelaufener Punkte usw.
+
+## Keine Cron-Jobs erforderlich
+
+**Das ist DIE Killer-Funktion.** Traditionelle Punktesysteme sind ein Albtraum aus geplanten Jobs:
+
+### Die Cron-Hölle, die Sie kennen
+
+```ruby
+# activate_points_job.rb - läuft jede Minute
+class ActivatePointsJob < ApplicationJob
+  def perform
+    Point.where(status: "pending")
+         .where("start_at <= ?", Time.current)
+         .update_all(status: "active")
+  end
+end
+
+# expire_points_job.rb - läuft jede Minute
+class ExpirePointsJob < ApplicationJob
+  def perform
+    Point.where(status: "active")
+         .where("end_at <= ?", Time.current)
+         .update_all(status: "expired")
+  end
+end
+
+# Und dann brauchen Sie:
+# - Sidekiq / Delayed Job / Good Job
+# - Redis (für Sidekiq)
+# - Cron oder whenever gem
+# - Monitoring für Job-Fehler
+# - Retry-Logik für fehlgeschlagene Jobs
+# - Sperrmechanismen zur Vermeidung von Doppelausführungen
+```
+
+### Der InTimeScope-Weg
+
+```ruby
+# Das war's. Keine Jobs. Keine Status-Spalte. Keine Infrastruktur.
+user.points.in_time.sum(:amount)
+```
+
+**Eine Zeile. Null Infrastruktur. Immer genau.**
+
+### Warum das funktioniert
+
+Die Spalten `start_at` und `end_at` SIND der Status. Es gibt keine Notwendigkeit für eine `status`-Spalte, da der Zeitvergleich zur Abfragezeit erfolgt:
+
+```ruby
+# All das funktioniert ohne Hintergrundverarbeitung:
+user.points.in_time                    # Aktuell gültig
+user.points.in_time(1.month.from_now)  # Nächsten Monat gültig
+user.points.in_time(1.year.ago)        # Waren letztes Jahr gültig (Audit!)
+user.points.before_in_time             # Ausstehend (noch nicht aktiv)
+user.points.after_in_time              # Abgelaufen
+```
+
+### Was Sie eliminieren
+
+| Komponente | Cron-basiertes System | InTimeScope |
+|-----------|------------------|-------------|
+| Hintergrund-Job-Bibliothek | Erforderlich | **Nicht benötigt** |
+| Redis/Datenbank für Jobs | Erforderlich | **Nicht benötigt** |
+| Job-Scheduler (cron) | Erforderlich | **Nicht benötigt** |
+| Status-Spalte | Erforderlich | **Nicht benötigt** |
+| Migration zur Status-Aktualisierung | Erforderlich | **Nicht benötigt** |
+| Monitoring für Job-Fehler | Erforderlich | **Nicht benötigt** |
+| Retry-Logik | Erforderlich | **Nicht benötigt** |
+| Race-Condition-Handling | Erforderlich | **Nicht benötigt** |
+
+### Bonus: Zeitreisen kostenlos
+
+Bei Cron-basierten Systemen erfordert die Beantwortung von "Wie viele Punkte hatte Benutzer X am 15. Januar?" komplexes Audit-Logging oder Event Sourcing.
+
+Mit InTimeScope:
+
+```ruby
+user.points.in_time(Date.parse("2024-01-15").middle_of_day).sum(:amount)
+```
+
+**Historische Abfragen funktionieren einfach.** Keine zusätzlichen Tabellen. Kein Event Sourcing. Keine Komplexität.
+
+## Schema
+
+```ruby
+# Migration
+class CreatePoints < ActiveRecord::Migration[7.0]
+  def change
+    create_table :points do |t|
+      t.references :user, null: false, foreign_key: true
+      t.integer :amount, null: false
+      t.string :reason, null: false
+      t.datetime :start_at, null: false  # Wann Punkte nutzbar werden
+      t.datetime :end_at, null: false    # Wann Punkte ablaufen
+      t.timestamps
+    end
+
+    add_index :points, [:user_id, :start_at, :end_at]
+  end
+end
+```
+
+## Modelle
+
+```ruby
+class Point < ApplicationRecord
+  belongs_to :user
+
+  # Sowohl start_at als auch end_at sind erforderlich (vollständiges Zeitfenster)
+  in_time_scope start_at: { null: false }, end_at: { null: false }
+end
+
+class User < ApplicationRecord
+  has_many :points
+  has_many :in_time_points, -> { in_time }, class_name: "Point"
+
+  # Monatliche Bonuspunkte gewähren (vorausgeplant)
+  def grant_monthly_bonus(amount:, months_valid: 6)
+    points.create!(
+      amount: amount,
+      reason: "Monthly membership bonus",
+      start_at: 1.month.from_now,  # Wird nächsten Monat aktiviert
+      end_at: (1 + months_valid).months.from_now
+    )
+  end
+end
+```
+
+### Die Kraft von `has_many :in_time_points`
+
+Diese einfache Zeile ermöglicht **N+1-freies Eager Loading** für gültige Punkte:
+
+```ruby
+# 100 Benutzer mit ihren gültigen Punkten in nur 2 Abfragen laden
+users = User.includes(:in_time_points).limit(100)
+
+users.each do |user|
+  # Keine zusätzlichen Abfragen! Bereits geladen.
+  total = user.in_time_points.sum(&:amount)
+  puts "#{user.name}: #{total} points"
+end
+```
+
+Ohne diese Assoziation bräuchten Sie:
+
+```ruby
+# N+1-Problem: 1 Abfrage für Benutzer + 100 Abfragen für Punkte
+users = User.limit(100)
+users.each do |user|
+  total = user.points.in_time.sum(:amount)  # Abfrage pro Benutzer!
+end
+```
+
+## Verwendung
+
+### Punkte mit verschiedenen Gültigkeitszeiträumen gewähren
+
+```ruby
+user = User.find(1)
+
+# Sofortige Punkte (1 Jahr gültig)
+user.points.create!(
+  amount: 100,
+  reason: "Welcome bonus",
+  start_at: Time.current,
+  end_at: 1.year.from_now
+)
+
+# Vorausgeplante Punkte für 6-Monats-Mitglieder
+# Punkte werden nächsten Monat aktiviert, 6 Monate nach Aktivierung gültig
+user.grant_monthly_bonus(amount: 500, months_valid: 6)
+
+# Kampagnenpunkte (zeitlich begrenzt)
+user.points.create!(
+  amount: 200,
+  reason: "Summer campaign",
+  start_at: Date.parse("2024-07-01").beginning_of_day,
+  end_at: Date.parse("2024-08-31").end_of_day
+)
+```
+
+### Punkte abfragen
+
+```ruby
+# Aktuell gültige Punkte
+user.in_time_member_points.sum(:amount)
+# => 100 (nur der Willkommensbonus ist aktuell aktiv)
+
+# Prüfen, wie viele Punkte nächsten Monat verfügbar sein werden
+user.in_time_member_points(1.month.from_now).sum(:amount)
+# => 600 (Willkommensbonus + monatlicher Bonus)
+
+# Ausstehende Punkte (geplant aber noch nicht aktiv)
+user.points.before_in_time.sum(:amount)
+# => 500 (monatlicher Bonus wartet auf Aktivierung)
+
+# Abgelaufene Punkte
+user.points.after_in_time.sum(:amount)
+
+# Alle ungültigen Punkte (ausstehend + abgelaufen)
+user.points.out_of_time.sum(:amount)
+```
+
+### Admin-Dashboard-Abfragen
+
+```ruby
+# Historisches Audit: Punkte gültig an einem bestimmten Datum
+Point.in_time(Date.parse("2024-01-15").middle_of_day)
+     .group(:user_id)
+     .sum(:amount)
+```
+
+## Automatischer Mitgliedschaftsbonus-Ablauf
+
+Für 6-Monats-Premium-Mitglieder können Sie wiederkehrende Boni einrichten **ohne Cron, ohne Sidekiq, ohne Redis, ohne Monitoring**:
+
+```ruby
+# Wenn sich ein Benutzer für Premium anmeldet, Mitgliedschaft und alle Boni atomar erstellen
+ActiveRecord::Base.transaction do
+  membership = Membership.create!(user: user, plan: "premium_6_months")
+
+  # Alle 6 monatlichen Boni bei der Anmeldung vorab erstellen
+  6.times do |month|
+    user.points.create!(
+      amount: 500,
+      reason: "Premium member bonus - Month #{month + 1}",
+      start_at: (month + 1).months.from_now,
+      end_at: (month + 7).months.from_now  # Jeder Bonus 6 Monate gültig
+    )
+  end
+end
+# => Erstellt Mitgliedschaft + 6 Punktedatensätze, die monatlich aktiviert werden
+```
+
+## Warum dieses Design überlegen ist
+
+### Korrektheit
+
+- **Keine Race Conditions**: Cron-Jobs können zweimal laufen, Ausführungen überspringen oder sich überlappen. InTimeScope-Abfragen sind immer deterministisch.
+- **Kein Timing-Drift**: Cron läuft in Intervallen (jede Minute? alle 5 Minuten?). InTimeScope ist millisekundengenau.
+- **Keine verlorenen Updates**: Job-Fehler können Punkte in falschen Zuständen hinterlassen. InTimeScope hat keinen Zustand, der beschädigt werden kann.
+
+### Einfachheit
+
+- **Keine Infrastruktur**: Löschen Sie Sidekiq. Löschen Sie Redis. Löschen Sie das Job-Monitoring.
+- **Keine Migrationen für Status-Änderungen**: Die Zeit IST der Status. Keine `UPDATE`-Anweisungen nötig.
+- **Kein Debugging von Job-Logs**: Fragen Sie einfach die Datenbank ab, um genau zu sehen, was passiert.
+
+### Testbarkeit
+
+```ruby
+# Cron-basiertes Testen ist mühsam:
+travel_to 1.month.from_now do
+  ActivatePointsJob.perform_now
+  ExpirePointsJob.perform_now
+  expect(user.points.active.sum(:amount)).to eq(500)
+end
+
+# InTimeScope-Tests sind trivial:
+expect(user.points.in_time(1.month.from_now).sum(:amount)).to eq(500)
+```
+
+### Zusammenfassung
+
+| Aspekt | Cron-basiert | InTimeScope |
+|--------|-----------|-------------|
+| Infrastruktur | Sidekiq + Redis + Cron | **Keine** |
+| Punkteaktivierung | Batch-Job (verzögert) | **Sofort** |
+| Historische Abfragen | Unmöglich ohne Audit-Log | **Eingebaut** |
+| Timing-Genauigkeit | Minuten (Cron-Intervall) | **Millisekunden** |
+| Debugging | Job-Logs + Datenbank | **Nur Datenbank** |
+| Testen | Zeitreisen + Jobs ausführen | **Nur Abfrage** |
+| Fehlermodi | Viele (Job-Fehler, Race Conditions) | **Keine** |
+
+## Tipps
+
+1. **Verwenden Sie Datenbankindizes** auf `[user_id, start_at, end_at]` für optimale Performance.
+
+2. **Gewähren Sie Punkte vorab bei der Anmeldung** anstatt Cron-Jobs zu planen.
+
+3. **Verwenden Sie `in_time(time)` für Audits**, um Punktestände zu jedem historischen Zeitpunkt zu prüfen.
+
+4. **Kombinieren Sie mit inversen Scopes**, um Admin-Dashboards mit ausstehenden/abgelaufenen Punkten zu erstellen.

data/docs/de/user-name-history.md

@@ -0,0 +1,164 @@
+# Beispiel: Benutzernamen-Historie
+
+Dieses Beispiel zeigt, wie man die Benutzernamen-Historie mit `in_time_scope` verwaltet, sodass Sie den Namen eines Benutzers zu jedem Zeitpunkt abfragen können.
+
+Siehe auch: [spec/user_name_history_spec.rb](https://github.com/kyohah/in_time_scope/blob/main/spec/user_name_history_spec.rb)
+
+## Anwendungsfall
+
+- Benutzer können ihren Anzeigenamen ändern
+- Sie müssen eine Historie aller Namensänderungen aufbewahren
+- Sie möchten den Namen abrufen, der zu einem bestimmten Zeitpunkt aktiv war (z.B. für Audit-Logs, historische Berichte)
+
+## Schema
+
+```ruby
+# Migration
+class CreateUserNameHistories < ActiveRecord::Migration[7.0]
+  def change
+    create_table :users do |t|
+      t.string :email, null: false
+      t.timestamps
+    end
+
+    create_table :user_name_histories do |t|
+      t.references :user, null: false, foreign_key: true
+      t.string :name, null: false
+      t.datetime :start_at, null: false  # Wann dieser Name aktiv wurde
+      t.timestamps
+    end
+
+    add_index :user_name_histories, [:user_id, :start_at]
+  end
+end
+```
+
+## Modelle
+
+```ruby
+class UserNameHistory < ApplicationRecord
+  belongs_to :user
+  include InTimeScope
+
+  # Nur-Start-Muster: Jeder Datensatz ist von start_at bis zum nächsten Datensatz gültig
+  in_time_scope start_at: { null: false }, end_at: { column: nil }
+end
+
+class User < ApplicationRecord
+  has_many :user_name_histories
+
+  # Den aktuellen Namen abrufen (neuester Datensatz, der begonnen hat)
+  has_one :current_name_history,
+          -> { latest_in_time(:user_id) },
+          class_name: "UserNameHistory"
+
+  # Praktische Methode für den aktuellen Namen
+  def current_name
+    current_name_history&.name
+  end
+
+  # Namen zu einem bestimmten Zeitpunkt abrufen
+  def name_at(time)
+    user_name_histories.in_time(time).order(start_at: :desc).first&.name
+  end
+end
+```
+
+## Verwendung
+
+### Namenshistorie erstellen
+
+```ruby
+user = User.create!(email: "alice@example.com")
+
+# Anfänglicher Name
+UserNameHistory.create!(
+  user: user,
+  name: "Alice",
+  start_at: Time.parse("2024-01-01")
+)
+
+# Namensänderung
+UserNameHistory.create!(
+  user: user,
+  name: "Alice Smith",
+  start_at: Time.parse("2024-06-01")
+)
+
+# Weitere Namensänderung
+UserNameHistory.create!(
+  user: user,
+  name: "Alice Johnson",
+  start_at: Time.parse("2024-09-01")
+)
+```
+
+### Namen abfragen
+
+```ruby
+# Aktueller Name (verwendet has_one mit latest_in_time)
+user.current_name
+# => "Alice Johnson"
+
+# Name zu einem bestimmten Zeitpunkt
+user.name_at(Time.parse("2024-03-15"))
+# => "Alice"
+
+user.name_at(Time.parse("2024-07-15"))
+# => "Alice Smith"
+
+user.name_at(Time.parse("2024-10-15"))
+# => "Alice Johnson"
+```
+
+### Effizientes Eager Loading
+
+```ruby
+# Benutzer mit ihren aktuellen Namen laden (kein N+1)
+users = User.includes(:current_name_history).limit(100)
+
+users.each do |user|
+  puts "#{user.email}: #{user.current_name_history&.name}"
+end
+```
+
+### Aktive Datensätze abfragen
+
+```ruby
+# Alle Namensdatensätze, die aktuell aktiv sind
+UserNameHistory.in_time
+# => Gibt den neuesten Namensdatensatz für jeden Benutzer zurück
+
+# Namensdatensätze, die zu einem bestimmten Zeitpunkt aktiv waren
+UserNameHistory.in_time(Time.parse("2024-05-01"))
+
+# Namensdatensätze, die noch nicht begonnen haben (für die Zukunft geplant)
+UserNameHistory.before_in_time
+```
+
+## Wie `latest_in_time` funktioniert
+
+Der `latest_in_time(:user_id)` Scope generiert eine effiziente `NOT EXISTS` Unterabfrage:
+
+```sql
+SELECT * FROM user_name_histories AS h
+WHERE h.start_at <= '2024-10-01'
+  AND NOT EXISTS (
+    SELECT 1 FROM user_name_histories AS newer
+    WHERE newer.user_id = h.user_id
+      AND newer.start_at <= '2024-10-01'
+      AND newer.start_at > h.start_at
+  )
+```
+
+Dies gibt nur den neuesten Datensatz pro Benutzer zurück, der zum gegebenen Zeitpunkt aktiv war, was es perfekt für `has_one` Assoziationen macht.
+
+## Tipps
+
+1. **Verwenden Sie immer `latest_in_time` mit `has_one`** - Es stellt sicher, dass Sie genau einen Datensatz pro Fremdschlüssel erhalten.
+
+2. **Fügen Sie einen zusammengesetzten Index hinzu** auf `[user_id, start_at]` für optimale Abfrageleistung.
+
+3. **Verwenden Sie `includes` für Eager Loading** - Das `NOT EXISTS`-Muster funktioniert effizient mit Rails Eager Loading.
+
+4. **Erwägen Sie das Hinzufügen einer Unique-Constraint** auf `[user_id, start_at]`, um doppelte Datensätze zum gleichen Zeitpunkt zu verhindern.

data/docs/fr/SUMMARY.md

@@ -0,0 +1,5 @@
+# Sommaire
+
+- [Introduction](./index.md)
+- [Système de points avec expiration](./point-system.md)
+- [Historique des noms d'utilisateur](./user-name-history.md)