Active work

Eine Person mit Coding-Agenten führt mehrere Sitzungen gleichzeitig, und ein Team vervielfacht das. Die Agenten zweier Personen können dasselbe auf zwei Branches bauen, die keine Datei gemeinsam haben, sodass es kein Merge-Konflikt je zeigt. Active work macht aus den Pushes, die fremforge ohnehin empfängt, ein Bild der laufenden Arbeit und warnt, wenn sich zwei Arbeiten ähneln.

Kein Agent muss mitspielen. Active work liest, was die Forge bereits sieht: Branches, Pushes, Pull Requests und die Trailer, die Agenten ohnehin schreiben.

Was es erfasst

Wird ein Branch zum ersten Mal gepusht, legt fremforge ein Active-work-Element an und aktualisiert es bei jedem Push und jeder Änderung am Pull Request:

Ein Element ist aktiv, solange innerhalb von 7 Tagen darauf gepusht wird. Es ist erledigt, wenn sein Pull Request gemergt oder der Branch gelöscht wird, und aufgegeben, wenn der Pull Request ohne Merge geschlossen wird. Pushes auf den Standard-Branch sowie Branches, die fremforges eigene Bots oder Renovate pushen, werden nicht erfasst.

Wie Arbeit verglichen wird

Jedes Mal, wenn sich ein Element ändert, vergleicht fremforge es mit den anderen aktiven Elementen im selben Repository. Zwei Elemente werden als möglicherweise dieselbe Arbeit gemeldet, wenn ihre Titel die meisten ihrer bedeutungstragenden Wörter teilen (zum Beispiel „Rate limit the login endpoint“ und „Add rate limiting to the login API“) oder wenn sich ihr weiterer Text stark überschneidet und sie denselben Bereich berühren.

Der Vergleich ist ein Textabgleich in fremforges eigener Datenbank. Es wird kein KI-Modell verwendet, und weder Code noch Text verlassen fremforge, es sei denn, ein Owner der Organisation schaltet zusätzlich den semantischen Abgleich mit deinem eigenen Modell ein, der standardmäßig aus ist. Wörter, die jede Änderung verwendet („fix“, „update“, „add“), und Wörter, die in der eigenen Arbeit des Repositorys häufig sind, werden ignoriert, damit zwei Änderungen nicht nur deshalb zusammengeführt werden, weil beide dasselbe Produkt betreffen.

Über Repositorys hinweg

Arbeit wird auch mit aktiver Arbeit in den anderen Repositorys der Organisation verglichen, nur anhand von Titel und Absicht (ein Bereich wie apps/api in einem Repository sagt nichts über ein anderes). Es gelten dieselben Regeln für Paare, die keine Neuigkeit sind. Ein Treffer über Repositorys hinweg:

• wird nur Personen gezeigt, die beide Repositorys lesen können: auf der Seite Active work, in der Mail, auf der Antwortseite und in den Lese-Tools;
• bekommt nie einen Kommentar am Pull Request und wird nicht im Event-Feed gesendet, weil der Kommentar für jeden sichtbar ist, der eines der Repositorys lesen kann;
• nennt die andere Arbeit als org/repo#12 oder als org/repo:branch bei einem Branch ohne Pull Request.

Semantischer Abgleich mit deinem eigenen Modell

Der Textabgleich findet Arbeit, die dasselbe mit denselben Worten sagt. Der semantische Abgleich fragt außerdem den eigenen KI-Anbieter deiner Organisation, ob zwei laufende Arbeiten dieselbe Arbeit sind, wenn sich ihre Worte unterscheiden („SSO button on the sign-in page“ und „Log in with the company account“). Er ist optional und standardmäßig aus, und er ergänzt den Textabgleich immer nur:

• Er kann einen Treffer hinzufügen, den der Text nicht gefunden hat, oder den Wert eines gefundenen erhöhen. Er senkt oder entfernt nie einen Treffer;
• er vergleicht nur Arbeit im selben Repository, nie über Repositorys hinweg;
• schlägt ein Aufruf fehl, ist er langsam oder würde er deine Grenzen überschreiten, läuft der Abgleich einfach nur mit Text weiter.

Dein eigener Anbieter und sonst nichts

