Active work

En person med kodeagenter kjører flere sesjoner samtidig, og et team mangedobler det. Agentene til to personer kan bygge det samme på to brancher som ikke deler en eneste fil, så ingen merge-konflikt avslører det noen gang. Active work gjør pushene fremforge allerede tar imot, om til et bilde av arbeidet som pågår, og advarer når to arbeider ligner på hverandre.

Ingen agent trenger å samarbeide. Active work leser det forgen allerede ser: brancher, pusher, pull requests og trailerne agentene allerede skriver.

Hva den registrerer

Når en branch pushes første gang, oppretter fremforge et aktivt arbeidselement og oppdaterer det ved hver push og hver endring i pull requesten:

Et element er aktivt så lenge det pushes til innen 7 dager. Det er ferdig når pull requesten merges eller branchen slettes, og forlatt når pull requesten lukkes uten merge. Pusher til standardbranchen, og brancher pushet av fremforges egne boter eller Renovate, registreres ikke.

Hvordan arbeid sammenlignes

Hver gang et element endres, sammenligner fremforge det med de andre aktive elementene i samme repository. To elementer rapporteres som mulig samme arbeid når titlene deler de fleste av de meningsbærende ordene (for eksempel «Rate limit the login endpoint» og «Add rate limiting to the login API»), eller når den bredere teksten overlapper sterkt og de berører samme område.

Sammenligningen er tekstmatching i fremforges egen database. Ingen AI-modell brukes, og ingen kode eller tekst forlater fremforge, med mindre en eier av organisasjonen også slår på semantisk matching på din egen modell, som er av som standard. Ord som hver endring bruker («fix», «update», «add»), og ord som er vanlige i repositoryets eget arbeid, ignoreres, så to endringer matches ikke bare fordi begge handler om det samme produktet.

På tvers av repositoryer

Arbeid sammenlignes også med aktivt arbeid i organisasjonens andre repositoryer, bare etter tittel og hensikt (et område som apps/api i ett repository sier ingenting om et annet). De samme reglene for par som ikke er nyheter, gjelder. En match på tvers av repositoryer:

• vises bare for personer som kan lese begge repositoryene: på siden Active work, i e-posten, på svarsiden og i leseverktøyene;
• får aldri en kommentar på pull requesten og sendes ikke på hendelsesfeeden, fordi kommentaren er synlig for alle som kan lese det ene repositoryet;
• omtaler det andre arbeidet som org/repo#12, eller org/repo:branch for en branch uten pull request.

Semantisk matching på din egen modell

Tekstmatching finner arbeid som sier det samme med de samme ordene. Semantisk matching spør i tillegg organisasjonens egen AI-leverandør om to pågående arbeider er det samme arbeidet når ordene er forskjellige («SSO button on the sign-in page» og «Log in with the company account»). Den er valgfri og av som standard, og den kommer bare i tillegg til tekstmatchingen:

• den kan legge til en match teksten ikke fant, eller heve poengsummen til en den fant. Den senker eller fjerner aldri en match;
• den sammenligner bare arbeid i samme repository, aldri på tvers av repositoryer;
• hvis et kall feiler, er tregt eller ville gått over grensene dine, fortsetter matchingen bare med tekst.

Din egen leverandør, og ingenting annet

Semantisk matching bruker en AI-leverandør som organisasjonen din har konfigurert under AI-integrasjoner, med din egen nøkkel og din egen avtale med den leverandøren. fremforge har ingen egen nøkkel til dette og ingen reserveløsning: uten leverandøren din finnes det ingen semantisk matching. Leverandøren er din databehandler, ikke en underdatabehandler for fremverk (databehandleravtalen, vedlegg B §B.8).

Kall forlater fremforge bare gjennom en begrenset utgående proxy, og bare til verten til leverandøren din slik den ble kontrollert og låst da du lagret leverandøren. Hvis adressen til leverandøren endres til en annen vert, slår semantisk matching seg selv av til en eier slår den på igjen, og det registreres i revisjonsloggen.

