Build Console

Ein reproduzierbarer Weg von der Fachanforderung bis zur internen Preview.

Agentische Produktisierung auf der GovTech-Plattform: Skills, Plattformvorgaben und Governance werden in jedem Schritt enforced — nicht im Nachgang geprüft. Drei Wege führen zum gleichen, prüfbaren Ergebnis.

Reproduzierbarer Weg · acht Phasen
In Konsole öffnen
  1. 01Idee

    Anforderung im Composer formuliert · Intake-Agent erkennt Domäne und Risiken.

    intake
  2. 02Kontext

    Plattformprofil, Capabilities, Skills und Wissensquellen werden materialisiert.

    kontext
  3. 03Fachkonzept

    Personas, Journeys, Domain-Modell und OpenAPI-Skizze entstehen.

    fachkonzept
  4. 04Review

    Compliance, Security und UX prüfen parallel. Blocker stoppen den Build.

    compliancesecurityux
  5. 05Build

    Code entsteht — jede Beat hat einen Pre-Check, forbidden-Regeln werden abgewehrt.

    build
  6. 06Evidence

    Gate-Summary, SBOM, A11y-Report — versiegelt und revisionssicher.

    evidence
  7. 07DevOps

    Platform Gate entscheidet: allow / conditional (Human Review) / block.

    cicd
  8. 08Preview

    Deploy in interne Preview-Umgebung · Trace-ID gesetzt · nur User-Research.

    preview

Jede Phase ist in der Konsole als Agentenlauf, Prüfung oder Gate sichtbar — mit Artefakten, Findings und Evidence. Die Review-Phase zerfällt in drei parallele Prüfungen (Compliance / Security / UX). Kein Schritt darf übersprungen werden.

Governance-Modell

Drei Scopes, drei Schärfegrade — jeder Beat muss durch alle drei.

Regeln stammen aus drei Quellen — Projekt, Plattform, Vendor — und werden vor jedem Beat zu einer effektiven Regelmenge gemerged. Die Signatur am Ende ist nur gültig, wenn alle drei Scopes grün sind und kein forbidden offen ist.

Projekt-Scope8

HITL, Tests, Compliance, Daten

Plattform-Scope9

Build-Gates, Evidence, SBOM, Eval

Vendor-Scope5

9 aktive Vendoren · 43 Vendor-Regeln

forbidden4

niemals freigebbar

hard9

blockt bis Plattform-Change

soft9

HITL-Freigabe möglich

HITL offen9

warten auf Reviewer

Live-Vorschau · Regelmenge im Demo-Szenario
22 Regeln effektiv
  • hardvendorEigenes Login-Modul statt zentraler GovTech IAM
  • softplatformNeue Dependency ohne SCA-Freigabe
  • forbiddenvendorDirekter LLM-Provider statt GovTech Inference-Broker
  • softprojectFokus-Reihenfolge im Bescheid-Screen unklar
  • softvendorCodesphere-Profil weicht von Plattform-Baseline ab

In der Konsole laufen diese Regeln vor jedem Beat als Pre-Check und steuern Trust-HUD, Evidence-Graph und Signatur-Zeremonie.

Konsole öffnen
Drei Wege, ein Governance-Vertrag

Die Plattform funktioniert auch ohne KI. KI ist optional — Governance ist nicht optional.

Alle drei Wege erzeugen dieselben prüfbaren Artefakte und laufen am Ende durch dieselben Plattform-Gates: SBOM, SCA, A11y, AI Eval, Evidence, Human Review.

Weg 1

Ohne Coding-Agent

Vendor entwickelt klassisch in eigener IDE gegen das GovTech SDK. CLI-Checks lokal, CI/CD validiert final.

SDK · Quickstarts · CI-Templates · Evidence-Schema
außerhalb dieser Demo
Weg 2

Eigene Agenten

Vendor bringt eigene Coding-Agents mit. Plattform liefert AGENTS.md, SKILL.md, Allowlists und CI-Templates.

AGENTS.md · SKILL.md · Tool-Allowlist · MR-Regeln
außerhalb dieser Demo
Weg 3

GovTech Build Console

Vendor arbeitet direkt in der Konsole. Full-Governance-Agent orchestriert Fachkonzept, Compliance, Build, Evidence und Preview.

Always-on Composer · Run Cards · Live Preview · Gate
Konsole öffnen