Referanse · Mini-Nils

Det tekniske du trenger

Denne siden forklarer hvor koden bor, hvordan en issue blir til en pull request, hva modellen får lov til å gjøre, og hvor du leter når noe feiler.

SpråkC# på .NET 10.

ModellClaude Code headless via claude -p.

DriftAzure Container Apps, Storage Queue og GitHub Actions secrets.

Fra issue til PR

Det er to kjøremiljøer med en tydelig grense mellom dem: Receiveren tar imot HTTP og legger en melding i kø; workeren gjør det tunge, modellerte arbeidet.

GitHub issue + etikett
        │ webhook (signert med HMAC)
        ▼
Receiver (Container App, minReplicas 1)
        │ kømelding (ikke signert)
        ▼
Storage Queue ── KEDA ──► Worker (Container Apps Job, scale-to-zero)
                              │
                              ├─ klon repo og lag branch
                              ├─ bygg systemprompt og kontekst
                              ├─ kjør claude -p med stage-profil
                              ├─ kjør dotnet build/test utenfor modellen
                              └─ push branch og åpne PR

GitHub venter maks 10 sekunder på svar fra webhooken. Derfor kjører ikke Receiveren Claude eller git. Den sjekker signaturen, legger én melding i køen og svarer med en gang. Under kurset har Receiveren minReplicas: 1, så den svarer raskt uten kaldstart. Workeren skalerer fortsatt til null og kan bruke flere minutter uten at webhooken står åpen.

Bare webhooken er signert. Kømeldingen er ikke signert; det er tilgangen til Storage-kontoen som beskytter køen. Både Receiveren og workeren avviser issues fra andre repoer enn TARGET_REPO.

KEDA og Actions Summary i Lab 2

KEDA er skaleringskomponenten

KEDA betyr Kubernetes Event-driven Autoscaling. I Azure Container Apps overvåker den Storage Queue og starter Container Apps Job når køen har meldinger. minExecutions: 0 gir scale-to-zero, pollingInterval: 30 bestemmer hvor ofte køen sjekkes, og maxExecutions: 3 setter en øvre grense for kjøringer.

Actions Summary viser navnene

Når deployen er ferdig, står verdiene du trenger nederst på workflow-kjøringen i GitHub Actions: Receiver URL, Receiver, Worker job, Issue label, Azure suffix og Resource group. Fila .deploy-outputs.json finnes bare på Actions-runneren, ikke hos deg.

Normal flytWebhooken treffer Receiveren, Receiveren legger én melding i køen, KEDA oppdager meldingen og starter en job execution, og workeren henter meldingen og avslutter. En forsinkelse på opptil polling-intervallet er forventet.

De to repoene

Repo	Innhold	Din jobb
`mini-<navn>`	Agenten, pipeline, prompts, skills, Bicep og deploy-skript.	Du eier og endrer dette.
`novanet/workshop.oslo-live`	Kartet, issuer og koden agenten skal endre.	Du sender PR hit, men endrer ikke `main` direkte.

MålrepoetAgentens eget repo er ikke målet for oppgaven. GH_TOKEN må derfor ha skrivetilgang til novanet/workshop.oslo-live, og workeren jobber bare mot TARGET_REPO.

Koder, nøkler og miljøvariabler

Lokalt trenger du bare .env for --dry-run i Lab 1. Alt Azure bruker, legger du inn som repository secrets og variables i agentrepoet. Kopier .env.example til .env:

Copy-Item .env.example .env

# Du velger navnet
AGENT_NAME=kari

# Du lager tokenet selv
GH_TOKEN=ghp_...

# Trengs ikke for --dry-run. I Azure kommer nøkkelen fra repository secret.
# ANTHROPIC_API_KEY=sk-ant-...

