Der Authoring-Kernel — eine zweite Authoring-Oberfläche aufbauen

Fortgeschritten. Für Asset-/Tool-Autoren, die eine eigene Authoring-Oberfläche (zum Beispiel eine Node-Graph-Canvas) auf der Engine von SheetForge aufbauen möchten. Spieleteams, die das Data Studio verwenden, benötigen diese Seite nicht.

Das Authoring-Fenster ist nicht die Engine. Das Data Studio – und die Browser-App daneben – sind Konsumenten eines fensterunabhängigen Authoring-Kernels.

Alles, was sie tun, läuft über öffentliche Typen, die eine dritte Oberfläche auf dieselbe Weise steuern kann: Staging, Validierung, Übernehmen-Orchestrierung, Undo-Grenzen, erneuter Import. Zwei Oberflächen tun das bereits, was der praktische Beweis ist, dass die Naht real ist und nicht nur angestrebt.

Bevor Sie eine ganze Oberfläche bauen, prüfen Sie, ob ein Erweiterungspunkt den Bedarf bereits abdeckt. Ein Plugin kann dem mitgelieferten Fenster Verben, Panels, Badges und Cell-Widgets hinzufügen, ganz ohne ein eigenes Fenster zu besitzen, als Daten beschrieben, sodass sie im Editor und im Browser gerendert werden — siehe Plugin-Erstellung §4.16. Diese Seite ist für den Fall gedacht, dass Sie Ihre eigene Canvas möchten.

Eine Konsumenten-Simulationstest-Assembly (SheetForge.Tests.Consumer, ohne InternalsVisibleTo-Zugriff auf Core oder Editor) implementiert eine virtuelle Authoring-Oberfläche end-to-end allein gegen die öffentliche API. Wäre ein benötigtes Member internal, würde diese Assembly nicht kompilieren (CS0122) — sie dient damit als die ausführbare Spezifikation für die unten beschriebene Oberfläche.

Die Drei-Objekt-Engine

┌─────────────────────┐     ┌──────────────────────────┐     ┌───────────────┐
│  AuthoringSession   │────▶│   AuthoringDispatcher    │────▶│ BaselineStore │
│  (staging state)    │     │   .Reflect()             │     │ (round-trip   │
│                     │     │   (the full cycle)       │     │  snapshots)   │
└─────────────────────┘     └────────────┬─────────────┘     └───────────────┘
                                         │ binds
                            ┌────────────▼─────────────┐
                            │ AuthoringDispatchCallbacks│
                            │ (view concerns — YOUR UI) │
                            └──────────────────────────┘

`AuthoringSession` — der Staging-Zustand

Eine einfache [Serializable]-Klasse (bewusst kein ScriptableObject): Halten Sie sie in einem [SerializeField]-Feld Ihres EditorWindow, und Sie erhalten Unity-native Undo-Schnappschüsse und das Überleben von Domain-Reloads gratis dazu — derselbe Mechanismus, der hinter dem Ctrl+Z des mitgelieferten Fensters steckt.

Sie besitzt den gesamten vorgemerkten Zustand:

Zellbearbeitungen (Edits), neue Zeilen (NewRows), Strukturoperationen (StructOps);
Neuanordnungen pro Tab (Reorders), Tab-Umbenennungen (TabRenames);
Baseline-Anker, isolierte Bearbeitungen.

Darüber hinaus stellt sie die Mutations-/Abfrage-API bereit:

SetStaged(...) — merkt eine Zellbearbeitung vor. Bearbeitungen tragen eine logische Adresse (Tab · RecordId · Feld); die physische Zeilenordnungszahl ist ein abgeleiteter Cache, der unmittelbar vor dem Übernehmen neu aufgelöst wird.
ResolveBaselineEdits(provider) — verankert alle Bearbeitungen neu gegen die aktuelle Baseline. Auflösbare Bearbeitungen laufen weiter; die drei unauflösbaren Fälle (externe Umbenennung / externes Löschen / Schlüsselkonflikt) werden nach IsolatedEdits verschoben — vom Übernehmen ausgeschlossen, mit Badge gekennzeichnet, nie stillschweigend verworfen, nie sitzungsblockierend.
Baseline-Lesezugriff: TabNames, TryGetBaselineTable(tab, out SheetTable) — typisierter Schemazugriff (TypeToken, @desc, @overlap), ohne den Parser selbst anzufassen.
EffectiveStructOps() / PendingStructCount() — die zusammengesetzte, kanonische Sicht auf die Strukturoperationen.
Remap-Hooks (RemapFieldName / RemapRecordId / RemapTab) halten den vorgemerkten Zustand über Umbenennungen hinweg konsistent.
LastProjectionResult speichert die letzte Projektion zwischen.

