khadhroony-solana-project/deltas/0.0.3/pre.008.md

Delta 0.0.3-pre.008

Base requise

v0.0.3-pre.007.

Objectif

Formaliser applications spécialisées, workers autonomes, control plane et convention des scenarios sans créer prématurément une application globale ou une infrastructure IPC générique.

Version Cargo

workspace.package.version passe de :

0.0.3-pre.7

à :

0.0.3-pre.8

Le header de Cargo.toml passe de version 13 à 14.

Fichiers ajoutés

• docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md
• docs/rules/SCENARIO_CONVENTION.md
• deltas/0.0.3/pre.008.md

Fichiers modifiés

• Cargo.toml
• ROADMAP.md
• docs/architecture/000-README.md
• docs/architecture/003-COMPONENT_CONTRACTS.md
• docs/architecture/004-COMPONENT_INVENTORY.md
• docs/architecture/005-DEPENDENCY_GRAPH.md
• docs/rules/RULES_DEPENDENCIES.md
• docs/rules/RULES_KSP.md
• docs/IDEAS.md
• docs/plans/001-V0_0_3_PLAN.md
• prompts/001-V0_1_X_START_PROMPT.md

Fichiers supprimés

Aucun.

Décisions principales

Applications spécialisées d'abord

KSP ne planifie pas actuellement d'application globale de contrôle.

Les applications spécialisées et demos doivent d'abord permettre de développer, tester et valider chaque capacité.

La future application globale est conservée dans docs/IDEAS.md comme produit attendu mais non planifié.

Workers services indépendants

Chaque worker doit pouvoir fonctionner comme service/processus autonome afin de pouvoir être arrêté, redémarré ou mis à jour sans imposer l'arrêt des autres.

Direction de packaging préférée :

package ksp-worker-<role>
├── library target
└── binary target

La bibliothèque porte le runtime/logique du worker ; le binaire reste un bootstrap/service wrapper mince.

Pas de dépendance worker-to-worker

Les workers se synchronisent via Store D1–D4 et notifications de wake-up.

Ils ne transportent pas les données directement entre processus.

Pas d'ordre global strict figé

Aucun ordre obligatoire de démarrage des workers n'est inscrit dans les contrats.

Un futur manager/orchestrateur pourra adopter un ordre pratique, mais les workers restent conçus pour tolérer un upstream temporairement absent.

Data plane / control plane

Data plane :

transport -> D1 -> D2 -> D3 -> D4

Control plane :

worker-api
worker-control-lib
job-api
future IPC
future managers/orchestrator

Les payloads de processing ne transitent pas dans le control plane.

ksp-worker-control-lib

Il reste la gouvernance commune des workers et doit pouvoir, à terme, travailler avec un handle local ou un proxy distant conforme aux mêmes contrats Worker.

IPC

Le besoin d'IPC est reconnu pour piloter les services autonomes.

Aucun ksp-ipc-api générique n'est créé maintenant.

Le premier manager/service réel déterminera le mécanisme et dira s'il faut un adapter interne à ksp-worker-control-lib ou une bibliothèque spécialisée.

Scenarios

La logique du scenario appartient exclusivement à :

ksp-scenario-<domain>-lib

L'app desktop demo appelle cette bibliothèque et ne recrée pas le workflow.

La même crate scenario doit pouvoir être appelée depuis test, futur CLI/tool ou CI lorsque pertinent.

Convention scenario

docs/rules/SCENARIO_CONVENTION.md remplace pour l'instant le besoin d'un ksp-scenario-api.

Elle définit notamment :

• indépendance de Tauri ;
• environnement explicite ;
• utilisation des capacités KSP ;
• execution policy explicite ;
• résultat exploitable par le caller ;
• validation/evidence dans la crate scenario ;
• logging via ksp-logging-lib.

Future orchestration

ksp-orchestrator-lib reste un concept futur seulement.

La future application globale reste également une idée future seulement.

Roadmap

La tâche « application globale de supervision/contrôle » est retirée du roadmap concret.

Le roadmap conserve les applications spécialisées et le mode service autonome des workers.

Plan restant

• pre.009 — découpage des premières releases fonctionnelles concrètes ;
• pre.010 — clôture fondatrice et prompt final.

Questions reportées

• mécanisme IPC concret ;
• discovery/authentication/framing du control plane ;
• nom exact des apps worker manager ;
• packaging/exécution des jobs ;
• graceful service update/restart ;
• éventuel ordre pratique de démarrage ;
• futur orchestrateur ;
• nom/scope/release de l'application globale.

Validations

• headers file: / version: vérifiés ;
• Cargo.toml parsé et version 0.0.3-pre.8 vérifiée ;
• référence vers 010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md vérifiée ;
• SCENARIO_CONVENTION.md ajouté ;
• application globale retirée des tâches roadmap et conservée dans IDEAS ;
• packaging lib + bin des workers documenté ;
• absence d'un ordre global strict documentée ;
• plan conservé jusqu'à pre.010 ;
• aucune commande Cargo build/test exécutée : ce delta reste documentaire.