430 lines
22 KiB
Markdown
430 lines
22 KiB
Markdown
<!-- file: docs/IDEAS.md -->
|
||
<!-- version: 27 -->
|
||
|
||
# Idées à explorer
|
||
|
||
Ce document conserve les idées, pistes, questions et alternatives qui méritent d'être étudiées sans constituer encore un engagement de développement ou une décision architecturale.
|
||
|
||
## Statuts
|
||
|
||
- `À explorer`
|
||
- `En exploration`
|
||
- `Retenue`
|
||
- `Rejetée`
|
||
- `Transférée au roadmap`
|
||
- `Transférée vers une décision/règle`
|
||
|
||
## APIs et extensibilité
|
||
|
||
### Nomenclature `*-api`
|
||
|
||
**Status :** Retenue
|
||
|
||
Les crates de contrats publics extensibles utilisent `ksp-<domain>-api`, sans suffixe `-lib`.
|
||
|
||
Premiers couples retenus : program, materializer et store. Les APIs worker/job sont des lifecycle APIs distinctes.
|
||
|
||
### Execution policy API
|
||
|
||
**Status :** Transférée vers une décision/règle
|
||
|
||
`ksp-execution-policy-api` est retenu comme contrat commun d'autorisation/safety/policy d'une exécution.
|
||
|
||
Le contrat doit permettre des implémentations différentes selon le contexte, par exemple scenario Devnet, application générale ou futur produit trading.
|
||
|
||
L'UI sélectionne/injecte une implémentation réutilisable ; elle ne doit pas devenir propriétaire d'une politique complexe.
|
||
|
||
### Execution orchestration
|
||
|
||
**Status :** Transférée vers une décision/règle
|
||
|
||
`ksp-execution-lib` est retenu comme orchestration spécialisée entre programme, policy, wallet et transport. Il dépend de `ksp-program-api`, pas de l'implémentation `ksp-program-lib`.
|
||
|
||
La frontière d'orchestration et les checkpoints de policy sont définis dans `007-EXECUTION_AND_POLICY.md`; les types Rust exacts restent à définir avec l'implémentation.
|
||
|
||
### Scenarios : norme avant API
|
||
|
||
**Status :** Retenue
|
||
|
||
Ne pas créer `ksp-scenario-api` pour l'instant.
|
||
|
||
Définir d'abord une norme souple de structure, métadonnées, exécution et résultat des crates `ksp-scenario-<domain>-lib`, sans imposer un trait Rust qui limiterait des scénarios hétérogènes.
|
||
|
||
Réévaluer seulement si les premières implémentations révèlent un vrai contrat commun.
|
||
|
||
### Type d'erreur KSP unique
|
||
|
||
**Status :** En exploration
|
||
|
||
La direction retenue est un seul type public `ksp_core_lib::Error` consommable par le workspace sans obliger `ksp-core-lib` à connaître chaque domaine supérieur.
|
||
|
||
### Nommage des items publics
|
||
|
||
**Status :** À explorer
|
||
|
||
Définir avec les premières APIs réelles les conventions de nommage des traits, structs, enums, aliases, constantes et autres items exportés publiquement.
|
||
|
||
### Arborescence et réexports
|
||
|
||
**Status :** À explorer
|
||
|
||
Définir avec les premières crates fonctionnelles les conventions d'arborescence, façades `lib.rs`, modules API et réexports publics.
|
||
|
||
### API Interface séparée
|
||
|
||
**Status :** Rejetée pour l'instant
|
||
|
||
`ksp-interface-lib` expose sa propre API publique wire afin que des crates Program externes puissent expérimenter contre les mêmes contrats que les implementations officielles.
|
||
|
||
Ne créer `ksp-interface-api` que si un futur problème réel de graphe de dépendances, de poids d'implémentation ou de publication démontre qu'un contrat séparé est nécessaire. La symétrie avec `ksp-program-api` n'est pas une justification suffisante.
|
||
|
||
## Transport
|
||
|
||
### Modèles homogènes on-chain
|
||
|
||
**Status :** Retenue
|
||
|
||
`ksp-onchain-transport-lib` ne dépend pas de `ksp-store-api`, mais ses différents providers doivent exposer des modèles homogènes par catégorie de données afin que `ksp-worker-raw-retriever` puisse les convertir simplement vers les modèles raw persistants du store.
|
||
|
||
Aucune `ksp-onchain-transport-api` séparée n'est prévue.
|
||
|
||
### Modèles communs inter-domaines
|
||
|
||
**Status :** À explorer avec l'implémentation
|
||
|
||
Aucun `ksp-data-api` global n'est prévu actuellement. Les modèles appartiennent à leur responsabilité (transport, program, materializer, store) et les composants de composition réalisent les conversions explicites.
|
||
|
||
Réévaluer seulement si les premières implémentations montrent une duplication réellement nuisible impossible à résoudre sans contrat commun supplémentaire.
|
||
|
||
### Événement passif de logs transaction
|
||
|
||
**Status :** À explorer après la première surface d'événements Interface
|
||
|
||
Conserver `TransactionLogEvent` comme idée différée, sans type public tant qu'un consumer concret et des bornes sûres ne sont pas démontrés. Le futur gate doit comparer au minimum `logsSubscribe` et les formes transaction/meta des transports réellement consommés, sans supposer que leur richesse, leur volumétrie ou leur disponibilité sont identiques.
|
||
|
||
Un éventuel contrat partagé doit rester un fait passif provider-neutral, distinct de `TransactionExecutionEvent` et des logs replayables contenus dans `RawTransaction`. Il ne doit créer ni `RawLog` Store par défaut, ni event bus Interface, ni wrapper d'un DTO Transport.
|
||
|
||
### Mesure du trafic et metering futur
|
||
|
||
**Status :** À explorer plus tard
|
||
|
||
Ne pas introduire de métriques de volume supplémentaires dans `ksp-onchain-transport-lib` pendant `0.2.7`. La surface HTTP/WebSocket doit d'abord être clôturée et les besoins réels doivent être observés avec le futur stockage raw.
|
||
|
||
La direction à étudier est de conserver `ksp-onchain-transport-lib` comme source de vérité pour les faits effectivement observés à la frontière réseau, par exemple volumes de payload entrants/sortants, requêtes/réponses, notifications WebSocket, retries et reconnects. Ces mesures doivent rester neutres et ne pas embarquer de modèle de prix, de crédits ou de facturation propre à un fournisseur.
|
||
|
||
Le futur Store conservera les données raw nécessaires aux analyses historiques sur les types de réponses, leurs tailles, leur fréquence et leur distribution. Il ne doit cependant pas être considéré comme la source de vérité des octets réellement transportés, car les données persistées peuvent différer de ce qui a été reçu ou envoyé sur le réseau.
|
||
|
||
Étudier ultérieurement une crate dédiée, nom provisoire `ksp-metering-lib` ou `ksp-metering-observer-lib`, chargée d'observer/agréger ces mesures sans devenir un filtre obligatoire dans le data path. Son nom, son API, sa relation exacte avec Store et la granularité des événements restent à définir.
|
||
|
||
Le besoin visé est d'abord l'observabilité et l'analyse statistique internes KSP ; aucune dépendance aux données de facturation remontées par les fournisseurs n'est requise.
|
||
|
||
### Off-chain volontairement hétérogène
|
||
|
||
**Status :** Retenue
|
||
|
||
`ksp-offchain-transport-lib` regroupe metadata, prix, quotes, routage et autres accès externes afin d'éviter une explosion de crates. Il n'est pas nécessaire de leur inventer une API métier commune.
|
||
|
||
### Pool automatique de sessions WebSocket
|
||
|
||
**Status :** À explorer après `0.2.7`
|
||
|
||
Le contrat WebSocket doit autoriser plusieurs sessions physiques sur une même URL, chaque session portant plusieurs subscriptions.
|
||
|
||
Ne pas implémenter automatiquement un scheduler/pool de sessions tant qu'un besoin réel de distribution de charge, quotas provider, isolation de flux ou reconnexion indépendante ne le justifie pas.
|
||
|
||
### Providers Yellowstone avancés
|
||
|
||
**Status :** À explorer après la fondation standard
|
||
|
||
Candidats à intégrer ultérieurement par adapters/capabilities sans dupliquer le client Yellowstone générique :
|
||
|
||
- Helius LaserStream gRPC ;
|
||
- Triton One / Dragon's Mouth ;
|
||
- ERPC ;
|
||
- Chainstack ;
|
||
- Shyft ;
|
||
- autres providers compatibles réellement utiles.
|
||
|
||
Le choix dépendra des capacités, quotas, replay, authentification, prix et besoins opérationnels au moment de leur introduction.
|
||
|
||
### Streaming pré-exécution / shreds
|
||
|
||
**Status :** À explorer plus tard
|
||
|
||
Conserver comme pistes séparées les offres pré-exécution/shred/deshred (Helius Shred Delivery, Triton/Yellowstone deshred, Shyft RabbitStream ou équivalents). Leur sémantique n'est pas identique à un flux exécuté Yellowstone standard et elles ne doivent pas être ajoutées comme simples aliases provider sans audit.
|
||
|
||
## Workers et jobs
|
||
|
||
### Workers de processing
|
||
|
||
**Status :** Retenue, granularité révisée
|
||
|
||
RAW et CORE peuvent disposer de workers dédiés à la fin de leur couche respective.
|
||
|
||
À partir de DECODE, ne pas figer à l'avance une chaîne globale `generic-materializer -> domain-projector` pour tout Solana : la granularité des workers/processors doit émerger des vertical slices Program réels et réutiliser les mêmes transformations que les jobs de replay correspondants.
|
||
|
||
### Worker control
|
||
|
||
**Status :** Retenue comme direction
|
||
|
||
`ksp-worker-control-lib` doit être une implémentation réutilisable de gouvernance consommable par des applications desktop manager, puis par la future application globale et, si un besoin réel le justifie, par un éventuel orchestrateur commun.
|
||
|
||
### Job control
|
||
|
||
**Status :** Rejetée pour l'instant
|
||
|
||
Ne pas créer `ksp-job-control-lib` sans duplication concrète entre plusieurs jobs. `ksp-job-api` suffit comme lifecycle API commune tant que chaque job peut être gouverné directement via son implémentation.
|
||
|
||
## Wallet : applications futures
|
||
|
||
### Wallet Android
|
||
|
||
**Status :** À explorer — futur lointain
|
||
|
||
Une application Android native utilisant `ksp-wallet-lib` est envisagée. Nom exact à définir plus tard, candidat : `ksp-app-wallet-android`.
|
||
|
||
### Extensions navigateur
|
||
|
||
**Status :** À explorer — futur lointain
|
||
|
||
Prévoir potentiellement des extensions Firefox et Chrome consommant les capacités KSP appropriées. Noms candidats non normatifs :
|
||
|
||
```text
|
||
ksp-app-wallet-firefox-extension
|
||
ksp-app-wallet-chrome-extension
|
||
```
|
||
|
||
Le modèle de sécurité, la frontière Rust/WebAssembly/native et le stockage des secrets devront être étudiés avant toute décision.
|
||
|
||
### Wallet web
|
||
|
||
**Status :** À explorer — futur lointain
|
||
|
||
Un wallet web/online utilisant les contrats KSP est envisagé. La gestion des secrets et le modèle de confiance devront être traités comme une question architecturale majeure avant développement.
|
||
|
||
### Formats Wallet import/export supplémentaires
|
||
|
||
**Status :** À explorer avec `0.2.5` et après
|
||
|
||
Le format natif KSP est `.kspwallet`. L'architecture d'import/export doit rester extensible, mais seules les conversions réellement nécessaires sont implémentées immédiatement.
|
||
|
||
Formats/cibles à inventorier et prioriser selon usage réel :
|
||
|
||
- Solana CLI keypair JSON — **acquis dans `0.2.5-pre.008`** ;
|
||
- keypair Base58 complet — **acquis dans `0.2.5-pre.008`** ;
|
||
- Phantom, en privilégiant le wire Solana générique réellement documenté plutôt qu'un codec de marque inutile ;
|
||
- Solflare, y compris réévaluation du keystore protégé seulement si son format public devient suffisamment stable pour un round-trip testé ;
|
||
- Backpack : caractériser le wire Solana exact de l'import `Private key` avant tout codec/alias dédié ;
|
||
- Trust Wallet : caractériser le wire Solana exact d'import/export avant implémentation ;
|
||
- Base app / ex-Coinbase Wallet : ne jamais synthétiser une recovery phrase depuis une keypair arbitraire ; réévaluer uniquement si un import direct de keypair Solana est officiellement spécifié ;
|
||
- distinguer Coinbase Developer Platform d'un wallet utilisateur Base/Coinbase si son API d'import/export est étudiée ;
|
||
- autres wallets logiciels Solana ;
|
||
- hardware wallets / standards de dérivation si un besoin apparaît ;
|
||
- migrations depuis formats historiques KSP/bot uniquement si utiles aux utilisateurs réels.
|
||
|
||
Chaque format doit être étudié côté sécurité, round-trip, secret/public, dépendances et compatibilité avant engagement.
|
||
|
||
### `.kspwallet` V2 binaire et formats futurs
|
||
|
||
**Status :** Transférée vers une décision/règle pour V2 stable en `0.2.6` / facteurs futurs à explorer
|
||
|
||
Le JSON V1 reste le format historique stable et lisible. Base64 seul n’apporte aucune sécurité et resterait un texte trivialement décodable avec environ un tiers de surcharge. La décision initialement envisagée pour `0.2.7` a été ramenée dans `0.2.6` : `pre.015` définit un **wire binaire V2 KSP** avec magic/framing explicite, entiers big-endian, identifiants numériques stables, longueurs bornées et lecture/écriture canonique stricte. V1 reste supporté sans réinterprétation ; la façade de lecture multi-version, la création/persistence V2, les APIs `_v1/_v2` et la politique `DEFAULT_WALLET_FORMAT = V2` sont matérialisées en `pre.016`, puis la migration explicite OWNER-authentifiée V1 -> V2 est matérialisée en `pre.017`. Le V2 ne modifie pas à lui seul les garanties cryptographiques de VIEW/OWNER, keypair ou import/export.
|
||
|
||
V2 est désormais réservé au wire binaire KSP sans second facteur. Un futur V3 pourra introduire d’autres modèles d’autorisation, notamment password + facteur supplémentaire. `ksp-wallet-lib` restera propriétaire du format, des challenges et de la vérification, mais toute interaction réelle (OTP, enrollment/recovery, hardware/WebAuthn, validation distante) exigera une évolution de Wallet Desk ou du client concerné. Un seed TOTP stocké uniquement dans le même fichier que le wallet ne doit pas être présenté automatiquement comme un second facteur indépendant contre un attaquant possédant ce fichier.
|
||
|
||
## Pipelines
|
||
|
||
### Pas de pipeline monolithique
|
||
|
||
**Status :** Retenue
|
||
|
||
Ne pas créer de `ksp-pipeline-lib`. Les pipelines sont introduits séparément à la demande avec un périmètre concret.
|
||
|
||
## Trading
|
||
|
||
### Trading Intelligence avant application de trading
|
||
|
||
**Status :** Retenue
|
||
|
||
Construire d'abord statistiques, features, signaux, risque, backtests, détection de patterns/anomalies et intégrations ML telles que XGBoost. La couche/application de trading opérationnelle est construite ensuite.
|
||
|
||
## Program API — questions d'implémentation
|
||
|
||
### Payload décodé ouvert et persistable
|
||
|
||
**Status :** À explorer lors de la première implémentation
|
||
|
||
`ksp-program-api` ne doit utiliser ni enum central fermé de Program IDs ni `Any` comme seule représentation.
|
||
|
||
À décider à partir des besoins réels :
|
||
|
||
- value tree typé KSP ;
|
||
- schema/version + payload binaire ;
|
||
- structure sérialisable ouverte ;
|
||
- autre contrat garantissant identification, persistence et extensibilité.
|
||
|
||
### Conflits de registry
|
||
|
||
**Status :** À explorer
|
||
|
||
Définir la politique lorsqu'un registry reçoit plusieurs implémentations capables de traiter le même Program ID/surface/version :
|
||
|
||
- priorité explicite ;
|
||
- refus du conflit ;
|
||
- sélection par version/capability ;
|
||
- autre mécanisme documenté.
|
||
|
||
### Convention interne `dec` / `exec_prep`
|
||
|
||
**Status :** À explorer avec les premiers modules
|
||
|
||
Le principe `domain/program/capability` est retenu. Les noms exacts des dossiers courts (`dec`, `exec_prep`) seront validés avec la première vraie arborescence.
|
||
|
||
## Execution — idées d'implémentation
|
||
|
||
### Composition de policies
|
||
|
||
**Status :** À explorer
|
||
|
||
Évaluer, lorsque plusieurs policies réelles existent, s'il est utile de composer des policies spécialisées (réseau, montants, risque, lifecycle/deprecated, approval utilisateur, etc.) derrière un contrat commun.
|
||
|
||
Ne pas imposer cette composition dans `ksp-execution-policy-api` avant qu'un cas concret ne démontre les règles de priorité, union des requirements et traitement des conflits.
|
||
|
||
### Reprise après approbation externe
|
||
|
||
**Status :** À explorer avec la première UI concernée
|
||
|
||
Définir un mécanisme sûr de suspension/reprise d'une exécution lorsque la policy demande une approbation externe, sans faire dépendre la couche execution d'une UI ou de Tauri.
|
||
|
||
## Data / Store — questions d'implémentation
|
||
|
||
### Schémas SQL D1/D2/D3/D4
|
||
|
||
**Status :** À explorer à partir de `0.3.2`
|
||
|
||
`0.3.1` a stabilisé uniquement les contrats RAW backend-agnostic. Les noms de tables, colonnes, contraintes, index, migrations et repositories PostgreSQL appartiennent à `ksp-store-postgres-lib` à partir de `0.3.2`; les couches D2/D3/D4 n'ajoutent leur persistence qu'au moment où elles sont réellement ouvertes.
|
||
|
||
### Format générique D3
|
||
|
||
**Status :** À explorer
|
||
|
||
Le journal D3 doit accepter les outputs de materializers officiels ou externes sans nécessiter une nouvelle table par materializer.
|
||
|
||
À définir : identité/type/domain, payload, hash, provenance, version processor, état current/superseded/failed/replay et stratégie de sérialisation.
|
||
|
||
### Backlog et checkpoints
|
||
|
||
**Status :** Transférée vers une décision/règle
|
||
|
||
Les futurs processing outcomes versionnés constituent la preuve durable de traitement. Les queries/cursors Store décrivent la navigation dans les données et ne fixent ni batch-size, ni priorité, ni policy d'executor ; les jobs historiques conservent en plus leurs checkpoints de source.
|
||
|
||
### Jobs de replay
|
||
|
||
**Status :** Requalifiée par `0.2.0-pre.003`
|
||
|
||
L'ancienne liste figée `ksp-job-replay-core` / `ksp-job-replay-generic-materialization` / `ksp-job-replay-domain-projection` n'est plus une décision KSP. La frontière `RAW -> CORE` pourra introduire un replay Core lorsque CORE sera ouverte. À partir de DECODE, les jobs de replay doivent émerger avec les groupes/capacités verticaux réels et réutiliser la même logique que le processing live correspondant, sans imposer un materializer/projector global à tout Solana.
|
||
|
||
### Notification backend de référence
|
||
|
||
**Status :** À réauditer avec le premier publisher/consumer réel
|
||
|
||
Aucun mécanisme PostgreSQL de notification n'est figé par `0.3.1`. L'ordre durable reste `persist -> commit -> publish`, le publisher appartenant au worker/analyser/runtime de composition et non au Store lui-même. Un polling périodique peut compléter le wake-up. Si PostgreSQL `LISTEN/NOTIFY` devient utile plus tard, il reste une optimisation backend/runtime et jamais la source de vérité ni un event bus possédé par `ksp-store-lib`.
|
||
|
||
## Workers / jobs — questions d'implémentation restantes
|
||
|
||
### Claim/lease PostgreSQL
|
||
|
||
**Status :** À explorer avec la première implémentation Store/worker
|
||
|
||
Définir le schéma SQL, la durée/renouvellement de lease et la technique PostgreSQL exacte permettant plusieurs instances concurrentes sans bloquer définitivement un input après crash.
|
||
|
||
### Processing outcomes
|
||
|
||
**Status :** À explorer avec D2/D3/D4 réels
|
||
|
||
Fixer les noms/types exacts et distinguer Produced, NoOutput, NotApplicable, Unsupported et failure déterministe sans transformer des situations normales en erreurs.
|
||
|
||
### Contexte stateful des projections SPECIALIZED
|
||
|
||
**Status :** À explorer avec la première projection nécessitant un état existant
|
||
|
||
Le Store est interrogé par la couche de composition/pipeline/worker puis le contexte est injecté dans l'implémentation de projection/materialization spécialisée concernée. Définir comment cette capacité décrit les données de contexte nécessaires sans dépendre du backend, sans imposer un type global `DomainProjector`.
|
||
|
||
### Job pause/resume
|
||
|
||
**Status :** À explorer avec `ksp-job-api`
|
||
|
||
Checkpoint/restart est nécessaire pour backfill/replay. Déterminer si pause/resume doit être une capability générique ou rester spécifique aux jobs qui la supportent.
|
||
|
||
### Télémétrie opérationnelle
|
||
|
||
**Status :** À explorer
|
||
|
||
Backlog count, oldest pending age, processing rate et failure rate doivent être observables. Décider plus tard si health/status + logging suffisent ou si une API/metrics exporter dédiée devient nécessaire.
|
||
|
||
### Market Desk évolutive
|
||
|
||
**Status :** Transférée au roadmap
|
||
|
||
Introduire une première `ksp-app-market-desk` après les groupes DEX prioritaires Meteora/Raydium/Pump/Orca, puis l'enrichir après Jupiter/OKX.
|
||
|
||
Pistes futures au-delà de la V1/V2 :
|
||
|
||
- profondeur/market microstructure si les sources le permettent ;
|
||
- indicateurs dérivés ;
|
||
- alertes/anomalies ;
|
||
- overlays de risk ;
|
||
- outputs XGBoost/ML ;
|
||
- comparaison de providers/latence ;
|
||
- vues replay historiques.
|
||
|
||
Ces extensions restent séparées de l'application de trading opérationnel tant que leur responsabilité est l'observation/analyse.
|
||
|
||
## Applications et orchestration futures
|
||
|
||
### Application globale de contrôle/exploitation
|
||
|
||
**Status :** Future certaine, non planifiée actuellement
|
||
|
||
Une application globale de contrôle/exploitation est attendue à terme.
|
||
|
||
Elle ne doit pas être construite avant les applications spécialisées et demos nécessaires pour valider séparément config, wallet, Store, Program/execution, scenarios, workers/jobs et futurs domaines.
|
||
|
||
Son nom, son périmètre et sa release ne sont pas fixés.
|
||
|
||
### Orchestrateur global
|
||
|
||
**Status :** À réévaluer plus tard
|
||
|
||
Un orchestrateur pourra devenir utile pour coordonner plusieurs services, policies de restart/shutdown et déclenchements de jobs.
|
||
|
||
Aucune crate `ksp-orchestrator-lib` n'est retenue actuellement.
|
||
|
||
### IPC worker control
|
||
|
||
**Status :** À explorer au premier manager/service réel
|
||
|
||
Les workers sont des services autonomes. Une app manager devra donc disposer d'un transport de control.
|
||
|
||
Ne pas créer de `ksp-ipc-api` générique avant de connaître les contraintes réelles du premier manager : plateforme, framing, discovery, authentication locale et lifecycle.
|
||
|
||
## Applications desktop — idées de diagnostic
|
||
|
||
### Réflexion Rust -> console WebKit
|
||
|
||
**Status :** Reporté hors `0.1.4`, à réévaluer au premier besoin de diagnostic WebView
|
||
|
||
Le bridge Config Desk validé en `0.1.4` couvre `console.*`/helpers frontend -> commande Tauri -> `ksp-logging-lib` tout en conservant l’affichage local dans la console WebKit. Le retour général des événements Rust vers la console WebKit n’est pas nécessaire au contrat fonctionnel actuel.
|
||
|
||
Si cette capacité devient utile, l’intégration doit être conçue dans la pile possédée par `ksp-logging-lib` afin de conserver un subscriber global unique. Elle doit vérifier explicitement l’absence de double émission et de boucle avec le bridge frontend avant toute adoption d’un mécanisme de type `WebviewLayer`/console attachée.
|
||
|
||
## Séquencement des releases futures
|
||
|
||
### Numérotation fine après `0.1.x`
|
||
|
||
**Status :** Transférée au roadmap pour le début de `0.2.x`
|
||
|
||
`0.2.0-pre.002` avait fixé le premier séquencement concret. `0.2.1-pre.001-fix.001` le recalibre désormais sur `0.2.1 -> 0.2.13`, sous réserve du gate de dimensionnement de chaque `pre.001` et avec possibilité d'enchaîner plusieurs releases complètement clôturées dans une même session lorsque le sizing le permet.
|
||
|
||
Les séries après RAW/CORE ne sont volontairement pas numérotées programme par programme à ce stade : la règle est de redécouper chaque vertical slice selon sa taille réelle et de ne jamais ouvrir une release qui ne peut pas être clôturée dans sa session.
|