Provenienz

Die Provenienz ist der Nachweis über eine einzelne Arbeitsleistung – eine Aufgabe, einen Plan, eine Planaufgabe oder ein Arbeitspaket. Sie beantwortet die Fragen, die nach dem Zusammenführen einer Änderung gestellt werden müssen: Woher stammt diese Leistung? Wer hat sie angefordert? Wer ist ihr Inhaber? Wer hat welche Entscheidungen getroffen und warum? Und was wurde letztlich geliefert?

Coroid erstellt diesen Nachweis auf Basis der Vorgänge, die bereits innerhalb der Factory ablaufen: das Gespräch oder die Anfrage, die den Ausgangspunkt bildeten, die von den Beteiligten genehmigten Dokumente, die getroffenen Entscheidungen sowie die Pull Requests und Commits, die die Leistung umsetzen. Diesen gleichen Nachweis sehen Sie im Portal, in Pull Requests und Commits – auch die für die Aufgabe zuständigen Agenten können ihn einsehen.

Was die Provenienz beantwortet#

• Ursprung. Was die Arbeit ausgelöst hat – mit einem Link dazu: ein Chat-Gespräch, eine Prepare Work-Rezension, eine Anfrage zu Neue Aufgaben, ein importiertes oder per Webhook eingegangenes Issue, ein Hook, ein Zeitplan, ein MCP-Client, API, ein Ergebnis oder Bericht oder auch ein übergeordneter Plan oder eine Aufgabe.
• Anforderer und Inhaber. Die Person, die die Arbeit angefordert hat, und die aktuelle Inhaberin bzw. der aktuelle Inhaber. Wenn die Arbeit über ein Dienstkonto oder von außerhalb Ihrer Organisation eintrifft – etwa vom Autor eines GitHub-Issues –, nennt die Provenienz dieses Konto oder diese Person. Coroid füllt dabei niemals Felder mit Vermutungen aus.
• Entscheidungen. Freigaben, Änderungsanfragen, Starts, Stopps, Neubearbeitungen, Zusammenführungen, Überschreibungen und Änderungen der Inhaberschaft – jeweils mit Angabe, wer sie getroffen hat, wann und ggf. auch der Begründung.
• Diskussion. Die Nachrichten der Beteiligten, die die Arbeit geprägt haben: kurze Auszüge aus dem zugrundeliegenden Gespräch und aus den Rückmeldungen zu den Dokumenten – jeweils mit Angabe des Autors und einem Link.
• Lieferung. Pull Requests, Commits, QA-Ergebnisse, Rezensionsentscheidungen und Nachweise.

Eine zur einem Plan gehörende Aufgabe teilt sich den Ursprung und den Anforderer des Plans. Die Provenienz zeigt außerdem die Abfolge auf: die Aufgabe, ihr Plan und Arbeitspaket sowie das Gespräch oder die Anfrage, aus der sie hervorgegangen sind.

Zuerst die Zusammenfassung#

Jede Ansicht der Provenienz beginnt mit einer Zusammenfassung, sodass Sie auf einen Blick erkennen, wofür die Arbeit bestimmt ist und wer dahintersteht:

• Absicht: Was die Arbeit leistet und warum – in einem kurzen Absatz. Diese Angabe stammt entweder aus der genehmigten Absicht, ansonsten aus der genehmigten Spezifikation, danach aus der ursprünglichen Anfrage oder schließlich aus der Beschreibung der Aufgabe bzw. des Plans. Darunter steht jeweils angegeben, woher die Information stammt.
• Angefordert von: Die Person, das Dienstkonto oder die externe Person, die die Arbeit angefordert hat.
• Inhaber: Wer die Arbeit aktuell innehat. Das ist die Person, an die sie zuletzt übertragen wurde, ansonsten die Person, der die Aufgabe zugewiesen ist, danach der Inhaber des zugrundeliegenden Gesprächs oder der Anforderer.
• Genehmigt von: Die Personen, die die Absicht, die Spezifikation und den Implementierungsplan sowie den Plan selbst genehmigt haben – jeweils mit Angabe der Rolle, für die sie die Genehmigung ausgesprochen haben.
• Wichtige Entscheidungen: Bis zu fünf der jüngsten getroffenen Entscheidungen samt Begründung – jeweils mit der entsprechenden Erklärung.

