OpenSpec abgelehnte Vorschläge: Eine Konvention für die Entscheidungsgeschichte

Kein Ablehnungszustand. Hier ist der Workaround.

Inhaltsverzeichnis

Ein Agent, der vor sechs Monaten „Persistenz in eine Shared Library verlagern“ vorgeschlagen und umgesetzt hat, wird dieses Vorschlag im nächsten Quartal wieder gern machen, es sei denn, etwas Dauerhaftes teilt ihm mit, dass diese Idee bereits untersucht und abgelehnt wurde – und OpenSpec verfügt heute über keinen eingebauten Zustand dafür.

/opsx:archive ist für genau eines Ergebnis gebaut: eine Änderung, die ausgeliefert wurde. Es synchronisiert die Delta-Spezifikationen in openspec/specs/ und verschiebt den Ordner nach openspec/changes/archive/YYYY-MM-DD-<name>/ als Aufzeichnung, was sich geändert hat und warum. Es gibt keinen Gegenpart wie /opsx:reject oder /opsx:abandon, und nichts im Archivformat sagt einem zukünftigen Vorschlag: „Diese exakte Idee wurde untersucht und abgelehnt.“ Diese Lücke ist genau in den Codebasen am wichtigsten, für die OpenSpec sonst gut geeignet ist: Brownfield-Systeme mit einer kleinen Anzahl von Mitwirkenden und Agenten, die regelmäßig dieselben Architekturfragen neu durchdenken – diese beiden Dienste zusammenführen, diese Persistenzschicht teilen, diese HTTP-Grenze durch einen direkten Import ersetzen.

Ein geschichtetes Entscheidungsarchiv, das Kontext in einen neuen Vorschlag zurückführt

Dies ist keine hypothetische Lücke. Sie wurde direkt mit den Maintainern von OpenSpec selbst als Feature-Anfrage erörtert, und der Verlauf dieses Gesprächs ist es wert, bekannt zu sein, bevor Sie eine eigene Lösung improvisieren: was das Projekt tatsächlich beschlossen hat bestimmt, welche Konvention es wert ist, übernommen zu werden. Dieser Leitfaden erklärt, was passiert, wenn Sie sich ausschließlich auf /opsx:archive verlassen, die bereits im Issue-Tracker von OpenSpec stattgefundene echte Diskussion und ein leichtgewichtiges decision.md-Muster, das Sie heute übernehmen können, ohne auf – oder auf – Kernunterstützung warten zu müssen.

Warum Archivierung allein keine abgelehnte Entscheidung aufzeichnet

Das Archivieren einer Änderung, die Sie beschlossen haben nicht zu bauen, funktioniert technisch – der Ordner wird ohnehin aus Ihrer aktiven Liste entfernt. Das Problem ist, was dieser archivierte Ordner nicht mehr kommuniziert, sobald er neben Dutzenden ausgelieferter Änderungen liegt:

  • Kein Statusfeld. Eine archivierte Änderung sieht identisch aus, egal ob sie ausgeliefert wurde oder drei Nachrichten nach /opsx:propose aufgegeben wurde. Ein Teammitglied oder ein Agent, der openspec/changes/archive/ durchsucht, kann den Unterschied nicht erkennen, ohne jeden Vorschlagsordner zu öffnen und die Artefakte darin zu lesen.
  • Kein Signal, vorher zu prüfen. Nichts im Standard-Workflow weist einen Agenten an, das Archiv zu durchsuchen, bevor er einen neuen Vorschlag erstellt. /opsx:propose entwirft aus Ihrer aktuellen Anfrage und dem Zustand der Codebasis, Punkt – es referenziert keine zuvor abgelehnten Änderungen, außer Sie sagen es ihm.
  • Delta-Spezifikationen, die nicht synchronisiert werden sollen. Wenn eine abgelehnte Änderung bereits Entwurfs-Delta-Spezifikationen hat und Sie sie auf herkömmliche Weise archivieren, wird /opsx:archive zunächst anbieten, diese Deltas in openspec/specs/ zu synchronisieren. Wenn Sie dieses Angebot annehmen, lehren Sie Ihre kanonischen Spezifikationen, Verhalten zu beschreiben, das Sie beschlossen haben nicht zu bauen, was das Aufzeichnungsprotokoll „Was macht das System aktuell“ leise korrupt macht, das jeder andere Vorschlag liest, bevor er irgendetwas plant.