Hva som sendes

Når et arbeid, eller det andre arbeidet det sammenlignes med, er endret (og høyst én gang hvert 10. minutt per arbeid), sender fremforge leverandøren din følgende for det arbeidet og for høyst 15 andre pågående arbeider i samme repository:

De andre arbeidene merkes c1, c2, … i forespørselen, aldri med id eller person.

Et felt med legitimasjon i blir utelatt. Før noe sendes, skannes hvert felt med push-beskyttelsens egne regler: gitleaks’ standardregler for versjonen fremforge kjører, pluss fremforges egne (frem.sh-tokener, europeiske skyleverandører, tilkoblingsstrenger, passord i konfigurasjon). Et felt som matcher, fjernes fra forespørselen, ikke maskeres. Hvis skanningen ikke kan kjøre, sendes ingenting i det hele tatt.

Hva som beholdes

fremforge beholder ikke forespørselen eller svaret fra leverandøren. For hvert par av arbeider beholdes bare om svaret regnet det som samme arbeid, og en konfidensverdi, pluss en enveis hash av forespørselen slik at samme forespørsel ikke sendes to ganger. Dette slettes sammen med arbeidet og matchene: 90 dager etter at arbeidet ble ferdig (pull requesten merget eller lukket, eller branchen slettet), eller 30 dager etter at Active work ble slått av for organisasjonen. Hvert kall registreres som kallene til alle AI-funksjoner (funksjon, leverandør, antall tokener, ventetid), aldri innholdet.

Først skyggemodus, så varsler

Semantisk matching starter i skyggemodus: vurderingene registreres og måles, og ingen får beskjed om dem. Tersklene settes ut fra disse vurderingene før matchene den finner, vises. Når den varsler, sier en kommentar på pull requesten eller en e-post om en match som semantisk matching fant eller bekreftet, det, og navngir AI-leverandøren og modellen som svarte.

Begrensninger

• Høyst ett kall per arbeid hvert 10. minutt, og bare når det som ville blitt sendt, har endret seg.
• Høyst 30 kall per organisasjon på 10 minutter og 500 per dag, i tillegg til organisasjonens grense for AI-forbruk.
• Fem mislykkede kall på rad setter semantisk matching på pause for organisasjonen i 15 minutter (revisjonshandling active_work.semantic.paused).

Slå på semantisk matching

En eier av organisasjonen slår den på under Organisasjonsadministrasjon → AI-integrasjoner → Active work: semantisk matching. Bryteren nekter til:

1. Active work er på for organisasjonen (Slå den på);
2. organisasjonen har en egen AI-leverandør;
3. den leverandøren har en kontrollert, låst vert (lagre leverandøren på nytt hvis den ble lagt til før 26. oktober 2026 og bryteren sier det).

Å slå den på eller av registreres i revisjonsloggen som active_work.semantic.enabled eller active_work.semantic.disabled, med personen, leverandøren og den låste verten. Test denne funksjonen tilbys ikke for semantisk matching: den sender bare teksten til pågående arbeid. Den slås bare på i konsollen; REST API-et konfigurerer den ikke.

Merk kontraktene dine

Noen filer er løfter som annet arbeid bygger på: en API-spesifikasjon, databasemigreringer, delte typer. Merk dem i .fremforge/contracts på standardbranchen i repositoryet, ett mønster per linje:

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

* matcher innenfor én mappe, ** på tvers av mapper, og en linje som slutter med /, dekker alt under den. # starter en kommentar. Uten filen behandles ingenting som en kontrakt.

Når en merge til standardbranchen endrer en kontraktfil, får hvert aktive arbeid i samme område som startet før endringen, en seksjon Contract changed i Active work-kommentaren sin, med filen og merge-en. what_changed_since og list_active_work viser det også. Ingenting blokkeres: det er en påminnelse om å rebase og sjekke på nytt. Registreringen av hvem som merget endringen, beholdes i 90 dager.

