Active work

En person med kodeagenter kører flere sessioner på én gang, og et team ganger det op. To personers agenter kan bygge det samme på to branches, der ikke deler en eneste fil, så ingen merge-konflikt nogensinde viser det. Active work gør de push, fremforge allerede modtager, til et billede af det igangværende arbejde og advarer, når to stykker arbejde ligner hinanden.

Ingen agent behøver at samarbejde. Active work læser det, forgen allerede ser: branches, push, pull requests og de trailers, agenter allerede skriver.

Hvad det registrerer

Når en branch pushes første gang, opretter fremforge et aktivt arbejdsemne og opdaterer det ved hvert push og hver ændring af pull requesten:

Et emne er aktivt, så længe der pushes til det inden for 7 dage. Det er færdigt, når dets pull request merges, eller branchen slettes, og opgivet, når pull requesten lukkes uden at blive merget. Push til default branch og branches pushet af fremforges egne bots eller Renovate registreres ikke.

Sådan sammenlignes arbejde

Hver gang et emne ændrer sig, sammenligner fremforge det med de andre aktive emner i samme repository. To emner rapporteres som muligvis det samme arbejde, når deres titler deler de fleste af deres meningsbærende ord (for eksempel “Rate limit the login endpoint” og “Add rate limiting to the login API”), eller når deres øvrige tekst overlapper meget, og de rører det samme område.

Sammenligningen er tekstmatchning i fremforges egen database. Der bruges ingen AI-model, og ingen kode eller tekst forlader fremforge, medmindre en organisationsejer også slår semantisk matchning på din egen model til, hvilket er slået fra som standard. Ord, som alle ændringer bruger (“fix”, “update”, “add”), og ord, der er almindelige i repositoriets eget arbejde, ignoreres, så to ændringer ikke matches, blot fordi de begge handler om det samme produkt.

På tværs af repositories

Arbejde sammenlignes også med aktivt arbejde i organisationens andre repositories, men kun ud fra titel og hensigt (et område som apps/api i ét repository siger intet om et andet). De samme regler for par, der ikke er nyheder, gælder. Et match på tværs af repositories:

• vises kun for personer, der kan læse begge repositories: på siden Active work, i mailen, på svarsiden og i læseværktøjerne;
• får aldrig en kommentar på en pull request og sendes ikke på hændelsesfeedet, fordi kommentaren er synlig for alle, der kan læse det ene repository;
• nævner det andet arbejde som org/repo#12, eller org/repo:branch for en branch uden pull request.

Semantisk matchning på din egen model

Tekstmatchning finder arbejde, der siger det samme med de samme ord. Semantisk matchning spørger også din organisations egen AI-udbyder, om to stykker igangværende arbejde er det samme arbejde, når ordene er forskellige (“SSO button on the sign-in page” og “Log in with the company account”). Det er valgfrit og slået fra som standard, og det supplerer kun tekstmatchningen:

• det kan tilføje et match, som teksten ikke fandt, eller hæve scoren for et, den fandt. Det sænker eller fjerner aldrig et match;
• det sammenligner kun arbejde i samme repository, aldrig på tværs af repositories;
• fejler et kald, er det langsomt, eller ville det gå over dine grænser, fortsætter matchningen blot med tekst alene.

Din egen udbyder og intet andet

Semantisk matchning bruger en AI-udbyder, som din organisation har konfigureret under AI-integrationer, med din egen nøgle og din egen aftale med den leverandør. fremforge har ingen egen nøgle til det og intet alternativ at falde tilbage på: uden din udbyder er der ingen semantisk matchning. Leverandøren er din databehandler, ikke en underdatabehandler for fremverk (databehandleraftalens bilag B §B.8).

Kald forlader kun fremforge gennem en begrænset udgående proxy, og kun til din udbyders vært, som den blev kontrolleret og fastlåst, da udbyderen blev gemt. Skifter udbyderens adresse til en anden vært, slår semantisk matchning sig selv fra, indtil en ejer slår den til igen, og det registreres i revisionsloggen.

