wehub/diegosouzapw--omniroute
1
0
Fork 0
Code Issues Pull Requests Actions Deployments Models Agent Notes Packages Projects Releases Wiki Activity
Files
main
diegosouzapw--omniroute/docs/i18n/no/CLAUDE.md
T
wehub-resource-sync d8dcd5f6d1 chore: import upstream snapshot with attribution
2026-07-13 13:39:12 +08:00

26 KiB
Raw Permalink Blame History

CLAUDE.md (Norsk)

🌐 Languages: 🇺🇸 English · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇪🇸 es · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇳 gu · 🇮🇱 he · 🇮🇳 hi · 🇭🇺 hu · 🇮🇩 id · 🇮🇩 in · 🇮🇹 it · 🇯🇵 ja · 🇰🇷 ko · 🇮🇳 mr · 🇲🇾 ms · 🇳🇱 nl · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇸🇰 sk · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇻🇳 vi · 🇨🇳 zh-CN

Denne filen gir veiledning til Claude Code (claude.ai/code) når du arbeider med kode i dette depotet.

Rask start

npm install                    # Installer avhengigheter (genererer automatisk .env fra .env.example)
npm run dev                    # Utviklingsserver på http://localhost:20128
npm run build                  # Produksjonsbygg (Next.js 16 standalone)
npm run lint                   # ESLint (0 feil forventet; advarsler er eksisterende)
npm run typecheck:core         # TypeScript-sjekk (bør være ren)
npm run typecheck:noimplicit:core  # Streng sjekk (ingen implicit any)
npm run test:coverage          # Enhetstester + dekning (75/75/75/70 — utsagn/linjer/funksjoner/grener)
npm run check                  # lint + test kombinert
npm run check:cycles           # Oppdag sirkulære avhengigheter

Kjøring av tester

# Enkel testfil (Node.js innebygd testkjører — de fleste tester)
node --import tsx/esm --test tests/unit/your-file.test.ts

# Vitest (MCP-server, autoCombo, cache)
npm run test:vitest

# Alle suite
npm run test:all

For full testmatrise, se CONTRIBUTING.md → "Kjøring av tester". For dyp arkitektur, se AGENTS.md.

Prosjektet i et nøtteskall

OmniRoute — enhetlig AI proxy/ruter. Ett endepunkt, 160+ LLM-leverandører, automatisk fallback.

Lag Sted Formål
API-ruter src/app/api/v1/ Next.js App Router — inngangspunkter
Håndterere open-sse/handlers/ Behandling av forespørsel (chat, embeddings, osv.)
Utøvere open-sse/executors/ Leverandørspesifikk HTTP-dispatch
Oversettere open-sse/translator/ Formatkonvertering (OpenAI↔Claude↔Gemini)
Transformer open-sse/transformer/ Respons API ↔ Chat Fullføringer
Tjenester open-sse/services/ Kombinasjonsruting, hastighetsbegrensninger, caching, osv.
Database src/lib/db/ SQLite domene moduler (45+ filer, 55 migrasjoner)
Domene/Politikk src/domain/ Politikkmotor, kostnadsregler, fallback-logikk
MCP-server open-sse/mcp-server/ 37 verktøy (30 base + 3 minne + 4 ferdigheter), 3 transport, ~13 omfang
A2A-server src/lib/a2a/ JSON-RPC 2.0 agentprotokoll
Ferdigheter src/lib/skills/ Utvidbar ferdighetsrammeverk
Minne src/lib/memory/ Vedvarende samtaleminne

Monorepo: src/ (Next.js 16 app), open-sse/ (streaming engine arbeidsområde), electron/ (desktop app), tests/, bin/ (CLI inngangspunkt).

Forespørsel Pipeline

Klient → /v1/chat/completions (Next.js rute)
  → CORS → Zod validering → auth? → policy sjekk → prompt injeksjonsbeskyttelse
  → handleChatCore() [open-sse/handlers/chatCore.ts]
    → cache sjekk → rate limit → combo routing?
      → resolveComboTargets() → handleSingleModel() per mål
    → translateRequest() → getExecutor() → executor.execute()
      → fetch() upstream → retry w/ backoff
    → respons oversettelse → SSE strøm eller JSON
    → Hvis Responses API: responsesTransformer.ts TransformStream

API-ruter følger et konsistent mønster: Rute → CORS preflight → Zod body validering → Valgfri auth (extractApiKey/isValidApiKey) → API-nøkkel policy håndheving → Handler delegasjon (open-sse). Ingen global Next.js middleware — avbrudd er rute-spesifikk.