`AuthoringDispatcher` — die Übernehmen-Orchestrierung

var dispatcher = new AuthoringDispatcher(session, callbacks, baselineStore);
dispatcher.Reflect();   // the entire cycle, one call

Reflect() läuft den gesamten Zyklus der Reihe nach ab:

Vorab-Validierung
quellenspezifisches Übernehmen — chirurgisch präzise Schreibvorgänge lokal, sicheres Rewrite bei Google, Ihr eigenes Ziel bei benutzerdefinierten Providern
Bereinigung des zurückgehaltenen Zustands
die ClearUndo-Bestätigungsgrenze
automatischer erneuter Import mit Bericht

Außerdem:

BuildProjectionResult() — eine nebenwirkungsfreie Projektion des aktuellen vorgemerkten Zustands als ImportResult (validieren, als wäre bereits übernommen worden). Verwenden Sie sie für Live-Fehler-Badges.
Öffentliche Session / Callbacks / Baselines — benutzerdefinierte Source-Provider verwenden diese, um ihre Übernehmen-Ziele zusammenzustellen.

`AuthoringDispatchCallbacks` — der Vertrag Ihrer Oberfläche

Ein Bündel von 13 allgemeinen Delegates, die der Dispatcher für jedes Ansichts-Anliegen aufruft: ResolveSettings, Bestätigungsdialoge (ConfirmKeyRenames, ConfirmTabRenames, …), RenderReport (ein Action<ImportReport> — null-tolerant, es ist rein beobachtend), PushApprover, TriggerReimport, ClearUndo, Rebuild und so weiter. Die 14 Dialog-Delegates, die spezifisch für die eingebauten Local-/Google-Quellen sind, leben in einem separaten Opt-in-Bündel BuiltInSourceDialogs — eine externe Oberfläche oder ein Provider muss sie niemals binden. Das mitgelieferte Fenster bindet Standardimplementierungen, die Dialoge anzeigen; Ihre Canvas bindet ihre eigenen (oder No-ops). Die Engine zeichnet niemals selbst eine Oberfläche.

Graph-Material

Für eine Projektion „Node = Datensatz, Kante = Referenz ∪ Deklaration":

ReferenceScanner (Core) — die einzige Quelle der Wahrheit für das Aufzählen von Referenz-Vorkommen über alle Tabellen hinweg: Skalare, Listenelemente, explizite Standardwerte. Dieselbe Aufzählung, die der Referenz-Validator verwendet, sodass Ihr Graph und die Validierung konstruktionsbedingt übereinstimmen. Scan(tables) / ScanTable / ScanField / IsReferenceField.
IEdgeContributor / EdgeSpec / EdgeContributorRegistry (Core) — Domänen-Plugins deklarieren Kanten, die der Scanner nicht sehen kann (innerhalb von Custom-Type-Werten, type-Spalten-Verknüpfungen, Datensatz-Kanten mit einem Payload-Datensatz). Sammeln Sie sie über die Editor-PluginRegistry.BuildEdgeContributors.
ReferenceIndex / RecordEdge (Core) — der zusammengesetzte Schnappschuss, auf dem die eigene Canvas des Data Studio läuft: Build(...) führt gescannte Referenzen und Contributor-Kanten einmalig zusammen, danach beantworten OutEdges / InEdges / InCount in O(1) pro Datensatz. Vollständige Member-Liste in der API-Referenz.
IRecordCanvasAugmenter / CanvasAugmentBuilder (Core) — der Override-Vertrag pro Tab, falls Sie möchten, dass Domänenpakete Ihre Canvas auf dieselbe Weise erweitern, wie sie die des Studios erweitern (virtuelle Nodes, zusätzliche Kanten, Layer- und Anzeige-Hinweise).
ProjectionErrorMapper (Editor, pure) — bildet die physische Koordinate eines Projektionsfehlers (Tab/Zeile/Feld) auf eine logische Adresse (Tab/RecordId/Feld) ab, sodass Sie Fehler-Badges an Nodes statt an Zeilennummern heften können.