Hvad der sendes

Når et stykke arbejde, eller det andet arbejde, det sammenlignes med, har ændret sig (og højst én gang hvert 10. minut for hvert stykke arbejde), sender fremforge din udbyder følgende for det stykke arbejde og for højst 15 andre stykker igangværende arbejde i samme repository:

De andre stykker arbejde betegnes c1, c2, … i anmodningen, aldrig med id eller person.

Et felt, der indeholder loginoplysninger, udelades. Før noget sendes, scannes hvert felt med push-beskyttelsens egne regler: gitleaks’ standardregler for den version, fremforge kører, plus fremforges egne (frem.sh-tokens, EU-cloududbydere, forbindelsesstrenge, adgangskoder i konfiguration). Et felt, der matcher, fjernes fra anmodningen, ikke maskeret. Kan scanningen ikke køre, sendes der slet ikke noget.

Hvad der gemmes

fremforge gemmer hverken anmodningen eller udbyderens svar. For hvert par af stykker arbejde gemmer den kun, om svaret talte som det samme arbejde, og en sikkerhedsscore samt en envejs-hash af anmodningen, så den samme anmodning ikke sendes to gange. Det slettes sammen med arbejdet og dets matches: 90 dage efter at arbejdet blev færdigt (dets pull request blev merget eller lukket, eller dets branch slettet), eller 30 dage efter at Active work er slået fra for organisationen. Hvert kald registreres som ethvert kald fra en AI-funktion (funktion, udbyder, antal tokens, svartid), aldrig dets indhold.

Først skygge, så notifikationer

Semantisk matchning starter i skyggetilstand: vurderinger registreres og måles, og ingen får besked om dem. Tærsklerne sættes ud fra de vurderinger, før de matches, den finder, bliver vist. Når den begynder at give besked, siger en kommentar på en pull request eller en mail om et match, som semantisk matchning fandt eller bekræftede, det og nævner den AI-leverandør og model, der svarede.

Grænser

• Højst ét kald pr. stykke arbejde hvert 10. minut, og kun når det, der ville blive sendt, har ændret sig.
• Højst 30 kald pr. organisation på 10 minutter og 500 om dagen, oven i organisationens grænse for AI-forbrug.
• Fem mislykkede kald i træk sætter semantisk matchning på pause for organisationen i 15 minutter (revisionshandling active_work.semantic.paused).

Slå semantisk matchning til

En organisationsejer slår det til under Administration → AI-integrationer → Active work: semantisk matching. Kontakten afviser, indtil:

1. Active work er slået til for organisationen (Slå det til);
2. organisationen har sin egen AI-udbyder;
3. den udbyder har en kontrolleret, fastlåst vært (gem udbyderen igen, hvis den blev tilføjet før 26. oktober 2026, og kontakten siger det).

At slå det til eller fra registreres i revisionsloggen som active_work.semantic.enabled eller active_work.semantic.disabled, med personen, udbyderen og den fastlåste vært. Test denne funktion tilbydes ikke til semantisk matchning: den sender kun teksten fra igangværende arbejde. Den slås kun til i konsollen; REST API’et konfigurerer den ikke.

Markér dine kontrakter

Nogle filer er løfter, som andet arbejde bygger på: en API-specifikation, databasemigreringer, fælles typer. Markér dem i .fremforge/contracts på repositoriets default branch, ét mønster pr. linje:

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

* matcher inden for én mappe, ** på tværs af mapper, og en linje, der slutter med /, dækker alt under den. # begynder en kommentar. Uden filen behandles intet som en kontrakt.

