Geplante Änderungen mit OpenSpec
Diese Seite richtet sich an Entwickler, die eine größere Änderung an Exponential planen oder eine Änderung bauen, die
jemand anderes geplant hat. Sie erklärt das Verzeichnis openspec/ im Wurzelverzeichnis des Repositorys und wie eine
Änderung es durchläuft. Kleine Korrekturen brauchen es nicht; eine Änderung, die eine Funktion, ein Modul oder eine
Erweiterung hinzufügt oder mehrere Designs berührt, sollte dort beginnen.
OpenSpec (github.com/Fission-AI/OpenSpec) hält den Plan einer Änderung als
einfaches Markdown neben dem Code, sodass der Plan im selben Pull Request wie der Code geprüft wird und in der
Historie bleibt. Exponential lädt zur Laufzeit nichts aus openspec/.
Das Verzeichnis
| Pfad | Inhalt |
|---|---|
openspec/config.yaml | Der Projektkontext und die Regeln, denen jedes Artefakt folgt: Architekturregeln, die Prüfungen, die eine Änderung nennt, die Plattformmatrix aus Datenbanken und Suchmaschinen |
openspec/schemas/plan-driven/ | Das Schema: welche Artefakte eine Änderung hat, in welcher Reihenfolge, und die Vorlage jedes Artefakts. SOURCE sagt, wo das gemeinsame Schema gepflegt wird |
openspec/changes/<name>/ | Eine laufende Änderung: proposal.md, specs/, design.md, tasks.md, plan.md, verify.md |
openspec/changes/archive/<datum>-<name>/ | Eine fertige und gemergte Änderung, so aufbewahrt, wie sie war |
openspec/specs/ | Das aktuelle Verhalten, eine Spec je Fähigkeit; eine archivierte Änderung führt ihre Specs hier zusammen |
openspec/handoff/ | Eine längere Spezifikation eines Tickets, auf die Änderungen als Entwurfsquelle verweisen, mit ihren Mockups |
Die Schritte einer Änderung
Das Schema plan-driven ordnet die Artefakte als Vorschlag, Specs, Entwurf, Aufgaben, Plan, Umsetzung, Prüfung:
- Vorschlag (
proposal.md): warum die Änderung nötig ist, was sich ändert, welches Ticket sie umsetzt und was nicht dazugehört. - Specs: das beobachtbare Verhalten als Anforderungen mit Szenarien (WHEN ... THEN ...); keine Klassennamen oder Dateipfade. Wo sich das Verhalten je Siteaccess, Rolle oder Suchmaschine unterscheidet, sagt es ein Szenario.
- Entwurf (
design.md): die Erweiterung, die die Änderung trägt (und warum eine Änderung inlib/oderkernel/nötig ist), die INI-Dateien und Schlüssel, die Richtlinien und Einschränkungen, die Datenbanktabellen und wie eine bestehende Installation sie erhält. - Aufgaben (
tasks.md): Gruppen von Arbeit; jede Gruppe bringt ihre eigenen Tests und ihre Dokumentation mit. - Plan (
plan.md): die Aufgaben als ausführbare Schritte, Test zuerst. - Umsetzung: die Arbeit, in einem eigenen Worktree, nie im Haupt-Checkout.
- Prüfung (
verify.md): die genaue phpunit-Aufrufzeile und das Ergebnis jeder betroffenen Suite und die übrigen Projektprüfungen.
Ist die Änderung gemergt, wandert sie nach openspec/changes/archive/, und ihre Specs aktualisieren openspec/specs/.
Geplante und fertige Änderungen
| Änderung | Stand |
|---|---|
add-workflow-definitions, add-workflow-runtime, add-workflow-jobs-and-timers, add-workflow-admin-ui, add-workflow-review-options, add-workflow-integrations, add-workflow-webhooks-and-importers, add-workflow-reference-cases | Geplant: die grafischen redaktionellen Workflows der Erweiterung expworkflow; Entwurfsquelle openspec/handoff/expworkflow-16702-spec.md |
add-workflow-outward-action-safeguards, add-channel-posts, add-newsletter-welcome-series, add-form-destinations, add-ai-field-provenance, add-newsletter-segments, add-share-metadata | Geplant: Marketing-Automatisierung auf dem Workflow-Designer (Schutz für Aktionen nach außen, Beiträge in Kanäle, Willkommensserie im Newsletter, Ziele für Formulare, Herkunft von KI-Feldern, Segmente im Newsletter, Metadaten zum Teilen); Entwurfsquelle und Bauanleitung openspec/handoff/marketing-automation-16741.md |
archive/2026-11-02-add-admin-search | Fertig: Suchvorschläge beim Tippen und die Suchseite mit ihrer Filterleiste; Specs in openspec/specs/admin/ |
Die Artefakte von OpenSpec selbst sind auf Englisch geschrieben.