Ekte konflikter: en prøve-merge

To brancher som ikke deler noen idé, kan likevel kollidere i de samme filene. Når et arbeid endres, gjør fremforge en prøve-merge av det med det andre åpne arbeidet som berører samme område (eller som ser ut som samme arbeid), head mot head, inne i Forgejo. Prøve-merge-en skriver ingenting til repositoryet og flytter ingen branch.

Når de to headene er i konflikt, lister Active work-kommentaren på begge pull requestene det andre arbeidet og filene med konflikt, før noen av dem er merget. Den som merger sist, må løse konflikten, så bli enige om hvem som går først, eller rebase på det andre arbeidet nå. Når den ene siden flytter seg og de to kan merges rent igjen, eller den ene siden blir ferdig, forsvinner konflikten fra kommentaren. list_active_work returnerer også de åpne konfliktene (conflicts).

Hvert par merges én gang per par av heads, høyst 10 ganger i minuttet per repository, og bare for repositoryer under 2 GiB. Hvis prøve-merge ikke er tilgjengelig, finnes det rett og slett ikke noe konfliktsignal; ingenting blokkeres noen gang.

Par som ikke er nyheter

Noen par ser ut som samme arbeid, men er ikke nyheter for noen. De vises på siden Active work med en etikett, og ingen får e-post eller advarsel på pull requesten:

Ethvert annet par av to forskjellige personer rapporteres, også når den ene nevner arbeidet til den andre: det viser at bare den ene vet om det, ikke begge. For å merke et repository som dokumentasjon uten å gi det nytt navn gir du det ett av disse emnene under Innstillinger.

En match sendes på e-post omtrent tre minutter etter at den er funnet, slik at en trailer for agentsesjon som først kommer med beskrivelsen av pull requesten, fortsatt kan rekke å merke paret som én sesjons eget arbeid.

Når én endring gir deg flere nye matcher samtidig, får du én e-post som lister dem, hver med sin Svar-lenke, ikke én e-post per par.

Kommentaren på pull requesten

Når en match er funnet, får hver berørt pull request én kommentar fra fremforge-bot:

• Den lister det andre arbeidet: pull requesten eller branchen, personen, ordene og områdene de deler.
• Den redigeres på stedet når matchene endres, og gjentas aldri. Når det andre arbeidet merges eller lukkes, sier kommentaren at det ikke lenger er noen overlapp.
• Tekst fra det andre arbeidet vises som ren kode, aldri som lenker eller omtaler, og merkes som data. En agent som leser pull requesten, leser det som informasjon, ikke som instruksjoner.

Kommentaren blokkerer aldri noe. Hvis arbeidet er det samme, blir du enig med den andre personen om hvem som fortsetter.

E-post til begge personene

Begge personene får én e-post per match, på sitt eget språk, med det andre arbeidet, personen og ordene og områdene de deler, og en lenke til den andre pull requesten eller branchen. Når begge sidene er to av dine egne sesjoner, får du én e-post som sier det. Hver person kan slå av E-post om Active work i sine varselinnstillinger; en eier av organisasjonen kan slå av e-post for hele organisasjonen (email_notify). Ingen med e-postinnstillingen «disabled» i Forgejo får e-post.

Svar på en match

Hver av de to personene kan si hva en match er:

Svar der du møter matchen:

• På pull requesten: Svar-lenken i kommentaren åpner svarsiden (krever innlogging).
• I e-posten: den samme siden, fra Answer here. Å åpne lenken endrer ingenting; bare å lagre skjemaet registrerer et svar.
• På siden Active work: Svar-lenken ved siden av et mulig duplikat, for de to personene i paret.
• Med API-et: POST /_app/api/v1/orgs/<org>/repos/<repo>/active-work/matches/<id>/response med {"response": "split", "continued_by": "<login>"} (findings:write, lesetilgang til repositoryet). GET …/matches/<id> leser én match og svaret på den, og list_active_work returnerer match_id, response og continued_by for hver åpen match.