Når en merge til default branch ændrer en kontraktfil, får hvert stykke aktivt arbejde i samme område, der begyndte før ændringen, et afsnit Contract changed i sin Active work-kommentar, der nævner filen og mergen. what_changed_since og list_active_work viser det også. Intet blokeres: det er en påmindelse om at rebase og kontrollere igen. Registreringen af, hvem der mergede ændringen, gemmes i 90 dage.

Reelle konflikter: en prøve-merge

To branches, der ikke deler en idé, kan stadig støde sammen i de samme filer. Når et stykke arbejde ændrer sig, laver fremforge en prøve-merge af det med det andet åbne arbejde, der rører det samme område (eller som ligner det samme arbejde), head mod head, inde i Forgejo. Prøve-mergen skriver intet i repositoriet og flytter ingen branch.

Når de to heads er i konflikt, viser begge pull requests’ Active work-kommentar det andet arbejde og de filer, der er i konflikt, før nogen af dem er merget. Den, der merger som nummer to, skal løse konflikten, så aftal, hvem der går først, eller rebase oven på det andet nu. Når den ene side flytter sig, og de to kan merges rent igen, eller når den ene side bliver færdig, forsvinder konflikten fra kommentaren. list_active_work returnerer også de åbne konflikter (conflicts).

Hvert par merges én gang pr. par af heads, højst 10 gange i minuttet pr. repository og kun for repositories under 2 GiB. Er prøve-mergen ikke tilgængelig, er der blot intet konfliktsignal; intet bliver nogensinde blokeret.

Par, der ikke er nyheder

Nogle par ligner det samme arbejde, men er ikke nyt for nogen. De vises på siden Active work med en label, og ingen får mail eller en advarsel på pull requesten:

Ethvert andet par fra to forskellige personer rapporteres, også når den ene nævner den andens arbejde: det viser, at én af jer ved det, ikke begge. For at markere et repository som dokumentation uden at omdøbe det skal du give det et af de emner under dets Settings.

Der sendes mail om et match cirka tre minutter efter, at det er fundet, så en trailer for agentsession, der først kommer med pull requestens beskrivelse, stadig kan nå at markere parret som én sessions eget arbejde.

Når én ændring giver flere nye matches for dig på én gang, får du én mail, der viser dem alle, hver med sit Svar-link, ikke én mail pr. par.

Kommentaren på pull requesten

Når der findes et match, får hver involveret pull request én kommentar fra fremforge-bot:

• Den viser det andet arbejde: dets pull request eller branch, personen, og de ord og områder, de deler.
• Den redigeres på stedet, når matchene ændrer sig, og gentages aldrig. Når det andet arbejde merges eller lukkes, siger kommentaren, at der ikke længere er noget overlap.
• Tekst fra det andet arbejde vises som almindelig kode, aldrig som links eller omtaler, og er markeret som data. En agent, der læser pull requesten, læser det som information, ikke som instruktioner.

Kommentaren blokerer aldrig noget. Er arbejdet det samme, så aftal med den anden person, hvem der fortsætter.

Mail til begge personer

Begge personer får én mail pr. match, på deres eget sprog, der nævner det andet arbejde, personen og de ord og områder, de deler, med et link til den anden pull request eller branch. Når begge sider er to af dine egne sessioner, får du én mail, der siger det. Hver person kan slå Active work-mail fra i sine notifikationsindstillinger; en organisationsejer kan slå mail fra for hele organisationen (email_notify). Ingen, hvis mailpræference i Forgejo er “disabled”, får mail.

Besvar et match

Hver af de to personer kan sige, hvad et match er:

Svar der, hvor du møder matchet:

• På pull requesten: kommentarens Svar-link åbner svarsiden (kræver login).
• I mailen: den samme side, fra Svar her. At åbne linket ændrer intet; kun når du gemmer formularen, registreres et svar.
• På siden Active work: Svar-linket ved siden af en mulig dublet, for de to personer i parret.
• Med API’et: POST /_app/api/v1/orgs/<org>/repos/<repo>/active-work/matches/<id>/response med {"response": "split", "continued_by": "<login>"} (findings:write, læseadgang til repositoriet). GET …/matches/<id> læser ét match og dets svar, og list_active_work returnerer match_id, response og continued_by for hvert åbent match.