Variabel	Påkrevd	Hva den brukes til	Hvem lager eller leverer den
`AGENT_NAME`	Ja	Den eneste deltaker-identiteten. Brukes på commits, PR-er, logger, Status, Azure-navn og ACR-namespace.	Du velger. 3–12 tegn, små bokstaver, tall og bindestrek, og det må starte med en bokstav, for eksempel `kari`. Etiketten er det samme som navnet, og Azure-navnene avledes av det.
`GH_TOKEN`	Ja	Leser issues lokalt med `--dry-run`. I Azure tildeler workeren issuen, kommenterer, pusher branch og oppretter PR i Oslo Live.	Du lager. Åpne GitHub-siden for klassiske tokens, kryss bare av `public_repo` og velg kort utløp. Du må ha godtatt collaborator-invitasjonen til `novanet/workshop.oslo-live`.
`ANTHROPIC_API_KEY`	Ja	Autoriserer og betaler for Claude Code-kjøringene i workeren.	Kurslederen gir deg den. Hele kurset deler én nøkkel med ett felles kostnadstak på kursets Anthropic-workspace. Claude.ai-abonnement og API-betaling er separate; du skal ikke kjøpe API-kreditt selv.
`WEBHOOK_SECRET`	Ja	Receiveren sjekker HMAC-signaturen på webhooken med denne verdien.	Kurslederen gir deg den. Kurslederen registrerer samme verdi på webhooken din i lunsjen. Ikke lag en egen.
`AZURE_CREDENTIALS`	Ja	Logger GitHub Actions inn i Azure og gir workflowen lov til å deploye ressursene dine.	Kurslederen gir deg den. JSON for en service principal med Contributor på den delte ressursgruppen `rg-agentic-workshop`. Bruk den bare i GitHub Actions, aldri lokalt, og ikke del den videre.
`ANTHROPIC_WORKSPACE_ID`	Standard i zip	Velger workspace når API-nøkkelen ikke er bundet til ett workspace.	Kursets workspace-ID ligger i starter-kitet. Workeren oversetter den til `ANTHROPIC_CUSTOM_HEADERS` med `anthropic-workspace-id`.
Azure-kursverdier	Automatisk	Ressursgruppe, region, felles ACR og pull-identitet for Container Apps.	Automatisk. GitHub Actions bruker kursets faste verdier; du skal ikke sette `RESOURCE_GROUP`, `NAME`, `ACR_NAME` eller `ACR_PULL_IDENTITY_RESOURCE_ID`.
`AGENT_LABEL`	Nei	GitHub-etiketten som starter akkurat din agent.	Automatisk. Workflowen avleder den fra `AGENT_NAME`. Med `kari` blir etiketten `kari`.
`CLAUDE_MODEL`	Nei	Standardmodell for stages som ikke har sin egen `model`.	Valgfri repository variable. I Azure settes den alltid, med `claude-sonnet-5` som standard. Den overstyrer toppnivå `"model"` i `stages.json`, men ikke stages som har egen `model`. I starter-kitet har alle fire stages egen modell.

GitHub Actions-innstillingerDu legger inn alt selv under Settings → Secrets and variables → Actions i agentrepoet. Repository variable: AGENT_NAME (påkrevd), eventuelt CLAUDE_MODEL. Repository secrets: AZURE_CREDENTIALS, GH_TOKEN, ANTHROPIC_API_KEY og WEBHOOK_SECRET (alle påkrevd). Ingen andre variables eller secrets er nødvendige. Kurslederen har et skript, setup-participant-actions.sh, som kan gjøre det samme som en snarvei.

Hva tokenet nårGH_TOKEN har bare public_repo. Det når ikke private repoer, men det når alle offentlige repoer du kan skrive til. Derfor skal det ha kort utløp, og workeren er låst til TARGET_REPO. Tokenet sendes secure fra GitHub Actions til deployen din og skal ikke brukes mot andre repoer.

Slik lager eller får du nøklene