Keines davon ist ein Fehler. /opsx:archive tut genau das, was seine Dokumentation besagt: es vollendet eine Änderung, die ausgeliefert wurde. Der Ablehnungsfall liegt absichtlich außerhalb dieses dokumentierten Umfangs, und der eigene Team-Workflow-Leitfaden von OpenSpec macht deutlich, dass das meiste, was er empfiehlt – Branch-Konventionen, PR-Review-Reihenfolge, wann archiviert wird – Konvention ist, die über dem Tool liegt, nicht etwas, das OpenSpec für Sie durchsetzt. Die Handhabung einer Ablehnung ist eine weitere Konvention, die Sie selbst definieren können, und die CLI gibt Ihnen bereits den Flag, den Sie benötigen, um es sauber zu tun: übergeben Sie --skip-specs, wenn Sie eine Änderung archivieren, die Sie nicht ausliefern, damit openspec archive investigate-shared-persistence --skip-specs den Ordner weglegt, ohne openspec/specs/ überhaupt anzufassen.

Was die Maintainer von OpenSpec tatsächlich über ADR-Unterstützung beschlossen haben

Bevor Sie eine Hauskonvention erfinden, lohnt es sich zu lesen, wie diese exakte Frage öffentlich ausgetragen wurde, denn die Lösung ist spezifischer – und interessanter – als „Nein“. GitHub-Issue #557 wurde im Januar 2026 mit einer Anfrage nach erstklassiger Unterstützung für Architektur-Entscheidungsprotokolle (Architecture Decision Records, ADR) eröffnet: dauerhafte Aufzeichnungen, die unabhängig vom Lebenszyklus einer einzelnen Änderung bestehen, damit eine abgelehnte oder überholte Entscheidung für jeden zukünftigen Vorschlag sichtbar bleibt. Ein Mitwirkender öffnete sogar einen Pull Request, der es implementierte.

Es folgte eine sieben Monate dauernde, genuinely substanzielle Diskussion mit dem Lead-Maintainer Tabish Bidiwale (@TabishB) und mehreren stark engagierten Community-Mitgliedern, die immutable versus mutable Aufzeichnungen, ob ein ADR zur Forschungs- oder Designphase gehört, übergreifende Ownership, wenn eine Entscheidung in ein Dutzend späterer Änderungen kaskadiert, und wie ADRs sich zu Spezifikationen als „autoritative“ Beschreibung des Systems verhalten. Die frühe Rahmung von Tabish Bidiwale setzte die Richtung, in die sich der Thread letztlich einpendelte: OpenSpec sollte standardmäßig leichtgewichtig bleiben und spezialisierte Workflows wie ADRs über sein Schema-System konfigurierbar machen, anstatt sie in den Kern zu backen. Ein Community-Mitglied fasste später zusammen, wo die Diskussion landete:

ADR-Workflows sind wertvoll, aber OpenSpec bietet derzeit keine erstklassige/native ADR-Unterstützung… die hier diskutierte Richtung ist es, den Standard-Workflow leichtgewichtig zu halten und spezialisierte Workflows konfigurierbar zu machen.