Kun de to personer, hvis arbejde det er, kan svare, aldrig nogen på deres vegne: et token, der ikke handler for nogen, får no-principal, alle andre not-a-party. Et svar kan ændres; det seneste tæller. Hvert svar registreres i revisionsloggen som active_work.match.responded, med det tidligere svar, og hvor det blev givet. En agent kan svare for sin person gennem API’et eller gennem MCP-skriveværktøjet answer_active_work_match, når personen har givet samtykke til det, og organisationen tillader skrivning via forbindelser. Svaret returnerer previous_response, det svar, det erstattede.

Overdragelsesnoter

Arbejde skifter hænder: en anden person pusher til branchen, åbner pull requesten for den, eller arbejdet går simpelthen i stå. Active work lægger mærke til begge dele og bevarer det, den første person eller vedkommendes agent vidste, sammen med arbejdet.

Når fremforge opdager en overdragelse:

• Skiftet hænder. Et push fra en anden end den person, der pushede sidst, eller en pull request åbnet af en anden end den person, der pushede sidst. Flere sessioner fra samme person er ikke en overdragelse.
• Inaktivt. En åben pull request uden push i 7 dage (kontrolleres én gang om dagen). Der spørges om det én gang pr. inaktiv periode; det næste push gør kommentaren til “work resumed”.

Pull requesten får så én overdragelseskommentar fra fremforge-bot, redigeret på stedet og aldrig gentaget:

• hvem der overdrog til hvem, eller siden hvornår arbejdet har ligget stille;
• Done: overdragelsesnoten, hvis der er skrevet en, ellers commit-emnerne;
• Next og Open questions fra noten (eller en Handoff:-linje);
• links til agentsessionerne på arbejdet. Et https://claude.ai/code/session_…-link vises som et link; det åbner kun for den person, hvis session det er, så vedkommende kan genoptage den der. Alle andre arbejder ud fra noterne.

Alt i kommentaren vises som almindelig kode og er markeret som data, ligesom overlapkommentaren ovenfor. Den følger organisationens indstilling pr_comment.

Skriv noten som et afsnit Handoff i pull requestens beskrivelse (eller i en commit-besked). Dette er blokken, du kan tilføje til din skabelon for pull requests (.forgejo/PULL_REQUEST_TEMPLATE.md):

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

Den nyeste note vinder: redigeres beskrivelsen, erstattes den, og en commit-besked med et Handoff-afsnit erstatter den også. En tom skabelon er ikke en note. Noten sammenlignes ikke som hensigt, så det giver aldrig en advarsel om overlap at skrive en. list_active_work og find_related_work returnerer den under written.handoff (done, next, open_questions, hvem der skrev den, og hvor), og selve overdragelsen som handoff (changed_hands eller idle, from, to, at, resumed).

En linje til 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ændelsesfeedet

Hvert nyt match er også en activework.warning-hændelse på hændelsesfeedet, så en agent, der allerede følger feedet, får det at vide uden at spørge.

Inaktivt arbejde: en daglig påmindelse

Agentsessioner slutter og efterlader branches og pull request-kladder. Én gang om dagen sender fremforge hver person én mail, der viser deres åbne pull requests og branches uden push i 14 dage, også det arbejde, deres agenter har lavet for dem. For hvert stykke arbejde er der tre svar:

Hvert punkt i mailen linker til sin svarside (/_app/settings/work/idle/<id>). Du skal være logget ind: kun den person, arbejdet tilhører, eller en ejer af organisationen kan se eller besvare det, så en videresendt mail ikke kan lukke nogens arbejde. At åbne linket ændrer intet. Organisationens ejere finder også et link Fortsæt, overdrag eller luk ved siden af inaktivt arbejde på siden Active work. Hvert svar står i revisionsloggen som active_work.idle.continue, active_work.idle.handover eller active_work.idle.close, med den person, der gav det.

