AEPS – Agentic Engineering Preset System: Strategic Initiative and Preset Consolidation

[hindermath]

AEPS – Agentic Engineering Preset System

Zweck

Dieses Issue verankert AEPS – Agentic Engineering Preset System als langfristige strategische Initiative im Level-0-System-of-Record.

AEPS soll ein evidenzbasiertes, modular aufgebautes Preset-System für professionelles Agentic Engineering werden. Es überführt wiederkehrende Findings, Learnings, Governance-Verträge, Review-Muster und bewährte Arbeitsweisen aus realen Projekten in wiederverwendbare Spec-Kit- und GitHub-Presets.

Leitgedanke:

Beschreiben, was erreicht werden soll. Das System unterstützt den Menschen dabei, die operativen Details kontrolliert, nachvollziehbar und evidenzbasiert durch KI-Agenten ausführen zu lassen.

AEPS ist damit kein einzelnes Preset und kein einzelnes Produkt. Es ist ein kuratiertes Preset-System und ein Engineering-Wissenskreislauf.

---

1. Strategisches Ziel

Referenzprojekt
    ↓
Findings und Learnings
    ↓
Review und Evidence
    ↓
Pattern und Anti-Pattern
    ↓
Candidate Preset
    ↓
projektübergreifende Validierung
    ↓
Stable / Canonical Preset
    ↓
nächstes Projekt

AEPS soll langfristig ermöglichen:

• deklaratorisches Arbeiten,
• explizite menschliche Verantwortung,
• kontrollierte Einzel-, Serien- und Parallel-Autonomie,
• reproduzierbare Requirements-, Review- und Evidence-Prozesse,
• systematische Rückführung von Projekterfahrung in Presets,
• projektübergreifende Wiederverwendung bewährter Engineering-Verträge.

---

2. Verhältnis zu bestehenden Systemen

Home Baseline / Level 0

Home Baseline bleibt:

• System of Record,
• Governance- und Preset-Unterbau,
• Fleet- und Maintenance-Plattform,
• Ort für projektübergreifende Preset-Kandidaten und deren Promotion.

Agent Operations Cockpit / Level 2

AOC ist:

• erstes großes Referenz- und Feldprojekt für AEPS,
• Konsument bestehender Presets,
• Lieferant neuer Findings, Evidence und Preset-Kandidaten,
• kein Eigentümer des gesamten AEPS.

Weitere Referenzprojekte

Bestehende und zukünftige Projekte wie TuiVision, TinyPl0, TinyCalc und weitere Level-2-Repositories können AEPS-Presets anwenden, validieren und weiterentwickeln.

---

3. Bestehende GitHub-Presets sind Teil von AEPS

Die bereits vorhandenen GitHub- und Repository-Governance-Presets des Maintainers sind ausdrücklich Bestandteil der AEPS-Ausgangsbasis.

Sie dürfen nicht als separates oder konkurrierendes Preset-System behandelt werden.

Phase 1 der AEPS-Konsolidierung muss daher:

• alle vorhandenen GitHub-Presets inventarisieren,
• ihren Zweck und ihre Autorität dokumentieren,
• Überschneidungen und Lücken analysieren,
• bestehende stabile Verträge bewahren,
• Kandidaten für Umbenennung, Gruppierung oder Konsolidierung ableiten,
• keine Presets allein wegen der Einführung des Namens AEPS vorschnell verändern.

Die tatsächliche Struktur muss aus den vorhandenen Repository-Artefakten und ihrer Feldnutzung abgeleitet werden, nicht aus einer theoretischen Neuordnung.

---

4. Vorgeschlagene AEPS-Domänen

Die folgenden Domänen sind eine Arbeitshypothese und müssen gegen vorhandene Presets geprüft werden:

1. Program Governance

   • Program Charter
   • Meta Initiative
   • Execution Contract
   • Engineering Session
   • Program-to-Knowledge

2. Requirements Engineering

   • Lastenheft
   • Decision Intake
   • Ownership Matrix
   • Series Planning
   • Coverage Matrix

3. Review and Evidence

   • Review Findings Ledger
   • Authoring Receipt
   • Review Receipt
   • Completion Receipt
   • Evidence Plan
   • Retrospective

4. Agent Authority and Execution

   • Authority Gates
   • Human-in-the-Loop
   • Execution Nodes
   • Side-Effect Classes
   • Stop Gates

5. Repository and GitHub Governance

   • Public Readiness
   • Branch- und PR-Verträge
   • CI- und Security-Gates
   • Maintenance und Fleet Integration
   • Release- und Merge-Verträge

6. Accessibility and Communication

   • WCAG 2.2 AA
   • CEFR B2
   • DE-first / EN-second
   • Glossar und Terminologie
   • Ausbildungsgeeignete Dokumentation

7. Multi-Agent and Parallel Work

   • Eligibility
   • Schreibbereichs-Isolation
   • Parallel-Autonomie
   • Integrationsstrategie
   • Recovery und Konfliktauflösung

---

5. Preset-Lebenszyklus

AEPS benötigt einen eigenen evidenzbasierten Lebenszyklus:

Idea
    ↓
Project Finding
    ↓
Pilot Pattern
    ↓
Candidate Preset
    ↓
Cross-Project Validation
    ↓
Stable Preset
    ↓
Canonical Preset
    ↓
Revision or Deprecation

Jede Promotion benötigt mindestens:

• Herkunft und Problemstatement,
• betroffene Projekte,
• positive und negative Evidence,
• Review-Ergebnis,
• bekannte Grenzen,
• Rückwärtskompatibilität,
• Revisionsbedingungen,
• Migrations- oder Deprecation-Strategie.

Ein einzelner erfolgreicher Lauf reicht nicht für eine kanonische Promotion.

---

6. Erste Arbeitsphasen

Phase 1 – Bestand verstehen

• vorhandene GitHub-, Governance- und Spec-Kit-Presets inventarisieren,
• Preset-Ownership und Autorität dokumentieren,
• aktuelle Nutzung in Referenzprojekten erfassen,
• bestehende Findings und Preset-Kandidaten zuordnen,
• Taxonomie und Namensmodell als Vorschlag erstellen,
• keine Presets verändern oder promoten.

Phase 2 – AEPS-Baseline definieren

• AEPS Charter,
• Preset Registry,
• Preset Lifecycle Contract,
• Compatibility- und Supersession-Regeln,
• Candidate Intake und Evidence-Vertrag,
• erste konsolidierte Domänenstruktur.

Phase 3 – Pilot und Validierung

• ausgewählte bestehende Presets unter AEPS klassifizieren,
• AOC und mindestens ein weiteres Projekt als Piloten verwenden,
• Abweichungen und False Positives erfassen,
• erst danach stabile AEPS-Presets promoten.

---

7. Nicht-Ziele dieses Issues

Dieses Issue autorisiert noch nicht:

• Umbenennung aller bestehenden Presets,
• Verschieben oder Löschen vorhandener Presets,
• Änderung der AOC-Produktarbeit,
• automatische Preset-Promotion,
• Erstellung eines separaten AEPS-Repositories,
• öffentliche Produkt- oder Markenentscheidung,
• Implementierung eines AEPS-Runtime-Systems.

Es verankert zunächst Begriff, Ziel, Systemgrenzen und Konsolidierungsauftrag.

---

8. Erwartete erste Deliverables

• Preset Inventory
• Existing GitHub Preset Map
• Preset Ownership Matrix
• AEPS Domain Map
• Finding-to-Preset Coverage Matrix
• Candidate Preset Register
• Preset Lifecycle Proposal
• Repository Placement Recommendation
• Completion Receipt mit klarer Stop-Grenze

---

Definition of Done

• AEPS ist als langfristige strategische Initiative im Level-0-System-of-Record verankert.
• Der Leitgedanke des deklaratorischen Agentic Engineering ist dokumentiert.
• Bestehende GitHub-Presets sind ausdrücklich Teil der AEPS-Ausgangsbasis.
• AOC ist als Referenzprojekt, nicht als Eigentümer des AEPS, eingeordnet.
• Ein evidenzbasierter Preset-Lebenszyklus ist als Arbeitshypothese definiert.
• Phase 1 beginnt mit Inventur und Review, nicht mit vorschneller Umstrukturierung.
• Keine laufende Level-2-Produktarbeit wird durch dieses Issue umgeleitet oder blockiert.