Combo routing (open-sse/services/combo.ts): 14 strategier (prioritet, vektet, fyll-først, rund-robin, P2C, tilfeldig, minst-brukt, kostnadsoptimalisert, reset-bevisst, streng-tilfeldig, auto, lkgp, kontekst-optimalisert, kontekst-rele). Hvert mål kaller handleSingleModel() som omslutter handleChatCore() med per-mål feilhåndtering og kretsbryter sjekker. Se docs/routing/AUTO-COMBO.md for 9-faktor Auto-Combo poengsetting og docs/architecture/RESILIENCE_GUIDE.md for de 3 motstandsdyktighetslagene.

Motstandsdyktighet Kjøretid Tilstand

OmniRoute har tre relaterte, men distinkte mekanismer for midlertidig feil. Hold deres omfang adskilt når du feilsøker rutingadferd. Se den 3-lags motstandsdyktighetsdiagram (kilde: docs/diagrams/resilience-3layers.mmd) for et oversiktskart.

Leverandør Kretsbryter

Omfang: hele leverandøren, f.eks. glm, openai, anthropic.

Formål: stoppe sending av trafikk til en leverandør som gjentatte ganger feiler på upstream/tjenestenivå, slik at en usunn leverandør ikke bremser ned hver forespørsel.

Implementering:

  • Kjerneklasse: src/shared/utils/circuitBreaker.ts
  • Chat gate/utførelsesledninger: src/sse/handlers/chatHelpers.ts, src/sse/handlers/chat.ts
  • Kjøretidsstatus API: src/app/api/monitoring/health/route.ts
  • Delte omslag: open-sse/services/accountFallback.ts
  • Persistert tilstandstabell: domain_circuit_breakers

Stater:

  • CLOSED: normal trafikk er tillatt.
  • OPEN: leverandøren er midlertidig blokkert; innringere får et provider-krets-åpen svar eller combo routing hopper til et annet mål.
  • HALF_OPEN: reset timeout har utløpt; tillat en probe forespørsel. Succes lukker bryteren, feil åpner den igjen.

Standarder (open-sse/config/constants.ts):

  • OAuth-leverandører: terskel 3, reset timeout 60s.
  • API-nøkkel leverandører: terskel 5, reset timeout 30s.
  • Lokale leverandører: terskel 2, reset timeout 15s.

Bare leverandør-nivå feilstater bør utløse leverandørbryteren:

(408, 500, 502, 503, 504);

Ikke utløse hele-leverandørbryteren for normale konto/nøkkel/modellfeil som de fleste 401, 403, eller 429 tilfeller. De tilhører vanligvis tilkoblings cooldown eller modell låsing. En generell API-nøkkel leverandør 403 bør være gjenopprettbar med mindre den er klassifisert som en terminal leverandør/konto feil.

Bryteren bruker lat recovery, ikke en bakgrunnstimer. Når OPEN utløper, leser som getStatus(), canExecute(), og getRetryAfterMs() oppdaterer tilstanden til HALF_OPEN, slik at dashbord og combo kandidatbyggere ikke fortsetter å ekskludere en utløpt leverandør for alltid.

Tilkoblings Cooldown

Omfang: én leverandør tilkobling/konto/nøkkel.

Formål: midlertidig hoppe over en dårlig nøkkel/konto mens andre tilkoblinger for den samme leverandøren kan fortsette å betjene forespørselene.

Implementering:

  • Skriv/oppdater sti: src/sse/services/auth.ts::markAccountUnavailable()
  • Kontoseleksjon/filtering: src/sse/services/auth.ts::getProviderCredentials...
  • Cooldown beregning: open-sse/services/accountFallback.ts::checkFallbackError()
  • Innstillinger: src/lib/resilience/settings.ts

Viktige felt på leverandørtilkoblinger:

rateLimitedUntil;
testStatus: "unavailable";
lastError;
lastErrorType;
errorCode;
backoffLevel;

Under kontoseleksjon, blir en tilkobling hoppet over mens:

new Date(rateLimitedUntil).getTime() > Date.now();

Cooldowns er også late: når rateLimitedUntil er i fortiden, blir tilkoblingen berettiget igjen. Ved vellykket bruk, clearAccountError() fjerner testStatus, rateLimitedUntil, feilkoder, og backoffLevel.