Hvor sjælden mailen er:

• højst én mail pr. person pr. dag, aldrig én pr. pull request;
• hvert stykke arbejde får en påmindelse efter 14 dage uden push, én gang mere 14 dage senere, hvis ingen svarede, og derefter ikke igen, før nogen pusher til det;
• en pull request, der venter på en anmodet reviewer, er udeladt: det næste skridt er ikke dit;
• bots (Renovate og andre bot-konti) får aldrig påmindelser.

Arbejde, der allerede fandtes, før organisationen slog Active work til, kommer også med ved den første daglige kørsel.

Personen kan slå mailen fra under Påmindelser om inaktivt arbejde i sine notifikationsindstillinger eller med linket til afmelding med ét klik i mailen. Hvert punkt i en samlet mail er også en work.idle-hændelse på hændelsesfeedet, så personens egne agenter kan se det.

Automatisk lukning af inaktive pull requests

En organisationsejer kan slå auto_close til. Det er slået fra som standard. En pull request lukkes så automatisk, når alt dette er opfyldt:

• intet push i auto_close_days (mindst 60, standard 90);
• en påmindelse om den er forblevet ubesvaret i mindst en uge;
• den har ingen godkendelse, ingen anmodet reviewer og ingen review, der beder om ændringer.

Branchen bevares, så alle kan genåbne pull requesten. Personen får besked i den dags samlede mail, og pull requesten får en kommentar om hvorfor. Branches uden pull request slettes aldrig automatisk.

Siden Active work

Organisationens ejere ser alt igangværende arbejde under Byg og udrul › Active work: ét kort pr. repository, arbejde grupperet efter område, hver persons agentsessioner og hver mulig dublet navngivet og linket med sit svar. Kontakten for organisationen findes på samme side.

Hvem arbejder nu (tilstedeværelse)

Arbejde vises her ved første push. Tilstedeværelse viser det tidligere: når en persons AI-assistent arbejder i et repository gennem MCP-serveren (læser filer, pull requests eller Active work der), ser personer, der kan læse det repository, at personen arbejder der nu.

• Hvad der vises: kun logins. “Working here now: alice, bob” på repositoriets kort, et kort for repositories, hvor nogen arbejder, og intet er pushet endnu, og working_now i list_active_work.
• Hvad der gemmes: én post pr. person og repository, overskrevet ved hvert kald og væk 60 minutter efter personens seneste kald. Ingen historik, ingen optællinger, og ingen tidspunkter vises. Tilstedeværelse er ikke et mål for nogens aktivitet.
• Kun et kald, der lykkedes, tæller: at nævne et repository, personen ikke kan læse, registrerer intet, og et API-token, der ikke handler for nogen person, tæller aldrig.
• Hvem ser det: personer, der kan læse repositoriet: organisationens ejere og revisorer på siden Active work og alle med læseadgang gennem list_active_work.
• Slå det fra: en organisationsejer med indstillingen Vis hvem der arbejder i et repository lige nu på denne side (eller presence: false i indstillings-API’et); hver person for sig selv med Vis, at jeg arbejder i sine notifikationsindstillinger. Begge dele sletter tilstedeværelsen med det samme.

Status: tilgængeligt for alle organisationer. En organisation, hvor Active work er slået fra, som er standard, registrerer og viser ingen tilstedeværelse.

En pull request-kladde ved første push

Arbejde sammenlignes fra første push, men en branch uden pull request er let at overse. Med Pull request-kladde ved første push slået til åbner fremforge, når nogen pusher en ny branch, med det samme en kladde til en pull request for den, som den person: arbejdet er synligt i forgen, på siden Active work og for alles agenter, før nogen anden går i gang med det samme.

