aYOUne
translate
Not in your language

This page is not yet available in en. You're reading the de version.

Core Changelog

@tolinax/ayoune-core ist das Backend-Framework — wenn sich hier was ändert, kaskadieren die Änderungen über alle ~330 Microservices. Dieser Changelog zeigt die wichtigsten Versionen seit 2026.41.

2026.50.x (April 2026)

  • 2026.50.1 — Marketplace-Integrations-Hooks im copyToCustomer-Primitive
  • 2026.50.0subscribeToReseedSignal() für State-Reseed ohne Pod-Restart (60s-Poll auf core.reseedStates.<modul>)

2026.48.0 — resolveHeroForEvent (April 2026)

Core-Helper mit per-EntityType-Resolver-Registry (MailLogs, Newsletters, Tasks, Invoices, Shippings, …) und Customer-Branding-Fallback cm.ayoune.app/<slug>/hero.jpg. Producer-explizit gewinnt.

2026.47.0 — Notifications Rich-Content Phase 2 (April 2026)

Type-aware Attachment-Display, Tag-Dedup (5s-Window), Initial-Bubble-Avatar, Wallboard-Alert-Mode-Trigger.

2026.46.0 — Two-Phase Boot + Health-Probes (24. April 2026)

Wichtigster Release des Quartals. Eliminiert das "Silent-Hang"-Anti-Pattern.

  • await ay.ready (Promise) statt nur ay.on('ready', ...) — Promise resolved nach DB + Models + License
  • ay.isReady (boolean Latch) für /readyz
  • Two-Phase Boot: Essential (DB+Models+License) blockt ready, Background (Logger, JobQ, Monitoring, Translation, Flags) tut es nicht. Hangs in Background → subsystem_error Event statt silent Ready=Yes.
  • 60s Boot-Watchdog crashloop'd Pods, deren Essential-Phase nicht durchläuft → init_error-Event.
  • Neue Helper: mountHealthEndpoints(app, ay) (Express → /healthz + /readyz), createWorkerHealthServer(ay) (Worker → minimaler HTTP-Listener auf AYOUNE_WORKER_PROBE_PORT).
  • Helm node-Chart: Probes hinter probes.enabled Flag (default off).

Migration: Services können ay.on('ready', ...) weiter nutzen — fires noch — aber await ay.ready ist klarer und race-free.

2026.45.x (April 2026)

Hub-Module Rendering, Glossar-Linking-Helper, Markdown-Sanitize-Pipeline für Wiki-Content.

2026.44.x

Mongoose 8 Compat-Layer Fixes — Document.update() ist endgültig weg (siehe Breaking Changes). Alle .update()-Aufrufe auf Document-Instanzen müssen .updateOne() werden.

2026.43.x

Atlas-Search Wiring für Hub-Module + neue Aggregation-Builder.

2026.42.x

Self-Documentation Foundation — KnowledgeBase und WikiPage-Schemas, Cross-Link-Resolver, Render-Hash-Idempotenz.

2026.41.1 — Self-Documentation Phase 1 (22. April 2026)

Erstmalig live: KB-/WikiPage-Modell, Markdown-Render, Atlas-Search-Wiring. Plus core.docs-Right.

Was kommt als nächstes?

Feature Geplante Version Status
Webhook-Signature-Verify Cross-cutting Fix 2026.51 in arbeit
State-Registry v3 (multi-tenant per-customer) 2026.52 design
await ay.shutdown (graceful) 2026.51 review

Verbindungen

Work with this page

Ready-made instructions for your AI tool. Copy, paste, go — the AI fetches the content itself via the address in the text.

Vertriebsunterlage daraus machen Nutzen und Einwaende statt Technik — fuer Gespraeche mit Interessenten.
Lies die folgende Dokumentation von tolinax UG und arbeite damit.

Diese Seite: https://ayoune.com/en/docs/release-notes/core-changelog.md
Die vollstaendige Sammlung: https://ayoune.com/en/docs/release-notes.md

Erstelle daraus eine **Vertriebsunterlage**. Nicht die Technik beschreiben, sondern:

1. Welches Problem loest das aus Kundensicht? In einem Satz.
2. Die drei staerksten Nutzen-Argumente, je mit dem technischen Beleg dahinter.
3. Fuer wen ist es NICHT geeignet — ehrlich, das schafft Vertrauen im Gespraech.
4. Die fuenf wahrscheinlichsten Einwaende und je eine belastbare Antwort.
5. Eine Kurzfassung von maximal 120 Woertern fuer die erste Mail.

Erfinde nichts. Wo die Quelle etwas nicht hergibt, schreib "nicht dokumentiert"
statt zu raten — eine erfundene Zusage im Vertrieb kostet spaeter mehr, als sie bringt.
Hinweis zu den Quellen:
- Jede Seite dieser Dokumentation ist als Markdown abrufbar (dieselbe Adresse mit `.md`).
- Ein maschinenlesbarer Ueberblick aller oeffentlichen Inhalte liegt unter `/llms.txt`.
- Falls du Zugriff auf den aYOUne-MCP-Server hast, kannst du damit gegen lebende Daten
  arbeiten statt gegen diese Momentaufnahme. Falls nicht, ignoriere diesen Punkt.
In einfachen Worten erklaeren Fuer Kolleginnen und Kollegen ohne Vorwissen im Thema.
Lies die folgende Dokumentation von tolinax UG und arbeite damit.

Diese Seite: https://ayoune.com/en/docs/release-notes/core-changelog.md
Die vollstaendige Sammlung: https://ayoune.com/en/docs/release-notes.md

Erklaere den Inhalt so, dass ihn jemand ohne Vorwissen versteht.

- Beginne mit dem Zweck: wozu gibt es das ueberhaupt?
- Fachbegriffe beim ersten Vorkommen in einem Halbsatz erklaeren.
- Ein Alltags-Vergleich, wo er wirklich traegt — keiner, wo er hinkt.
- Am Ende: die drei Dinge, die man sich merken sollte.

Kuerze nicht durch Weglassen von Einschraenkungen. Eine Vereinfachung, die eine
Bedingung unterschlaegt, ist eine Falschaussage.
Hinweis zu den Quellen:
- Jede Seite dieser Dokumentation ist als Markdown abrufbar (dieselbe Adresse mit `.md`).
- Ein maschinenlesbarer Ueberblick aller oeffentlichen Inhalte liegt unter `/llms.txt`.
- Falls du Zugriff auf den aYOUne-MCP-Server hast, kannst du damit gegen lebende Daten
  arbeiten statt gegen diese Momentaufnahme. Falls nicht, ignoriere diesen Punkt.
Einarbeitungs-Leitfaden bauen Ein Weg vom ersten Tag bis zur selbststaendigen Arbeit.
Lies die folgende Dokumentation von tolinax UG und arbeite damit.

Diese Seite: https://ayoune.com/en/docs/release-notes/core-changelog.md
Die vollstaendige Sammlung: https://ayoune.com/en/docs/release-notes.md

Baue daraus einen **Einarbeitungs-Leitfaden** fuer eine neue Person im Team.

- In Etappen gliedern, jede mit einem pruefbaren Ergebnis ("danach kannst du X").
- Reihenfolge nach Abhaengigkeit, nicht nach Wichtigkeit.
- Je Etappe: was zu lesen ist, was zu tun ist, woran man merkt, dass es sitzt.
- Benenne die Stellen, an denen erfahrungsgemaess Rueckfragen entstehen.

Wo die Dokumentation eine Luecke hat, markiere sie als offene Frage an das Team,
statt sie zu ueberbruecken.
Hinweis zu den Quellen:
- Jede Seite dieser Dokumentation ist als Markdown abrufbar (dieselbe Adresse mit `.md`).
- Ein maschinenlesbarer Ueberblick aller oeffentlichen Inhalte liegt unter `/llms.txt`.
- Falls du Zugriff auf den aYOUne-MCP-Server hast, kannst du damit gegen lebende Daten
  arbeiten statt gegen diese Momentaufnahme. Falls nicht, ignoriere diesen Punkt.