[hindermath]

Erste AEPS-Preset-Kandidaten aus AOC- und Level-0-/Level-1-Arbeit

Die bisherige AOC-Vorbereitung und Umsetzung liefert bereits belastbare, aber noch nicht automatisch promotionsreife Preset-Kandidaten. Sie werden hier zunächst als Candidate Findings verankert. Ein separates Folge-Issue ist sinnvoll, sobald die strukturierte Inventur, Cross-Project-Validierung oder tatsächliche Preset-Promotion beginnt.

Einordnung

Diese Ableitungen stammen aus:

• der strategischen und operativen Vorarbeit in home-baseline,
• den Issues Meta-Initiative: Agent Operations Console – kanonische Lastenheft- und Decision-Intake-Reihe #156–AOC Phase 2 Contract: Public Level-2 Repository and Self-Generating Spec-Kit Lastenheft Program #182 und ihren Completion Receipts,
• der Level-0-/Level-1-Übergabe,
• dem Aufbau des öffentlichen Level-2-Repositories hindermath/agent-operations-cockpit,
• den AOC-PRs chore(main): release 0.4.0 #3, chore(main): release 0.4.2 #5 und chore(main): release 0.5.0 #6,
• dem AOC-Maintenance-Issue chore(main): release 0.4.1 #4,
• der validierten Lastenheft-, Review-, Decision-, Evidence- und Series-Struktur.

Sie sind daher als Pilot Evidence einzustufen. Für Stable oder Canonical ist zusätzliche projektübergreifende Evidence erforderlich.

---

CAND-AEPS-01 – Development Readiness Gate

Problem: Strategische Issues, Bootstrap-Kontext, Execution Contract und Implementierungsautorität können konkurrierende Einstiegspunkte erzeugen.

Preset-Kandidat: Ein verbindliches Readiness-Gate vor Repository-Erzeugung, Lastenheft-Authoring oder Implementierung.

Mindestbestandteile:

• kanonische Quellenhierarchie,
• Konfliktregel,
• erlaubter und nicht erlaubter Scope,
• Phasenautorität,
• explizite Stop-Grenze,
• erwartete Deliverables,
• Completion Receipt.

Evidence: #180, #181, #182; erfolgreicher Übergang von reiner Analyse zu kontrollierter Phase 2.

Vorgeschlagene AEPS-Domäne: Program Governance / Agent Authority.

---

CAND-AEPS-02 – Review Findings Ledger und Coverage Gate

Problem: Umfangreiche Review-Ergebnisse können in Zusammenfassungen verschwinden und ohne Wirkung auf spätere Lastenhefte bleiben.

Preset-Kandidat: Stabile Finding-IDs mit Coverage bis auf Lastenheft-, Decision-, Akzeptanzkriterien- und Evidence-Ebene.

Mindestbestandteile:

• Finding-ID,
• Quelle,
• Severity,
• Owner-Reihe,
• Zielartefakt,
• Akzeptanzkriterium,
• positive und negative Evidence,
• Coverage-Status,
• Restlücke.

Gate: Blocking Findings dürfen vor Authoring- oder Execution-Freigabe nicht uncovered bleiben.

Evidence: RF-01 bis RF-21 und AOC Coverage-Struktur.

Vorgeschlagene AEPS-Domäne: Review and Evidence / Requirements Engineering.

---

CAND-AEPS-03 – Selbsttragender Level-2-Handoff

Problem: Produktprojekte dürfen nicht dauerhaft von verstreuten strategischen Artefakten im Level-0-Repository abhängen.

Preset-Kandidat: Ein Handoff-Vertrag, der alle relevanten Constraints, Findings, Authority Gates, Glossare und Provenienz in das Level-2-Repository überführt.

Regel:

• Level-0-Referenzen dienen der Provenienz,
• Level-2 enthält die vollständige operative Fachbasis,
• keine versteckte Inhaltsabhängigkeit zu Level-0-Lastenheften,
• Home Baseline bleibt Governance- und Tooling-Unterbau, nicht Produktlaufzeitabhängigkeit.

Evidence: AOC Phase-2-Baseline und Abschluss von #180–#182.

Vorgeschlagene AEPS-Domäne: Repository Governance / Program Governance.

---

CAND-AEPS-04 – Meta-Lastenheft-Programm

Problem: Große Initiativen benötigen nicht nur einzelne Lastenhefte, sondern eine reproduzierbare Methode, aus Quellen und Findings ein vollständiges Portfolio zu erzeugen.

Preset-Kandidat: Eine Meta-Reihe zur Erzeugung und Governance aller fachlichen Lastenhefte.

Erprobte Struktur:

1. Quellen, Constraints und vollständige Inhaltsübernahme,
2. Lastenheft-Portfolio und Ownership,
3. Authoring Contract und Generator,
4. Series-Planung, Eligibility und Parallelität,
5. Erzeugung der ersten vollständigen Lastenheft-Welle.

Evidence: META-LH-01 bis META-LH-05 im AOC-Repository.

Vorgeschlagene AEPS-Domäne: Requirements Engineering.

---

CAND-AEPS-05 – Single Ownership und azyklische Series

Problem: Lastenheft-Reihen können konkurrierende Wahrheiten, Redundanz und zyklische Abhängigkeiten erzeugen.

Preset-Kandidat: Ownership-, Non-Ownership-, Handoff- und Series-Graph-Vertrag.

Mindestregeln:

• jeder Concern besitzt genau eine kanonische Owner-Reihe,
• andere Reihen referenzieren nur,
• Abhängigkeiten werden als DAG validiert,
• Decision- und Evidence-Abhängigkeiten sind Teil des Graphen,
• Roots und Gates sind explizit.

Evidence: 14 Targets, 1 Root, 14 Kanten, zyklusfrei; neun fachliche Owner-Reihen.

Vorgeschlagene AEPS-Domäne: Requirements Engineering / Multi-Agent Work.

---

CAND-AEPS-06 – Decision-Resolution vor Specify

Problem: Offene Architektur-, Security- oder Produktentscheidungen dürfen nicht durch Templates oder Agentenläufe stillschweigend entschieden werden.

Preset-Kandidat: Ein Decision-Intake- und Clarification-Gate vor speckit.specify, Plan oder Implementierung.

Mindestregeln:

• offene Decisions werden explizit dokumentiert,
• NeedsClarification ist ein planmäßiger Status,
• keine implizite Entscheidung durch Scaffold oder Template,
• nach Entscheidung werden Lastenheft, Review und Eligibility aktualisiert,
• erst danach darf Specify starten.

Evidence: 13 dokumentierte menschliche Decision Intakes in RAW-02, RAW-06, RAW-07 und RAW-09.

Vorgeschlagene AEPS-Domäne: Requirements Engineering / Agent Authority.

---

CAND-AEPS-07 – Kontrollierte Autonomie je Workitem

Problem: Autonomie darf nicht pauschal auf ein Projekt oder eine Initiative angewandt werden.

Preset-Kandidat: Eligibility- und Execution-Mode-Klassifikation je Lastenheft oder Workitem.

Erprobte Modi:

• manual-assisted,
• single-autonomous,
• serial-autonomous,
• parallel-autonomous,
• research-only,
• blocked.

Mindestregeln für Parallelität:

• disjunkte oder kontrolliert koordinierte Schreibbereiche,
• keine gemeinsame offene Decision-Abhängigkeit,
• geplante Integration und Review,
• Recovery- und Abbruchregeln,
• ausdrückliche Authority.

Vorgeschlagene AEPS-Domäne: Multi-Agent and Parallel Work.

---

CAND-AEPS-08 – Evidence- und Receipt-Vertrag

Problem: Agentenergebnisse sind ohne strukturierte Evidence und Abschlussnachweis schwer prüfbar und nicht zuverlässig wiederverwendbar.

Preset-Kandidat: Einheitliche Authoring-, Review-, Decision-, Evidence- und Completion-Receipts.

Mindestbestandteile:

• ausgeführter Scope,
• gelesene Quellen,
• erzeugte Artefakte,
• Validierungen,
• offene Decisions und Blocker,
• negative Evidence,
• ausdrücklich nicht ausgeführte Aktionen,
• nächster zulässiger Schritt.

