<!-- file: docs/IDEA_REMINDERS.md -->
<!-- version: 8 -->

# Rappels d’idées

Ce document conserve les idées utiles qui ne constituent pas encore des engagements de version ainsi que quelques repères de portefeuille explicitement demandés comme rappels. Lorsqu’une orientation est devenue normative, le document actif correspondant est indiqué et reste prioritaire.

## Positionnement futur des projets

Repères durables de portefeuille, désormais également formalisés dans la politique de namespace active :

- `khadhroony-project` est une umbrella de projets de trading et/ou de crypto ; elle n'est pas limitée à Solana ni même à la crypto ;
- des projets futurs pourront par exemple viser XTB (`khadhroony-xtb`) ou MetaTrader (`khadhroony-mt5`) sans dépendre de Solana ;
- `khadhroony-solana` regroupe les bibliothèques généralistes dédiées à Solana et converge vers les namespaces `ks-*`, `ks_*` et `KS_*` ;
- `ks-pipeline-demo-scenarios` appartient à ce domaine Solana généraliste : les scénarios de validation ne sont pas spécifiques au bot ;
- `khadhroony-bot` / bot3 doit devenir le robot de trading consommant les composants Khadhroony Solana, avec à terme analyse/création de stratégies et exécution de trading automatique ;
- `kb-app-demo-desktop` reste côté Bot : il valide aujourd'hui surtout les composants Solana généralistes mais pourra aussi accueillir des démonstrations spécifiques au bot ;
- les identités techniques généralistes doivent migrer vers `ks-lib-decoder.*`, `ks-lib-materializer.*` et `ks-lib-executor.*` ;
- les tables Solana doivent à terme utiliser `k_sol_*`, tandis que `kb_*` est réservé aux éventuelles tables réellement spécifiques au domaine Bot.

La décision normative et son calendrier sont dans [`decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md`](decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md).

## Application desktop

- autocomplétion Token et Pool lorsque des tables de référence fiables existeront ;
- pagination SQL/IPC côté serveur avant l’exploitation de volumes massifs ;
- résolution configurable du chemin de base de `kb-store` ;
- sélection indépendante du profil de logging ;

## Pipeline et PostgreSQL

- dimensionnement dynamique de la concurrence Decode replay selon le pool ;
- retry borné et observable des erreurs transitoires ;
- compteurs séparés pour erreurs fonctionnelles, traitement, stockage, reprises et échecs finaux ;
- persistance éventuelle des erreurs survenant avant l’écriture du ledger.

## Documentation et outils

- refaire les scripts Python d’audit après stabilisation définitive de la nomenclature ;
- maintenir un inventaire des IDL avec source, version/commit, Program ID et surfaces utilisatrices ;
- rescanner les archives bot2 et bobobot avant de déclarer le registre Program IDs complet.

## Workers et applications

L’orientation W1/W2, rattrapage historique, application de contrôle et applications consommatrices est désormais intégrée au ROADMAP. Les points encore ouverts sont :

- mécanisme de notification fiable entre acquisition, stockage et décodage ;
- ownership et idempotence entre W2 et le rattrapage historique ;
- configuration à chaud et reprise après erreur ;
- métriques, files d’attente et contrats d’administration ;
- frontière entre événements temps réel et historiques OHLC.