Pågående arbete

En person med kodagenter kör flera sessioner samtidigt, och ett team mångdubblar det. Två personers agenter kan bygga samma sak på två brancher som inte delar någon fil, så ingen merge-konflikt avslöjar det någonsin. Active work gör om de pushar som fremforge redan tar emot till en bild av det pågående arbetet och varnar när två arbeten liknar varandra.

Ingen agent behöver samarbeta. Active work läser det som forgen redan ser: brancher, pushar, pull requests och de trailers som agenterna redan skriver.

Vad som registreras

När en branch pushas första gången skapar fremforge ett pågående arbete och uppdaterar det vid varje push och varje ändring i pull requesten:

Ett arbete är pågående så länge det pushas till inom 7 dagar. Det är klart när dess pull request mergas eller branchen tas bort, och övergivet när pull requesten stängs utan merge. Pushar till standardbranchen, och brancher som pushas av fremforges egna botar eller Renovate, registreras inte.

Hur arbeten jämförs

Varje gång ett arbete ändras jämför fremforge det med de andra pågående arbetena i samma repository. Två arbeten rapporteras som möjligen samma arbete när deras titlar delar de flesta av sina betydelsebärande ord (till exempel “Rate limit the login endpoint” och “Add rate limiting to the login API”), eller när den bredare texten överlappar kraftigt och de rör samma område.

Jämförelsen är textmatchning i fremforges egen databas. Ingen AI-modell används, och ingen kod eller text lämnar fremforge, om inte en ägare i organisationen också slår på semantisk matchning med din egen modell, som är avslagen som standard. Ord som alla ändringar använder (“fix”, “update”, “add”) och ord som är vanliga i repots eget arbete ignoreras, så två ändringar matchas inte bara för att de båda handlar om samma produkt.

Mellan repon

Arbeten jämförs också med pågående arbete i organisationens övriga repon, men bara utifrån titel och avsikt (ett område som apps/api i ett repo säger ingenting om ett annat). Samma regler för par som inte är nyheter gäller. En matchning mellan repon:

• visas bara för personer som kan läsa båda repona: på sidan Active work, i mejlet, på svarssidan och i läsverktygen;
• får aldrig någon kommentar på en pull request och skickas inte på händelseflödet, eftersom kommentaren syns för alla som kan läsa ett av repona;
• namnger det andra arbetet som org/repo#12, eller org/repo:branch för en branch utan pull request.

Semantisk matchning med din egen modell

Textmatchning hittar arbeten som säger samma sak med samma ord. Semantisk matchning frågar dessutom organisationens egen AI-leverantör om två pågående arbeten är samma arbete när orden skiljer sig åt (“SSO button on the sign-in page” och “Log in with the company account”). Den är valfri och avslagen som standard, och den lägger bara till saker utöver textmatchningen:

• den kan lägga till en matchning som texten inte hittade, eller höja poängen för en som den hittade. Den sänker eller tar aldrig bort en matchning;
• den jämför bara arbeten i samma repository, aldrig mellan repon;
• om ett anrop misslyckas, är långsamt eller skulle överskrida dina gränser fortsätter matchningen helt enkelt med bara text.

Din egen leverantör och inget annat

Semantisk matchning använder en AI-leverantör som organisationen har konfigurerat under AI-integrationer, med din egen nyckel och ditt eget avtal med den leverantören. fremforge har ingen egen nyckel för det och ingen reservlösning: utan din leverantör finns ingen semantisk matchning. Leverantören är ditt personuppgiftsbiträde, inte fremverks underbiträde (DPA bilaga B §B.8).

Anropen lämnar fremforge bara via en begränsad utgående proxy, och bara till leverantörens värd så som den kontrollerades och låstes när du sparade leverantören. Om leverantörens adress ändras till en annan värd stänger semantisk matchning av sig själv tills en ägare slår på den igen, och det registreras i granskningsloggen.

Vad som skickas

När ett arbete, eller ett annat arbete som det jämförs med, har ändrats (och högst en gång var tionde minut per arbete), skickar fremforge följande till din leverantör, för det arbetet och för högst 15 andra pågående arbeten i samma repo:

De andra arbetena märks c1, c2, … i begäran, aldrig med id eller person.