Maintainer Clay Good (@clay-good) schloss das Issue auf dieser Grundlage im August 2026 und verlegte es in GitHub-Diskussion #1553, damit das Gespräch weiterentwickelt werden konnte, ohne als ungeklärter Bug offen zu bleiben. Das ist eine vernünftige Entscheidung für ein Tool, dessen gesamter Ansatz darin besteht, standardmäßig speck-Kit-artige Zeremonie zu vermeiden. Es bedeutet auch, dass die Lösung eine Ebene höher liegt, an einer von zwei Stellen:

  1. Ein Community-Schema. Das spec-driven-with-adr-Schema, erstellt von OpenSpec-Technikberater Hari Krishnan (@harikrishnan83) und dokumentiert auf intent-driven.dev, fügt ein fünftes Artefakt zur standardmäßigen Vier-Artefakt-Pipeline von OpenSpec hinzu. Es existiert, weil das Standard-Schema die Argumentation von design.md verliert, sobald eine Änderung archiviert wird – nur die Delta-Spezifikationen werden nach vorn synchronisiert, so dass das „Warum“ hinter einer Entscheidung mit der Änderung verschwindet, es sei denn, etwas anderes bewahrt es auf.
  2. Eine repository-weite Konvention. Eine kleine, handgemachte decision.md-Datei plus eine Benennungsregel, die nichts kostet und kein Installieren eines benutzerdefinierten Schemas erfordert.

Der Rest dieses Leitfadens behandelt Option zwei im Detail, da sie der niedrigere Reibungspunkt für die meisten Teams ist – und, wie der Abschnitt über das Community-Schema unten zeigt, ist sie kompatibel mit einem späteren Wechsel zu diesem schwereren Tooling, falls Ihr Ablehnungsprotokoll groß genug wird, es zu rechtfertigen.

Die decision.md-Konvention zur Aufzeichnung einer abgelehnten Änderung

Strukturieren Sie eine abgelehnte Untersuchung so wie eine ausgelieferte, aber stoppen Sie vor der Synchronisation irgendwelcher Deltas und fügen Sie eine Datei hinzu, die das Ergebnis offen ausspricht:

openspec/
  changes/
    archive/
      2026-09-16-rejected-shared-persistence-layer/
        proposal.md
        decision.md

decision.md beantwortet dieselben vier Fragen, die ein ordentliches Architecture Decision Record beantwortet – was entschieden wurde, warum, welche Alternativen bestanden und was die Antwort verändern würde:

# Entscheidung

Status: Abgelehnt

## Entscheidung

Ersetzen Sie nicht die HTTP-Grenze zwischen Diensten durch einen direkten
Package-Import zwischen den beiden Go-Diensten.

## Gründe

- Erhöht die Kopplung zur Kompilierzeit zwischen unabhängig ausgelieferten Diensten.
- Macht die Persistenzschicht einen impliziten, undokumentierten Vertrag.
- Der gemessene Nutzen (Latenz, Code-Duplizität) war kleiner als die
  Kopplungskosten in dieser Codebasis.

## In Betracht gezogene Alternativen

- Geteiltes internes Go-Modul – aus demselben Kopplungsgrund abgelehnt.
- gRPC statt HTTP – aufgeschoben, nicht abgelehnt; erneut prüfen, wenn HTTP-
  Overhead zu einem gemessenen Engpass wird.

## Nur erneut in Betracht ziehen, wenn

- Die beiden Dienste absichtlich zu einer deploybaren Einheit zusammengeführt werden, oder
- Latenzmessungen zeigen, dass die HTTP-Übertragung ein bewiesener Engpass ist.

## Verwandt

- Architektur-Regel: Dienste kommunizieren über HTTP, nicht über geteilte Pakete.

Die eine harte Regel, die diese gesamte Konvention funktionieren lässt: Führen Sie den Synchronisationsschritt für eine abgelehnte Änderung nicht aus. Wenn /opsx:propose bereits Delta-Spezifikationen entworfen hat, bevor Sie sich gegen die Änderung entschieden haben, nutzen Sie den Flag, den die CLI Ihnen genau für diese Situation gibt:

openspec archive investigate-shared-persistence --skip-specs

