Das Verhältnis zwischen mSCAILE und adSCAILE ist kein Konflikt. mSCAILE übernimmt den Intent von adSCAILE und löst ihn von der konkreten Mechanik — damit Entwickler das Framework mit ihren eigenen Tools anwenden können, ohne eine bestimmte Plattform vorauszusetzen.

adSCAILE auf drei Ebenen

Das erste, was man verstehen muss: "adSCAILE" ist kein einzelnes Dokument. Es existiert auf drei Abstraktionsebenen — und sie sind unterschiedlicher, als man denkt.

EBENE 01
Marketing-Website
5 Schritte, 4 Design-Merkmale. Überzeugt und positioniert. Behauptet "technologie-agnostisch" — und meint das auch so.
EBENE 02
Framework-Poster
10 Loops, 5 Rollen, konkrete Tools: Claude Code, Beads, Jira, Arc42, MCP Hub. Eine vollständige Referenzimplementierung.
EBENE 03
mSCAILE
8 Prinzipien, technologie-agnostisch. Handlungsspielraum für Ausgestaltung. Entwickler sollen das WARUM verstehen, nicht nur das WIE.

Die Marketing-Website ist dabei näher an mSCAILE als das Poster. Sie teilt den Anspruch "technologie-agnostisch" und verwendet ähnliche Konzepte: Fluent Process, Beyond Agile, Guided Automation. Das Poster dagegen ist eine Referenzimplementierung — wertvoll, aber toolspezifisch.

Wo die Konzepte übereinstimmen

adSCAILE-KonzeptmSCAILE-Entsprechung
Spec-Driven (Gherkin + Requirements Graph)Behavioral Contracts — Format frei, Struktur nicht (P2)
Human-in-the-Loop (5 definierte Rollen)"Der Mensch orchestriert, die KI implementiert" (P1)
Human Quality Gate nach ImplementationQualitätssicherung bleibt deterministisch (P6)
Git als Source of TruthEin Agent, ein Schritt, ein Commit (P4)
Traceability: Commit → Task → RequirementIntention explizit festhalten (P3)
Iterative Loops pro EPICPlan → Work → Assess → Compound Loop

Und die Prozess-Schritte der Website spiegeln sich direkt im mSCAILE-Loop:

adSCAILE-SchrittmSCAILE-Entsprechung
1. Systemanforderungen & ArchitekturPlan-Phase
2. KomponentenspezifikationP2 Spec-Driven (Behavioral Contracts)
3. Implementierung (Agent Loops)Work-Phase
4. Review & QualitätssicherungAssess-Phase + P6
5. Betrieb & WeiterentwicklungCompound-Phase + P8

Wo mSCAILE bewusst abweicht

Nicht alles am Poster funktioniert für ein Team von 1–3 Personen. Und manche Entscheidungen im Poster lösen Probleme, die in der KI-Ära anders gelöst werden sollten. Sechs bewusste Abweichungen:

Abweichung 01
Sequenzielle Loops → Einfacher iterativer Loop
adSCAILE
10 nummerierte Loops in fester Reihenfolge: Req Extraction → Refinement → Architecture → Spine → EPIC Structuring → 5 per-EPIC Loops.
mSCAILE
Ein einziger Loop (Plan → Work → Assess → Compound) mit kontextabhängiger Tiefe. Keine vorgeschriebene Reihenfolge.
Sequenzielle Phasen implizieren Wasserfall-Struktur. Ein einfacher Bugfix braucht keine 10 Loops — eine Iteration reicht. Die Sorgfalt skaliert mit dem Risiko, nicht mit dem Prozess.
Abweichung 02
5 spezialisierte Rollen → Rollenkollaps
adSCAILE
Product Owner, Software Architect, Developer/Orchestrator, Requirements Manager, QA Owner — separate Verantwortlichkeiten, eigene Tools.
mSCAILE
"Der Mensch orchestriert" (P1). Ein Mensch trägt mehrere Hüte. Rollenaufteilung ist Konfiguration, keine Voraussetzung.
In einem 1–3 Personen Setup ist Rollenaufteilung impraktikabel. mSCAILE adressiert den Einzelentwickler — für größere Teams kann man Rollen optional aufteilen.
Abweichung 03
Requirements Graph → Behavioral Contracts
adSCAILE
Zentraler Requirements Graph mit Embeddings, vollständige Traceability-Chain (Commit→Task→EPIC→Requirement), Gherkin als Format.
mSCAILE
Strukturelle Anforderung: Behaviors sind referenzierbare Einheiten, Tests verweisen darauf, Spec-Coverage ist das Maß. Format: frei.
Ein Requirements Graph ist ein Werkzeug, kein Prinzip. Entscheidend ist, dass Behaviors identifizierbar und Tests darauf referenzierbar sind — ob das mit Gherkin, YAML oder Markdown passiert, ist Implementierungsentscheidung.
Abweichung 04
Gherkin → Format-agnostisch
adSCAILE
Gherkin (Given/When/Then) als explizites Spec-Format durch den gesamten Prozess.
mSCAILE
Behavioral Contracts — format-agnostisch. Gherkin ist eine mögliche Ausgestaltung, nicht die einzige.
Gherkin hat Stärken, aber auch Einschränkungen. mSCAILE verschreibt sich dem Prinzip (Verhalten beschreiben), nicht dem Format.
Abweichung 05
Beads/Jira/EPIC → Isolierte Change-Units
adSCAILE
EPIC→Task-Hierarchie mit Jira-Synchronisation, Beads für git-native Task-Abstraktion, Worktrees für Parallelisierung.
mSCAILE
Changes als isolierte, selbstbeschreibende Einheiten. Kein Tooling vorgeschrieben.
Beads, Jira, OpenSpec oder ein simples Markdown-File sind alle valide, solange Changes isoliert und nachvollziehbar sind. Die Beispielimplementierung nutzt OpenSpec — aber das ist nicht normativ.
Abweichung 06
Spezifisches Tooling → Tool-agnostisch
adSCAILE
Benennt explizit: Claude Code, Beads, Jira, Confluence, Arc42, Context7, MCP Hub.
mSCAILE
Kein Tool vorgeschrieben. Die Prinzipien gelten unabhängig von Modell und IDE.
Im AI-Bereich ändern sich Tools monatlich. Tool-Lock-in widerspricht der Realität — und dem eigenen Anspruch "technologie-agnostisch".