Die aufgeführten Genehmigenden sind stets Menschen. Eine automatisch von Coroid aufgezeichnete Genehmigung wird nicht aufgeführt; siehe Automatische Entscheidungen.

Wo Sie es sehen#

Im Portal#

Öffnen Sie eine Aufgabe oder einen Plan in der Factory und expandieren Sie den Abschnitt Provenienz. Unter der Zusammenfassung finden Sie folgende Bestandteile:

• Ursprung: Woher die Arbeit stammt – mit einem Link zum zugrundeliegenden Gespräch, zur Anfrage, zum Issue oder Bericht.
• Abfolge: Der Plan und das Arbeitspaket, zu denen eine Aufgabe gehört, sofern sie zu einem Plan zählt.
• Entscheidungen: Geordnet von der ältesten zur neuesten Entscheidung – jeweils mit Begründung. Bei einer langen Historie werden die acht jüngsten Entscheidungen angezeigt; mit einem Klick sehen Sie den Rest.
• Diskussion: Die Nachrichten, die die Arbeit geprägt haben – geordnet von der neuesten zur ältesten.
• Lieferung: Pull Requests und wer sie zusammengeführt hat, Commits, QA-Ergebnisse, Rezensionen und Nachweise.

Eine kompakte Version dieser Informationen erscheint auf der Registerkarte Details einer Aufgabe sowie in der Promotions-Rezension eines Plans – jeweils mit einem Link zur vollständigen Provenienz.

Der Zugriff richtet sich nach der Arbeit selbst: Für die Provenienz einer Aufgabe ist der Lesezugriff auf ihr Projekt erforderlich; die Provenienz eines Plans ist wie der Plan selbst in Ihrer gesamten Organisation einsehbar.

In Pull Requests#

Jeder pull request Coroid-Auftrag enthält einen Provenienz-Abschnitt – egal ob er eine Aufgabe, einen Plan oder einen Release-Pull-Request liefert. Der Abschnitt beginnt mit derselben Zusammenfassung: dem Zweck, der Arbeit, wer sie angefordert hat, wer der Inhaber ist, wer die Freigaben erteilt hat und die wichtigsten Entscheidungen. Anschließend folgen die Herkunft mit ihren Links, die Abstammungslinie, die getroffenen Entscheidungen, die Lieferung sowie ein Link, um die Arbeit in Coroid zu öffnen.

Coroid erstellt die übrigen Abschnitte dazu: eine Zusammenfassung der Änderung, einen Link zur Aufgabe und den Rezensionsnachweis, die Annahmekriterien sowie den Status von QA und Rezension.

Coroid übernimmt nur die Abschnitte, die es in der Beschreibung mit versteckten Kommentaren kennzeichnet. Wenn es den pull request aktualisiert – etwa nach einer Nachbesserung – ersetzt es diese Abschnitte und bewahrt alles andere, was Sie oder Ihre Rezensenten geschrieben haben, exakt so auf. Falls die lange Historie nicht passt, werden zuerst die ältesten Entscheidungen entfernt; der Abschnitt gibt dann an, dass weitere Details in Coroid zu finden sind.

Ein Release-Pull-Request listet jeweils die gebündelten pull request-Elemente auf: was sie liefern, wer sie angefordert hat und wer die Freigaben erteilt hat – in der Reihenfolge des Merge-Vorgangs.

In Commits#

Jeder Commit, den Coroid erstellt, endet mit Trailern, die das zugehörige Arbeitspaket benennen:

Coroid-Task: 3f6e2b1c-7d4a-4c1e-9b2f-0a8d5e6c7b91
Coroid-Plan: 8a41b7c3-25d0-4f6b-a1e9-6c3d2b7f4e05
Coroid-Requested-By: Maya Lindqvist
Coroid-Origin: prepare_work

Je nach Art der Arbeit nennt ein Commit auch ihre Plan-Aufgabe, ihr Arbeitspaket, den Agenten-Lauf, den Patch oder den Release. Der Trailer des Anforderers enthält einen Namen – niemals eine E-Mail-Adresse.

Coroid ist der Committer jedes von ihm erstellten Commits. Wenn ein Commit mit dem Konto einer Person erstellt wird, fügt Coroid sich ebenfalls als Mitautor hinzu.

Co-authored-by: Coroid <ai@coroid.ai>

Coroid führt außerdem seine eigene Zuordnung von jedem Commit zu seiner Aufgabe oder seinem Plan. Wenn ein von Coroid geöffneter Pull-Request in GitHub oder GitLab gemergt wird, protokolliert Coroid den Merge- oder Squash-Commit, damit ein Squash-Merge den Link nicht verliert.

Für Agenten#

Die Arbeitsanweisung jedes Agents für eine Aufgabe fasst deren Provenienz zusammen: Warum die Arbeit überhaupt existiert, wer sie angefordert hat, wer sie verantwortet und welche Entscheidungen getroffen wurden. Wenn ein Agent weitere Informationen benötigt, kann er den vollständigen Datensatz Abschnitt für Abschnitt einsehen.

Die Spezifikation bleibt weiterhin maßgebend. Stimmen Provenienz und Spezifikation nicht überein, folgt ein Agent der Spezifikation und benennt den Konflikt in seinem Bericht – statt stillschweigend zu entscheiden. Nachrichten und Begründungen, die von Menschen stammen, durchlaufen vor dem Lesen durch einen Agenten den Prompt-Injection-Filter von Coroid; der gefilterte Text wird nicht weitergegeben.

Was niemals an Ihren Git-Host gesendet wird#

Chat-Verläufe werden niemals in einen pull request oder einen Commit geschrieben. Ein Pull-Request enthält Namen, Rollen, Entscheidungen, Begründungen und Links. Die Diskussion wird lediglich als Anzahl der Nachrichten und die beteiligten Personen angezeigt – mit einem Link zum Chat in Coroid. E-Mail-Adressen werden nie verwendet; Personen werden stets mit ihrem Namen genannt.

Nur Links#

Standardmäßig enthält der Provenienz-Abschnitt eines pull request den Absatz zum Zweck, die wichtigsten Entscheidungen und die von den Personen genannten Begründungen. Eine Organisation kann sich jedoch für „nur Links“ entscheiden. In diesem Fall enthält der Abschnitt wer die Arbeit angefordert hat, wer der Inhaber ist, wer die Freigaben erteilt hat, die Entscheidungen sowie die Links zu Coroid – der Absatz zum Zweck, die wichtigsten Entscheidungen und alle Begründungen werden weggelassen.

Wählen Sie „nur Links“ aus, wenn Personen, die Ihre Produktbegründungen nicht einsehen sollen, Ihr Repository betrachten können – etwa bei öffentlichen Repositories. Die Einstellung gilt für Pull-Requests, die Coroid nach der Auswahl öffnet oder aktualisiert. Es gibt bisher noch keine Einstellungsoberfläche dafür. Kontaktieren Sie uns um Ihre Organisation auf „nur Links“ umzustellen.

Entscheidungen und ihre Begründungen#

Coroid protokolliert, wer welche Entscheidung während des Arbeitsablaufs trifft: Freigaben zum Zweck, zur Spezifikation und zum Plan, Qualifikation, manuelles Starten, Stoppen, Neuversuchen und Abschließen der Arbeit, Merges und Force-Merges, Gate-Übersteigungen, Release-Freigaben, Änderungen bezüglich des Inhabers oder der Teilnehmer einer Unterhaltung sowie die Urteile der QA- und Rezensionsagenten sowie des Koordinators.