Der semantische Abgleich nutzt einen KI-Anbieter, den deine Organisation unter KI-Integrationen eingerichtet hat, mit deinem eigenen Schlüssel und deinem eigenen Vertrag mit diesem Anbieter. fremforge hat dafür keinen eigenen Schlüssel und keinen Rückfall: Ohne deinen Anbieter gibt es keinen semantischen Abgleich. Der Anbieter ist dein Auftragsverarbeiter, nicht der Unterauftragsverarbeiter von fremverk (AVV Anhang B §B.8).

Aufrufe verlassen fremforge nur über einen eingeschränkten ausgehenden Proxy und nur an den Host deines Anbieters, so wie er beim Speichern des Anbieters geprüft und festgepinnt wurde. Ändert sich die Adresse des Anbieters auf einen anderen Host, schaltet sich der semantische Abgleich selbst ab, bis ein Owner ihn wieder einschaltet, und das wird im Audit-Log erfasst.

Was gesendet wird

Wenn sich eine Arbeit oder die andere Arbeit, mit der sie verglichen wird, geändert hat (und höchstens alle 10 Minuten pro Arbeit), schickt fremforge deinem Anbieter für diese Arbeit und für höchstens 15 andere laufende Arbeiten im selben Repository:

Die anderen Arbeiten werden in der Anfrage als c1, c2, … bezeichnet, nie per ID oder Person.

Ein Feld mit Zugangsdaten darin wird weggelassen. Bevor etwas gesendet wird, wird jedes Feld mit den eigenen Regeln des Push-Schutzes gescannt: die Standardregeln von gitleaks für die Version, die fremforge betreibt, plus fremforges eigene (frem.sh-Tokens, EU-Cloud-Anbieter, Verbindungszeichenfolgen, Passwörter in Konfigurationen). Ein passendes Feld wird aus der Anfrage entfernt, nicht maskiert. Kann der Scan nicht laufen, wird gar nichts gesendet.

Was aufbewahrt wird

fremforge bewahrt weder die Anfrage noch die Antwort des Anbieters auf. Für jedes Paar von Arbeiten behält es nur, ob die Antwort als dieselbe Arbeit gewertet wurde, einen Konfidenzwert und einen Einweg-Hash der Anfrage, damit dieselbe Anfrage nicht zweimal gesendet wird. Diese werden mit der Arbeit und ihren Treffern gelöscht: 90 Tage nachdem die Arbeit beendet ist (ihr Pull Request gemergt oder geschlossen oder ihr Branch gelöscht) oder 30 Tage nachdem Active work für die Organisation abgeschaltet wurde. Jeder Aufruf wird erfasst wie der Aufruf jeder KI-Funktion (Funktion, Anbieter, Token-Zahlen, Latenz), nie sein Inhalt.

Erst Schattenmodus, dann Benachrichtigungen

Der semantische Abgleich beginnt im Schattenmodus: Urteile werden erfasst und gemessen, und niemand erfährt davon. Aus diesen Urteilen werden Schwellenwerte festgelegt, bevor Treffer, die er findet, angezeigt werden. Sobald er benachrichtigt, sagt ein Kommentar am Pull Request oder eine Mail über einen Treffer, den der semantische Abgleich gefunden oder bestätigt hat, das ausdrücklich und nennt den KI-Anbieter und das Modell, die geantwortet haben.

Grenzen

• Höchstens ein Aufruf pro Arbeit alle 10 Minuten, und nur, wenn sich geändert hat, was gesendet würde.
• Höchstens 30 Aufrufe pro Organisation in 10 Minuten und 500 am Tag, zusätzlich zum KI-Ausgabenlimit deiner Organisation.
• Fünf fehlgeschlagene Aufrufe in Folge pausieren den semantischen Abgleich für die Organisation 15 Minuten lang (Audit-Aktion active_work.semantic.paused).

Semantischen Abgleich einschalten

Ein Owner der Organisation schaltet ihn unter Organisationsverwaltung → KI-Integrationen → Active work: semantischer Abgleich ein. Der Schalter verweigert das, bis:

1. Active work für die Organisation eingeschaltet ist (Einschalten);
2. die Organisation einen eigenen KI-Anbieter hat;
3. dieser Anbieter einen geprüften, festgepinnten Host hat (speichere den Anbieter erneut, wenn er vor dem 26. Oktober 2026 hinzugefügt wurde und der Schalter das verlangt).