Luecken und offene Fragen finden Was fehlt, was widerspricht sich, was ist nicht belegt.
Lies die folgende Dokumentation von tolinax UG und arbeite damit.

Diese Seite: https://ayoune.com/en/docs/release-notes/core-changelog.md
Die vollstaendige Sammlung: https://ayoune.com/en/docs/release-notes.md

Pruefe die Dokumentation kritisch und benenne:

1. **Luecken** — was ein Leser braeuchte, aber nicht findet.
2. **Widersprueche** — Stellen, die sich gegenseitig ausschliessen.
3. **Unbelegtes** — Behauptungen ohne Beleg, Zahl oder Verweis.
4. **Veraltetes** — was nach Stand der Quelle ueberholt sein koennte.

Sortiere nach Auswirkung: was fuehrt einen Leser in die Irre, was ist nur unschoen.
Sei konkret mit Abschnitt und Zitat — eine allgemeine Kritik hilft niemandem.
Hinweis zu den Quellen:
- Jede Seite dieser Dokumentation ist als Markdown abrufbar (dieselbe Adresse mit `.md`).
- Ein maschinenlesbarer Ueberblick aller oeffentlichen Inhalte liegt unter `/llms.txt`.
- Falls du Zugriff auf den aYOUne-MCP-Server hast, kannst du damit gegen lebende Daten
  arbeiten statt gegen diese Momentaufnahme. Falls nicht, ignoriere diesen Punkt.
Fragen und Antworten ableiten Fuer Hilfe-Center, Support-Team oder die Produktseite.
Lies die folgende Dokumentation von tolinax UG und arbeite damit.

Diese Seite: https://ayoune.com/en/docs/release-notes/core-changelog.md
Die vollstaendige Sammlung: https://ayoune.com/en/docs/release-notes.md

Leite daraus **Fragen und Antworten** ab.

- Formuliere die Fragen so, wie ein Nutzer sie stellen wuerde — nicht in Fachsprache.
- Jede Antwort in zwei bis vier Saetzen, mit Verweis auf den Abschnitt der Quelle.
- Ordne nach Haeufigkeit, mit der die Frage vermutlich auftritt.
- Nimm auch die unangenehmen Fragen auf (Grenzen, Kosten, Voraussetzungen).

Nur Fragen, die die Quelle wirklich beantwortet.
Hinweis zu den Quellen:
- Jede Seite dieser Dokumentation ist als Markdown abrufbar (dieselbe Adresse mit `.md`).
- Ein maschinenlesbarer Ueberblick aller oeffentlichen Inhalte liegt unter `/llms.txt`.
- Falls du Zugriff auf den aYOUne-MCP-Server hast, kannst du damit gegen lebende Daten
  arbeiten statt gegen diese Momentaufnahme. Falls nicht, ignoriere diesen Punkt.
Arbeits-Checkliste erstellen Zum Abarbeiten waehrend der Umsetzung.
Lies die folgende Dokumentation von tolinax UG und arbeite damit.

Diese Seite: https://ayoune.com/en/docs/release-notes/core-changelog.md
Die vollstaendige Sammlung: https://ayoune.com/en/docs/release-notes.md

Mache daraus eine **abhakbare Checkliste** fuer die praktische Umsetzung.

- Je Punkt genau eine Handlung, im Imperativ.
- Reihenfolge so, dass kein Punkt eine spaetere Voraussetzung braucht.
- Voraussetzungen und Stolperstellen als eingerueckte Unterpunkte.
- Am Ende eine Abnahme: woran erkenne ich, dass alles richtig ist?
Hinweis zu den Quellen:
- Jede Seite dieser Dokumentation ist als Markdown abrufbar (dieselbe Adresse mit `.md`).
- Ein maschinenlesbarer Ueberblick aller oeffentlichen Inhalte liegt unter `/llms.txt`.
- Falls du Zugriff auf den aYOUne-MCP-Server hast, kannst du damit gegen lebende Daten
  arbeiten statt gegen diese Momentaufnahme. Falls nicht, ignoriere diesen Punkt.

Was this article helpful?

👎 No (0)
Leave a comment