GitHub-token, lag selv: Godta først collaborator-invitasjonen til novanet/workshop.oslo-live. Åpne så GitHub → New personal access token (classic) (alternativt: Settings → Developer settings → Personal access tokens → Tokens (classic) → Generate new token (classic)). Gi tokenet et navn som mini-kari-workshop, velg kort utløpsdato og kryss bare av public_repo. Ikke velg hele repo. Fine-grained funker ikke for collaborators utenfor Novanet-orgen. Trykk Generate token, kopier verdien til .env for Lab 1, og legg den som repository secret GH_TOKEN.
Anthropic-nøkkel, få fra kurslederen: Hele kurset deler én nøkkel med ett felles kostnadstak. Legg den som repository secret ANTHROPIC_API_KEY. Du trenger den ikke lokalt.
Webhook-hemmelighet, få fra kurslederen: Legg den som repository secret WEBHOOK_SECRET. Kurslederen registrerer samme verdi på webhooken din.
Azure-credentials, få fra kurslederen: Legg hele JSON-en som repository secret AZURE_CREDENTIALS. Den gir Contributor på den delte ressursgruppen, så den skal bare brukes av GitHub Actions.

Hvis GitHub-operasjoner feilerLogger workeren addComment eller replaceActorsForAssignable når du ikke har godtatt collaborator-invitasjonen eller tokenet mangler public_repo. Sjekk invitasjonen først. gh auth login og GH_TOKEN er separate innlogginger. I Azure bruker workeren repository secret GH_TOKEN; lokalt bruker --dry-run tokenet i .env.

Hvis Claude-nøkkelen manglerStopper workeren med Mangler eller ikke utfylt: ANTHROPIC_API_KEY, sjekk at repository secret ANTHROPIC_API_KEY er satt, og kjør deployen på nytt. Workeren bruker kursets workspace-ID automatisk. --dry-run trenger ikke nøkkelen.

Behandle disse som passordIkke commit .env, lim nøkler inn i issue eller PR, legg dem i JavaScript, eller send dem i chat. Hvis en nøkkel lekker: si fra med en gang, tilbakekall den i leverandørens portal, og få en ny.

Logg inn i GitHub CLI

gh auth login
gh auth status

gh auth login er innloggingen for din egen GitHub-konto og brukes til å opprette agentrepoet og merke issues. GH_TOKEN er tokenet workeren bruker mot novanet/workshop.oslo-live; de to tilgangene kan være forskjellige. Du trenger ikke Azure CLI. Deployen logger inn i Azure fra GitHub Actions.

Verdier du ikke skal fylle inn selv

GitHub Actions og Bicep lager resten. Workflowen sender repository secrets til Bicep som secure parametere. Du trenger ikke finne eller kopiere disse inn i .env:

Verdi	Hvor den kommer fra	Hva du gjør
`QUEUE_CONNECTION`	Storage-kontoen som Bicep oppretter.	La workflowen og Azure håndtere den.
`MEMORY_CONNECTION`	Samme Storage-konto; brukes til bloben `hukommelse/memory.md`.	Ikke legg connection string i repoet.
`QUEUE_NAME`	Settes av Bicep til `agent-tasks`.	Ikke endre den uten å endre både mottak og worker.
`TARGET_REPO`	Settes til `novanet/workshop.oslo-live`.	Receiver og worker avviser issues fra andre repoer. La den stå.
Repository secrets	`GH_TOKEN`, `ANTHROPIC_API_KEY`, `WEBHOOK_SECRET` og `AZURE_CREDENTIALS`.	Du legger dem inn i agentrepoet én gang. Workflowen sender dem secure til deployen; de havner aldri i image eller ACR.
`AGENT_NAME`	Agentidentitet for workflowen.	Sett som repository variable. Lokal deploy er deaktivert.

Mappene som betyr noe

`src/Worker/`

Pipeline.cs er orkestreringen deltakerne implementerer i Lab 1. Repository.cs håndterer klon, branch, commit og PR. ClaudeRunner.cs kjører modellen.

`src/Receiver/`

En liten ASP.NET Core-app som validerer webhooken og skriver til køen. Den har ingen LLM og ingen git.

`agent/`

system.md, conventions.md, prompts, skills, stages og hukommelse styrer modellens oppførsel.