Ett fält som innehåller en inloggningsuppgift utelämnas. Innan något skickas skannas varje fält med push-skyddets egna regler: gitleaks standardregler för den version som fremforge kör, plus fremforges egna (frem.sh-tokens, europeiska molnleverantörer, anslutningssträngar, lösenord i konfiguration). Ett fält som matchar tas bort ur begäran, det maskeras inte. Om skanningen inte kan köras skickas ingenting alls.

Vad som sparas

fremforge sparar varken begäran eller leverantörens svar. För varje par av arbeten sparas bara om svaret räknades som samma arbete och en konfidenspoäng, samt en envägshash av begäran så att samma begäran inte skickas två gånger. De tas bort tillsammans med arbetet och dess matchningar: 90 dagar efter att arbetet avslutades (pull requesten mergades eller stängdes, eller branchen togs bort), eller 30 dagar efter att Active work slogs av för organisationen. Varje anrop registreras som alla AI-funktioners anrop (funktion, leverantör, antal tokens, latens), aldrig dess innehåll.

Först skuggläge, sedan aviseringar

Semantisk matchning börjar i skuggläge: bedömningarna registreras och mäts, och ingen får veta något om dem. Tröskelvärdena sätts utifrån de bedömningarna innan matchningar som den hittar visas. När den väl aviserar står det i en kommentar på pull requesten eller ett mejl om en matchning som semantisk matchning hittade eller bekräftade, med namnet på den AI-leverantör och modell som svarade.

Gränser

• Högst ett anrop per arbete var tionde minut, och bara när det som skulle skickas har ändrats.
• Högst 30 anrop per organisation på 10 minuter och 500 per dag, utöver organisationens kostnadsgräns för AI.
• Fem misslyckade anrop i rad pausar semantisk matchning för organisationen i 15 minuter (granskningsåtgärden active_work.semantic.paused).

Slå på semantisk matchning

En ägare i organisationen slår på den under Organisationens administration → AI-integrationer → Active work: semantisk matchning. Reglaget vägrar tills:

1. Active work är påslaget för organisationen (Slå på det);
2. organisationen har en egen AI-leverantör;
3. den leverantören har en kontrollerad, låst värd (spara leverantören igen om den lades till före den 26 oktober 2026 och reglaget säger det).

Att slå på eller av den registreras i granskningsloggen som active_work.semantic.enabled eller active_work.semantic.disabled, med personen, leverantören och den låsta värden. Testa den här funktionen erbjuds inte för semantisk matchning: den skickar bara texten från pågående arbete. Den slås bara på i konsolen; REST-API:t konfigurerar den inte.

Markera dina kontrakt

Vissa filer är löften som annat arbete bygger på: en API-specifikation, databasmigreringar, delade typer. Markera dem i .fremforge/contracts på repots standardbranch, ett mönster per rad:

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

* matchar inom en mapp, ** över flera mappar, och en rad som slutar med / omfattar allt under den. # inleder en kommentar. Utan filen behandlas ingenting som ett kontrakt.

När en merge till standardbranchen ändrar en kontraktsfil får varje pågående arbete i samma område som började före ändringen ett avsnitt Contract changed i sin Active work-kommentar, med filen och mergen. what_changed_since och list_active_work visar det också. Ingenting blockeras: det är en påminnelse om att göra rebase och kontrollera igen. Uppgiften om vem som mergade ändringen sparas i 90 dagar.

Verkliga konflikter: en provmerge

Två brancher som inte delar någon idé kan ändå krocka i samma filer. När ett arbete ändras gör fremforge en provmerge av det mot det andra öppna arbetet som rör samma område (eller som ser ut att vara samma arbete), head mot head, inne i Forgejo. Provmergen skriver ingenting i repot och flyttar ingen branch.

När de två headsen är i konflikt listar båda pull requestarnas Active work-kommentar det andra arbetet och de filer som är i konflikt, innan någon av dem mergas. Den som mergar sist måste lösa konflikten, så kom överens om vem som går först, eller gör rebase på det andra arbetet nu. När den ena sidan flyttas och de två går att merga utan problem igen, eller när den ena sidan blir klar, försvinner konflikten från kommentaren. list_active_work returnerar också de öppna konflikterna (conflicts).

Varje par mergas en gång per par av heads, högst 10 gånger i minuten per repo, och bara för repon under 2 GiB. Om provmergen inte är tillgänglig finns det helt enkelt ingen konfliktsignal; ingenting blockeras någonsin.

Par som inte är nyheter

Vissa par ser ut som samma arbete men är inte nyheter för någon. De visas på sidan Active work med en etikett, och ingen får mejl eller varning på pull requesten:

