Technische Architektur

Repository, Steuerungsartefakte und Nachweisstruktur

Die Architektur dieses Projekts ist weniger eine Produktarchitektur im klassischen Sinne als eine Kombination aus Arbeitsarchitektur, Wissensarchitektur und technischer Nachweisstruktur. Sie schafft die Voraussetzung dafür, dass KI-gestützte Entwicklung nicht nur produktiv, sondern später auch prüfbar und auditierbar bleibt.

System View

Drei Ebenen, die zusammen Steuerbarkeit und Nachvollziehbarkeit tragen

1. Steuerungsebene

Jira verwaltet Status, Rollen, Reihenfolge, Historie, Freigaben und aktive Arbeit.

2. Wissensebene

Regeln, Anforderungen, Teststrategie, Reviewprozess und offene Punkte halten die langlebige Projektlogik fest.

3. Artefaktebene

Code, HTML-Dokumentation, Handover-Dateien und DOC-/DEV-/QA-Resultate liefern die konkreten Ergebnisse.

Repository

Wie die Dateistruktur die Organisation unterstützt

Sources/             technische Artefakte und Beispielcode
Tests/               Platzhalter für automatisierte Prüfungen
docs/                HTML- und Markdown-Dokumentation
project-control/     Anforderungen, Teststrategie, Reviews, offene Punkte, Resultate
project-rules/       verbindliche Rollen- und Prozessregeln

Warum diese Trennung sinnvoll ist

Steuerungswissen bleibt von Produktcode getrennt
Dokumentation kann wachsen, ohne den Projektkern zu überladen
Resultate und Handover-Dateien bleiben als auditierbare Artefakte greifbar

Technische Einstiegspunkte

Package.swift als technischer Startpunkt
Sources/HelloWorldCLI/main.swift als minimales lauffähiges Beispiel
docs/project-documentation.html als redaktioneller Starteinstieg

Betriebsarchitektur

Wie das Projekt im Alltag stabil, lesbar und nachweisfähig gehalten wird

Stabilität entsteht hier nicht durch große technische Plattformen, sondern durch kleine, klar definierte Kontrollpunkte: Jira-Status, Rollentrennung, verlinkte Artefaktpfade und sichtbare Restpunkte. Diese Kombination verhindert, dass Wissen ausschliesslich in flüchtigen Chatverläufen oder impliziten Annahmen steckt.

Besonders wichtig ist dabei die Regel, dass zentrale Projektdateien nur auf freigegebener Basis nachgezogen werden. So wird vermieden, dass unbestätigte Reviewmeinungen oder vorläufige technische Ideen ungeprüft in die dauerhafte Projektgrundlage einfließen. Gerade für sicherheitsnahe, kritische oder später zertifizierte Systeme ist diese Trennung zwischen Arbeitsstand und freigegebener Basis zentral.

Lifecycle

Welche Pflegefälle die Architektur berücksichtigt

Regelupdate

Eine Änderung in `project-rules/` führt zu Rollout-Tickets, Rücklesebestätigungen und gegebenenfalls Folgeanpassungen in Dokumentationsartefakten.

Review-Rückkopplung

Findings aus DEV-, QA-, PM- oder Chef-Reviews werden in handhabbare Nachbesserungstickets übersetzt und dann zielgerichtet in Artefakte eingearbeitet.

Onboarding neuer Rollen

Neue Bearbeiter finden Einstieg über `README`, Rollenregel, Dokumentationssatz und die jeweils passende Jira-Arbeitsliste.

Architekturgrenzen

Was diese Architektur bewusst noch nicht behauptet

Noch nicht vollständig festgelegt

verbindliche technische Konventionen für spätere Implementierungsarbeit
eine feingranulare Produktarchitektur jenseits der Projektorganisationsbasis
eine abgeschlossene mehrstufige Release- oder Deployment-Architektur

Warum diese Zurückhaltung wichtig ist

sie verhindert spekulative Dokumentation
sie hält die Projektgrundlage ehrlich und anschlussfähig
sie macht offen, welche Entscheidungen später noch zu treffen sind