Standard tilkoblings cooldown oppførsel:

  • OAuth grunn cooldown: 5s.
  • API-nøkkel grunn cooldown: 3s.
  • API-nøkkel 429 bør foretrekke upstream retry hints (Retry-After, reset headers, eller parsebar reset tekst) når tilgjengelig.
  • Gjentatte gjenopprettbare feil bruker eksponentiell backoff:
baseCooldownMs * 2 ** failureIndex;

Anti-thundering-herd beskyttelsen forhindrer samtidige feil på samme tilkobling fra gjentatte ganger å forlenge cooldown eller doble-incrementere backoffLevel.

Terminalstater er ikke cooldowns. banned, expired, og credits_exhausted er ment å forbli utilgjengelige inntil legitimasjon/innstillinger endres eller en operatør tilbakestiller dem. Ikke overskriv terminalstater med midlertidig cooldown tilstand.

Modell Låsing

Omfang: leverandør + tilkobling + modell.

Formål: unngå å deaktivere en hel tilkobling når bare én modell er utilgjengelig eller kvote-limite for den tilkoblingen.

Eksempler:

  • Per-modell kvote leverandører som returnerer 429.
  • Lokale leverandører som returnerer 404 for én manglende modell.
  • Leverandør-spesifikke modus/modell tillatelsesfeil som valgte Grok-moduser.

Modell låsing lever i open-sse/services/accountFallback.ts og lar den samme tilkoblingen fortsette å betjene andre modeller.

Feilsøkingsveiledning

  • Hvis alle nøkler for en leverandør blir hoppet over, inspiser både leverandørbryter tilstand og hver tilkoblings rateLimitedUntil/testStatus.
  • Hvis en leverandør ser ut til å være permanent ekskludert etter resetvinduet, sjekk om koden leser rå state i stedet for å bruke getStatus()/canExecute().
  • Hvis én leverandørnøkkel feiler, men andre bør fungere, foretrekk tilkoblings cooldown over leverandørbryteren.
  • Hvis bare én modell feiler, foretrekk modell låsing over tilkoblings cooldown.
  • Hvis en tilstand skal selv-gjenopprette, bør den ha et fremtidig tidsstempel/reset timeout og en lesevei som oppdaterer utløpt tilstand. Permanente statuser krever manuelle legitimasjon eller konfigurasjonsendringer.

Nøkkelkonvensjoner

Kode Stil

  • 2 mellomrom, semikolon, doble anførselstegn, 100 tegn bredde, es5 trailing commas (håndhevet av lint-staged via Prettier)
  • Imports: ekstern → intern (@/, @omniroute/open-sse) → relativ
  • Navngivning: filer=camelCase/kebab, komponenter=PascalCase, konstanter=UPPER_SNAKE
  • ESLint: no-eval, no-implied-eval, no-new-func = feil overalt; no-explicit-any = advarsel i open-sse/ og tests/
  • TypeScript: strict: false, mål ES2022, modul esnext, oppløsning bundler. Foretrekk eksplisitte typer.

Database

  • Alltid gå gjennom src/lib/db/ domenemoduler — aldri skriv rå SQL i ruter eller håndterere
  • Aldri legg til logikk i src/lib/localDb.ts (re-export lag kun)
  • Aldri barrel-import fra localDb.ts — importer spesifikke db/ moduler i stedet
  • DB singleton: getDbInstance() fra src/lib/db/core.ts (WAL journaling)
  • Migrasjoner: src/lib/db/migrations/ — versjonerte SQL-filer, idempotente, kjør i transaksjoner

Feilhåndtering

  • try/catch med spesifikke feiltyper, logg med pino kontekst
  • Aldri sluk feil i SSE-strømmer — bruk abortsignaler for opprydding
  • Returner riktige HTTP-statuskoder (4xx/5xx)