Unterstützende Bausteine

Typ	Wofür Ihre Oberfläche ihn verwendet
`ImportEvents`	Zwei Busse, beide öffentliche Verträge. `ImportCompleted` (`ImportCompletedArgs`: `Tabs` · `BakeFolder`) feuert, wenn die automatische Kette vollständig bis zum Bake durchgelaufen ist, sodass ein Abonnent die per Bake erzeugten Assets lesen darf. `BaselineUpdated` (`BaselineUpdatedArgs`: `Tabs` · `Quarantined`) feuert, wann immer ein Tabellen-Snapshot gespeichert wurde — einschließlich eines Laufs, dessen Validierung fehlschlug —, was eine Oberfläche abonniert, wenn sie die fehlgeschlagenen Tabellen zeigen und sie beheben lassen möchte. Abonnieren Sie beide, wenn Ihre Ansicht sowohl Tabellen als auch per Bake erzeugte Werte zeigt; melden Sie sich symmetrisch in `OnDisable` wieder ab.
`IPipelineObserver`	Ist das, was Bescheid wissen muss, ein Plugin statt eines Fensters, ist dies der leichtere Pfad: Registrieren Sie einen Beobachter und erhalten Sie am Ende jedes Import-Zyklus einen unveränderlichen `PipelineRunView`, ganz ohne Editor-Abhängigkeit — er funktioniert auch im Browser-Host. Siehe Plugin-Erstellung §4.17.
`RecordIdMinter`	Schlägt Ids für neue Datensätze vor — Präfix-Erkennung + kollisionssichere Eindeutigmachung. Eine Vorschlags-API, bewusst keine automatische Nummerierung.
`EphemeralSoApply`	Zeigt vorgemerkte Werte temporär auf per Bake erzeugten SOs vor (erneuter Import stellt wieder her). Wendet die berechenbare Teilmenge an; liefert Übersprungs-Gründe für ausstehende Spalten und Parse-Fehler. Nichts in der mitgelieferten Oberfläche steuert es noch, daher besitzt eine Oberfläche, die diese Vorschau möchte, die Schaltfläche dafür selbst.
`KeyRenamePlanner`	Plant Schlüssel-Umbenennungen (3-stufig: Extraktion / Propagierung / chirurgischer Eingriff), genau so, wie es das mitgelieferte Fenster tut. Tab-Umbenennungs-Bestätigungen laufen stattdessen über den öffentlichen `ConfirmTabRenames`-Callback.
`SourceProviderRegistry`	Löst den aktiven Source-Provider auf dieselbe Weise auf wie die Settings-Oberfläche.

Grundregeln, die der Kernel erzwingt (und die Sie erben)

Die Tabelle bleibt kanonisch — Ihre Oberfläche merkt vor und übernimmt; sie schreibt niemals SOs.
Erst validieren, dann übernehmen — Reflect() schreibt nichts, wenn die Vorab-Validierung fehlschlägt.
Kein stiller Verlust — unauflösbare Bearbeitungen werden mit einem Grund isoliert; Bestätigungen laufen durch Ihre Callbacks.
Undo integriert sich nativ — halten Sie die Session in einem serialisierten Feld und registrieren Sie Undo-Schnappschüsse an Ihrem Fenster; ClearUndo markiert die Übernehmen-Grenze.
Domänenunabhängig — der Kernel enthält null Domänenvokabular (durch Schutztests abgesichert). Ihre Domäne kommt über die Plugin-Verträge hinzu, nicht über Änderungen am Kernel.