Evidence: 14/14 gültige Authoring Receipts, Review-, Decision-, Evidence- und Completion-Receipts im AOC.

Vorgeschlagene AEPS-Domäne: Review and Evidence.

---

CAND-AEPS-09 – Maintenance als getrennte Level-2-Arbeit

Problem: Nach Bootstrap und Fleet-Registrierung können zentrale Maintenance-Differenzen entstehen, die nicht mit Produkt- oder Requirements-Arbeit vermischt werden dürfen.

Preset-Kandidat: Ein Maintenance-Synchronisationsvertrag mit eigenem Issue, Preview, Diff-Review, Validierung, Merge und Completion Evidence.

Mindestregeln:

• Dry-run vor schreibender Propagation,
• projektspezifische Anpassungen schützen,
• Maintenance, Produktarbeit und Decision Intakes getrennt halten,
• current-Nachweis nach Merge,
• vollständiger Fleet-Check,
• datumssensitive Generated Artifacts als eigener Minimal-Follow-up.

Evidence: AOC-Issue #4, PR #5 und Statistik-Follow-up PR #6.

Vorgeschlagene AEPS-Domäne: Repository and GitHub Governance.

---

CAND-AEPS-10 – Public-Readiness- und Multi-Platform-Baseline

Problem: Public by design darf nicht mit ungeprüfter Veröffentlichung verwechselt werden.

Preset-Kandidat: Ein Public-Readiness-Gate für neue öffentliche Level-2-Repositories.

Mindestprüfungen:

• Secrets und persönliche Pfade,
• Lizenz, Security und Contribution Guidance,
• Branch-/Merge-Vertrag,
• Dependency- und Vulnerability-Prüfung,
• .NET-/Toolchain-Vertrag auf Linux, Windows und macOS,
• Bash- und PowerShell-Parität,
• Homogeneity und statische Analyse.

Evidence: AOC Repository-Baseline, Secret Scan, .NET-Vertrag und grüne Plattformprüfungen.

Vorgeschlagene AEPS-Domäne: Repository and GitHub Governance.

---

CAND-AEPS-11 – Accessibility-, Ausbildungs- und Sprachbaseline

Problem: Agentisch erzeugte Artefakte können fachlich korrekt, aber unnötig schwer verständlich oder nicht zugänglich sein.

Preset-Kandidat: Verbindliche Communication- und Accessibility-Baseline.

Regeln:

• Zielgruppe einschließlich IHK-IT-Auszubildender ab dem 1. Ausbildungsjahr,
• CEFR B2,
• DE-first, EN-second,
• Fachbegriffe erklären oder im Glossar verankern,
• WCAG 2.2 AA für anwendbare Oberflächen und Dokumentationsmuster,
• keine ausschließlich farbcodierte Bedeutung,
• semantische Struktur und Tastaturbedienbarkeit.

Evidence: Phase-2-Vertrag und AOC-Lastenheftbaseline.

Vorgeschlagene AEPS-Domäne: Accessibility and Communication.

---

CAND-AEPS-12 – Engineering Session als Knowledge-Quelle

Problem: Wesentliche Architekturentscheidungen und Learnings entstehen häufig in langen Arbeits- und Review-Sitzungen und können außerhalb der versionierten Wissensbasis verloren gehen.

Preset-Kandidat: Engineering-Session-Archiv mit standardisiertem Header, Entscheidungen, Findings, verworfenen Alternativen, Outputs und Provenienz.

Evidence: docs/engineering-sessions/ in home-baseline, PR #183.

Vorgeschlagene AEPS-Domäne: Program Governance / Review and Evidence.

---

Vorläufige Bewertung

Kandidat	Reifegrad	Nächste Evidence
CAND-AEPS-01 Readiness Gate	Pilot Pattern	Anwendung in weiterem Level-2-Projekt
CAND-AEPS-02 Findings Coverage	Pilot Pattern	Cross-Project-Review
CAND-AEPS-03 Level-2-Handoff	Pilot Pattern	zweites eigenständiges Produktrepository
CAND-AEPS-04 Meta-Lastenhefte	Pilot Pattern	erneute Portfolio-Generierung
CAND-AEPS-05 Ownership/DAG	Pilot Pattern	komplexere parallele Series
CAND-AEPS-06 Decision Gate	Candidate	erfolgreiche Decision-Resolution und erster Specify-Lauf
CAND-AEPS-07 Autonomie-Modi	Candidate	reale serielle und parallele Agentenläufe
CAND-AEPS-08 Receipts	Pilot Pattern	Vergleich mehrerer Projekte
CAND-AEPS-09 Maintenance Sync	Pilot Pattern	weitere Fleet-Ziele und Upgrades
CAND-AEPS-10 Public Readiness	Pilot Pattern	zweites öffentliches Repository
CAND-AEPS-11 A11Y/CEFR/DE-EN	Candidate	Review realer Produktdokumentation und UI
CAND-AEPS-12 Engineering Sessions	Candidate	wiederholte Sessions und Retrieval-Nutzung

Empfehlung zur Issue-Struktur

• AEPS – Agentic Engineering Preset System: Strategic Initiative and Preset Consolidation #196 bleibt das strategische AEPS-Anchor-Issue und enthält diese erste Candidate Map.
• Ein neues Folge-Issue sollte erstellt werden, sobald Phase 1 tatsächlich gestartet wird: Preset Inventory, Existing GitHub Preset Map, Ownership Matrix und Finding-to-Preset Coverage.
• Einzelne Preset-Promotionen erhalten später eigene Issues, damit Evidence, Versionierung, Kompatibilität und Rollout getrennt reviewbar bleiben.

Diese Kandidaten autorisieren noch keine Preset-Änderung oder Promotion.

[hindermath]

Verbindlicher Härtungsweg für AEPS-Findings aus Level-2-Projekten

Dieses Issue verankert folgenden projektübergreifenden Arbeitsweg:

Level-2-Referenzprojekt
    Beobachtung und Finding
        ↓
    Reproduktion und negative/positive Evidence
        ↓
    unabhängiges Review
        ↓
    projektbezogenes Pattern oder Anti-Pattern
        ↓
    AEPS-Preset-Kandidat mit Upstream-Verweis auf #196
        ↓
Level 0 / Home Baseline
    projektübergreifende Konsolidierung
        ↓
    Cross-Project Validation
        ↓
    Candidate-, Stable- oder Canonical-Promotion

Rollen und Autorität

Level 2 ist der Ort für Entdeckung, Erprobung und Härtung:

• Findings aus realer Produkt- und Governance-Arbeit,
• reproduzierbare Evidence,
• Grenzen und Gegenbeispiele,
• projektbezogene Review-Ergebnisse,
• erste Pattern- und Anti-Pattern-Hypothesen.

Level 0 bleibt das AEPS-System-of-Record für:

• Preset-Inventar und Ownership,
• projektübergreifende Konsolidierung,
• Compatibility- und Supersession-Regeln,
• Promotion, Versionierung und Deprecation,
• kanonische Distribution an die Fleet.

Ein Level-2-Projekt darf einen AEPS-Kandidaten liefern, aber keinen projektübergreifend stabilen oder kanonischen Preset-Status allein vergeben.

Verbindliches Metadatenmodell

Jedes Level-2-Finding, das als AEPS-Kandidat gehärtet werden soll, soll mindestens folgende Metadaten besitzen:

aeps:
  upstream_issue: hindermath/home-baseline#196
  candidate_id: AEPS-CAND-<stable-id>
  source_repository: <owner/repository>
  source_artifact: <issue/pr/receipt/path>
  maturity: observation | pilot-pattern | candidate
  portability: project-specific | likely-generic | cross-project-validated
  domain: <proposed AEPS domain>
  owner: <responsible role or workstream>
  evidence:
    positive: []
    negative: []
  known_limits: []
  related_presets: []
  promotion_blockers: []

Die konkrete Datei- oder Formularstruktur darf repositorykonform angepasst werden. Die semantischen Felder bleiben jedoch erhalten.

Mindestanforderungen an ein gehärtetes Finding

Vor einer Übernahme als AEPS-Preset-Kandidat sind mindestens erforderlich:

1. stabile Finding- oder Candidate-ID,
2. konkrete Ausgangssituation und Problemstatement,
3. reproduzierbarer Kontext,
4. positive Evidence,
5. negative Evidence oder dokumentierte Gegenbeispiele,
6. bekannte Grenzen und Nicht-Ziele,
7. Einschätzung der Übertragbarkeit,
8. unabhängiges Review,
9. Zuordnung zu vorhandenen oder neuen Presets,
10. klare Promotion-Blocker und nächste Validierung.

Schutz vor vorschneller Generalisierung

• AOC-spezifische Dateipfade, Technologien und Workarounds dürfen nicht ungeprüft zu allgemeinen AEPS-Regeln werden.
• Ein einzelner erfolgreicher Lauf bleibt höchstens pilot-pattern oder candidate.
• cross-project-validated setzt Evidence aus mindestens einem weiteren geeigneten Referenzprojekt voraus.
• Widersprüchliche Evidence wird nicht geglättet, sondern als Finding, Variant oder Constraint erhalten.
• Preset-Promotion benötigt einen separaten Level-0-Arbeitsauftrag und Completion Evidence.

Praktische Anwendung im AOC

Das AOC kann ab sofort Findings und Learnings mit Verweis auf hindermath/home-baseline#196 sammeln und härten. Geeignete Orte sind insbesondere:

• eigene AOC-Issues für umfangreiche Findings,
• Review- oder Completion-Receipts,
• Retrospektiven,
• Evidence-Dokumente,
• Candidate-Register im Repository.

Die laufende AOC-Produktarbeit bleibt davon unabhängig. AEPS-Metadaten ergänzen die Provenienz und Wiederverwendbarkeit, verändern aber nicht automatisch Scope oder Authority eines AOC-Workitems.

Späterer Handoff nach Level 0

Ein Level-2-Kandidat wird erst dann in einen eigenständigen Level-0-Workstream überführt, wenn mindestens eines der folgenden Kriterien erfüllt ist:

• dieselbe Beobachtung tritt wiederholt im AOC auf,
• ein bestehendes Preset benötigt nachweisbar eine Änderung,
• der Kandidat besitzt wahrscheinlich projektübergreifende Relevanz,
• ein zweites Referenzprojekt liefert bestätigende oder widersprechende Evidence,
• eine formale Candidate- oder Promotion-Entscheidung ist fällig.

Damit gilt verbindlich:

Im Level 2 entdecken, testen und härten. Im Level 0 konsolidieren, versionieren und promoten.

[hindermath]

Architekturentscheidung: META-LH als deklarative, projektneutrale Agentic-Engineering-Verträge

Anlass

Die bisher im AOC-Level-2-Repository authorierten META-LH-* haben zwei Funktionen vermischt:

1. projektbezogene Vorbereitung des AOC-Lastenheftprogramms,
2. allgemeine Regeln dafür, wie professionelle agentische Entwicklung deklarativ gesteuert werden soll.

Für AEPS wird diese Trennung jetzt ausdrücklich abstrahiert.

Leitgedanke:

Der Mensch beschreibt Ziel, Randbedingungen, Qualitätsmaßstäbe und Autoritätsgrenzen. Das Agentic-Engineering-System leitet daraus mit freigegebenen Presets, Spec-Kit-Befehlen, Reviews und Evidence die operativen Details ab.

---

1. Neue kanonische Bedeutung von META-LH

META-LH beschreibt künftig nicht den Produktgegenstand, sondern die wiederverwendbaren Engineering-Verträge, mit denen ein KI-Agent aus einer deklarativen Absicht ein kontrolliertes Entwicklungsprogramm erzeugt.

Human Intent
    ↓
Declarative Engineering Contract
    ↓
AEPS Preset Selection
    ↓
Spec-Kit Workflow
    ↓
Requirements / Specification / Plan / Tasks
    ↓
Implementation
    ↓
Evidence / Review / Learning

META-LH beantwortet damit Fragen wie:

• Welche Eingaben muss der Mensch deklarieren?
• Welche Details darf der Agent ableiten?
• Welche Details benötigen eine menschliche Decision?
• Welche Presets und Spec-Kit-Schritte sind anzuwenden?
• Welche Artefakte müssen erzeugt werden?
• Welche Stop-, Review- und Evidence-Gates gelten?
• Wann ist ein Workitem für Einzel-, Serien- oder Parallel-Autonomie geeignet?

META-LH ist damit ein Kandidat für die spätere Überführung in AEPS-Presets.

---

2. Trennung zu fachlichen Lastenheften

META-LH / AEPS-Ebene

Beschreibt:

• Engineering-Intent,
• Authoring- und Ableitungsregeln,
• Preset-Auswahl,
• Spec-Kit-Orchestrierung,
• Decision- und Clarification-Gates,
• Review-, Evidence- und Receipt-Verträge,
• Eligibility und Autonomie,
• Wissensrückführung und Preset-Kandidaten.

Fachliche Owner-Reihen, etwa RAW

Beschreiben:

• Produktziele,
• Nutzer und Stakeholder,
• fachliche Capabilities,
• System- und Trust-Grenzen,
• funktionale und nichtfunktionale Anforderungen,
• Produktakzeptanz und Feldevidence.

Kurzform:

META-LH
    Wie wird aus deklarierter Absicht ein belastbarer Engineering-Ablauf?

RAW und weitere Owner-Reihen
    Was soll das konkrete Produkt leisten?

AOC-spezifische Details dürfen daher nicht in eine allgemeine META-LH-Baseline übernommen werden. Sie verbleiben in RAW oder der jeweils zuständigen fachlichen Owner-Reihe.

---

3. Deklarativer Eingabevertrag

Eine projektneutrale META-LH-Struktur soll mindestens folgende menschliche Eingaben unterstützen:

• gewünschtes Ergebnis und Nutzen,
• Zielgruppe und Nutzungskontext,
• verbindliche Constraints,
• Qualitäts- und Compliance-Ziele,
• Plattform- und Portabilitätsgrenzen,
• erlaubte und verbotene Seiteneffekte,
• menschlich zu entscheidende Punkte,
• gewünschter Autonomiegrad,
• Evidence- und Review-Erwartungen,
• Delivery- und Stop-Grenzen.

Der Mensch muss nicht alle technischen Details vorgeben. Der Agent darf Details ableiten, wenn:

• ein freigegebenes Preset oder ein kanonischer Vertrag die Ableitung trägt,
• die Entscheidung reversibel oder risikoarm ist,
• keine offene menschliche Decision umgangen wird,
• die Ableitung dokumentiert und prüfbar bleibt.

---

4. Vorgeschlagene abstrakte META-LH-Reihe

Die bestehende AOC-Reihe liefert Evidence, aber die AEPS-Abstraktion wird funktional neu geschnitten.

AEPS-META-01 – Declarative Intent and Constraint Contract

Erfasst menschliche Absicht, Nutzen, Zielgruppe, Constraints, Qualitätsziele, Nicht-Ziele und Autoritätsgrenzen in einer projektneutralen Form.

AEPS-META-02 – Preset Selection and Applicability

Bestimmt anhand des deklarierten Intents, welche vorhandenen AEPS-, Spec-Kit-, GitHub- und Governance-Presets anwendbar, optional, unzulässig oder noch nicht vorhanden sind.

AEPS-META-03 – Requirements and Work-Program Derivation

Leitet aus Intent, Presets, Quellen und Findings ein de-dupliziertes Portfolio aus Lastenheften, Decision Intakes, Serien und Handoffs ab.

AEPS-META-04 – Spec-Kit Orchestration Contract

Definiert, wann und mit welchen Eingaben specify, Clarification, Plan, Tasks und Implementierung gestartet werden dürfen und welche Artefakte beziehungsweise Receipts jeder Schritt erzeugt.

AEPS-META-05 – Authority, Autonomy and Side-Effect Control

Klassifiziert menschliche Decisions, reversible Ableitungen, Seiteneffekte, Stop-Gates sowie Einzel-, Serien- und Parallel-Autonomie.

AEPS-META-06 – Review, Evidence and Completion

Definiert Review Findings, Coverage, positive und negative Evidence, Completion Receipts und Kriterien für Ready, NeedsClarification, Blocked oder Rejected.

AEPS-META-07 – Learning and Preset Evolution