Sikkerhet

  • Aldri bruk eval(), new Function(), eller implisert eval
  • Valider alle innganger med Zod-skjemaer
  • Krypter legitimasjon i ro (AES-256-GCM)
  • Oppstrøms header denylist: src/shared/constants/upstreamHeaders.ts — hold sanitere, Zod-skjemaer, og enhetstester i samsvar når du redigerer
  • Offentlige oppstrøms legitimasjoner (Gemini/Antigravity/Windsurf-stil OAuth client_id/secret + Firebase Web-nøkler hentet fra offentlige CLI-er): MÅ være innebygd via resolvePublicCred() fra open-sse/utils/publicCreds.ts — aldri som strengliteraler. Se docs/security/PUBLIC_CREDS.md for den obligatoriske malen.
  • Feilrespons (HTTP / SSE / executor / MCP-håndterer): MÅ rutes gjennom buildErrorBody() eller sanitizeErrorMessage() fra open-sse/utils/error.ts — aldri sett rå err.stack eller err.message i en responsbody. Se docs/security/ERROR_SANITIZATION.md.
  • Shell-kommandoer bygget fra variabler: når du kaller exec()/spawn() med et skript som trenger kjøretidsverdier, send dem via env-alternativet (shell-escaped automatisk) — aldri string-interpoler ubetrodde/eksterne stier inn i skriptkroppen. Referanse: src/mitm/cert/install.ts::updateNssDatabases.
  • Sikre-bygge-biblioteker (tldrsec/awesome-secure-defaults): foretrekk Helmet.js, DOMPurify, ssrf-req-filter, safe-regex, Google Tink over tilpassede implementeringer når du legger til nye sikkerhetsfølsomme flater.

Vanlige Modifikasjons Scenarier

Legge til en Ny Leverandør

  1. Registrer i src/shared/constants/providers.ts (Zod-validert ved last)
  2. Legg til executor i open-sse/executors/ hvis tilpasset logikk er nødvendig (utvid BaseExecutor)
  3. Legg til oversetter i open-sse/translator/ hvis ikke-OpenAI format
  4. Legg til OAuth-konfigurasjon i src/lib/oauth/constants/oauth.ts hvis OAuth-basert — hvis den oppstrøms CLI-en leverer en offentlig client_id/secret, innebygg via resolvePublicCred() (se docs/security/PUBLIC_CREDS.md), aldri som en literal
  5. Registrer modeller i open-sse/config/providerRegistry.ts
  6. Skriv tester i tests/unit/ (inkluder publicCreds formassertion hvis du la til en ny innebygd standard)

Legge til en Ny API Rute

  1. Opprett katalog under src/app/api/v1/your-route/
  2. Opprett route.ts med GET/POST håndterere
  3. Følg mønster: CORS → Zod body validering → valgfri autentisering → håndterer delegasjon
  4. Håndterer går i open-sse/handlers/ (importer derfra, ikke inline)
  5. Feilrespons bruker buildErrorBody() / errorResponse() fra open-sse/utils/error.ts (auto-sanitized — aldri sett err.stack eller err.message rått i kroppen). Se docs/security/ERROR_SANITIZATION.md.
  6. Legg til tester — inkludert minst en påstand om at feilresponsene ikke lekker stakkspor (!body.error.message.includes("at /"))

Legge til en Ny DB Modul

  1. Opprett src/lib/db/yourModule.ts — importer getDbInstance fra ./core.ts
  2. Eksporter CRUD-funksjoner for din domenetabell(er)
  3. Legg til migrasjon i src/lib/db/migrations/ hvis nye tabeller er nødvendige
  4. Re-export fra src/lib/localDb.ts (legg til i re-export listen kun)
  5. Skriv tester

Legge til et Nytt MCP Verktøy

  1. Legg til verktøydefinisjon i open-sse/mcp-server/tools/ med Zod inngangsskjema + asynkron håndterer
  2. Registrer i verktøysettet (koblet av createMcpServer())
  3. Tildel til passende omfang
  4. Skriv tester (verktøyinnkalling logget til mcp_audit tabell)

Legge til en Ny A2A Ferdighet

  1. Opprett ferdighet i src/lib/a2a/skills/ (5 eksisterer allerede: smart-routing, quota-management, provider-discovery, cost-analysis, health-report)
  2. Ferdigheten mottar oppgavekontekst (meldinger, metadata) → returnerer strukturert resultat
  3. Registrer i A2A_SKILL_HANDLERS i src/lib/a2a/taskExecution.ts
  4. Eksponer i src/app/.well-known/agent.json/route.ts (Agent Card)
  5. Skriv tester i tests/unit/
  6. Dokumenter i docs/frameworks/A2A-SERVER.md ferdighetstabell

Legge til en Ny Cloud Agent

  1. Opprett agentklasse i src/lib/cloudAgent/agents/ som utvider CloudAgentBase (3 eksisterer allerede: codex-cloud, devin, jules)
  2. Implementer createTask, getStatus, approvePlan, sendMessage, listSources
  3. Registrer i src/lib/cloudAgent/registry.ts
  4. Legg til OAuth/legitimasjonshåndtering hvis nødvendig (src/lib/oauth/providers/)
  5. Tester + dokumenter i docs/frameworks/CLOUD_AGENT.md