--skip-specs sagt openspec archive, die Änderung wegzuverschieben, ohne openspec/specs/ überhaupt anzufassen, was der sicherste Standard für alles ist, was Sie archivieren, ohne es auszuliefern. Wenn Sie stattdessen den gewöhnlichen Synchronisationsprompt annehmen, würden die Delta-Spezifikationen der abgelehnten Idee in Ihre kanonischen Spezifikationen merged, und die kanonische openspec/specs/ sollte beschreiben, was das System aktuell tut, nicht jede Idee, die entworfen und abgelehnt wurde. Wenn eine Änderung aus strukturellen Gründen dauerhaft keine Spezifikationsänderungen hervorbringt – ein reiner Untersuchungsordner, zum Beispiel – unterstützt OpenSpec auch, skip_specs: true in der .openspec.yaml dieser Änderung zu erklären, damit sie sauber ohne Flag archiviert wird.

Ablehnene Änderungen benennen, damit Menschen und Agenten das Archiv scannen können

Eine decision.md-Datei hilft nur, wenn jemand den Ordner öffnet. Präfix den Ordnernamen mit dem Ergebnis, damit sowohl ein Mensch, der ls openspec/changes/archive/ durchblättert, als auch ein Agent, der Änderungen auflistet, den Status ohne das Öffnen einer einzigen Datei erkennen können:

2026-09-16-rejected-shared-persistence-layer/
2026-09-20-abandoned-react-router-migration/
2026-10-01-superseded-old-auth-design/
2026-10-10-add-project-filtering/          # ausgeliefert, kein Präfix nötig

Dies spiegelt den Status-Vokabular wider, das bereits für eigenständige Entscheidungsprotokolle empfohlen wird – vorgeschlagen, akzeptiert, ersetzt, veraltet – angewendet auf das eigene Archiv von OpenSpec anstatt eines separaten docs/decisions/-Ordners. Halten Sie das Vokabular klein. Drei oder vier konsistente Präfixe schlagen eine Freitext-Statuszeile, die jeder Vorschlag leicht anders buchstabiert.

Wie man seinen Agenten dazu bringt, das Archiv vor einem neuen Vorschlag zu prüfen

Benennung und eine decision.md-Datei lösen die Entdeckbarkeit für einen Menschen, der den Ordner durchblättert. Sie tun von allein nichts, um einen Agenten dazu zu bringen, das Archiv zu durchsuchen, bevor er einen neuen Vorschlag entwirft – das muss eine explizite Anweisung sein, denn /opsx:propose tut es standardmäßig nicht, und kein Maß an ordentlicher Dateibennennung ändert das von allein.

Zwei Stellen für diese Anweisung, passend zu dem, wie OpenSpec bereits erwartet, dass projektspezifische Richtlinien injiziert werden:

In openspec/config.yaml, unter dem context:-Feld, das in jede Planungsanfrage injiziert wird (beachten Sie die 50KB-Grenze, die im OpenSpec-Quickstart behandelt wird):

context: |
  Bevor Sie eine Änderung vorschlagen, durchsuchen Sie openspec/changes/archive auf Ordner
  mit dem Präfix "rejected-" oder "abandoned-", die eine materiell ähnliche
  Idee beschreiben. Wenn einer existiert, fassen Sie seine decision.md zusammen und
  legen Sie dar, was sich geändert hat, bevor Sie die Idee erneut vorschlagen. Verhandeln Sie
  keine abgelehnte Entscheidung neu, ohne neuen Beleg.

In AGENTS.md oder den eigenen Agenten-Anweisungen Ihres Projekts, als stehende Regel statt als pro-Anfrage-Kontext-Blob:

## Abgelehnte OpenSpec-Änderungen

Wenn ein Vorschlag untersucht und abgelehnt wird:

1. Synchronisieren oder wenden Sie seine Delta-Spezifikationen nicht an.
2. Fügen Sie `decision.md` mit Status, Entscheidung, Gründen, In Betracht
   gezogenen Alternativen und Nur erneut in Betracht ziehen, wenn hinzu.
