Architekturvorgaben

Verfügbar auf dedizierten Instanzen, auf denen nyxory die Funktion für Sie einschaltet. Auf der gemeinsamen Plattform derzeit nicht.

Ihre Organisation weiß bereits, wie Software gebaut werden soll, also von welchen Vorlagen Teams ausgehen, welche Technologien die Cloud-Strategie erlaubt und was die Plattform zentral bereitstellt. Auf einer dedizierten Instanz schreiben Sie das einmal auf. Jeder Coding-Agent erfährt es aus nyx_brain, bevor er Code schreibt, die Plattform lehnt einen Rollout ab, der dagegen verstößt, und ein Team, das abweichen muss, beantragt eine Ausnahme, über die ein Mensch entscheidet.

Ein Workspace ohne Vorgaben verhält sich genau wie bisher.

Die Architecture-Seite

Öffnen Sie in der Console Settings › Architecture. Die Seite hat fünf Abschnitte, in dieser Reihenfolge:

Architekturverantwortliche sind eine kleine Gruppe von Personen pro Instanz, typischerweise Ihr Architektur- oder Plattformteam. nyxory vergibt die Rolle auf Ihrer Instanz. Mitglieder und Agenten lesen alles, was sie zum Bauen brauchen. Vorgaben ändern und über Ausnahmen entscheiden nur Menschen, nie ein Agent.

Referenzarchitekturen

Eine Referenzarchitektur ist eine Vorlage für eine Art von Software, mit ihrem Zweck, den Plattform-Bausteinen, die sie nutzt, und einer Bauanleitung, der der Agent folgt. Die Seite zeigt sie als Galerie, jede mit ihrem Architekturdiagramm.

• From nyxory sind die Vorlagen, die nyxory pflegt, etwa eine Web-App mit Postgres oder ein Agent mit dem KI-Gateway. Eine Vorlage, die nicht zu Ihrer Cloud-Strategie passt, erscheint ausgegraut mit dem Grund und wird den Agenten nicht angeboten.
• Own sind Ihre eigenen Vorlagen und gelten für alle Workspaces auf der Instanz. Sie werden vor denen von nyxory angeboten.

Create reference architecture öffnet einen Editor mit Live-Vorschau. Eine Vorlage ist Markdown mit einem YAML-Kopf:

---
id: web-service-postgres
title: Web service with Postgres
purpose: Web service on the platform's Postgres database.
signals: [web service, node, api, postgres, database]
components: [postgres, public_url]
diagram:
  nodes:
    - {id: web, kind: ingress, label: "Public URL"}
    - {id: app, kind: app, label: "Web service"}
    - {id: db, kind: postgres, label: "Postgres"}
  edges: [[web, app], [app, db]]
---
## Build instructions
…

id, title, purpose, signals und entweder diagram oder image sind Pflicht. signals sind die Schlüsselwörter, über die ein Vorhaben der Vorlage zugeordnet wird. Braucht die Vorlage über die Plattform-Bausteine hinaus eine Technologie, gehört sie unter technologies, jeweils mit einem reason. Die Console prüft sie gegen Ihre Cloud-Strategie und warnt beim Speichern, und das Architektur-Review nennt dann den Konflikt. In der Bauanleitung setzt die Console __APP__, __NAMESPACE__, __REGISTRY__ und __GATEWAY__ ein. Bei jedem Speichern erhöht sie version. Projekte, die aus einer älteren Version gebaut wurden, zeigen „newer version available“, und für sie wird nichts neu gebaut.

Cloud-Strategie

Fügen Sie die Cloud-Strategie Ihrer Organisation mit Insert strategy ein. Architekturverantwortliche wählen unter Where should the strategy apply?:

• For the whole instance wendet sie auf alle Workspaces dieser Instanz an.
• Only for this workspace wendet sie zusätzlich hier an. Dieser Workspace wird strenger, alle anderen bleiben, wie sie sind.

Workspace-Inhaber und Admins ohne die Rolle bekommen für den zweiten Fall Make it stricter for this workspace. Ein Workspace kann die instanzweite Strategie ergänzen, aber nie lockern.

Das KI-Modell, das mit Ihrer Instanz verbunden ist, liest sie Abschnitt für Abschnitt und macht daraus Vorschläge, jeweils mit dem Satz aus dem Dokument und der Stelle, an der er steht. Ein Vorschlag, dessen Satz nicht wörtlich im Dokument steht, wird verworfen. Es gilt nichts, bis Sie einen Vorschlag mit Adopt übernehmen, einzeln oder mit Adopt all.

Eine Vorgabe hat eine von zwei Formen:

• Databases: only PostgreSQL erlaubt in einer Kategorie eine oder mehrere Technologien und schließt den Rest der Kategorie aus.
• Kafka: not allowed schließt eine einzelne Technologie aus.

Bei jeder Vorgabe steht, wo die Plattform sie erkennt: im Code, im Container-Image, in der Stückliste. Eine Technologie, die die Plattform nicht kennt, erreicht trotzdem den Agenten, und die Seite markiert sie mit „unknown to the platform: the agent is told, it is not enforced“.

Eine neue Fassung des Dokuments kommt über Insert new version herein und zeigt ihre Vorschläge als Unterschied zur aktuellen Fassung. Den vollständigen Text sehen nur Personen, die die Strategie ändern dürfen. Alle anderen, Agenten eingeschlossen, sehen die Vorgaben mit ihrem Satz.