Alla andra par mellan två olika personer rapporteras, även när den ena nämner den andras arbete: det visar att en av er vet, inte båda. Om du vill markera ett repo som dokumentation utan att byta namn på det ger du det ett av de ämnena under dess Settings.

En matchning mejlas ungefär tre minuter efter att den hittats, så att en trailer för agentsession som bara kommer med pull requestens beskrivning ändå hinner markera paret som en sessions eget arbete först.

När en ändring ger flera nya matchningar för dig på en gång får du ett mejl som listar dem, var och en med sin länk Svara, inte ett mejl per par.

Kommentaren på pull requesten

När en matchning hittas får varje inblandad pull request en kommentar från fremforge-bot:

• Den listar det andra arbetet: dess pull request eller branch, personen samt de ord och områden som de delar.
• Den redigeras på plats när matchningarna ändras och upprepas aldrig. När det andra arbetet mergas eller stängs säger kommentaren att det inte längre finns någon överlappning.
• Text från det andra arbetet visas som vanlig kod, aldrig som länkar eller omnämnanden, och märks som data. En agent som läser pull requesten läser det som information, inte som instruktioner.

Kommentaren blockerar aldrig något. Om arbetet är detsamma kommer du överens med den andra personen om vem som fortsätter.

Mejl till båda personerna

Båda personerna får ett mejl per matchning, på sitt språk, med det andra arbetet, personen samt de ord och områden som de delar, och en länk till den andra pull requesten eller branchen. När båda sidorna är två av dina egna sessioner får du ett mejl som säger det. Varje person kan slå av Active work-mejl i sina aviseringsinställningar; en ägare i organisationen kan slå av mejlen för hela organisationen (email_notify). Ingen vars mejlinställning i Forgejo är “disabled” får mejl.

Svara på en matchning

Var och en av de två personerna kan säga vad en matchning är:

Svara där du stöter på matchningen:

• På pull requesten: kommentarens länk Answer öppnar svarssidan (inloggning krävs).
• I mejlet: samma sida, via Answer here. Att öppna länken ändrar ingenting; bara när du sparar formuläret registreras ett svar.
• På sidan Active work: länken Svara bredvid en möjlig dubblett, för parets två personer.
• Med API:t: POST /_app/api/v1/orgs/<org>/repos/<repo>/active-work/matches/<id>/response med {"response": "split", "continued_by": "<login>"} (findings:write, läsåtkomst till repot). GET …/matches/<id> läser en matchning och dess svar, och list_active_work returnerar match_id, response och continued_by för varje öppen matchning.

Bara de två personer vars arbete det är kan svara, aldrig någon annan för deras räkning: en token som inte agerar för någon får no-principal, alla andra not-a-party. Ett svar kan ändras; det senaste gäller. Varje svar registreras i granskningsloggen som active_work.match.responded, med det tidigare svaret och var svaret gavs. En agent kan svara för sin person via API:t, eller via MCP-skrivverktyget answer_active_work_match när personen har gett sitt samtycke och organisationen tillåter skrivningar från connectorer. Svaret returnerar previous_response, det svar som det ersatte.

Överlämningsanteckningar

Arbete byter händer: en annan person pushar till branchen eller öppnar pull requesten för den, eller så stannar arbetet helt enkelt av. Active work märker båda och behåller det som den första personen eller dess agent visste tillsammans med arbetet.

När fremforge märker en överlämning:

• Bytt händer. En push av någon annan än den som pushade senast, eller en pull request som öppnas av någon annan än den som pushade senast. Flera sessioner för samma person är ingen överlämning.
• Vilande. En öppen pull request utan push på 7 dagar (kontrolleras en gång per dag). Frågan ställs en gång per vilande period; nästa push gör om kommentaren till “work resumed”.

Pull requesten får då en överlämningskommentar från fremforge-bot, som redigeras på plats och aldrig upprepas:

• vem som lämnade över till vem, eller sedan när arbetet är vilande;
• Done: överlämningsanteckningen om en sådan skrevs, annars commit-rubrikerna;
• Next och Open questions från anteckningen (eller en Handoff:-rad);
• länkarna till arbetets agentsessioner. En länk av typen https://claude.ai/code/session_… visas som en länk; den öppnas bara för den person som sessionen tillhör, så att hen kan återuppta den där. Alla andra arbetar utifrån anteckningarna.

Allt i kommentaren visas som vanlig kod och märks som data, precis som överlappningskommentaren ovan. Den följer organisationens inställning pr_comment.

