v0.2.6-rel.001
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
|
||||
<!-- version: 77 -->
|
||||
<!-- version: 79 -->
|
||||
|
||||
# Séquence des releases fonctionnelles KSP
|
||||
|
||||
@@ -18,7 +18,7 @@ Principes :
|
||||
- une session de chat peut enchaîner plusieurs releases si chacune est entièrement clôturée avant l'ouverture de la suivante et si le sizing de la suivante reste raisonnablement positif ; cette possibilité ne fusionne ni les numéros, ni les deltas, ni les validations ;
|
||||
- les numéros futurs sont confirmés lorsque leur série approche et que les dépendances réelles sont connues.
|
||||
|
||||
# Première série fonctionnelle : `0.1.x`
|
||||
## Première série fonctionnelle : `0.1.x`
|
||||
|
||||
La série `0.1.x` construit les fondations N1 dans l'ordre de dépendances réel.
|
||||
|
||||
@@ -41,15 +41,15 @@ Séquence par défaut :
|
||||
|
||||
`0.1.4 — ksp-app-config-desk` établit le modèle de référence des futures applications Tauri KSP sans déplacer la logique Config dans l'application. Sa matrice finale a été validée avant `rel.001`, avec le build Tauri exécuté en dernière opération.
|
||||
|
||||
## `0.1.1` — Core foundation
|
||||
### `0.1.1` — Core foundation
|
||||
|
||||
### Mission
|
||||
#### Mission
|
||||
|
||||
Stabiliser `ksp-core-lib` comme fondation N1 minimale et durable.
|
||||
|
||||
Le Core possède uniquement les contrats réellement transversaux nécessaires aux couches supérieures.
|
||||
|
||||
### Surface stabilisée
|
||||
#### Surface stabilisée
|
||||
|
||||
`0.1.1` stabilise :
|
||||
|
||||
@@ -62,13 +62,13 @@ Le Core possède uniquement les contrats réellement transversaux nécessaires a
|
||||
- une taxonomie extensible séparant notamment `subfamily` et `program_version` ;
|
||||
- les réexports crate-root, rustdocs et tests publics correspondants.
|
||||
|
||||
### Dépendances
|
||||
#### Dépendances
|
||||
|
||||
Core ne dépend pas de `ksp-logging-lib`, Config, Wallet, Store, Transport, Program ou Materializer.
|
||||
|
||||
La seule dépendance externe directe de `ksp-core-lib` à la clôture est `solana-pubkey`, déclarée au workspace avec la génération `^4.3`, `default-features = false`, puis héritée par la crate avec `.workspace = true`. Aucune feature optionnelle supplémentaire n'est activée dans `0.1.1`.
|
||||
|
||||
### Hors scope
|
||||
#### Hors scope
|
||||
|
||||
- logging ;
|
||||
- configuration ;
|
||||
@@ -83,7 +83,7 @@ La seule dépendance externe directe de `ksp-core-lib` à la clôture est `solan
|
||||
- workers/jobs ;
|
||||
- scenarios.
|
||||
|
||||
### Lifecycle de la release
|
||||
#### Lifecycle de la release
|
||||
|
||||
Trajectoire réellement suivie :
|
||||
|
||||
@@ -99,13 +99,13 @@ pre.005 validation finale/docs/cleanup/prompt 0.1.2
|
||||
rel.001 publication stable validée de 0.1.1
|
||||
```
|
||||
|
||||
## `0.1.2` — Logging foundation
|
||||
### `0.1.2` — Logging foundation
|
||||
|
||||
### Mission
|
||||
#### Mission
|
||||
|
||||
Faire de `ksp-logging-lib` la façade KSP unique de logging/tracing pour les composants runtime.
|
||||
|
||||
### Surface stabilisée
|
||||
#### Surface stabilisée
|
||||
|
||||
`0.1.2` stabilise :
|
||||
|
||||
@@ -120,7 +120,7 @@ Faire de `ksp-logging-lib` la façade KSP unique de logging/tracing pour les com
|
||||
- tests de saturation, concurrence/reload, lifecycle spans et instrumentation Tokio réelle ;
|
||||
- audit d'ownership empêchant les autres crates workspace de dépendre directement de la stack `tracing*`.
|
||||
|
||||
### Dépendances runtime
|
||||
#### Dépendances runtime
|
||||
|
||||
```text
|
||||
ksp-logging-lib
|
||||
@@ -134,7 +134,7 @@ Tokio est uniquement une dev-dependency de `ksp-logging-lib` pour les tests asyn
|
||||
|
||||
`ksp-logging-lib` ne dépend pas de `ksp-config-lib`. Config pourra convertir ses documents résolus en `LoggingSettings` puis utiliser le lifecycle public de Logging.
|
||||
|
||||
### Lifecycle de la release
|
||||
#### Lifecycle de la release
|
||||
|
||||
Trajectoire réellement suivie :
|
||||
|
||||
@@ -154,9 +154,9 @@ pre.006-fix.001 correction documentaire du prompt Config
|
||||
rel.001 publication stable validée de 0.1.2
|
||||
```
|
||||
|
||||
## `0.1.3` — Configuration foundation
|
||||
### `0.1.3` — Configuration foundation
|
||||
|
||||
### Dépendances stabilisées
|
||||
#### Dépendances stabilisées
|
||||
|
||||
```text
|
||||
ksp-config-lib
|
||||
@@ -164,7 +164,7 @@ ksp-config-lib
|
||||
-> ksp-logging-lib
|
||||
```
|
||||
|
||||
### Mission
|
||||
#### Mission
|
||||
|
||||
Introduire la configuration générale KSP.
|
||||
|
||||
@@ -193,7 +193,7 @@ Périmètre retenu :
|
||||
- accès explicite aux secrets pour les surfaces de management autorisées ;
|
||||
- modèle Logging non régressif : console configurable et plusieurs sinks fichier/routings ; les capacités manquantes de `ksp-logging-lib 0.1.2` sont complétées dans Logging sans dépendance inverse vers Config.
|
||||
|
||||
### Décision de scission
|
||||
#### Décision de scission
|
||||
|
||||
Le `pre.001` ne scinde pas Config : `0.1.3` reste une release unique et `0.1.4` reste réservée à `ksp-app-config-desk`.
|
||||
|
||||
@@ -252,7 +252,7 @@ pre.015-fix.002 tracing Tauri + critères fonctionnels de clôture 0.1.
|
||||
rel.001 publication stable validée de 0.1.3
|
||||
```
|
||||
|
||||
## `0.1.4` — Config desktop par défaut
|
||||
### `0.1.4` — Config desktop par défaut
|
||||
|
||||
`0.1.4-pre.001` ouvre désormais cette release par l'audit et le plan détaillé :
|
||||
|
||||
@@ -293,7 +293,7 @@ La logique Config reste dans `ksp-config-lib` et le subscriber/runtime `tracing`
|
||||
|
||||
`0.1.4-rel.001` publie cette surface sous `0.1.4` stable après validation complète de `pre.019` et de son fix documentaire.
|
||||
|
||||
# Règle Git à partir de `0.1.x`
|
||||
## Règle Git à partir de `0.1.x`
|
||||
|
||||
À partir de la première release fonctionnelle, **chaque delta est commité**.
|
||||
|
||||
@@ -315,9 +315,9 @@ Seul le commit de release stable reçoit le tag :
|
||||
v0.1.1
|
||||
```
|
||||
|
||||
# Lifecycle standard d'une release fonctionnelle
|
||||
## Lifecycle standard d'une release fonctionnelle
|
||||
|
||||
## Première prerelease
|
||||
### Première prerelease
|
||||
|
||||
Par défaut :
|
||||
|
||||
@@ -332,13 +332,13 @@ Par défaut :
|
||||
|
||||
La première prerelease ne doit pas se transformer automatiquement en une grosse phase d'implémentation.
|
||||
|
||||
## Prereleases intermédiaires
|
||||
### Prereleases intermédiaires
|
||||
|
||||
Chaque prerelease porte un objectif borné et cohérent.
|
||||
|
||||
Une tranche de travail de planification/développement manifestement trop grosse est scindée. La cible de dimensionnement KSP est d'environ 15–20 minutes de travail effectif par prerelease ; ce budget est un garde-fou de granularité, pas une raison pour comprimer le périmètre.
|
||||
|
||||
## Dernière prerelease
|
||||
### Dernière prerelease
|
||||
|
||||
Par défaut :
|
||||
|
||||
@@ -350,7 +350,7 @@ Par défaut :
|
||||
- prompt de la release suivante ;
|
||||
- vérification de cohérence des versions.
|
||||
|
||||
# Série `0.2.x` — accès Solana, Wallet et contrats initiaux
|
||||
## Série `0.2.x` — accès Solana, Wallet et contrats initiaux
|
||||
|
||||
`0.2.0` est publiée stable par `0.2.0-rel.001`. `pre.002` a fixé le début de la séquence fonctionnelle suivante et `pre.003` en a réalisé l'audit final de cohérence :
|
||||
|
||||
@@ -372,7 +372,7 @@ Par défaut :
|
||||
|
||||
`0.2.1-pre.001` a appliqué le gate de sizing et refusé le scope HTTP monolithique initial : l'inventaire du 2026-08-17 contient 52 méthodes courantes et 14 méthodes Deprecated historiques. Ce premier delta avait réparti la couverture typée sur `0.2.1`–`0.2.6`. `0.2.1-pre.001-fix.001` recalibre ensuite les 48 méthodes restantes sur trois releases complémentaires `0.2.2`–`0.2.4`, soit trois sessions nominales au maximum si chaque release utilise sa session complète. Si une release se clôt plus vite que prévu, la même session peut enchaîner la suivante après clôture complète de la précédente et nouveau gate de sizing positif. Un Wallet Desk utile doit pouvoir lire le solde du wallet : `getBalance` fait donc partie des quatre canaris de la foundation `0.2.1`, avant Wallet. Les transports live arrivent ensuite ; Interface/Program restent préparés avant les couches de données décodées.
|
||||
|
||||
## `0.2.1` — HTTP transport foundation réduite
|
||||
### `0.2.1` — HTTP transport foundation réduite
|
||||
|
||||
Mission : créer `ksp-onchain-transport-lib` avec la foundation HTTP JSON-RPC indépendante de Config/Store/Program, le registry documentaire exhaustif, la résilience/pool et quatre méthodes typed canari.
|
||||
|
||||
@@ -380,7 +380,7 @@ Inclure : settings publics ; endpoint/provider/cluster ; pool logique ; rôles/c
|
||||
|
||||
Le plan détaillé clôturé est `docs/plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md`. `0.2.1-rel.001` publie la foundation après validation des canaries de complétude, du smoke Devnet opt-in Config -> Transport, des README/USAGE et des graphes Cargo. Le smoke cross-crates hébergé dans Config est transitoire et devra migrer vers une future surface d’intégration/orchestration ; aucun futur smoke `Config + autre crate` ne doit prendre Config comme destination générale. Un appel raw/générique ne compte pas comme couverture typée des méthodes reportées.
|
||||
|
||||
## `0.2.2` à `0.2.4` — complétude HTTP Solana
|
||||
### `0.2.2` à `0.2.4` — complétude HTTP Solana
|
||||
|
||||
- `0.2.2` : 5 Accounts restants + 5 Tokens + 12 Cluster restants = 22 méthodes ;
|
||||
- `0.2.3` : 11 Transactions, y compris write/submission technique et no-resend ambigu ;
|
||||
@@ -396,7 +396,7 @@ Chaque `pre.001` réaudite la documentation officielle actuelle. Les méthodes D
|
||||
|
||||
`0.2.4-pre.001` réaudite le même jour l'inventaire HTTP officiel et la baseline runtime actuelle : les 15 méthodes réservées restent exactement 10 Blocks + 5 Economics, la navigation Deprecated reste à 14 historiques et Agave stable `v4.2.1` confirme les overloads/limites/extensions sensibles (`getBlock` legacy, `getBlocks`, plafond 500_000, performance samples 720, `commissionBps`). Le gate de sizing est positif sans split de release. `pre.002`–`pre.008` livrent ensuite les DTOs/wires et les 15 wrappers ; `pre.008-fix.001` corrige uniquement la conformité Clippy. `pre.009` réaudite l'index officiel et les SIMDs HTTP sensibles, confirme l'égalité exacte des ensembles 52 current + 14 Deprecated avec le registre, ajoute les canaries de wrapper/compliance globales, étend le smoke Transport aux familles Blocks/Economics et synchronise la documentation. `pre.009-fix.001` finalise ensuite le prompt Wallet sans changement Cargo. `0.2.4-rel.001` publie la surface stable après validation du workspace et des deux smokes Devnet. Le plan détaillé clôturé est `docs/plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md`.
|
||||
|
||||
## `0.2.5` — Wallet foundation
|
||||
### `0.2.5` — Wallet foundation
|
||||
|
||||
Mission : créer `ksp-wallet-lib` et le format natif interopérable `.kspwallet`, indépendants de Config/Transport/Tauri/ExecutionPolicy.
|
||||
|
||||
@@ -420,11 +420,11 @@ La release fournit `docs/formats/KSPWALLET_V1.md` comme spécification séparée
|
||||
|
||||
`0.2.5-pre.007` complète l'administration native capability-bound : OWNER signe des messages Solana sans getter secret, modifie alias/notes, change son password ou celui de VIEW et peut disable/recreate VIEW avec rekey metadata fort ; VIEW ne peut que tourner son propre credential en rewrappant le même `K_metadata`. Les mutations sont staged puis remplacent le fichier uniquement si la destination courante correspond encore à l'enveloppe authentifiée attendue ; un handle stale ou une mauvaise cible reçoit `wallet.state_conflict`. Ce garde-fou ne prétend pas fournir un CAS filesystem portable ni un anti-rollback externe. La keypair reste encapsulée dans Wallet et aucune nouvelle dépendance tierce n'est ajoutée. `pre.008` ajoute ensuite les adapters `solana_cli_json` et `solana_keypair_base58`, l’inspection sûre limitée à Pubkey+format, l’import no-clobber vers un nouveau `.kspwallet` et l’export OWNER en mémoire/fichier. La source d’import reste inchangée, VIEW n’exporte jamais, aucun `bs58` direct n’est ajouté puisque `solana-keypair 3.1.2` possède déjà le codec Base58 complet. `pre.009` ferme ensuite le gate adversarial/security/interoperability/compliance : canaris de tampering et non-oracle, reproduction indépendante des vecteurs, audit des frontières et graphes Cargo. `pre.010` finalise README/USAGE, la spec, les graphes, la matrice de clôture et le prompt `0.2.6`. Les fixes `pre.010-fix.001`–`fix.003` mettent le Dalek direct à `3.0.0`, normalisent le Rust workspace, ajoutent l'audit structurel Python et réconcilient celui-ci avec rustfmt. Le checkpoint final est vert ; `0.2.5-rel.001` publie cette surface sans nouvelle capacité runtime.
|
||||
|
||||
## `0.2.6` — Wallet Desk
|
||||
### `0.2.6` — Wallet Desk
|
||||
|
||||
Mission : créer `ksp-app-wallet-desk` comme application Tauri mince de composition `Config + Wallet + Transport HTTP`, sans déplacer la cryptographie Wallet, la résolution Config ni le transport Solana dans le frontend. Le plan actif et le découpage fin restent dans `docs/plans/013-V0_2_6_WALLET_DESK_PLAN.md`.
|
||||
Mission : créer `ksp-app-wallet-desk` comme application Tauri mince de composition `Config + Wallet + Transport HTTP`, sans déplacer la cryptographie Wallet, la résolution Config ni le transport Solana dans le frontend. Le plan détaillé clôturé est `docs/plans/013-V0_2_6_WALLET_DESK_PLAN.md`.
|
||||
|
||||
État fonctionnel déjà acquis :
|
||||
Trajectoire exécutée :
|
||||
|
||||
- `pre.001`–`pre.004` : sizing, shell desktop, `std.wallet`, composite Wallet Desk, répertoires Config et inventory locked `.kspwallet` root-scoped ;
|
||||
- `pre.005`–`pre.006` : création native, `WalletSession`, unlock VIEW/OWNER manuel et via candidats `KSP_SECRET_WALLET_PASS_*` résolus exclusivement par Config ;
|
||||
@@ -433,7 +433,7 @@ Mission : créer `ksp-app-wallet-desk` comme application Tauri mince de composit
|
||||
|
||||
Les correctifs de ces tranches restent tracés dans `deltas/0.2.6/` et ne sont pas dupliqués ici.
|
||||
|
||||
Trajectoire restante :
|
||||
Clôture exécutée :
|
||||
|
||||
```text
|
||||
pre.009 administration OWNER alias/notes + recovery wallet.state_conflict
|
||||
@@ -449,21 +449,21 @@ pre.018 documentation finale, validations, prompt 0.2.7 et cargo tauri build en
|
||||
rel.001 publication stable 0.2.6
|
||||
```
|
||||
|
||||
`pre.017` est désormais matérialisé et validé : la migration V1 -> V2 est explicite, OWNER-authentifiée et séparée de toute ouverture normale, avec copie no-clobber et remplacement in-place stale-protected. `pre.018` matérialise la candidate finale : README/USAGE Wallet Desk, documentation/compliance, runtime packagé commun à Config Desk/Wallet Desk avec Config resources + racine user-writable, et prompt `0.2.7`. Le build Wallet Desk et `rel.001` restent les gates finaux.
|
||||
`pre.017` a matérialisé et validé la migration V1 -> V2 explicite, OWNER-authentifiée et séparée de toute ouverture normale, avec copie no-clobber et remplacement in-place stale-protected. `pre.018` a ensuite fermé la candidate : README/USAGE Wallet Desk, documentation/compliance, runtime packagé commun à Config Desk/Wallet Desk avec resources Config + racine user-writable et prompt `0.2.7`. `pre.018-fix.001` a corrigé le canari d’ownership Config et aligné les signaux Cargo/npm/Tauri ; le gate complet puis le build final Wallet Desk ont été validés, avec production des bundles Linux `.deb`, `.rpm` et `.AppImage`. `pre.018-fix.002`, documentaire uniquement, a renforcé le prompt autonome `0.2.7` sans invalider la preuve technique. `0.2.6-rel.001` publie désormais cette surface stable sans nouvelle capacité runtime.
|
||||
|
||||
La tranche `pre.014` est réservée aux défauts visuels/templating observés en usage réel, notamment les scrollbars occasionnelles du splashscreen ; son contenu précis sera borné à partir du retour opérateur avant implémentation. `ROADMAP.md` reste synthétique et `CHANGELOG.md` n'est synchronisé qu'à la phase documentaire finale.
|
||||
La tranche historique `pre.014` a traité les défauts visuels/templating observés en usage réel, notamment le splashscreen et le layout desktop. Les décisions finales CWD/resources ont été fermées en `pre.018`. `ROADMAP.md` reste synthétique et `CHANGELOG.md` ne contient que les releases stables.
|
||||
|
||||
## `0.2.7` — WebSocket Solana standard
|
||||
### `0.2.7` — WebSocket Solana standard
|
||||
|
||||
Mission : couvrir la surface WebSocket standard officielle ciblée.
|
||||
|
||||
Une URL peut avoir plusieurs sessions physiques ; une session peut avoir plusieurs subscriptions. Un pool automatique de sessions est reporté jusqu'à besoin concret.
|
||||
|
||||
## `0.2.8` — Helius LaserStream WebSocket
|
||||
### `0.2.8` — Helius LaserStream WebSocket
|
||||
|
||||
Mission : étendre le moteur WebSocket standard avec les opérations/filtres/capabilities Helius ciblés sans copier le client.
|
||||
|
||||
## `0.2.9` — Yellowstone gRPC standard
|
||||
### `0.2.9` — Yellowstone gRPC standard
|
||||
|
||||
Mission : introduire un backend Yellowstone standard/provider-neutral.
|
||||
|
||||
@@ -471,7 +471,7 @@ Le `pre.001` est un gate de sizing : inventorier toute la surface normative cibl
|
||||
|
||||
Les profiles/adapters Helius/Triton/ERPC/Chainstack/Shyft sont reportés après les priorités fondatrices.
|
||||
|
||||
## `0.2.10` / `0.2.11` — Off-chain price + app
|
||||
### `0.2.10` / `0.2.11` — Off-chain price + app
|
||||
|
||||
`0.2.10` introduit `ksp-offchain-transport-lib` avec au minimum SOL/USD et SOL/EUR via une abstraction indépendante du premier provider.
|
||||
|
||||
@@ -479,19 +479,19 @@ Les profiles/adapters Helius/Triton/ERPC/Chainstack/Shyft sont reportés après
|
||||
|
||||
Metadata HTTP/IPFS/Arweave viendra au premier besoin Metadata réel.
|
||||
|
||||
## `0.2.12` — Interface foundation
|
||||
### `0.2.12` — Interface foundation
|
||||
|
||||
`ksp-interface-lib` devient la façade wire officielle et expose une API publique wire utilisable par les implementations officielles et externes.
|
||||
|
||||
Aucune `ksp-interface-api` séparée n'est retenue pour l'instant.
|
||||
|
||||
## `0.2.13` — Program API foundation
|
||||
### `0.2.13` — Program API foundation
|
||||
|
||||
Introduire `ksp-program-api`, sans suffixe `-lib`, comme contrat d'extension Program.
|
||||
|
||||
`ksp-program-lib` et les vertical slices réels arrivent plus tard.
|
||||
|
||||
# Architecture durable : RAW -> CORE -> DECODE -> SPECIALIZED
|
||||
## Architecture durable : RAW -> CORE -> DECODE -> SPECIALIZED
|
||||
|
||||
La chaîne de données est :
|
||||
|
||||
@@ -506,7 +506,7 @@ RAW et CORE ne nécessitent aucun decoder Program.
|
||||
|
||||
`RAW -> CORE` est une normalisation générique Solana ; le premier decoder intervient à `CORE -> DECODE`.
|
||||
|
||||
# Série `0.3.x` — RAW / acquisition persistée
|
||||
## Série `0.3.x` — RAW / acquisition persistée
|
||||
|
||||
Début décidé :
|
||||
|
||||
@@ -521,7 +521,7 @@ La suite de la série termine la couche RAW avec worker/service live et outils d
|
||||
|
||||
`0.3.1` ne doit pas créer par anticipation les modèles/tables DECODE/SPECIALIZED.
|
||||
|
||||
# Série CORE suivante
|
||||
## Série CORE suivante
|
||||
|
||||
Objectif : rendre CORE exploitable sans aucun decoder Program :
|
||||
|
||||
@@ -534,7 +534,7 @@ RAW persisted
|
||||
-> CORE inspection/control app
|
||||
```
|
||||
|
||||
# Séries DECODE/SPECIALIZED/EXECUTION suivantes
|
||||
## Séries DECODE/SPECIALIZED/EXECUTION suivantes
|
||||
|
||||
À partir du décodage, KSP progresse par vertical slices complets et non par grandes couches de crates isolées :
|
||||
|
||||
@@ -571,7 +571,7 @@ Un programme satellite nécessaire reste dans son groupe protocolaire : Pump fee
|
||||
|
||||
SPM est reporté au décodage généraliste ultérieur.
|
||||
|
||||
# Market Desk
|
||||
## Market Desk
|
||||
|
||||
Après les DEX prioritaires, introduire une petite `ksp-app-market-desk` consommant les projections KSP pour afficher tokens, pools, liquidité, trades, prix, volumes et OHLC.
|
||||
|
||||
@@ -579,17 +579,17 @@ Après Jupiter/OKX, enrichir la même app avec routes, legs, DEX impliqués, fee
|
||||
|
||||
L'app ne réimplémente pas les SDK/protocoles DEX ; elle consomme les faits SPECIALIZED normalisés.
|
||||
|
||||
# Discipline de sizing
|
||||
## Discipline de sizing
|
||||
|
||||
Chaque prerelease vise environ 15–20 minutes de travail effectif.
|
||||
|
||||
Chaque release concrète doit pouvoir être ouverte et clôturée dans une seule session de chat. Si `pre.001` montre que ce n'est pas réaliste, scinder la release avant implémentation fonctionnelle lourde.
|
||||
|
||||
# Progression de la série `0.1.x`
|
||||
## Progression de la série `0.1.x`
|
||||
|
||||
Les releases `0.1.1` à `0.1.4` sont stables et leurs plans/prompts restent historiques.
|
||||
|
||||
# Clôture stable de `0.2.0` et ouverture de `0.2.1`
|
||||
## Clôture stable de `0.2.0` et ouverture de `0.2.1`
|
||||
|
||||
`0.2.0` a été ouverte par :
|
||||
|
||||
|
||||
Reference in New Issue
Block a user