Überführt projektbezogene Findings und Learnings in projektneutral bewertete Preset-Kandidaten und steuert den Level-2→Level-0-Härtungsweg.

---

5. Verhältnis zu den bestehenden AOC-META-LH

Die bestehenden AOC-META-LH bleiben historische und operative Evidence für Phase 2. Sie werden nicht rückwirkend umbenannt oder aus dem AOC entfernt.

Sie sind jedoch künftig zu klassifizieren als:

• pilot implementation of meta-engineering contracts,
• Quelle für AEPS-Abstraktion,
• nicht automatisch kanonische projektneutrale Presets.

Eine spätere AEPS-Phase-1-Inventur muss:

1. jedes bestehende AOC-META-LH gegen AEPS-META-01 bis AEPS-META-07 mappen,
2. AOC-spezifische Inhalte von generischen Verträgen trennen,
3. vorhandene GitHub- und Spec-Kit-Presets zuordnen,
4. Lücken und Überschneidungen dokumentieren,
5. Candidate Presets ableiten, ohne vorschnelle Promotion.

---

6. Zielbild für deklaratorisches Arbeiten

Beispielhafte menschliche Deklaration:

Ich möchte eine öffentlich verfügbare, plattformübergreifende Anwendung
für Auszubildende ab dem ersten Lehrjahr.

Sie soll WCAG 2.2 AA erfüllen, Deutsch zuerst und danach Englisch liefern,
keine unbestätigten Remote-Mutationen ausführen und einen read-only
Vertical Slice als ersten Meilenstein verwenden.

Das System soll daraus kontrolliert ableiten:

• anwendbare Presets,
• notwendige Lastenhefte und Owner-Reihen,
• offene Decision Intakes,
• Spec-Kit-Ausführungsreihenfolge,
• Reviews und Evidence,
• geeignete Autonomieklassen,
• Stop- und Delivery-Gates.

Der Agent kümmert sich damit um operative Details, aber nicht durch freie Improvisation, sondern innerhalb versionierter AEPS-Verträge.

---

7. Status und Grenzen

Diese Architekturentscheidung:

• verankert die projektneutrale Zielabstraktion,
• ändert noch keine bestehenden Presets oder AOC-Artefakte,
• autorisiert keine Promotion,
• erzeugt noch kein separates AEPS-Repository,
• verlangt vor Umsetzung eine Bestandsaufnahme der vorhandenen GitHub- und Spec-Kit-Presets.

Leitsatz:

META-LH beschreibt, wie professionelle agentische Entwicklung aus deklarierter menschlicher Absicht zuverlässig abgeleitet, ausgeführt, geprüft und verbessert wird.

[hindermath]

AEPS-Abstraktion der Level-0-Vorarbeit zum Level-2-Start

Die Entstehung des AOC-Level-2-Programms zeigt, dass ein startfähiges Produktrepository nicht aus einem isolierten Bootstrap entsteht. Ihm geht eine eigenständige, projektübergreifend abstrahierbare Level-0-Vorbereitungsphase voraus.

Diese Vorarbeit wird hiermit als eigener AEPS-Vertrag festgehalten.

---

1. Grundsatz

Menschliche Absicht
    ↓
strategische Klärung in Level 0
    ↓
Review, Findings und Readiness
    ↓
selbsttragendes Übergabepaket
    ↓
Level-2-Repository und Requirements-Programm
    ↓
Spec Kit
    ↓
Produktentwicklung

Level 2 entsteht damit nicht „aus dem Nichts“.

Es entsteht aus einem kontrollierten Übergang von:

• Absicht,
• Kontext,
• strategischen Grenzen,
• Findings,
• Entscheidungen,
• Autorität,
• Repository- und Public-Readiness,
• Lastenheft- und Series-Struktur,
• sowie einem expliziten Completion- und Handoff-Nachweis.

---

2. Abstrakte AEPS-Vorstufe vor Level 2

Die folgende Reihe ergänzt die bereits abstrahierten AEPS-META-*-Verträge.

AEPS-FOUND-01 – Intent, Problemraum und strategische Leitplanken

Zweck:

• menschliche Absicht erfassen,
• Problemraum und erwarteten Nutzen beschreiben,
• harte Constraints und Nicht-Ziele dokumentieren,
• Zielgruppen, Qualitätsziele und Verantwortungsgrenzen festlegen.

Typische Artefakte:

• Program Charter,
• Strategic Initiative,
• Glossargrundlage,
• Constraint Register,
• erste Architekturhypothesen.

Der Vertrag ist deklarativ: Der Mensch beschreibt, was erreicht werden soll. Noch keine Implementierungsdetails werden festgelegt.

AEPS-FOUND-02 – Quellen-, Provenienz- und Wissensbasis

Zweck:

• relevante Issues, Engineering Sessions, vorhandene Presets, Referenzprojekte und historische Entscheidungen inventarisieren,
• Quellenrollen und Supersession dokumentieren,
• aus verstreuten Quellen eine konsistente Wissensbasis erzeugen.

Typische Artefakte:

• Source Inventory,
• Provenance Map,
• Supersession Register,
• Engineering Session Archive,
• vorhandene Preset Map.

AEPS-FOUND-03 – Review Findings und Coverage

Zweck:

• Architektur-, Governance-, Sicherheits-, Accessibility- und Prozessfindings stabil nummerieren,
• Severity, Ownership, Zielartefakt und Evidence festlegen,
• sicherstellen, dass Findings nicht nur zusammengefasst, sondern in Anforderungen oder Decision Intakes überführt werden.

Typische Artefakte:

• Review Findings Ledger,
• Coverage Matrix,
• Conflict and Gap Register,
• Rejection-/Deferral-Rationale.

Blocking Findings dürfen nicht unbehandelt in Level 2 übergehen.

AEPS-FOUND-04 – Ownership, Reihen und Entscheidungslandkarte

Zweck:

• für jeden Concern genau eine kanonische Owner-Reihe bestimmen,
• Handoffs und Nicht-Ownership dokumentieren,
• Lastenheft- und Decision-Struktur als azyklischen Graph vorbereiten.

Typische Artefakte:

• Ownership Matrix,
• Lastenheft Landscape,
• Series Map,
• Decision Map,
• Eligibility-Hypothesen.

AEPS-FOUND-05 – Repository- und Systemgrenzen

Zweck:

• Rolle von Level 0, Level 1 und Level 2 festlegen,
• das zukünftige Produktrepository identifizieren,
• öffentliche Sichtbarkeit, Lizenz, Zielpfad, Owner, Default Branch und technische Baseline entscheiden oder bewusst vertagen,
• Runtime-, Tooling- und Authority-Grenzen definieren.

Typische Artefakte:

• Repository Blueprint,
• Public-Readiness-Gate,
• Authority Map,
• Trust Boundaries,
• Fleet-/Registry-Plan.

AEPS-FOUND-06 – Self-Contained Handoff Package

Zweck:

• alle für Level 2 notwendigen Inhalte in ein selbsttragendes Übergabepaket überführen,
• versteckte Inhaltsabhängigkeiten auf verstreute Level-0-Lastenhefte vermeiden,
• Provenienz erhalten, ohne Level 2 dauerhaft von Level-0-Interpretation abhängig zu machen.

Das Übergabepaket enthält mindestens:

• strategische Baseline,
• Constraints,
• Glossar,
• Review Findings und Coverage,
• Ownership- und Series-Struktur,
• offene Decisions,
• Authority- und Stop-Gates,
• Repository Blueprint,
• Evidence- und Completion-Vertrag.

AEPS-FOUND-07 – Development Readiness und Phasenautorität

Zweck:

• klar zwischen Verstehen, Repository-Erzeugung, Requirements-Authoring, Specify, Plan, Tasks und Implementierung unterscheiden,
• jeder Phase einen eigenen erlaubten Scope geben,
• Stop-Gates und menschliche Freigaben definieren.

Typische Phasen:

1. Read-only verstehen und strukturieren,
2. Repository und Presets initialisieren,
3. Lastenhefte und Serien authorieren,
4. Decision Intakes auflösen,
5. Spec Kit Specify/Plan/Tasks,
6. Implementierung und Evidence.

Kein späterer Phasenstatus darf stillschweigend aus einem früheren Auftrag abgeleitet werden.