Das Ein- oder Ausschalten wird im Audit-Log als active_work.semantic.enabled oder active_work.semantic.disabled erfasst, mit der Person, dem Anbieter und dem festgepinnten Host. Diese Funktion testen wird für den semantischen Abgleich nicht angeboten: Er sendet immer nur den Text laufender Arbeit. Er wird nur in der Konsole eingeschaltet; die REST-API konfiguriert ihn nicht.

Markiere deine Verträge

Manche Dateien sind Zusagen, auf denen andere Arbeit aufbaut: eine API-Spezifikation, Datenbankmigrationen, gemeinsame Typen. Markiere sie in .fremforge/contracts auf dem Standard-Branch des Repositorys, ein Muster pro Zeile:

# API and schema contracts
apps/api/openapi.yaml
packages/db/migrations/**
proto/**/*.proto

* passt innerhalb eines Ordners, ** über Ordner hinweg, und eine Zeile, die mit / endet, deckt alles darunter ab. # beginnt einen Kommentar. Ohne die Datei wird nichts als Vertrag behandelt.

Ändert ein Merge in den Standard-Branch eine Vertragsdatei, bekommt jede aktive Arbeit im selben Bereich, die vor der Änderung begonnen hat, einen Abschnitt Contract changed in ihrem Active-work-Kommentar, der die Datei und den Merge nennt. what_changed_since und list_active_work zeigen das ebenfalls. Nichts wird blockiert: Es ist eine Erinnerung, zu rebasen und erneut zu prüfen. Die Angabe, wer die Änderung gemergt hat, wird 90 Tage aufbewahrt.

Echte Konflikte: ein Probe-Merge

Zwei Branches, die keine Idee teilen, können trotzdem in denselben Dateien kollidieren. Ändert sich eine Arbeit, führt fremforge in Forgejo einen Probe-Merge mit der anderen offenen Arbeit durch, die denselben Bereich berührt (oder nach derselben Arbeit aussieht), Head gegen Head. Der Probe-Merge schreibt nichts ins Repository und bewegt keinen Branch.

Kollidieren die beiden Heads, listet der Active-work-Kommentar beider Pull Requests die andere Arbeit und die kollidierenden Dateien auf, bevor einer von beiden gemergt wird. Wer als Zweites mergt, muss den Konflikt lösen; vereinbart also, wer zuerst geht, oder rebase jetzt auf die andere Arbeit. Bewegt sich eine Seite und lassen sich beide wieder sauber mergen, oder ist eine Seite fertig, verschwindet der Konflikt aus dem Kommentar. list_active_work liefert die offenen Konflikte ebenfalls (conflicts).

Jedes Paar wird einmal pro Paar von Heads gemergt, höchstens 10-mal pro Minute und Repository und nur bei Repositorys unter 2 GiB. Ist der Probe-Merge nicht verfügbar, gibt es einfach kein Konfliktsignal; nichts wird je blockiert.

Paare, die keine Neuigkeit sind

Manche Paare lesen sich wie dieselbe Arbeit, sind aber für niemanden neu. Sie erscheinen auf der Seite Active work mit einer Markierung, und niemand bekommt eine Mail oder eine Warnung am Pull Request:

Jedes andere Paar von zwei verschiedenen Personen wird gemeldet, auch wenn eine davon die Arbeit der anderen nennt: Das zeigt, dass einer von euch Bescheid weiß, nicht beide. Um ein Repository als Dokumentation zu kennzeichnen, ohne es umzubenennen, gib ihm in seinen Einstellungen eines dieser Topics.

Eine Mail zu einem Treffer geht etwa drei Minuten nach seiner Entdeckung raus, damit ein Trailer einer Agenten-Sitzung, der erst mit der Beschreibung des Pull Requests kommt, das Paar vorher noch als eigene Arbeit einer Sitzung kennzeichnen kann.

Erzeugt eine Änderung auf einmal mehrere neue Treffer für dich, bekommst du eine Mail, die sie alle auflistet, jeweils mit ihrem Link Antworten, nicht eine Mail pro Paar.

Der Kommentar am Pull Request

Wird ein Treffer gefunden, bekommt jeder beteiligte Pull Request einen Kommentar von fremforge-bot:

• Er listet die andere Arbeit: ihren Pull Request oder Branch, die Person, die gemeinsamen Wörter und Bereiche.
• Er wird an Ort und Stelle bearbeitet, wenn sich die Treffer ändern, und nie wiederholt. Wird die andere Arbeit gemergt oder geschlossen, sagt der Kommentar, dass es keine Überschneidung mehr gibt.
• Text aus der anderen Arbeit wird als reiner Code angezeigt, nie als Link oder Erwähnung, und ist als Daten gekennzeichnet. Ein Agent, der den Pull Request liest, liest ihn als Information, nicht als Anweisung.

Der Kommentar blockiert nie etwas. Ist es dieselbe Arbeit, vereinbart mit der anderen Person, wer weitermacht.

Mail an beide Personen

Beide Personen bekommen pro Treffer eine Mail in ihrer Sprache, mit der anderen Arbeit, der Person und den gemeinsamen Wörtern und Bereichen sowie einem Link zum anderen Pull Request oder Branch. Sind beide Seiten zwei deiner eigenen Sitzungen, bekommst du eine Mail, die das sagt. Jede Person kann Active-work-Mails in ihren Benachrichtigungseinstellungen abschalten; ein Owner der Organisation kann Mails für die ganze Organisation abschalten (email_notify). Wer in Forgejo die Mail-Einstellung „disabled“ hat, bekommt keine Mail.

Einen Treffer beantworten

Jede der beiden Personen kann sagen, was ein Treffer ist:

Antworte dort, wo du dem Treffer begegnest:

• Am Pull Request: Der Link Antworten im Kommentar öffnet die Antwortseite (Anmeldung nötig).
• In der Mail: dieselbe Seite, über Hier antworten. Das Öffnen des Links ändert nichts; erst das Speichern des Formulars erfasst eine Antwort.
• Auf der Seite Active work: der Link Antworten neben einem möglichen Duplikat, für die beiden Personen des Paars.
• Über die API: POST /_app/api/v1/orgs/<org>/repos/<repo>/active-work/matches/<id>/response mit {"response": "split", "continued_by": "<login>"} (findings:write, Lesezugriff auf das Repository). GET …/matches/<id> liest einen Treffer und seine Antwort, und list_active_work liefert match_id, response und continued_by für jeden offenen Treffer.

Nur die beiden Personen, deren Arbeit es ist, können antworten, nie jemand in ihrem Auftrag: Ein Token, das für niemanden handelt, bekommt no-principal, alle anderen not-a-party. Eine Antwort lässt sich ändern; die letzte zählt. Jede Antwort wird im Audit-Log als active_work.match.responded erfasst, mit der vorherigen Antwort und dem Ort, an dem sie gegeben wurde. Ein Agent kann für seine Person über die API antworten oder über das MCP-Schreib-Tool answer_active_work_match, sobald die Person ihm zugestimmt hat und die Organisation Schreibzugriffe von Verbindungen erlaubt. Die Antwort liefert previous_response, die Antwort, die sie ersetzt hat.

Übergabenotizen

Arbeit wechselt die Hände: Eine andere Person pusht auf den Branch, öffnet den Pull Request dafür, oder die Arbeit hört einfach auf. Active work bemerkt beides und behält bei der Arbeit, was die erste Person oder ihr Agent wusste.

Wann fremforge eine Übergabe bemerkt:

• Hände gewechselt. Ein Push von jemand anderem als der Person, die zuletzt gepusht hat, oder ein Pull Request, den jemand anderes als die Person öffnet, die zuletzt gepusht hat. Mehrere Sitzungen einer Person sind keine Übergabe.
• Ruhend. Ein offener Pull Request ohne Push seit 7 Tagen (einmal täglich geprüft). Pro Ruhephase wird einmal nachgefragt; der nächste Push macht aus dem Kommentar „Arbeit wieder aufgenommen“.

Der Pull Request bekommt dann einen Übergabekommentar von fremforge-bot, an Ort und Stelle bearbeitet, nie wiederholt:

• wer an wen übergeben hat oder seit wann die Arbeit ruht;
• Done: die Übergabenotiz, falls eine geschrieben wurde, sonst die Betreffzeilen der Commits;
• Next und Open questions aus der Notiz (oder einer Zeile Handoff:);
• die Links zu Agenten-Sitzungen an der Arbeit. Ein Link https://claude.ai/code/session_… wird als Link angezeigt; er öffnet sich nur für die Person, deren Sitzung es ist, damit sie sie dort fortsetzen kann. Alle anderen arbeiten mit den Notizen.

