khadhroony-solana-project/docs/rules/RULES_KSP.md

Règles spécifiques à KSP

Nomenclature

• KSP-NAME-001 — Une bibliothèque Rust d'implémentation réutilisable se nomme ksp-<role>-lib, sauf famille explicitement définie par une règle plus spécifique.
• KSP-NAME-002 — Une crate publique de contrats extensibles se nomme ksp-<domain>-api. Elle est techniquement une bibliothèque Rust mais ne porte volontairement pas le suffixe -lib.
• KSP-NAME-003 — Une crate ksp-<domain>-api expose principalement les types/traits/contrats nécessaires aux implémentations ; elle n'est pas une implémentation fonctionnelle directement destinée aux exécutables.
• KSP-NAME-004 — Une application se nomme ksp-app-<role>-<interface> lorsque l'interface doit être indiquée.
• KSP-NAME-005 — Un worker continu se nomme ksp-worker-<role>.
• KSP-NAME-006 — Un job ponctuel/historique/terminable se nomme ksp-job-<role>.
• KSP-NAME-007 — Une démonstration se termine par -demo.
• KSP-NAME-008 — Les crates Rust sont placées directement sous crates/.
• KSP-NAME-009 — Une application desktop de scénario spécialisée suit la forme ksp-app-scenario-<domain>-<environment>-desk-demo lorsque l'environnement est imposé.

Architecture et APIs

• KSP-API-001 — Un domaine extensible peut séparer ksp-<domain>-api et ksp-<domain>-lib.
• KSP-API-002 — Les premiers couples retenus sont ksp-program-api / ksp-program-lib, ksp-materializer-api / ksp-materializer-lib et ksp-store-api / ksp-store-lib.
• KSP-API-003 — KSP ne crée pas de ksp-api-lib monolithique regroupant les contrats de domaines indépendants.
• KSP-API-004 — Un contrat public extensible doit pouvoir être implémenté depuis une crate séparée du workspace principal lorsque cela est techniquement pertinent.
• KSP-API-005 — Les signatures des contrats publics utilisent en priorité des types publics KSP et les primitives externes explicitement admises ; elles ne doivent pas imposer des détails internes instables.
• KSP-API-006 — ksp-store-lib contient PostgreSQL comme implémentation officielle de référence derrière ksp-store-api.
• KSP-API-007 — Une crate *-api n'est créée que lorsqu'un vrai besoin d'extension, backend ou lifecycle le justifie ; la symétrie de nommage n'est jamais une justification suffisante.

Programmes et exécution

• KSP-PROGRAM-001 — Les contrats decoder/executor appartiennent à ksp-program-api; les implémentations officielles intégrées appartiennent à ksp-program-lib.
• KSP-PROGRAM-002 — Le decoder vise toute surface techniquement décodable dont la définition est connue, y compris les formats anciens, obsolètes ou expérimentaux encore distinguables.
• KSP-PROGRAM-003 — Le statut deprecated concerne la capacité d'exécution, pas la capacité de décodage.
• KSP-PROGRAM-004 — Lorsqu'une définition wire a été réellement écrasée/remplacée sous la même identité et que l'ancienne définition n'est plus distinguable de manière fiable, le decoder utilise la définition la plus récente applicable.
• KSP-PROGRAM-005 — Une opération devenue obsolète mais toujours identifiable/exécutable peut rester implémentée dans l'executor et être marquée deprecated.
• KSP-PROGRAM-006 — ksp-program-lib ne contient pas la politique de sécurité de production.
• KSP-EXEC-001 — ksp-execution-policy-api est retenu comme API publique de policy d'exécution afin que plusieurs contextes puissent fournir des politiques différentes sans modifier ksp-program-lib.
• KSP-EXEC-002 — Une application UI sélectionne/injecte une implémentation de policy réutilisable ; elle ne doit pas enfouir une politique d'exécution complexe dans sa couche d'interface.
• KSP-EXEC-003 — ksp-execution-lib est retenu comme orchestration spécialisée entre programme, policy, wallet et transport. Il dépend de ksp-program-api et non de ksp-program-lib.

Transports

• KSP-TRANSPORT-001 — KSP ne crée pas de ksp-onchain-transport-api séparée dans l'architecture actuelle.
• KSP-TRANSPORT-002 — ksp-onchain-transport-lib ne dépend pas de ksp-store-api.
• KSP-TRANSPORT-003 — Les providers on-chain normalisent leurs sorties dans des modèles de transport homogènes par catégorie de données avant exposition aux consommateurs.
• KSP-TRANSPORT-004 — Les modèles de transport restent sans décodage métier/protocolaire et doivent être explicitement/facilement convertibles vers les modèles raw persistants de ksp-store-api par la couche d'acquisition.
• KSP-TRANSPORT-005 — KSP ne crée pas de ksp-offchain-transport-api globale ni de trait universel artificiel pour des domaines off-chain hétérogènes.

Wallet

• KSP-WALLET-001 — KSP ne crée pas de ksp-wallet-api dans l'architecture actuelle ; ksp-wallet-lib possède le format wallet KSP et ses capacités de lecture/protection/import/export/pubkey/secret/signature.

Workers

