Anwendungsteil 7. Specification CI: Spezifikation als ausführbares Artefakt

Status: Empfehlung. Spezifikationsprüfungen in CI auszuführen ist eine bewährte Praxis. Der konkrete Satz von Gates (Coverage, Scope, Schema, spec_gate) und das Format der JSON-Diagnostik sind ein empfohlener Rahmen, den die meisten Teams anpassen. Die JSON-Schema-Validierung der Fixtures aus validation.md ist eine Standardverwendung des Werkzeugs.

In diesem Kapitel ist „Spezifikations-Gate“ eine Kurzbezeichnung für den Kreislauf, der die Spezifikation auf dieselbe Weise prüft, wie ein gewöhnliches CI den Code prüft. Die Prüfung selbst besteht aus üblichen Schritten: Parsen von requirements.md und plan.md, Validierung der Beispiele gegen JSON Schema, Prüfung der Übereinstimmungen zwischen Dateien. Alle übrigen Begriffe – gate, fixture, schema-check, coverage-check – werden weiter unten an den Stellen eingeführt, an denen sie tatsächlich im Team oder im Skript auftauchen; sie müssen nicht in einer einleitenden Zeile zusammengefasst werden.

Das Spezifikations-Gate automatisiert genau jene Prozedur, die Teil 9 des ersten Bandes mit dem Auge und Teil 16 im Team im Pull Request durchgeführt hat. Im Übungs-AgentClinic konnten REQ-Identifikatoren und Payload-Schemata für Reviews aus Teil 12 noch Vereinbarung bleiben. In der Produktion gibt es diesen Vertrauensvorschuss nicht. Dieselben Beziehungen müssen in ein verbindliches Gate verwandelt werden, das grüne Unit-Tests nicht umgehen können.

Vor dem Lesen

• Anknüpfung aus dem ersten Band: Teil 9 verbindet validation.md mit Fakten, Teil 16 zeigt das Review des Beweispakets.
• Lokaler Übungsfall: incident payload, weil Coverage und JSON Schema lokal ohne CI geprüft werden können.
• Spur für capstone/: eine Zeile Spec CI für high_memory_usage: Befehl, bewiesene Tatsache und negatives Beispiel.
• Hauptbegriff des ersten Durchgangs: Spec CI. gate, fixture, schema-check, coverage-check sind nachschlagbar und tauchen direkt im Befehl und im Skriptkommentar auf.
• Was zurückzustellen ist: GitHub-Actions-Workflow, Scope-Gate und Extrahieren von Fixtures aus beliebigem validation.md.

Ziel

In diesem Kapitel wird das Spezifikations-Gate von der Idee „Dokumente prüfen“ zu einem funktionierenden GitHub-Actions-Kreislauf für das Incident-Projekt. Jeder push und jeder Pull Request durchlaufen ein verbindliches Gate. Das Gate blockiert das Zusammenführen bei drei Klassen von Verstößen:

• nicht erfüllte Anforderungen,
• Überschreitung des Geltungsbereichs (out-of-scope),
• JSON-Schema-Fehler.

Der Leser erhält ein praktisches Repository-Schema, in dem requirements.md, plan.md, validation.md und API-Verträge als ausführbare Artefakte geprüft werden und nicht als Referenzdokumentation.

Der wichtigste Gewinn: Das Team erhält einen reproduzierbaren Blockierungsmechanismus im CI. Die Auseinandersetzung über die Qualität der Spezifikation reduziert sich auf eine konkrete Zeile, Regel und Korrekturmaßnahme.

Minimales Übungsszenario

Übungsfall

incident payload: Prüfen, dass requirements.md mit plan.md verknüpft ist und dass die JSON-Fixtures (Eingabebeispiele, die wir aus validation.md entnehmen) das Pflichtfeld incident_id enthalten. Ziel ist es, Spec CI als kleines lokales Gate (eine verbindliche Prüfung, ohne die das Zusammenführen blockiert wird) zu sehen und nicht als großen GitHub-Actions-Prozess.

Vorbereitung

• book2/examples/spec-ci/requirements.md.
• book2/examples/spec-ci/plan.md.

• book2/examples/spec-ci/fixtures/valid-incident.json.
• book2/examples/spec-ci/fixtures/invalid-missing-incident-id.json.
• Die Skripte check_coverage.py und validate_schema.py.