Alles im Kommentar wird als reiner Code angezeigt und als Daten gekennzeichnet, wie beim Überschneidungskommentar oben. Er folgt der Einstellung pr_comment der Organisation.

Schreib die Notiz als Abschnitt Handoff in die Beschreibung des Pull Requests (oder in eine Commit-Nachricht). Diesen Block fügst du deiner Vorlage für Pull Requests (.forgejo/PULL_REQUEST_TEMPLATE.md) hinzu:

## Handoff
Done:
- 
Next:
- 
Open questions:
- 

Die neueste Notiz gewinnt: Eine Änderung der Beschreibung ersetzt sie, und eine Commit-Nachricht mit einem Abschnitt Handoff ersetzt sie ebenfalls. Eine leere Vorlage ist keine Notiz. Die Notiz wird nicht als Absicht verglichen; eine Notiz zu schreiben löst also nie eine Überschneidungswarnung aus. list_active_work und find_related_work liefern sie unter written.handoff (done, next, open_questions, wer sie wo geschrieben hat) und die Übergabe selbst als handoff (changed_hands oder idle, from, to, at, resumed).

Eine Zeile für deine AGENTS.md oder CLAUDE.md:

When you stop working on a pull request, or hand it to someone else, add or update the "## Handoff" section of its description: Done, Next, Open questions. When you continue someone else's pull request, read written.handoff from list_active_work first.

Live im Event-Feed

Jeder neue Treffer ist auch ein Ereignis activework.warning im Event-Feed, sodass ein Agent, der dem Feed bereits folgt, ohne Polling davon erfährt.

Ruhende Arbeit: eine tägliche Erinnerung

Agenten-Sitzungen enden und hinterlassen Branches und Pull-Request-Entwürfe. Einmal am Tag schickt fremforge jeder Person eine Mail mit ihren offenen Pull Requests und Branches ohne Push seit 14 Tagen, einschließlich der Arbeit, die ihre Agenten für sie erledigt haben. Für jede Arbeit gibt es drei Antworten:

Jedes Element in der Mail verlinkt auf seine Antwortseite (/_app/settings/work/idle/<id>). Du musst angemeldet sein: Nur die Person, der die Arbeit gehört, oder ein Owner der Organisation kann sie sehen oder beantworten; eine weitergeleitete Mail kann also niemandes Arbeit schließen. Das Öffnen des Links ändert nichts. Owner der Organisation finden außerdem neben ruhender Arbeit auf der Seite Active work einen Link Weitermachen, übergeben oder schließen. Jede Antwort steht im Audit-Log als active_work.idle.continue, active_work.idle.handover oder active_work.idle.close, mit der Person, die sie gegeben hat.

Wie selten die Mail ist:

• höchstens eine Mail pro Person und Tag, nie eine pro Pull Request;
• jede Arbeit wird nach 14 Tagen ohne Push erinnert, ein weiteres Mal 14 Tage später, wenn niemand geantwortet hat, und dann erst wieder, wenn jemand darauf pusht;
• ein Pull Request, der auf einen angefragten Reviewer wartet, wird ausgelassen: Der nächste Schritt liegt nicht bei dir;
• Bots (Renovate und andere Bot-Konten) werden nie erinnert.

Arbeit, die schon existierte, bevor deine Organisation Active work eingeschaltet hat, wird beim ersten täglichen Lauf ebenfalls erfasst.

Die Person kann die Mail unter Erinnerungen an ruhende Arbeit in ihren Benachrichtigungseinstellungen abschalten oder über den Abmeldelink mit einem Klick in der Mail. Jedes Element eines Digests ist außerdem ein Ereignis work.idle im Event-Feed, damit die eigenen Agenten der Person es sehen können.

Ruhende Pull Requests automatisch schließen

Ein Owner der Organisation kann auto_close einschalten. Das ist standardmäßig aus. Ein Pull Request wird dann automatisch geschlossen, wenn all dies zutrifft:

• kein Push seit auto_close_days (mindestens 60, Standard 90);
• eine Erinnerung dazu blieb mindestens eine Woche unbeantwortet;
• er hat keine Freigabe, keinen angefragten Reviewer und kein Review, das Änderungen verlangt.

Der Branch bleibt erhalten, sodass jeder den Pull Request wieder öffnen kann. Die Person erfährt es im Digest dieses Tages, und der Pull Request bekommt einen Kommentar mit dem Grund. Branches ohne Pull Request werden nie automatisch gelöscht.