Legge til en Ny Guardrail / Eval / Ferdighet / Webhook-hendelse

  • Guardrail: src/lib/guardrails/ → docs: docs/security/GUARDRAILS.md
  • Eval suite: src/lib/evals/ → docs: docs/frameworks/EVALS.md
  • Ferdighet (sandbox): src/lib/skills/ → docs: docs/frameworks/SKILLS.md
  • Webhook-hendelse: src/lib/webhookDispatcher.ts → docs: docs/frameworks/WEBHOOKS.md

Referansedokumentasjon

For enhver ikke-triviell endring, les den tilhørende dybdeanalysen først:

Område Dokument
Repo-navigasjon docs/architecture/REPOSITORY_MAP.md
Arkitektur docs/architecture/ARCHITECTURE.md
Ingeniørreferanse docs/architecture/CODEBASE_DOCUMENTATION.md
Auto-Combo (9-faktor poengsum, 14 strategier) docs/routing/AUTO-COMBO.md
Motstandsdyktighet (3 mekanismer) docs/architecture/RESILIENCE_GUIDE.md
Resonnement replay docs/routing/REASONING_REPLAY.md
Ferdighetsramme docs/frameworks/SKILLS.md
Minne system (FTS5 + Qdrant) docs/frameworks/MEMORY.md
Skyagenter docs/frameworks/CLOUD_AGENT.md
Beskyttelsesrammer (PII / injeksjon / visjon) docs/security/GUARDRAILS.md
Offentlige upstream-legitimasjoner (Gemini/osv.) docs/security/PUBLIC_CREDS.md
Rensing av feilmeldinger docs/security/ERROR_SANITIZATION.md
Evalueringer docs/frameworks/EVALS.md
Overholdelse / revisjon docs/security/COMPLIANCE.md
Webhooks docs/frameworks/WEBHOOKS.md
Autorisasjonspipeline docs/architecture/AUTHZ_GUIDE.md
Stealth (TLS / fingeravtrykk) docs/security/STEALTH_GUIDE.md
Agentprotokoller (A2A / ACP / Sky) docs/frameworks/AGENT_PROTOCOLS_GUIDE.md
MCP-server docs/frameworks/MCP-SERVER.md
A2A-server docs/frameworks/A2A-SERVER.md
API-referanse + OpenAPI docs/reference/API_REFERENCE.md + docs/reference/openapi.yaml
Leverandørkatalog (auto-generert) docs/reference/PROVIDER_REFERENCE.md
Utgivelsesflyt docs/ops/RELEASE_CHECKLIST.md

Testing

Hva Kommando
Enhetstester npm run test:unit
Enkel fil node --import tsx/esm --test tests/unit/file.test.ts
Vitest (MCP, autoCombo) npm run test:vitest
E2E (Playwright) npm run test:e2e
Protokoll E2E (MCP+A2A) npm run test:protocols:e2e
Økosystem npm run test:ecosystem
Dekningsgrense npm run test:coverage (75/75/75/70 — utsagn/linjer/funksjoner/grener)
Dekningsrapport npm run coverage:report

PR-regel: Hvis du endrer produksjonskode i src/, open-sse/, electron/, eller bin/, må du inkludere eller oppdatere tester i samme PR.

Testlagpreferanse: enhet først → integrasjon (multi-modul eller DB-tilstand) → e2e (UI/arbeidsflyt kun). Kode feilreproduksjoner som automatiserte tester før eller sammen med fiksen.

Copilot dekning policy: Når en PR endrer produksjonskode og dekningen er under 75% (utsagn/linjer/funksjoner) eller 70% (grener), rapporter ikke bare — legg til eller oppdater tester, kjør dekningstesten på nytt, og be om bekreftelse. Inkluder kjørte kommandoer, endrede testfiler, og sluttresultatet for dekning i PR-rapporten.

Git Workflow

# Aldri commit direkte til main
git checkout -b feat/your-feature
git commit -m "feat: beskriv endringen din"
git push -u origin feat/your-feature

Grenprefikser: feat/, fix/, refactor/, docs/, test/, chore/

Commit-format (Conventional Commits): feat(db): legg til kretsbryter — omfang: db, sse, oauth, dashboard, api, cli, docker, ci, mcp, a2a, memory, skills