• KSP-WORKER-001 — Un worker représente un service continu/live ; il est distinct d'un job.
• KSP-WORKER-002 — Les contrats communs des workers appartiennent à ksp-worker-api et ne contiennent aucun contrat propre aux jobs.
• KSP-WORKER-003 — ksp-worker-api est principalement une lifecycle API de services continus : identité, état, health, démarrage/arrêt et événements communs ; les capacités optionnelles ne deviennent universelles que si plusieurs workers les partagent réellement.
• KSP-WORKER-004 — ksp-worker-control-lib est une implémentation commune de gouvernance/contrôle réutilisable par managers desktop, future application globale et orchestrateur ; les apps ne réimplémentent pas cette gouvernance.
• KSP-WORKER-005 — ksp-worker-raw-retriever est le worker d'acquisition raw live/quasi-live. Il ne décode pas, ne matérialise pas et ne réalise pas de replay/backfill historique.
• KSP-WORKER-006 — ksp-worker-raw-retriever persiste les données raw puis notifie leur disponibilité selon les contrats de données normalisés.
• KSP-WORKER-007 — ksp-worker-raw-retriever doit pouvoir faire évoluer à chaud les listeners et la sélection des données qu'il rapatrie/stocke.
• KSP-WORKER-008 — Les workers de processing actuellement retenus sont ksp-worker-core-processor, ksp-worker-generic-materializer et ksp-worker-domain-projector; le dernier nom reste provisoire.

Jobs

• KSP-JOB-001 — Un job représente un travail déclenché à la demande, suivable et terminable ; il est distinct d'un worker continu.
• KSP-JOB-002 — Les contrats communs des jobs appartiennent à ksp-job-api et ne contiennent aucun contrat propre aux workers.
• KSP-JOB-003 — ksp-job-api est principalement une lifecycle API de travaux terminables : identité, état, progression, annulation, résultat et capacités de reprise lorsqu'elles sont pertinentes.
• KSP-JOB-004 — Les implémentations concrètes utilisent le préfixe ksp-job-.
• KSP-JOB-005 — ksp-job-backfill est retenu pour le backfill historique ; il ne doit pas être implémenté comme un mode du worker raw.
• KSP-JOB-006 — D'autres jobs peuvent être introduits pour metadata, quotes ou autres travaux ponctuels lorsqu'un besoin réel le justifie.
• KSP-JOB-007 — Aucune ksp-job-control-lib commune n'est prévue actuellement ; elle ne sera créée que si une duplication concrète entre plusieurs jobs le justifie.
• KSP-JOB-008 — Le contrôle/gouvernance des jobs reste séparé du contrôle des workers.

Matérialisation et persistence

• KSP-MAT-001 — ksp-materializer-api peut dépendre de ksp-program-api ; ksp-materializer-lib dépend de son API mais ne dépend pas du store.
• KSP-MAT-002 — ksp-materializer-api / ksp-materializer-lib ne réalisent pas eux-mêmes la persistance ; les workers/jobs/pipelines spécialisés composent matérialisation et store.
• KSP-STORE-001 — ksp-store-api reste indépendant des APIs Program/Materializer/Transport et possède les contrats persistants.
• KSP-STORE-002 — Les conversions entre modèles runtime et DTO persistants sont explicites aux frontières de composition ; aucun ksp-data-api global n'est introduit actuellement.

Notifications de données

• KSP-DATA-001 — Une notification de donnée décrit la donnée disponible et non le worker/job qui l'a produite.
• KSP-DATA-002 — Le même type de donnée utilise le même contrat de notification quelle que soit son origine : worker, job, import ou autre source.
• KSP-DATA-003 — ksp-store-api est le propriétaire retenu des références/notifications canoniques lorsqu'elles signifient qu'une donnée persistée est disponible.
• KSP-DATA-004 — Le contrat de notification est séparé de son mécanisme de transport concret.

Pipelines et scénarios

• KSP-PIPE-001 — KSP ne crée pas de ksp-pipeline-lib monolithique. Les pipelines sont introduits séparément à la demande selon leur responsabilité réelle.
• KSP-SCENARIO-001 — Il n'existe pas de crate monolithique ksp-scenarios-lib.
• KSP-SCENARIO-002 — Les scénarios sont séparés en crates ksp-scenario-<domain>-lib par responsabilité fonctionnelle cohérente.
• KSP-SCENARIO-003 — ksp-scenario-api n'est pas retenu actuellement ; KSP privilégie d'abord une norme documentaire/structurelle commune qui ne limite pas les contrats spécifiques des scénarios.
• KSP-SCENARIO-004 — Memo, SPL Token classique, ATA et Token-2022 restent dans des crates/scénarios séparés.
• KSP-SCENARIO-005 — Une famille metadata d'assets/tokens peut regrouper Metaplex Token Metadata et Token-2022 Metadata ; Solana Program Metadata reste séparé.
• KSP-SCENARIO-006 — Lorsqu'un scénario réutilisable existe dans KSP, l'application demo le consomme et ne réimplémente pas le workflow.

Applications

• KSP-APP-001 — Une application KSP est une interface et une couche de composition. Elle ne réimplémente pas une opération appartenant conceptuellement à un composant KSP réutilisable inférieur.
• KSP-APP-002 — Les applications/demos ne dépendent pas directement de crates Solana/protocoles externes.
• KSP-APP-003 — Les applications/demos peuvent réaliser les opérations strictement liées à l'interface, mais pas la logique métier/protocolaire réutilisable.
• KSP-APP-004 — Une demo scenario desktop consomme la crate ksp-scenario-<domain>-lib correspondante ; elle suit la convention ksp-app-scenario-<domain>-<environment>-desk-demo lorsque l'environnement est imposé.