3. Präfix den archivierten Ordnernamen: `rejected-<name>` oder `abandoned-<name>`.
4. Bevor Sie eine materiell ähnliche Änderung vorschlagen, durchsuchen Sie
   `openspec/changes/archive/` und referenzieren Sie die vorangegangene Entscheidung.
5. Öffnen Sie eine abgelehnte Entscheidung nicht erneut, es sei denn, ihre dokumentierten
   Wiedervorlage-Bedingungen haben sich tatsächlich geändert.
flowchart TD A[Nouvelle idee für eine Änderung] --> B{openspec/changes/archive durchsuchen} B -->|Ähnliche abgelehnte Entscheidung gefunden| C[Vorherige decision.md zusammenfassen] C --> D{Wiedervorlage-Bedingungen geändert?} D -->|Nein| E[Nicht erneut vorschlagen. Die Entscheidung referenzieren.] D -->|Ja| F["/opsx:propose mit dem geänderten Kontext dargelegt"] B -->|Nichts ähnliches gefunden| F

Keine der Anweisungen garantiert Compliance – ein Agent kann den Suchschritt immer noch überspringen, so wie er jede andere injizierte Kontextinformation überspringen kann. Aber es ist der Unterschied zwischen „die Information existiert irgendwo im Repo“ und „dem Agenten wird jedes Mal gesagt, sie zu suchen“, und nur die zweite Option reduziert in der Praxis tatsächlich wiederholte Untersuchungen.

Ein konkretes Beispiel: Einen Vorschlag ablehnen und ihn dann korrekt erneut in Betracht ziehen

Fassen Sie die Teile für einen konkreten Fall zusammen. Sagen wir, ein Teammitglied bittet einen Agenten, den Ersatz eines HTTP-Aufrufs zwischen Diensten durch einen direkten Go-Package-Import zu betrachten, um Netzwerklatenz zu reduzieren.

  1. Erkunden, dann vorschlagen. /opsx:explore liest beide Dienste, und /opsx:propose replace-http-with-direct-import entwirft einen Vorschlag, ein Design-Dokument, das den Latenzgewinn gegen die Kopplungskosten abwägt, und eine Entwurfs-Delta-Spezifikation.
  2. Untersuchen und ablehnen. Nach Überprüfung des Design-Dokuments entscheidet das Team, dass der Kopplungskosten – zwei unabhängig ausgelieferte Dienste teilen nun eine Kompilierzeit-Abhängigkeit – einen Latenzgewinn überwiegt, den niemand tatsächlich als Problem gemessen hat. Es wird nichts gebaut.
  3. Archivieren ohne Synchronisation. Anstatt den Ordner zu löschen, führen Sie openspec archive replace-http-with-direct-import --skip-specs aus, fügen Sie dann decision.md mit Status: Rejected, den obigen Gründen und einer Nur erneut in Betracht ziehen, wenn-Klausel hinzu, die die Bedingung benennt, die die Antwort verändern würde – zum Beispiel, „Latenzmessungen zeigen, dass die HTTP-Übertragung ein bewiesener Engpass ist“. Benennen Sie den Ordner mit einem rejected--Präfix um, so dass er als openspec/changes/archive/2026-09-16-rejected-replace-http-with-direct-import/ lesbar ist.
  4. Monate später wirft jemand es erneut auf. Ein anderer Mitwirkender, oder derselbe Agent in einer neuen Sitzung, wird gebeten, den „Checkout-to-Inventory-Aufruf zu beschleunigen“, und beginnt, einen Vorschlag zu entwerfen, der stark nach derselben Idee aussieht. Da openspec/config.yaml den Agenten anweist, zuerst das Archiv zu durchsuchen, findet er den abgelehnten Ordner, liest decision.md und meldet zurück: „Eine materiell ähnliche Änderung wurde am 2026-09-16 aus Kopplungsgründen vorgeschlagen und abgelehnt. Die Wiedervorlage-Bedingung war ‚Latenzmessungen zeigen, dass die HTTP-Übertragung ein bewiesener Engpass ist‘. Haben Sie neue Messungen, oder ist dies ein anderes Problem?“
  5. Das Team liefert neue Beweise. Wenn das Profiling nun zeigt, dass die HTTP-Übertragung tatsächlich die Checkout-Latenz dominiert, ist das genau die geänderte Umstände, nach der das ursprüngliche decision.md gefragt hat. Der Agent fährt mit /opsx:propose fort, und die decision.md des neuen Vorschlags – wenn auch diese archiviert wird, akzeptiert oder abgelehnt – referenziert die vorherige unter Verwandt, so dass das Archiv als durchgängige Entscheidungsgeschichte lesbar ist und nicht als zwei unverbundene Ordner, die zufällig dieselbe Idee beschreiben.