• Slået til som standard for organisationer oprettet den 12. november 2026 eller senere, slået fra for ældre. En organisationsejer slår det til eller fra under Byg og udrul › Active work (eller auto_draft_pr i indstillings-API’et). Hver person kan stadig slå det fra for sig selv under Pull request-kladde ved mit første push i sine notifikationsindstillinger.
• Pull requesten er personens. Den åbnes i vedkommendes navn med en WIP:-titel, det første commit-emne og en kort beskrivelse, der fortæller, hvordan man slår det fra. Den forbliver en kladde, så den ikke kan merges, før vedkommende fjerner WIP: og markerer den som klar. Intet bliver nogensinde merget eller sat til auto-merge for vedkommende.
• Dens CI venter, til den er klar. Så længe titlen begynder med WIP:, kører kladdens pull_request-workflows ikke, så en kladde koster ingen runner-minutter. Når personen markerer den som klar (fjerner WIP: i webbrugerfladen, ved at redigere titlen eller via API’et), kører checks for det aktuelle head-commit, så de påkrævede checks altid findes, før den kan merges. For at køre dem tidligere kan alle med skriveadgang trykke på Run checks på pull requesten (eller kalde POST /api/v1/repos/{owner}/{repo}/pulls/{index}/fremforge/run-checks): én gang pr. head-commit, og en ny anmodning for samme commit svarer 409. Push-workflows og fremforges egne scanninger af pull requests (secrets, licenser, sikkerhed) kører som normalt. Kun de kladder, fremforge åbner, påvirkes: Forgejo registrerer det, når kladden åbnes gennem den ene platformskonto, der kan åbne dem, og intet, der skrives i en titel eller beskrivelse, kan gøre en pull request til eller fra sådan en. En pull request, du selv markerer WIP:, kører CI som før, og det gør enhver pull request fra en fork også. Når checks kører ved klar eller Run checks, kører de som den person, kladden tilhører, så godkendelsesregler gælder for den person, ikke for den, der trykkede på knappen.
• Kun deres egen nye branch, én gang. Et push til en eksisterende branch, en branch, der allerede har en pull request, bots, deploy-nøgler og Forgejo Actions får aldrig en. Højst 10 i minuttet pr. organisation på hver api-instans.
• Hvordan det gøres, og hvad der begrænser det. fremforge åbner pull requesten gennem Forgejos Sudo-mekanisme med én dedikeret platformskonto, hvis token ikke kan andet: omfanget write:fremforge-draft-pr lader den åbne en kladde til igangværende arbejde fra en branch i samme repository, som en aktiv person med skriveadgang, og alle andre anmodninger med den afvises af Forgejo selv. Hver kladde registreres i revisionsloggen som active_work.draft_pr.opened, med personen som aktør.

Spørg, før du starter: værktøjer til agenter

Agenter gør Active work bedre, men er aldrig påkrævet. En Handoff:-linje i en commit-besked eller i en pull requests beskrivelse gemmes sammen med arbejdet som en note til den næste person eller session (se Overdragelsesnoter). Tre skrivebeskyttede værktøjer, tilgængelige i fremforges MCP-server og som REST-endpoints, lader en agent kontrollere, før den går i gang:

list_active_work returnerer også working_now: logins for de personer, der arbejder i repositoriet nu (se tilstedeværelse).

Alle tre kræver findings:read og læseadgang til repositoriet. Tekst, som personer og agenter har skrevet (titler, branchnavne, hensigt, commit-emner, sessionsdetaljer, overdragelsesnoter), returneres kun inde i et written-objekt med written_by og at ved siden af, og hvert svar har en besked om, at det er data, aldrig instruktioner.

Meld det, før du pusher. I konsollen beder Byg og udrul › Active work › Start arbejde (eller /_app/settings/active-work/start) om repositoriet, en titel og eventuelt hensigt, områder og branch og viser derefter den branch, der skal oprettes, og alt arbejde, der ligner. Med CLI’en:

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