Wenn Sie einen Plan freigeben und starten, eine Aufgabe stoppen oder erneut versuchen, fragt die Bestätigung optional nach einer Begründung von bis zu 2.000 Zeichen. Diese wird mit Ihrem Namen in der Provenienz der Arbeit gespeichert und in Pull-Requests angezeigt – sofern Ihre Organisation nicht „nur Links“ verwendet. Ein Satz genügt: „Kunden haben dies vor der Frühjahrskampagne angefordert“ vermittelt dem nächsten Leser mehr als die bloße Freigabe. Ein Force-Merge erfordert bereits eine schriftliche Begründung – diese wird auf dieselbe Weise protokolliert.

Automatische Entscheidungen#

Einige Entscheidungen werden im Namen einer Person festgehalten, ohne dass sie von ihr getroffen wurden. Der Liefervertrag einer Plan-Aufgabe wird automatisch aus dem genehmigten Plan übernommen; bei einem Plan ohne zugewiesene Person tritt dessen Ersteller an deren Stelle. Das Zeitstrahl-Label bezeichnet diese Entscheidungen als „Automatisch“ – sie zählen niemals als Genehmigung einer Person.

Von Agenten getroffene Entscheidungen – wie Urteile von QA und Rezension sowie Entscheidungen des Koordinators – erscheinen unter dem Namen des jeweiligen Agenten mit der von ihm gegebenen Zusammenfassung.

Kontext zu einer laufenden Aufgabe hinzufügen#

Während eine Aufgabe läuft, können Sie den Agenten Informationen mitteilen, ohne sie zu unterbrechen. Öffnen Sie den Reiter „Aktivität“ der Aufgabe und wählen Sie neben der laufenden Aktivität „Kontext hinzufügen“ aus. Geben Sie ein, was die Agenten wissen sollen – bis zu 2.000 Zeichen – und bestätigen Sie anschließend.

• Sobald ein Agent aktiv ist, liest er Ihre Nachricht beim nächsten Schritt. Ein Koordinator, der auf einen anderen Agenten wartet, wird dadurch geweckt und liest die Nachricht.
• Falls kein Agent gerade läuft, liest der nächste zu startende Agent die Nachricht.

Die Nachricht wird in der Provenienz der Aufgabe als Entscheidung „Kontext hinzugefügt“ mit Ihrem Namen festgehalten. Sie ändert nicht das, was die Aufgabe liefern muss: Falls Ihre Nachricht den Spezifikationen widerspricht, meldet der Agent den Konflikt statt schweigend zu handeln. Um das Ergebnis zu ändern, passen Sie die Spezifikationen an oder senden Sie die Aufgabe zur Nachbesserung zurück.

Zum Hinzufügen von Kontext benötigen Sie Schreibrechte für das Projekt der Aufgabe. Bei abgeschlossenen und abgebrochenen Aufgaben steht diese Funktion nicht zur Verfügung.

Code bis zu seiner zugrundeliegenden Arbeit zurückverfolgen#

Sie können bei einer Codezeile beginnen und die Arbeit finden, die sie erzeugt hat. Das Portal, die Agenten, MCP-Clients und Git führen Sie dabei alle zum Ziel.

Warum ist das hier?#

In der Code-Rezension einer Aufgabe weist jeder Abschnitt, der bestehende Zeilen bearbeitet, diesen Button auf. Er sucht die Commits heraus, die diese Zeilen zuletzt auf dem Zielzweig geändert haben, und zeigt an, woher jede Änderung stammt:

• Erstellt von Coroid: die Aufgabe oder der Plan mit seinem Zweck, dem Anforderer und Genehmiger, den wichtigsten Entscheidungen sowie einem Link zur vollständigen Provenienz.
• Außerhalb von Coroid erstellt: Es gibt keine Aufgabe oder Plan, die den Grund für die Änderung dokumentiert; daher sehen Sie nur den Autor und das Datum.