Bare de to personene som eier arbeidet, kan svare, aldri noen på deres vegne: et token som ikke handler for noen, får no-principal, alle andre not-a-party. Et svar kan endres; det siste teller. Hvert svar registreres i revisjonsloggen som active_work.match.responded, med det forrige svaret og hvor det ble gitt. En agent kan svare for sin person gjennom API-et, eller gjennom MCP-skriveverktøyet answer_active_work_match når personen har samtykket til det og organisasjonen tillater skriving via connectorer. Svaret returnerer previous_response, svaret det erstattet.

Overleveringsnotater

Arbeid skifter hender: en annen person pusher til branchen, åpner pull requesten for den, eller arbeidet stopper rett og slett opp. Active work merker begge deler og holder det den første personen eller agenten visste, sammen med arbeidet.

Når fremforge merker en overlevering:

• Skiftet hender. En push fra en annen enn den som pushet sist, eller en pull request åpnet av en annen enn den som pushet sist. Flere sesjoner fra én person er ikke en overlevering.
• Står stille. En åpen pull request uten push på 7 dager (sjekkes én gang om dagen). Det spørres én gang per periode der arbeidet står stille; neste push gjør kommentaren om til «work resumed».

Pull requesten får da én overleveringskommentar fra fremforge-bot, redigert på stedet og aldri gjentatt:

• hvem som overleverte til hvem, eller siden når arbeidet har stått stille;
• Ferdig: overleveringsnotatet hvis det er skrevet et, ellers emnelinjene i commitene;
• Neste og Open questions fra notatet (eller en Handoff:-linje);
• lenkene til agentsesjonene på arbeidet. En https://claude.ai/code/session_…-lenke vises som lenke; den åpnes bare for personen sesjonen tilhører, slik at de kan fortsette den der. Alle andre jobber ut fra notatene.

Alt i kommentaren vises som ren kode og merkes som data, som overlappskommentaren over. Den følger organisasjonens innstilling pr_comment.

Skriv notatet som en Handoff-seksjon i beskrivelsen av pull requesten (eller i en commit-melding). Dette er blokken du legger til i malen for pull requests (.forgejo/PULL_REQUEST_TEMPLATE.md):

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

Det nyeste notatet vinner: å redigere beskrivelsen erstatter det, og en commit-melding med en Handoff-seksjon erstatter det også. En tom mal er ikke et notat. Notatet sammenlignes ikke som hensikt, så å skrive et gir aldri en advarsel om overlapp. list_active_work og find_related_work returnerer det under written.handoff (done, next, open_questions, hvem som skrev det og hvor), og selve overleveringen som handoff (changed_hands eller idle, from, to, at, resumed).

En linje til 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å hendelsesfeeden

Hver ny match er også en activework.warning-hendelse på hendelsesfeeden, så en agent som allerede følger feeden, får vite om den uten å spørre jevnlig.

Arbeid som står stille: en daglig påminnelse

Agentsesjoner avsluttes og etterlater brancher og utkast til pull requests. Én gang om dagen sender fremforge hver person én e-post med de åpne pull requestene og branchene deres uten push på 14 dager, inkludert arbeidet agentene deres har gjort for dem. For hvert arbeid finnes det tre svar:

Hvert element i e-posten lenker til sin svarside (/_app/settings/work/idle/<id>). Du må være innlogget: bare personen arbeidet tilhører, eller en eier av organisasjonen, kan se eller svare på det, så en videresendt e-post kan ikke lukke noens arbeid. Å åpne lenken endrer ingenting. Eiere av organisasjonen finner også lenken Continue, hand over or close ved siden av arbeid som står stille, på siden Active work. Hvert svar ligger i revisjonsloggen som active_work.idle.continue, active_work.idle.handover eller active_work.idle.close, med personen som ga det.