Intet reserveres, og intet blokeres: at melde arbejde gør det blot synligt tidligere. Fra en agent registrerer start_work (POST /_app/api/v1/orgs/<org>/repos/<repo>/active-work/start, findings:write og skriveadgang til repositoriet) dit arbejde, før noget er pushet: en title, din intent og eventuelt areas og branch. Uden en branch foreslår den en, såsom alice/rate-limit-the-login-api. Arbejdet sammenlignes med det samme, så alle, der allerede er i gang med det samme, får besked efter organisationens indstillinger, og svaret viser det relaterede arbejde. Push til den branch, den nævner: det første push opdaterer det samme emne. En andens igangværende arbejde på den branch afvises (409). Gennem MCP er start_work et skriveværktøj: din forbindelse skal have dit samtykke til det, og organisationen skal tillade skrivning via forbindelser.

En linje til 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.

Hvem kan se det

Kommentaren på pull requesten nævner kun arbejde i samme repository, så den viser kun andet arbejde for personer, der allerede kan læse det repository. Et match på tværs af repositories vises kun for personer, der kan læse begge. Private repositories forbliver private inden for organisationen.

Slå det til

Organisationens ejere slår Active work til for organisationen med API’et:

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

At læse indstillingerne kræver policy:read, at ændre dem policy:write. Hver ændring registreres i revisionsloggen som active_work.settings.updated, med den person, der lavede den.

Dine egne kontakter

Hver person har tre kontakter for sig selv, i sine notifikationsindstillinger eller via API’et:

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 er personlige, så de kræver en legitimation, der bærer din identitet: tokenet fra fremforge auth login, din bench eller en AI-forbindelse (kun læsning, som værktøjet get_my_settings). Et API-token for en organisation afvises med user-identity-required. Læsning kræver orgs:read, ændring orgs:write. Kun organisationer, du er medlem af nu, vises eller kan ændres (navne matches uden hensyn til store og små bogstaver), og en AI-forbindelse ser ikke organisationer, hvis ejere har blokeret AI-forbindelser. Hver ændring registreres i den organisations revisionslog som notifications.preference.self_updated, med dig som aktør.

Læs alle indstillinger på én gang

GET /_app/api/v1/orgs/<org>/settings (orgs:read), også det skrivebeskyttede MCP-værktøj get_org_settings, returnerer organisationens indstillinger for flowstyring og AI i ét svar. Hvad det viser, afhænger af, hvem der spørger:

• Medlemmer ser det, der gælder deres eget arbejde: Active works kontakter, hvilke branches der har merge-holds (kun i repositories, de kan læse), og om AI-forbindelser må læse eller handle.
• Ejere og revisorer ser også indstillingerne for release-tog, risikoniveauer og løbsk CI, alle Active work-indstillingerne og hver AI-funktion med dens model og udbyderens navn og leverandør.

Det returnerer aldrig en udbydernøgle, et nøglefingeraftryk, en endpoint-adresse, en tilføjelse til prompten eller et token. Der findes ingen skriveversion, hverken via API’et eller i MCP.

Sådan måles det

GET /_app/api/v1/orgs/<org>/active-work/metrics?days=30 (policy:read) returnerer kun optællinger og varigheder, aldrig teksten i nogens arbejde:

• matches og matches_both_notified;
• notify_seconds_p50 og notify_seconds_p90: tiden fra den anden persons første push, til begge personer har fået vist matchet (målet er under 5 minutter);
• false_positive_rate: andelen af besvarede matches markeret “different”;
• dismissed_share_of_notified: matches besvaret “different” ud af alle matches, begge personer har fået vist, besvaret eller ej (målet er under 30 %), og response_rate;
• responses_by_kind og responses_by_via (api, page, pr_comment, mail).

Siden Active work viser det samme mål for de seneste 30 dage.

Se API-referencen for de fulde skemaer.