Dieser fünfte Schritt ist der gesamte Punkt der Konvention. Ohne ihn passiert Schritt 4 entweder gar nicht – der Agent untersucht einfach von Null neu – oder es passiert per Zufall, weil sich ein Mensch das vorherige Gespräch erinnerte. Die decision.md-Datei und die Anweisung, das Archiv zu durchsuchen, verwandeln „jemand könnte es sich erinnern“ in etwas, das der Workflow tatsächlich prüft.

OpenSpec-Archiv vs. ein dediziertes ADR-Protokoll: Wer besitzt was

Sobald Sie decision.md-Dateien im Archiv pflegen, lohnt es sich, explizit zu sein, welches Artefakt welche Frage beantwortet, damit die Konvention nicht leise in doppelte Dokumentation umschlägt:

Artefakt Beantwortet
openspec/specs/ Was macht das System aktuell?
openspec/changes/<name>/ (aktiv) Was schlagen wir vor zu ändern, gerade jetzt?
openspec/changes/archive/<name>/ Was sich geändert (oder abgelehnt) hat in der Vergangenheit, und warum?
docs/adr/ (eigenständig, tool-neutral) Welche dauerhafte Architektur-Regel haben wir gelernt, unabhängig von einer einzelnen Änderung?

Für eine Entscheidung, die eng genug ist, um zu einer Untersuchung zu gehören – „wir haben geteilte Persistenzschicht betrachtet und nein gesagt“ – ist die oben genannte decision.md-im-Archiv-Konvention ausreichend. Für eine Entscheidung, die viele zukünftige Änderungen überdauern und einschränken sollte – „Dienste kommunizieren über HTTP, nie geteilte Pakete“ – fördern Sie sie zu einem eigenständigen Architecture Decision Record in docs/adr/, und lassen Sie die decision.md der abgelehnten Änderung sie unter Verwandt referenzieren. Diese Aufteilung hält das OpenSpec-Archiv auf einzelne Untersuchungen fokussiert, während das ADR-Protokoll die kleine Anzahl an Regeln hält, die den Lebenszyklus eines einzelnen Tools überdauern sollten – einschließlich einer zukünftigen Migration weg von OpenSpec insgesamt.

Wann das spec-driven-with-adr-Schema stattdessen übernehmen

Die handgemachte Konvention oben kostet nichts und passt in fünfzehn Minuten Einrichtung, was sie zum richtigen Standard macht. Aber es lohnt sich zu verstehen, was die strukturierte Alternative tatsächlich tut, bevor Sie entscheiden, dass Sie ein Namenspräfix outgrown haben.