Hvor sjelden e-posten kommer:

• høyst én e-post per person per dag, aldri én per pull request;
• hvert arbeid får en påminnelse etter 14 dager uten push, én gang til 14 dager senere hvis ingen svarte, og deretter ikke igjen før noen pusher til det;
• en pull request som venter på en forespurt godkjenner, utelates: neste steg er ikke ditt;
• boter (Renovate og andre botkontoer) får aldri påminnelser.

Arbeid som allerede fantes før organisasjonen din slo på Active work, blir også fanget opp, ved den første daglige kjøringen.

Personen kan slå av e-posten under Idle-work nudges i sine varselinnstillinger, eller med lenken for å melde seg av med ett klikk i e-posten. Hvert element i en oppsummering er også en work.idle-hendelse på hendelsesfeeden, så personens egne agenter kan se det.

Lukke pull requests som står stille, automatisk

En eier av organisasjonen kan slå på auto_close. Den er av som standard. En pull request lukkes da automatisk når alt dette gjelder:

• ingen push på auto_close_days (minst 60, standard 90);
• en påminnelse om den har stått ubesvart i minst en uke;
• den har ingen godkjenning, ingen forespurt godkjenner og ingen gjennomgang som ber om endringer.

Branchen beholdes, så hvem som helst kan åpne pull requesten igjen. Personen får beskjed i dagens oppsummering, og pull requesten får en kommentar som forklarer hvorfor. Brancher uten pull request slettes aldri automatisk.

Siden Active work

Eiere av organisasjonen ser alt pågående arbeid under Bygg og utrulling › Active work: ett kort per repository, arbeid gruppert etter område, hver persons agentsesjoner, og hvert mulige duplikat navngitt og lenket med svaret. Bryteren for organisasjonen ligger på samme side.

Hvem som jobber nå (tilstedeværelse)

Arbeid dukker opp her ved første push. Tilstedeværelse viser det tidligere: når en persons AI-assistent jobber i et repository gjennom MCP-serveren (leser filer, pull requests eller Active work der), ser personer som kan lese det repositoryet, at personen jobber der nå.

• Hva som vises: bare brukernavn. «Working here now: alice, bob» på kortet til repositoryet, et kort for repositoryer der noen jobber og ingenting er pushet ennå, og working_now i list_active_work.
• Hva som beholdes: én oppføring per person og repository, overskrevet ved hvert kall og borte 60 minutter etter personens siste kall. Ingen historikk, ingen tellinger, og ingen tidspunkter vises. Tilstedeværelse er ikke et mål på noens aktivitet.
• Bare et kall som virket, teller: å nevne et repository personen ikke kan lese, registrerer ingenting, og et API-token som ikke handler for noen person, teller aldri.
• Hvem som ser det: personer som kan lese repositoryet: organisasjonens eiere og revisorer på siden Active work, og alle med lesetilgang gjennom list_active_work.
• Slå det av: en eier av organisasjonen med innstillingen Vis hvem som jobber i et repository nå på denne siden (eller presence: false i innstillings-API-et); hver person for seg selv med Vis at jeg jobber i sine varselinnstillinger. Begge sletter tilstedeværelsen med en gang.

Status: tilgjengelig for alle organisasjoner. En organisasjon der Active work er av, som er standard, registrerer og viser ingen tilstedeværelse.

Et utkast til pull request ved første push

Arbeid sammenlignes fra første push, men en branch uten pull request er lett å overse. Med Draft pull request on the first push slått på åpner fremforge, når noen pusher en ny branch, med en gang et utkast til pull request for den, som den personen: arbeidet er synlig i forgen, på siden Active work og for alles agenter før noen andre begynner på det samme.