AEPS-FOUND-08 – Level-2 Bootstrap und Requirements-Programm

Zweck:

• das freigegebene Level-2-Repository erzeugen,
• Spec Kit und genehmigte Presets initialisieren,
• das selbsttragende Handoff Package übernehmen,
• Meta-Lastenhefte und fachliche Owner-Reihen authorieren,
• Receipts, Reviews, Decisions und Series-Manifeste erzeugen.

Ergebnis:

• startfähiges Level-2-Requirements-Programm,
• aber noch kein impliziter Specify-, Plan- oder Implementierungsauftrag.

AEPS-FOUND-09 – Abschluss, Registrierung und operative Übergabe

Zweck:

• Level-2-Repository in Fleet, Registry und IDE-Baselines registrieren,
• Maintenance- und Preset-Synchronität herstellen,
• Level-0-/Level-1-Arbeit mit Completion Receipts schließen,
• Level 2 als einzige operative Produktarbeitsquelle festlegen.

Typische Evidence:

• Merge- und Sync-Nachweis,
• CI- und Homogeneity-Status,
• Maintenance current,
• Registry/Fleet current,
• geschlossene Readiness-Issues,
• zentraler Provenienz-Handoff.

---

3. Verhältnis zu den AEPS-META-Verträgen

AEPS-FOUND-*
    schafft den startfähigen Projekt- und Repositorykontext

AEPS-META-*
    steuert innerhalb dieses Kontexts die deklarative Ableitung,
    Spec-Kit-Orchestrierung, Autonomie, Reviews und Learnings

fachliche Owner-Reihen
    beschreiben das konkrete Produkt

Kurz:

• AEPS-FOUND-* beantwortet: Wie entsteht aus einer Idee ein startfähiges Level-2-Engineering-Programm?
• AEPS-META-* beantwortet: Wie wird dieses Programm deklarativ und agentisch ausgeführt und weiterentwickelt?
• fachliche Reihen beantworten: Was soll das Produkt leisten?

---

4. AOC als Pilot-Evidence

Die bisherige AOC-Arbeit liefert bereits Pilot-Evidence für diese Abstraktion:

• Program Charter und Meta-Initiative,
• Engineering Sessions,
• Issues AOC Development Readiness Gate: Analyse, Lastenheft-Landkarte und erster Agentenstart #180, AOC Review Findings Register: Development Readiness, Lastenheft Precision and Start Conditions #181 und AOC Phase 2 Contract: Public Level-2 Repository and Self-Generating Spec-Kit Lastenheft Program #182,
• Review Findings RF-01 ff.,
• selbsttragendes Phase-2-Handoff,
• öffentliches Level-2-Repository,
• Meta- und RAW-Lastenhefte,
• Completion Receipts,
• Fleet- und Registry-Integration,
• Abschluss von Level 0 und Level 1,
• alleinige operative Fortsetzung in Level 2.

Diese Evidence ist noch kein Nachweis universeller Gültigkeit. Sie begründet aber einen belastbaren Pilot Pattern-Status.

---

5. Preset-Kandidaten aus der Level-0-Vorarbeit

Aus dieser Abstraktion entstehen mindestens folgende AEPS-Kandidaten:

• Development Readiness Gate
• Source and Provenance Consolidation
• Review Findings Coverage Gate
• Single Ownership and Series DAG
• Repository Blueprint and Public Readiness
• Self-Contained Level-2 Handoff
• Phase Authority and Stop Gates
• Level-2 Requirements Program Bootstrap
• Fleet Registration and Operational Handoff
• Level-0/Level-1 Completion Receipt

Bestehende GitHub- und Spec-Kit-Presets sind bei der späteren Inventur auf diese Verträge abzubilden. Neue Presets dürfen nur dort entstehen, wo vorhandene Verträge die Anforderungen nicht bereits vollständig abdecken.

---

6. Nicht-Ziele

Diese Verankerung autorisiert noch nicht:

• bestehende Presets umzubenennen,
• neue Presets direkt zu promoten,
• AOC-Arbeit zurück nach Level 0 zu verlagern,
• ein separates AEPS-Repository anzulegen,
• den AOC-spezifischen Ablauf ungeprüft als universellen Standard zu deklarieren.

Sie konserviert die Level-0-Vorarbeit als projektneutrale AEPS-Arbeitshypothese und Preset-Kandidatenbasis.

---

Arbeitsformel

Level 0 klärt, konsolidiert und autorisiert. Level 2 übernimmt selbsttragend, spezifiziert, implementiert und liefert Evidence zurück.

[hindermath]

Neuer AEPS-Preset-Kandidat: Dependency-Driven Lastenheft Scheduling

Die laufende AOC-Arbeit zeigt einen reproduzierbaren, zustands- und abhängigkeitsgesteuerten Ablauf für Lastenhefte. Dieser Ablauf soll als weiterer AEPS-Preset-Kandidat konserviert und später projektübergreifend gehärtet werden.

Arbeitstitel

Dependency-Driven Lastenheft Scheduling

Zweck

Das Preset soll sicherstellen, dass Lastenhefte nicht nach subjektiver Priorität oder lokaler Fertigstellung gestartet werden, sondern ausschließlich dann, wenn ihre Abhängigkeiten, Reviews, Decision Intakes, Authority-Gates und Evidence-Voraussetzungen erfüllt sind.

Der Workflow beschreibt damit nicht nur Fortschritt, sondern den zulässigen Zustandsraum eines agentischen Engineering-Programms.

Ausgangs-Evidence aus AOC

Aktuell beobachtete Zustände und Übergänge:

• Eligible
• Ready
• Pending
• Research
• Blocked
• Promotion

Beispiele aus der RAW-Reihe:

• RAW-01: Completed
• RAW-03: einziger Eligible-Kandidat
• RAW-02: Einzelreview Ready, aber Lifecycle durch RAW-03 blockiert
• RAW-04: Pending, wartet auf RAW-03
• RAW-05: Research, ausschließlich read-only
• RAW-06 und RAW-07: durch fachliche IAD-Entscheidungen und vorgelagerte Lastenhefte blockiert
• RAW-09: zusätzliche separate Promotion Authority erforderlich

Vorläufiges Zustandsmodell

Pending

Das Lastenheft ist bekannt und im Series-Graphen eingeordnet, aber mindestens eine fachliche, technische, Evidence- oder Sequenzvoraussetzung fehlt noch.

Research

Es ist ausschließlich read-only Forschungs-, Evidence- oder Decision-Arbeit autorisiert. Keine mutierende Spec-Kit- oder Produktarbeit.

Ready

Authoring und Review sind formal gültig. Ready allein erzeugt jedoch noch keine Ausführungsberechtigung, wenn vorgelagerte Lifecycle- oder Dependency-Gates offen sind.

Eligible

Alle für den nächsten zulässigen Schritt erforderlichen Abhängigkeiten, Reviews, Authority-Gates und Decision-Voraussetzungen sind erfüllt. Ein Lastenheft darf nur dann zum aktiven Kandidaten werden.

Blocked

Mindestens eine explizite Voraussetzung verhindert den nächsten Schritt. Jeder Blocker muss maschinenlesbar auf Quelle, Decision Intake, Authority, Finding oder Dependency verweisen.

Promotion

Die technische oder fachliche Arbeit kann abgeschlossen sein, aber eine getrennte Promotion-, Release-, Public- oder Governance-Autorität ist noch erforderlich.

Zentrale Regel

Ready beschreibt lokale Artefaktqualität. Eligible beschreibt globale Ausführungsberechtigung im Programmgraphen.

Diese Zustände dürfen nicht synonym verwendet werden.

Übergangsregeln

Ein AEPS-kompatibles Scheduling-Preset soll mindestens folgende Regeln erzwingen:

1. Ein Lastenheft wird nur Eligible, wenn alle harten Vorgänger abgeschlossen oder ausdrücklich erfüllt sind.
2. Ein Ready-Review hebt keine offenen Lifecycle-, Decision-, Evidence- oder Authority-Blocker auf.
3. Research erlaubt ausschließlich den zuvor definierten read-only Scope.
4. Jeder Blocked-Status benötigt:
   • Blocker-ID,
   • Ursache,
   • Owner,
   • Auflösungsbedingung,
   • betroffene Nachfolger.
