@usefragment/core 0.0.0

package/dist/index.d.ts

@@ -0,0 +1,3075 @@
+// Generated by dts-bundle-generator v9.5.1
+
+import { Extension } from '@codemirror/state';
+
+/**
+ * La classe mère des plugins (§11.3) — et la PLUS SIMPLE du projet. C'est le but.
+ *
+ * Chaque registerX() fait EXACTEMENT deux choses, jamais trois :
+ *
+ *     const retrait = this.app.<registre>.register(…)   // 1. j'écris dans la table
+ *     this.register(retrait)                            // 2. je programme mon retrait
+ *
+ * registry.ts ignore l'existence de component.ts, et inversement. Cette classe
+ * est le SEUL endroit où ils se rencontrent — le mariage, répété autant de fois
+ * qu'il y a de points d'extension, sans aucune logique propre. C'est ce qui
+ * rend « le coût marginal d'un point d'extension quasi nul » (§4) : chaque
+ * nouveau registerX() hérite gratuitement de la sémantique de démontage.
+ *
+ * La désactivation d'un plugin, c'est unload() : le rejeu de la pile en sens
+ * inverse. L'auteur n'écrit jamais de onunload() — il n'a jamais eu la
+ * responsabilité de nettoyer, donc il ne peut pas l'oublier.
+ *
+ * Noter le paramètre `owner` passé aux registres : app.registries devient
+ * auditable — chaque entrée dit quel plugin l'a posée.
+ */
+declare abstract class Plugin$1 extends Component {
+	app: App;
+	manifest: PluginManifest;
+	constructor(app: App, manifest: PluginManifest);
+	/** §8.3 — un nouveau type de vue. */
+	registerView(type: string, creator: ViewCreator): void;
+	/** §8.3 — extension de fichier → type de vue. Ouvre photo.png dans ta vue. */
+	registerExtensions(extensions: string[], viewType: string): void;
+	/** §11.5 — l'id est préfixé par celui du plugin : deux plugins peuvent avoir 'open'. */
+	addCommand(command: Command): Command;
+	/** Retrait explicite. Prend l'id NON préfixé — le préfixe est ajouté ici. */
+	removeCommand(id: string): void;
+	/** §9.2 — une extension CM6 injectée dans les éditeurs (via livePreviewExtensions). */
+	registerEditorExtension(extension: Extension): void;
+	/** §10.2 — transformation du HTML rendu (le mode lecture, quand il existera). */
+	registerMarkdownPostProcessor(processor: MarkdownPostProcessor, priority?: number): void;
+	/** §10.2 — un bloc ```lang devient une zone d'UI arbitraire. */
+	registerMarkdownCodeBlockProcessor(lang: string, processor: CodeBlockProcessor): void;
+	/** §12.6 — une icône, ajoutée OU écrasant une Lucide du même nom. */
+	addIcon(name: string, svg: string): void;
+	/**
+	 * §11.3 — une icône dans le ribbon. Renvoie le bouton, comme Obsidian :
+	 * les plugins s'en servent pour le styler ou le cacher. C'est possible
+	 * parce que trigger('changed') est SYNCHRONE : pendant le register()
+	 * ci-dessous, WorkspaceRibbon a déjà reconstruit et posé buttonEl.
+	 */
+	addRibbonIcon(icon: string, title: string, callback: (evt: MouseEvent) => unknown): HTMLElement;
+	/**
+	 * View layers — contribue un layer au catalogue, retiré à unload
+	 * (plan-view-layers.md). Même mariage que registerView : j'écris dans la
+	 * table, je programme mon retrait.
+	 */
+	registerLayer(spec: LayerSpec): void;
+	/**
+	 * §15 bis — une sous-commande du CLI (API 1.12 d'Obsidian).
+	 *
+	 * Préfixée par l'id du plugin, comme une commande : `templater` qui
+	 * enregistre `create-from-template` répond à
+	 * `fragment templater:create-from-template template="x"`.
+	 *
+	 * Le handler REND sa sortie ; il n'a pas de stdout. Lever une `CliError`
+	 * choisit le code de sortie ; lever autre chose donne 1 avec la pile.
+	 */
+	registerCliHandler(command: string, description: string, flags: CliFlags, handler: CliHandler): void;
+	private get dataPath();
+	loadData(): Promise<unknown | null>;
+	saveData(data: unknown): Promise<void>;
+}
+declare abstract class WorkspaceItem extends Events {
+	app: App;
+	workspace: Workspace;
+	abstract parent: WorkspaceParent | null;
+	containerEl: HTMLElement;
+	constructor(workspace: Workspace, className: string);
+	getRoot(): WorkspaceItem;
+	/**
+	 * §8.2 — chaque nœud sait se réduire à du JSON. C'est le Composite qui fait
+	 * son travail : le Workspace n'a aucune connaissance des formes de nœud, il
+	 * demande à ses trois racines et récupère l'arbre entier.
+	 */
+	abstract serialize(): LayoutNode;
+}
+declare abstract class WorkspaceParent extends WorkspaceItem {
+	children: WorkspaceItem[];
+	protected get childrenEl(): HTMLElement;
+	addChild(child: WorkspaceItem, index?: number): void;
+	removeChild(child: WorkspaceItem): void;
+}
+declare class CommandManager extends Events {
+	name: string;
+	label: string;
+	/** Le stockage, COMPOSÉ : toute la mécanique clef→valeur vit ici. */
+	private table;
+	private app;
+	constructor(app: App);
+	/**
+	 * Enregistre une commande et rend sa fonction de retrait (§3.2).
+	 *
+	 * ★ On NE MUTE PAS l'objet reçu (A26) : le désucrage écrit `checkCallback`
+	 *   sur NOTRE copie (`entry`), qui devient l'entrée du registre. L'appelant
+	 *   garde son objet intact ; pour tenir un handle vivant sur la commande
+	 *   réellement exécutée, il lit l'entrée via findCommand (Plugin.addCommand).
+	 *
+	 * @param command Son `id` doit déjà être préfixé (Plugin.addCommand s'en charge).
+	 * @param owner   L'id du plugin propriétaire, pour l'audit.
+	 * @returns La fonction de retrait, à confier à `Component.register`.
+	 */
+	addCommand(command: Command, owner?: string): () => void;
+	/**
+	 * Retrait explicite par id (parité d'API avec Obsidian).
+	 *
+	 * Préférer la fermeture rendue par `addCommand` : elle porte la garde
+	 * d'identité, celle-ci non — un retrait explicite est un ordre.
+	 */
+	removeCommand(id: string): void;
+	/** Lecture brute, sans aucun filtrage de disponibilité. */
+	findCommand(id: string): Command | undefined;
+	/**
+	 * Les commandes DISPONIBLES maintenant — le seul endroit qui passe
+	 * `checking = true`.
+	 *
+	 * ★ Une commande dont le `checkCallback` LÈVE est masquée, pas propagée :
+	 *   un plugin tiers ne doit pas pouvoir vider la palette de l'utilisateur.
+	 */
+	listCommands(): Command[];
+	/**
+	 * Exécution par id. Rend `true` si la commande a tourné ; `false` si l'id est
+	 * inconnu, si la commande était indisponible, ou si elle a levé (A30).
+	 */
+	executeCommandById(id: string, evt?: Event | null): boolean;
+	/**
+	 * Exécution directe. Rend « la commande a-t-elle tourné ? » (voir l'en-tête).
+	 *
+	 * ★ Pose `app.lastEvent` AVANT d'appeler : une commande peut ainsi lire les
+	 *   modificateurs de la frappe ou du clic qui l'a déclenchée (Keymap.isModEvent).
+	 */
+	executeCommand(command: Command, evt?: Event | null): boolean;
+	get size(): number;
+	entries(): Array<{
+		key: string;
+		value: Command;
+		owner: string;
+	}>;
+}
+declare class DragManager extends Events {
+	app: App;
+	source: DragData | null;
+	private ghostEl;
+	private captureEl;
+	private pointerId;
+	private onMove;
+	private onUp;
+	private onCancel;
+	constructor(app: App);
+	startDrag(event: PointerEvent, captureEl: HTMLElement, data: DragData, label: string): void;
+	private moveGhost;
+	endDrag(): void;
+}
+declare class HotkeyManager {
+	/** id de commande → raccourcis par défaut. Jamais persistés. */
+	defaultKeys: Record<string, Hotkey[]>;
+	/** id de commande → raccourcis de l'utilisateur. C'est le fichier. */
+	private custom;
+	private baked;
+	private bakedHotkeys;
+	private bakedIds;
+	private app;
+	private rechargerBientot;
+	constructor(app: App);
+	private get chemin();
+	load(): Promise<void>;
+	save(): Promise<void>;
+	getDefaultHotkeys(id: string): Hotkey[] | undefined;
+	addDefaultHotkeys(id: string, hotkeys: Hotkey[]): void;
+	removeDefaultHotkeys(id: string): void;
+	/** Les personnalisations d'une commande, ou `undefined` si elle n'en a pas. */
+	getHotkeys(id: string): Hotkey[] | undefined;
+	/** Une COPIE : la table interne n'est modifiable que par set/remove. */
+	getCustomKeys(): Record<string, Hotkey[]>;
+	setHotkeys(id: string, hotkeys: Hotkey[]): void;
+	removeHotkeys(id: string): void;
+	/** Ce qu'il faut AFFICHER pour une commande : la personnalisation, sinon le défaut. */
+	hotkeysForCommand(id: string): Hotkey[];
+	/** Force la recompilation au prochain dispatch. Public pour les tests. */
+	invalidate(): void;
+	private bake;
+	/**
+	 * Frappe → commande. Rend `false` pour consommer, `undefined` pour laisser passer.
+	 *
+	 * ★ NE CONSULTE PAS LA DISPONIBILITÉ, et c'est délibéré (cf. l'en-tête de
+	 *   CommandManager). Une commande d'éditeur déclenchée sans éditeur actif
+	 *   ne fait rien MAIS AVALE QUAND MÊME LA FRAPPE — parce qu'`executeCommand`
+	 *   rend `true` dès que rien n'a levé.
+	 *
+	 *   C'est le comportement d'Obsidian, et la source du fameux « mon raccourci
+	 *   ne fait rien, et en plus il bloque le comportement par défaut ». On le
+	 *   copie sciemment : le corriger voudrait dire appeler `checkCallback(true)`
+	 *   sur chaque liaison à chaque frappe, dans le chemin le plus chaud de l'app.
+	 */
+	private onTrigger;
+}
+declare class OrderedRegistry<T> extends Events {
+	name: string;
+	label: string;
+	items: Array<{
+		value: T;
+		priority: number;
+		owner: string;
+	}>;
+	constructor(name: string, label?: string);
+	register(value: T, { priority, owner }?: {
+		priority?: number;
+		owner?: string;
+	}): (() => void);
+	values(): T[];
+	entries(): Array<{
+		key: string;
+		value: T;
+		owner: string;
+	}>;
+	get size(): number;
+}
+declare class Plugins {
+	app: App;
+	/** Les instances chargées, par id. */
+	plugins: Map<string, Plugin$1>;
+	/** Les manifestes découverts (chargés ou non). */
+	manifests: Map<string, PluginManifest>;
+	/** Les classes internes enregistrées par seedCore, en attente de load. */
+	private internal;
+	constructor(app: App);
+	get pluginsDir(): string;
+	/** seedCore passe par ici — AUCUN privilège : la classe sera instanciée et
+	 *  chargée exactement comme un plugin communautaire. */
+	registerInternalPlugin(manifest: PluginManifest, ctor: PluginConstructor): void;
+	/**
+	 * §16.1 étape 5 — après le Vault, avant que l'UI ne dépende des vues.
+	 * Internes d'abord (markdown, explorateur), puis découverte du disque.
+	 */
+	initialize(): Promise<void>;
+	private discoverCommunityPlugins;
+	/**
+	 * §11.2 reconstitué : lire main.js via l'adapter, l'évaluer comme module
+	 * CommonJS, servir les modules hôtes par le shim, instancier, charger.
+	 */
+	private loadCommunityPlugin;
+	private instantiate;
+	/**
+	 * §16.4 — la désactivation est L'EXACT MIROIR : unload() rejoue tous les
+	 * register* en sens inverse, les registres se vident (garde d'identité
+	 * comprise), les vues ouvertes du plugin dégradent en placeholder — et se
+	 * rematérialiseront à la réactivation, via viewRegistry.on('changed').
+	 */
+	disablePlugin(id: string): void;
+	enablePlugin(id: string): Promise<void>;
+}
+declare class Registry<T> extends Events {
+	map: Map<string, {
+		value: T;
+		owner: string;
+	}>;
+	name: string;
+	label: string;
+	constructor(name: string, label?: string);
+	register(key: string, value: T, owner?: string): (() => void);
+	/**
+	 * Retrait explicite par clef ; rend `true` si quelque chose a été retiré.
+	 *
+	 * La fermeture rendue par `register()` reste la voie NORMALE — elle porte la
+	 * garde d'identité (ne défaire que si l'entrée est toujours la sienne). Ceci
+	 * est un ordre direct, sans garde : à réserver aux retraits explicites.
+	 */
+	remove(key: string): boolean;
+	get(key: string): T | undefined;
+	has(key: string): boolean;
+	keys(): Array<string>;
+	entries(): Array<{
+		key: string;
+		value: T;
+		owner: string;
+	}>;
+	get size(): number;
+}
+declare class ViewOverlays implements OverlayHost {
+	private paneParent;
+	/** Le repère de `coordsAtPos` — c'est LUI qui héberge le plan document. */
+	private documentParent;
+	private viewportRoot;
+	private documentRoot;
+	private geometryCbs;
+	private observer;
+	private lastWidths;
+	/**
+	 * L'échelle appliquée au plan document par la vue, lue à CHAQUE conversion.
+	 *
+	 * ★ POURQUOI une fonction et pas un nombre : le zoom d'une vue PDF change
+	 *   sans prévenir personne. Une valeur copiée serait périmée au premier
+	 *   zoom — le même piège que l'écart de repère qu'on a supprimé plus haut,
+	 *   et pour la même raison : ne jamais dupliquer ce qui bouge.
+	 */
+	private scale;
+	/**
+	 * La COLONNE DE LECTURE — l'élément dont les marges sont les marges.
+	 *
+	 * ★ POURQUOI c'est une entrée distincte du plan document, alors que ç'a
+	 *   longtemps été le même élément : parce que ce sont deux rôles différents,
+	 *   et qu'ils ne coïncident que par accident. Le plan est un REPÈRE (l'origine
+	 *   des coordonnées) ; la colonne est une GÉOMÉTRIE (là où s'arrête le texte).
+	 *   Sur un markdown, `.cm-scroller` était les deux à la fois, donc la
+	 *   confusion ne coûtait rien. Sur un PDF, le plan est une boîte 0×0 — en
+	 *   déduire la colonne donnait une marge gauche négative et une marge droite
+	 *   large comme le pane entier.
+	 *
+	 *   Une vue DÉCLARE donc sa colonne (`ItemView.documentColumn`) au lieu qu'on
+	 *   la devine. Défaut : le plan lui-même, ce qui préserve le comportement des
+	 *   vues où les deux coïncident vraiment.
+	 */
+	private columnParent;
+	constructor(paneParent: HTMLElement, documentParent?: HTMLElement | null, scale?: () => number, columnParent?: HTMLElement | null);
+	/** L'échelle, bornée : une valeur nulle ou absurde ferait exploser les divisions. */
+	private echelle;
+	mount(el: HTMLElement, plane: OverlayPlane): () => void;
+	clientToViewport(x: number, y: number): {
+		x: number;
+		y: number;
+	} | null;
+	clientToDocument(x: number, y: number): {
+		x: number;
+		y: number;
+	} | null;
+	gutterBand(side: GutterSide): {
+		left: number;
+		width: number;
+	} | null;
+	onGeometryChange(cb: () => void): () => void;
+	destroy(): void;
+	/**
+	 * L'origine du repère `coordsAtPos`, en coords CLIENT — l'inverse exact du
+	 * `getBase()` de CM6. Le terme de scroll est nul tant que le scroller de
+	 * l'éditeur ne scrolle pas lui-même (chez nous c'est `.doc-scroll` qui s'en
+	 * charge), mais le garder rend le calcul juste dans les deux cas.
+	 */
+	private documentOrigin;
+	/**
+	 * Un seul ResizeObserver pour toute la vue, ouvert au premier abonné et fermé
+	 * au dernier. Il regarde les deux boîtes dont dépendent les marges : le pane et
+	 * la colonne.
+	 *
+	 * Le filtre sur les LARGEURS n'est pas de l'optimisation prématurée : la
+	 * colonne change de hauteur à chaque frappe, ce qui déclencherait l'observateur
+	 * en continu pour une géométrie de marge inchangée.
+	 */
+	private ensureObserver;
+	private stopObserver;
+	private ensureViewport;
+	private ensureDocument;
+	private static makeRoot;
+}
+declare class WorkspaceRibbon {
+	workspace: Workspace;
+	app: App;
+	side: "left" | "right";
+	containerEl: HTMLElement;
+	/** Les actions des plugins — la partie pilotée par le registre. */
+	private actionsEl;
+	constructor(workspace: Workspace, side?: "left" | "right");
+	/**
+	 * Projette le registre dans le DOM. replaceChildren + boutons STABLES :
+	 * un retrait fait disparaître le bouton (plus ré-appendu), un ajout
+	 * s'insère à sa place de priorité — et les références déjà rendues aux
+	 * plugins par addRibbonIcon restent les éléments vivants, listeners
+	 * compris. Reconstruire les boutons à chaque fois les rendrait orphelins.
+	 */
+	private rebuild;
+	/** Crée le bouton d'un item UNE SEULE FOIS — mémoïsé sur l'item lui-même. */
+	private buttonFor;
+}
+declare class WorkspaceRoot extends WorkspaceSplit {
+	parent: WorkspaceParent | null;
+	constructor(workspace: Workspace);
+}
+declare class WorkspaceSidedock extends WorkspaceSplit {
+	collapsed: boolean;
+	side: "left" | "right";
+	constructor(workspace: Workspace, side: "left" | "right");
+	/**
+	 * Un dock ajoute les deux choses qui lui sont propres : son repli (un vrai
+	 * champ) et sa largeur (une propriété CSS posée par
+	 * Workspace.attachSidebarResize). `--sidebar-width` est lue sur le style
+	 * INLINE et non calculée : tant que l'utilisateur n'a pas dragué, elle est
+	 * vide — et c'est exactement ce qu'on veut sérialiser, « pas de largeur
+	 * choisie », pour que le CSS garde la main au restore.
+	 */
+	serialize(): SplitLayout;
+	toggle(): void;
+	collapse(): void;
+	expand(): void;
+}
+declare class WorkspaceSplit extends WorkspaceParent {
+	parent: WorkspaceParent | null;
+	direction: SplitDirection;
+	constructor(workspace: Workspace, direction?: SplitDirection, className?: string);
+	/**
+	 * §8.2 — la géométrie est LUE DANS LE DOM au moment de sérialiser.
+	 *
+	 * C'est un choix assumé : les proportions vivent dans le `flex-grow` que
+	 * pose attachResize (plus bas), et nulle part ailleurs. Le modèle n'en a
+	 * pas de copie, donc rien à tenir synchronisé — mais le DOM reste la source
+	 * de vérité de la géométrie, et une lecture faite pendant que l'arbre est
+	 * caché ou en transition rendrait des valeurs fausses. C'est le garde
+	 * `layoutReady` de Workspace.saveLayout() qui écarte ce cas.
+	 */
+	serialize(): SplitLayout;
+	protected serializeChildren(): LayoutNode[];
+	setDirection(direction: SplitDirection): void;
+	addChild(child: WorkspaceItem, index?: number): void;
+	removeChild(child: WorkspaceItem): void;
+	/**
+	 * Le point UNIQUE « les enfants de ce split ont changé ». Deux responsabilités
+	 * indissociables d'un changement structurel : refaire les poignées, et
+	 * rétablir l'invariant de géométrie. Appelé par addChild, removeChild et la
+	 * restauration (Workspace.applyGeometry) — un seul propriétaire, pour qu'une
+	 * future mutation ne puisse pas oublier l'un des deux (le bug d'origine :
+	 * removeChild refaisait les poignées mais pas la géométrie).
+	 */
+	reflowGeometry(): void;
+	/**
+	 * L'invariant de géométrie : la somme des flex-grow des enfants vaut leur
+	 * nombre (moyenne 1), proportions gardées. Sans lui, une somme < 1 laisse un
+	 * trou (piège flexbox §9.7, voir normalizeGrows) — typiquement l'unique
+	 * survivant d'un merge, hérité d'un resize à 0.95. On lit le flex-grow inline
+	 * (growInline), donc ça marche même sur un split encore détaché (restauration).
+	 */
+	private normalizeGrow;
+	/**
+	 * (Re)crée les poignées : une avant chaque enfant sauf le premier. Ce sont
+	 * des <div> DOM, PAS des nœuds de children[] — d'où la régénération plutôt
+	 * qu'un suivi. Sans état ; l'état du resize est capturé au pointerdown.
+	 */
+	private rebuildResizeHandles;
+	/**
+	 * Drague la poignée → transfère du flex-grow entre les deux voisins EN
+	 * GARDANT leur somme constante : les autres panes ne bougent pas. Les enfants
+	 * sont flex: 1 1 0% → taille ∝ flex-grow.
+	 */
+	private attachResize;
+}
+declare class WorkspaceTabs extends WorkspaceParent {
+	parent: WorkspaceParent | null;
+	tabHeaderEl: HTMLElement;
+	tabHeaderInnerEl: HTMLElement;
+	tabContentEl: HTMLElement;
+	private outlineEl;
+	private outlinePathEl;
+	private outlineObserver;
+	private activeIndex;
+	private suppressTabClick;
+	constructor(workspace: Workspace);
+	/**
+	 * On redirige l'insertion vers tabContentEl : sans ça, addChild() mettrait
+	 * les feuilles à côté de la barre d'onglets au lieu de dessous.
+	 */
+	protected get childrenEl(): HTMLElement;
+	addChild(child: WorkspaceItem, index?: number): void;
+	removeChild(child: WorkspaceItem): void;
+	/** §8.2 — une pile, et l'onglet qu'elle montrait. */
+	serialize(): TabsLayout;
+	selectTab(index: number): void;
+	getActiveLeaf(): WorkspaceLeaf | null;
+	/**
+	 * Reconstruit la barre d'onglets. Public : une feuille dont la vue vient de
+	 * changer (setViewState) appelle ceci sur son parent — sans ça, un onglet
+	 * garderait le titre de l'ANCIENNE vue (« Vide » après l'ouverture d'un
+	 * fichier, par exemple).
+	 */
+	refreshHeaders(): void;
+	private rebuildTabHeaders;
+	/** L'interstice (0…N) à cette abscisse, en scannant les onglets. */
+	private dropIndexAt;
+	/** Traduit un point en zone de drop, selon la géométrie PROPRE de la pile. */
+	private zoneAt;
+	/**
+	 * Le commit d'un drop : selon la zone sous le curseur, réordonne, rejoint la
+	 * pile (centre), ou crée un split (les 4 bords). C'est ici — et pas dans
+	 * l'aperçu — que la vraie hiérarchie WorkspaceSplit entre en jeu.
+	 */
+	dropLeaf(leaf: WorkspaceLeaf, x: number, y: number): void;
+	/** Réordonne dans cette pile, à l'interstice sous le curseur. */
+	private reorderLeaf;
+	/**
+	 * Crée un split : une nouvelle pile accueille `leaf`, du côté indiqué par la
+	 * zone. La RÈGLE unique :
+	 *   - même axe que le parent → pile sœur (addChild) ;
+	 *   - axe perpendiculaire → on enveloppe ce pane dans un nouveau WorkspaceSplit
+	 *     de l'axe voulu, contenant [pane, nouvelle pile] dans le bon ordre.
+	 * Le rendu sort du flex (mod-vertical/horizontal), aucun inset bricolé.
+	 *
+	 * PUBLIC depuis §11.5 : le drag l'appelait seul ; `Workspace.createLeafBySplit`
+	 * — donc les commandes `workspace:split-*` et le menu ⋯ — passent par la
+	 * MÊME méthode. Une seule implémentation du split, trois portes d'entrée.
+	 */
+	splitLeaf(leaf: WorkspaceLeaf, zone: DropZone): void;
+	/**
+	 * Actions sur les onglets, puis la liste de TOUS les onglets (icône + titre,
+	 * coche sur l'actif). Builder + sections, comme les autres menus du projet
+	 * (voir core/Menu.ts).
+	 */
+	private showTabListMenu;
+	/** Ferme tous les onglets du pane. Le dernier detach déclenche onPileEmptied
+	 *  (le pane se ferme s'il est dans un split, sinon un onglet vide s'ouvre). */
+	private closeAll;
+	/**
+	 * Aperçu du drop selon la zone sous le curseur : barre de réordonnancement
+	 * (bas de la barre) ou aperçu de split (les 4 bords). Purement visuel et
+	 * éphémère — aucune mutation d'arbre ici.
+	 */
+	showDropIndicator(x: number, y: number): void;
+	/** La barre --drop-x à l'interstice sous le curseur. */
+	private showReorderBar;
+	clearDropIndicator(): void;
+	/**
+	 * Retrace le contour de l'onglet actif : la baseline de la barre,
+	 * interrompue sous l'onglet pour épouser sa silhouette — montée, arcs
+	 * convexes en haut, arcs concaves au pied (ceux que les ::before/::after
+	 * CSS remplissent). Un seul path pour toute la barre : une bordure CSS
+	 * par morceau laisserait des raccords visibles aux jonctions.
+	 */
+	private updateTabOutline;
+}
+declare global {
+	interface Window {
+		app: App;
+	}
+}
+/**
+ * Un maillon PUREMENT MARQUEUR de la hiérarchie — corps vide, et c'est fidèle :
+ * chez Obsidian aussi elle ne déclare rien du tout.
+ *
+ * Son rôle est de séparer, dans la chaîne d'héritage, les vues de fichier
+ * simplement lisibles (image, PDF) de celles qui savent écrire (TextFileView →
+ * MarkdownView). Un `instanceof EditableFileView` répond alors à « cette vue
+ * peut-elle modifier son fichier ? » sans connaître le type concret.
+ *
+ * Ne la supprime pas sous prétexte qu'elle est vide : c'est le point
+ * d'accrochage prévu pour ce qui concernera l'édition en général.
+ */
+export declare abstract class EditableFileView extends FileView {
+}
+export declare abstract class FileView extends ItemView {
+	file: TFile | null;
+	allowNoFile: boolean;
+	navigation: boolean;
+	constructor(leaf: WorkspaceLeaf);
+	onload(): void;
+	loadFile(file: TFile | null): Promise<void>;
+	onLoadFile(file: TFile): Promise<void>;
+	onUnloadFile(file: TFile): Promise<void>;
+	onRename(file: TFile): Promise<void>;
+	canAcceptExtension(extension: string): boolean;
+	/** Le fichier de la vue, pour le LayerContext (ItemView le veut null par défaut). */
+	protected getViewFile(): TFile | null;
+	/**
+	 * L'étage FICHIER du menu ⋯ (§5.3). Les entrées grisées sont la silhouette
+	 * du menu d'Obsidian : chacune s'activera quand sa machinerie existera —
+	 * le TODO dit laquelle.
+	 */
+	onPaneMenu(menu: Menu, source: string): void;
+	/**
+	 * Le geste « Renommer » — template method : FileView ne sait pas COMMENT on
+	 * renomme (chaque vue a sa propre UI). MarkdownView focus son titre inline ;
+	 * une vue sans UI de renommage laisse le no-op.
+	 */
+	protected requestRename(): void;
+	getDisplayText(): string;
+	getState(): Record<string, unknown>;
+	setState(state: unknown, result: ViewStateResult): Promise<void>;
+}
+/**
+ * §14 — une SuggestModal branchée sur la recherche floue.
+ *
+ * Les trois trous de SuggestModal se réduisent à trois trous plus petits :
+ * quels ÉLÉMENTS (`getItems`), quel TEXTE pour chacun (`getItemText`), que
+ * faire du choix (`onChooseItem`). Le filtrage, le tri et le surlignage sont
+ * fournis. Le quick switcher et la palette de commandes sont exactement ça.
+ *
+ * ★ `T` est l'élément de la sous-classe ; ce que SuggestModal manipule est un
+ *   `FuzzyMatch<T>` — l'élément ET son match, pour surligner au rendu. La
+ *   sous-classe n'a pas à le savoir : `onChooseItem` reçoit `T` nu.
+ */
+export declare abstract class FuzzySuggestModal<T> extends SuggestModal<FuzzyMatch<T>> {
+	abstract getItems(): T[];
+	abstract getItemText(item: T): string;
+	abstract onChooseItem(item: T, evt: MouseEvent | KeyboardEvent): void;
+	getSuggestions(query: string): FuzzyMatch<T>[];
+	/**
+	 * Le tri, isolé pour être surchargeable.
+	 *
+	 * ★ Requête VIDE : on ne trie PAS. `getItems()` a alors le dernier mot sur
+	 *   l'ordre — c'est ce qui permet à la palette de montrer épinglés puis
+	 *   récents avant la première frappe. Dès qu'on tape, c'est le score.
+	 */
+	protected sortSuggestions(resultats: FuzzyMatch<T>[], query: string): void;
+	/** Défaut : le texte, avec les plages matchées surlignées. */
+	renderSuggestion(value: FuzzyMatch<T>, el: HTMLElement): void;
+	onChooseSuggestion(value: FuzzyMatch<T>, evt: MouseEvent | KeyboardEvent): void;
+}
+export declare abstract class ItemView extends View {
+	headerEl: HTMLElement;
+	actionsEl: HTMLElement;
+	moreOptionsEl: HTMLElement;
+	contentEl: HTMLElement;
+	constructor(leaf: WorkspaceLeaf);
+	/** Active cette feuille, puis exécute — le contrat de toute entrée de menu ⋯. */
+	protected executerIci(commandId: string): void;
+	addAction(icon: string, title: string, callback: (evt: MouseEvent) => unknown): HTMLElement;
+	/** Points de montage d'overlay de cette vue (viewport ; + document si éditeur). */
+	protected overlays: ViewOverlays | null;
+	/** Ids des layers actifs sur CETTE vue (survit à rebuildView via l'état éphémère). */
+	private activeLayers;
+	/** Les instances montées, par id — ressources jetables (un disposer chacune). */
+	private mountedLayers;
+	/**
+	 * La surface de document de la vue, s'il y en a une. Défaut : aucune.
+	 *
+	 * ★ PUBLIC depuis §11.5, et ce n'est pas un détail : `Workspace.activeEditor`
+	 *   le lit pour résoudre la cible d'une commande d'éditeur. Le hook servait
+	 *   jusqu'ici aux seuls layers, qui vivent DANS la vue ; il est désormais
+	 *   aussi une porte vers l'extérieur.
+	 */
+	getEditor(): DocumentSurface | null;
+	/**
+	 * Le facteur d'échelle du plan document, quand la vue en applique un.
+	 *
+	 * ★ POURQUOI ce hook existe : une vue peut zoomer (le PDF le fait). Le plan
+	 *   document vit alors dans un espace NON zoomé — c'est ce qui rend les
+	 *   ancres invariantes au zoom : la page change de taille en pixels, pas
+	 *   l'annotation relativement à elle. Mais un événement pointeur, lui, arrive
+	 *   toujours en pixels écran : la conversion doit donc diviser par l'échelle.
+	 *
+	 *   Même mécanique que le `scaleX/scaleY` de CM6, pour la même raison. Défaut
+	 *   1 : une vue qui ne zoome pas ne paie rien.
+	 */
+	protected documentScale(): number;
+	/**
+	 * La COLONNE DE LECTURE de la vue — l'élément dont les bords définissent les
+	 * marges où se rangent les widgets de gouttière.
+	 *
+	 * ★ Distinct de `documentPlane()`, et la distinction n'est pas théorique :
+	 *   le plan est un REPÈRE, la colonne est une GÉOMÉTRIE. Ils coïncidaient
+	 *   tant que la seule vue ancrable était le markdown, où `.cm-scroller` joue
+	 *   les deux rôles. Une vue PDF a un plan de taille nulle — en déduire la
+	 *   colonne donnait une marge gauche négative et une marge droite large comme
+	 *   tout le pane.
+	 *
+	 * Défaut : le plan, ce qui préserve exactement le comportement des vues où
+	 * les deux sont le même élément.
+	 */
+	protected documentColumn(): HTMLElement | null;
+	/**
+	 * L'élément qui sert de REPÈRE à `coordsAtPos`, si la vue a un éditeur : c'est
+	 * lui qui hébergera le plan document, pour que les coordonnées de l'éditeur y
+	 * retombent sans conversion. Défaut : aucun (plan viewport seul).
+	 */
+	protected documentPlane(): HTMLElement | null;
+	/** Le fichier de la vue, pour le LayerContext (FileView le surcharge). */
+	protected getViewFile(): TFile | null;
+	/**
+	 * Monté après onOpen() (cf. View.open) : l'éditeur de la sous-classe existe,
+	 * donc documentPlane() peut le référencer.
+	 */
+	protected onAfterOpen(): void;
+	/** Bascule un layer sur cette vue et remonte l'écran dans la foulée (synchrone). */
+	toggleLayer(id: string): void;
+	private showLayerMenu;
+	/** Le catalogue × l'activation × l'applicabilité → montage/démontage par clef. */
+	private reconcileLayers;
+	private layerApplies;
+	private layerContext;
+	getEphemeralState(): Record<string, unknown>;
+	setEphemeralState(state: unknown): void;
+}
+/**
+ * §9.4 / §12.3 — une modale de SUGGESTION : un champ, une liste, un choix.
+ *
+ * C'est le « framework inversé » du document d'archi : la classe impose le
+ * squelette (le champ, le clavier, la sélection, le défilement) et la
+ * sous-classe remplit trois trous — d'où viennent les suggestions, comment en
+ * dessiner une, que faire de celle qu'on choisit. Le quick switcher et la
+ * palette de commandes ne sont que deux remplissages de ces trois trous.
+ *
+ * ★ Le clavier passe par la PORTÉE de la modale (héritée de Modal), pas par des
+ *   `keydown` sur l'input. Différence concrète : les flèches et Entrée sont
+ *   consommées AVANT de pouvoir atteindre quoi que ce soit d'autre, et un
+ *   raccourci global sur ces touches ne peut pas voler la frappe.
+ *
+ * Classes CSS d'Obsidian — l'API des thèmes :
+ *
+ *     .modal-container.mod-dim
+ *       .modal-bg
+ *       .prompt                          ← remplace .modal
+ *         .prompt-input-container
+ *           input.prompt-input
+ *         .prompt-results
+ *           .suggestion-item.is-selected
+ *         .prompt-instructions
+ *           .prompt-instruction
+ *             .prompt-instruction-command
+ */
+export declare abstract class SuggestModal<T> extends Modal {
+	/** Nombre maximal de suggestions rendues. */
+	limit: number;
+	emptyStateText: string;
+	inputEl: HTMLInputElement;
+	resultContainerEl: HTMLElement;
+	private instructionsEl;
+	private suggestions;
+	private itemEls;
+	private selected;
+	/** Numéro de la dernière requête : une réponse asynchrone en retard est jetée. */
+	private requete;
+	constructor(app: App);
+	/** D'où viennent les suggestions pour cette requête. Peut être asynchrone. */
+	abstract getSuggestions(query: string): T[] | Promise<T[]>;
+	/** Dessine UNE suggestion dans `el` (déjà `.suggestion-item`). */
+	abstract renderSuggestion(value: T, el: HTMLElement): void;
+	/** Que faire de celle que l'utilisateur a choisie. La modale est déjà fermée. */
+	abstract onChooseSuggestion(item: T, evt: MouseEvent | KeyboardEvent): void;
+	/** Rien ne correspond. Défaut : le texte d'état vide. */
+	onNoSuggestion(): void;
+	setPlaceholder(placeholder: string): this;
+	setInstructions(instructions: Instruction[]): this;
+	onOpen(): void;
+	onClose(): void;
+	private updateSuggestions;
+	private setSelected;
+	private useSelectedItem;
+	/** Ferme PUIS notifie : la sous-classe peut ouvrir autre chose sans conflit de portée. */
+	selectSuggestion(value: T, evt: MouseEvent | KeyboardEvent): void;
+}
+export declare abstract class TAbstractFile {
+	vault: Vault;
+	path: string;
+	parent: TFolder | null;
+	constructor(vault: Vault, path: string, parent?: TFolder | null);
+	get name(): string;
+}
+export declare abstract class TextFileView extends EditableFileView {
+	data: string;
+	requestSave: () => void;
+	constructor(leaf: WorkspaceLeaf);
+	abstract getViewData(): string;
+	abstract setViewData(data: string, clear: boolean): void;
+	abstract clear(): void;
+	onLoadFile(file: TFile): Promise<void>;
+	onUnloadFile(file: TFile): Promise<void>;
+	save(clear?: boolean): Promise<void>;
+	onload(): void;
+}
+export declare abstract class View extends Component {
+	app: App;
+	leaf: WorkspaceLeaf;
+	containerEl: HTMLElement;
+	icon: string;
+	navigation: boolean;
+	/**
+	 * §12.5 — les raccourcis propres à cette vue, actifs quand elle a le focus.
+	 *
+	 * Une vue qui en pose un doit l'empiler elle-même
+	 * (`app.keymap.pushScope(this.scope)`) au focus et le dépiler à la perte —
+	 * le workspace ne le fait pas à sa place, parce qu'il ne sait pas ce qu'une
+	 * vue considère comme « avoir le focus ».
+	 */
+	scope: Scope | null;
+	constructor(leaf: WorkspaceLeaf);
+	abstract getViewType(): string;
+	abstract getDisplayText(): string;
+	getIcon(): string;
+	protected onOpen(): Promise<void>;
+	protected onClose(): Promise<void>;
+	/**
+	 * Hook de câblage de la BASE, joué APRÈS onOpen() (donc après que la vue a
+	 * bâti son DOM et, le cas échéant, son éditeur). ItemView s'en sert pour
+	 * monter l'hébergement de layers — le dev de vue n'a rien à faire. À ne pas
+	 * confondre avec onOpen(), qui est le hook des sous-classes.
+	 */
+	protected onAfterOpen(): void;
+	open(parentEl: Node): Promise<void>;
+	close(): Promise<void>;
+	getState(): Record<string, unknown>;
+	setState(state: unknown, result: ViewStateResult): Promise<void>;
+	getEphemeralState(): Record<string, unknown>;
+	setEphemeralState(state: unknown): void;
+	onResize(): void;
+	/**
+	 * Le menu ⋯ du panneau. Interception par mutation (§5.3) : la vue reçoit un
+	 * Menu EN CONSTRUCTION et y AJOUTE ses entrées — elle ne le crée pas, ne
+	 * l'affiche pas, ne le ferme pas. C'est l'ouvreur (l'onglet) qui orchestre,
+	 * et les plugins passeront après elle sur le même objet.
+	 */
+	onPaneMenu(menu: Menu, source: "more-options" | "tab-header" | string): void;
+}
+export declare class App {
+	vault: Vault;
+	workspace: Workspace;
+	plugins: Plugins;
+	dragManager: DragManager;
+	/** La version de Fragment (injectée à la compilation, cf. __APP_VERSION__).
+	 *  Le cœur en est propriétaire — un plugin lit `app.version`, pas la
+	 *  constante de build, qui n'existe pas pour lui. */
+	version: string;
+	/** Le pont vers les capacités du main (eval hors CSP, shim sur le PATH).
+	 *  Câblé au boot (bootApp.tsx) depuis window.electron.cli ; le cœur et les
+	 *  plugins passent par ici plutôt que de toucher window.electron. */
+	cliHost: CliHost;
+	keymap: Keymap;
+	scope: Scope;
+	hotkeyManager: HotkeyManager;
+	viewRegistry: Registry<ViewCreator>;
+	extensionRegistry: Registry<string>;
+	embedRegistry: Registry<unknown>;
+	commands: CommandManager;
+	icons: Registry<string>;
+	protocolHandlers: Registry<ProtocolHandler>;
+	codeBlockProcessors: Registry<CodeBlockProcessor>;
+	propertyWidgets: Registry<unknown>;
+	layers: Registry<LayerSpec>;
+	cliHandlers: Registry<CliHandlerSpec>;
+	postProcessors: OrderedRegistry<MarkdownPostProcessor>;
+	editorExtensions: OrderedRegistry<Extension>;
+	ribbonItems: OrderedRegistry<RibbonItem>;
+	statusBarItems: OrderedRegistry<unknown>;
+	settingTabs: OrderedRegistry<unknown>;
+	/** Pour l'inspecteur d'UI — l'ordre d'affichage. */
+	registries: InspectableRegistry[];
+	lastEvent: Event | null;
+	constructor();
+	/** §15 — une URL arrive, on cherche l'action MAINTENANT dans la table. */
+	handleProtocol(action: string, params: Record<string, string>): void;
+	private cleLocale;
+	loadLocalStorage(key: string): unknown;
+	saveLocalStorage(key: string, data: unknown): void;
+}
+/**
+ * Une erreur qui PORTE un code de sortie.
+ *
+ * Un handler qui lève n'importe quoi rend EXIT.HANDLER_ERROR (1) avec la pile.
+ * Un handler qui lève une CliError choisit son code — « commande introuvable »
+ * n'est pas un plantage, c'est un 7, et un script doit pouvoir les distinguer.
+ */
+export declare class CliError extends Error {
+	readonly code: number;
+	constructor(code: number, message: string);
+}
+export declare class Component {
+	_children: Component[];
+	_cleanups: (() => void)[];
+	_loaded: boolean;
+	load(): void;
+	unload(): void;
+	onunload(): void;
+	onload(): void;
+	addChild<T extends Component>(component: T): T;
+	removeChild<T extends Component>(component: T): T;
+	register(cb: () => any): void;
+	registerEvent(eventRef: EventRef): void;
+	registerDomEvent<K extends keyof HTMLElementEventMap>(el: HTMLElement, type: K, callback: (this: HTMLElement, ev: HTMLElementEventMap[K]) => unknown, options?: boolean | AddEventListenerOptions): void;
+	registerDomEvent<K extends keyof DocumentEventMap>(el: Document, type: K, callback: (this: Document, ev: DocumentEventMap[K]) => unknown, options?: boolean | AddEventListenerOptions): void;
+	registerDomEvent<K extends keyof WindowEventMap>(el: Window, type: K, callback: (this: Window, ev: WindowEventMap[K]) => unknown, options?: boolean | AddEventListenerOptions): void;
+	registerInterval(id: number): number;
+}
+export declare class EventRef {
+	emitter: Events;
+	name: string;
+	cb: (...args: any[]) => unknown;
+	ctx: unknown;
+	constructor(emitter: Events, name: string, cb: (...args: any[]) => unknown, ctx: unknown);
+	off(): void;
+}
+export declare class Events {
+	_handlers: Map<string, EventRef[]>;
+	on(name: string, cb: (...args: any[]) => unknown, ctx?: unknown): EventRef;
+	/** Désinscription par identité de fonction — conservée par compatibilité. */
+	off(name: string, cb: (...args: any[]) => unknown): void;
+	/** ★ Désinscription par référence. Ce que registerEvent() appelle. */
+	offref(ref: EventRef): void;
+	trigger(name: string, ...data: any[]): void;
+	/** §5.1 — le dispatch défensif. */
+	tryTrigger(ref: EventRef, args: any[]): void;
+	/** Introspection — sert à l'inspecteur d'UI. */
+	_listenerCount(name: string): number;
+}
+export declare class Keymap {
+	/** Les modificateurs de la DERNIÈRE frappe vue, en forme canonique. */
+	modifiers: string;
+	/** La portée du bas de la pile — celle où le HotkeyManager s'installe. */
+	readonly rootScope: Scope;
+	/** La portée active. C'est elle qui reçoit la frappe en premier. */
+	scope: Scope;
+	private prevScopes;
+	private detacher;
+	/**
+	 * @param cible où écouter. `null` = nulle part (mode headless, tests) — le
+	 *              Keymap reste alors parfaitement utilisable par appel direct
+	 *              à `handleKeyEvent`, ce dont les tests se servent.
+	 */
+	constructor(cible?: EventTarget | null);
+	destroy(): void;
+	getRootScope(): Scope;
+	pushScope(scope: Scope): void;
+	/**
+	 * ★ Dépiler une portée qui n'est PAS au sommet ne se plaint pas : on la
+	 *   retire de la pile, et le sommet ne bouge pas. C'est ce qui rend le
+	 *   démontage désordonné sans danger — deux modales fermées dans le
+	 *   « mauvais » ordre laissent quand même une pile cohérente.
+	 */
+	popScope(scope: Scope): void;
+	/** Public pour que les tests puissent injecter une frappe sans DOM. */
+	handleKeyEvent(evt: KeyboardEvent): boolean | void;
+	/** Les modificateurs d'un événement, en forme canonique. */
+	static getModifiers(evt: Pick<KeyboardEvent, "ctrlKey" | "metaKey" | "altKey" | "shiftKey">): string;
+	/** `['Mod','Shift']` → `"Ctrl,Shift"`. Résout, trie, joint. */
+	static compileModifiers(modifiers: Modifier[], plateforme?: Plateforme): string;
+	/**
+	 * L'inverse — pour AFFICHER une liaison enregistrée en dur.
+	 *
+	 * Le modificateur natif de la plateforme redevient `Mod`, ce qui est la
+	 * bonne réponse à « comment nommer cette combinaison à l'utilisateur ? ».
+	 */
+	static decompileModifiers(compiles: string, plateforme?: Plateforme): Modifier[];
+	static isModifierKey(key: string): boolean;
+	/** Ce modificateur-là est-il enfoncé ? `Mod` se résout selon la plateforme. */
+	static isModifier(evt: Pick<KeyboardEvent, "ctrlKey" | "metaKey" | "altKey" | "shiftKey">, modifier: Modifier, plateforme?: Plateforme): boolean;
+	/**
+	 * La liaison correspond-elle à la frappe ?
+	 *
+	 * ★ Les modificateurs sont comparés à l'IDENTIQUE, pas par inclusion :
+	 *   `Mod+P` ne se déclenche PAS sur `Mod+Shift+P`. Sans quoi tout raccourci
+	 *   serait le préfixe de tous ses sur-ensembles.
+	 *
+	 * ★ La touche est acceptée sur `vkey` (emplacement physique) OU sur `key`
+	 *   sans tenir compte de la casse. Le second point n'est pas une commodité :
+	 *   `Shift+A` produit `key === 'A'` tandis que `A` seul produit `'a'`, et
+	 *   une liaison écrite `'A'` doit marcher dans les deux cas — la
+	 *   différenciation par Shift est déjà faite par les modificateurs.
+	 */
+	static isMatch(liaison: Liaison, ctx: KeymapContext): boolean;
+	/**
+	 * §8.5 — l'événement demande-t-il une ouverture ailleurs ?
+	 *
+	 * C'est LA raison d'être d'`app.lastEvent` : une commande n'a pas accès à
+	 * l'événement qui l'a déclenchée, mais elle peut lire celui-ci pour décider
+	 * entre remplacer la feuille, ouvrir un onglet, ou splitter.
+	 */
+	static isModEvent(evt: Event | null | undefined): PaneType | false;
+}
+/**
+ * Le menu contextuel (§12.3) — un builder impératif, DOM pur, à durée de vie
+ * courte : construit, montré, détruit à la fermeture. Jamais réutilisé.
+ *
+ * ★ POURQUOI extends Component : tout ce que le menu acquiert (listeners de
+ *   fermeture sur document, éléments DOM, sous-menus) est enregistré via
+ *   register*()/addChild() et rejoué à hide(). Un menu ne peut pas fuir — même
+ *   mécanique que les vues. Les SOUS-MENUS sont des enfants Component : fermer
+ *   un menu démonte récursivement toute la chaîne ouverte, à n'importe quelle
+ *   profondeur, sans une ligne de gestion dédiée.
+ *
+ * ★ POURQUOI ce n'est PAS un registre : un menu est une contribution À
+ *   L'INSTANT T. Le pattern est l'interception par mutation (§5.3) — celui qui
+ *   ouvre le menu le construit, le peuple, puis le passe aux listeners d'un
+ *   événement (`editor-menu`, `file-menu`, onPaneMenu) qui le MUTENT :
+ *
+ *       const menu = new Menu();
+ *       menu.addItem((i) => i.setTitle('Copier').onClick(…));
+ *       workspace.trigger('editor-menu', menu, editor, view);   // chacun ajoute
+ *       menu.showAtMouseEvent(evt);
+ *
+ *   « C'est moins pur que des contributions déclaratives, mais radicalement
+ *   plus simple » — et cohérent avec la confiance totale accordée aux plugins.
+ */
+export declare class Menu extends Component {
+	/** La racine, créée tout de suite mais attachée au body seulement à show. */
+	dom: HTMLElement;
+	/** Le menu qui nous héberge comme sous-menu. `null` pour un menu racine. */
+	private parentMenu;
+	/** Nos sous-menus (aussi enfants Component — ceci n'est que l'index typé). */
+	private childMenus;
+	/** Le sous-menu actuellement déployé, s'il y en a un. */
+	private activeSubmenu;
+	private items;
+	private hideCallbacks;
+	private shown;
+	/** L'ordre des sections déclaré par l'OUVREUR du menu (voir addSections). */
+	private declaredSections;
+	constructor();
+	/** Le builder central. Rend `this` — tout s'enchaîne. */
+	addItem(cb: (item: MenuItem) => unknown): this;
+	addSeparator(): this;
+	/**
+	 * Déclare l'ordre des sections de ce menu — appelé par celui qui OUVRE le
+	 * menu, avant de le passer aux listeners (`file-menu`, onPaneMenu…).
+	 *
+	 * ★ POURQUOI les sections : c'est la pièce qui rend l'interception par
+	 *   mutation (§5.3) viable à plusieurs contributeurs. Sans elles, l'ordre
+	 *   visuel du menu dépend de l'ordre d'exécution des listeners — arbitraire.
+	 *   Avec setSection, chaque item déclare son GROUPE (« je suis une action
+	 *   destructive ») et atterrit au bon endroit, peu importe qui a parlé
+	 *   quand. Même contrat qu'Obsidian : setSection est public (0.15.3),
+	 *   addSections est réservé à l'ouvreur.
+	 *
+	 * Les sections non déclarées apparaissent après, dans l'ordre de première
+	 * apparition. Les items sans section forment le groupe '' (idem).
+	 */
+	addSections(sections: string[]): this;
+	/**
+	 * Regroupe les items par section et régénère les séparateurs ENTRE les
+	 * groupes. Appelé une seule fois, à show — un menu est one-shot, l'ordre
+	 * final n'est connu qu'à l'affichage (comme Obsidian : « Only works when
+	 * menu is not shown yet »).
+	 *
+	 * OPT-IN : sans aucun setSection ni addSections, ne touche à rien — les
+	 * menus existants (ordre d'insertion + addSeparator manuel) sont
+	 * inchangés. En mode sections, les addSeparator manuels sont retirés :
+	 * les deux régimes ne se mélangent pas, ce sont les groupes qui séparent.
+	 */
+	private applySections;
+	onHide(callback: () => unknown): this;
+	showAtMouseEvent(evt: MouseEvent): this;
+	showAtPosition(x: number, y: number): this;
+	hide(): this;
+	onunload(): void;
+	/** Ce point est-il chez nous OU chez un de nos descendants ? Récursif. */
+	private isInside;
+	/** @internal — appelé par MenuItem.setSubmenu(). */
+	attachSubmenu(sub: Menu): void;
+	/** @internal — survol d'un item : déploie son sous-menu, replie les autres. */
+	onItemHover(item: MenuItem): void;
+	/** @internal — un clic d'item ferme TOUTE la chaîne, pas juste son niveau. */
+	getRoot(): Menu;
+}
+/**
+ * Une entrée de menu. Construite UNIQUEMENT via menu.addItem() — le
+ * constructeur n'est pas exporté du point de vue de l'API.
+ *
+ * Tous les setters rendent `this` : c'est le style builder du §11.7, le même
+ * que le futur `new Setting(el).setName(…).addToggle(…)`.
+ */
+export declare class MenuItem {
+	dom: HTMLElement;
+	/** Le sous-menu de cet item, s'il en a un (voir setSubmenu). */
+	submenu: Menu | null;
+	/** La section de cet item ('' = sans section). Lu par Menu.applySections. */
+	section: string;
+	private iconEl;
+	private titleEl;
+	private menu;
+	private disabled;
+	constructor(menu: Menu);
+	setTitle(title: string): this;
+	setIcon(icon: string): this;
+	setChecked(checked: boolean): this;
+	setDisabled(disabled: boolean): this;
+	/** Marque une entrée destructive (Supprimer…) — en rouge, comme Obsidian. */
+	setWarning(warning: boolean): this;
+	/**
+	 * Place cet item dans une section — le placement devient DÉCLARATIF :
+	 * l'item dit à quel groupe il appartient au lieu de dépendre de l'ordre
+	 * d'exécution des listeners. Voir Menu.addSections pour l'ordre des
+	 * groupes. data-section est posé sur le DOM, comme Obsidian, pour que
+	 * l'inspection révèle les ids de sections d'un menu existant.
+	 */
+	setSection(section: string): this;
+	onClick(callback: (evt: MouseEvent) => unknown): this;
+	/**
+	 * Attache un sous-menu à cet item et LE REND — on le peuple ensuite avec la
+	 * même API que n'importe quel menu :
+	 *
+	 *     menu.addItem((i) => {
+	 *         i.setTitle('Trier par');
+	 *         const sub = i.setSubmenu();
+	 *         sub.addItem((s) => s.setTitle('Nom').onClick(…));
+	 *     });
+	 *
+	 * Nesting illimité gratuit : un sous-menu est un Menu complet, donc ses
+	 * items peuvent avoir des sous-menus — et la cascade de fermeture suit,
+	 * parce que chaque niveau est l'enfant Component du précédent.
+	 */
+	setSubmenu(): Menu;
+}
+/**
+ * §12.3 — la modale : une boîte par-dessus tout, avec SA portée clavier.
+ *
+ * ★ POURQUOI extends Component : tout ce qu'une modale acquiert — son DOM dans
+ *   le body, sa portée dans la pile du Keymap, ses écouteurs — est enregistré
+ *   via register*() et rejoué à close(). Une modale ne peut pas fuir, et elle
+ *   peut se ROUVRIR : load()/unload() sont symétriques, la palette de commandes
+ *   réutilise la même instance à chaque Mod+P.
+ *
+ * ★ LA PORTÉE est le point important. À l'ouverture, `keymap.pushScope(scope)` :
+ *   tant que la modale est là, sa portée est la SEULE interrogée — les
+ *   raccourcis globaux sont masqués, Échap ferme, et une sous-classe y pose ses
+ *   propres liaisons (flèches, Entrée) sans risquer de les voir interceptées
+ *   par l'éditeur en dessous. Le dépilement est enregistré comme un cleanup,
+ *   donc symétrique par construction.
+ *
+ * Les classes CSS sont celles d'Obsidian — c'est l'API publique des thèmes :
+ *
+ *     .modal-container.mod-dim
+ *       .modal-bg
+ *       .modal
+ *         .modal-close-button
+ *         .modal-title
+ *         .modal-content
+ */
+export declare class Modal extends Component {
+	app: App;
+	/** Chaînée à la racine (Scope.pourVue) : Échap ferme la modale et est
+	 *  consommé ici, mais les raccourcis globaux non gérés remontent — une
+	 *  modale ne gèle pas Mod+P (A3). */
+	scope: Scope;
+	/** La racine, plein écran. Attachée au body à open(), retirée à close(). */
+	containerEl: HTMLElement;
+	/** Le voile derrière la boîte. Cliquer dessus ferme. */
+	bgEl: HTMLElement;
+	/** La boîte elle-même. */
+	modalEl: HTMLElement;
+	titleEl: HTMLElement;
+	/** Le seul endroit où une sous-classe écrit. */
+	contentEl: HTMLElement;
+	constructor(app: App);
+	open(): void;
+	close(): void;
+	/** Appelé à chaque ouverture, une fois le DOM attaché et la portée empilée. */
+	onOpen(): void;
+	/** Appelé à chaque fermeture, AVANT le démontage. */
+	onClose(): void;
+	setTitle(title: string): this;
+	setContent(content: string | Node): this;
+}
+export declare class Notice {
+	/** L'élément DOM de la notification — exposé comme chez Obsidian. */
+	readonly noticeEl: HTMLElement;
+	private masquee;
+	private timer;
+	/**
+	 * @param message Le texte (ou un fragment DOM) à afficher.
+	 * @param duration Millisecondes avant disparition ; `0` = persistante (elle
+	 *   ne part qu'au clic). Défaut : 5 s, comme Obsidian.
+	 */
+	constructor(message: string | DocumentFragment, duration?: number);
+	/** Remplace le contenu affiché. Rend `this`, pour chaîner (parité Obsidian). */
+	setMessage(message: string | DocumentFragment): this;
+	/** Ferme la notification (idempotent) : transition de sortie, puis retrait. */
+	hide(): void;
+}
+/**
+ * §12.5 — une PORTÉE clavier : un ensemble de liaisons, empilable.
+ *
+ * Le problème qu'elle résout : quand une modale est ouverte, Échap doit la
+ * fermer et surtout PAS déclencher le « Échap » de la vue en dessous ; les
+ * flèches doivent naviguer dans la liste et pas dans le texte. Sans pile de
+ * portées, chaque composant pose son `keydown` sur `window` et le premier
+ * arrivé gagne — c'est-à-dire le hasard de l'ordre de montage.
+ *
+ * ★ LA RÈGLE DE PROPAGATION, en une phrase : une liaison EXPLICITE arrête la
+ *   chaîne même si elle ne consomme rien ; une liaison ATTRAPE-TOUT
+ *   (`key === null && modifiers === null`) qui ne consomme rien laisse
+ *   continuer.
+ *
+ *   C'est ce qui permet au HotkeyManager de poser UN SEUL handler attrape-tout
+ *   sur la portée racine : quand aucun raccourci ne correspond, il rend
+ *   `undefined` et la chaîne se poursuit normalement.
+ */
+export declare class Scope {
+	keys: KeymapEventHandler[];
+	parent: Scope | null;
+	constructor(parent?: Scope | null);
+	/**
+	 * La portée d'une VUE ou d'une MODALE : chaînée à la racine.
+	 *
+	 * Parent = `app.scope`. La vue/modale a la priorité (ses liaisons sont vues
+	 * d'abord), mais tout ce qu'elle ne reconnaît PAS remonte à la racine —
+	 * Mod+P, Mod+S et les autres globaux restent joignables. C'est le
+	 * `new Scope(app.scope)` d'Obsidian.
+	 */
+	static pourVue(app: App): Scope;
+	/**
+	 * La portée d'un MENU one-shot : parent nul, masquage ASSUMÉ.
+	 *
+	 * Échap ferme et CONSOMME (ne remonte pas à CodeMirror) ; tout le reste est
+	 * bloqué tant que le menu est ouvert — on ne veut pas déclencher un raccourci
+	 * global derrière un menu contextuel.
+	 *
+	 * ★ À NE PAS employer pour un élément PERSISTANT (barre d'outils) : le
+	 *   masquage y gèlerait les globaux dans toute l'app (le bug A3). Un tel
+	 *   élément prend `Scope.pourVue`.
+	 */
+	static echap(fermer: () => void): Scope;
+	/**
+	 * @param modifiers `null` = n'importe quels modificateurs.
+	 * @param key       `null` = n'importe quelle touche. Les deux à `null` = attrape-tout.
+	 * @returns le handler, à garder pour `unregister`.
+	 */
+	register(modifiers: Modifier[] | null, key: string | null, func: KeymapEventListener): KeymapEventHandler;
+	unregister(handler: KeymapEventHandler): void;
+	/** Le dispatch. Rend `false` pour consommer la frappe, `undefined` pour laisser passer. */
+	handleKey(evt: KeyboardEvent, ctx: KeymapContext): boolean | void;
+}
+/**
+ * Nomenclature :
+ *
+ *     "dossier/note.md"  →  name "note.md"   basename "note"   extension "md"
+ *     "README"           →  name "README"    basename "README" extension ""
+ *     ".gitignore"       →  name ".gitignore" basename ".gitignore" extension ""
+ *
+ */
+export declare class TFile extends TAbstractFile {
+	stat: FileStats;
+	constructor(vault: Vault, path: string, stat: FileStats, parent?: TFolder | null);
+	get extension(): string;
+	get basename(): string;
+}
+export declare class TFolder extends TAbstractFile {
+	children: TAbstractFile[];
+	isRoot(): boolean;
+}
+export declare class Toolbar extends Component {
+	/** La racine, créée tout de suite mais attachée au parent seulement à show. */
+	dom: HTMLElement;
+	/**
+	 * La poignée — toujours au BOUT de la barre (à droite en horizontal, en bas
+	 * en vertical). On la traîne pour déplacer la barre, on la double-clique pour
+	 * la faire basculer.
+	 */
+	handleEl: HTMLElement;
+	/**
+	 * La section en cours de remplissage. Une section est un GROUPE d'items entre
+	 * deux séparateurs — c'est elle qui porte la mise en colonnes.
+	 *
+	 * ★ POURQUOI le séparateur définit la section, plutôt qu'un addSection()
+	 *   explicite : le séparateur EST déjà la frontière, visuellement. Deux
+	 *   notions de découpage — l'une pour l'œil, l'autre pour la grille —
+	 *   finiraient par diverger, et il faudrait alors expliquer laquelle gagne.
+	 */
+	private sectionEl;
+	private items;
+	private hideCallbacks;
+	private shown;
+	private orientation;
+	private columns;
+	/**
+	 * L'utilisateur a-t-il posé la barre lui-même ? Une fois vrai, l'appelant
+	 * doit cesser de la recentrer : sa position devient un choix, pas un défaut.
+	 */
+	private userPlaced;
+	/** L'écart entre le pointeur et le coin de la barre, figé au début du drag. */
+	private grab;
+	/**
+	 * Le conteneur qui héberge la barre ET la borne. Passer la `contentEl` d'une
+	 * vue y enferme la toolbar ; le défaut `document.body` la laisse libre dans
+	 * la fenêtre, comme le menu.
+	 */
+	private parentEl;
+	constructor(parentEl?: HTMLElement);
+	/** Le builder central. Rend `this` — tout s'enchaîne. */
+	addItem(cb: (item: ToolbarItem) => unknown): this;
+	/** Ferme la section courante et en ouvre une neuve. */
+	addSeparator(): this;
+	/**
+	 * Le nombre de colonnes sur lequel CHAQUE section range ses items — et sur
+	 * lequel les rangées d'options (setOptions) rangent les leurs.
+	 *
+	 * ★ Ne mord qu'en mode VERTICAL. À l'horizontale, une section est une ligne :
+	 *   parler de colonnes y voudrait dire « combien d'items avant de passer à la
+	 *   ligne », c'est-à-dire l'inverse. Plutôt que d'inventer une seconde
+	 *   sémantique pour le même mot, l'horizontale ignore le réglage.
+	 *
+	 * Défaut : 2 — assez pour qu'une palette de six couleurs tienne en trois
+	 * rangs. `setColumns(1)` donne la barre la plus fine possible, au prix de la
+	 * hauteur.
+	 */
+	setColumns(columns: number): this;
+	getColumns(): number;
+	onHide(callback: () => unknown): this;
+	/**
+	 * Bascule le sens de la barre. Le clamp est rejoué dans la foulée : une barre
+	 * horizontale posée en bas de l'écran dépasserait en passant à la verticale.
+	 */
+	setOrientation(orientation: ToolbarOrientation): this;
+	toggleOrientation(): this;
+	getOrientation(): ToolbarOrientation;
+	/** L'utilisateur a-t-il déplacé la barre à la main ? (voir userPlaced) */
+	isUserPlaced(): boolean;
+	showAtPosition(x: number, y: number): this;
+	/**
+	 * Repositionne une toolbar déjà montrée — appelé quand le pane qu'elle
+	 * surplombe bouge (fenêtre redimensionnée, split). Sans effet si la toolbar
+	 * n'est pas affichée.
+	 *
+	 * `x`/`y` sont en coordonnées CLIENT : celles de `getBoundingClientRect` et
+	 * des événements pointeur, donc celles que l'appelant a déjà sous la main.
+	 * La conversion vers le repère du parent vit ICI, en un seul endroit — c'est
+	 * ce qui permet au drag comme au placement par défaut de l'ignorer.
+	 */
+	moveTo(x: number, y: number): this;
+	hide(): this;
+	onunload(): void;
+	/** Ouvre une section neuve, insérée avant la poignée si elle existe déjà. */
+	private nouvelleSection;
+	/**
+	 * Le déplacement à la poignée, et la bascule au double-clic.
+	 *
+	 * ★ POURQUOI une poignée et pas la barre entière : chaque pixel de la barre
+	 *   est un bouton. Attraper le fond pour déplacer marcherait tant qu'on vise
+	 *   entre deux items, et raterait le reste du temps. La poignée est la seule
+	 *   zone dont le geste ne peut pas être confondu avec un clic d'outil.
+	 *
+	 * Le seuil de 4px est celui de DocWidget : sans lui, un double-clic sur la
+	 * poignée (donc deux pointerdown suivis de micro-mouvements) déplacerait la
+	 * barre de deux pixels avant de la faire pivoter.
+	 *
+	 * pointercancel et lostpointercapture sont traités comme pointerup : perdre
+	 * le focus fenêtre (alt-tab, capture d'écran) ne délivre jamais de pointerup,
+	 * et la barre resterait collée au curseur — le piège documenté par
+	 * DragManager pour le drag d'onglets.
+	 */
+	private wireDrag;
+	/**
+	 * @internal — un item d'un groupe vient d'être activé : on désactive ses
+	 * pairs. C'est la toolbar qui arbitre, pas les items entre eux : un item ne
+	 * connaît que son groupe, jamais ses voisins.
+	 */
+	activateInGroup(item: ToolbarItem): void;
+}
+/**
+ * Un bouton de barre d'outils. Construit UNIQUEMENT via toolbar.addItem().
+ *
+ * Tous les setters rendent `this` : le style builder du §11.7, celui de MenuItem.
+ */
+export declare class ToolbarItem {
+	dom: HTMLElement;
+	/** Le groupe d'exclusivité ('' = aucun). Lu par Toolbar.activateInGroup. */
+	group: string;
+	private iconEl;
+	private labelEl;
+	private optionsEl;
+	private toolbar;
+	private disabled;
+	private active;
+	constructor(toolbar: Toolbar);
+	setIcon(icon: string): this;
+	setLabel(label: string): this;
+	/** L'infobulle — et le seul a11y du projet aujourd'hui (cf. ItemView.addAction). */
+	setTooltip(tooltip: string): this;
+	/**
+	 * Inscrit cet item dans un groupe exclusif : l'activer désactive ses pairs.
+	 * C'est ce qui fait des boutons crayon / surligneur / gomme un vrai choix
+	 * d'outil plutôt que trois bascules indépendantes.
+	 */
+	setGroup(group: string): this;
+	setActive(active: boolean): this;
+	isActive(): boolean;
+	setDisabled(disabled: boolean): this;
+	onClick(callback: (evt: MouseEvent) => unknown): this;
+	/**
+	 * Transforme cet item en RANGÉE D'OPTIONS — la couleur, l'épaisseur, tout
+	 * choix à faible cardinalité qui mérite d'être visible en permanence plutôt
+	 * que caché derrière un sous-menu.
+	 *
+	 * ★ POURQUOI ici et pas dans le plugin : sans ça, chaque consommateur
+	 *   réinventerait sa rangée de pastilles et la toolbar ne serait qu'un
+	 *   conteneur. Une option est un couple (valeur, aspect) ; l'aspect est une
+	 *   icône, une pastille colorée ou un disque dimensionné — assez pour couvrir
+	 *   couleur ET épaisseur sans rien coder de spécifique au dessin.
+	 */
+	setOptions(options: readonly ToolbarOption[], onPick: (value: string) => unknown): this;
+	/** Marque l'option courante d'une rangée posée par setOptions(). */
+	setValue(value: string): this;
+}
+export declare class Vault extends Events {
+	adapter: DataAdapter;
+	configDir: string;
+	root: TFolder;
+	fileMap: Map<string, TAbstractFile>;
+	private readCache;
+	private processQueue;
+	constructor(adapter: DataAdapter);
+	load(): Promise<void>;
+	/**
+	 * Un niveau de l'arbre, puis la descente.
+	 *
+	 * ★ Le commentaire qui ouvrait cette fonction disait « elle demande
+	 *   beaucoup de transactions dans l'IPC Bus si on ne fait pas gaffe ».
+	 *   Ce n'est plus vrai : l'adapter lit le disque dans CE processus (modèle
+	 *   Obsidian, cf. FileSystemAdapter.ts). `list()` et `stat()` sont des
+	 *   appels de fonction, pas des allers-retours — et c'est exactement pour
+	 *   ça que `listWithStats`, notre seul écart avec l'API d'Obsidian, a pu
+	 *   être supprimé.
+	 */
+	private buildFolder;
+	private onChange;
+	getName(): string;
+	getRoot(): TFolder;
+	getAbstractFileByPath(path: string): TAbstractFile | null;
+	/** Rend `null` si le chemin désigne un dossier — pas seulement s'il est absent. */
+	getFileByPath(path: string): TFile | null;
+	getFolderByPath(path: string): TFolder | null;
+	getAllLoadedFiles(): TAbstractFile[];
+	getFiles(): TFile[];
+	getMarkdownFiles(): TFile[];
+	getAllFolders(includeRoot?: boolean): TFolder[];
+	read(file: TFile): Promise<string>;
+	cachedRead(file: TFile): Promise<string>;
+	readBinary(file: TFile): Promise<ArrayBuffer>;
+	/**
+	 * L'adresse d'un fichier pour la plateforme (§6.1). À préférer à readBinary
+	 * partout où c'est la PLATEFORME qui consomme les octets — image, audio,
+	 * vidéo, PDF : le renderer ne les voit alors jamais passer.
+	 *
+	 * Le Vault est le seul à tenir le TFile, donc le seul à connaître le mtime :
+	 * c'est lui qui fournit le cache-buster. L'adapter, lui, décide de ce qu'il
+	 * en fait — d'où le paramètre plutôt qu'une concaténation ici.
+	 */
+	getResourcePath(file: TFile): string;
+	private refreshStat;
+	private assertCreatable;
+	create(path: string, data: string, options?: DataWriteOptions): Promise<TFile>;
+	createBinary(path: string, data: ArrayBuffer, options?: DataWriteOptions): Promise<TFile>;
+	createFolder(path: string): Promise<TFolder>;
+	modify(file: TFile, data: string, options?: DataWriteOptions): Promise<void>;
+	modifyBinary(file: TFile, data: ArrayBuffer, options?: DataWriteOptions): Promise<void>;
+	append(file: TFile, data: string, options?: DataWriteOptions): Promise<void>;
+	appendBinary(file: TFile, data: ArrayBuffer, options?: DataWriteOptions): Promise<void>;
+	process(file: TFile, fn: (data: string) => string, options?: DataWriteOptions): Promise<string>;
+	delete(file: TAbstractFile, force?: boolean): Promise<void>;
+	/**
+	 * `system: true` → corbeille de l'OS ; `false` → .trash/ du coffre.
+	 * Repli sur la corbeille locale si l'OS refuse (volume réseau, corbeille
+	 * désactivée) : mieux vaut un fichier récupérable dans .trash/ qu'un échec.
+	 */
+	trash(file: TAbstractFile, system: boolean): Promise<void>;
+	private detachAndAnnounce;
+	rename(file: TAbstractFile, newPath: string): Promise<void>;
+	copy<T extends TAbstractFile>(file: T, newPath: string): Promise<T>;
+	private parentPathOf;
+	protected addToTree(file: TAbstractFile): void;
+	protected removeFromTree(file: TAbstractFile): void;
+	protected moveInTree(file: TAbstractFile, newPath: string): void;
+	on(name: "create", callback: (file: TAbstractFile) => unknown, ctx?: unknown): EventRef;
+	on(name: "modify", callback: (file: TAbstractFile) => unknown, ctx?: unknown): EventRef;
+	on(name: "delete", callback: (file: TAbstractFile) => unknown, ctx?: unknown): EventRef;
+	on(name: "rename", callback: (file: TAbstractFile, oldPath: string) => unknown, ctx?: unknown): EventRef;
+	/**
+	 * §6.4 — le disque a bougé, AVANT toute interprétation.
+	 *
+	 * Les quatre événements ci-dessus parlent de l'arbre des fichiers : ils
+	 * portent un TFile et n'existent que pour ce que le coffre connaît.
+	 * Celui-ci parle du DISQUE : un chemin brut, y compris dans .fragment/, que
+	 * l'arbre ne contiendra jamais.
+	 *
+	 * C'est ce qui permet au HotkeyManager de voir hotkeys.json changer.
+	 */
+	on(name: "raw", callback: (path: string) => unknown, ctx?: unknown): EventRef;
+	static recurseChildren(root: TFolder, cb: (file: TAbstractFile) => void): void;
+}
+export declare class WidgetLayer {
+	private editor;
+	private overlays;
+	private widgets;
+	private offChange;
+	private offGeometry;
+	constructor(editor: DocumentSurface | null, overlays: OverlayHost);
+	addWidget(el: HTMLElement, anchor: WidgetAnchor): WidgetHandle;
+	/** Point client → coords viewport (ou null hors du pane) — pour le drop-to-spawn. */
+	clientToViewport(x: number, y: number): {
+		x: number;
+		y: number;
+	} | null;
+	/**
+	 * L'ancre DOCUMENT qui laisse l'objet EXACTEMENT où il est à l'écran.
+	 *
+	 * Le piège que ça referme : `posAtCoords` rend l'offset du caractère le plus
+	 * PROCHE, et `coordsAtPos` le coin de CE glyphe — s'ancrer avec dx/dy = 0
+	 * aimante donc sur le glyphe et fait sauter l'objet d'une hauteur de ligne.
+	 * On garde l'écart, mesuré dans le repère document des deux côtés.
+	 */
+	documentAnchorAt(clientX: number, clientY: number): WidgetAnchor | null;
+	/** Le symétrique : l'ancre VIEWPORT à la même place à l'écran. */
+	viewportAnchorAt(clientX: number, clientY: number): WidgetAnchor | null;
+	/**
+	 * L'ancre de MARGE qui garde l'objet au même NIVEAU vertical qu'à l'écran.
+	 *
+	 * Une ancre de marge ne retient qu'un `y` : le `x` et la largeur sont imposés
+	 * par la bande à chaque placement, puisqu'ils dépendent du pane. On sonde donc
+	 * le texte au MILIEU de la colonne — pas sous le widget, qui est justement à
+	 * côté du texte, voire hors de la zone rendue.
+	 */
+	gutterAnchorAt(clientY: number, side: GutterSide): WidgetAnchor | null;
+	/** Y a-t-il la place d'afficher un widget dans cette marge ? */
+	gutterFits(side: GutterSide): boolean;
+	/** L'ancrage document est-il possible ici ? (Faux sans éditeur : PDF, image…) */
+	canAnchorToDocument(): boolean;
+	destroy(): void;
+	/** Change l'ancre d'un widget monté ; bascule de plan si le plan change. */
+	private reanchor;
+	/**
+	 * Rejoue les ancres document à travers un changement de document. Sans ça,
+	 * l'offset stocké désigne un autre caractère dès la première frappe en amont
+	 * et le widget dérive.
+	 *
+	 * Texte ancré supprimé : on DÉTACHE en viewport, à la place qu'occupe le widget
+	 * à l'écran. Il ne disparaît pas et ne se téléporte pas — l'utilisateur voit ce
+	 * qu'il a détruit. (Fermer le widget serait l'autre lecture défendable ; c'est
+	 * une décision produit, isolée à ces trois lignes.) Si le widget est hors du
+	 * pane, on ne peut pas le détacher « sur place » : il garde une ancre document,
+	 * au point d'effondrement — toujours valide, jamais hors bornes.
+	 */
+	private remapAnchors;
+	private position;
+	/**
+	 * Replace les widgets document. Utile uniquement quand les COORDS DU TEXTE
+	 * changent (édition, reflux) — pas quand la mise en page se contente de
+	 * déplacer l'éditeur : le plan document vit dans le repère de `coordsAtPos`,
+	 * donc il glisse avec lui et les coords restent valables telles quelles.
+	 */
+	/**
+	 * Un widget de marge : le NIVEAU vient du texte, la COLONNE vient du pane.
+	 *
+	 * C'est tout le contrat de ce mode — et c'est pour ça que la largeur est
+	 * réécrite ici à chaque placement plutôt que laissée au widget : elle est une
+	 * conséquence de l'ancre, pas un réglage. Marge trop étroite (fenêtre
+	 * rétrécie, colonne qui remplit le pane) → on masque, plutôt que de laisser
+	 * un widget déborder sur le texte ou sortir du pane.
+	 */
+	private positionGutter;
+	private repositionTexte;
+}
+/**
+ *
+ *   WorkspaceItem (extends Events)     un nœud de l'arbre, porte un élément DOM
+ *    ├─ WorkspaceParent                peut avoir des enfants
+ *    │   ├─ WorkspaceSplit             découpe horizontale / verticale
+ *    │   │   ├─ WorkspaceRoot          la zone centrale
+ *    │   │   └─ WorkspaceSidedock      les panneaux latéraux, repliables
+ *    │   └─ WorkspaceTabs              empile des feuilles, une seule visible
+ *    └─ WorkspaceLeaf                  ★ héberge exactement une View
+ */
+export declare class Workspace extends Events {
+	app: App;
+	/** La zone centrale. */
+	rootSplit: WorkspaceRoot;
+	/** Les panneaux latéraux — c'est ici qu'ira l'explorateur de fichiers. */
+	leftSplit: WorkspaceSidedock;
+	rightSplit: WorkspaceSidedock;
+	/** §8.1 — la barre d'icônes verticale. HORS de l'arbre des splits : elle
+	 *  le borde. Son contenu vient d'app.ribbonItems (addRibbonIcon, §11.3). */
+	leftRibbon: WorkspaceRibbon;
+	/** L'élément à insérer dans le DOM de l'application. */
+	containerEl: HTMLElement;
+	activeLeaf: WorkspaceLeaf | null;
+	/** La pile qui affiche actuellement le trait d'insertion du drag, s'il y en
+	 *  a une — pour l'éteindre quand le curseur change de pile ou sort. */
+	private dropPile;
+	/**
+	 * §6.3 — le layout n'est jamais écrit dans un chemin chaud. Chaque
+	 * addChild, removeChild, resize ou changement d'onglet le « demande ».
+	 */
+	requestSaveLayout: () => void;
+	/**
+	 * §16.1 — `false` jusqu'à la fin de loadLayout(). Deux rôles distincts :
+	 * l'invariant offert aux plugins (onLayoutReady), et le garde qui interdit
+	 * d'écrire un arbre en cours de reconstruction (saveLayout).
+	 */
+	layoutReady: boolean;
+	private layoutReadyCallbacks;
+	/**
+	 * Le type de vue posé dans le panneau gauche quand aucun layout n'est
+	 * enregistré. Vide par défaut : le cœur ne connaît AUCUNE vue par son nom
+	 * (l'invariant de seedCore.ts — « compte les occurrences de 'markdown' dans
+	 * core/ : zéro »). C'est la couche d'assemblage qui le renseigne.
+	 */
+	defaultSideViewType: string;
+	constructor(app: App);
+	iterateAllLeaves(cb: (leaf: WorkspaceLeaf) => void): void;
+	/**
+	 * ★ `leaf.getViewType()` et NON `leaf.view.getViewType()` — la discipline
+	 *   du §8.4. La vue peut être une coquille différée ou un placeholder ;
+	 *   c'est la FEUILLE qui sait ce qu'elle affiche. Sans ça, un onglet
+	 *   markdown restauré mais pas encore ouvert serait invisible à tout plugin
+	 *   qui cherche ses vues.
+	 */
+	getLeavesOfType(type: string): WorkspaceLeaf[];
+	getLeavesOfFile(file: TFile): WorkspaceLeaf[];
+	/**
+	 * Rend une feuille utilisable.
+	 *
+	 * `false` → réutilise la feuille active si elle n'est pas épinglée.
+	 * `'tab'` → nouvel onglet dans la même pile.
+	 * `'split'` → nouvelle division dans le rootSplit.
+	 */
+	getLeaf(newLeaf?: boolean | PaneType): WorkspaceLeaf;
+	/** Une feuille dans le panneau latéral — pour l'explorateur, la recherche… */
+	getLeftLeaf(): WorkspaceLeaf;
+	/**
+	 * Crée une feuille dans un parent donné — le nom et la signature de l'API
+	 * Obsidian (chez eux `index` est obligatoire ; notre défaut -1 = « à la
+	 * fin », la convention d'addChild).
+	 * Public : WorkspaceTabs (bouton « + ») en a besoin, et importer
+	 * WorkspaceLeaf en valeur là-bas créerait un cycle d'imports avec
+	 * WorkspaceLeaf → WorkspaceTabs (le instanceof de setViewState).
+	 */
+	createLeafInParent(parent: WorkspaceParent, index?: number): WorkspaceLeaf;
+	/**
+	 * §8.1 — une nouvelle feuille à CÔTÉ de `leaf`, dans un split.
+	 *
+	 * `'vertical'` = à droite (une colonne de plus), `'horizontal'` = en
+	 * dessous — le vocabulaire d'Obsidian, où le split VERTICAL est celui dont
+	 * la ligne de séparation est verticale. Pas l'intuition CSS, mais c'est la
+	 * convention que les thèmes et les plugins connaissent.
+	 *
+	 * ★ Ne fait que déléguer à `WorkspaceTabs.splitLeaf`, la mécanique déjà
+	 *   éprouvée par le drag d'onglet. Même axe que le parent → pile sœur ;
+	 *   axe perpendiculaire → wrapper. Rien n'est réimplémenté ici.
+	 */
+	createLeafBySplit(leaf: WorkspaceLeaf, direction?: SplitDirection): WorkspaceLeaf | null;
+	setActiveLeaf(leaf: WorkspaceLeaf | null): void;
+	getActiveViewOfType<T>(ctor: abstract new (...args: never[]) => T): T | null;
+	/**
+	 * §11.5 — l'éditeur de TEXTE de la vue active, s'il y en a un.
+	 *
+	 * C'est ce que lit le désucrage d'`editorCallback` (CommandManager) : sans
+	 * ce getter, une commande d'éditeur n'a aucun moyen d'atteindre sa cible.
+	 *
+	 * ★ DEUX gardes structurels, et aucun `instanceof MarkdownView` :
+	 *
+	 *   1. `porteUneSurface` — toutes les vues n'ont pas de surface de document
+	 *      (l'explorateur de fichiers n'en a pas). La question porte sur ce qui
+	 *      est là, pas sur un drapeau à tenir synchrone.
+	 *   2. `isEditable` — toutes les surfaces ne s'écrivent pas : le PDF a du
+	 *      texte adressable (hasText) mais `editor:toggle-bold` n'a rien à y
+	 *      faire. C'est l'étage du dessus qu'on exige.
+	 *
+	 *   Le prix de l'`instanceof` aurait été un import de `MarkdownView` dans
+	 *   `core/`, ce que l'invariant « le cœur ne connaît aucune vue par son
+	 *   nom » interdit. Le bénéfice est le même que celui des gardes : une
+	 *   future vue textuelle héritera de toutes les commandes d'éditeur sans
+	 *   qu'une ligne de `core/` change.
+	 */
+	get activeEditor(): Editor | null;
+	/**
+	 * Pose mod-top-right-space sur LE groupe d'onglets qui touche le coin
+	 * haut-droit de la fenêtre : son header réserve la place des boutons
+	 * minimize/maximize/close (WindowControls, en overlay fixe). Les boutons
+	 * ne bougent jamais — c'est la classe qui migre avec le layout.
+	 *
+	 * Recalculé à chaque mutation de l'arbre (addChild/removeChild) et au
+	 * pli/dépli des sidedocks : la sidebar droite DÉPLIÉE touche le coin —
+	 * c'est elle qui s'écarte, pas le groupe haut-droit du root.
+	 */
+	updateFrameSpacing(): void;
+	/** Descend vers le coin haut-droit : DERNIER enfant d'un split en ligne
+	 *  (mod-vertical → flex row), PREMIER d'un split en colonne. */
+	private findTopRightTabs;
+	/**
+	 * La pile dont le rectangle contient (x, y) — hit-test géométrique sur
+	 * l'arbre, dans l'esprit de findTopRightTabs. `null` hors de toute pile.
+	 * Le walk ne considère QUE les nœuds du workspace : le fantôme de drag
+	 * (sur document.body) et les overlays n'existent pas pour lui.
+	 */
+	getTabsAtPoint(x: number, y: number): WorkspaceTabs | null;
+	/** Met à jour le trait d'insertion : la pile sous (x, y) l'affiche, l'ancienne
+	 *  l'éteint. Appelé à chaque pointermove d'un drag de feuille. */
+	showDropIndicatorAt(x: number, y: number): void;
+	/** Éteint le trait, où qu'il soit — fin du drag. */
+	clearDropIndicator(): void;
+	/**
+	 * Une pile vient de perdre son dernier onglet. Si elle est dans le root et
+	 * qu'il reste d'AUTRES panes, on la ferme ; sinon (dernier pane du root, ou
+	 * pile hors root) on rouvre un onglet vide. Le sidedock (« file bar ») ne
+	 * compte pas : countTabs ne balaie que rootSplit.
+	 */
+	onPileEmptied(pile: WorkspaceTabs): void;
+	/** Nombre de piles (WorkspaceTabs) dans un sous-arbre. */
+	private countTabs;
+	/**
+	 * Redimensionne un sidedock à la souris : on ajuste sa LARGEUR (--sidebar-
+	 * width), pas le flex-grow — un sidedock a une largeur propre, le centre
+	 * absorbe. La transition de largeur est coupée le temps du drag (classe
+	 * is-resizing) pour coller au curseur.
+	 */
+	private attachSidebarResize;
+	/** @internal — appelé par WorkspaceLeaf.detach(). */
+	onLeafDetached(leaf: WorkspaceLeaf): void;
+	/**
+	 * §8.5 — le chemin « clic sur un lien », entièrement public.
+	 * Aucune connaissance du markdown ici : on résout un chemin, on choisit une
+	 * feuille, on lui demande d'ouvrir. C'est le registre qui décide du reste.
+	 */
+	openLinkText(linktext: string, sourcePath: string, newLeaf?: boolean | PaneType): Promise<void>;
+	private rebuildPlaceholders;
+	/** Le chemin du layout dans le coffre — relocalisable avec configDir. */
+	private get layoutPath();
+	/**
+	 * §8.2 — l'arbre entier, réduit à du JSON. Le Workspace ne connaît aucune
+	 * forme de nœud : il demande à ses trois racines, chacune sait le reste.
+	 */
+	getLayout(): WorkspaceLayout;
+	/**
+	 * §6.3 — l'écriture, débouncée par requestSaveLayout.
+	 *
+	 * ★ Le garde `layoutReady` n'est pas une optimisation, c'est ce qui empêche
+	 *   la perte du layout. Pendant changeLayout(), CHAQUE addChild appelle
+	 *   requestSaveLayout() ; sans le garde, le debounce de 2 s pourrait écrire
+	 *   un arbre à moitié reconstruit par-dessus le fichier qu'on est en train
+	 *   de lire. C'est aussi lui qui écarte les lectures de géométrie faites
+	 *   pendant que l'arbre n'est pas encore posé à l'écran (voir
+	 *   WorkspaceSplit.serialize).
+	 */
+	private saveLayout;
+	/**
+	 * §16.1 — reconstruit l'arbre depuis le disque, puis déclare le layout prêt.
+	 *
+	 * Tout ce qui peut mal tourner (fichier absent, JSON tronqué, format d'une
+	 * version antérieure) tombe sur le layout par défaut : un coffre qu'on
+	 * n'arrive pas à restaurer doit s'ouvrir comme un coffre neuf, jamais
+	 * refuser de démarrer.
+	 */
+	loadLayout(): Promise<void>;
+	/**
+	 * Le layout d'un coffre neuf : l'explorateur à gauche, le premier markdown
+	 * au centre. C'est exactement ce que main.tsx câblait en dur avant que la
+	 * restauration existe — ça vit ici désormais, à un seul endroit.
+	 */
+	private defaultLayout;
+	/**
+	 * §8.2 — l'inverse de getLayout(). Vide les trois racines et les remplit.
+	 *
+	 * Synchrone, et c'est le point : aucune vue n'est construite ici. Chaque
+	 * feuille reçoit son état par setDeferredState() et reste une coquille.
+	 */
+	changeLayout(layout: WorkspaceLayout): void;
+	/**
+	 * Vide un conteneur RACINE et le remplit depuis son nœud sérialisé. Les
+	 * racines (rootSplit, leftSplit, rightSplit) sont permanentes : on ne les
+	 * recrée jamais, on remplace leur contenu et on réapplique leurs propriétés.
+	 */
+	private restoreInto;
+	/** Construit récursivement un sous-arbre. Aucune vue n'est instanciée. */
+	private buildNode;
+	/** Repose les proportions lues au save, puis délègue à reflowGeometry — le
+	 *  MÊME unique propriétaire de l'invariant que add/removeChild. Conséquence
+	 *  gratuite : un workspace.json d'avant le fix (somme < 1, ex. 0.95 sur un
+	 *  pane unique) est renormalisé au démarrage, donc plus de trou. reflowGeometry
+	 *  lit le flex-grow inline, ça marche bien que le split soit encore détaché. */
+	private applyGeometry;
+	/**
+	 * §8.4 — matérialise ce qui est réellement à l'écran dans un sous-arbre :
+	 * l'onglet courant de chaque pile, sauf sous un dock replié. Tout le reste
+	 * attend d'être regardé.
+	 *
+	 * Public parce qu'un dock qu'on DÉPLIE doit pouvoir le redemander : après
+	 * une restauration où il était replié, ses feuilles sont des coquilles, et
+	 * le clic sur le bouton de repli n'est pas un clic sur un onglet — sans ça
+	 * la sidebar s'ouvrirait sur du vide.
+	 */
+	materializeVisibleIn(racine: WorkspaceItem): Promise<void>;
+	/** L'écran entier, à la fin de la restauration. */
+	private materializeVisible;
+	/**
+	 * L'invariant du §16.1 pour les plugins : ne pas toucher au layout avant
+	 * qu'il soit prêt. La file existe parce que les plugins sont chargés AVANT
+	 * loadLayout() — leur onload() s'abonne, et le rappel part plus tard.
+	 */
+	onLayoutReady(cb: () => void): void;
+	on(name: "active-leaf-change", callback: (leaf: WorkspaceLeaf | null) => unknown, ctx?: unknown): EventRef;
+	on(name: "file-open", callback: (file: TFile | null) => unknown, ctx?: unknown): EventRef;
+	on(name: "layout-change", callback: () => unknown, ctx?: unknown): EventRef;
+	on(name: "resize", callback: () => unknown, ctx?: unknown): EventRef;
+	/** §5.3 — le listener MUTE le menu reçu. Frappe éditeur : menu, éditeur, vue. */
+	on(name: "editor-menu", callback: (menu: Menu, editor: unknown, view: View) => unknown, ctx?: unknown): EventRef;
+	/** §5.3 — clic droit sur un fichier (explorateur, onglets…). */
+	on(name: "file-menu", callback: (menu: Menu, file: TAbstractFile, source: string) => unknown, ctx?: unknown): EventRef;
+}
+export declare class WorkspaceLeaf extends WorkspaceItem {
+	parent: WorkspaceParent | null;
+	view: View;
+	private requestedState;
+	/**
+	 * Le fichier qu'on n'a PAS su ouvrir : aucune vue n'est enregistrée pour son
+	 * extension. C'est le pendant FICHIER de `requestedState` — sauf qu'ici il
+	 * n'y a aucun type à mémoriser, c'est l'extension qui est irrésolue. On
+	 * garde donc le fichier lui-même, et `rebuildView` refait la résolution.
+	 */
+	private requestedFile;
+	pinned: boolean;
+	/**
+	 * §8.4 — la feuille connaît son état mais n'a pas construit sa vue.
+	 * Posé par la restauration du layout, levé par loadIfDeferred().
+	 */
+	isDeferred: boolean;
+	/** L'état éphémère mis en attente avec le différé, s'il y en a un. */
+	private deferredEState;
+	private static compteur;
+	/**
+	 * L'identité de la feuille dans workspace.json. Stable pour la durée de vie
+	 * de l'objet, RE-POSÉE à la restauration pour que `active` continue de
+	 * désigner la bonne feuille d'une session à l'autre.
+	 */
+	id: string;
+	constructor(workspace: Workspace);
+	/**
+	 * §8.4 — pose l'état SANS construire la vue. La feuille sait tout ce qu'il
+	 * faut pour se nommer et pour se sérialiser ; elle ne paiera l'instanciation
+	 * qu'au premier regard (loadIfDeferred).
+	 *
+	 * Volontairement synchrone et sans await : c'est tout l'intérêt. Restaurer
+	 * quarante onglets ne doit rien coûter d'autre que quarante coquilles.
+	 */
+	setDeferredState(viewState: ViewState, eState?: unknown): void;
+	/**
+	 * §8.4 — matérialise, si besoin. Idempotent et sûr à appeler partout : sur
+	 * une feuille déjà chargée, c'est un no-op.
+	 */
+	loadIfDeferred(): Promise<void>;
+	setViewState(viewState: ViewState, eState?: unknown): Promise<void>;
+	/**
+	 * §8.4 — le type que la feuille VEUT afficher, pas celui qu'elle affiche.
+	 *
+	 * ★ C'est cette méthode que le cœur doit interroger, jamais
+	 *   `leaf.view.getViewType()` : la vue peut être une coquille différée ou un
+	 *   placeholder, et répondrait alors 'deferred' ou 'empty'. C'est la
+	 *   discipline que le §8.4 impose — Obsidian l'a découverte en 1.7.2, après
+	 *   coup, et l'a payée dans tout son écosystème.
+	 */
+	getViewType(): string;
+	/**
+	 * L'état sérialisable de la feuille.
+	 *
+	 * ★ Il se lit dans `requestedState`, PAS dans la vue montée. Une feuille en
+	 *   placeholder (type inconnu, extension sans lecteur) porte une EmptyView :
+	 *   interroger la vue sérialiserait `empty` et PERDRAIT ce que l'onglet
+	 *   voulait ouvrir — un plugin désactivé au moment de quitter effacerait
+	 *   silencieusement ses onglets du layout. Même raison pour une coquille
+	 *   différée, qui n'a par définition jamais rien chargé.
+	 *
+	 *   Quand la vue EST matérialisée, c'est elle qui a l'état frais (le fichier
+	 *   a pu changer par navigation depuis la restauration) : on la préfère.
+	 */
+	getViewState(): ViewState;
+	/** §8.2 — la feuille dans workspace.json. */
+	serialize(): LeafLayout;
+	/**
+	 * Rejoue la demande en cours.
+	 *
+	 * Appelé par le Workspace quand un registre change : une feuille qui
+	 * affichait un placeholder peut alors devenir la vraie vue.
+	 */
+	rebuildView(): Promise<void>;
+	/**
+	 * La feuille attend-elle un type — ou une extension — pas encore enregistré ?
+	 *
+	 * ★ `!this.isDeferred` n'est pas une précaution, c'est la condition qui fait
+	 *   marcher le §8.4. Une feuille différée satisfait les deux autres termes
+	 *   (coquille + type demandé non vide) ; sans cette exclusion,
+	 *   Workspace.rebuildPlaceholders() les matérialiserait TOUTES au premier
+	 *   'changed' du viewRegistry — c'est-à-dire au chargement du premier
+	 *   plugin, donc systématiquement, et le report ne servirait jamais à rien.
+	 */
+	isPlaceholder(): boolean;
+	/**
+	 * Ouvre un fichier — le chemin complet du §8.3 :
+	 *   extension → type de vue → fabrique → vue montée.
+	 *
+	 * ★ AUCUN REPLI. Une extension que personne n'a enregistrée donne un
+	 *   placeholder, exactement comme un type de vue inconnu : « je ne sais pas
+	 *   ouvrir ça » n'est pas une erreur, c'est l'état normal et transitoire du
+	 *   §8.3. Le jour où un plugin enregistre 'pdf', l'onglet déjà ouvert
+	 *   devient la vraie vue — sans rechargement (voir rebuildView).
+	 *
+	 *   Le repli qui vivait ici (`?? extensionRegistry.get('md')`) n'avait rien
+	 *   de neutre : il envoyait TOUT binaire dans une TextFileView, qui le lit
+	 *   en UTF-8 avec perte (TextFileView.onLoadFile) puis le RÉÉCRIT sur le
+	 *   disque en partant (onUnloadFile → save → vault.modify). Ouvrir puis
+	 *   fermer un PDF suffisait à le détruire, sans frapper une touche.
+	 */
+	openFile(file: TFile, openState?: OpenViewState): Promise<void>;
+	/** Monte une vue déjà construite (chemin direct, sans passer par le registre). */
+	open(view: View): Promise<View>;
+	/**
+	 * Ferme la vue courante. `view.close()` rejoue toute la pile de nettoyages
+	 * accumulée par Component — aucune fuite à gérer ici.
+	 *
+	 * ★ Le loadFile(null) préalable comble un trou du cycle de vie : les hooks
+	 *   onUnloadFile — et donc la SAUVEGARDE de TextFileView — ne sont déclenchés
+	 *   que par un changement de fichier, pas par la fermeture de la vue. Sans
+	 *   cette ligne, fermer un onglet dans les 2 s suivant la dernière frappe
+	 *   perdrait le texte non écrit.
+	 */
+	private detachView;
+	/** Retire la feuille de l'arbre et détruit sa vue. */
+	detach(): Promise<void>;
+	getDisplayText(): string;
+	getIcon(): string;
+	/**
+	 * Le fichier ouvert, si la feuille en héberge un.
+	 *
+	 * ★ Le repli sur `requestedState` est ce qui rend le §8.4 invisible aux
+	 *   appelants. Sans lui, une feuille différée qui tient bel et bien un
+	 *   fichier répondrait `null` : Workspace.getLeavesOfFile() ne la
+	 *   trouverait pas, et cliquer une note déjà ouverte dans un onglet non
+	 *   encore matérialisé en ouvrirait un SECOND. Le fichier est résolu au
+	 *   moment de l'usage, comme partout — le chemin vient d'un layout qui peut
+	 *   dater.
+	 */
+	get file(): TFile | null;
+	setPinned(pinned: boolean): void;
+	togglePinned(): void;
+}
+/**
+ * Les codes de sortie — stables, documentés, testables.
+ *
+ * ★ Obsidian rend 0 même en cas d'erreur (« The CLI exits 0 even on errors, so
+ *   read what it printed »). C'est le seul point de sa CLI qu'on ne copie PAS :
+ *   un script shell qui ne peut pas tester `$?` n'est pas scriptable.
+ */
+export declare const EXIT: {
+	readonly OK: 0;
+	/** Le handler a levé. La pile est dans `error`. */
+	readonly HANDLER_ERROR: 1;
+	/** `vault=` ne désigne aucune instance connue. */
+	readonly UNKNOWN_VAULT: 2;
+	/** Sous-commande inconnue du serveur. */
+	readonly UNKNOWN_SUBCOMMAND: 4;
+	/** Pas d'instance qui tourne, et impossible d'en lancer une. */
+	readonly NO_INSTANCE: 5;
+	/** Plusieurs instances, et pas de `vault=` pour choisir. */
+	readonly AMBIGUOUS_VAULT: 6;
+	/** `command id=` désigne une commande qui n'existe pas dans le registre. */
+	readonly UNKNOWN_COMMAND: 7;
+	/** `command id=` désigne une commande connue mais INDISPONIBLE ici (p.ex. aucun éditeur actif). */
+	readonly UNAVAILABLE: 8;
+	/** Ligne de commande mal formée. */
+	readonly USAGE: 64;
+	/** Le serveur n'a pas répondu à temps — convention de GNU timeout. */
+	readonly TIMEOUT: 124;
+	/** La fenêtre a disparu pendant la requête. */
+	readonly RENDERER_GONE: 125;
+	/** Jeton absent ou faux. */
+	readonly REFUSED: 126;
+};
+/** L'OS courant, façon Obsidian : des booléens plutôt qu'une énumération. */
+export declare const Platform: {
+	/** Fragment ne tourne que sur bureau. */
+	isDesktop: boolean;
+	isMobile: boolean;
+	isDesktopApp: boolean;
+	isMobileApp: boolean;
+	isMacOS: boolean;
+	isWin: boolean;
+	isLinux: boolean;
+	isIosApp: boolean;
+	isAndroidApp: boolean;
+};
+/**
+ * @param cb        la fonction à retarder
+ * @param timeout   délai en ms
+ * @param resetTimer si `true`, chaque appel REPART du délai complet (« attendre
+ *                   que ça se calme ») ; si `false`, le premier appel arme le
+ *                   minuteur et les suivants ne le repoussent pas (« au plus une
+ *                   fois par fenêtre »). La frappe clavier veut `true`.
+ */
+export declare function debounce<TArgs extends unknown[]>(cb: (...args: TArgs) => unknown, timeout?: number, resetTimer?: boolean): Debouncer<TArgs>;
+/**
+ * @returns une fonction qui, pour un texte, rend son score et ses plages — ou
+ *          `null` si la requête n'y est pas. Une requête vide matche TOUT, avec
+ *          un score nul et aucune plage : c'est ce qu'une palette affiche avant
+ *          la première frappe.
+ */
+export declare function prepareFuzzySearch(query: string): (text: string) => SearchResult | null;
+/**
+ * Rend `text` dans `el`, en enveloppant chaque plage matchée d'un
+ * `<span class="suggestion-highlight">` — la classe d'Obsidian, donc celle
+ * que les thèmes stylent.
+ *
+ * @param offset décalage à soustraire aux plages : utile quand `text` est une
+ *               SOUS-CHAÎNE du texte qui a été cherché (la palette découpe
+ *               « Plugin: Commande » en deux spans mais cherche sur le tout).
+ */
+export declare function renderMatches(el: HTMLElement, text: string, matches: SearchMatches | null, offset?: number): void;
+/**
+ * Pose une icône dans un élément (§12.6). Signature d'Obsidian : `setIcon(el,
+ * icon)` (A31) — le registre n'est plus passé en paramètre.
+ *
+ * TROIS COUCHES, interrogées dans l'ordre :
+ *
+ *   1. app.icons — le registre, atteint via `window.app` (posé au boot). Lu AU
+ *      MOMENT DE L'USAGE : un plugin peut AJOUTER une icône à lui… ou ÉCRASER
+ *      une icône des couches du dessous, puisque le registre passe avant.
+ *      ★ Lu DÉFENSIVEMENT : la fenêtre de gestion des coffres n'a pas d'App —
+ *      elle doit pouvoir poser une icône Lucide sans planter, elle n'a
+ *      simplement pas la couche custom (aucun plugin n'y tourne).
+ *   2. les icônes internes — celles qu'Obsidian a en propre, hors Lucide.
+ *   3. le jeu Lucide embarqué — la couche de base, ~1500 icônes, aucune
+ *      inscription nécessaire.
+ *
+ * Nom introuvable partout → point médian discret, pas d'erreur :
+ * l'absence est un état normal, même philosophie que les vues (§8.3).
+ */
+export declare function setIcon(el: HTMLElement, name: string): void;
+/** Une entrée du registre `app.cliHandlers`. */
+export interface CliHandlerSpec {
+	/** L'id complet : `help`, `commands`, ou `templater:create-from-template`. */
+	command: string;
+	description: string;
+	flags: CliFlags;
+	handler: CliHandler;
+}
+/**
+ * Les capacités CLI que le processus principal fournit au renderer. Injecté au
+ * boot ; jamais construit par le cœur (qui n'a pas le droit de toucher
+ * `window.electron`).
+ */
+export interface CliHost {
+	/**
+	 * Évalue `code` hors CSP et rend sa valeur de complétion sérialisée. Rend un
+	 * `CliResult` (A21) : `code` = EXIT.TIMEOUT si l'éval a dépassé `timeoutMs`,
+	 * EXIT.HANDLER_ERROR sinon — le même vocabulaire que toute la CLI.
+	 */
+	eval(code: string, timeoutMs: number): Promise<CliResult>;
+	/** Écrit le shim `fragment` et le met sur le PATH. */
+	installShim(): Promise<CliInstallResult>;
+}
+/** Le résultat d'`installShim` — seul le message intéresse l'appelant. */
+export interface CliInstallResult {
+	message: string;
+}
+/**
+ * Une commande.
+ * Dans chaque commande il y a 2 possibilités :
+ * Soit on écrit un callback : lui il est tout le temps disponible
+ * Soit on écrit un checkCallback : lui il prend un bool en entrée.
+ * Dans tous les cas il va checker d'abord s'il peut s'appliquer (supprimer la node active par exemple)
+ * puis selon le bool d'entrée, il va tester si il s'applique.
+ *
+ * Les quatre callbacks se recouvrent, du plus général au plus spécifique, et
+ * chacun ÉCRASE les précédents :
+ *
+ *     callback  <  checkCallback  <  editorCallback  <  editorCheckCallback
+ *
+ * En pratique on n'en écrit qu'un. Les deux variantes `editor*` sont désucrées
+ * en `checkCallback` par CommandManager.addCommand — il n'existe donc qu'UNE
+ * seule branche d'exécution dans toute l'app.
+ */
+export interface Command {
+	id: string;
+	name: string;
+	/** Nom d'icône Lucide, pour la palette et les barres d'outils. */
+	icon?: string;
+	/**
+	 * Maintenir le raccourci re-déclenche-t-il la commande ? Lu uniquement au
+	 * dispatch clavier (phase B) ; sans effet ailleurs.
+	 */
+	repeatable?: boolean;
+	/**
+	 * Commande réservée au mobile. Fragment est desktop-only : une commande
+	 * ainsi marquée n'est PAS enregistrée du tout. Le champ existe pour qu'un
+	 * plugin écrit contre l'API mobile reste typé.
+	 */
+	mobileOnly?: boolean;
+	/** Le cas simple : déclenchable partout, toujours disponible. */
+	callback?: () => unknown;
+	/**
+	 * Le micro-pattern §11.5 : un seul appel fusionne « est-elle disponible ? »
+	 * (checking = true, SANS effet de bord) et « exécute-la » (checking = false).
+	 *
+	 * ★ `checking = true` n'est appelé qu'au listage — donc à chaque ouverture
+	 *   de palette, sur chaque commande enregistrée. Il doit rester bon marché.
+	 */
+	checkCallback?: (checking: boolean) => boolean | void;
+	/**
+	 * Ne se déclenche que lorsqu'un éditeur de texte a le focus, et reçoit cet
+	 * éditeur ainsi que la vue qui l'héberge.
+	 *
+	 * ★ Obsidian passe ici un `MarkdownView | MarkdownFileInfo`, parce que chez
+	 *   lui un éditeur peut vivre HORS d'une vue (nœud texte de Canvas).
+	 *   Fragment n'a pas ce cas : on passe la `View`. Le jour où il apparaît, ce
+	 *   type s'élargit sans casser personne.
+	 */
+	editorCallback?: (editor: Editor, ctx: View) => unknown;
+	/** La variante `checking` de la précédente. Écrase toutes les autres. */
+	editorCheckCallback?: (checking: boolean, editor: Editor, ctx: View) => boolean | void;
+	/**
+	 * Raccourci par défaut. Lu par le HotkeyManager (phase B).
+	 *
+	 * Un plugin devrait s'abstenir d'en poser : l'espace des combinaisons est
+	 * une ressource partagée, et une personnalisation de l'utilisateur ne
+	 * « corrige » pas un conflit, elle le déplace.
+	 */
+	hotkeys?: Hotkey[];
+	/**
+	 * Dormant. Autoriserait la commande en mode lecture — qui n'existe pas
+	 * encore (postProcessors n'a aucun consommateur). Déclaré pour la
+	 * compatibilité de typage, sans garde correspondante : on n'écrit pas de
+	 * fausse protection autour d'un mode qui n'existe pas.
+	 */
+	allowPreview?: boolean;
+	/** Dormant. Voir allowPreview — l'éditeur de propriétés n'existe pas (§7.6). */
+	allowProperties?: boolean;
+	/** Dormant. Barre d'outils mobile ; Fragment est desktop-only. */
+	showOnMobileToolbar?: boolean;
+}
+export interface DataAdapter {
+	getName(): string;
+	exists(path: string): Promise<boolean>;
+	stat(path: string): Promise<Stat | null>;
+	list(path: string): Promise<ListedFiles>;
+	read(path: string): Promise<string>;
+	readBinary(path: string): Promise<ArrayBuffer>;
+	write(path: string, data: string, options?: DataWriteOptions): Promise<void>;
+	writeBinary(path: string, data: ArrayBuffer, options?: DataWriteOptions): Promise<void>;
+	append(path: string, data: string, options?: DataWriteOptions): Promise<void>;
+	appendBinary(path: string, data: ArrayBuffer, options?: DataWriteOptions): Promise<void>;
+	mkdir(path: string): Promise<void>;
+	rename(path: string, newPath: string): Promise<void>;
+	copy(path: string, newPath: string): Promise<void>;
+	remove(path: string): Promise<void>;
+	rmdir(path: string, recursive: boolean): Promise<void>;
+	trashSystem(path: string): Promise<boolean>;
+	trashLocal(path: string): Promise<void>;
+	/**
+	 * Une URL que la PLATEFORME sait aller chercher toute seule — <img src>,
+	 * <video>, fetch, pdf.js. C'est l'inverse de readBinary : là où celui-ci
+	 * fait TRANSPORTER les octets par le renderer (IPC → structured clone →
+	 * ArrayBuffer dans le tas JS), ici on ne rend qu'une adresse, et Chromium
+	 * lit le fichier lui-même, en streaming, hors du thread JS.
+	 *
+	 * Synchrone, comme chez Obsidian : c'est ce qui permet de l'appeler dans un
+	 * rendu. Donc aucun aller-retour IPC ici — l'implémentation n'a le droit
+	 * que de fabriquer une chaîne.
+	 *
+	 * `cacheKey` est HORS API Obsidian — même justification que listWithStats.
+	 * Sans cache-buster, Chromium sert indéfiniment la version qu'il a mise en
+	 * cache et une image modifiée sur le disque ne se rafraîchit jamais à
+	 * l'écran. Obsidian le résout en concaténant le mtime côté Vault ; on le
+	 * passe explicitement, parce que la forme de l'URL appartient à l'adapter
+	 * (le Bridge du §6.1) : un adapter navigateur rendrait un blob:, où le
+	 * suffixe « ?mtime » n'aurait aucun sens. En le laissant facultatif, la
+	 * signature d'Obsidian reste appelable telle quelle.
+	 */
+	getResourcePath(path: string, cacheKey?: string | number): string;
+	onChange: ((type: "create" | "modify" | "delete", path: string) => void) | null;
+}
+/*
+ * ── Ce qui a été retiré ici, et pourquoi c'est une bonne nouvelle ────────
+ *
+ * `ListedEntry` et `ListedFilesWithStats` vivaient à cet endroit. Ils
+ * n'existaient QUE pour amortir la frontière IPC : ramener les stat avec le
+ * listing faisait passer la construction de l'arbre de D+F allers-retours à D.
+ * C'était notre seul écart de forme avec l'API d'Obsidian, et il était justifié
+ * par une contrainte que nous n'avons plus.
+ *
+ * Depuis que le coffre est lu par `fs` dans le renderer, un `stat` coûte un
+ * appel de fonction. La béquille n'a plus d'objet, et `ListedFiles` — mot pour
+ * mot celle d'obsidian.d.ts — redevient la seule forme de listing.
+ */
+export interface DataWriteOptions {
+	ctime?: number;
+	mtime?: number;
+}
+/**
+ * L'utilitaire de coalescence (§6.3, §7.5).
+ *
+ * Le PDF insiste : « chaque frontière de sous-système a sa politique de
+ * coalescence explicite ». requestSave d'un éditeur, requestSaveLayout du
+ * workspace, requestSaveConfig des réglages — tous passent par ici. La règle
+ * qui les gouverne : on n'écrit jamais le disque dans un chemin chaud, on le
+ * « demande ».
+ */
+export interface Debouncer<TArgs extends unknown[]> {
+	(...args: TArgs): void;
+	/** Exécute immédiatement si un appel est en attente, et annule le minuteur. */
+	run(): void;
+	/** Annule l'appel en attente sans l'exécuter. */
+	cancel(): void;
+}
+/**
+ * LE SOCLE — ce dont les layers vivent réellement, et RIEN de plus.
+ *
+ * ★ POURQUOI cette interface existe séparément d'`Editor` : parce que « document
+ *   affichable » et « éditeur de texte » ne sont pas la même chose. Une vue PDF
+ *   a une géométrie, une virtualisation et des surfaces de markers, mais peut
+ *   n'avoir aucun texte adressable (un scan est une suite d'images). Tout ce que
+ *   consomment `WidgetLayer`, `posVisibility`, les markers et la saisie de
+ *   dessin est ICI ; aucun d'eux n'a jamais appelé `getLine`.
+ *
+ *   Le dire dans les types, c'est le faire vérifier par le compilateur plutôt
+ *   que par la discipline. `LayerContext.editor` est donc un `DocumentSurface` :
+ *   un layer ne PEUT pas dépendre d'un texte qui n'existera pas forcément.
+ *
+ *   Une surface qui a du texte se reconnaît par le garde `hasText()` ci-dessous,
+ *   qui rétrécit le type — pas par un drapeau à tenir synchrone.
+ *
+ * Les coordonnées sont DOCUMENT-relatives (cf. `Rect`), sauf `posAtCoords`.
+ */
+export interface DocumentSurface {
+	coordsAtPos(offset: number): Rect | null;
+	/** Coords CLIENT (issues d'un événement pointeur) → offset. Pour la saisie. */
+	posAtCoords(x: number, y: number): number | null;
+	/**
+	 * La fenêtre de VIRTUALISATION : ce que l'éditeur a monté. Elle inclut ce qui
+	 * est masqué (replié) — un offset peut y être sans être dessiné.
+	 */
+	viewportRange(): EditorRange;
+	/**
+	 * Les portions RÉELLEMENT dessinées : le viewport, MOINS ce qui est masqué.
+	 * Une plage repliée y laisse un TROU.
+	 *
+	 * ★ POURQUOI c'est distinct de `viewportRange` — et pourquoi les deux sont
+	 *   nécessaires. « Pas visible » recouvre deux situations qui appellent des
+	 *   réactions OPPOSÉES :
+	 *
+	 *     - hors viewport (virtualisation) : l'objet existe, il est juste hors
+	 *       écran. Il faut GARDER sa dernière position — recalculer depuis le
+	 *       heightmap a été mesuré pire (cf. §8.4 du doc d'ancrage).
+	 *     - dans un trou (replié) : le contenu est CACHÉ. Il faut MASQUER
+	 *       l'objet. Le repositionner est un contresens : `coordsAtPos` répond
+	 *       quand même, en rendant le point dessiné le plus proche — donc le
+	 *       placeholder du repli. Toutes les annotations d'un bloc replié
+	 *       s'empilaient ainsi sur son titre.
+	 *
+	 *   Un seul membre ne pouvait pas distinguer les deux, d'où l'ajout.
+	 *
+	 * ⚠️ Un trou ne dit PAS « replié par l'utilisateur », il dit « non dessiné ».
+	 *    Chez CM6 la virtualisation horizontale des lignes très longues (line
+	 *    gaps) en produit aussi. Pour décider de masquer c'est équivalent — dans
+	 *    les deux cas les coordonnées seraient fausses. Distinguer les deux
+	 *    causes exigerait de connaître l'extension de repli, donc de perdre la
+	 *    portabilité de la façade : on ne le fait pas.
+	 */
+	renderedRanges(): readonly EditorRange[];
+	addLayer(spec: LayerSurfaceSpec): () => void;
+	/** Force un recalcul des layers — le "poke" quand une donnée EXTERNE change. */
+	requestUpdate(): void;
+	onChange(cb: (change: EditorChange) => void): () => void;
+	readonly contentEl: HTMLElement;
+	readonly scrollEl: HTMLElement;
+	readonly cm: unknown;
+}
+/**
+ * Le contrat d'un éditeur : une surface textuelle QUI S'ÉCRIT.
+ *
+ * ★ POURQUOI un troisième étage. Le PDF a du texte adressable — on y
+ *   sélectionne, on y mesure des plages, les layers s'y ancrent — mais il ne
+ *   s'édite pas. Le mettre au même étage que CodeMirror aurait forcé un choix
+ *   entre deux mensonges : des méthodes d'écriture qui ne font rien, ou
+ *   « Mettre en gras » proposé dans la palette sur un PDF.
+ *
+ *   Trois étages, trois questions, trois gardes :
+ *
+ *     DocumentSurface   « y a-t-il une géométrie ? »    (toute vue à layers)
+ *     TextSurface       « y a-t-il du texte ? »         hasText()
+ *     Editor            « puis-je l'écrire ? »          isEditable()
+ *
+ *   C'est `Editor` — et lui seul — que les commandes `editor:*` reçoivent.
+ *   Même sens que chez Obsidian : un Editor, c'est ce qu'on édite.
+ */
+export interface Editor extends TextSurface {
+	getValue(): string;
+	getRange(from: number, to: number): string;
+	/** LA primitive d'écriture. Tout le reste est du sucre par-dessus. */
+	transaction(spec: EditorTransactionSpec): void;
+	/** Sucre : `transaction({ changes: [{ from, to, insert }] })`. */
+	replaceRange(from: number, to: number, text: string): void;
+	/** Sucre : `transaction({ selection: { anchor, head } })`. */
+	setSelection(anchor: number, head?: number): void;
+	focus(): void;
+	hasFocus(): boolean;
+}
+/** Ce qui a bougé dans l'éditeur. `origin` est libre (ex. le poke de données externes). */
+export interface EditorChange {
+	docChanged: boolean;
+	selectionChanged: boolean;
+	viewportChanged: boolean;
+	/**
+	 * Remappe un offset de l'ANCIEN document vers le NOUVEAU.
+	 *
+	 * C'est LA pièce sans laquelle rien ne peut être ancré au texte : un offset
+	 * brut désigne un caractère différent dès qu'on édite au-dessus de lui. Tout
+	 * ce qui garde une position entre deux changements DOIT passer par ici.
+	 *
+	 * `assoc` dit de quel côté la position colle : `1` (défaut) = au caractère qui
+	 * SUIT — une insertion pile sur l'ancre pousse l'ancre avec son texte ; `-1` =
+	 * au caractère qui précède (l'ancre reste avant l'insertion).
+	 *
+	 * Identité quand `docChanged` est faux.
+	 */
+	mapPos(pos: number, assoc?: -1 | 1): MappedPos;
+	origin?: string;
+}
+/** Un changement : remplace `[from, to)` par `insert`. `to` absent = insertion. */
+export interface EditorChangeSpec {
+	from: number;
+	to?: number;
+	insert: string;
+}
+/** Une position ligne/colonne (0-indexée), comme l'`Editor` d'Obsidian. */
+export interface EditorPosition {
+	line: number;
+	ch: number;
+}
+/** Une plage d'offsets absolus dans le document. */
+export interface EditorRange {
+	from: number;
+	to: number;
+}
+/**
+ * Ce qu'une commande d'éditeur PRODUIT — et ce que `Editor.transaction` applique.
+ *
+ * ★ Les `changes` sont TOUS exprimés dans le document d'avant la transaction ;
+ *   c'est le moteur qui les compose. Une commande n'a donc jamais à recalculer
+ *   ses offsets après son propre premier changement — c'est ce qui rend
+ *   « un titre sur chaque ligne sélectionnée » écrivable en une passe.
+ *
+ * ★ La `selection`, elle, est dans le document d'APRÈS : c'est là que le
+ *   curseur atterrira.
+ */
+export interface EditorTransactionSpec {
+	changes?: EditorChangeSpec[];
+	selection?: {
+		anchor: number;
+		head?: number;
+	};
+	/** Amène la sélection à l'écran. */
+	scrollIntoView?: boolean;
+}
+export interface FileStats {
+	ctime: number;
+	mtime: number;
+	size: number;
+}
+/** Ce que rend une FuzzySuggestModal : l'élément et son match. */
+export interface FuzzyMatch<T> {
+	item: T;
+	match: SearchResult;
+}
+/** Une combinaison. `key` est la valeur logique (`KeyboardEvent.key`) : 'P', 'F2', 'ArrowUp'. */
+export interface Hotkey {
+	modifiers: Modifier[];
+	key: string;
+}
+/**
+ * Vue structurelle commune à Registry et OrderedRegistry, pour l'inspecteur d'UI.
+ * Aucune des deux classes ne déclare l'implémenter — le typage structurel suffit.
+ */
+export interface InspectableRegistry {
+	name: string;
+	label: string;
+	readonly size: number;
+	entries(): Array<{
+		key: string;
+		value: unknown;
+		owner: string;
+	}>;
+}
+export interface Instruction {
+	/** La touche, telle qu'affichée : '↑↓', '↵', 'esc'. */
+	command: string;
+	purpose: string;
+}
+/**
+ * Ce que le Keymap a déduit de la frappe, et qu'il passe aux handlers.
+ *
+ * ★ DEUX représentations de la touche, et il faut les deux :
+ *
+ *   - `key`  est la valeur LOGIQUE — ce que la disposition clavier produit.
+ *            Sur un AZERTY, la touche à droite de « L » donne `'m'`.
+ *   - `vkey` est la valeur PHYSIQUE (`KeyboardEvent.code`) — l'emplacement.
+ *            La même touche donne `'Semicolon'`, parce que c'est là qu'est le
+ *            point-virgule sur un QWERTY.
+ *
+ *   Un raccourci enregistré sur `key` suit la disposition ; enregistré sur
+ *   `vkey`, il suit l'emplacement physique. `isMatch` accepte les deux, ce qui
+ *   permet à un raccourci de survivre à un changement de disposition sans que
+ *   l'auteur ait à choisir.
+ */
+export interface KeymapContext {
+	/** Forme canonique compilée : trié, joint par virgules. `"Ctrl,Shift"`. */
+	modifiers: string;
+	key: string;
+	vkey: string;
+}
+/** Une liaison enregistrée dans un Scope. `null` vaut « n'importe lequel ». */
+export interface KeymapEventHandler {
+	modifiers: string | null;
+	key: string | null;
+	func: KeymapEventListener;
+}
+export interface LayerContext {
+	/**
+	 * La surface de document de la vue, ou `null` si elle n'en a pas. Un layer qui
+	 * veut ancrer au document doit gérer le cas null : sans surface, seuls les
+	 * overlays viewport (fixes à l'écran) sont possibles.
+	 *
+	 * ★ C'est un `DocumentSurface`, PAS un `Editor` : un layer n'a jamais eu besoin
+	 *   des membres textuels, et toutes les vues n'en ont pas (un PDF scanné n'a
+	 *   aucun texte). Le garde `hasText()` ouvre la moitié textuelle quand elle
+	 *   existe — et le compilateur l'interdit partout ailleurs.
+	 */
+	editor: DocumentSurface | null;
+	view: View;
+	file: TFile | null;
+	app: App;
+	/** Points de montage d'overlay view-level (viewport toujours ; document si éditeur). */
+	overlays: OverlayHost;
+}
+/**
+ * La déclaration d'un layer (fiche de catalogue), contribuée par un plugin.
+ * Un layer n'est PAS un Component : `create` monte la contribution sur un éditeur
+ * et rend un disposer ; c'est le plugin (Component) qui possède les ressources
+ * partagées entre éditeurs (réseau/CRDT).
+ */
+export interface LayerSpec {
+	/** Clef unique dans le catalogue — identité de réconciliation. */
+	id: string;
+	/** Libellé pour le switcher. */
+	name: string;
+	icon?: string;
+	/** Activé d'office à l'ouverture d'une vue applicable ? (défaut : non). */
+	defaultEnabled?: boolean;
+	/** Le layer concerne-t-il cette vue ? (défaut : toute vue éditrice). */
+	appliesTo?(view: View): boolean;
+	/** Monte le layer sur l'éditeur d'une vue ; rend le disposer. */
+	create(ctx: LayerContext): () => void;
+}
+/**
+ * Ce qu'un layer contribue, façon `layer()` de CM6 :
+ *   - `above`   : devant (true) ou derrière (false) le texte.
+ *   - `markers` : recalculé au reflux ; ne calculer que sur `renderedRanges()`
+ *                 (pas `viewportRange()` : ce qui est replié ne doit rien rendre).
+ *   - `update`  : faut-il recalculer sur ce changement ? (défaut : sur docChanged).
+ *                 Le reflux de scroll/géométrie est géré tout seul par l'impl.
+ */
+export interface LayerSurfaceSpec {
+	above: boolean;
+	markers(surface: DocumentSurface): readonly Marker[];
+	update?(change: EditorChange): boolean;
+}
+/**
+ * §8.2 — la forme SÉRIALISÉE de l'arbre de fenêtrage, telle qu'elle atterrit
+ * dans `.fragment/workspace.json`.
+ *
+ * Trois formes de nœud, une par classe du Composite. Aucune référence d'objet,
+ * aucun état éphémère : ce fichier doit se relire après un redémarrage, et
+ * c'est tout ce qu'il doit savoir faire. Le défilement et la sélection vivent
+ * dans getEphemeralState() et n'entrent JAMAIS ici — c'est la définition même
+ * de la dualité du §8.2.
+ */
+/** La part de flex-grow d'un nœud dans son split parent. Posée par le PARENT. */
+export interface LayoutDimension {
+	dimension?: number;
+}
+export interface LeafLayout extends LayoutDimension {
+	type: "leaf";
+	id: string;
+	state: ViewState;
+}
+/**
+ * Ce qui doit correspondre pour qu'une liaison se déclenche. `null` = indifférent.
+ * Volontairement structurel : un `KeymapEventHandler` comme une liaison compilée
+ * du HotkeyManager satisfont tous les deux cette forme.
+ */
+export interface Liaison {
+	modifiers: string | null;
+	key: string | null;
+}
+/** Conforme à `ListedFiles` d'obsidian.d.ts — ne pas modifier. */
+export interface ListedFiles {
+	files: string[];
+	folders: string[];
+}
+/**
+ * Le résultat d'un remappage de position. Les deux questions sont séparées à
+ * dessein : « où est-ce maintenant ? » a TOUJOURS une réponse valide (sinon
+ * l'appelant garderait un offset hors bornes, qui explose au premier usage),
+ * « le texte a-t-il été supprimé ? » est une information EN PLUS, dont chacun
+ * fait ce qu'il veut.
+ */
+export interface MappedPos {
+	/** La position dans le NOUVEAU document — toujours dans les bornes. */
+	pos: number;
+	/** Le texte ancré a-t-il disparu ? `pos` est alors le point d'effondrement. */
+	deleted: boolean;
+}
+/**
+ * Un marker — l'atome visuel, à la sémantique de `LayerMarker` de CM6 :
+ *   - `eq`     : deux markers identiques → on réutilise le DOM (pas de redraw).
+ *   - `draw`   : rend l'élément (avatar `<img>`, rectangle, trait `<svg>`…).
+ *              L'élément doit se POSITIONNER lui-même (position: absolute + coords
+ *              document-relatives, cf. `Rect`).
+ *   - `update` : met à jour un DOM existant en place ; `false` → CM redessine.
+ */
+export interface Marker {
+	eq(other: Marker): boolean;
+	draw(): HTMLElement;
+	update?(dom: HTMLElement, old: Marker): boolean;
+}
+/**
+ * Les options d'une ouverture. `eState` porte l'état ÉPHÉMÈRE (§8.2) —
+ * défilement, sélection, ligne à atteindre : ce qui survit à la navigation mais
+ * n'a rien à faire dans un fichier de layout.
+ */
+export interface OpenViewState {
+	state?: Record<string, unknown>;
+	eState?: Record<string, unknown>;
+	active?: boolean;
+}
+/**
+ * Ce que la vue offre aux layers pour poser des overlays, SANS exposer son DOM :
+ * on monte un élément dans un plan, on récupère le retrait. Le layer POSITIONNE
+ * lui-même l'élément (left/top) ; le host garantit seulement l'origine du plan :
+ *   - 'viewport' : coin du pane, NE scrolle pas (objets fixes à l'écran) ;
+ *   - 'document' : le repère de `coordsAtPos` lui-même — un élément posé aux
+ *     coords rendues par l'éditeur y atterrit juste, et suit le texte au scroll
+ *     comme à la remise en page, sans que personne n'ait à resynchroniser quoi
+ *     que ce soit.
+ * Un layer ne peut ni restructurer les plans ni toucher les widgets d'un autre.
+ */
+export interface OverlayHost {
+	mount(el: HTMLElement, plane: OverlayPlane): () => void;
+	/**
+	 * Convertit un point CLIENT en coordonnées du plan viewport, ou `null` si le
+	 * point est HORS du pane. Sert de hit-test (est-ce que ce drop me concerne ?)
+	 * ET de conversion, sans exposer le DOM.
+	 */
+	clientToViewport(x: number, y: number): {
+		x: number;
+		y: number;
+	} | null;
+	/**
+	 * Le symétrique pour le plan 'document' : un point CLIENT → le repère de
+	 * `coordsAtPos`. C'est ce qui permet d'ancrer au texte SANS déplacer ce qu'on
+	 * ancre : on compare la position voulue et celle du glyphe dans le même
+	 * repère, et on garde l'écart. `null` sans plan document (vue sans éditeur).
+	 */
+	clientToDocument(x: number, y: number): {
+		x: number;
+		y: number;
+	} | null;
+	/**
+	 * La bande de MARGE disponible d'un côté du texte, en coordonnées du plan
+	 * document — c'est-à-dire prête à être posée telle quelle sur un widget.
+	 *
+	 * C'est l'espace entre le bord du pane et le bord de la colonne de lecture.
+	 * Il dépend de la largeur du PANE, pas du document : c'est la seule géométrie
+	 * des plans qu'un widget ne peut pas déduire de l'éditeur, d'où sa présence
+	 * ici. `width` peut être négatif ou nul quand la colonne remplit le pane —
+	 * l'appelant décide alors quoi faire (typiquement : masquer).
+	 */
+	gutterBand(side: GutterSide): {
+		left: number;
+		width: number;
+	} | null;
+	/**
+	 * Prévient quand la géométrie des plans change (pane ou colonne redimensionnés).
+	 *
+	 * ⚠️ À n'utiliser QUE pour ce qui dépend vraiment de la taille des plans — les
+	 * marges. La position d'un widget ancré au texte, elle, n'en dépend pas : le
+	 * plan document vit dans le repère de `coordsAtPos`, donc il glisse avec lui
+	 * (§2 du doc). S'abonner ici « au cas où » ferait revenir la valeur dérivée
+	 * qu'on a supprimée.
+	 */
+	onGeometryChange(cb: () => void): () => void;
+}
+/** §11.1 — le manifest.json d'un plugin. */
+export interface PluginManifest {
+	id: string;
+	name: string;
+	version: string;
+	minAppVersion?: string;
+	description?: string;
+	author?: string;
+}
+/**
+ * Un rectangle, MÊME shape que le `Rect` de CM6 (choix délibéré : re-export sans
+ * conversion côté CmEditor).
+ *
+ * ★ Système de coordonnées : DOCUMENT-relatif — l'origine est le coin haut-gauche
+ *   du contenu, pas la fenêtre. C'est le repère dans lequel vivent les markers
+ *   d'un `addLayer` ; un marker positionné avec ces coordonnées atterrit donc au
+ *   bon endroit et suit le défilement gratuitement.
+ */
+export interface Rect {
+	left: number;
+	top: number;
+	right: number;
+	bottom: number;
+}
+/**
+ * §11.3 — une icône du ribbon (addRibbonIcon). `buttonEl` est posé par
+ * WorkspaceRibbon au premier rendu et JAMAIS recréé : c'est la référence que
+ * addRibbonIcon rend au plugin — elle doit rester l'élément vivant.
+ */
+export interface RibbonItem {
+	icon: string;
+	title: string;
+	callback: (evt: MouseEvent) => unknown;
+	buttonEl?: HTMLElement;
+}
+export interface SearchResult {
+	score: number;
+	matches: SearchMatches;
+}
+export interface SplitLayout extends LayoutDimension {
+	type: "split";
+	direction: SplitDirection;
+	children: LayoutNode[];
+	/** Sidedocks seulement. */
+	collapsed?: boolean;
+	/** Sidedocks seulement — la valeur de --sidebar-width, en px. */
+	width?: number;
+}
+// ═══════════════════════════════════════════════════════════════════════════
+//  Ce fichier est AMBIANT (chargé via "types": ["./types"]) : tout ce qu'il
+//  déclare est global, sans import. Conséquence : PAS d'`import … from` en tête
+//  — la moindre ligne de ce genre en ferait un module et ferait disparaître la
+//  portée globale de tout le reste.
+//
+//  Pour réutiliser quand même les types du coffre, on passe par l'import EN
+//  POSITION DE TYPE : `import('chemin').Type`. C'est la seule forme autorisée
+//  ici, et elle n'affecte pas la nature globale du fichier.
+// ═══════════════════════════════════════════════════════════════════════════
+// ─── Stat vs FileStats : deux types voisins, à ne pas confondre ─────────────
+// Obsidian les distingue, et la raison est bonne.
+//
+//   Stat      — niveau ADAPTER/disque. Rendu par adapter.stat(chemin). Il PORTE
+//               un discriminant `type`, parce qu'à ce niveau on n'a qu'un
+//               chemin : rien ne dit si c'est un fichier ou un dossier.
+//   FileStats — niveau OBJET du Vault. C'est le champ TFile.stat. PAS de `type`,
+//               parce qu'être un TFile le dit déjà. Le discriminant serait
+//               redondant, et donc une occasion de mentir.
+export interface Stat {
+	type: "file" | "folder";
+	ctime: number; // création (ms epoch)
+	mtime: number; // dernière modif
+	size: number;
+}
+export interface TabsLayout extends LayoutDimension {
+	type: "tabs";
+	children: LayoutNode[];
+	currentTab: number;
+}
+/**
+ * Le contrat d'un éditeur de TEXTE : le socle, plus ce qu'un document textuel
+ * sait faire en propre. Mêmes membres qu'avant le découpage, même nom — vu de
+ * l'extérieur, `Editor` n'a pas bougé. `CmEditor implements Editor` est inchangé.
+ *
+ * Ce qui vit ICI plutôt que dans le socle a un point commun : ça n'a de sens que
+ * s'il existe un espace d'offsets de caractères. `coordsForRange` en fait partie
+ * — un rect par rangée VISUELLE d'une plage de texte.
+ */
+export interface TextSurface extends DocumentSurface {
+	getLine(n: number): string;
+	lineCount(): number;
+	offsetToPos(offset: number): EditorPosition;
+	posToOffset(pos: EditorPosition): number;
+	getSelection(): EditorRange;
+	coordsForRange(from: number, to: number): Rect[];
+}
+/** Une option d'une rangée (voir ToolbarItem.setOptions) : valeur + aspect. */
+export interface ToolbarOption {
+	value: string;
+	label: string;
+	/** Aspect par icône Lucide… */
+	icon?: string;
+	/** …ou par pastille colorée… */
+	color?: string;
+	/** …dont on peut imposer le diamètre en px (l'épaisseur de trait). */
+	size?: number;
+}
+/**
+ * Un coffre connu, tel que la fenêtre de gestion et le sélecteur l'affichent.
+ *
+ * `name` est DÉRIVÉ du chemin côté main (basename), jamais persisté : renommer
+ * le dossier sur le disque doit changer le nom affiché sans migration.
+ *
+ * `exists` est là exprès pour qu'un coffre introuvable — déplacé, disque
+ * débranché — soit MONTRÉ comme cassé plutôt que caché. Un coffre qui disparaît
+ * en silence, c'est la panique assurée.
+ */
+export interface VaultInfo {
+	path: string;
+	name: string;
+	exists: boolean;
+	/** Celui qui est ouvert dans cette instance. */
+	current: boolean;
+}
+/**
+ *
+ *   WorkspaceItem (extends Events)     un nœud de l'arbre, porte un élément DOM
+ *    ├─ WorkspaceParent                peut avoir des enfants
+ *    │   ├─ WorkspaceSplit             découpe horizontale / verticale
+ *    │   │   ├─ WorkspaceRoot          la zone centrale
+ *    │   │   └─ WorkspaceSidedock      les panneaux latéraux, repliables
+ *    │   └─ WorkspaceTabs              empile des feuilles, une seule visible
+ *    └─ WorkspaceLeaf                  ★ héberge exactement une View
+ *
+ *  Et dans la feuille, la hiérarchie de vues (§8.3) :
+ *
+ *   View (extends Component)           un panneau, containerEl
+ *    └─ ItemView                       + en-tête, actions, contentEl
+ *        └─ FileView                   + un TFile, onLoadFile/onUnloadFile
+ *            └─ EditableFileView       marqueur : « celle-ci sait écrire »
+ *                └─ TextFileView       + data, requestSave débouncé
+ *
+ */
+/**
+ * L'état SÉRIALISABLE d'une feuille (§8.2). Ce qui finira dans workspace.json.
+ *
+ * Ne contient que des données : un type de vue par son nom, un état opaque
+ * appartenant à la vue. Aucune référence d'objet — c'est ce qui permet de le
+ * relire après un redémarrage.
+ */
+export interface ViewState {
+	type: string;
+	state?: Record<string, unknown>;
+	active?: boolean;
+	pinned?: boolean;
+}
+/**
+ * Rendu par View.setState(). `history: true` dit au Workspace que ce changement
+ * mérite une entrée dans l'historique de navigation de la feuille — le bouton
+ * « précédent ». Charger un fichier, oui ; restaurer un layout au démarrage, non.
+ */
+export interface ViewStateResult {
+	history: boolean;
+}
+export interface WidgetHandle {
+	/** L'ancre COURANTE — remappée par les éditions. La source de vérité. */
+	getAnchor(): WidgetAnchor;
+	setAnchor(anchor: WidgetAnchor): void;
+	remove(): void;
+}
+export interface Window {
+	electron: {
+		vault: VaultBridge;
+		vaults: VaultsBridge;
+		windowControls: WindowControlsBridge;
+		requests: RequestsBridge;
+		cli: CliBridge;
+	};
+}
+/**
+ * Le document entier. `main` / `left` / `right` sont les trois racines
+ * permanentes du Workspace — elles ne sont jamais créées ni détruites par la
+ * restauration, seulement remplies.
+ */
+export interface WorkspaceLayout {
+	version: 1;
+	main: SplitLayout;
+	left: SplitLayout;
+	right: SplitLayout;
+	/** L'id de la feuille active, ou null. */
+	active: string | null;
+}
+export type CliBridge = {
+	[K in keyof IpcInvokeMapping as StripCliPrefix<K>]: IpcInvokeMapping[K];
+};
+/**
+ * Ce qu'un handler reçoit : les `clé=valeur` de la ligne, plus chaque
+ * `--drapeau` sous la forme `drapeau: 'true'`.
+ */
+export type CliData = Record<string, string>;
+/**
+ * Ce qu'un handler ACCEPTE, pour `help` : nom → description. Un nom qui se
+ * termine par `=` attend une valeur (`id=`), sinon c'est un drapeau (`total`).
+ * Purement documentaire — rien n'est validé contre.
+ */
+export type CliFlags = Record<string, string>;
+/**
+ * Le handler. Il REND sa sortie — il n'écrit pas dans stdout, il n'a pas de
+ * stdout. Ce qu'il rend est imprimé tel quel par le client.
+ */
+export type CliHandler = (params: CliData) => string | Promise<string>;
+/** Ce que le serveur répond. */
+export type CliResult = {
+	ok: true;
+	output: string;
+} | {
+	ok: false;
+	error: string;
+	code: number;
+};
+/** §10.2 — ```lang → UI riche. */
+export type CodeBlockProcessor = (source: string, el: HTMLElement, ctx: unknown) => unknown;
+export type DragData = {
+	type: "leaf";
+	leaf: WorkspaceLeaf;
+} | {
+	type: "file";
+	file: TFile;
+};
+export type DropZone = "reorder" | "split-top" | "split-bottom" | "split-left" | "split-right" | "center";
+/** De quel côté du texte se trouve une marge. */
+export type GutterSide = "left" | "right";
+// ─── Canaux requête/réponse : ipcRenderer.invoke ↔ ipcMain.handle ───────────
+// Une entrée par méthode du DataAdapter qui a besoin du disque.
+// Noter les absents et POURQUOI :
+//   - getName()         : l'adapter répond tout seul, aucun aller-retour.
+//   - getResourcePath() : SYNCHRONE (une URL, pas une Promise) → simple
+//                         concaténation avec le protocole custom côté renderer.
+//   - process()         : vit sur le Vault (une closure ne traverse pas l'IPC).
+export type IpcInvokeMapping = {
+	/**
+	 * ★ LE SEUL CANAL `vault:` QUI RESTE.
+	 *
+	 *   Les vingt autres (exists, stat, list, read, write, mkdir, rename…) ont
+	 *   été supprimés : le coffre est lu et écrit par `fs` dans le renderer,
+	 *   comme chez Obsidian. Le pourquoi — 1 627 allers-retours et 23 secondes
+	 *   de gel du processus principal sur un vrai coffre — est en tête de
+	 *   src/ui/core/vault/FileSystemAdapter.ts.
+	 *
+	 *   Celui-ci survit parce que `shell.trashItem` est une API d'Electron et
+	 *   non de Node : le renderer ne peut pas l'appeler, quelle que soit son
+	 *   intégration Node. Le critère de ce qui reste ici n'est donc pas « est-ce
+	 *   du disque ? » mais « est-ce que ça exige le processus principal ? ».
+	 */
+	"vault:trashSystem": (path: string) => Promise<boolean>;
+	// ─── Gestion des COFFRES ────────────────────────────────────────────
+	//
+	//  Préfixe `vaults:` et non `vault:`, et la nuance n'est pas cosmétique :
+	//  `vault:` c'est le DISQUE du coffre ouvert (le DataAdapter), `vaults:`
+	//  c'est le choix du coffre lui-même. Deux sujets, deux préfixes — et deux
+	//  bridges distincts côté preload, dérivés séparément (voir plus bas).
+	//
+	//  Ces canaux sont les SEULS enregistrés avant que le coffre soit connu :
+	//  la fenêtre de gestion les invoque alors qu'aucun `vault:` n'existe encore.
+	"vaults:list": () => Promise<VaultInfo[]>;
+	/** Mémorise et ouvre. Avant le boot : débloque le démarrage. Après : relance l'app. */
+	"vaults:switch": (path: string) => Promise<void>;
+	/** Dialogue natif « ouvrir un dossier comme coffre ». `null` si annulé. */
+	"vaults:pickFolder": () => Promise<string | null>;
+	/** Idem, mais crée le dossier au besoin — « créer un coffre ». */
+	"vaults:create": () => Promise<string | null>;
+	/** Retire de la liste. NE SUPPRIME RIEN sur le disque. */
+	"vaults:forget": (path: string) => Promise<void>;
+	/** Ouvre la fenêtre de gestion depuis l'app (« Gérer les coffres… »). */
+	"vaults:openManager": () => Promise<void>;
+	// ─── Fenêtre : frame: false → l'OS ne dessine plus min/max/close, le
+	//     renderer les dessine (WindowControls) et pilote par ces canaux. ────
+	"window:minimize": () => Promise<void>;
+	"window:toggleMaximize": () => Promise<void>;
+	"window:close": () => Promise<void>;
+	/** L'état initial au montage — ensuite, window:maximizedChanged pousse. */
+	"window:isMaximized": () => Promise<boolean>;
+	// ─── Le retour de la TROISIÈME forme (voir IpcRequestMapping) ──────
+	/** Le renderer rend la réponse à une 'ipc:request', corrélée par son id. */
+	"ipc:reply": (id: string, result: unknown) => Promise<void>;
+	/** Le renderer annonce que boot() est passé et que 'cli:exec' est posé. */
+	"cli:ready": () => Promise<void>;
+	/**
+	 * `fragment eval` : le renderer demande au main d'évaluer `code` DANS le
+	 * renderer lui-même, par webContents.executeJavaScript — qui n'est pas
+	 * soumis à la CSP de la page (script-src sans 'unsafe-eval'), et qui rend
+	 * la valeur de complétion du script, promesses attendues, comme les
+	 * devtools. Le résultat est déjà une chaîne : la sérialisation se fait
+	 * côté main, avant le structured clone du retour.
+	 */
+	"cli:eval": (code: string, timeoutMs: number) => Promise<CliResult>;
+	/**
+	 * Écrit le shim `fragment` et met son dossier sur le PATH utilisateur
+	 * (Windows). Une API d'Electron et du système, donc ici — voir
+	 * src/electron/cli/installShim.ts.
+	 */
+	"cli:installShim": () => Promise<{
+		shim: string;
+		pathModifie: boolean;
+		message: string;
+	}>;
+};
+/**
+ * Un handler de frappe.
+ *
+ * ★ La valeur de retour porte TROIS sens distincts, et c'est le cœur de la
+ *   propagation :
+ *
+ *     false      « j'ai consommé la frappe » → preventDefault + stopPropagation
+ *     true       « j'ai traité, mais laisse passer »
+ *     undefined  « pas pour moi » → on continue la chaîne
+ */
+export type KeymapEventListener = (evt: KeyboardEvent, ctx: KeymapContext) => boolean | void;
+export type LayoutNode = SplitLayout | TabsLayout | LeafLayout;
+/** §10.2 — transforme le HTML rendu en mode lecture. */
+export type MarkdownPostProcessor = (el: HTMLElement, ctx: unknown) => unknown;
+/**
+ * Un modificateur.
+ *
+ * ★ `Mod` est le seul qu'on devrait écrire dans du code de commande : il
+ *   ABSTRAIT Cmd sur macOS et Ctrl partout ailleurs. Écrire `Ctrl` en dur, c'est
+ *   fabriquer un raccourci qui sera faux sur un Mac — et l'utilisateur mac ne
+ *   pourra que le personnaliser, pas le réparer.
+ */
+export type Modifier = "Mod" | "Ctrl" | "Meta" | "Shift" | "Alt";
+/**
+ * Ce que la vue tend au layer à sa création — le « contrat exposé par la vue ».
+ * `editor` est la façade (le layer ne touche jamais CM6) ; `file` dit sur QUEL
+ * document on place (filtrer la présence, les surlignages…).
+ */
+export type OverlayPlane = "viewport" | "document";
+/**
+ * Où ouvrir (§8.5). Keymap.isModEvent() convertira un jour l'état des touches
+ * de modification en une de ces valeurs — une seule convention d'UX, appliquée
+ * partout.
+ */
+export type PaneType = "tab" | "split" | "window";
+export type Plateforme = "macOS" | "autre";
+export type PluginConstructor = new (app: App, manifest: PluginManifest) => Plugin$1;
+/** §15 — fragment://<action>?params */
+export type ProtocolHandler = (params: Record<string, string>) => unknown;
+/**
+ * La quatrième famille du pont : recevoir des requêtes du main. Pas de
+ * préfixe à retirer ici — la seule dérivation utile est celle de
+ * ipcRendererHandle (core/cli/ipcRendererHandle.ts), qui contraint `key`
+ * et `handler` par IpcRequestMapping. Le pont, lui, reste non typé par clef :
+ * il ne fait que corréler.
+ */
+export type RequestsBridge = {
+	/** Pose un handler pour une clef ; rend son retrait. */
+	handle: (key: string, handler: (...args: unknown[]) => Promise<unknown>) => unsubscribeFunction;
+};
+/** Les plages `[from, to)` du texte qui ont matché, fusionnées si adjacentes. */
+export type SearchMatches = Array<[
+	number,
+	number
+]>;
+export type SplitDirection = "horizontal" | "vertical";
+/** 'cli:ready' → 'ready', 'cli:eval' → 'eval'. Même dérivation que les autres familles. */
+export type StripCliPrefix<K> = K extends `cli:${infer Rest}` ? Rest : never;
+// ═══════════════════════════════════════════════════════════════════════════
+//  La surface exposée au renderer par le preload.
+//
+//  Elle est DÉRIVÉE de IpcInvokeMapping plutôt que réécrite à la main : un type
+//  mappé avec remappage de clefs (`as`) retire le préfixe "vault:". Ainsi
+//  'vault:read' devient window.electron.vault.read, et il est IMPOSSIBLE que
+//  les deux listes divergent — ajouter un canal ajoute la méthode, et inversement.
+// ═══════════════════════════════════════════════════════════════════════════
+/** 'vault:read' → 'read' — type littéral de gabarit + `infer`. */
+export type StripVaultPrefix<K> = K extends `vault:${infer Rest}` ? Rest : never;
+/** 'vaults:switch' → 'switch'. Distinct de StripVaultPrefix : 'vaults:list'
+ *  ne matche PAS `vault:${…}` (après "vault" vient 's', pas ':'), donc les deux
+ *  familles se séparent toutes seules — aucune clef ne tombe dans les deux. */
+export type StripVaultsPrefix<K> = K extends `vaults:${infer Rest}` ? Rest : never;
+/** Même dérivation que VaultBridge, pour les canaux window:. Les clefs vault:
+ *  tombent sur `never` et disparaissent du type mappé — et réciproquement. */
+export type StripWindowPrefix<K> = K extends `window:${infer Rest}` ? Rest : never;
+/**
+ * La barre d'outils flottante — le pendant PERSISTANT du menu contextuel
+ * (core/Menu.ts). Même builder impératif, même DOM pur, même contrat de
+ * démontage ; ce qui change est la DURÉE DE VIE et, elle seule, entraîne tout
+ * le reste.
+ *
+ * ★ POURQUOI un composant du cœur et pas un widget de layer : une toolbar n'est
+ *   pas ancrée au document. Elle appartient au geste en cours, pas au texte —
+ *   exactement comme le menu. Un plugin la construit, la peuple et la montre ;
+ *   il ne connaît ni le DOM de la vue ni les plans d'overlay.
+ *
+ * ★ POURQUOI un PARENT au constructeur : une toolbar arme un mode DANS une vue,
+ *   donc elle appartient à cette vue. Montée dans le body — ce qu'elle faisait —
+ *   elle se bornait au viewport de la FENÊTRE : traînée par sa poignée, elle
+ *   sortait de son pane pour se poser sur le split voisin, sur la sidebar ou sur
+ *   la barre d'onglets. Le parent est son territoire : on l'y monte, et on l'y
+ *   borne. Le défaut `document.body` redonne exactement l'ancien comportement —
+ *   le body ne scrolle pas, un `absolute` s'y résout contre le viewport.
+ *
+ *   Le confinement appartient à la barre, pas à l'appelant : `moveTo` prend un
+ *   point CLIENT — celui que rendent `getBoundingClientRect` et les événements
+ *   pointeur — et fait seule la conversion vers le repère du parent.
+ *
+ * ★ POURQUOI extends Component : tout ce que la toolbar acquiert (listeners
+ *   globaux, DOM) est enregistré et rejoué à hide(). Elle ne peut pas fuir —
+ *   même mécanique que le menu et les vues.
+ *
+ * CE QU'ELLE FAIT DIFFÉREMMENT DU MENU, et pourquoi :
+ *
+ *   - Elle NE se ferme PAS au clic extérieur. Un menu est une question à
+ *     laquelle on répond une fois ; une toolbar arme un mode. Dessiner sur la
+ *     feuille EST un clic extérieur — fermer là-dessus rendrait l'outil
+ *     inutilisable.
+ *   - Ses items ont un ÉTAT : setActive() et les groupes exclusifs (setGroup).
+ *     Un item de menu déclenche puis meurt ; un item de toolbar dit « c'est le
+ *     crayon qui est armé », et le dit tant que c'est vrai.
+ *   - Pas de showAtMouseEvent : la position ne vient pas du curseur mais de
+ *     l'appelant, qui sait où est sa vue.
+ *
+ * Échap ferme (comme le menu). `blur` NE ferme PAS : perdre le focus fenêtre —
+ * alt-tab, capture d'écran — ne doit pas désarmer l'outil.
+ *
+ *     const tb = new Toolbar(view.contentEl);
+ *     tb.addItem((i) => i.setIcon('pencil').setTooltip('Crayon')
+ *                        .setGroup('outil').setActive(true)
+ *                        .onClick(() => armer('crayon')));
+ *     tb.showAtPosition(x, y);
+ */
+/** Le sens dans lequel la barre range ses items. */
+export type ToolbarOrientation = "horizontal" | "vertical";
+export type VaultBridge = {
+	[K in keyof IpcInvokeMapping as StripVaultPrefix<K>]: IpcInvokeMapping[K];
+} & {
+	/** Le canal poussé (§6.4). Rend son désabonnement — cf. Component.register(). */
+	onChanged: (callback: (type: VaultChangeType, path: string) => void) => unsubscribeFunction;
+};
+export type VaultChangeType = "create" | "modify" | "delete";
+export type VaultsBridge = {
+	[K in keyof IpcInvokeMapping as StripVaultsPrefix<K>]: IpcInvokeMapping[K];
+};
+/**
+ * §8.3 — ce que le viewRegistry stocke : une FABRIQUE, pas une instance.
+ *
+ * (Les interfaces provisoires ViewLike/LeafLike qui tenaient cette place ont
+ * disparu à l'étape 4 : les vraies classes existent, on les importe.)
+ */
+export type ViewCreator = (leaf: WorkspaceLeaf) => View;
+export type WidgetAnchor = {
+	mode: "viewport";
+	x: number;
+	y: number;
+} | {
+	mode: "document";
+	pos: number;
+	dx: number;
+	dy: number;
+} | {
+	mode: "gutter";
+	side: GutterSide;
+	pos: number;
+	dy: number;
+};
+export type WindowControlsBridge = {
+	[K in keyof IpcInvokeMapping as StripWindowPrefix<K>]: IpcInvokeMapping[K];
+} & {
+	onMaximizedChanged: (callback: (maximized: boolean) => void) => unsubscribeFunction;
+};
+export type unsubscribeFunction = () => void;
+
+export {
+	Plugin$1 as Plugin,
+};
+
+export {};
+
+// ═══════════════════════════════════════════════════════════════════════════
+//  Pied de page ambient, concaténé en fin de dist/index.d.ts par le build.
+//
+//  Le package expose le contrat comme module `@usefragment/core`, mais l'auteur
+//  d'un plugin importe depuis 'fragment' (ou les alias 'promethium'/'obsidian')
+//  qu'il marque en external — l'hôte les résout à l'exécution (resoudreModuleHote).
+//  Ces re-déclarations ambiantes typent ces trois specifiers côté consommateur,
+//  qui a @usefragment/core installé. Il ajoute `"types": ["@usefragment/core"]` (ou
+//  un `import '@usefragment/core';`) pour charger ces blocs.
+// ═══════════════════════════════════════════════════════════════════════════
+
+declare module 'fragment' {
+  export * from '@usefragment/core';
+}
+
+declare module 'promethium' {
+  export * from '@usefragment/core';
+}
+
+declare module 'obsidian' {
+  export * from '@usefragment/core';
+}