Entscheidungen, Annahmen, Risiken
Was entschieden ist, was bis zur Klärung angenommen wird und welche Risiken die Planung trägt. Neue Entscheidungen werden hier mit Datum nachgetragen.
Entschieden am 4. Oktober 2026
| Frage | Entscheidung | Folge |
|---|---|---|
| Mailsystem der Funktionspostfächer | alle Varianten, je Postfach in der Verwaltung eingestellt | Adapter für Microsoft Graph und IMAP, Zugangsdaten und Verbindungstest je Postfach |
| Anmeldung | SSO und eigene Konten, beides in der Verwaltung | SAML und OIDC je Mandant als eCore-Minor, lokale Konten daneben; LDAP nur mit gesicherter Verbindung zum Kunden |
| DMS oder E-Akte | keins vorhanden, die App ist die Ablage | vollwertige Ablage schon im MVP: Versionen, Aufbewahrung, Suche, Aktenexport, geprobte Wiederherstellung |
| Signaturniveau | meist einfache elektronische Signatur, qualifiziert nur im Einzelfall | Standardweg ohne Vertrauensdiensteanbieter; qualifizierte Signatur als Erweiterung |
| Vergaberecht | noch offen | Verfahrensarten, Wertgrenzen, Pflichtfelder sind Konfiguration, nichts davon im Code |
| Betrieb | mandantenfähig von Anfang an, Rechenzentrum in Deutschland, der Kunde stellt keinen Server; Plattform-Verwaltung und Abo aus eCore; dedizierte Instanz aus denselben Images als Option | |
| Arbeitsfläche | eCore braucht neben der App-Form einen Desktop-Modus mit deutlich mehr Arbeitsfläche (René, 4. Oktober abends) | eCore-Minor in Etappe 1: Arbeitsplatz-Gerüst, geteilte Ansicht, Datentabelle; ein Quelltext für beide Formen |
| Entwicklungsweise | KI-gestützt: Coding-Agenten bauen, ein Mensch steuert und prüft; die Planung richtet sich nicht nach menschlichem Entwicklungstempo (René, 4. Oktober spät) | Fachmodule werden parallel gebaut, sobald die Verträge des Kerns stehen; den Takt der Einführung geben Entscheidungen und Abnahmen des Dezernats |
| Vorgehen | logisch aufbauen: Kern, dann MVP, dann erweitern | Etappen wie unter Umsetzungsreihenfolge |
Entschieden am 9. Oktober 2026
Zeichnung startet im Signaturmodul; kein Report-Runner und kein Siegel in Etappe 4. Drei Abweichungen von der Kernarchitektur, wie sie Etappe 4 gebaut hat.
| Frage | Entscheidung | Warum |
|---|---|---|
| Wer rendert PDFs | der PdfRenderer von eCore mit Gotenberg im Container pdf, nicht der Report-Runner aus calServer; Zusammenfügen und Stempel mit qpdf im api-Image | keine zweite Laufzeit neben Laravel, und die Mandantentrennung bleibt im eigenen Stack: der Wandler bekommt je Aufruf nur ein Dokument eines Mandanten, im internen Netz ohne JavaScript |
| Wo eine Zeichnung beginnt | im Signaturmodul; es liest das Dokument über den Vertrag CaseDocumentStore und meldet DocumentSubmittedForSignature | so weiß das Dokumentmodul nichts vom Zeichnen: es sperrt und gibt frei, wenn ein Ereignis es sagt, und kennt weder Regeln noch Läufe |
| Siegel in Etappe 4 | keins; die Ausfertigung mit Zeichnungsprotokoll und Hash ist eine einfache elektronische Signatur nach Art. 3 Nr. 10 eIDAS | der Standardweg braucht kein Siegel (Signaturniveau oben); qualifizierte Signatur und Siegel kommen in Etappe 7 |
Entschieden am 10. Oktober 2026
Gegenzeichnung im selben Lauf, Ausfertigung ohne Siegel. Wie Etappe 5 gebaut ist und wo sie vom Plan abweicht.
| Frage | Entscheidung | Warum |
|---|---|---|
| Wo die Externen stehen | im Zeichnungslauf, als letzte Stufe nach der internen Zeichnung; eingetragen beim Start, höchstens drei | so gilt die Zeichnung des Partners genau der Fassung und dem Hash, den intern alle gezeichnet haben, und die Ausfertigung entsteht erst, wenn alle gezeichnet haben |
| Wie Externe sich ausweisen | Einmal-Link mit 256 Bit im Fragment, auf Wunsch ein Code per Mail; gezeichnet wird mit eingetipptem Namen | einfache elektronische Signatur wie intern; der Code belegt das Postfach, wenn ein Link weitergeleitet wird |
| Ausfertigung in Etappe 5 | wie in Etappe 4: PDF mit Zeichnungsprotokoll und Hash, ohne Siegel und ohne PDF/A | Siegel und qualifizierte Signatur kommen mit Etappe 7; bis dahin trägt das Protokoll in der Akte den Nachweis |
| Mandanten ohne Mailversand | Einstellung „Link in der Oberfläche zeigen“: beim erneuten Senden erscheint der neue Link einmal zum Kopieren; voreingestellt aus | der Testserver verschickt keine Mail; wer den Link sieht, kann ihn weitergeben, deshalb nur bewusst einschalten |
| Erinnerung und Ablauf | Link gilt 1 bis 60 Tage (Vorgabe 14), Erinnerung nach 0 bis 30 Tagen (Vorgabe 3), höchstens dreimal; ein abgelaufener Link meldet sich bei der Person, die gestartet hat | einstellbar je Mandant, weil Partner unterschiedlich schnell antworten |
Vertragsregister (Etappe 6)
Ein Vertrag hängt an einer Akte, seine Fristen führt der Kern. Wie Etappe 6 gebaut ist und welche Annahmen bis zur Klärung mit dem Dezernat gelten.
| Frage | Entscheidung | Warum |
|---|---|---|
| Wo ein Vertrag steht | immer an genau einer Akte; aus einer Ausfertigung entsteht ein Entwurf „zu erfassen“, den ein Mensch ergänzt und in Kraft setzt | eine Vorgangsakte (Regel 11); lieber ein Entwurf zu viel, den jemand verwirft, als ein Vertrag, dessen Kündigungsfrist niemand kennt |
| Kündigungsfrist | gilt zum Vertragsende: „Kündigen bis“ ist Ende minus Frist, in Tagen, Wochen oder Monaten; Sonderformen wie „zum Quartalsende“ kommen später als eigene Einheit (Annahme) | der häufigste Fall in Dienstleistungs- und Wartungsverträgen; eine Sonderform verbiegt sonst die Rechnung für alle |
| Erinnerung | „Kündigen bis“ und „Vertragsende“ sind Fristen des Kerns an der Akte; der Vorlauf kommt aus der Vertragsart (Vorgabe 30 Tage), erinnert und eskaliert der Fristenjob | eine Stelle für alle Fristen, auch in „Mein Tag“; das Register zeigt nur, was der Kern führt |
| Automatische Verlängerung | täglich um 5:15 Uhr, vor dem Fristenjob: ein Vertrag in Kraft mit Verlängerung, dessen Ende gestern oder früher war, läuft um seine Monate weiter, bis das Ende in der Zukunft liegt; die Fristen ziehen mit (Annahme) | wer nicht gekündigt hat, ist weiter gebunden; der Fristenjob sieht danach schon das neue Ende |
| Meldung bei Verlängerung | Eintrag in der Zeitleiste und im Protokoll; die zuständige Person erfährt es über ihre verschobene Frist „Kündigen bis“, keine eigene Mail (Annahme) | die nächste Entscheidung ist die Kündigung, und an die erinnert der Fristenjob ohnehin |
| Ende ohne Verlängerung | ein gekündigter Vertrag oder einer ohne Verlängerung endet mit seinem Ende; als Tag des Endes gilt sein Ende, nicht der Tag des Laufs | das Register soll zeigen, wann der Vertrag endete, nicht wann der Server es bemerkte |
| Import der Bestandsverträge | CSV in der Verwaltung (nur Rolle Verwaltung): erst prüfen, dann übernehmen, alles oder nichts; Befunde aller Zeilen auf einmal mit Zeile und Spalte; je Vertrag eine neue Akte der gewählten Vorgangsart oder alle in eine Akte per Aktenzeichen (Annahme) | ein Bestand kommt meist aus einer Excel-Liste; eine halb übernommene Liste wäre schlimmer als keine, und ein Vertrag braucht eine Akte |
| Partner und Personen im Import | ein Partner wird verknüpft, wenn genau einer im Verzeichnis so heißt, sonst frei eingetragen; die zuständige Person über die E-Mail-Adresse ihres Kontos; eine Vertragsart bringt ihre Vorgaben für Frist und Verlängerung mit | Namen in Altlisten sind selten eindeutig; lieber frei eingetragen als dem falschen Partner zugeordnet |
| Vertragsart der Akte und des Registers | die Zeichnungsregeln lesen die Vertragsart aus einem Auswahlfeld der Akte, das Register führt eigene Arten mit Vorlauf, Frist und Verlängerung; unter Vertragsarten wählt die Verwaltung dasselbe Feld, und eine Art mit gleichem Namen gilt als dieselbe; ein Entwurf aus einer Ausfertigung bekommt sie samt Vorgaben, ein neuer Vertrag an der Akte bekommt sie vorgeschlagen; ein Wert ohne gleichnamige Art lässt die Art leer | die Zeichnungsregeln prüfen schon vor jedem Vertrag, und ein Fachmodul kennt das andere nicht (Regel 12); eine Brücke über den Namen hält beide Seiten bei einer Wahrheit, ohne dass eines die Tabellen des anderen liest |
| Wer Verträge sieht | wer die Akte sieht; die Verwaltung sieht alle (Annahme) | dieselbe Regel wie für jede Akte, kein zweites Rechtemodell |
| Aussonderung | eine Akte mit laufendem Vertrag wird nicht ausgesondert; beendete Verträge gehen mit der Akte (Annahme) | ein laufender Vertrag braucht seine Akte noch |
Einarbeitungsassistent
| Frage | Entscheidung | Warum |
|---|---|---|
| Woher der Assistent seine Schritte hat | jedes Modul meldet seine Schritte über einen eigenen Vertrag des Kerns (AssistantSteps); der Kern ordnet sie nach den Phasen der Vorgangsart und zeigt den Schritt eines Moduls nur, wenn dessen Capability freigeschaltet ist | der Kern kennt die Fachmodule nicht (Regel 12), und ein Modul, das die eigene Freischaltung vergäße, zeigte sonst Schritte, die mit 403 enden |
| Was „bereit“ heißt | ein Übergang ist bereit, wenn die Pflichtfelder der Zielphase gefüllt sind und kein Wächter widerspricht; der Probelauf nutzt dieselbe Prüfung wie der Klick, ohne Sperre, Protokoll oder Ereignis; fehlende Felder und Einwand stehen nebeneinander | der Assistent darf nie anders urteilen als der Knopf, und wer beides auf einmal sieht, muss nicht zweimal klicken |
| Fortschritt | nichts gespeichert; ob ein Schritt erledigt ist, liest jedes Modul aus seinem Bestand, und Warten ist ein eigener Zustand | eine zweite Wahrheit neben Phase und Bestand liefe auseinander, sobald jemand an der Akte vorbei arbeitet |
| Freischaltung | eigene Capability assistent, voreingestellt aus; der Lesepunkt antwortet nach den Rechten der Akte, eine Akte außer Sicht ist 404 | die Akte funktioniert ohne Assistent wie bisher; dieselbe Sichtregel wie überall, kein zweites Rechtemodell |
Annahmen bis zur Klärung
| Offene Frage | Annahme | wird geklärt in |
|---|---|---|
| Wer zeichnet, ab welchem Betrag | Zeichnungsregeln als Einstellung nach Betrag und Vertragsart; Werte aus dem Workshop | Etappe 0 |
| Finanzbuchhaltung | spätere Schnittstelle über E-Rechnung und Bestelldaten, Adapter nach Wahl des Systems | Etappe 0, gebaut in Etappe 7 |
| Geltendes Vergaberecht | Beispielregelwerk zum Start, rechtlich zu prüfen | Etappe 0 |
| Vertragsarten mit Schriftform | Klärung durch die Rechtsabteilung (abgeleitet, nicht geprüft) | Etappe 0 |
| Rechenzentrum der Plattform | Anbieter in Deutschland nach Wahl von calhelp, Entwicklung wie bisher bei Hetzner | vor Etappe 2 |
| Nachweise für Kunden aus dem öffentlichen Bereich | Auftragsverarbeitung und Standort Deutschland reichen für den Start; BSI C5 oder ISO 27001 nach Bedarf der Kunden | Etappe 0 |
| Lokales Exchange beim Kunden | Abruf per IMAP über TLS aus dem Internet oder über ein Gateway beim Kunden | Etappe 0 |
| Name der Anwendung | Arbeitstitel eVorgang | jederzeit |
Risiken
| Risiko | Gegenmaßnahme |
|---|---|
| App als einzige Ablage trägt Aufbewahrung, Sicherung und Revisionssicherheit selbst | Ablage im MVP, Wiederherstellung je Mandant vor dem Produktivstart proben, Aufbewahrungsfristen in Etappe 0 festlegen, Datenübergabe bei Vertragsende festlegen |
| Graph und IMAP verhalten sich bei Ordnern, Lesestatus und Anhängen unterschiedlich | eine gemeinsame Schnittstelle, je Variante ein Testpostfach |
| Envelope-Verschlüsselung verhindert Volltextsuche | nur Personenbezogenes verschlüsseln, Geschäftsdaten als Klartext mit Rechten schützen |
| Desktop-Modus verdoppelt die Oberfläche | keine zweite Seite je Ansicht: Bausteine ordnen sich nach Breite an; Browser-Tests in drei Breiten |
| Desktop-Modus verändert andere eCore-Hüllen | nur eingeschaltet, wenn eine Hülle ihn beim Gerüst anmeldet; additiv innerhalb der Hauptversion |
| eforms-Oberflächen passen nicht zum eCore-Stil | Backend portieren, Oberfläche neu |
| calServer-Module hängen am V1-Schema | nur Muster übernehmen, Java-Dienste als Container |
| CSC-Adapter in Seal nur gegen Attrappe getestet | erst mit der Erweiterung bei einem echten Anbieter erproben |
| Review wird zum Engpass, wenn Agenten mehr liefern, als ein Mensch prüfen kann | Pakete klein und einzeln prüfbar schneiden, Grundprüfung automatisieren, Bauströme nach Prüfkapazität begrenzen statt nach Bautempo |
| Agenten schreiben plausible, aber fachlich falsche Regeln (Vergabe, Fristen, Zeichnung) | Fachregeln als Konfiguration, nicht im Code; Abnahmekriterien des Dezernats als Tests; Abnahme am echten Vorgang |
| Gebaut wird schneller, als entschieden wird | offene Fragen früh klären; was an offenen Entscheidungen hängt, bleibt einstellbar oder wartet |
| Ein Fehler im Mandanten-Scope zeigt Daten eines Kunden einem anderen | Isolation als Pflichttest je Endpunkt und als eigene Testreihe; Schlüssel und Ablage je Mandant, damit auch ein Lesefehler nichts im Klartext liefert |
| Kunden aus dem öffentlichen Bereich verlangen Nachweise, die ein kleiner Anbieter erst aufbauen muss | Anforderungen in Etappe 0 erheben; dedizierte Instanz als Rückfall |
| Lokales Exchange ist aus dem Internet nicht erreichbar | Gateway beim Kunden oder Weiterleitung der Funktionspostfächer; früh klären |
| Siegel und Signatur brauchen eine Identität je Kunde | Siegelzertifikat je Mandant in seal; bis dahin Siegel von calhelp nur als Integritätsnachweis, nicht als Erklärung des Kunden |
| Rechte am Code, LGPL-Komponenten | intern klären; LGPL-Komponenten bleiben eigene Dienste |
Grundlagen
- Architekturkonzept: Integriertes Vorgangs-, Vergabe-, Signatur- und Vertragsmanagement (Bestandsaufnahme der Repositories, Zielarchitektur, Etappen)
- Konzept: Ideales Zielsystem mit nachgenutzten Modulen (Zielbild, Modulschnitt, Zuordnung der Bausteine)
- Anfrage des Dezernats zum integrierten Ticket-, Vorgangs-, Signatur- und Vertragsmanagement einschließlich digitaler Vergabeakte