v0.2.1-pre.006

crates/ksp-config-lib/USAGE.md

@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-config-lib/USAGE.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Utilisation de ksp-config-lib
 
@@ -29,6 +29,7 @@ Les arguments compris par Config sont :
 --cfgpath=/path/to/config
 --schemapath=/path/to/schemas
 --filemap=cfg.std.logging=my-logging.json
+--filemap=cfg.std.transport=my-transport.json
 ```
 
 `cfgpath` et `schemapath` ne sont jamais lus depuis JSON, `.env` ou une variable KSP : cette règle évite un bootstrap récursif.
@@ -122,6 +123,23 @@ Un `logs_directory` relatif est ancré sur le current working directory du proce
 
 Les `files[].path` restent relatifs sous le root Logging, y compris après interpolation.
 
+### 4.1 Construire le Transport HTTP depuis Config
+
+Config possède également l'adapter du document `std.transport` vers le contrat runtime de `ksp-onchain-transport-lib` :
+
+```rust
+let transport = match engine.load_resolved_transport_config(std::option::Option::None, &environment) {
+    std::result::Result::Ok(value) => value,
+    std::result::Result::Err(error) => return std::result::Result::Err(error),
+};
+
+let transport_settings = transport.into_settings();
+```
+
+Les scalaires `*_ms` restent des valeurs Config et sont convertis en `std::time::Duration` par l'adapter. Les URLs peuvent provenir de `KSP_PUBLIC_*` ou de `KSP_SECRET_*`; dans ce dernier cas la valeur réelle reste disponible au runtime Transport, mais `ResolvedTransportConfig::effective().safe_value()` et les représentations `Debug` sont redacted.
+
+La dépendance reste unidirectionnelle : Config connaît le contrat Transport pour le construire ; Transport ne connaît ni Config, ni `.env`, ni les variables KSP.
+
 ## 5. Profils et composites
 
 Pour un document standard profilé :
@@ -213,6 +231,7 @@ Ce guide reste volontairement indépendant des numéros de release. Les contrats
 | Environnement          | `ConfigEnvironment`, `ConfigEnvironmentSource`, `ConfigEnvironmentValue`, `DEFAULT_DOTENV_PATH`, `DEFAULT_DOTENV_EXAMPLE_PATH`                         | §3, §7–8                 |
 | Sensibilité/provenance | `ConfigSensitivity`, `ConfigValueProvenance`, `ResolvedConfigText`, `ResolvedConfigJson`, `REDACTED_CONFIG_VALUE`                                      | §3                       |
 | Logging effectif       | `ResolvedLoggingConfig`                                                                                                                                | §4                       |
+| Transport effectif     | `ResolvedTransportConfig`                                                                                                                              | §4.1                     |
 | Management             | `ConfigManagement`, `ConfigManagedSource`, `ConfigDocumentChangeReport`, `ConfigEnvironmentReport`, `ConfigEnvironmentChangeReport`                    | §6–7                     |
 | Source Logging typée   | `LoggingConfigDocument`, `LoggingProfileConfig`, `LoggingConsoleConfig`, `LoggingFileConfig`, `LoggingOutputFilterConfig`, `LoggingTargetFilterConfig` | §6 et exemple ci-dessous |
 | Erreurs Config         | constantes `ERROR_CODE_*` réexportées par la crate                                                                                                     | exemple ci-dessous       |
@@ -324,4 +343,3 @@ if let std::result::Result::Err(error) = loaded {
 ```
 
 Le message/context d'erreur reste destiné au diagnostic ; l'identité machine-readable passe par `ErrorCode`.
-