Die Seite Active work

Owner der Organisation sehen alle laufende Arbeit unter Build und Deployment › Active work: eine Karte pro Repository, Arbeit nach Bereich gruppiert, die Agenten-Sitzungen jeder Person und jedes mögliche Duplikat benannt und verlinkt, mit seiner Antwort. Der Schalter für die Organisation liegt auf derselben Seite.

Wer gerade arbeitet (Präsenz)

Arbeit erscheint hier beim ersten Push. Präsenz zeigt sie früher: Arbeitet der KI-Assistent einer Person über den MCP-Server in einem Repository (liest dort Dateien, Pull Requests oder Active work), sehen Personen, die dieses Repository lesen können, dass die Person gerade dort arbeitet.

• Was angezeigt wird: nur Logins. „Arbeitet gerade hier: alice, bob“ auf der Karte des Repositorys, eine Karte für Repositorys, in denen jemand arbeitet und noch nichts gepusht ist, und working_now in list_active_work.
• Was aufbewahrt wird: ein Eintrag pro Person und Repository, von jedem Aufruf überschrieben und 60 Minuten nach dem letzten Aufruf der Person verschwunden. Kein Verlauf, keine Zählungen, und es werden keine Zeiten angezeigt. Präsenz ist kein Maß für die Aktivität von irgendwem.
• Nur ein erfolgreicher Aufruf zählt: Ein Repository zu nennen, das die Person nicht lesen kann, erfasst nichts, und ein API-Token, das für keine Person handelt, zählt nie.
• Wer es sieht: Personen, die das Repository lesen können: die Owner und Auditoren der Organisation auf der Seite Active work und jeder mit Lesezugriff über list_active_work.
• Abschalten: ein Owner der Organisation mit der Einstellung Zeigen, wer gerade in einem Repository arbeitet auf dieser Seite (oder presence: false in der Einstellungs-API); jede Person für sich selbst mit Zeigen, dass ich arbeite in ihren Benachrichtigungseinstellungen. Beides löscht die Präsenz sofort.

Status: für jede Organisation verfügbar. Eine Organisation, in der Active work ausgeschaltet ist (die Voreinstellung), erfasst und zeigt keine Anwesenheit.

Ein Pull-Request-Entwurf beim ersten Push

Arbeit wird ab ihrem ersten Push verglichen, aber ein Branch ohne Pull Request wird leicht übersehen. Ist Pull-Request-Entwurf beim ersten Push eingeschaltet und pusht jemand einen neuen Branch, öffnet fremforge sofort einen Entwurf eines Pull Requests dafür, als diese Person: Die Arbeit ist auf der Forge, auf der Seite Active work und für die Agenten aller sichtbar, bevor jemand anderes dasselbe beginnt.