• På som standard for organisasjoner opprettet 12. november 2026 eller senere, av for eldre. En eier av organisasjonen slår den på eller av under Bygg og utrulling › Active work (eller auto_draft_pr i innstillings-API-et). Hver person kan fortsatt slå den av for seg selv under Draft pull request on my first push i sine varselinnstillinger.
• Pull requesten er personens. Den åpnes i personens navn med en WIP:-tittel, emnelinjen i den første commiten og en kort beskrivelse av hvordan dette slås av. Den forblir et utkast, så den kan ikke merges før personen fjerner WIP: og merker den som klar. Ingenting blir noen gang merget eller klargjort til merge for dem.
• CI-en venter til den er klar. Så lenge tittelen starter med WIP:, kjører ikke utkastets pull_request-workflower, så et utkast koster ingen runner-minutter. Når personen merker det som klart (fjerner WIP: i nettgrensesnittet, ved å redigere tittelen eller gjennom API-et), kjører sjekkene for den gjeldende head-commiten, så de påkrevde sjekkene alltid finnes før den kan merges. For å kjøre dem tidligere trykker hvem som helst med skrivetilgang Kjør sjekker på pull requesten (eller kaller POST /api/v1/repos/{owner}/{repo}/pulls/{index}/fremforge/run-checks): én gang per head-commit, og en forespørsel nummer to for samme commit svarer 409. Push-workflower, og fremforges egne skanninger av pull requests (secrets, lisenser, sikkerhet), kjører som vanlig. Bare utkastene fremforge åpner, berøres: Forgejo registrerer det når utkastet åpnes gjennom den ene plattformkontoen som kan åpne dem, og ingenting som skrives i en tittel eller beskrivelse, kan gjøre en pull request til et slikt utkast eller omvendt. En pull request du selv merker med WIP:, kjører CI som før, og det samme gjør enhver pull request fra en fork. Når sjekkene kjører ved klar eller Kjør sjekker, kjører de som personen utkastet tilhører, så godkjenningsreglene gjelder for den personen, ikke for den som trykket på knappen.
• Bare personens egen nye branch, én gang. En push til en eksisterende branch, en branch som allerede har en pull request, boter, deploy-nøkler og Forgejo Actions får aldri et utkast. Høyst 10 i minuttet per organisasjon på hver API-instans.
• Hvordan det gjøres, og hva som begrenser det. fremforge åpner pull requesten gjennom Forgejos Sudo-mekanisme med én dedikert plattformkonto der tokenet ikke kan gjøre noe annet: scopet write:fremforge-draft-pr lar den åpne et utkast for pågående arbeid fra en branch i samme repository, som en aktiv person med skrivetilgang, og alle andre forespørsler med det avvises av Forgejo selv. Hvert utkast registreres i revisjonsloggen som active_work.draft_pr.opened, med personen som aktør.

Spør før du starter: verktøy for agenter

Agenter gjør Active work bedre, men er aldri påkrevd. En Handoff:-linje i en commit-melding eller i beskrivelsen av en pull request beholdes sammen med arbeidet som et notat til neste person eller sesjon (se Overleveringsnotater). Tre verktøy med bare lesetilgang, tilgjengelige i fremforges MCP-server og som REST-endepunkter, lar en agent sjekke før den starter:

list_active_work returnerer også working_now: brukernavnene til personer som jobber i repositoryet nå (se tilstedeværelse).

Alle tre krever findings:read og lesetilgang til repositoryet. Tekst som personer og agenter har skrevet (titler, branchnavn, hensikt, emnelinjer i commits, sesjonsdetaljer, overleveringsnotater), returneres bare inne i et written-objekt, med written_by og at ved siden av, og hvert svar har en merknad om at det er data, aldri instruksjoner.

Meld det før du pusher. I konsollen ber Bygg og utrulling › Active work › Start arbeid (eller /_app/settings/active-work/start) om repositoryet, en tittel og eventuelt hensikten, områdene og branchen, og viser deretter branchen du skal opprette og eventuelt arbeid som ser relatert ut. 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