5. Promotion benötigt eine eigene Authority und darf nicht aus technischer Fertigstellung abgeleitet werden.
6. Es darf standardmäßig genau einen aktiven Eligible-Kandidaten geben, sofern keine explizit validierte Parallelitätsfreigabe besteht.
7. Parallel-Eligibility ist nur zulässig, wenn:
   • Schreibbereiche disjunkt oder koordiniert sind,
   • keine gemeinsame offene Decision-Abhängigkeit besteht,
   • Integration, Review und Recovery definiert sind.
8. Jeder Zustandswechsel benötigt Evidence und ein Receipt oder eine gleichwertige versionierte Begründung.

Erforderliche Metadaten

Ein späteres Preset sollte pro Lastenheft mindestens erfassen:

scheduling:
  state: Pending | Research | Ready | Eligible | Blocked | Promotion | Completed
  predecessors: []
  blockers: []
  required_decisions: []
  required_reviews: []
  required_evidence: []
  authority_gate: null
  allowed_mode: manual-assisted | research-only | single-autonomous | serial-autonomous | parallel-autonomous
  writable_scope: []
  next_transition: null

Erwartete Evidence

Für eine spätere Härtung werden mindestens benötigt:

• mehrere vollständige RAW-Übergänge,
• absichtlich blockierte Fälle,
• Research-only-Fälle,
• Promotion-Gates,
• mindestens ein kontrollierter serieller Ablauf,
• später mindestens ein sicherer Parallel-Autonomie-Pilot,
• negative Evidence zu falschen oder zu frühen Eligibility-Entscheidungen.

Vorgeschlagene AEPS-Domänen

Primär:

• Requirements Engineering
• Multi-Agent and Parallel Work

Sekundär:

• Agent Authority and Execution
• Review and Evidence

Vorläufiger Reifegrad

pilot-pattern

Begründung:

• der Ablauf ist im AOC-Series-Graphen bereits real angewendet,
• mehrere unterschiedliche Zustände und Blockerklassen sind sichtbar,
• Zustandsübergänge werden durch Reviews, Decisions und Receipts kontrolliert,
• projektübergreifende Evidence fehlt noch.

Offene Härtungsfragen

• Soll Completed Teil des eigentlichen Scheduling-Presets oder eines getrennten Lifecycle-Presets sein?
• Sind Research und Promotion Zustände oder orthogonale Ausführungs-/Authority-Klassen?
• Wie wird parallele Eligibility formal und maschinenlesbar validiert?
• Welche Statusnamen müssen kanonisch sein und welche dürfen projektspezifisch erweitert werden?
• Welche Validatoren verhindern, dass Ready fälschlich als Eligible interpretiert wird?

Promotion-Grenze

Dieser Eintrag autorisiert keine Preset-Erstellung oder Promotion. Er konserviert das im AOC beobachtete Pattern als AEPS-Kandidaten. Die spätere Konsolidierung erfolgt gemäß AEPS-Lifecycle und benötigt weitere Projekt-Evidence.

[hindermath]

Ergänzung: AEPS Documentation Architecture und Brownfield Inventory/Upgrade

Die folgenden beiden Anforderungen werden als strategische AEPS-Bausteine verankert. Sie sind wesentlich, damit AEPS nicht nur technisch wirksam, sondern auch verständlich, einführbar und auf bestehende Repositories anwendbar wird.

---

1. AEPS Documentation Architecture

Problem

AEPS ist kein einzelnes Preset, sondern ein zusammenhängendes Engineering-System aus Presets, Governance-Verträgen, Lifecycle-Modellen, Reviews, Evidence, Receipts, Authority-Gates und projektübergreifender Wissensrückführung.

Eine knappe README oder verteilte Einzeldokumentation reicht dafür nicht aus. Ohne eine zentrale, maximal beziehungsweise ultra ausführliche Dokumentation besteht das Risiko, dass Nutzende zwar einzelne Presets anwenden können, aber:

• das Gesamtmodell nicht verstehen,
• Presets falsch kombinieren,
• Authority- und Stop-Grenzen übersehen,
• Reifegrade und Promotion falsch interpretieren,
• AEPS als Prompt-Sammlung statt als Engineering-System behandeln,
• den Zusammenhang zwischen Level 0, Level 1, Level 2, Spec Kit, Presets, Findings und Evidence verlieren.

Ziel

AEPS benötigt eine zentrale, autoritative Dokumentationsarchitektur.

Arbeitshypothese:

• ein zentrales, ausschließlich oder überwiegend dokumentationsorientiertes AEPS-Repository,
• darin die vollständige Systemdokumentation,
• jede Preset-README beschreibt das eigene Preset maximal ausführlich und verweist auf die zentrale AEPS-Dokumentation,
• die zentrale Dokumentation verweist zurück auf alle Presets und deren Stellung im Gesamtsystem.

Die endgültige Repository-Entscheidung ist noch offen und muss durch einen eigenen Decision Intake getroffen werden.

Mindestinhalt der zentralen AEPS-Dokumentation

• Vision, Zweck und Leitprinzipien,
• deklaratorisches Arbeiten: Intent statt operative Detailsteuerung,
• Verhältnis Mensch, KI-Agent, Spec Kit und Presets,
• Level-0-/Level-1-/Level-2-Modell,
• FOUND-, META-, fachliche Owner- und Preset-Ebenen,
• AEPS-Domänen und Taxonomie,
• Preset-Lifecycle von Observation bis Canonical,
• Finding-, Evidence- und Receipt-Modell,
• PDCA-Zyklus und kontinuierliche Verbesserung,
• Engineering Controls,
• Dependency-Driven Lastenheft Scheduling,
• Authority-, Autonomie-, Side-Effect- und Promotion-Gates,
• Greenfield- und Brownfield-Nutzung,
• Upgrade- und Migrationsmodell,
• Referenzprojekte und Feld-Evidence,
• Glossar DE/EN,
• vollständige Beispiele,
• Anti-Patterns und Fehlanwendungen,
• Troubleshooting,
• Auditierbarkeit und Traceability,
• Accessibility- und Verständlichkeitsregeln,
• Beitrag, Review und Promotion neuer Presets.

Anforderungen an jede Preset-README

Jedes AEPS-Preset muss maximal ausführlich dokumentieren:

• Zweck und Problemstellung,
• Stellung innerhalb von AEPS,
• zugehörige AEPS-Domäne,
• implementierte Engineering Controls,
• Voraussetzungen,
• Inputs und Outputs,
• unterstützte Spec-Kit-Befehle und Workflow-Phasen,
• Authority und erlaubte Seiteneffekte,
• Stop- und Review-Gates,
• Konfiguration,
• Beispiele Greenfield und Brownfield,
• typische Fehlanwendungen,
• Evidence- und Receipt-Anforderungen,
• Kompatibilität,
• Versionierung und Migration,
• Reifegrad und zugrunde liegende Projekte/Evidence,
• bekannte Grenzen,
• Verweise auf zentrale AEPS-Kapitel und verwandte Presets.

Dokumentationsqualität

Verbindliche Baseline:

• DE-first, EN-second,
• Zielgruppe ab IHK-IT-Ausbildung im 1. Ausbildungsjahr sowie erfahrene Fachkräfte,
• CEFR B2,
• WCAG 2.2 AA für anwendbare Dokumentationsoberflächen,
• semantische Überschriftenstruktur,
• Tastatur- und Screenreader-taugliche Navigation,
• keine ausschließlich farbcodierte Information,
• Glossar und konsistente Terminologie,
• vollständige, reproduzierbare Beispiele.

Preset-Kandidat

AEPS Documentation Architecture and Preset Documentation Contract

Vorläufiger Reifegrad: candidate.

---

2. Brownfield Repository Inventory and AEPS Upgrade

Problem

AOC ist ein Greenfield-Referenzprojekt. Viele reale Repositories enthalten jedoch bereits:

• Lastenhefte,
• Intakes,
• Spec-Kit-Artefakte,
• Presets,
• Governance-Dateien,
• Receipts,
• projektspezifische Konventionen,
• historische Inkonsistenzen,
• nicht mehr aktuelle Strukturen.

AEPS darf bei Anwendung auf ein bestehendes Repository nicht einfach neue Strukturen darüberlegen oder vorhandene Artefakte ignorieren.

