Mountain/Vine/Server/Notification/mod.rs
1//! # Vine Cocoon → Mountain Notification Atoms
2//!
3//! One handler per file, file name = the exported function name
4//! (reverse-hierarchical path: `Vine::Server::Notification::<Atom>::<Atom>`).
5//! Each atom encapsulates exactly one wire-method's side effects so the
6//! main `send_cocoon_notification` dispatcher in
7//! `MountainVinegRPCService.rs` stays a thin match that routes into
8//! these files.
9//!
10//! ## Naming
11//!
12//! - Wire string `outputChannel.create` → atom file `OutputChannelCreate.rs`
13//! with `pub async fn OutputChannelCreate(...)`.
14//! - Wire string `unregister_scm_provider` → atom file
15//! `UnregisterScmProvider.rs`.
16//! - Wire string `progress.update` → atom file `ProgressUpdate.rs`.
17//!
18//! Snake_case / dotted wire strings collapse to PascalCase file names.
19//! The function name mirrors the file name verbatim so a grep for
20//! `fn <Name>` lands in exactly one place.
21//!
22//! ## Signature contract
23//!
24//! Every atom takes the same two parameters:
25//!
26//! ```ignore
27//! pub async fn <Atom>(
28//! Service: &MountainVinegRPCService,
29//! Parameter: &serde_json::Value,
30//! );
31//! ```
32//!
33//! - `Service` gives access to `ApplicationHandle` (for Tauri `emit` / webview
34//! lookup) and `RunTime` (for `Environment`, `ApplicationState`, provider
35//! registry, scheduler).
36//! - `Parameter` is the raw JSON payload Cocoon sent; each atom extracts the
37//! fields it needs and validates locally.
38//! - Return `()` - atoms that need to fail just log via `dev_log!` on the
39//! `notif-drop` / `grpc` tag; the caller always returns `Empty` to Cocoon
40//! because notifications are fire-and-forget.
41
42#![allow(non_snake_case)]
43
44// --- Batch 8: provider-unregister cleanup ---
45pub mod UnregisterAuthenticationProvider;
46pub mod UnregisterDebugAdapter;
47pub mod UnregisterFileSystemProvider;
48pub mod UnregisterScmProvider;
49pub mod UnregisterTaskProvider;
50pub mod UnregisterUriHandler;
51pub mod UpdateScmGroup;
52
53// --- Batch 11: progress lifecycle name alignment ---
54pub mod ProgressComplete;
55pub mod ProgressUpdate;
56
57// --- Batch 10: status-bar text + disposal ---
58pub mod DisposeStatusBarItem;
59pub mod SetStatusBarText;
60
61// --- Batch 9: output channel lifecycle (`output.*` + `outputChannel.*`) ---
62pub mod OutputAppend;
63pub mod OutputAppendLine;
64pub mod OutputChannelAppend;
65pub mod OutputChannelClear;
66pub mod OutputChannelCreate;
67pub mod OutputChannelDispose;
68pub mod OutputChannelHide;
69pub mod OutputChannelShow;
70pub mod OutputClear;
71pub mod OutputCreate;
72pub mod OutputDispose;
73pub mod OutputReplace;
74pub mod OutputShow;
75
76// --- Batch 13: webview reverse messaging ---
77pub mod WebviewDispose;
78pub mod WebviewPostMessage;
79
80// --- Batch 14: grammar, security, external ---
81pub mod OpenExternal;
82pub mod SecurityIncident;
83pub mod SetLanguageConfiguration;
84
85// --- Batch 15: inline arms atomised from `MountainVinegRPCService` dispatcher.
86// These were previously ~300 lines of inline match-arm bodies; now each
87// wire method is a one-fn file that the dispatcher delegates into.
88pub mod ExtensionActivated;
89pub mod ExtensionDeactivated;
90pub mod ExtensionHostMessage;
91pub mod LanguagesSetDocumentLanguage;
92pub mod ProgressEnd;
93pub mod ProgressReport;
94pub mod ProgressStart;
95pub mod WebviewReady;
96pub mod WindowShowTextDocument;
97pub mod WorkspaceApplyEdit;
98
99// --- Batch 16: the remaining inline arms - command register/unregister,
100// status-bar lifecycle / message, window show-message / create-terminal,
101// decoration / debug / webview / terminal fan-outs. A handful are
102// "group" atoms (`TerminalLifecycle` covers 4 wire methods that share a
103// relay + provider-drive pattern) - kept together where the handling
104// is truly identical and splitting would duplicate 5-line files.
105pub mod DebugLifecycle;
106pub mod DecorationTypeLifecycle;
107pub mod RegisterCommand;
108pub mod StatusBarLifecycle;
109pub mod StatusBarMessage;
110pub mod TerminalLifecycle;
111pub mod UnregisterCommand;
112pub mod WebviewLifecycle;
113pub mod WindowCreateTerminal;
114pub mod WindowShowMessage;
115
116// --- Batch 17 (post-§14): SCM register pair pulled out of the
117// language-providers OR-block in `MountainVinegRPCService.rs`. The
118// catch-all fallthrough was registering SCM providers in the
119// language-feature provider registry, which the SCM viewlet never
120// reads. These atoms route through `SourceControlManagementProvider`
121// + emit the `sky://scm/*` events the renderer actually subscribes to.
122pub mod RegisterScmProvider;
123pub mod RegisterScmResourceGroup;