`infra/`

main.bicep beskriver Container Apps, jobben, køen, secure deploy-parametere og miljøvariabler.

GitHub Actions

Logger inn, oppretter deltakerens ressurser, bygger namespacede images i kursets felles ACR og ruller ut den nye revisjonen.

`.env`

Lokale verdier for --dry-run i Lab 1. Filen skal aldri committes eller legges i issue, PR eller logg.

Hva som er kode og hva som er modell

Deterministisk kode

Reservasjon, arbeidsområde, promptbygging, diff-sjekk, bygg/test, commit, push og PR. Disse delene skal gi samme kontroll ved hver kjøring.

Modellens arbeid

Les oppgaven, finn relevant kode, velg en implementasjon og gjør endringer innenfor verktøyprofilen. Modellen avgjør ikke om leveransen er grønn.

Kvalitetsportene

Plan-review må svare PLAN GODKJENT, ellers stopper kjøringen. En tom diff stopper leveransen. Bygg og test kjøres etter modellstegene. Rødt bygg gir PR som utkast, eller ingen PR når stopOnVerifyFailure er true. Auto-merge er av; et menneske merger.

Stages og verktøytilgang

agent/stages.json er arbeidsflytens kontrollpanel. Pipelinen er fire steg + levering: fire modellsteg, og så levering som er kode. Hver stage kan ha egen prompt, modell, verktøyliste, maks antall turer og timeout.

Stage	Typisk tilgang	Hvorfor
Research	`claude-opus-5-5`; `Read`, `Glob`, `Grep`	Forstå oppgaven og skrive en plan uten å endre kode.
Plan-review	`claude-haiku-4-5`; lesing	Finne hull i planen billig; alt annet enn et svar som starter med `PLAN GODKJENT` stopper kjøringen.
Implement	`claude-sonnet-5`; lesing, `Edit`, `Write`, bygg og test	Gjøre endringen etter planen.
Self-review	`claude-sonnet-5`; lesing, diff, Edit og test	Finne og rette feil før leveringen.
Levering	Kode, ikke modell	Bygg, test, commit, push og PR uten modellskjønn.

Toppnivå "model" i stages.json er claude-sonnet-5 og gjelder stages uten egen model. I Azure setter deployen alltid CLAUDE_MODEL (standard claude-sonnet-5), og den overstyrer toppnivå-verdien, men ikke stages med egen modell. Priser per million tokens, input/output: claude-opus-5-5 $4/$20, claude-sonnet-5 $2/$10, claude-haiku-4-5 $1/$5.

Minst mulig tilgang er et teknisk valg. Fjerner du Write, kan agenten fortsatt gjøre mye med Edit. Legger du til et bredt Bash-mønster, øker konsekvensen av en feil instruksjon.

Lokalt og i Azure

	Lokalt	Azure
Trigger	`dotnet run ... --issue 1 --dry-run` (lesende kontroll)	GitHub webhook + etikett
Worker	Terminal/devcontainer, bare lesende kontroll	Container Apps Job
Modell	Starter ikke	`claude -p` med stages fra `stages.json`
Skriver til GitHub	Nei	Tildeler issue, kommenterer, pusher branch og oppretter PR
Hukommelse	Brukes ikke	Bloben `hukommelse/memory.md`
Kjøringsdata	Logg i terminalen	Table Storage `agentRuns`, lest via et sanert statusendepunkt
Hemmeligheter	`.env` med `AGENT_NAME` og `GH_TOKEN`	GitHub repository secrets → secure deploy-parametere
Følge med	Terminalen	Actions Summary, kommentarer fra agenten på issuen og rapporten i PR-en. Jobbloggene i Log Analytics ser kurslederen på.

Vil du bygge en monitoreringsside i Lab 3, kan nettleseren lese det offentlige GitHub API-et for issues og pull requests, og et sanert /status-endepunkt kan lese kjøringsdata fra Table Storage-tabellen agentRuns. Den kan vise statuser, lenker, stager, tid, tokens og kostnad. Azure-tabellen, logger og hemmeligheter skal ikke hentes direkte fra JavaScript; bruk serversidekode eller lenk til Azure-portalen.

