Grenzen v1

• Ein Optionssatz je Mandant, ein eigener DI-Container. AddMesoAibeCore verdrahtet einen Mandanten pro Aufruf (Singleton-Optionen, analog den MesoXPO.Business-Extensions). Der Standalone baut deshalb je konfiguriertem Mandanten aus Aibe:Mandanten einen eigenen ServiceCollection/ServiceProvider. Mehrere Mandanten in einem gemeinsamen Container sind in v1 nicht vorgesehen.
• Graph-/IMAP-Serverpfade sind nicht CI-getestet und werden am Pilotpostfach verprobt. Ohne M365-/IMAP-Zugriff im Build laesst sich nur die serverfreie Logik automatisiert testen (Nachrichten-zu-DTO-Mapping via MimeMapper, OrdnerLeser gegen ein Temp-Verzeichnis). Die eigentlichen Leseoperationen gegen Graph und IMAP werden noch manuell am Pilotpostfach verprobt — der Pilotbetrieb steht zum Zeitpunkt dieses Standes noch aus.
• Kein GUI. MesoAibe.Service ist ein reiner Hintergrunddienst ohne Freigabe-Oberflaeche — wer automatisch angelegte Belege pruefen oder Vorschlaege freigeben will, braucht das WorkerService-Modul MESO-WSAIBE, das diese Oberflaeche mitbringt.
• Doppelanlage-Restfenster bei Dienst-Neustart. Gegen doppelte Beleganlage markieren GraphPostfachLeser/ImapPostfachLeser eine Nachricht unmittelbar nach dem Lesen als gelesen (isRead-Patch bzw. Seen-Flag) statt erst beim Verschieben, und AibeWorker haelt zusaetzlich prozesslebenslang die Schluessel bereits verarbeiteter Quelldokumente vor (VerarbeiteteQuellen) — das faengt einen spaeter scheiternden Move/Verschiebe-Schritt ab. Beide Sicherungen sind an den laufenden Prozess gebunden: ein Dienst-Neustart genau zwischen erfolgreicher Beleganlage und der Markierung an der Quelle kann im Extremfall trotzdem eine Doppelverarbeitung erzeugen. Persistenz der Quell-Ids ueber einen Neustart hinweg ist Backlog.