Ingenting reserveres og ingenting blokkeres: å melde arbeid gjør det bare synlig tidligere. Fra en agent registrerer start_work (POST /_app/api/v1/orgs/<org>/repos/<repo>/active-work/start, findings:write og skrivetilgang til repositoryet) arbeidet ditt før noe er pushet: en title, din intent, og eventuelt areas og branch. Uten en branch foreslår den en, for eksempel alice/rate-limit-the-login-api. Arbeidet sammenlignes med en gang, så alle som allerede holder på med det samme, får beskjed etter organisasjonens innstillinger, og svaret lister det relaterte arbeidet. Push til branchen den oppgir: den første pushen oppdaterer det samme elementet. Noen andres pågående arbeid på den branchen avvises (409). Gjennom MCP er start_work et skriveverktøy: connectoren din trenger samtykket ditt til det, og organisasjonen må tillate skriving via connectorer.

En linje til 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 som kan se det

Kommentaren på pull requesten nevner bare arbeid i samme repository, så den viser annet arbeid bare til personer som allerede kan lese det repositoryet. En match på tvers av repositoryer vises bare for personer som kan lese begge. Private repositoryer forblir private innenfor organisasjonen.

Slå den på

Eiere av organisasjonen slår på Active work for organisasjonen 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}'

Å lese innstillingene krever policy:read, å endre dem policy:write. Hver endring registreres i revisjonsloggen som active_work.settings.updated, med personen som gjorde den.

Dine egne brytere

Hver person har tre egne brytere, i sine varselinnstillinger 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}}}'

Disse er personlige, så de krever en legitimasjon som bærer identiteten din: tokenet fra fremforge auth login, benchen din eller en AI-connector (bare lesing, som verktøyet get_my_settings). Et API-token for en organisasjon avvises med user-identity-required. Lesing krever orgs:read, endring orgs:write. Bare organisasjoner du er medlem av nå, listes eller kan endres (navn matches uten hensyn til store og små bokstaver), og en AI-connector ser ikke organisasjoner der eierne har blokkert AI-connectorer. Hver endring registreres i revisjonsloggen til den organisasjonen som notifications.preference.self_updated, med deg som aktør.

Les alle innstillingene på én gang

GET /_app/api/v1/orgs/<org>/settings (orgs:read), og også MCP-verktøyet get_org_settings med bare lesetilgang, returnerer organisasjonens innstillinger for flytkontroll og AI i ett svar. Hva det viser, avhenger av hvem som spør:

• Medlemmer ser det som gjelder deres eget arbeid: bryterne for Active work, hvilke brancher som har merge-stopp (bare i repositoryer de kan lese), og om AI-connectorer kan lese eller handle.
• Eiere og revisorer ser i tillegg innstillingene for utgivelsestog, risikonivåer og CI som løper løpsk, alle innstillingene for Active work, og hver AI-funksjon med modellen og navnet på og leverandøren bak provideren.

Det returnerer aldri en leverandørnøkkel, et nøkkelfingeravtrykk, en endepunktadresse, et tillegg til prompten eller et token. Det finnes ingen skriveversjon, verken i API-et eller i MCP.

Måle det

GET /_app/api/v1/orgs/<org>/active-work/metrics?days=30 (policy:read) returnerer bare antall og varigheter, aldri teksten i noens arbeid:

• matches og matches_both_notified;
• notify_seconds_p50 og notify_seconds_p90: tiden fra den andre personens første push til begge personene har fått se matchen (målet er under 5 minutter);
• false_positive_rate: andelen besvarte matcher merket «different»;
• dismissed_share_of_notified: matcher besvart med «different» av alle matcher begge personene har fått se, besvart eller ikke (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ålet for de siste 30 dagene.

Se API-referansen for de fullstendige skjemaene.