• Standardmäßig eingeschaltet für Organisationen, die am oder nach dem 12. November 2026 angelegt werden, aus für ältere. Ein Owner der Organisation schaltet es unter Build und Deployment › Active work ein oder aus (oder auto_draft_pr in der Einstellungs-API). Jede Person kann es trotzdem für sich selbst unter Pull-Request-Entwurf bei meinem ersten Push in ihren Benachrichtigungseinstellungen abschalten.
• Der Pull Request gehört der Person. Er wird in ihrem Namen geöffnet, mit einem Titel WIP:, der Betreffzeile des ersten Commits und einer kurzen Beschreibung, die sagt, wie man das abschaltet. Er bleibt ein Entwurf und kann daher nicht gemergt werden, bis sie WIP: entfernt und ihn als bereit markiert. Für sie wird nie etwas gemergt oder auf Auto-Merge gesetzt.
• Seine CI wartet, bis er bereit ist. Solange der Titel mit WIP: beginnt, laufen die pull_request-Workflows des Entwurfs nicht; ein Entwurf kostet also keine Runner-Minuten. Markiert die Person ihn als bereit (entfernt WIP: in der Weboberfläche, durch Bearbeiten des Titels oder über die API), laufen die Prüfungen für den aktuellen Head-Commit, sodass die Pflichtprüfungen immer existieren, bevor er gemergt werden kann. Um sie früher laufen zu lassen, drückt jemand mit Schreibzugriff am Pull Request auf Run checks (oder ruft POST /api/v1/repos/{owner}/{repo}/pulls/{index}/fremforge/run-checks auf): einmal pro Head-Commit, und eine zweite Anfrage für denselben Commit antwortet mit 409. Push-Workflows und fremforges eigene Scans von Pull Requests (Secrets, Lizenzen, Sicherheit) laufen wie gewohnt. Betroffen sind nur die Entwürfe, die fremforge öffnet: Forgejo hält das fest, wenn der Entwurf über das eine Plattformkonto geöffnet wird, das sie öffnen kann, und nichts, was in einem Titel oder einer Beschreibung steht, kann einen solchen Entwurf erzeugen oder aufheben. Ein Pull Request, den du selbst mit WIP: markierst, führt die CI wie bisher aus, ebenso jeder Pull Request aus einem Fork. Laufen die Prüfungen bei „bereit“ oder Run checks, laufen sie als die Person, der der Entwurf gehört; Freigaberegeln gelten also für diese Person, nicht für die, die den Knopf gedrückt hat.
• Nur ihr eigener neuer Branch, einmal. Ein Push auf einen bestehenden Branch, ein Branch, der schon einen Pull Request hat, Bots, Deploy-Keys und Forgejo Actions bekommen nie einen. Höchstens 10 pro Minute und Organisation auf jeder API-Instanz.
• Wie es gemacht wird und was es begrenzt. fremforge öffnet den Pull Request über Forgejos Sudo-Mechanismus mit einem eigenen Plattformkonto, dessen Token sonst nichts kann: Der Scope write:fremforge-draft-pr erlaubt ihm, aus einem Branch desselben Repositorys einen Work-in-Progress-Entwurf zu öffnen, als aktive Person mit Schreibzugriff, und jede andere Anfrage damit weist Forgejo selbst ab. Jeder Entwurf wird im Audit-Log als active_work.draft_pr.opened erfasst, mit der Person als Akteur.

Vor dem Start fragen: Tools für Agenten

Agenten machen Active work besser, sind aber nie Voraussetzung. Eine Zeile Handoff: in einer Commit-Nachricht oder der Beschreibung eines Pull Requests wird bei der Arbeit als Notiz für die nächste Person oder Sitzung aufbewahrt (siehe Übergabenotizen). Drei Lese-Tools, verfügbar im fremforge-MCP-Server und als REST-Endpunkte, lassen einen Agenten vor dem Start prüfen:

list_active_work liefert außerdem working_now: die Logins der Personen, die gerade im Repository arbeiten (siehe Präsenz).

Alle drei brauchen findings:read und Lesezugriff auf das Repository. Text, den Personen und Agenten geschrieben haben (Titel, Branch-Namen, Absicht, Betreffzeilen von Commits, Sitzungsdetails, Übergabenotizen), wird nur innerhalb eines Objekts written geliefert, mit written_by und at daneben, und jede Antwort trägt einen Hinweis, dass es sich um Daten handelt, nie um Anweisungen.

Melde sie an, bevor du pushst. In der Konsole fragt Build und Deployment › Active work › Arbeit beginnen (oder /_app/settings/active-work/start) nach dem Repository, einem Titel und optional nach Absicht, Bereichen und Branch und zeigt dann den anzulegenden Branch und jede Arbeit, die verwandt aussieht. Mit der CLI:

fremforge work start acme/web --title="Rate limit the login endpoint" --areas=apps/api
fremforge work list acme/web --area=apps/api

Nichts wird reserviert und nichts blockiert: Arbeit anzumelden macht sie nur früher sichtbar. Von einem Agenten aus erfasst start_work (POST /_app/api/v1/orgs/<org>/repos/<repo>/active-work/start, findings:write und Schreibzugriff auf das Repository) deine Arbeit, bevor etwas gepusht ist: einen title, deine intent und optional die areas und den branch. Ohne Branch schlägt es einen vor, etwa alice/rate-limit-the-login-api. Die Arbeit wird sofort verglichen; wer schon an derselben Sache ist, erfährt es also gemäß den Einstellungen der Organisation, und die Antwort listet die verwandte Arbeit. Pushe auf den Branch, den es nennt: Der erste Push aktualisiert dasselbe Element. Laufende Arbeit einer anderen Person auf diesem Branch wird abgewiesen (409). Über MCP ist start_work ein Schreib-Tool: Deine Verbindung braucht dafür deine Zustimmung, und die Organisation muss Schreibzugriffe von Verbindungen erlauben.

Eine Zeile für deine AGENTS.md oder CLAUDE.md:

Before starting work in a repository, call find_related_work with a one-sentence description and the paths you expect to change. If an item has likely_same_work, stop and tell the person before building.
At each push, call what_changed_since for your branch with the cursor from the last call. If a migration or shared contract you depend on changed, rebase and re-check before building further.

Wer es sehen kann

Der Kommentar am Pull Request nennt nur Arbeit im selben Repository und zeigt andere Arbeit also nur Personen, die dieses Repository ohnehin lesen können. Ein Treffer über Repositorys hinweg wird nur Personen gezeigt, die beide lesen können. Private Repositorys bleiben innerhalb der Organisation privat.

Einschalten

Owner der Organisation schalten Active work für die Organisation über die API ein:

curl -X PUT https://frem.sh/_app/api/v1/orgs/<org>/active-work/settings \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"enabled": true}'

Lesen der Einstellungen braucht policy:read, Ändern policy:write. Jede Änderung wird im Audit-Log als active_work.settings.updated erfasst, mit der Person, die sie vorgenommen hat.

Deine eigenen Schalter

Jede Person hat drei eigene Schalter, in ihren Benachrichtigungseinstellungen oder über die API:

curl https://frem.sh/_app/api/v1/users/me/settings/active-work \
  -H "Authorization: Bearer $FREMFORGE_TOKEN"

curl -X PUT https://frem.sh/_app/api/v1/users/me/settings/active-work \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"presence": false, "orgs": {"acme": {"mail": false}}}'

Diese Einstellungen sind persönlich und brauchen daher Zugangsdaten, die deine Identität tragen: das Token aus fremforge auth login, deine Bench oder eine KI-Verbindung (nur lesend, als Tool get_my_settings). Ein API-Token der Organisation wird mit user-identity-required abgewiesen. Lesen braucht orgs:read, Ändern orgs:write. Nur Organisationen, in denen du jetzt Mitglied bist, werden aufgeführt oder lassen sich ändern (Namen werden ohne Rücksicht auf Groß-/Kleinschreibung abgeglichen), und eine KI-Verbindung sieht keine Organisationen, deren Owner KI-Verbindungen gesperrt haben. Jede Änderung wird im Audit-Log dieser Organisation als notifications.preference.self_updated erfasst, mit dir als Akteur.

Alle Einstellungen auf einmal lesen

GET /_app/api/v1/orgs/<org>/settings (orgs:read), auch als lesendes MCP-Tool get_org_settings, liefert die Einstellungen der Organisation zur Ablaufsteuerung und zu KI in einer Antwort. Was es zeigt, hängt davon ab, wer fragt:

• Mitglieder sehen, was für ihre eigene Arbeit gilt: die Schalter von Active work, welche Branches Merges anhalten (nur in Repositorys, die sie lesen können) und ob KI-Verbindungen lesen oder handeln dürfen.
• Owner und Auditoren sehen außerdem die Einstellungen zu Release-Trains, Risikostufen und außer Kontrolle geratener CI, die vollständigen Einstellungen von Active work und jede KI-Funktion mit ihrem Modell sowie Name und Hersteller des Anbieters.

Es liefert nie einen Schlüssel eines Anbieters, einen Fingerabdruck eines Schlüssels, eine Endpunktadresse, eine Prompt-Ergänzung oder ein Token. Es gibt keine schreibende Variante, weder über die API noch in MCP.

Messen

GET /_app/api/v1/orgs/<org>/active-work/metrics?days=30 (policy:read) liefert nur Zählungen und Dauern, nie den Text der Arbeit von irgendwem:

• matches und matches_both_notified;
• notify_seconds_p50 und notify_seconds_p90: die Zeit vom ersten Push der zweiten Person, bis beiden Personen der Treffer angezeigt wurde (das Ziel liegt unter 5 Minuten);
• false_positive_rate: der Anteil der beantworteten Treffer, die als „different“ markiert wurden;
• dismissed_share_of_notified: Treffer, die mit „different“ beantwortet wurden, von allen Treffern, die beiden Personen gezeigt wurden, beantwortet oder nicht (das Ziel liegt unter 30 %), sowie response_rate;
• responses_by_kind und responses_by_via (api, page, pr_comment, mail).

Die Seite Active work zeigt dasselbe Maß für die letzten 30 Tage.

Die vollständigen Schemas findest du in der API-Referenz.