spec-driven-with-adr fügt ein fünftes Artefakt, adr, zwischen design und tasks in OpenSpecs Pipeline ein. Anstatt ADR-Inhalte direkt in den Änderungsordner zu schreiben, produziert der adr-Schritt eine kurze, Änderung-lokale adr.md-Review-Manifest und, wenn die Änderung eine genuinely dauerhafte architektonische Verpflichtung einführt, eine nummerierte Aufzeichnung an der Repository-Wurzel – /adr/0042-use-postgres-for-catalog.md, Geschwister von openspec/, nicht darin verschachtelt. Jedes ADR, das das Schema erstellt, ist immutable, sobald es akzeptiert wurde: die eigenen Anweisungen des Schemas nennen dies eine „Eisenregel“ – Sie bearbeiten nie den Status, Körper oder das Datum einer akzeptierten Aufzeichnung. Um eine frühere Entscheidung zu ändern, schreiben Sie eine neue ADR, deren Supersedes:-Feld die alte benennt, und zukünftige Designs folgen dieser Supersession-Kette, um zu wissen, welche Entscheidungen noch gültig sind. Das ist eine rigideres Version genau der „nur erneut in Betracht ziehen, wenn“-Idee in der decision.md-Konvention oben, erzwungen durch das Schema statt einem Menschen überlassen, es aufzuschreiben.

Es lohnt sich, präzise zu sein, was dieses Schema löst und was nicht. Es ist für Entscheidungen gebaut, die akzeptiert werden und das Archivieren überdauern müssen – Postgres über DynamoDB, JWT über Session-Cookies – nicht für Vorschläge, die untersucht und abgelehnt wurden, ohne etwas auszuliefern. Eine abgelehnte Untersuchung hat unter diesem Schema auch keinen offensichtlichen Platz; Sie würden dieselbe decision.md-und-Benennungs-Konvention aus diesem Leitfaden darüber legen, nur /adr/-Aufzeichnungen referenzieren statt eines eigenständigen docs/adr/-Ordners.

Greifen Sie danach, wenn Sie eines der folgenden bemerken:

  • Ihre Anzahl abgelehnter Entscheidungen ist groß genug, dass das Durchsuchen von openspec/changes/archive/ nach Präfixen nicht mehr schnell ist.
  • Sie möchten dauerhafte architektonische Entscheidungen validiert und gegen jedes neue Design automatisch referenziert haben, statt durch Konvention und grep.
  • Mehrere Mitwirkende erfinden fortlaufend leicht unterschiedliche decision.md-Formate, und Sie möchten ein Schema, das ein immutable, nummeriertes Format erzwingt.

Die Installation eines benutzerdefinierten Schemas ist ein größeres Engagement als eine Benennungskonvention – es ändert, was /opsx:propose für jede zukünftige Änderung generiert, nicht nur für abgelehnte – betrachten Sie es also als einen Schritt nach oben, wenn die leichtgewichtige Version sichtbar an ihre Grenzen stößt, nicht als erste Maßnahme.

Fazit

Das OpenSpec-Archiv wurde um eines Ergebnis herum designed – eine Änderung, die ausgeliefert wurde – und seine eigenen Maintainer waren explizit, nach einer sieben Monate dauernden öffentlichen Diskussion, dass erstklassige Ablehnungs- oder ADR-Unterstützung dem Kern-Workflow nicht bald kommen wird. Das lässt die Lösung dort, wo OpenSpec bereits die meisten seiner Team-Konventionen platziert: in Ihrem Repository, nicht im Tool. Eine decision.md-Datei, der --skip-specs-Flag beim Archivieren, ein rejected-/abandoned--Namenspräfix und eine explizite Anweisung, die den Agenten anweist, das Archiv vor dem Vorschlagen zu durchsuchen, sind genug, um die meisten wiederholten Untersuchungen zu stoppen. Greifen Sie nach dem spec-driven-with-adr-Schema nur, wenn diese leichtgewichtige Konvention sich unter der Anzahl der Entscheidungen, die Sie tracken, genuinely belastet fühlt – und auch dann, halten Sie die Unterscheidung klar: es verwaltet Entscheidungen, die Sie akzeptiert haben und die das Archivieren überdauern sollen, nicht die, die Sie abgelehnt haben.

Abonnieren

Neue Beiträge zu Systemen, Infrastruktur und KI-Engineering.