Projektkonfiguration (config.yaml)

Jedes Feld in openspec/config.yaml: Das Schema, den Kontext und die Regeln, nach denen dieses Projekt plant.

Standort

Jedes OpenSpec-Projekt speichert seine Konfigurationsdatei unter openspec/config.yaml im Projektstammverzeichnis.

Felder

Schlüssel	Typ	Erforderlich	Auswirkung
schema	string	Ja	Das Workflow-Schema, dem die Änderungen dieses Projekts folgen
context	string	Nein	In jedes Artefakt, apply und archive eingefügt
rules	Map: Artefakt-ID → Liste von Strings	Nein	Zusätzliche Regeln, die zur integrierten Anleitung eines Artefakts hinzugefügt werden
operations	Map: Operation → Anleitungsliste	Nein	Beratende Anleitung für apply- und archive-Arbeiten
store	string	Nein	Fallback-OpenSpec-Root, wenn dieses openspec/ nur Konfiguration ist
references	list	Nein	Stores, deren Specs in die Anweisungen indiziert werden

Ungültige Felder lassen einen Befehl niemals fehlschlagen. Jedes Feld wird einzeln validiert, und ein ungültiger Wert wird mit einer Warnung verworfen. Eine Datei, die nicht gelesen werden kann oder kein gültiges YAML ist, wird mit einer Warnung ignoriert, außer bei openspec validate, das mit 1 endet, damit CI sie abfängt.

Was in diese Felder geschrieben werden soll, wird unter Projektkonfiguration behandelt.

schema

Das Workflow-Schema, dem jede Änderung in diesem Projekt folgt. Gültige Werte sind spec-driven oder ein Schema-Name, den das Projekt definiert. Führen Sie openspec schemas aus, um die verfügbaren Schema-Namen aufzulisten.

context

Freitext, der in die Anweisungen jedes Artefakts eingefügt und an apply und archive übergeben wird. Das Limit beträgt 50 KB, und ein größerer Wert wird mit einer Warnung ignoriert.

rules

Zusätzliche Regeln für ein Artefakt, die zur integrierten Anleitung des Schemas hinzugefügt werden:

rules:
  proposal:
    - Keep proposals under 500 words

Artefakt-IDs sind nicht auf die integrierten Namen beschränkt, sodass Artefakte aus benutzerdefinierten Schemas als Schlüssel verwendet werden können.

operations

Beratende Anleitung, wie apply- und archive-Arbeiten durchgeführt werden, getrennt von Artefakt-Regeln:

operations:
  apply:
    guidance:
      - Keep test summaries concise

Nur apply und archive werden gelesen.

store

Eine Store-ID, die als OpenSpec-Root verwendet wird und nur konsultiert wird, wenn dieses openspec/-Verzeichnis nur Konfiguration ist (keine specs/ oder changes/). Es ist ein Fallback, niemals eine Überschreibung. Die vollständige Abfolge ist Root-Auflösung.

references

Store-IDs, auf deren Specs die Arbeit dieses Projekts aufbaut. Ein Index der Specs jedes Stores (ID, Zusammenfassung, Fetch-Befehl) wird der Anweisungsausgabe hinzugefügt. Spec-Inhalte werden nie eingebettet, und die Root-Auflösung wird nie beeinflusst. Ein Eintrag ist eine Store-ID oder eine Map mit id und einer optionalen remote-Klonquelle:

references:
  - platform-specs
  - id: billing-specs
    remote: git@github.com:acme/billing-specs.git

Beispiel

Eine ausgefüllte config.yaml:

schema: spec-driven

context: |
  Designs and tasks must cover Windows, macOS, and Linux
  Write all artifacts in Spanish

rules:
  proposal:
    - Keep proposals under 500 words
    - Always state what is out of scope
  tasks:
    - Break tasks into chunks of max 2 hours

operations:
  apply:
    guidance:
      - Keep test summaries concise
  archive:
    guidance:
      - Summarize the archive outcome before finishing

Legacy-Namen

openspec/config.yml wird als Alias gelesen, wenn config.yaml nicht existiert. Wenn beide Dateien existieren, hat config.yaml Vorrang und openspec/config.yml wird ignoriert. openspec init erstellt config.yaml.