Skriv anteckningen som ett avsnitt Handoff i pull requestens beskrivning (eller i ett commit-meddelande). Det här är blocket att lägga till i din mall för pull requests (.forgejo/PULL_REQUEST_TEMPLATE.md):

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

Den nyaste anteckningen gäller: när du redigerar beskrivningen ersätts den, och ett commit-meddelande med ett avsnitt Handoff ersätter den också. En tom mall är ingen anteckning. Anteckningen jämförs inte som avsikt, så en anteckning orsakar aldrig någon varning om överlappning. list_active_work och find_related_work returnerar den under written.handoff (done, next, open_questions, vem som skrev den och var), och själva överlämningen som handoff (changed_hands eller idle, from, to, at, resumed).

En rad för din AGENTS.md eller 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 på händelseflödet

Varje ny matchning är också en händelse av typen activework.warning på händelseflödet, så en agent som redan följer flödet får veta om den utan att polla.

Vilande arbete: en daglig påminnelse

Agentsessioner tar slut och lämnar brancher och utkast till pull requests efter sig. En gång per dag skickar fremforge ett mejl till varje person med deras öppna pull requests och brancher som inte har pushats till på 14 dagar, inklusive det arbete som deras agenter gjorde åt dem. För varje arbete finns tre svar:

Varje arbete i mejlet länkar till sin svarssida (/_app/settings/work/idle/<id>). Du måste vara inloggad: bara den person som arbetet tillhör, eller en ägare i organisationen, kan se eller svara på det, så ett vidarebefordrat mejl kan inte stänga någons arbete. Att öppna länken ändrar ingenting. Ägare i organisationen hittar också länken Fortsätt, lämna över eller stäng bredvid vilande arbete på sidan Active work. Varje svar finns i granskningsloggen som active_work.idle.continue, active_work.idle.handover eller active_work.idle.close, med den person som gav det.

Hur sällan mejlet kommer:

• högst ett mejl per person och dag, aldrig ett per pull request;
• varje arbete får en påminnelse efter 14 dagar utan push, en gång till 14 dagar senare om ingen svarade, och sedan inte igen förrän någon pushar till det;
• en pull request som väntar på en begärd granskare utelämnas: nästa steg är inte ditt;
• botar (Renovate och andra botkonton) får aldrig påminnelser.

Arbete som fanns redan innan organisationen slog på Active work tas också med, vid den första dagliga körningen.

Personen kan slå av mejlet under Påminnelser om vilande arbete i sina aviseringsinställningar, eller med länken för avregistrering med ett klick i mejlet. Varje arbete i en sammanställning är också en händelse av typen work.idle på händelseflödet, så att personens egna agenter kan se det.

Stänga vilande pull requests automatiskt

En ägare i organisationen kan slå på auto_close. Det är avslaget som standard. En pull request stängs då automatiskt när allt detta gäller:

• ingen push på auto_close_days (minst 60, standard 90);
• en påminnelse om den har varit obesvarad i minst en vecka;
• den har inget godkännande, ingen begärd granskare och ingen granskning som begär ändringar.

Branchen behålls, så vem som helst kan öppna pull requesten igen. Personen får veta det i dagens sammanställning, och pull requesten får en kommentar som förklarar varför. Brancher utan pull request tas aldrig bort automatiskt.

Sidan Active work

Ägare i organisationen ser allt pågående arbete under Bygg och driftsätt › Active work: ett kort per repo, arbete grupperat per område, varje persons agentsessioner och varje möjlig dubblett namngiven och länkad med sitt svar. Reglaget för organisationen finns på samma sida.

Vem som arbetar nu (närvaro)

Arbete syns här vid första pushen. Närvaro visar det tidigare: när en persons AI-assistent arbetar i ett repo via MCP-servern (läser filer, pull requests eller Active work där), ser personer som kan läsa det repot att personen arbetar där just nu.