Eine Datei, die durch die Änderung hinzugefügt wird, enthält keine früheren Zeilen und hat daher keinen Button.

Mit einem Agenten oder MCP-Client#

Agents sowie MCP-Clients stellen mit einem Tool dieselbe Anfrage. Das Tool benötigt eine Datei – optional auch einen Zeilenbereich sowie einen Branch, Tag oder Commit. Es gibt anschließend jeden Zeilenbereich samt dem Commit zurück, der ihn zuletzt geändert hat. Für einen von Coroid erstellten Commit liefert das Tool zudem die zugrundeliegende Aufgabe oder den Plan sowie eine Zusammenfassung seiner Provenienz. Das Tool heißt explain_code.

• Agenten: Die Developer-, Reviewer- und Koordinator-Agenten von Coroid nutzen dieses Tool, bevor sie Code ändern oder löschen, dessen Zweck unklar ist.
• MCP-Clients: Es handelt sich um ein Lese-Tool; daher benötigen Sie die Rolle „Reviewer“ und diesen Umfang: mcp.read. Es funktioniert nur in den Projekten, auf die die Verbindung zugreifen kann, und erlaubt 30 Aufrufe pro Minute.

Mit Git#

Jeder Commit, den Coroid erstellt, benennt seine zugrundeliegende Arbeit in seinen Trailern; daher führt Sie Git ebenfalls dorthin:

git blame -L 120,120 src/search/alerts.ts   # the commit that last changed line 120
git log -1 <sha>                            # its Coroid-Task or Coroid-Plan trailer

Öffnen Sie anschließend diese Aufgabe oder diesen Plan im Portal, um ihre Provenienz zu lesen:

• Aufgabe: https://client.coroid.ai/factory/task:<task id>?panel=provenance
• Plan: https://client.coroid.ai/factory/<plan id>#provenance

Bei einem Merge- oder Squash-Commit öffnen Sie den pull request, aus dem er stammt. Sein Provenienz-Abschnitt verlinkt zurück zu Coroid.

Provenienz exportieren#

Im Panel befinden sich oben zwei Download-Buttons. Markdown lädt die Provenienz als dokument mit vorangestellter Zusammenfassung herunter. Es hat die gleiche Form wie der Abschnitt pull request, enthält die Gründe aber ohne Gesprächstexte. JSON lädt den vollständigen Datensatz einschließlich der Diskussionsauszüge für Ihre eigenen Unterlagen oder Tools herunter. Bewahren Sie die JSON-Datei genauso privat auf wie das Gespräch, das sie zitiert.

Ursprung nicht dokumentiert#

Coroid dokumentiert die Provenienz für Arbeit, die nach Einführung dieser Funktion entstanden ist. Ältere Arbeiten zeigen stattdessen diese Meldung anstelle eines Ursprungs an:

Ursprung nicht dokumentiert. Diese Arbeit wurde vor der Einführung der Provenienz-Dokumentation durch Coroid erstellt.

Wenn Coroid einen Quellcode aus früheren Aufzeichnungen kennt – etwa das Gespräch, aus dem ein Plan entstand, oder den zugrundeliegenden Bericht –, listet das Panel ihn als bekannten Quellcode auf. Entscheidungen, die bereits zuvor dokumentiert wurden – wie die Freigaben von Dokumenten – bleiben weiterhin sichtbar; andere können fehlen.

Ein mit „Abgeleitet“ gekennzeichneter Ursprung wurde aus früheren Aufzeichnungen rekonstruiert und nicht zum Zeitpunkt der Erstellung der Arbeit erfasst.

Verwandt#

• Aufgaben
• Pläne
• Ergebnis rezensieren und mergen
• Chat-Assistent
• Spezifikationen
• Coroid als MCP-Server