import { Class_ApplicationData } from '../types/ApplicationData';
import type { Type_JSON } from '../types/Utils';
/** Le résultat de l'extraction : un JSON de fichier par brique, plus l'assemblage. */
export type Type_UnitaryExtraction = {
    bricks: {
        [process_node_id: string]: Type_JSON;
    };
    assembly: Type_JSON;
};
/**
 * L'étoile d'UN nœud arbitraire, rendue comme un fichier OpenSankey de brique —
 * la matière première de l'APERÇU unitaire (os#1382, chantier U5).
 *
 * Le board unitaire accepte tout nœud VISIBLE qui n'est pas un nœud d'échange
 * (cf. `ModalUnitarySankeyOSP.tsx`, `centralCandidates`) : produit, secteur, ou
 * nœud d'un diagramme sans groupe `'type de noeud'` du tout. On ne filtre donc
 * PAS sur le tag `secteur` ici — c'est la différence avec `extractUnitaryBricks`,
 * qui, lui, dérive un modèle de procédés et n'a de sens que sur les secteurs.
 *
 * `null` quand le nœud est inconnu ou invisible : il n'y a alors pas d'étoile à
 * montrer, et ce n'est pas une erreur (un focus sur un nœud masqué par un
 * changement de niveau, par exemple).
 *
 * PERF — O(graphe) par appel : la brique est fabriquée par copie complète du
 * global puis suppression, comme les briques de l'extraction. C'est assumé,
 * parce que c'est exactement le coût d'ouverture du board unitaire d'aujourd'hui
 * (`buildUnitaryDrawingArea` sérialise et recharge le global entier). Un focus
 * successif sur N nœuds paie donc N fois ce prix, pas une fois.
 *
 * POURQUOI CE POINT D'ENTRÉE SÉRIALISE AU NIVEAU DRAWING AREA, et non
 * `app_data.toJSON` comme `extractUnitaryBricks` — deux raisons, toutes deux
 * propres à l'aperçu :
 *
 *  1. LA VUE AFFICHÉE. Sur une application à vues hors du maître
 *     (`ApplicationDataOSP._toJSONWithoutContextOverlay`), `toJSON` rend à la
 *     racine le MAÎTRE et range la vue courante dans `_views`. On lit pourtant le
 *     nœud, ses flux et leurs valeurs sur `app_data.drawing_area`, c'est-à-dire
 *     sur la VUE : la brique serait découpée dans un autre diagramme que celui
 *     qu'on vient de mesurer, et l'aperçu montrerait l'étoile du maître avec les
 *     coefficients de la vue. `DrawingAreaPersistence.toJSON` sérialise
 *     exactement la drawing area qu'on a lue — la même, toujours.
 *  2. ZÉRO EFFET DE BORD. Ce même chemin gzippe la vue courante dans `_views` et
 *     lève `ref_to_save_in_cache_indicator`. L'aperçu s'ouvre et se refocalise à
 *     chaque clic : il n'a rien à faire enregistrer.
 *
 * L'aval ne change pas : la RACINE d'un fichier OpenSankey EST un JSON de
 * drawing area (`ApplicationData._toJSON` n'ajoute que des clés de niveau
 * application par-dessus). Le rechargement dans une application neuve, ici comme
 * côté board, lit donc la même chose. Les kwargs passent tels quels :
 * `keep_siblings` est consommé plus bas, par `SankeyPersistence.toJSON` (c'est
 * lui qui décide d'écrire les nœuds d'échange éclatés ou agrégés) ; seul
 * `without_sheets` devient sans objet, les feuilles étant de niveau application
 * — une brique n'en portait de toute façon aucune.
 *
 * `extractUnitaryBricks`, lui, RESTE au niveau application : son shell doit être
 * le global entier, clés d'application comprises, sous peine de casser la recette
 * `global → (briques + assemblage) → global` du chantier U2.
 */
export declare const extractUnitaryBrickFor: (app_data: Class_ApplicationData, node_id: string) => Type_JSON | null;
/**
 * Extrait d'un global chargé un fichier OpenSankey de brique par procédé, plus le
 * fichier d'assemblage qui porte l'échelle de chaque brique, le graphe port-à-port
 * et le SHELL — le global amputé de tout ce qui est parti dans une brique.
 *
 * L'application source n'est pas modifiée : chaque brique est fabriquée dans une
 * application détachée, à partir d'une copie du JSON du global.
 */
export declare const extractUnitaryBricks: (app_data: Class_ApplicationData) => Type_UnitaryExtraction;
/**
 * L'inverse mécanique de `extractUnitaryBricks` : recolle les briques sur le shell
 * et rend le JSON du global.
 *
 * C'est un VÉRIFICATEUR DE BIJECTION, pas la composition du chantier U3 : il ne
 * met pas les briques à l'échelle de leur niveau d'activité et ne réconcilie rien
 * aux coutures — ce calcul-là vit côté plateforme Python (mfa#252), avec la matrice
 * qu'il faut pour fermer les bilans. Ici on remonte le puzzle par identifiant, et
 * l'on vérifie que les pièces s'emboîtent.
 *
 * Premier arrivé gagne ; un identifiant réécrit différemment lève une erreur
 * explicite (cf. `mergeNodeJSON`).
 */
export declare const composeUnitaryBricks: (bricks: {
    [process_node_id: string]: Type_JSON;
}, assembly_json: Type_JSON) => Type_JSON;