Schritte

1. cd book2/examples/spec-ci. Erwartung: Sie befinden sich im Verzeichnis des ausführbaren Beispiels.
2. python3 scripts/check_coverage.py --requirements requirements.md --plan plan.md. *Erwartung: Rückgabecode 0, alle REQ-* haben eine Verknüpfung zum Plan.*
3. python3 scripts/validate_schema.py --schema schemas/incident_payload.schema.json --fixtures fixtures. Erwartung: Die gültige Fixture besteht, die negative fällt vorhersagbar durch.
4. Öffnen Sie die Fehlermeldung für die negative Fixture. Erwartung: Es ist klar, welches Feld fehlt und welche Datei zu korrigieren ist.
5. Halten Sie in validation.md fest, was das Gate genau blockiert: Coverage, Geltungsbereich oder Schema.

Kontrollfakt

Ein einziger lokaler Durchlauf zeigt zwei Arten von Wahrheit: Die Anforderung ist mit dem Plan verknüpft, und die Daten entsprechen dem Vertrag. Wenn der CI-Fehler keine Datei, Regel und Aktion angibt, ist er nicht teamreif.

Wie dies in capstone/ landet

Übertragen Sie eine Zeile Spec CI in capstone/validation.md: Welcher Befehl ausgeführt wurde, was er bewiesen hat und welches negative Beispiel blockiert wurde. Übertragen Sie nicht den vollständigen GitHub-Actions-Workflow, falls dieser nicht erstellt wurde; für das Übungsminimum genügt das ausführbare Gegenstück aus examples/spec-ci.

Minimales Fragment:

| Spec CI | `python3 scripts/check_coverage.py ...` | alle REQ-* sind mit dem Plan verknüpft | PASS |
| Schema negative | `python3 scripts/validate_schema.py ...` | missing incident_id blockiert | PASS |

Übertragung auf high_memory_usage

Das Übungsbeispiel arbeitet mit incident payload, aber in capstone/ wird eine Zeile für high_memory_usage benötigt. Wenden Sie dieselben zwei Prüfklassen auf Ihre Anforderungen an:

| Schema negative | validate_schema.py --schema schemas/incident_payload.schema.json --fixtures fixtures | Fixture ohne incident_id oder mit severity: "P0" ohne backup_verified wird blockiert |

Wenn die Zeilen Coverage und Schema negative für high_memory_usage nicht geschrieben werden können, dann fehlt in requirements.md noch eine prüfbare Anforderung oder das Schema unterscheidet P0 ohne Backup noch nicht.

Überprüfbare Spur

Im Übungspaket werden Änderungen an requirements.md, plan.md, validation.md oder am Schema aufbewahrt. Temporäre Fixtures, die nur für die lokale Diagnose erstellt wurden, sind nicht erforderlich, sofern sie nicht Teil des Regression-Sets geworden sind.

Schlüsselideen

Hier bedeutet „ausführbares Artefakt“ nicht, Markdown als Programm auszuführen. Es geht darum, Anforderungen, Plan und Beispiele mit gewöhnlichen CI-Skripten zu prüfen.

Führen Sie das verbindliche GitHub-Actions-Gate sowohl auf pull_request als auch auf push in den geschützten Branch aus. Warum beide Trigger. Eine Spezifikationsverletzung kann auf zwei Wegen hineingelangen: über einen gewöhnlichen Pull Request oder über eine direkte Aktualisierung von Wartungsdateien.

Minimaler Satz der zu verfolgenden Artefakte:

• requirements.md,
• plan.md,
• validation.md,
• contracts/**,

• constitution.md – bei Bedarf, falls darin Domäneneinschränkungen der Incident-Pipeline festgehalten sind.

Markieren Sie in den Branch-Protection-Einstellungen genau die abschließende Aufgabe spec_gate als verbindlich. Sonst können grüne Unit-Tests die inhaltliche Prüfung umgehen. Dieses Schema entspricht dem SDD-Ansatz, bei dem Anforderungen, Plan und Aufgaben zu prüfbaren Schichten werden und nicht zu statischem Text (GitHub Spec Kit).

> [project script] – .github/workflows/spec-ci.yml ruft die projekteigenen Skripte scripts/spec_ci/*.py auf.

name: spec-ci

on:
  pull_request:
    paths:
      - 'requirements.md'
      - 'plan.md'
      - 'validation.md'
      - 'contracts/**'
      - 'constitution.md'
  push:
    branches: [main]
    paths:
      - 'requirements.md'
      - 'plan.md'
      - 'validation.md'
      - 'contracts/**'
      - 'constitution.md'

jobs:
  coverage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: python3 scripts/spec_ci/check_coverage.py --requirements requirements.md --plan plan.md --out out/spec-ci/coverage-report.json

  scope:
    runs-on: ubuntu-latest
    needs: [coverage]

steps:
      - uses: actions/checkout@v4
      - run: python3 scripts/spec_ci/check_scope.py --domain models/incident-response.yaml --plan plan.md --contracts contracts/api.md --out out/spec-ci/scope-violations.ndjson

  schema:
    runs-on: ubuntu-latest
    needs: [coverage, scope]
    steps:
      - uses: actions/checkout@v4
      - run: python3 scripts/spec_ci/extract_fixtures.py --from validation.md --out out/spec-ci/fixtures
      - run: python3 scripts/spec_ci/validate_schema.py --schemas schemas --fixtures out/spec-ci/fixtures --out out/spec-ci/schema-audit.json

  spec_gate:
    runs-on: ubuntu-latest
    needs: [coverage, scope, schema]
    steps:
      - run: echo "Specification gate passed"

Die Coverage-Prüfung beginnt mit dem Graphen requirements → plan und nicht mit der Suche nach übereinstimmenden Wörtern. Führen wir die Traceability-Regeln ein:

• jede User Story aus requirements.md erhält einen stabilen Identifikator REQ-*;
• jede Aufgabe oder jeder Schritt in plan.md muss über ein Feld wie implements: [REQ-014] auf einen oder mehrere dieser Identifikatoren verweisen.

Was als Fehler zählt. Wenn eine Story keine traceable Aufgabe hat, beenden Sie den Prozess mit fail: Das Team hat das Versprechen an den Nutzer bereits vor Beginn der Implementierung verloren. Die umgekehrte Verletzung ist ebenfalls wichtig. Eine Aufgabe ohne implements wird zu einer herrenlosen Aufgabe (rogue task). Das bedeutet, der Plan fügt Funktionen hinzu, die nicht durch Anforderungen gedeckt sind.

> [project script] – scripts/spec_ci/check_coverage.py; ausführbares Gegenstück – [examples/spec-ci/scripts/check_coverage.py](examples/spec-ci/).

python3 scripts/spec_ci/check_coverage.py \
  --requirements requirements.md \
  --plan plan.md \
  --out out/spec-ci/coverage-report.json

Der Detektor für Geltungsbereichsüberschreitungen wird für Fälle benötigt, in denen eine formale Traceability vorhanden ist, der Inhalt des Schritts jedoch den Incident-Domänenbereich verlässt. Gleichen Sie Aktionen aus plan.md mit dem Domänenmodell incident-response ab. Zulässige Operationen, zum Beispiel:

• acknowledge,
• escalate,
• annotate,
• rollback,
• notify_on_call.

Beliebige geschäftliche Aktionen (wie notify_finance, close_customer_contract oder force_resolve_without_operator) gehören nicht hierher.

Berücksichtigen Sie nicht nur das Verb. Prüfen Sie ebenfalls:

• den Akteur,
• den Endpunkt (endpoint),

• die Auslösebedingung.

Warum so. resolve incident kann einem manuellen Bereitschaftsingenieur erlaubt und einem autonomen Agenten verboten sein. Die praktische Regel ist einfach: Wenn ein Schritt nicht durch das Incident-Modell und den erlaubten API-Vertrag erklärt werden kann, blockiert er den Pull Request.

> [project script] – scripts/spec_ci/check_scope.py. Es gibt kein fertiges Gegenstück; implementieren Sie es selbst auf Basis des Domänenmodells und des API-Vertrags.

python3 scripts/spec_ci/check_scope.py \
  --domain models/incident-response.yaml \
  --plan plan.md \
  --contracts contracts/api.md \
  --out out/spec-ci/scope-violations.ndjson

JSON-Schema-Prüfungen schließen die Schicht der Fixtures und Payload-Beispiele ab, in denen häufig stille Integrationsregressionen entstehen. Was zu tun ist:

• Extrahieren Sie alle JSON-Blöcke aus validation.md;
• wandeln Sie sie in einzelne Fixtures um;
• validieren Sie sie gegen Schemata aus schemas/** – zum Beispiel incident_payload.schema.json, pagerduty_webhook.schema.json oder grafana_alert.schema.json.

Beachten Sie zwei Richtungen. Gültige Beispiele müssen fehlerfrei durchgehen. Speziell negative Beispiele müssen vorhersagbar fehlschlagen. Wenn eine negative Payload durchgeht, ist das Schema zu lasch und schützt den Vertrag nicht.

Vor dem Zusammenführen in den geschützten Branch wird dies genauso streng geprüft wie Anwendungstests. Eine falsche incident_id, ein inkorrekter severity oder ein leerer source können den gesamten Remediation-Kreislauf zerstören.

> [project script] – scripts/spec_ci/extract_fixtures.py und scripts/spec_ci/validate_schema.py; ausführbares Gegenstück der Schema-Prüfung – [examples/spec-ci/scripts/validate_schema.py](examples/spec-ci/). Den Extraktionsschritt implementieren Sie selbst für das Format des validation.md Ihres Projekts.

python3 scripts/spec_ci/extract_fixtures.py \
  --from validation.md \
  --out out/spec-ci/fixtures

python3 scripts/spec_ci/validate_schema.py \
  --schemas schemas \
  --fixtures out/spec-ci/fixtures \
  --out out/spec-ci/schema-audit.json

Gestalten Sie das Diagnoseformat der CI-Ablehnungen so, dass es auf schnelle Korrektur ausgelegt ist und nicht auf Untersuchung über Prozessprotokolle.

Schlecht: > Coverage failed: missing REQ

Problem: Der Reviewer weiß nicht, welche Anforderung verwaist ist und wo nachzuschauen ist. Der Fehler kann nicht ohne separate Untersuchung behoben werden.

Gut: > requirements.md:42: REQ-014 hat keinen Verweis in plan.md. Fügen Sie in plan.md eine Aufgabe mit implements: REQ-014 hinzu oder entfernen Sie die Anforderung.

In jedem Fehler geben Sie vier Elemente an:

• einen verständlichen Grund,
• einen Verweis auf Datei und Zeile,
• den Identifikator der verletzten Regel,
• eine konkrete Aktion für das Spezifikationsteam.

Fehlertypen sehen so aus. Für Coverage kann dies REQ-021 has no implementing plan item; add implements: [REQ-021] to plan.md or remove the requirement sein. Für den Geltungsbereich – plan.md:48 uses force_resolve without domain permission. Für das Schema – validation.md:72 missing required property incident_id.

Dieses Format verringert die Belastung des Reviewers. Die Person prüft den Sinn der Änderung und stellt nicht wieder her, was das CI eigentlich gebrochen hat.

{
  "status": "failed",
  "check": "scope",
  "file": "plan.md",
  "line": 48,
  "rule": "IR-SCOPE-007",
  "reason": "Autonomous force resolve is outside the incident-response domain model",
  "action": "Replace with POST /incidents/{id}/ack or add an approved requirement and domain rule"
}

Beispiele und Anwendung

flowchart LR
A[pre-commit hook]
B[localer schneller Durchlauf und leichtes Duell vor push]
C[PR push]
D[Hervorhebung der geänderten Dateien]
E[check_coverage Anforderungen Plan Aufgaben Graph]
F[check_scope Domänenmodell und contracts/api]
G[check_schema Validierung und Gegenbeispiele]
H[Gate-Bericht und PR-Status]
A --> B --> C --> D --> E --> F --> G --> H

Ein typischer Pull Request im Übungs-Incident-Repository ändert drei Dateien:

• requirements.md,
• plan.md,
• validation.md.

Der Autor beschreibt die Story REQ-014: Als Bereitschaftsingenieur (on-call) möchte ich eine Bestätigung der Eskalation erhalten. Dann fügt er im Plan die Aufgabe TASK-033 mit implements: [REQ-014] hinzu. Und in validation.md legt er ein Beispiel für die Webhook-Payload mit den Feldern incident_id, severity, source und escalation_target ab.

Was geprüft wird. Die Coverage-Prüfung besteht, wenn die Verknüpfung REQ-014 → TASK-033 existiert. Die Geltungsbereichsprüfung besteht, wenn die Aktion dem Domänenmodell entspricht. Die Schema-Prüfung besteht, wenn die Payload zum Vertrag passt. Wenn eine der drei Schichten bricht, gibt spec_gate einen roten Status zurück und GitHub erlaubt das Zusammenführen nicht.

Lehrreicher Fehlschlag: Der Autor versucht, die Bearbeitung zu „beschleunigen“, und fügt in plan.md den Schritt POST /pagerduty/force-resolve ohne separate Anforderung und ohne Erlaubnis im Domänenmodell hinzu. Die Coverage kann grün bleiben, wenn der Schritt formal an eine bestehende Story gebunden ist. Doch die Geltungsbereichsprüfung blockiert den Pull Request: Autonomes Schließen eines Incidents ohne Bestätigung des Bereitschaftsdienstes gehört nicht zu den vereinbarten Operationen.

Wenn derselbe Pull Request in validation.md eine Payload mit event_code anstelle des Pflichtfelds incident_id hinzufügt, liefert die Schema-Prüfung einen unabhängigen Blocker. Das Team erhält zwei verschiedene Fehlerklassen:

• inhaltliche Geltungsbereichsüberschreitung,
• Verletzung der Datenstruktur.

Ein lokaler schneller Durchlauf vor dem push spart Zeit und macht das Spezifikations-Gate zu einem gewohnten Teil des Arbeitszyklus. In pre-commit führen Sie nur die geänderten Dateien aus. Den vollständigen Lauf überlassen Sie GitHub Actions, um den Entwickler nicht durch eine lange Prüfung aller Fixtures auszubremsen.

Für das Incident-Projekt genügt ein Befehl, der drei Dinge tut:

• den Coverage-Graphen aufbauen,
• den Geltungsbereich anhand von Diffs prüfen,
• die betroffenen JSON-Blöcke validieren.

Wenn der lokale Bericht bereits orphan requirement, rogue task oder schema mismatch zeigt, korrigiert der Autor die Spezifikation vor dem Anlegen des Pull Requests und nicht erst nach Erhalt des roten Status im entfernten CI.

> [project script] – Beispiel einer lokalen Wrapper-Datei für scripts/spec_ci/*.py.

#!/usr/bin/env bash
set -euo pipefail

python3 scripts/spec_ci/check_coverage.py \
  --requirements requirements.md \
  --plan plan.md \
  --out out/spec-ci/coverage-report.json

python3 scripts/spec_ci/check_scope.py \
  --domain models/incident-response.yaml \
  --plan plan.md \
  --contracts contracts/api.md \
  --out out/spec-ci/scope-violations.ndjson

python3 scripts/spec_ci/extract_fixtures.py \
  --from validation.md \
  --out out/spec-ci/fixtures

python3 scripts/spec_ci/validate_schema.py \
  --schemas schemas \
  --fixtures out/spec-ci/fixtures \
  --out out/spec-ci/schema-audit.json

Zusammenfassung

Das Spezifikations-Gate macht die Spezifikation zum ausführbaren Schiedsrichter des Repositorys. GitHub Actions blockiert den Pull Request bei drei Klassen von Verstößen:

• nicht abgedeckte User Stories,
• fremde Szenarien im Plan,
• JSON-Schema-Fehler in den Validierungsbeispielen.

Für das Team verändert dies den Charakter des Reviews. Anstelle einer subjektiven Auseinandersetzung über die Vollständigkeit der Anforderungen erscheint ein Diagnosebericht mit Datei, Zeile, Regel und Aktion.

In der Incident-Automatisierung ist diese Strenge besonders wichtig. Ein falscher Geltungsbereich oder ein schwacher Payload-Vertrag kann zu drei Konsequenzen führen:

• falsche Eskalationen,
• gefährliche Auto-Operationen,
• Verlust des Vertrauens in die Remediation.

Im Folgenden wird dieser Kreislauf zur Grundlage für die Datei-Schlichtung strittiger Änderungen.

Der minimale ausführbare Satz für dieses Kapitel liegt in examples/spec-ci/. Durchlaufen Sie ihn, bevor Sie den vollständigen GitHub-Actions-Prozess einführen. Erreichen Sie zunächst ein grünes lokales Gate. Übertragen Sie dann dieselben Befehle ins CI.

> [runnable] – ausführbares Beispiel: examples/spec-ci/scripts/check_coverage.py und examples/spec-ci/scripts/validate_schema.py.

cd book2/examples/spec-ci
python3 scripts/check_coverage.py --requirements requirements.md --plan plan.md
python3 scripts/validate_schema.py --schema schemas/incident_payload.schema.json --fixtures fixtures

AoT-Gate für Agentenpläne

Spec CI prüft nicht nur textuelle Anforderungen. Wenn ein Agent einen Plan als Menge atomarer Aktionen aufbaut, wird auch dieser Plan zu einem prüfbaren Artefakt. Das Format kann einfach sein: atoms[], wobei jedes Atom id, kind, name, input und dependsOn hat.

Minimale Regel: Das LLM darf Atome vorschlagen, aber es darf sie nicht ausführen, bevor sie geprüft wurden. Das lokale Gate muss Folgendes ablehnen:

• unbekannter Werkzeugname;
• fehlende Pflichtparameter;
• Verweis auf das Ergebnis eines nicht existierenden Atoms;
• Abhängigkeitszyklus;
• Aktion außerhalb des Domänenmodells incident-response.

Für high_memory_usage sieht das so aus:

{
  "atoms": [
    {"id": 1, "kind": "tool", "name": "read_metrics", "input": {"window": "10m"}, "dependsOn": []},
    {"id": 2, "kind": "tool", "name": "check_readiness", "input": {"incident_id": "HM-2026-05-17-01"}, "dependsOn": [1]},
    {"id": 3, "kind": "tool", "name": "dry_run", "input": {"action": "restart_pod"}, "dependsOn": [2]}
  ]
}

Ein solcher Plan darf nicht nach der Überzeugungskraft des Textes akzeptiert werden. Er muss als Graph validiert werden: topologische Sortierung, Liste der erlaubten name, JSON Schema für input jedes Werkzeugs und eine separate Prüfung des Konsequenzradius. Dies ist dasselbe Prinzip wie für requirements.md → plan.md: Eine Spezifikation ist nur dann nützlich, wenn sie maschinell abgelehnt werden kann.

Artefakte und Fertigkeitskriterien

Der vollständige Track fügt .github/workflows/spec-ci.yml oder sein projekteigenes Gegenstück hinzu, out/spec-ci/coverage-report.json für den Graphen requirements → plan, out/spec-ci/scope-violations.ndjson mit Verletzungen des Domänenmodells, out/spec-ci/schema-audit.json für die Fixtures aus validation.md und eine lokale Wrapper-Datei für den schnellen Durchlauf. Betrachten Sie ihn als bereit, wenn die Geltungsbereichsprüfung autonome Aktionen außerhalb des Modells incident-response blockiert, die Aufgabe spec_gate im geschützten Branch verbindlich ist und das CI-Diagnoseformat Datei, Zeile, Regelidentifikator und Aktion nennt.

Praxis

1. cd book2/examples/spec-ci && python3 scripts/check_coverage.py --requirements requirements.md --plan plan.md – *Erwartung: Code 0, stdout – eine Zeile coverage ok: 3 requirements covered.*
2. python3 scripts/validate_schema.py --schema schemas/incident_payload.schema.json --fixtures fixtures – *Erwartung: Code 0; stdout enthält valid-incident.json: valid und invalid-missing-incident-id.json: expected invalid, rejected: missing required property incident_id (die negative Fixture ist mit _expected_invalid: true markiert und gilt daher als erfolgreich abgelehnt).*

1. Übertragen Sie eine Zeile Spec CI in capstone/validation.md: „coverage ok: 3/3, schema ok: 2/2 (negative abgelehnt wegen missing required property incident_id)“. Erwartung: Bei der nächsten Regression erlaubt die Zeile, wiederherzustellen, was das Zusammenführen genau blockiert, ohne CI-Logs zu lesen.

Kontrollfragen

1. Warum ist Coverage nach Wörtern schwächer als der Graph requirements → plan?
2. Welche Verstöße muss die Geltungsbereichsprüfung erkennen und welche nicht?
3. Was macht einen CI-Fehler ohne Untersuchung behebbar?
4. Das Spezifikations-Gate blockiert das Zusammenführen wegen einer Nichtübereinstimmung der REQ-ID. Der Programmierer möchte die REQ-ID zu einem bestehenden Planpunkt hinzufügen und den Pull Request zusammenführen. Was ist an diesem Vorgehen gefährlich?