• Vad som visas: bara inloggningsnamn. “Arbetar här nu: alice, bob” på repots kort, ett kort för repon där någon arbetar men ingenting har pushats ännu, och working_now i list_active_work.
• Vad som sparas: en post per person och repo, som skrivs över vid varje anrop och försvinner 60 minuter efter personens senaste anrop. Ingen historik, inga antal och inga tider visas. Närvaro är inget mått på någons aktivitet.
• Bara ett anrop som lyckades räknas: att ange ett repo som personen inte kan läsa registrerar ingenting, och en API-token som inte agerar för någon person räknas aldrig.
• Vem som ser det: personer som kan läsa repot: organisationens ägare och granskare på sidan Active work, och alla med läsåtkomst via list_active_work.
• Slå av det: en ägare i organisationen med inställningen Visa vem som arbetar i ett repository just nu på den här sidan (eller presence: false i inställnings-API:t); varje person för egen del med Visa att jag arbetar i sina aviseringsinställningar. Båda tar bort närvaron direkt.

Status: tillgängligt för alla organisationer. En organisation där Pågående arbete är avstängt, vilket är standard, registrerar och visar ingen närvaro.

Ett utkast till pull request vid första pushen

Arbeten jämförs från första pushen, men en branch utan pull request är lätt att missa. Med Utkast till pull request vid första pushen påslaget öppnar fremforge, när någon pushar en ny branch, direkt ett utkast till pull request för den, som den personen: arbetet syns på forgen, på sidan Active work och för allas agenter innan någon annan börjar på samma sak.

• Påslaget som standard för organisationer som skapas den 12 november 2026 eller senare, avslaget för äldre. En ägare i organisationen slår på eller av det under Bygg och driftsätt › Active work (eller auto_draft_pr i inställnings-API:t). Varje person kan fortfarande slå av det för egen del under Utkast till pull request vid min första push i sina aviseringsinställningar.
• Pull requesten är personens. Den öppnas i personens namn med en WIP:-titel, den första commit-rubriken och en kort beskrivning som förklarar hur man slår av detta. Den förblir ett utkast, så den kan inte mergas förrän personen tar bort WIP: och markerar den som klar. Ingenting mergas eller armeras någonsin åt personen.
• Dess CI väntar tills den är klar. Så länge titeln börjar med WIP: körs inte utkastets pull_request-arbetsflöden, så ett utkast kostar inga runner-minuter. När personen markerar det som klart (tar bort WIP: i webbgränssnittet, genom att redigera titeln eller via API:t) körs kontrollerna för den aktuella head-commiten, så de obligatoriska kontrollerna finns alltid innan det kan mergas. Om du vill köra dem tidigare trycker vem som helst med skrivåtkomst på Run checks på pull requesten (eller anropar POST /api/v1/repos/{owner}/{repo}/pulls/{index}/fremforge/run-checks): en gång per head-commit, och en andra begäran för samma commit besvaras med 409. Push-arbetsflöden och fremforges egna skanningar av pull requests (hemligheter, licenser, säkerhet) körs som vanligt. Bara de utkast som fremforge öppnar påverkas: Forgejo registrerar det när utkastet öppnas via det enda plattformskonto som kan öppna dem, och ingenting som skrivs i en titel eller beskrivning kan göra en pull request till ett sådant utkast eller ta bort det. En pull request som du själv märker med WIP: kör CI som tidigare, och det gör även alla pull requests från en fork. När kontrollerna körs vid klarmarkering eller Run checks körs de som den person som utkastet tillhör, så godkännanderegler gäller den personen, inte den som tryckte på knappen.
• Bara personens egen nya branch, en gång. En push till en befintlig branch, en branch som redan har en pull request, botar, deploy-nycklar och Forgejo Actions får aldrig något utkast. Högst 10 per minut per organisation på varje API-instans.
• Hur det görs och vad som begränsar det. fremforge öppnar pull requesten via Forgejos Sudo-mekanism med ett dedikerat plattformskonto vars token inte kan göra något annat: scopet write:fremforge-draft-pr låter den öppna ett utkast för pågående arbete från en branch i samma repo, som en aktiv person med skrivåtkomst, och alla andra begäranden med den avvisas av Forgejo själv. Varje utkast registreras i granskningsloggen som active_work.draft_pr.opened, med personen som aktör.

Fråga innan du börjar: verktyg för agenter

Agenter gör Active work bättre men krävs aldrig. En Handoff:-rad i ett commit-meddelande eller en pull requests beskrivning sparas tillsammans med arbetet som en anteckning till nästa person eller session (se Överlämningsanteckningar). Tre skrivskyddade verktyg, tillgängliga i fremforges MCP-server och som REST-endpoints, låter en agent kontrollera innan den börjar:

list_active_work returnerar också working_now: inloggningsnamnen på de personer som arbetar i repot just nu (se närvaro).