Ekstra: mention-modus (eksperimentelt)

Labbene bruker ikke mention-modus. Vil du prøve etter kurset, setter du repository variable AGENT_MENTION til GitHub-loginet som eier GH_TOKEN, uten @. Da registreres webhooken også for PR-kommentarer og review-tråder, og agenten svarer read-only på en PR uten å lage branch eller ny PR.

Noen andre enn deg må skrive mentionen. Agenten ignorerer sitt eget login, og den kommenterer med ditt token.
Bare mentions fra collaborators på repoet teller, ikke fra forks.
I mention-modus får agenten ingen MCP-servere.

Tre kvalitetsporter du må kunne forklare

Issue-status: et kontrollpunkt som stopper arbeid på lukkede issuer; flere agenter kan konkurrere på en åpen issue, og første mergete PR vinner.
Verktøyprofil: et kontrollpunkt som begrenser hva modellen kan lese, skrive og kjøre.
Bygg/test: et kontrollpunkt som avgjør med faktisk kode om resultatet kan leveres.

Modellen er ikke en sikkerhetsgrense aleneIssues og kommentarer er brukerstyrt data. Branch protection, token-rettigheter, verktøyallowlist og deterministiske kvalitetsporter må sammen beskytte leveransen.

Kommandoer du bruker oftest

Alle kommandoene er skrevet for pwsh (PowerShell 7).

# Lokalt
dotnet build --nologo -v quiet
dotnet run --project src/Worker -- --issue 1 --repo novanet/workshop.oslo-live --dry-run

# Deploy: push til main, eller Actions → Build and deploy Mini-Nils → Run workflow
gh run list --workflow deploy-azure.yml --limit 3
gh run watch

# Sjekk at receiveren svarer. URL-en står i Actions Summary.
$ReceiverUrl = 'https://ca-kari-receiver.<noe>.norwayeast.azurecontainerapps.io'
curl.exe -i "$ReceiverUrl/"

# Målrepoet
gh issue edit 22 --repo novanet/workshop.oslo-live --add-label kari
gh issue view 22 --repo novanet/workshop.oslo-live --comments
gh pr list --repo novanet/workshop.oslo-live

--dry-run sjekker issue-status uten å reservere, klone, kommentere eller starte Claude Code. Direkte issue-kjøring uten --dry-run er blokkert i starter-kitet; levering skjer fra Azure etter webhook-triggeren.

Kurslederen kjører Azure CLI når noen trenger jobbloggene. Deltakerne trenger ikke az.

# Kurslederen kjører
az containerapp job execution list -g rg-agentic-workshop -n caj-kari-worker -o table
az containerapp job logs show -g rg-agentic-workshop -n caj-kari-worker --container worker --follow

Når noe feiler

Bygget feiler

Les første egentlige compiler-feil, rett én ting, og kjør dotnet build igjen. Ikke be modellen om å rapportere grønt.

Ingen PR

Se først etter kommentarer fra agenten på issuen. Den skriver hvorfor den stoppet: plan ikke godkjent, tom diff, rødt bygg eller stage-feil. Kom det ingen kommentar, be kurslederen sjekke webhook delivery og jobbloggen. GH_TOKEN trenger public_repo fordi agenten skal tildele issue, kommentere og opprette PR.

Azure-jobben starter ikke

Sjekk at etiketten er riktig, og at Actions Summary viser samme Issue label. KEDA kan bruke opptil polling-intervallet på å oppdage meldingen. Kurslederen kan sjekke webhook delivery, køen og jobbloggen; manglende miljøvariabler står ofte under env: i Bicep.

PR-en er dyr

Les forbrukstabellen i PR-en. Den viser modell, tokens og kostnad per steg. Reduser kontekst, modell eller maxTurns én endring om gangen.