Husky hooks:

  • pre-commit: lint-staged + check-docs-sync + check:any-budget:t11
  • pre-push: npm run test:unit

Miljø

  • Kjøretid: Node.js ≥20.20.2 <21 || ≥22.22.2 <23 || ≥24 <25, ES-moduler
  • TypeScript: 5.9+, mål ES2022, modul esnext, oppløsning bundler
  • Sti-aliaser: @/* → src/, @omniroute/open-sse → open-sse/, @omniroute/open-sse/* → open-sse/*
  • Standardport: 20128 (API + dashboard på samme port)
  • Datakatalog: DATA_DIR miljøvariabel, standard til ~/.omniroute/
  • Nøkkel miljøvariabler: PORT, JWT_SECRET, API_KEY_SECRET, INITIAL_PASSWORD, REQUIRE_API_KEY, APP_LOG_LEVEL
  • Oppsett: cp .env.example .env og deretter generer JWT_SECRET (openssl rand -base64 48) og API_KEY_SECRET (openssl rand -hex 32)

Harde regler

  1. Aldri commit hemmeligheter eller legitimasjon
  2. Aldri legg til logikk i localDb.ts
  3. Aldri bruk eval() / new Function() / implisitt eval
  4. Aldri commit direkte til main
  5. Aldri skriv rå SQL i ruter — bruk src/lib/db/ moduler
  6. Aldri stilltiende sluk feil i SSE-strømmer
  7. Alltid valider innganger med Zod-skjemaer
  8. Alltid inkludere tester når du endrer produksjonskode
  9. Dekningen må forbli ≥75% (utsagn, linjer, funksjoner) / ≥70% (grener). Nåværende målt: ~82%.
  10. Aldri omgå Husky hooks (--no-verify, --no-gpg-sign) uten eksplisitt godkjenning fra operatøren.
  11. Aldri innebygde offentlige upstream OAuth client_id/hemmelighet eller Firebase Web-nøkler som strenglitteraler — gå alltid gjennom resolvePublicCred() (open-sse/utils/publicCreds.ts). Se docs/security/PUBLIC_CREDS.md.
  12. Aldri returner rå err.stack / err.message i HTTP / SSE / executor-responser — alltid rute gjennom buildErrorBody() eller sanitizeErrorMessage() (open-sse/utils/error.ts). Se docs/security/ERROR_SANITIZATION.md.
  13. Aldri strenge-interpolere eksterne stier eller kjøretidsverdier inn i shell-skript som sendes til exec()/spawn() — send via env-alternativet i stedet. Referanse: src/mitm/cert/install.ts::updateNssDatabases.
  14. Aldri avvis en CodeQL / Secret-Scanning varsling uten (a) først å sjekke mønsterdokumentene ovenfor for å se om hjelpen gjelder, og (b) registrere den tekniske begrunnelsen i avvisningskommentaren. Presedens: js/stack-trace-exposure hevet på kallsteder som allerede ruter gjennom sanitizeErrorMessage() er en kjent CodeQL-begrensning (tilpassede sanitizere ikke gjenkjent) — avvis som false positive med referanse til docs/security/ERROR_SANITIZATION.md.
  15. Aldri eksponer ruter som starter barneprosesser (/api/mcp/, /api/cli-tools/runtime/) uten isLocalOnlyPath() klassifisering i src/server/authz/routeGuard.ts. Loopback-håndheving skjer ubetinget før noen autentisering sjekk — lekket JWT via tunnel kan ikke utløse prosessstart. Se docs/security/ROUTE_GUARD_TIERS.md.
  16. Aldri inkluder Co-Authored-By-trailere som krediterer en AI-assistent, LLM eller automatiseringskonto (f.eks. navn som inneholder "Claude", "GPT", "Copilot", "Bot"; e-poster på anthropic.com / openai.com / bot-eide noreply.github.com-adresser). Slike trailere ruter commit-attribusjon til bot-kontoen på GitHub, og skjuler den virkelige forfatteren (diegosouzapw) i PR-historikken. Menneskelige bidragsytere — inkludert upstream PR-forfattere og issue-rapportører som blir portet til OmniRoute — KAN og BØR krediteres med standard Co-authored-by: Name <email>-trailere; upstream-port arbeidsflyter (/port-upstream-features, /port-upstream-issues) avhenger av dette.
Reference in New Issue View Git Blame Copy Permalink