Ziel

Vor jeder AEPS-Einführung in ein bestehendes Repository muss eine kontrollierte Inventarisierungs-, Klassifizierungs- und Upgrade-Phase erfolgen.

Leitprinzip:

Erst verstehen und sichern, dann klassifizieren, dann Upgrade planen, dann kontrolliert migrieren.

Vorgeschlagener Ablauf

Phase 1 – Read-only Inventory

Inventarisieren:

• alle Lastenheft-/Intake-Dateien,
• Spec-Kit-Struktur und Version,
• vorhandene Presets,
• Governance- und Constitution-Dateien,
• Reviews, Findings, Decisions und Receipts,
• Branch-/PR-/CI-Verträge,
• Dokumentations- und Accessibility-Status,
• projektspezifische Erweiterungen,
• verwaiste, doppelte oder widersprüchliche Artefakte.

Keine Änderung in dieser Phase.

Phase 2 – Classification and Mapping

Jedes Artefakt klassifizieren als:

• AEPS-konform,
• kompatibel mit Anpassung,
• Legacy, aber erhaltenswert,
• redundant,
• widersprüchlich,
• unbekannt,
• migrationspflichtig,
• nicht übertragbar.

Mapping auf:

• AEPS-Domäne,
• Owner-Reihe,
• Preset,
• Lifecycle-Status,
• Authority,
• Evidence- und Receipt-Typ.

Phase 3 – Upgrade Plan

Erzeugen:

• Inventory Report,
• Compatibility Matrix,
• Gap Analysis,
• Migration Map,
• Supersession Plan,
• Backup/Rollback Strategy,
• Decision Intakes,
• Risiko- und Seiteneffektklassifikation,
• vorgeschlagene Migrationsreihenfolge,
• Validation und Completion Plan.

Phase 4 – Controlled Upgrade

Erst nach menschlicher Freigabe:

• vorhandene Artefakte sichern,
• kanonische Strukturen ergänzen,
• Inhalte verlustfrei migrieren,
• IDs und Traceability erhalten,
• Überschneidungen auflösen,
• Presets initialisieren oder aktualisieren,
• Reviews und Receipts nachziehen,
• Validatoren ausführen,
• Completion Evidence erzeugen.

Unverhandelbare Regeln

• kein destruktives Überschreiben,
• keine stille Umbenennung oder Löschung,
• historische Provenienz erhalten,
• bestehende gültige Projektverträge respektieren,
• keine Greenfield-Annahmen auf Brownfield-Repositories übertragen,
• jede automatische Migration muss idempotent oder sicher wiederholbar sein,
• Preview/WhatIf vor schreibender Migration,
• Rollback- oder Recovery-Strategie,
• vollständiger Diff- und Review-Nachweis.

Feldkandidaten

Als erste Brownfield-Referenzprojekte werden vorgemerkt:

1. TuiVision
2. TinyPl0
3. TinyCalc
4. InventarWorkerService

Diese Projekte sollen unterschiedliche historische Strukturen, Reifegrade und Nutzungsmuster repräsentieren. Vor der Auswahl der Pilot-Reihenfolge ist eine read-only Eignungs- und Risikoprüfung erforderlich.

Erwartete Evidence

• Inventarisierungsgenauigkeit,
• keine verlorenen Artefakte,
• erhaltene Traceability,
• reproduzierbare Migration,
• idempotenter Wiederholungslauf,
• Unterschiede zwischen Greenfield und Brownfield,
• False Positives und nicht migrierbare Sonderfälle,
• Aufwand und Nutzen je Repository,
• Verbesserungskandidaten für Upgrade-Presets.

Preset-Kandidaten

• AEPS Brownfield Repository Inventory
• AEPS Compatibility and Gap Assessment
• AEPS Controlled Repository Upgrade
• AEPS Legacy Artifact Migration and Supersession
• AEPS Upgrade Validation and Completion

Vorläufiger Reifegrad: observation bis candidate; Härtung durch die vier Feldprojekte erforderlich.

---

3. Zusammenspiel Greenfield und Brownfield

Greenfield
    Intent
    → FOUND
    → Level-2 Bootstrap
    → Requirements Program
    → Spec Kit

Brownfield
    Existing Repository
    → Inventory
    → Classification
    → Gap/Compatibility
    → Controlled Upgrade
    → AEPS-konformes Requirements Program
    → Spec Kit

Beide Pfade müssen in denselben AEPS-Kern münden, dürfen aber nicht dieselben Startannahmen verwenden.

---

4. Erwartete spätere Lastenhefte / Decision Intakes

• AEPS Central Documentation Repository Decision
• AEPS Documentation Information Architecture
• AEPS Preset README Contract
• AEPS Greenfield Adoption Guide
• AEPS Brownfield Inventory Contract
• AEPS Upgrade Planning Contract
• AEPS Migration and Supersession Contract
• AEPS Upgrade Validation and Recovery Contract
• Brownfield Pilot Selection and Sequencing

---

5. Stop-Grenze

Diese Ergänzung autorisiert noch nicht:

• Erstellung eines zentralen AEPS-Dokumentationsrepositories,
• Migration der vier Feldprojekte,
• Änderung bestehender Presets,
• automatische Upgrade-Ausführung,
• Löschung oder Umbenennung vorhandener Artefakte.

Sie stellt sicher, dass Dokumentationsarchitektur und Brownfield-Upgrade beim späteren AEPS-Authoring verbindlich berücksichtigt werden.

[hindermath]

AEPS-Glossar und Begriffssystem verankern

AEPS benötigt ein zentrales, autoritatives Glossar, damit Nutzende, Maintainer und KI-Agenten die zentralen Begriffe eindeutig und konsistent verwenden. Das Glossar soll insbesondere Begriffe voneinander abgrenzen, die in angrenzenden Disziplinen bereits existieren, im AEPS-Kontext aber eine präzisere Bedeutung erhalten.

Mindestumfang des Glossars

Das Glossar soll mindestens folgende Begriffe definieren und zueinander in Beziehung setzen:

• Agentic Engineering
• Agentic Engineering Preset System (AEPS)
• Engineering Intelligence
• Business Intelligence
• Engineering Evidence
• Review Finding
• Learning
• Pattern
• Anti-Pattern
• Preset Candidate
• Engineering Control
• Decision Intake
• Lastenheft
• Authoring Receipt
• Review Receipt
• Completion Receipt
• Promotion Authority
• Greenfield
• Brownfield
• Level 0, Level 1 und Level 2
• Readiness Gate
• Eligibility
• Ready
• Completed
• Dormant
• Pilot Pattern
• Stable
• Canonical

Dokumentationsregeln

• Deutsch ist die autoritative Erstfassung, Englisch folgt terminologisch konsistent.
• CEFR B2 bleibt die sprachliche Baseline.
• Fachbegriffe sind zulässig, müssen aber beim ersten Auftreten verständlich erklärt oder im Glossar verlinkt werden.
• Synonyme, Abgrenzungen, Gegenbegriffe und typische Fehlinterpretationen sollen dokumentiert werden.
• Jeder Preset-README verweist auf die relevanten Glossarbegriffe und darf keine konkurrierenden Definitionen erzeugen.
• Änderungen an zentralen Begriffen benötigen Review, Impact-Analyse und gegebenenfalls Migrationshinweise.

Strategische Einordnung

Business Intelligence wertet Geschäftsdaten aus, um Geschäftsentscheidungen zu verbessern.

Engineering Intelligence wertet Engineering Evidence, Findings, Reviews, Entscheidungen und Wirksamkeitsnachweise aus, um Engineering-Prozesse und Presets zu verbessern.

AEPS ist damit kein BI-System, kann aber als evidenzbasiertes Engineering-Intelligence-System verstanden werden, das Erkenntnisse in wiederverwendbare Engineering-Verträge und Presets überführt.

Vorgeschlagene Artefakte

• AEPS Glossary
• DE/EN Terminology Registry
• Terminology Decision Log
• Glossary Review Contract
• Preset-to-Glossary Reference Matrix
• Migration- und Supersession-Regeln für geänderte Begriffe

Diese Glossararbeit soll bei der späteren AEPS-Dokumentationsarchitektur und beim Authoring der Preset-READMEs ausdrücklich berücksichtigt werden.