FR-3/FR-4 beschreiben einen älteren Änderungsvertrag als das ausgelieferte req_update

[hauschel]

Anlass

Store-Review vom 2026-09-08, Funde 4 und 5 und Ursachenabschnitt 11.2: "Requirement und Werkzeugvertrag driften unbemerkt". Der Befund ist am 2026-09-09 gegen das ausgelieferte Tool-Schema von req_update verifiziert.

Befund

FR-3 sagt Verhalten zu, das req_update nicht hat -- und verschweigt Verhalten, das es hat.

• FR-3 (description): eine Anderung erfolgt, "ohne ... die Verknupfungen zu Terms und Constraints anzutasten", AC5 wiederholt es. req_update tastet sie sehr wohl an: usesTermCodes ersetzt die arkreq:usesTerm-Kanten wholesale (seit req_update und uc_update koennen usesTerm-Kanten nicht entfernen #540) -- ein Term, der nicht in der Liste steht, wird entfernt. Die Zusage gilt nur fur einen Aufruf, der den Parameter weglasst.
• FR-3 AC4: "Mitgegebene Akzeptanzkriterien ersetzen die bestehenden vollstandig." req_update kennt kein Voll-Ersetzen, sondern drei enge Parameter: newAcceptanceCriteria (anhangen), acceptanceCriteriaTextPatches (positionsweise korrigieren), removeAcceptanceCriterionPositions (entfernen, mindestens eines muss bleiben).
• FR-3 gegen FR-4: FR-4 kennt nur das Herstellen einer Term-Verknupfung, FR-3 verbietet dem Anderungsweg, Verknupfungen anzutasten. Zusammengenommen beschreibt der Requirement-Korpus keinen Weg, eine Term-Verknupfung wieder zu losen -- obwohl das Werkzeug ihn seit req_update und uc_update koennen usesTerm-Kanten nicht entfernen #540 hat. UC3 zeigt dieselbe Lucke im Ablauf.

Der Fund trifft also nicht das Werkzeug, sondern das Modell: die Requirements beschreiben einen alteren Vertrag als den ausgelieferten.

Ursache

Es gibt keinen Ort, an dem das Tool-Schema gegen die Requirements gehalten wird, die es einlosen soll. #540 hat das Verhalten geandert, die Requirements sind mitgelaufen -- niemand hat es gemerkt, weil kein Check und kein Test die beiden Seiten verbindet.

Was es kunftig verhindert

Ein Requirement, das dem Code widerspricht, ist schlimmer als keins: es wird beim Lesen fur die Zusage gehalten, und ein Agent, der danach baut, baut am ausgelieferten Verhalten vorbei. Der Bestand hat drei solche Stellen in einem einzigen Requirement.

Vorschlag

1. FR-3 und FR-4 gegen das heutige req_update neu fassen (description, AC4, AC5; de und en), und den Loseweg als eigenes Akzeptanzkriterium oder eigenes Requirement fuhren.
2. Fur die Ursache: den Abgleich Tool-Schema gegen die Requirements als wiederkehrenden Punkt in /arknet:store-review verankern (kein store_check-Kandidat -- die eine Seite ist Java-Code, die andere Store-Inhalt).

Zu entscheiden

Ob Punkt 1 als Korrektur an FR-3/FR-4 lauft oder ob der Requirement-Schnitt fur den Anderungsweg insgesamt neu gezogen wird (Anlegen / Andern / Verknupfen / Losen als vier Requirements statt zwei).