Plattform-Bausteine

Für jeden Baustein antwortet ein Workspace mit allowed oder no. Ein no braucht einen Reason, und Sie können eine Note for the agent on what to use instead ergänzen, zum Beispiel die zentrale Datenbank und das Secret, in dem ihre Zugangsdaten liegen. Beides erreicht den Agenten wörtlich.

Unter den Bausteinen listet Still running although no longer allowed auf, was schon vor einer Vorgabe da war und weiterläuft. Es bleibt unangetastet. Dazu gehören laufende Container, deren Image unter eine Technologievorgabe der Cloud-Strategie fällt, etwa ein Container mysql:8 nach „Databases: only PostgreSQL“. Für jeden davon führt Request exception zum Ausnahmeformular des Projekts, falls er weiterlaufen soll.

Was Ihr Coding-Agent bekommt

Der Agent ruft nyx_brain mit dem Projekt auf und beschreibt in agent_briefing sein Vorhaben, also was er baut, seine Komponenten und seine Datenspeicher. Zusätzlich zum Cookbook enthält die Antwort:

Der Agent wählt eine Vorlage und ruft nyx_brain erneut auf, mit reference auf ihre id gesetzt. Die Antwort ist die Bauanleitung mit den eingesetzten Werten des Projekts. Rollt der Agent danach aus derselben Sitzung aus, gilt das Projekt als aus dieser Vorlage gebaut, und die Seite der Vorlage führt es auf.

Ihre Vorgaben haben Vorrang vor jedem Rezept im Cookbook und jeder Referenzarchitektur. Die Repo-Prüfung liest Abhängigkeiten, Basis-Images im Dockerfile und Services in einer Compose-Datei. Was sie nicht lesen konnte, benennt sie, und der Agent prüft diesen Teil selbst.

Was beim Rollout passiert

Die Plattform prüft jeden neuen Rollout gegen die Vorgaben, auf jedem Weg ins Projekt: nyx_deploy_manifests, ein Push mit einem Ordner deploy/ und kubectl über nyx_shell. Ein Rollout, der gegen eine Vorgabe verstößt, wird abgelehnt, bevor irgendetwas angewendet wird. Die Meldung beginnt mit einem Code, den der Agent lesen kann, hier umbrochen dargestellt:

requirement:denied:technology:mysql: image "mysql:8"
(mysql) is not allowed in workspace "Orders". …

Der Code lautet requirement:denied:<rule>, bei einer Technologie requirement:denied:technology:<name>. Der Rest der Meldung enthält den Grund, die Alternative, den Hinweis für den Agenten, falls Sie einen gesetzt haben, und wie man eine Ausnahme beantragt. Auf manchen Wegen steht vor dem Code ein Präfix, deshalb sucht der Agent überall in der Meldung nach requirement:. Wird ein Push mit deploy/ abgelehnt, bleibt die laufende Version in Betrieb.

Laufende Workloads bleiben unangetastet. Vorgaben gelten für das, was angelegt oder geändert wird. Ein Update wird nur auf Images geprüft, die darin neu sind, und ein Arbeitsspeicherlimit zu senken funktioniert immer.

Ausnahme beantragen

Braucht ein Projekt etwas, das eine Vorgabe ausschließt, beantragt der Agent mit nyx_exception_request eine Ausnahme. Ein Mitglied macht dasselbe im Projekt, unter Settings › Architecture mit Request exception.

Die Antwort ist der Antrag mit seinem Status, und created sagt, ob er neu ist. Wer dasselbe noch einmal beantragt, bekommt den offenen Antrag oder die bereits geltende Ausnahme zurück statt eines zweiten Antrags. Ein Projekt hat höchstens zehn offene Anträge.

Ein Mensch entscheidet, nie ein Agent. Architekturverantwortliche sehen den Antrag unter Exceptions, mit seiner Begründung und der Person, die ihn gestellt hat, und wählen Approve oder Reject. Eine Ablehnung braucht eine Begründung, damit das Team weiß, was es stattdessen tun soll. Wer entscheidet, kann aus derselben Auswahl eine andere Laufzeit wählen. Eine freigegebene Ausnahme gilt nach etwa einer Minute, in der Prüfung beim Rollout und in der nächsten Antwort von nyx_brain. Der Agent sagt Ihnen, dass der Antrag auf eine Entscheidung wartet, und plant bis dahin mit der Alternative.

Eine Ausnahme durchläuft diese Zustände:

Vierzehn Tage vor dem Ende einer Ausnahme weisen der Betriebs-Feed und die Alarmkanäle des Projekts darauf hin. Läuft sie ab oder wird sie widerrufen, bleibt bestehen, was läuft, und ein neuer Rollout dieser Technologie wird wieder abgelehnt. Eine Ausnahme mit unlimited läuft nie ab.

Beispiel: vom Vorhaben zur freigegebenen Ausnahme

Ein Team baut einen Bestellservice. Ihre Cloud-Strategie sagt „Databases: only PostgreSQL“, und das Team liefert außerdem ein Reporting-Tool aus, das nur auf MySQL läuft.

Siehe auch: MCP-Tools · App aus dem Repo konfigurieren · Das Cookbook