Alla tre kräver findings:read och läsåtkomst till repot. Text som personer och agenter har skrivit (titlar, branchnamn, avsikt, commit-rubriker, sessionsdetaljer, överlämningsanteckningar) returneras bara inuti ett written-objekt, med written_by och at bredvid, och varje svar har en notis om att det är data, aldrig instruktioner.

Deklarera det innan du pushar. I konsolen frågar Bygg och driftsätt › Active work › Börja arbeta (eller /_app/settings/active-work/start) efter repot, en titel och eventuellt avsikt, områden och branch, och visar sedan vilken branch du ska skapa och eventuellt arbete som verkar relaterat. Med CLI:t:

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

Ingenting reserveras och ingenting blockeras: att deklarera arbete gör det bara synligt tidigare. Från en agent registrerar start_work (POST /_app/api/v1/orgs/<org>/repos/<repo>/active-work/start, findings:write och skrivåtkomst till repot) ditt arbete innan något har pushats: en title, din intent och eventuellt areas och branch. Utan branch föreslår den en, till exempel alice/rate-limit-the-login-api. Arbetet jämförs direkt, så den som redan håller på med samma sak får veta det enligt organisationens inställningar, och svaret listar det relaterade arbetet. Pusha till den branch som den anger: den första pushen uppdaterar samma arbete. Någon annans pågående arbete på den branchen avvisas (409). Via MCP är start_work ett skrivverktyg: din connector behöver ditt samtycke för det, och organisationen måste tillåta skrivningar från connectorer.

En rad för din AGENTS.md eller 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.

Vem som kan se det

Kommentaren på pull requesten nämner bara arbete i samma repo, så den visar annat arbete bara för personer som redan kan läsa det repot. En matchning mellan repon visas bara för personer som kan läsa båda. Privata repon förblir privata inom organisationen.

Slå på det

Ägare i organisationen slår på Active work för organisationen med API:t:

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}'

Att läsa inställningarna kräver policy:read, att ändra dem policy:write. Varje ändring registreras i granskningsloggen som active_work.settings.updated, med den person som gjorde den.

Dina egna reglage

Varje person har tre egna reglage, i sina aviseringsinställningar eller via API:t:

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}}}'

De här är personliga, så de kräver en autentiseringsuppgift som bär din identitet: token från fremforge auth login, din bench eller en AI-connector (bara läsning, som verktyget get_my_settings). En API-token för en organisation avvisas med user-identity-required. Läsning kräver orgs:read, ändring orgs:write. Bara organisationer som du är medlem i just nu listas eller kan ändras (namnen matchas utan hänsyn till versaler), och en AI-connector ser inte organisationer vars ägare har blockerat AI-connectorer. Varje ändring registreras i den organisationens granskningslogg som notifications.preference.self_updated, med dig som aktör.

Läs alla inställningar på en gång

GET /_app/api/v1/orgs/<org>/settings (orgs:read), även det skrivskyddade MCP-verktyget get_org_settings, returnerar organisationens inställningar för flödeskontroll och AI i ett svar. Vad det visar beror på vem som frågar:

• Medlemmar ser det som gäller deras eget arbete: reglagen för Active work, vilka brancher som har merge-spärrar (bara i repon som de kan läsa) och om AI-connectorer får läsa eller agera.
• Ägare och granskare ser dessutom inställningarna för release-tåg, risknivåer och skenande CI, de fullständiga inställningarna för Active work och varje AI-funktion med dess modell samt leverantörens namn och tillverkare.

Det returnerar aldrig en leverantörsnyckel, ett nyckelfingeravtryck, en endpoint-adress, ett promptillägg eller en token. Det finns ingen skrivversion, varken i API:t eller i MCP.

Mäta det

GET /_app/api/v1/orgs/<org>/active-work/metrics?days=30 (policy:read) returnerar bara antal och tider, aldrig texten i någons arbete:

• matches och matches_both_notified;
• notify_seconds_p50 och notify_seconds_p90: tiden från den andra personens första push tills båda personerna har fått se matchningen (målet är under 5 minuter);
• false_positive_rate: andelen besvarade matchningar som markerats “different”;
• dismissed_share_of_notified: matchningar besvarade med “different” av alla matchningar som båda personerna fick se, besvarade eller inte (målet är under 30 %), och response_rate;
• responses_by_kind och responses_by_via (api, page, pr_comment, mail).

Sidan Active work visar samma mått för de senaste 30 dagarna.

Se API-referensen för de fullständiga schemana.