Was mSCAILE hinzufügt

Vier Konzepte fehlen in adSCAILE vollständig — nicht weil sie vergessen wurden, sondern weil das Poster aus dem manuellen Paradigma kommt. mSCAILE ergänzt sie für die generative Ära:

Intent Ceiling — das "Warum" explizit halten (P3)

adSCAILE hat Traceability (Commit→Task→Requirement), aber kein Konzept für die Dokumentation des "Warum" hinter Entscheidungen. Code speichert das Wie, Tests das Was. Das Warum geht verloren, wenn es nicht aktiv dokumentiert wird.

In der Praxis: Die KI liest den Code und versteht ihn technisch. Aber sie kann nicht rekonstruieren, warum eine Architekturentscheidung so getroffen wurde. Im Zweifelsfall optimiert sie sie weg. ADRs und Decision Logs sind keine Bürokratie — sie sind das Gedächtnis des Projekts.

Compound — akkumulierendes Lernen (P8)

adSCAILE erwähnt "Continuous Improvement" in Schritt 5, aber ohne Mechanismus. mSCAILE macht das explizit: Am Ende jeder Iteration werden Zeit und Tokens investiert, um die nächsten Iterationen leichter zu machen — für Mensch und KI.

Ohne Compound arbeitet die KI bei jedem Durchlauf mit denselben Defaults. Macht dieselben Fehler, kennt dieselben Lösungen nicht, verbraucht Tokens für bereits gelöste Probleme. Mehr zu Compound →

Fail Fast — neu generieren statt debuggen (P7)

adSCAILE hat ein "Agent Refinement & Refactoring"-Gate, das iteratives Verbessern impliziert. Das passt zum manuellen Paradigma. mSCAILE sagt: KI-Output ist billig, Debugging ist teuer. Drei Runden Debugging sind oft langsamer als ein frischer Anlauf mit besserer Spec.

Deterministisch, was deterministisch sein kann (P5)

adSCAILE macht keine Unterscheidung zwischen LLM-Aufgaben und deterministischen. mSCAILE schon: npm run check-links ist besser als "Claude, prüfe alle Links". Deterministische Schritte brauchen keine Tokens, sind reproduzierbar und funktionieren noch, wenn das Token-Kontingent erschöpft ist.

Das Verhältnis in einer Zeile

adSCAILE (Framework — adesso-weit)
  ├─ Marketing-Website (Positionierung, 5 Steps)
  ├─ Poster (Referenzimplementierung, 10 Loops, konkretes Tooling)
  └─ mSCAILE (BL Microsoft: 8 Prinzipien + Enablement + eigene Implementierung)

mSCAILE übernimmt den Intent von adSCAILE — Spec-Driven Development, menschliche Kontrolle, Quality Gates, Git als Wahrheitsquelle — und löst ihn von der konkreten Mechanik. 8 Prinzipien statt Prozessvorschrift. Kein Tooling vorgeschrieben.

Das adSCAILE-Poster taugt als Ausgestaltung für größere Teams mit Rollenaufteilung und Enterprise-Tooling. mSCAILE ist die Implementierung für heute: realistisch, schlank, verständlich.