diff --git a/.claude/agent-memory/archgate-developer/MEMORY.md b/.claude/agent-memory/archgate-developer/MEMORY.md index bb476920..8de1cc9a 100644 --- a/.claude/agent-memory/archgate-developer/MEMORY.md +++ b/.claude/agent-memory/archgate-developer/MEMORY.md @@ -52,6 +52,10 @@ Non-enforceable lessons — environment/CI/platform quirks no static rule can re - **macOS `/var` → `/private/var` symlink breaks temp dir path comparisons in tests** — On macOS, `/var` is a symlink to `/private/var`. `mkdtempSync(join(tmpdir(), ...))` returns `/var/folders/...` but `process.cwd()` after `chdir()` resolves the symlink to `/private/var/folders/...`. Tests that compare `tempDir` against paths derived from `process.cwd()` or `findProjectRoot()` will fail. Fix: always wrap `mkdtempSync` with `realpathSync` in test setup: `tempDir = realpathSync(mkdtempSync(join(tmpdir(), "archgate-test-")))`. This normalizes the path upfront. Discovered in v0.38.0/v0.39.0 release builds — PR CI runs on ubuntu-latest only, so macOS-specific issues are invisible until the release workflow. - **Don't test that well-known tools exist on PATH** — Tests like `expect(resolveCommand("bun")).toBe("bun")` assert CI environment state, not application logic. They fail when the runner installs tools via shims (e.g., proto on macOS ARM64 where `Bun.which` returns null). Delete such tests entirely — the "returns null for non-existent command" tests already cover `resolveCommand`'s actual logic, and WSL-specific tests cover the `.exe` fallback path. +## Translation Quality + +- **Norwegian (nb/) diacritical patterns to scan for** — When reviewing or editing `docs/src/content/docs/nb/` translations, scan for three corruption patterns: (1) stripped diacriticals (`monster` for `mønster`, `a` for `å`), (2) ASCII approximations (`aa` for `å`, `oe` for `ø`, `ae` for `æ`), (3) HTML entities (`å` for `å`, `ø` for `ø`, `æ` for `æ`). GEN-002 mandates correct characters but automated rules only check structural i18n (page parity, link prefixes, translation drift) — diacritical correctness requires manual/AI review. Common Norwegian words to watch: må, når, på, også, både, får, bør, før, første, følger, kjører, mønster, nøkkel, verktøy, nødvendig, støtter, foreslår, påvirkning, forårsaker, primær, erklæring, miljø, overføring. + ## Validation Pipeline - `bun run validate` is the mandatory gate: lint → typecheck → format:check → test → ADR check → knip → build:check diff --git a/docs/src/content/docs/nb/examples/clean-architecture-layers.mdx b/docs/src/content/docs/nb/examples/clean-architecture-layers.mdx index b3e3d7d6..3694bba8 100644 --- a/docs/src/content/docs/nb/examples/clean-architecture-layers.mdx +++ b/docs/src/content/docs/nb/examples/clean-architecture-layers.mdx @@ -9,7 +9,7 @@ Krev avhengighetsretning i ren arkitektur -- indre lag må ikke referere til ytr Ren arkitektur krever at avhengigheter peker innover: API -> Application -> Domain. Domain-laget må ha null eksterne avhengigheter, Application-laget må ikke referere til Infrastructure direkte, og ingen lavere lag skal referere til API-prosjektet. Denne regelen sjekker `using`-direktiver (C#) eller `import`-setninger for å håndheve disse grensene. -Det samme monsteret gjelder for enhver lagdelt arkitektur i ethvert språk -- tilpass importmonstrene og lagstiene deretter. +Det samme mønsteret gjelder for enhver lagdelt arkitektur i ethvert språk -- tilpass importmønstrene og lagstiene deretter. ## Eksempler på **feil** kode @@ -109,7 +109,7 @@ export default { } satisfies RuleSet; ``` -For TypeScript-prosjekter, tilpass monstrene: +For TypeScript-prosjekter, tilpass mønstrene: ```typescript // Check that domain/ does not import from infrastructure/ @@ -121,7 +121,7 @@ For TypeScript-prosjekter, tilpass monstrene: ## Når bør du bruke den -Når prosjektet ditt folger ren arkitektur, heksagonal arkitektur, eller en annen lagdelt arkitektur der avhengighetsretning må håndheves. +Når prosjektet ditt følger ren arkitektur, heksagonal arkitektur, eller en annen lagdelt arkitektur der avhengighetsretning må håndheves. ## Når bør du ikke bruke den diff --git a/docs/src/content/docs/nb/examples/common-rule-patterns.mdx b/docs/src/content/docs/nb/examples/common-rule-patterns.mdx index e21007d3..f70ca80b 100644 --- a/docs/src/content/docs/nb/examples/common-rule-patterns.mdx +++ b/docs/src/content/docs/nb/examples/common-rule-patterns.mdx @@ -1,11 +1,11 @@ --- -title: Vanlige regelmonstre -description: "Bruksklare Archgate-regelmonstre for vanlige styringsbehov: avhengighetsstyring, importrestriksjoner, filstruktur, kodekvalitet, databaseskjema og arkitekturgrenser." +title: Vanlige regelmønstre +description: "Bruksklare Archgate-regelmønstre for vanlige styringsbehov: avhengighetsstyring, importrestriksjoner, filstruktur, kodekvalitet, databaseskjema og arkitekturgrenser." sidebar: order: 0 --- -Bla gjennom komplette, kopierbare regeleksempler organisert etter kategori. Hver regelside folger et konsistent format: hva regelen sjekker, eksempler pa feil og riktig kode, den fullstendige `.rules.ts`-implementasjonen, og veiledning om nar du bor bruke den. +Bla gjennom komplette, kopierbare regeleksempler organisert etter kategori. Hver regelside følger et konsistent format: hva regelen sjekker, eksempler på feil og riktig kode, den fullstendige `.rules.ts`-implementasjonen, og veiledning om når du bør bruke den. ## Avhengigheter og pakkestyring @@ -19,8 +19,8 @@ Bla gjennom komplette, kopierbare regeleksempler organisert etter kategori. Hver | Regel | Beskrivelse | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------- | -| [no-banned-imports](/examples/no-banned-imports/) | Forhindre bruk av forbudte biblioteker med en datadrevet monsterliste | -| [no-banned-api](/examples/no-banned-api/) | Forby spesifikke kjoretidens API-er som forårsaker plattform- eller stabilitetsproblemer | +| [no-banned-imports](/examples/no-banned-imports/) | Forhindre bruk av forbudte biblioteker med en datadrevet mønsterliste | +| [no-banned-api](/examples/no-banned-api/) | Forby spesifikke kjøretidens API-er som forårsaker plattform- eller stabilitetsproblemer | | [wrapper-enforcement](/examples/wrapper-enforcement/) | Krev bruk av en prosjektwrapper i stedet for en rå plattform-API | ## Filstruktur og organisering @@ -29,7 +29,7 @@ Bla gjennom komplette, kopierbare regeleksempler organisert etter kategori. Hver | ------------------------------------------------------- | ------------------------------------------------------------------ | | [kebab-case-filenames](/examples/kebab-case-filenames/) | Krev konsistente filnavnkonvensjoner med regex-validering | | [no-barrel-files](/examples/no-barrel-files/) | Oppdag og forby barrel-filer (re-eksport-bare `index.ts`) | -| [test-file-coverage](/examples/test-file-coverage/) | Kontroller at hver kildefil har en tilhorende testfil | +| [test-file-coverage](/examples/test-file-coverage/) | Kontroller at hver kildefil har en tilhørende testfil | | [component-pairing](/examples/component-pairing/) | Krev Connected/presentational-komponentpar med mulighet for unntak | ## Kodekvalitet og output @@ -38,23 +38,23 @@ Bla gjennom komplette, kopierbare regeleksempler organisert etter kategori. Hver | ------------------------------------------------------------------- | -------------------------------------------------------------------- | | [no-todo-comments](/examples/no-todo-comments/) | Flagg TODO-, FIXME-, HACK- og XXX-kommentarer for sammenslåing | | [no-emoji-in-output](/examples/no-emoji-in-output/) | Forby emoji og rå ANSI-koder i CLI-outputstrenger | -| [max-file-length](/examples/max-file-length/) | Advar nar kildefiler overskrider en konfigurerbar linjeantallsgrense | -| [page-component-constraints](/examples/page-component-constraints/) | Krev storrelesgrenser og forby data-henting-hooks i sidekomponenter | +| [max-file-length](/examples/max-file-length/) | Advar når kildefiler overskrider en konfigurerbar linjeantallsgrense | +| [page-component-constraints](/examples/page-component-constraints/) | Krev størrelsesgrenser og forby data-henting-hooks i sidekomponenter | ## Databaseskjema | Regel | Beskrivelse | | --------------------------------------------------------- | --------------------------------------------------------------------------- | -| [database-audit-fields](/examples/database-audit-fields/) | Sorg for at alle tabeller inkluderer `created_at`- og `updated_at`-kolonner | +| [database-audit-fields](/examples/database-audit-fields/) | Sørg for at alle tabeller inkluderer `created_at`- og `updated_at`-kolonner | ## Arkitekturgrenser | Regel | Beskrivelse | | ----------------------------------------------------------------- | ------------------------------------------------------------ | -| [required-export-pattern](/examples/required-export-pattern/) | Kontroller at filer eksporterer en pakrevd funksjonssignatur | -| [openapi-routes](/examples/openapi-routes/) | Sorg for at backend-ruter bruker OpenAPI-typede definisjoner | +| [required-export-pattern](/examples/required-export-pattern/) | Kontroller at filer eksporterer en påkrevd funksjonssignatur | +| [openapi-routes](/examples/openapi-routes/) | Sørg for at backend-ruter bruker OpenAPI-typede definisjoner | | [clean-architecture-layers](/examples/clean-architecture-layers/) | Krev avhengighetsretning i lagdelte arkitekturer | :::tip[La AI-agenter skrive regler for deg] -Editorutvidelsene for [Claude Code](/guides/claude-code-plugin/) og [Cursor](/guides/cursor-integration/) inkluderer en Quality Manager-ferdighet som identifiserer gjentakende monstre i kodebasen din og foreslar nye regler for å handtere dem. [Registrer deg for betatilgang](https://plugins.archgate.dev). +Editorutvidelsene for [Claude Code](/guides/claude-code-plugin/) og [Cursor](/guides/cursor-integration/) inkluderer en Quality Manager-ferdighet som identifiserer gjentakende mønstre i kodebasen din og foreslår nye regler for å håndtere dem. [Registrer deg for betatilgang](https://plugins.archgate.dev). ::: diff --git a/docs/src/content/docs/nb/examples/component-pairing.mdx b/docs/src/content/docs/nb/examples/component-pairing.mdx index 7c111791..9182deef 100644 --- a/docs/src/content/docs/nb/examples/component-pairing.mdx +++ b/docs/src/content/docs/nb/examples/component-pairing.mdx @@ -7,7 +7,7 @@ Krev at tilstandsfulle "Connected"-komponenter har en tilhørende presentasjonsk ## Regeldetaljer -Container/presentational-monsteret skiller datahentende (Connected) komponenter fra rene UI- (presentasjons-) komponenter. Denne regelen sjekker at hver `*Connected.tsx`-fil har en matchende `*.tsx` presentasjonsmotstykke. Den stotter et unntak-direktiv (`// @no-presentational: `) for tilfeller der en Connected-komponent ikke trenger et presentasjonspar. +Container/presentational-mønsteret skiller datahentende (Connected) komponenter fra rene UI- (presentasjons-) komponenter. Denne regelen sjekker at hver `*Connected.tsx`-fil har en matchende `*.tsx` presentasjonsmotstykke. Den støtter et unntak-direktiv (`// @no-presentational: `) for tilfeller der en Connected-komponent ikke trenger et presentasjonspar. ## Eksempler på **feil** kode @@ -75,8 +75,8 @@ export default { ## Når bør du bruke den -Når frontend-arkitekturen din folger container/presentational-monsteret og du vil håndheve at datahentingslogikk alltid er adskilt fra UI-rendering. +Når frontend-arkitekturen din følger container/presentational-mønsteret og du vil håndheve at datahentingslogikk alltid er adskilt fra UI-rendering. ## Når bør du ikke bruke den -Når prosjektet ditt bruker en annen komponentarkitektur (f.eks. kun hooks, eller serverkomponenter), eller når monsteret brukes selektivt i stedet for universelt. +Når prosjektet ditt bruker en annen komponentarkitektur (f.eks. kun hooks, eller serverkomponenter), eller når mønsteret brukes selektivt i stedet for universelt. diff --git a/docs/src/content/docs/nb/examples/database-audit-fields.mdx b/docs/src/content/docs/nb/examples/database-audit-fields.mdx index a808e39b..6d2385d0 100644 --- a/docs/src/content/docs/nb/examples/database-audit-fields.mdx +++ b/docs/src/content/docs/nb/examples/database-audit-fields.mdx @@ -3,11 +3,11 @@ title: database-audit-fields description: Sørg for at alle databasetabeller inkluderer påkrevde revisjonskolonner som created_at og updated_at for sporbarhet. --- -Sorg for at alle databasetabeller inkluderer påkrevde revisjonskolonner. +Sørg for at alle databasetabeller inkluderer påkrevde revisjonskolonner. ## Regeldetaljer -Revisjonsfelt (`created_at`, `updated_at`) er essensielle for feilsoking, datastyring og synkroniseringsprotokoller. Denne regelen analyserer skjemafiler for å finne tabelldefinisjoner, henter ut hver tabells kolonneblokk ved hjelp av klammeparentesdybde-sporing, og sjekker om påkrevde kolonner er til stede. Den fungerer med enhver ORM som definerer tabeller som funksjonsanrop med objektargumenter (Drizzle, Prisma schema-in-code, osv.). +Revisjonsfelt (`created_at`, `updated_at`) er essensielle for feilsøking, datastyring og synkroniseringsprotokoller. Denne regelen analyserer skjemafiler for å finne tabelldefinisjoner, henter ut hver tabells kolonneblokk ved hjelp av klammeparentesdybde-sporing, og sjekker om påkrevde kolonner er til stede. Den fungerer med enhver ORM som definerer tabeller som funksjonsanrop med objektargumenter (Drizzle, Prisma schema-in-code, osv.). ## Eksempler på **feil** kode @@ -102,7 +102,7 @@ export default { ## Når bør du bruke den -Når datamodellen din krever konsistente revisjonsfelt for sporbarhet, feilsoking eller samsvar. Tilpass `TABLE_PATTERN`-regex og kolonnenavn for din ORM: +Når datamodellen din krever konsistente revisjonsfelt for sporbarhet, feilsøking eller samsvar. Tilpass `TABLE_PATTERN`-regex og kolonnenavn for din ORM: ```typescript // For Drizzle with PostgreSQL diff --git a/docs/src/content/docs/nb/examples/kebab-case-filenames.mdx b/docs/src/content/docs/nb/examples/kebab-case-filenames.mdx index aa875a02..785c8bc8 100644 --- a/docs/src/content/docs/nb/examples/kebab-case-filenames.mdx +++ b/docs/src/content/docs/nb/examples/kebab-case-filenames.mdx @@ -7,7 +7,7 @@ Krev konsistente filnavnkonvensjoner på tvers av kildemapper. ## Regeldetaljer -Inkonsistente filnavn (blanding av `camelCase`, `PascalCase`, `snake_case` og `kebab-case`) gjor filer vanskeligere å finne og forårsaker problemer med store/små bokstaver på tvers av operativsystemer. Denne regelen validerer hvert filnavn innenfor omfanget mot et regex-monster og foreslar rettelser. +Inkonsistente filnavn (blanding av `camelCase`, `PascalCase`, `snake_case` og `kebab-case`) gjør filer vanskeligere å finne og forårsaker problemer med store/små bokstaver på tvers av operativsystemer. Denne regelen validerer hvert filnavn innenfor omfanget mot et regex-mønster og foreslår rettelser. ## Eksempler på **feil** kode @@ -64,7 +64,7 @@ export default { ## Når bør du bruke den -Når teamet ditt har standardisert en navnekonvensjon og onsker å håndheve den automatisk. Tilpass regex for din konvensjon: +Når teamet ditt har standardisert en navnekonvensjon og ønsker å håndheve den automatisk. Tilpass regex for din konvensjon: ```typescript // PascalCase (React components) @@ -79,4 +79,4 @@ const SNAKE_CASE = /^[a-z][a-z0-9]*(_[a-z0-9]+)*\.(ts|tsx|js|jsx)$/; ## Når bør du ikke bruke den -Når prosjektet ditt med vilje blander navnekonvensjoner (f.eks. PascalCase for React-komponenter og kebab-case for hjelpefunksjoner), eller når du migrerer en gammel kodebase der masseomdobing ikke er gjennomforbart. +Når prosjektet ditt med vilje blander navnekonvensjoner (f.eks. PascalCase for React-komponenter og kebab-case for hjelpefunksjoner), eller når du migrerer en gammel kodebase der masseomdøping ikke er gjennomførbart. diff --git a/docs/src/content/docs/nb/examples/license-compatibility.mdx b/docs/src/content/docs/nb/examples/license-compatibility.mdx index 186f0865..31c68abf 100644 --- a/docs/src/content/docs/nb/examples/license-compatibility.mdx +++ b/docs/src/content/docs/nb/examples/license-compatibility.mdx @@ -18,7 +18,7 @@ Når du kompilerer eller bundler avhengigheter inn i applikasjonen din, gjelder } ``` -Hvis `readline-sync` bruker GPL-3.0, utloses et brudd selv som devDependency. +Hvis `readline-sync` bruker GPL-3.0, utløses et brudd selv som devDependency. ## Eksempler på **riktig** kode @@ -122,7 +122,7 @@ export default { ## Tilpasning -- **Endre tillatt-listen**: Legg til eller fjern lisensidentifikatorer basert på prosjektets lisens. GPL-prosjekter kan tillate GPL-avhengigheter; Apache-2.0-prosjekter bor blokkere dem. +- **Endre tillatt-listen**: Legg til eller fjern lisensidentifikatorer basert på prosjektets lisens. GPL-prosjekter kan tillate GPL-avhengigheter; Apache-2.0-prosjekter bør blokkere dem. - **Sjekk kun produksjonsavhengigheter**: Fjern `devDependencies` fra `allDeps` hvis du bare bryr deg om bundlet/levert kode. - **Skann transitive avhengigheter**: Bruk `ctx.glob("node_modules/{*,@*/*}/package.json")` for å skanne alle installerte pakker (inkludert scoped) rekursivt, ikke bare direkte avhengigheter. @@ -132,4 +132,4 @@ Når prosjektet ditt bruker en permissiv lisens (MIT, Apache-2.0, ISC, BSD) og d ## Når bør du ikke bruke den -I GPL-lisensierte prosjekter (der copyleft-avhengigheter er kompatible), eller når du har et dedikert lisensskanningsverktoy (FOSSA, Snyk) som allerede beskytter CI-pipelinen din. +I GPL-lisensierte prosjekter (der copyleft-avhengigheter er kompatible), eller når du har et dedikert lisensskanningsverktøy (FOSSA, Snyk) som allerede beskytter CI-pipelinen din. diff --git a/docs/src/content/docs/nb/examples/max-file-length.mdx b/docs/src/content/docs/nb/examples/max-file-length.mdx index 41c0c450..0b858cdd 100644 --- a/docs/src/content/docs/nb/examples/max-file-length.mdx +++ b/docs/src/content/docs/nb/examples/max-file-length.mdx @@ -7,7 +7,7 @@ Advar når kildefiler overskrider en linjeantallsgrense. ## Regeldetaljer -Store filer er vanskeligere å navigere, gjennomgå og teste. Denne regelen teller linjer i hver fil innenfor omfanget og rapporterer en advarsel når antallet overskrider et konfigurerbart maksimum. Bruk av `warning`-alvorlighetsgrad holder CI gronn samtidig som filer som bor refaktoreres blir synliggjort. +Store filer er vanskeligere å navigere, gjennomgå og teste. Denne regelen teller linjer i hver fil innenfor omfanget og rapporterer en advarsel når antallet overskrider et konfigurerbart maksimum. Bruk av `warning`-alvorlighetsgrad holder CI grønn samtidig som filer som bør refaktoreres blir synliggjort. ## Eksempler på **feil** kode @@ -60,7 +60,7 @@ export default { ## Når bør du bruke den -Når du onsker en myk grense mot at filer vokser for store. Juster `MAX_LINES` etter teamets preferanse (200-500 er vanlig). +Når du ønsker en myk grense mot at filer vokser for store. Juster `MAX_LINES` etter teamets preferanse (200-500 er vanlig). ## Når bør du ikke bruke den diff --git a/docs/src/content/docs/nb/examples/no-banned-api.mdx b/docs/src/content/docs/nb/examples/no-banned-api.mdx index 8ab965f1..437fab52 100644 --- a/docs/src/content/docs/nb/examples/no-banned-api.mdx +++ b/docs/src/content/docs/nb/examples/no-banned-api.mdx @@ -9,7 +9,7 @@ Forby spesifikke kjøretids-API-er som forårsaker plattform- eller stabilitetsp Noen API-er fungerer korrekt på en plattform, men feiler på en annen. For eksempel henger Buns shell-API (`Bun.$`) på Windows på grunn av pipe-deadlocks. Denne regelen oppdager flere varianter av en forbudt API -- det direkte kallet, importen og destrukturert bruk -- og sikrer at ingen form slipper gjennom. -Dette monsteret kan generaliseres til enhver API du vil forby mens du tillater et sikkert alternativ. +Dette mønsteret kan generaliseres til enhver API du vil forby mens du tillater et sikkert alternativ. ## Eksempler på **feil** kode @@ -103,7 +103,7 @@ export default { ## Når bør du bruke den -Når prosjektet ditt må kjore på flere plattformer og en spesifikk API er kjent for å feile på en av dem. Også nyttig for å forby utdaterte API-er med kjente stabilitetsproblemer. +Når prosjektet ditt må kjøre på flere plattformer og en spesifikk API er kjent for å feile på en av dem. Også nyttig for å forby utdaterte API-er med kjente stabilitetsproblemer. ## Når bør du ikke bruke den diff --git a/docs/src/content/docs/nb/examples/no-banned-imports.mdx b/docs/src/content/docs/nb/examples/no-banned-imports.mdx index 4618f85c..5b9391e6 100644 --- a/docs/src/content/docs/nb/examples/no-banned-imports.mdx +++ b/docs/src/content/docs/nb/examples/no-banned-imports.mdx @@ -7,7 +7,7 @@ Forhindre bruk av forbudte biblioteker og krev anbefalte alternativer. ## Regeldetaljer -Team forbyr ofte tunge eller utdaterte biblioteker til fordel for lettere eller native alternativer. Denne regelen bruker en datadrevet konfigurasjon -- en array med objekter som spesifiserer regex-monsteret, biblioteknavnet og det anbefalte alternativet. Å legge til et nytt forbud er en endring på en linje. +Team forbyr ofte tunge eller utdaterte biblioteker til fordel for lettere eller native alternativer. Denne regelen bruker en datadrevet konfigurasjon -- en array med objekter som spesifiserer regex-mønsteret, biblioteknavnet og det anbefalte alternativet. Å legge til et nytt forbud er en endring på en linje. ## Eksempler på **feil** kode diff --git a/docs/src/content/docs/nb/examples/no-barrel-files.mdx b/docs/src/content/docs/nb/examples/no-barrel-files.mdx index e7f2bf45..6b25c327 100644 --- a/docs/src/content/docs/nb/examples/no-barrel-files.mdx +++ b/docs/src/content/docs/nb/examples/no-barrel-files.mdx @@ -7,7 +7,7 @@ Oppdag og forby barrel-filer -- `index.ts`-filer som kun inneholder re-eksporter ## Regeldetaljer -Barrel-filer (re-eksport-bare `index.ts`) tilslorer hvor koden faktisk befinner seg, forringer tree-shaking, skaper risiko for sirkulære avhengigheter og gjor IDE-navigasjon tregere. Denne regelen bruker en tilpasset analysefunksjon for å avgjore om en `index.ts`-fil er en ren re-eksport-barrel ved å inspisere hver ikke-kommentar-, ikke-tom linje. +Barrel-filer (re-eksport-bare `index.ts`) tilslører hvor koden faktisk befinner seg, forringer tree-shaking, skaper risiko for sirkulære avhengigheter og gjør IDE-navigasjon tregere. Denne regelen bruker en tilpasset analysefunksjon for å avgjøre om en `index.ts`-fil er en ren re-eksport-barrel ved å inspisere hver ikke-kommentar-, ikke-tom linje. ## Eksempler på **feil** kode @@ -99,7 +99,7 @@ export default { ## Når bør du bruke den -Når du vil kreve direkte importer og unngå omveien som barrel-filer introduserer. Spesielt verdifullt i store kodebaser der barrel-filer forårsaker treg IDE-ytelse og gjor avhengighetsgrafer vanskeligere å forstå. +Når du vil kreve direkte importer og unngå omveien som barrel-filer introduserer. Spesielt verdifullt i store kodebaser der barrel-filer forårsaker treg IDE-ytelse og gjør avhengighetsgrafer vanskeligere å forstå. ## Når bør du ikke bruke den diff --git a/docs/src/content/docs/nb/examples/no-emoji-in-output.mdx b/docs/src/content/docs/nb/examples/no-emoji-in-output.mdx index afacf4e9..1c357ac1 100644 --- a/docs/src/content/docs/nb/examples/no-emoji-in-output.mdx +++ b/docs/src/content/docs/nb/examples/no-emoji-in-output.mdx @@ -1,17 +1,17 @@ --- title: no-emoji-in-output -description: Forby emoji-tegn i CLI-utdata for konsistent visning på tvers av terminaler og tilgjengelighetsverktøy. +description: Forby emoji-tegn i CLI-utdata for konsistent visning på tvers av terminaler og tilgjengelighetsverktøy. --- Forby emoji-tegn i CLI-utdata. ## Regeldetaljer -Emoji vises inkonsekvent på tvers av terminaler, bryter justering i monospace-utdata, og skaper problemer med skjermlesere og CI-loggparsere. Denne regelen bruker Unicode-område-regex for å oppdage emoji-tegn og en sekundær sjekk for å sikre at de forekommer inne i streng-literaler (ikke kommentarer eller variabelnavn). +Emoji vises inkonsekvent på tvers av terminaler, bryter justering i monospace-utdata, og skaper problemer med skjermlesere og CI-loggparsere. Denne regelen bruker Unicode-område-regex for å oppdage emoji-tegn og en sekundær sjekk for å sikre at de forekommer inne i streng-literaler (ikke kommentarer eller variabelnavn). -Regelen sjekker også for rå ANSI-escape-koder, og håndhever bruk av `styleText()` fra `node:util` for terminalformatering. +Regelen sjekker også for rå ANSI-escape-koder, og håndhever bruk av `styleText()` fra `node:util` for terminalformatering. -## Eksempler på **feil** kode +## Eksempler på **feil** kode ```typescript title="src/commands/check.ts" console.log("✅ All checks passed!"); @@ -19,7 +19,7 @@ console.log("❌ Validation failed"); console.log("\x1b[32mSuccess\x1b[0m"); // raw ANSI ``` -## Eksempler på **riktig** kode +## Eksempler på **riktig** kode ```typescript title="src/commands/check.ts" import { styleText } from "node:util"; @@ -90,10 +90,10 @@ export default { } satisfies RuleSet; ``` -## Når du bør bruke den +## Når du bør bruke den -I CLI-verktøy der konsistent utdata på tvers av terminaler er viktig, eller når tilgjengelighet har prioritet. +I CLI-verktøy der konsistent utdata på tvers av terminaler er viktig, eller når tilgjengelighet har prioritet. -## Når du ikke bør bruke den +## Når du ikke bør bruke den -I webapplikasjoner eller verktøy der emoji er en del av det forventede brukergrensesnittet, eller når utdataene alltid konsumeres av mennesker i moderne terminaler. +I webapplikasjoner eller verktøy der emoji er en del av det forventede brukergrensesnittet, eller når utdataene alltid konsumeres av mennesker i moderne terminaler. diff --git a/docs/src/content/docs/nb/examples/no-todo-comments.mdx b/docs/src/content/docs/nb/examples/no-todo-comments.mdx index 920e767a..475322e6 100644 --- a/docs/src/content/docs/nb/examples/no-todo-comments.mdx +++ b/docs/src/content/docs/nb/examples/no-todo-comments.mdx @@ -1,15 +1,15 @@ --- title: no-todo-comments -description: Flagg TODO-, FIXME-, HACK- og XXX-kommentarer for å sikre at de løses før sammenslåing. +description: Flagg TODO-, FIXME-, HACK- og XXX-kommentarer for å sikre at de løses før sammenslåing. --- -Flagg `TODO`-, `FIXME`-, `HACK`- og `XXX`-kommentarer slik at de løses før sammenslåing. +Flagg `TODO`-, `FIXME`-, `HACK`- og `XXX`-kommentarer slik at de løses før sammenslåing. ## Regeldetaljer -TODO-kommentarer er nyttige under utvikling, men bør ikke hope seg opp i hovedgrenen. Denne regelen bruker `ctx.grepFiles` for å skanne alle kildefiler etter vanlige oppgavemarkerings-kommentarer. Den bruker `warning`-alvorlighetsgrad slik at den ikke blokkerer CI, men gjør kommentarene synlige i hver sjekk. +TODO-kommentarer er nyttige under utvikling, men bør ikke hope seg opp i hovedgrenen. Denne regelen bruker `ctx.grepFiles` for å skanne alle kildefiler etter vanlige oppgavemarkerings-kommentarer. Den bruker `warning`-alvorlighetsgrad slik at den ikke blokkerer CI, men gjør kommentarene synlige i hver sjekk. -## Eksempler på **feil** kode +## Eksempler på **feil** kode ```typescript title="src/helpers/git.ts" // TODO: handle merge conflicts @@ -18,7 +18,7 @@ TODO-kommentarer er nyttige under utvikling, men bør ikke hope seg opp i // XXX: revisit this logic ``` -## Eksempler på **riktig** kode +## Eksempler på **riktig** kode ```typescript title="src/helpers/git.ts" // Proper implementation with no deferred work @@ -52,10 +52,10 @@ export default { } satisfies RuleSet; ``` -## Når du bør bruke den +## Når du bør bruke den -Når du ønsker innsikt i utsatt arbeid og vil forhindre at TODO-kommentarer hoper seg opp over tid. Endre alvorlighetsgrad til `"error"` og bruk `ctx.report.violation()` for å gjøre den til en hard blokkering. +Når du ønsker innsikt i utsatt arbeid og vil forhindre at TODO-kommentarer hoper seg opp over tid. Endre alvorlighetsgrad til `"error"` og bruk `ctx.report.violation()` for å gjøre den til en hard blokkering. -## Når du ikke bør bruke den +## Når du ikke bør bruke den -Når TODO-kommentarer er tilsiktet dokumentasjon (f.eks. sporet av et eget verktøy som oppretter saker fra TODO-kommentarer). +Når TODO-kommentarer er tilsiktet dokumentasjon (f.eks. sporet av et eget verktøy som oppretter saker fra TODO-kommentarer). diff --git a/docs/src/content/docs/nb/examples/no-unapproved-deps.mdx b/docs/src/content/docs/nb/examples/no-unapproved-deps.mdx index a2b05e80..3af3eb22 100644 --- a/docs/src/content/docs/nb/examples/no-unapproved-deps.mdx +++ b/docs/src/content/docs/nb/examples/no-unapproved-deps.mdx @@ -1,23 +1,23 @@ --- title: no-unapproved-deps -description: Begrens produksjonsavhengigheter til en godkjent tillatelsesliste for å kontrollere forsyningskjederisiko og avhengighetsoppblåsing. +description: Begrens produksjonsavhengigheter til en godkjent tillatelsesliste for å kontrollere forsyningskjederisiko og avhengighetsoppblåsing. --- Begrens produksjonsavhengigheter til en godkjent tillatelsesliste. ## Regeldetaljer -Store avhengighetstrær øker forsyningskjederisiko og blåser opp pakkestørrelser. Denne regelen leser `package.json` og rapporterer enhver produksjonsavhengighet som ikke står på en eksplisitt tillatelsesliste. Utviklingsavhengigheter sjekkes ikke. +Store avhengighetstrær øker forsyningskjederisiko og blåser opp pakkestørrelser. Denne regelen leser `package.json` og rapporterer enhver produksjonsavhengighet som ikke står på en eksplisitt tillatelsesliste. Utviklingsavhengigheter sjekkes ikke. -## Eksempler på **feil** kode +## Eksempler på **feil** kode ```json title="package.json" { "dependencies": { "zod": "^3.23.0", "chalk": "^5.3.0" } } ``` -Hvis bare `zod` står på den godkjente listen, utløser `chalk` et brudd. +Hvis bare `zod` står på den godkjente listen, utløser `chalk` et brudd. -## Eksempler på **riktig** kode +## Eksempler på **riktig** kode ```json title="package.json" { @@ -26,7 +26,7 @@ Hvis bare `zod` står på den godkjente listen, utløser `chalk` } ``` -Alle produksjonsavhengigheter står på den godkjente listen. Biblioteker som bare trengs ved byggetidspunkt ligger i `devDependencies`. +Alle produksjonsavhengigheter står på den godkjente listen. Biblioteker som bare trengs ved byggetidspunkt ligger i `devDependencies`. ## Regelimplementasjon @@ -68,10 +68,10 @@ export default { } satisfies RuleSet; ``` -## Når du bør bruke den +## Når du bør bruke den -Når teamet ditt har en eksplisitt policy for avhengighetsstyring og ønsker å forhindre at ikke-godkjente pakker havner i produksjonspakken. +Når teamet ditt har en eksplisitt policy for avhengighetsstyring og ønsker å forhindre at ikke-godkjente pakker havner i produksjonspakken. -## Når du ikke bør bruke den +## Når du ikke bør bruke den -I prosjekter i tidlig fase der avhengighetslisten fortsatt utvikles raskt, eller når avhengighetsstyring håndteres av et eget verktøy som Socket eller Snyk. +I prosjekter i tidlig fase der avhengighetslisten fortsatt utvikles raskt, eller når avhengighetsstyring håndteres av et eget verktøy som Socket eller Snyk. diff --git a/docs/src/content/docs/nb/examples/openapi-routes.mdx b/docs/src/content/docs/nb/examples/openapi-routes.mdx index 66cfd222..d8028dd1 100644 --- a/docs/src/content/docs/nb/examples/openapi-routes.mdx +++ b/docs/src/content/docs/nb/examples/openapi-routes.mdx @@ -1,15 +1,15 @@ --- title: openapi-routes -description: Sørg for at alle backend-rutefiler bruker OpenAPI-typede rutedefinisjoner i stedet for rå HTTP-metodebehandlere. +description: Sørg for at alle backend-rutefiler bruker OpenAPI-typede rutedefinisjoner i stedet for rå HTTP-metodebehandlere. --- -Sørg for at alle backend-rutefiler bruker OpenAPI-typede rutedefinisjoner. +Sørg for at alle backend-rutefiler bruker OpenAPI-typede rutedefinisjoner. ## Regeldetaljer -Når et backend-rammeverk støtter OpenAPI-integrasjon (f.eks. `@hono/zod-openapi`), omgår rå HTTP-metodebehandlere (`.get()`, `.post()`) skjemavalidering og dokumentasjonsgenerering. Denne regelen sjekker at rutefiler importerer OpenAPI-integrasjonen og bruker `.openapi()` i stedet for rå metoder. +Når et backend-rammeverk støtter OpenAPI-integrasjon (f.eks. `@hono/zod-openapi`), omgår rå HTTP-metodebehandlere (`.get()`, `.post()`) skjemavalidering og dokumentasjonsgenerering. Denne regelen sjekker at rutefiler importerer OpenAPI-integrasjonen og bruker `.openapi()` i stedet for rå metoder. -## Eksempler på **feil** kode +## Eksempler på **feil** kode ```typescript title="packages/backend/src/routes/users.ts" import { Hono } from "hono"; @@ -22,7 +22,7 @@ app.get("/users", async (c) => { }); ``` -## Eksempler på **riktig** kode +## Eksempler på **riktig** kode ```typescript title="packages/backend/src/routes/users.ts" import { OpenAPIHono, createRoute, z } from "@hono/zod-openapi"; @@ -91,9 +91,9 @@ export default { } satisfies RuleSet; ``` -## Når du bør bruke den +## Når du bør bruke den -Når backend-rammeverket ditt støtter OpenAPI-integrasjon og du vil sikre at alle ruter er dokumentert og skjemavalidert. Tilpass importmønsteret og metodedeteksjonen for ditt rammeverk: +Når backend-rammeverket ditt støtter OpenAPI-integrasjon og du vil sikre at alle ruter er dokumentert og skjemavalidert. Tilpass importmønsteret og metodedeteksjonen for ditt rammeverk: ```typescript // For Express with express-openapi-validator @@ -103,6 +103,6 @@ Når backend-rammeverket ditt støtter OpenAPI-integrasjon og du vil /from\s+["']@fastify\/swagger["']/ ``` -## Når du ikke bør bruke den +## Når du ikke bør bruke den -Når ikke alle ruter krever OpenAPI-dokumentasjon (f.eks. interne helsesjekker, metrikk-endepunkter), eller når OpenAPI-spesifikasjoner vedlikeholdes separat fra rutekoden. +Når ikke alle ruter krever OpenAPI-dokumentasjon (f.eks. interne helsesjekker, metrikk-endepunkter), eller når OpenAPI-spesifikasjoner vedlikeholdes separat fra rutekoden. diff --git a/docs/src/content/docs/nb/examples/page-component-constraints.mdx b/docs/src/content/docs/nb/examples/page-component-constraints.mdx index 04062a6c..dfba40ab 100644 --- a/docs/src/content/docs/nb/examples/page-component-constraints.mdx +++ b/docs/src/content/docs/nb/examples/page-component-constraints.mdx @@ -1,18 +1,18 @@ --- title: page-component-constraints -description: Håndhev at sidekomponenter er tynne layout-innpakninger ved å begrense størrelsen og forby datahentings-hooks. +description: Håndhev at sidekomponenter er tynne layout-innpakninger ved å begrense størrelsen og forby datahentings-hooks. --- -Håndhev at sidekomponenter er tynne layout-innpakninger -- små i størrelse og fri for datahentingslogikk. +Håndhev at sidekomponenter er tynne layout-innpakninger -- små i størrelse og fri for datahentingslogikk. ## Regeldetaljer -I frontend-arkitekturer som skiller ruting fra logikk, bør sidekomponenter bare sette sammen layout og delegere datahenting til Connected-komponenter. Denne regelen håndhever to begrensninger i en enkelt regelfil: +I frontend-arkitekturer som skiller ruting fra logikk, bør sidekomponenter bare sette sammen layout og delegere datahenting til Connected-komponenter. Denne regelen håndhever to begrensninger i en enkelt regelfil: -1. **Størrelsesgrense** -- Sidekomponenter må holde seg under et konfigurerbart linjetall (standard: 75 linjer). -2. **Ingen data-hooks** -- Sidekomponenter må ikke bruke `useState`, `useQuery`, `useMutation` eller andre datahentings-hooks direkte. +1. **Størrelsesgrense** -- Sidekomponenter må holde seg under et konfigurerbart linjetall (standard: 75 linjer). +2. **Ingen data-hooks** -- Sidekomponenter må ikke bruke `useState`, `useQuery`, `useMutation` eller andre datahentings-hooks direkte. -## Eksempler på **feil** kode +## Eksempler på **feil** kode ```tsx title="src/pages/DashboardPage.tsx" import { useQuery } from "@tanstack/react-query"; @@ -25,7 +25,7 @@ export default function DashboardPage() { } ``` -## Eksempler på **riktig** kode +## Eksempler på **riktig** kode ```tsx title="src/pages/DashboardPage.tsx" import { DashboardConnected } from "../components/DashboardConnected"; @@ -108,10 +108,10 @@ export default { } satisfies RuleSet; ``` -## Når du bør bruke den +## Når du bør bruke den -Når frontend-arkitekturen din følger page/container/presentational-mønsteret og du vil håndheve at sider forblir tynne rutingsendepunkter. Juster `PAGE_MAX_LINES` og hook-listene for ditt rammeverk. +Når frontend-arkitekturen din følger page/container/presentational-mønsteret og du vil håndheve at sider forblir tynne rutingsendepunkter. Juster `PAGE_MAX_LINES` og hook-listene for ditt rammeverk. -## Når du ikke bør bruke den +## Når du ikke bør bruke den -Når sider forventes å inneholde logikk (f.eks. i Next.js server-komponenter der datahenting i siden er idiomatisk), eller når prosjektet ditt ikke følger dette arkitekturmønsteret. +Når sider forventes å inneholde logikk (f.eks. i Next.js server-komponenter der datahenting i siden er idiomatisk), eller når prosjektet ditt ikke følger dette arkitekturmønsteret. diff --git a/docs/src/content/docs/nb/examples/required-export-pattern.mdx b/docs/src/content/docs/nb/examples/required-export-pattern.mdx index c807c6e2..53aebe54 100644 --- a/docs/src/content/docs/nb/examples/required-export-pattern.mdx +++ b/docs/src/content/docs/nb/examples/required-export-pattern.mdx @@ -1,15 +1,15 @@ --- title: required-export-pattern -description: Verifiser at filer i en spesifikk mappe eksporterer en påkrevd funksjonssignatur for å håndheve konsistent modulstruktur. +description: Verifiser at filer i en spesifikk mappe eksporterer en påkrevd funksjonssignatur for å håndheve konsistent modulstruktur. --- -Verifiser at filer i en spesifikk mappe eksporterer en påkrevd funksjonssignatur. +Verifiser at filer i en spesifikk mappe eksporterer en påkrevd funksjonssignatur. ## Regeldetaljer -Konvensjonsbaserte arkitekturer (CLI-kommandofiler, rutebehandlere, pluginmoduler) krever ofte at hver fil eksporterer en funksjon med et spesifikt navnemønster. Denne regelen skanner omfangsfiler etter en påkrevd eksport og rapporterer enhver fil som ikke samsvarer. Den bruker `Promise.all()` for å sjekke filer parallelt for ytelse. +Konvensjonsbaserte arkitekturer (CLI-kommandofiler, rutebehandlere, pluginmoduler) krever ofte at hver fil eksporterer en funksjon med et spesifikt navnemønster. Denne regelen skanner omfangsfiler etter en påkrevd eksport og rapporterer enhver fil som ikke samsvarer. Den bruker `Promise.all()` for å sjekke filer parallelt for ytelse. -## Eksempler på **feil** kode +## Eksempler på **feil** kode ```typescript title="src/commands/deploy.ts" // Missing the required register*Command export @@ -18,7 +18,7 @@ export function deploy() { } ``` -## Eksempler på **riktig** kode +## Eksempler på **riktig** kode ```typescript title="src/commands/deploy.ts" import type { Command } from "commander"; @@ -60,7 +60,7 @@ export default { } satisfies RuleSet; ``` -Tilpass mønsteret for andre konvensjoner: +Tilpass mønsteret for andre konvensjoner: ```typescript // Express/Hono route handlers @@ -73,10 +73,10 @@ Tilpass mønsteret for andre konvensjoner: /export\s+const\s+plugin\s*[:=]/ ``` -## Når du bør bruke den +## Når du bør bruke den -Når arkitekturen din krever et spesifikt eksportmønster fra filer i en mappe. Kombiner denne med ADR-ens `files`-frontmatter-felt for å avgrense den til riktig mappe. +Når arkitekturen din krever et spesifikt eksportmønster fra filer i en mappe. Kombiner denne med ADR-ens `files`-frontmatter-felt for å avgrense den til riktig mappe. -## Når du ikke bør bruke den +## Når du ikke bør bruke den -Når mappen inneholder blandede filtyper som ikke alle trenger å følge det samme eksportmønsteret. +Når mappen inneholder blandede filtyper som ikke alle trenger å følge det samme eksportmønsteret. diff --git a/docs/src/content/docs/nb/examples/spdx-license-headers.mdx b/docs/src/content/docs/nb/examples/spdx-license-headers.mdx index 9d5f2262..1f95496a 100644 --- a/docs/src/content/docs/nb/examples/spdx-license-headers.mdx +++ b/docs/src/content/docs/nb/examples/spdx-license-headers.mdx @@ -1,15 +1,15 @@ --- title: spdx-license-headers -description: Håndhev SPDX-License-Identifier-hoder i alle kildefiler for lisensklarhet per fil og kompatibilitet med samsvarsskannere. +description: Håndhev SPDX-License-Identifier-hoder i alle kildefiler for lisensklarhet per fil og kompatibilitet med samsvarsskannere. --- -Sørg for at hver kildefil deklarerer lisensen sin med en maskinlesbar SPDX-identifikator. +Sørg for at hver kildefil deklarerer lisensen sin med en maskinlesbar SPDX-identifikator. ## Regeldetaljer -Åpen kildekode-prosjekter drar nytte av lisensdeklarasjoner per fil -- de overlever filutpakking, bunting og kopier-og-lim-scenarier der rot-LICENSE-filen ikke er til stede. Denne regelen verifiserer at hver TypeScript-kildefil starter med standard SPDX-hodekommentar. +Åpen kildekode-prosjekter drar nytte av lisensdeklarasjoner per fil -- de overlever filutpakking, bunting og kopier-og-lim-scenarier der rot-LICENSE-filen ikke er til stede. Denne regelen verifiserer at hver TypeScript-kildefil starter med standard SPDX-hodekommentar. -## Eksempler på **feil** kode +## Eksempler på **feil** kode ```typescript title="src/helpers/utils.ts" import { join } from "node:path"; @@ -21,7 +21,7 @@ export function resolvePath(base: string, rel: string): string { Filen mangler SPDX-lisensidentifikator-hodet. -## Eksempler på **riktig** kode +## Eksempler på **riktig** kode ```typescript title="src/helpers/utils.ts" // SPDX-License-Identifier: Apache-2.0 @@ -87,13 +87,13 @@ export default { ## Tilpasning - **Endre lisensen**: Erstatt `Apache-2.0` med prosjektets SPDX-identifikator (f.eks. `MIT`, `BSD-3-Clause`) -- **Endre omfanget**: Juster `files`-glob-en i ADR-frontmatteren for å samsvare med kildekatalogene dine -- **Legg til opphavsrettssjekk**: Utvid regelen til også å verifisere opphavsrettslinje-formatet +- **Endre omfanget**: Juster `files`-glob-en i ADR-frontmatteren for å samsvare med kildekatalogene dine +- **Legg til opphavsrettssjekk**: Utvid regelen til også å verifisere opphavsrettslinje-formatet -## Når du bør bruke den +## Når du bør bruke den -Når prosjektet ditt er åpen kildekode og du ønsker entydige lisensdeklarasjoner per fil som gjenkjennes av samsvarsskannere (FOSSA, Snyk, Black Duck, npm license-checker). +Når prosjektet ditt er åpen kildekode og du ønsker entydige lisensdeklarasjoner per fil som gjenkjennes av samsvarsskannere (FOSSA, Snyk, Black Duck, npm license-checker). -## Når du ikke bør bruke den +## Når du ikke bør bruke den -I proprietære/lukkede prosjekter der alle filer implisitt er "alle rettigheter forbeholdt", eller når organisasjonen din bruker en annen lisensdeklarasjonsmekanisme som REUSE 3.0 `.dep5`-filer. +I proprietære/lukkede prosjekter der alle filer implisitt er "alle rettigheter forbeholdt", eller når organisasjonen din bruker en annen lisensdeklarasjonsmekanisme som REUSE 3.0 `.dep5`-filer. diff --git a/docs/src/content/docs/nb/examples/test-file-coverage.mdx b/docs/src/content/docs/nb/examples/test-file-coverage.mdx index dc41158d..2de98e85 100644 --- a/docs/src/content/docs/nb/examples/test-file-coverage.mdx +++ b/docs/src/content/docs/nb/examples/test-file-coverage.mdx @@ -1,15 +1,15 @@ --- title: test-file-coverage -description: Verifiser at hver kildefil har en tilhørende testfil for å forhindre at utestet kode blir sammenslått. +description: Verifiser at hver kildefil har en tilhørende testfil for å forhindre at utestet kode blir sammenslått. --- -Verifiser at hver kildefil har en tilhørende testfil. +Verifiser at hver kildefil har en tilhørende testfil. ## Regeldetaljer -Utestet kode er en risiko. Denne regelen håndhever en strukturell konvensjon: for hver fil i `src/` må en matchende `.test.ts`-fil finnes i `tests/`. Den bruker `ctx.glob` for å oppdage eksisterende testfiler, bygger et oppslagssett for rask matching, og rapporterer enhver kildefil uten en motpart. +Utestet kode er en risiko. Denne regelen håndhever en strukturell konvensjon: for hver fil i `src/` må en matchende `.test.ts`-fil finnes i `tests/`. Den bruker `ctx.glob` for å oppdage eksisterende testfiler, bygger et oppslagssett for rask matching, og rapporterer enhver kildefil uten en motpart. -## Eksempler på **feil** kode +## Eksempler på **feil** kode ``` src/ @@ -21,7 +21,7 @@ tests/ log.test.ts ``` -## Eksempler på **riktig** kode +## Eksempler på **riktig** kode ``` src/ @@ -66,17 +66,17 @@ export default { } satisfies RuleSet; ``` -For å tilpasse til prosjekter som plasserer tester ved siden av kildefilene: +For å tilpasse til prosjekter som plasserer tester ved siden av kildefilene: ```typescript const testPath = rel.replace(/\.ts$/, ".test.ts"); // src/helpers/log.ts → src/helpers/log.test.ts ``` -## Når du bør bruke den +## Når du bør bruke den -Når teamet ditt følger en konvensjon om at hver kildemodul må ha en tilhørende testfil, og du ønsker å fange opp manglende tester under kodegjennomgang. +Når teamet ditt følger en konvensjon om at hver kildemodul må ha en tilhørende testfil, og du ønsker å fange opp manglende tester under kodegjennomgang. -## Når du ikke bør bruke den +## Når du ikke bør bruke den -Når testdekning spores på andre måter (f.eks. dekningsgrenser i CI), eller når noen kildefiler genuint ikke trenger tester (kun-type-filer, konstanter). +Når testdekning spores på andre måter (f.eks. dekningsgrenser i CI), eller når noen kildefiler genuint ikke trenger tester (kun-type-filer, konstanter). diff --git a/docs/src/content/docs/nb/examples/version-catalog.mdx b/docs/src/content/docs/nb/examples/version-catalog.mdx index 154edfdb..d165ce38 100644 --- a/docs/src/content/docs/nb/examples/version-catalog.mdx +++ b/docs/src/content/docs/nb/examples/version-catalog.mdx @@ -1,25 +1,25 @@ --- title: version-catalog -description: Håndhev sentralisert versjonsadministrasjon i monorepoer ved å kreve catalog- eller workspace-notasjon for alle avhengigheter. +description: Håndhev sentralisert versjonsadministrasjon i monorepoer ved å kreve catalog- eller workspace-notasjon for alle avhengigheter. --- -Håndhev sentralisert versjonsadministrasjon i monorepoer ved å kreve `catalog:`- eller `workspace:`-notasjon for alle avhengigheter. +Håndhev sentralisert versjonsadministrasjon i monorepoer ved å kreve `catalog:`- eller `workspace:`-notasjon for alle avhengigheter. ## Regeldetaljer -I monorepoer med mange pakker fører duplisering av versjonsstrenger på tvers av `package.json`-filer til versjonsforskyvning og oppgraderingssmerter. Denne regelen sikrer at hver avhengighetsreferanse bruker `catalog:` (hentet fra en sentral katalog i rot-`package.json`) eller `workspace:` (for interne pakker), aldri en rå semver-streng. +I monorepoer med mange pakker fører duplisering av versjonsstrenger på tvers av `package.json`-filer til versjonsforskyvning og oppgraderingssmerter. Denne regelen sikrer at hver avhengighetsreferanse bruker `catalog:` (hentet fra en sentral katalog i rot-`package.json`) eller `workspace:` (for interne pakker), aldri en rå semver-streng. -Regelen har to sjekker: `catalog-usage` verifiserer at alle avhengigheter bruker riktig notasjon, og `catalog-completeness` verifiserer at hver `catalog:`-referanse peker til en faktisk oppføring i rotkatalogen. +Regelen har to sjekker: `catalog-usage` verifiserer at alle avhengigheter bruker riktig notasjon, og `catalog-completeness` verifiserer at hver `catalog:`-referanse peker til en faktisk oppføring i rotkatalogen. -## Eksempler på **feil** kode +## Eksempler på **feil** kode ```json title="packages/api/package.json" { "dependencies": { "zod": "^3.23.0", "hono": "^4.0.0" } } ``` -Rå semver-strenger omgår den sentrale katalogen og vil divergere på tvers av pakker. +Rå semver-strenger omgår den sentrale katalogen og vil divergere på tvers av pakker. -## Eksempler på **riktig** kode +## Eksempler på **riktig** kode ```json title="packages/api/package.json" { @@ -134,10 +134,10 @@ export default { } satisfies RuleSet; ``` -## Når du bør bruke den +## Når du bør bruke den -I monorepoer der flere pakker deler avhengigheter og du ønsker en enkelt sannhetskilde for versjoner (f.eks. Bun workspaces med katalogstøtte, eller lignende oppsett). +I monorepoer der flere pakker deler avhengigheter og du ønsker en enkelt sannhetskilde for versjoner (f.eks. Bun workspaces med katalogstøtte, eller lignende oppsett). -## Når du ikke bør bruke den +## Når du ikke bør bruke den I enkeltpakke-repositorier eller monorepoer som bruker en annen versjonsstyringstrategi som Renovates gruppeoppdateringer. diff --git a/docs/src/content/docs/nb/examples/wrapper-enforcement.mdx b/docs/src/content/docs/nb/examples/wrapper-enforcement.mdx index 2e1f94d9..de6ed302 100644 --- a/docs/src/content/docs/nb/examples/wrapper-enforcement.mdx +++ b/docs/src/content/docs/nb/examples/wrapper-enforcement.mdx @@ -1,15 +1,15 @@ --- title: wrapper-enforcement -description: Håndhev bruk av en prosjektinnpakning eller hjelper i stedet for et rått plattform-API, med automatisk ekskludering av innpakningsfilen selv. +description: Håndhev bruk av en prosjektinnpakning eller hjelper i stedet for et rått plattform-API, med automatisk ekskludering av innpakningsfilen selv. --- -Håndhev bruk av en prosjektinnpakning i stedet for et rått plattform-API. +Håndhev bruk av en prosjektinnpakning i stedet for et rått plattform-API. ## Regeldetaljer -Når et prosjekt tilbyr en hjelper som normaliserer et lavnivå-API (f.eks. en `platform.ts`-hjelper som innpakker `process.platform`), bør direkte bruk av det rå API-et forbys overalt unntatt i innpakningen selv. Denne regelen skanner omfangsfiler etter det rå API-kallet og ekskluderer automatisk hjelpefilen og ikke-produksjonskode. +Når et prosjekt tilbyr en hjelper som normaliserer et lavnivå-API (f.eks. en `platform.ts`-hjelper som innpakker `process.platform`), bør direkte bruk av det rå API-et forbys overalt unntatt i innpakningen selv. Denne regelen skanner omfangsfiler etter det rå API-kallet og ekskluderer automatisk hjelpefilen og ikke-produksjonskode. -## Eksempler på **feil** kode +## Eksempler på **feil** kode ```typescript title="src/commands/build.ts" if (process.platform === "win32") { @@ -17,7 +17,7 @@ if (process.platform === "win32") { } ``` -## Eksempler på **riktig** kode +## Eksempler på **riktig** kode ```typescript title="src/commands/build.ts" import { isWindows } from "../helpers/platform"; @@ -65,15 +65,15 @@ export default { } satisfies RuleSet; ``` -## Når du bør bruke den +## Når du bør bruke den -Når prosjektet ditt har en innpakning eller hjelpemodul som normaliserer et rått API og du vil forhindre direkte tilgang til det underliggende API-et. Vanlige eksempler: +Når prosjektet ditt har en innpakning eller hjelpemodul som normaliserer et rått API og du vil forhindre direkte tilgang til det underliggende API-et. Vanlige eksempler: - `platform.ts` som innpakker `process.platform` - `logger.ts` som innpakker `console.log` / `console.error` - `fs.ts` som innpakker `node:fs` med prosjektspesifikke standardverdier - `env.ts` som innpakker `process.env` med typede aksessorer -## Når du ikke bør bruke den +## Når du ikke bør bruke den -Når det rå API-et er enkelt nok til at en innpakning ikke tilfører verdi, eller når innpakningen ennå ikke er tatt i bruk på tvers av kodebasen (vurder å bruke `warning`-alvorlighetsgrad under migrering). +Når det rå API-et er enkelt nok til at en innpakning ikke tilfører verdi, eller når innpakningen ennå ikke er tatt i bruk på tvers av kodebasen (vurder å bruke `warning`-alvorlighetsgrad under migrering). diff --git a/docs/src/content/docs/nb/guides/copilot-cli-plugin.mdx b/docs/src/content/docs/nb/guides/copilot-cli-plugin.mdx index a9aaad19..980e47b3 100644 --- a/docs/src/content/docs/nb/guides/copilot-cli-plugin.mdx +++ b/docs/src/content/docs/nb/guides/copilot-cli-plugin.mdx @@ -1,53 +1,53 @@ --- title: Copilot CLI-plugin -description: Sett opp Archgate-pluginet for GitHub Copilot CLI. Legg til arkitekturstyring i Copilot med automatisert ADR-samsvar og regelhaandheving. +description: Sett opp Archgate-pluginet for GitHub Copilot CLI. Legg til arkitekturstyring i Copilot med automatisert ADR-samsvar og regelhåndhevning. --- -Archgate Copilot CLI-pluginet gir AI-agenter som jobber i [GitHub Copilot CLI](https://github.com/features/copilot) en strukturert styringsarbeidsflyt. Agenter leser ADR-ene dine for de skriver kode, validerer etterpaa, og fanger opp nye monstre for teamet -- den samme arbeidsflyten som er tilgjengelig i [Claude Code-pluginet](/guides/claude-code-plugin/). +Archgate Copilot CLI-pluginet gir AI-agenter som jobber i [GitHub Copilot CLI](https://github.com/features/copilot) en strukturert styringsarbeidsflyt. Agenter leser ADR-ene dine før de skriver kode, validerer etterpå, og fanger opp nye mønstre for teamet -- den samme arbeidsflyten som er tilgjengelig i [Claude Code-pluginet](/guides/claude-code-plugin/). ## Hvordan det fungerer -Copilot CLI stotter plugin-installasjon fra git-repositorier ved hjelp av `copilot plugin install`. Archgate-pluginet serveres fra et git-repositorium paa `plugins.archgate.dev/archgate.git`, som Copilot CLI gjenkjenner direkte -- det samme `.claude-plugin/plugin.json`-manifestformatet fungerer for baade Claude Code og Copilot CLI. +Copilot CLI støtter plugin-installasjon fra git-repositorier ved hjelp av `copilot plugin install`. Archgate-pluginet serveres fra et git-repositorium på `plugins.archgate.dev/archgate.git`, som Copilot CLI gjenkjenner direkte -- det samme `.claude-plugin/plugin.json`-manifestformatet fungerer for både Claude Code og Copilot CLI. ## Installasjon :::note[Betatilgang kreves] -Copilot CLI-pluginet er for oyeblikket i beta. Kjor `archgate login` for aa registrere deg og autentisere for du folger trinnene nedenfor. +Copilot CLI-pluginet er for øyeblikket i beta. Kjør `archgate login` for å registrere deg og autentisere før du følger trinnene nedenfor. ::: ### 1. Logg inn med GitHub -Autentiser med GitHub-kontoen din for aa faa et plugin-token: +Autentiser med GitHub-kontoen din for å få et plugin-token: ```bash archgate login ``` -Dette starter en GitHub Device Flow. CLI-en viser en engangskode og URL -- aapne URL-en i nettleseren din, skriv inn koden, og autoriser. Naar det er fullfort, lagres legitimasjonen sikkert i operativsystemets legitimasjonsbehandler via `git credential approve`. +Dette starter en GitHub Device Flow. CLI-en viser en engangskode og URL -- åpne URL-en i nettleseren din, skriv inn koden, og autoriser. Når det er fullført, lagres legitimasjonen sikkert i operativsystemets legitimasjonsbehandler via `git credential approve`. ### 2. Initialiser prosjektet ditt med pluginet -Kjor `archgate init` med `--editor copilot`-flagget: +Kjør `archgate init` med `--editor copilot`-flagget: ```bash archgate init --editor copilot ``` -Hvis du allerede er logget inn og `copilot`-CLI-en er paa PATH, installeres pluginet automatisk via: +Hvis du allerede er logget inn og `copilot`-CLI-en er på PATH, installeres pluginet automatisk via: ```bash copilot plugin install https://:@plugins.archgate.dev/archgate.git ``` -Hvis `copilot`-CLI-en ikke finnes, skriver kommandoen ut den manuelle kommandoen du maa kjore. +Hvis `copilot`-CLI-en ikke finnes, skriver kommandoen ut den manuelle kommandoen du må kjøre. -For aa eksplisitt be om plugin-installasjon: +For å eksplisitt be om plugin-installasjon: ```bash archgate init --editor copilot --install-plugin ``` -For aa installere eller reinstallere pluginet paa et allerede initialisert prosjekt: +For å installere eller reinstallere pluginet på et allerede initialisert prosjekt: ```bash archgate plugin install --editor copilot @@ -55,7 +55,7 @@ archgate plugin install --editor copilot ### Genererte filer -Kommandoen oppretter `.github/copilot/`-mappen for plugin-konfigurasjon. Plugin-installasjon haandteres separat via `copilot plugin install`-kommandoen. +Kommandoen oppretter `.github/copilot/`-mappen for plugin-konfigurasjon. Plugin-installasjon håndteres separat via `copilot plugin install`-kommandoen. ### Manuell installasjon @@ -65,7 +65,7 @@ Hvis `copilot`-CLI-en ikke finnes under `archgate init`, kan du installere plugi copilot plugin install https://:@plugins.archgate.dev/archgate.git ``` -Du kan finne den autentiserte URL-en din ved aa kjore `archgate plugin url copilot`. +Du kan finne den autentiserte URL-en din ved å kjøre `archgate plugin url copilot`. ## Hva pluginet tilbyr @@ -73,39 +73,39 @@ Pluginet legger til en agent og rollebaserte ferdigheter i Copilot CLI. Agenten ### Agent -| Agent | Formaal | -| -------------------- | -------------------------------------------------------------------------- | -| `archgate:developer` | Generell utviklingsagent som leser ADR-er for koding og validerer etterpaa | +| Agent | Formål | +| -------------------- | ------------------------------------------------------------------------- | +| `archgate:developer` | Generell utviklingsagent som leser ADR-er før koding og validerer etterpå | `archgate:developer`-agenten er satt som standardagent via plugin-innstillingene. Den orkestrerer ferdighetene nedenfor automatisk som en del av arbeidsflyten. ### Ferdigheter -| Ferdighet | Formaal | +| Ferdighet | Formål | | -------------------------- | --------------------------------------------------------------------------------------- | | `archgate:architect` | Validerer kodeendringer mot alle prosjektets ADR-er for strukturell samsvar | -| `archgate:quality-manager` | Gjennomgaar regeldekning og foreslar nye ADR-er naar monstre dukker opp | +| `archgate:quality-manager` | Gjennomgår regeldekning og foreslår nye ADR-er når mønstre dukker opp | | `archgate:adr-author` | Oppretter og redigerer ADR-er i henhold til prosjektets konvensjoner | | `archgate:onboard` | Engangsoppsett: utforsker kodebasen, intervjuer utvikleren, oppretter innledende ADR-er | -## Forste oppsett med onboard +## Første oppsett med onboard -Etter installasjon, kjor `archgate:onboard`-ferdigheten i prosjektet ditt en gang. Denne ferdigheten: +Etter installasjon, kjør `archgate:onboard`-ferdigheten i prosjektet ditt en gang. Denne ferdigheten: -1. Utforsker kodebasestrukturen din (mapper, nokkelfiler, pakkekonfigurasjon) +1. Utforsker kodebasestrukturen din (mapper, nøkkelfiler, pakkekonfigurasjon) 2. Intervjuer deg om teamets konvensjoner, begrensninger og arkitekturbeslutninger -3. Oppretter et innledende sett med ADR-er basert paa svarene dine -4. Setter opp `.archgate/`-mappen med de forste reglene dine +3. Oppretter et innledende sett med ADR-er basert på svarene dine +4. Setter opp `.archgate/`-mappen med de første reglene dine -Onboard-ferdigheten er designet for aa kjores en gang per prosjekt. Etter onboarding handterer de andre ferdighetene daglig utvikling. +Onboard-ferdigheten er designet for å kjøres en gang per prosjekt. Etter onboarding håndterer de andre ferdighetene daglig utvikling. ## Hvordan det fungerer i praksis -Pluginet folger en strukturert arbeidsflyt for hver kodeoppgave: +Pluginet følger en strukturert arbeidsflyt for hver kodeoppgave: ### 1. Les gjeldende ADR-er -Naar utvikleren gir en kodeoppgave, kjorer agenten `archgate review-context` for aa lese alle ADR-er som gjelder for filene som endres. Dette gir en komprimert briefing med **Decision**- og **Do's and Don'ts**-seksjonene fra hver relevante ADR. +Når utvikleren gir en kodeoppgave, kjører agenten `archgate review-context` for å lese alle ADR-er som gjelder for filene som endres. Dette gir en komprimert briefing med **Decision**- og **Do's and Don'ts**-seksjonene fra hver relevante ADR. ### 2. Skriv kode i henhold til ADR-begrensninger @@ -113,17 +113,17 @@ Agenten skriver kode som samsvarer med begrensningene fra ADR-ene. Do's and Don' ### 3. Valider endringer -Etter aa ha skrevet kode, kjorer agenten `archgate check` for aa utfore automatiserte regler mot endringene. Eventuelle brudd utbedres for man gaar videre. +Etter å ha skrevet kode, kjører agenten `archgate check` for å utføre automatiserte regler mot endringene. Eventuelle brudd utbedres før man går videre. ### 4. Arkitektgjennomgang -Agenten aktiverer `archgate:architect` for aa validere strukturelt ADR-samsvar utover det automatiserte regler fanger opp. +Agenten aktiverer `archgate:architect` for å validere strukturelt ADR-samsvar utover det automatiserte regler fanger opp. -### 5. Fang opp laeringer +### 5. Fang opp læringer -Agenten aktiverer `archgate:quality-manager` for aa gjennomgaa arbeidet og identifisere monstre som er verdt aa fange opp som nye ADR-er. +Agenten aktiverer `archgate:quality-manager` for å gjennomgå arbeidet og identifisere mønstre som er verdt å fange opp som nye ADR-er. ## Tips -- **Kjor onboard en gang per prosjekt** for aa generere de innledende ADR-ene fra den faktiske kodebasen din. -- **Hold ADR-regelfiler oppdatert** -- agenten haandterer det reglene sjekker for. +- **Kjør onboard en gang per prosjekt** for å generere de innledende ADR-ene fra den faktiske kodebasen din. +- **Hold ADR-regelfiler oppdatert** -- agenten håndterer det reglene sjekker for. diff --git a/docs/src/content/docs/nb/guides/cursor-integration.mdx b/docs/src/content/docs/nb/guides/cursor-integration.mdx index 22166f40..47bc3825 100644 --- a/docs/src/content/docs/nb/guides/cursor-integration.mdx +++ b/docs/src/content/docs/nb/guides/cursor-integration.mdx @@ -3,11 +3,11 @@ title: Cursor-integrasjon description: Integrer Archgate med Cursor IDE for AI-assistert utvikling med arkitekturstyring. Konfigurer agentregler og ferdigheter for ADR-samsvar. --- -Archgate integreres med [Cursor](https://cursor.com) for aa gi AI-agenter en strukturert styringsarbeidsflyt. Agenten leser ADR-ene dine for den skriver kode, validerer etterpaa, og fanger opp nye monstre for teamet -- den samme arbeidsflyten som er tilgjengelig i [Claude Code-pluginet](/guides/claude-code-plugin/). +Archgate integreres med [Cursor](https://cursor.com) for å gi AI-agenter en strukturert styringsarbeidsflyt. Agenten leser ADR-ene dine før den skriver kode, validerer etterpå, og fanger opp nye mønstre for teamet -- den samme arbeidsflyten som er tilgjengelig i [Claude Code-pluginet](/guides/claude-code-plugin/). ## Oppsett -Kjor `archgate init` med `--editor cursor`-flagget for aa konfigurere Cursor-integrasjon i prosjektet ditt: +Kjør `archgate init` med `--editor cursor`-flagget for å konfigurere Cursor-integrasjon i prosjektet ditt: ```bash archgate init --editor cursor @@ -16,17 +16,17 @@ archgate init --editor cursor ### Med plugin (beta) :::note[Betatilgang kreves] -Cursor-pluginet er for oyeblikket i beta. Kjor `archgate login` for aa registrere deg og autentisere. +Cursor-pluginet er for øyeblikket i beta. Kjør `archgate login` for å registrere deg og autentisere. ::: -Hvis du har logget inn via `archgate login`, installerer init-kommandoen ogsaa Archgate-pluginet for Cursor. Pluginet tilbyr ferdigbygde agentregler og ferdigheter som gir Cursor sin AI-agent en komplett styringsarbeidsflyt. +Hvis du har logget inn via `archgate login`, installerer init-kommandoen også Archgate-pluginet for Cursor. Pluginet tilbyr ferdigbygde agentregler og ferdigheter som gir Cursor sin AI-agent en komplett styringsarbeidsflyt. -Pluginet distribueres paa to maater: +Pluginet distribueres på to måter: 1. **Cursor Team Marketplace** -- Pluginet publiseres til et git-basert team-markedsplass-repositorium. Etter installasjon oppdager Cursor det fra team-markedsplassens URL som skrives ut av CLI-en. 2. **VS Code Extension (VSIX)** -- En `.vsix`-utvidelse installeres i Cursor via `cursor --install-extension`-kommandoen. -For aa eksplisitt installere pluginet: +For å eksplisitt installere pluginet: ```bash archgate login # engangsoppsett @@ -35,7 +35,7 @@ archgate init --editor cursor --install-plugin Kommandoen `archgate plugin install --editor cursor` installerer VS Code-utvidelsen via `cursor`-CLI-en hvis tilgjengelig og skriver ut team-markedsplassens URL; ellers skrives manuelle instruksjoner ut. -For aa installere eller reinstallere pluginet paa et allerede initialisert prosjekt: +For å installere eller reinstallere pluginet på et allerede initialisert prosjekt: ```bash archgate plugin install --editor cursor @@ -43,119 +43,119 @@ archgate plugin install --editor cursor ### Uten plugin (gratis) -Uten pluginet konfigurerer `archgate init --editor cursor` fortsatt en grunnleggende styringsregel. AI-agenten kan konsultere ADR-er og kjore sjekker via CLI-kommandoer, men faar ikke de rollebaserte ferdighetene beskrevet nedenfor. +Uten pluginet konfigurerer `archgate init --editor cursor` fortsatt en grunnleggende styringsregel. AI-agenten kan konsultere ADR-er og kjøre sjekker via CLI-kommandoer, men får ikke de rollebaserte ferdighetene beskrevet nedenfor. ### Genererte filer -| Fil | Formaal | -| --------------------------------------- | ---------------------------------------------------------------------- | -| `.cursor/rules/archgate-governance.mdc` | Alltid-paa Cursor-regel som instruerer agenten om aa konsultere ADR-er | +| Fil | Formål | +| --------------------------------------- | -------------------------------------------------------------------- | +| `.cursor/rules/archgate-governance.mdc` | Alltid-på Cursor-regel som instruerer agenten om å konsultere ADR-er | ## Hva pluginet tilbyr -Pluginet legger til en agent og rollebaserte ferdigheter i Cursor. Cursors plugin-system haandterer navnerom, saa ferdigheter bruker sine direkte navn uten prefiks. +Pluginet legger til en agent og rollebaserte ferdigheter i Cursor. Cursors plugin-system håndterer navnerom, så ferdigheter bruker sine direkte navn uten prefiks. ### Agent -| Navn | Formaal | -| ----------- | -------------------------------------------------------------------------- | -| `developer` | Generell utviklingsagent som leser ADR-er for koding og validerer etterpaa | +| Navn | Formål | +| ----------- | ------------------------------------------------------------------------- | +| `developer` | Generell utviklingsagent som leser ADR-er før koding og validerer etterpå | `developer`-agenten orkestrerer ferdighetene nedenfor automatisk som en del av arbeidsflyten. ### Ferdigheter -| Navn | Formaal | +| Navn | Formål | | ----------------- | --------------------------------------------------------------------------------------- | | `architect` | Validerer kodeendringer mot alle prosjektets ADR-er for strukturell samsvar | -| `quality-manager` | Gjennomgaar regeldekning og foreslar nye ADR-er naar monstre dukker opp | +| `quality-manager` | Gjennomgår regeldekning og foreslår nye ADR-er når mønstre dukker opp | | `adr-author` | Oppretter og redigerer ADR-er i henhold til prosjektets konvensjoner | | `onboard` | Engangsoppsett: utforsker kodebasen, intervjuer utvikleren, oppretter innledende ADR-er | | `cli-reference` | Intern referanse for AI-agenter med den komplette Archgate CLI-kommandoguiden | Disse er den samme agenten og ferdighetene som er tilgjengelige i Claude Code-pluginet (`archgate:developer`, `archgate:architect`, osv.), tilpasset Cursors plugin-system. -## Forste oppsett med onboard +## Første oppsett med onboard -Etter aa ha installert pluginet, kjor `onboard`-ferdigheten i prosjektet ditt en gang. Denne ferdigheten: +Etter å ha installert pluginet, kjør `onboard`-ferdigheten i prosjektet ditt en gang. Denne ferdigheten: -1. Utforsker kodebasestrukturen din (mapper, nokkelfiler, pakkekonfigurasjon) +1. Utforsker kodebasestrukturen din (mapper, nøkkelfiler, pakkekonfigurasjon) 2. Intervjuer deg om teamets konvensjoner, begrensninger og arkitekturbeslutninger -3. Oppretter et innledende sett med ADR-er basert paa svarene dine -4. Setter opp `.archgate/`-mappen med de forste reglene dine +3. Oppretter et innledende sett med ADR-er basert på svarene dine +4. Setter opp `.archgate/`-mappen med de første reglene dine -Onboard-ferdigheten er designet for aa kjores en gang per prosjekt. Etter onboarding haandterer de andre ferdighetene daglig utvikling. +Onboard-ferdigheten er designet for å kjøres en gang per prosjekt. Etter onboarding håndterer de andre ferdighetene daglig utvikling. ## Hvordan det fungerer i praksis ### Med pluginet -`developer`-agenten folger en strukturert arbeidsflyt for hver kodeoppgave: +`developer`-agenten følger en strukturert arbeidsflyt for hver kodeoppgave: -1. **Les gjeldende ADR-er** -- Agenten kjorer `archgate review-context` for aa se hvilke ADR-er som gjelder for filene som endres. Den skriver ikke kode for den har lest de gjeldende ADR-ene. +1. **Les gjeldende ADR-er** -- Agenten kjører `archgate review-context` for å se hvilke ADR-er som gjelder for filene som endres. Den skriver ikke kode før den har lest de gjeldende ADR-ene. 2. **Skriv kode i henhold til ADR-begrensninger** -- Agenten implementerer endringer i henhold til Do's and Don'ts fra de gjeldende ADR-ene. -3. **Kjor samsvarssjekker** -- Agenten kjorer `archgate check --staged` for aa utfore automatiserte regler. Eventuelle brudd utbedres for man gaar videre. +3. **Kjør samsvarssjekker** -- Agenten kjører `archgate check --staged` for å utføre automatiserte regler. Eventuelle brudd utbedres før man går videre. -4. **Arkitektgjennomgang** -- Agenten aktiverer `architect`-ferdigheten for aa validere strukturelt ADR-samsvar utover det automatiserte regler fanger opp. +4. **Arkitektgjennomgang** -- Agenten aktiverer `architect`-ferdigheten for å validere strukturelt ADR-samsvar utover det automatiserte regler fanger opp. -5. **Fang opp laeringer** -- Agenten aktiverer `quality-manager`-ferdigheten for aa gjennomgaa arbeidet og identifisere monstre som er verdt aa fange opp som nye ADR-er eller oppdateringer til eksisterende. +5. **Fang opp læringer** -- Agenten aktiverer `quality-manager`-ferdigheten for å gjennomgå arbeidet og identifisere mønstre som er verdt å fange opp som nye ADR-er eller oppdateringer til eksisterende. ### Uten pluginet -Agenten bruker styringsregelen og CLI-kommandoer for aa folge fire manuelle trinn: +Agenten bruker styringsregelen og CLI-kommandoer for å følge fire manuelle trinn: -1. **Gjennomgaa kontekst** -- Kjor `archgate review-context` for aa se hvilke ADR-er som gjelder for filene som endres. +1. **Gjennomgå kontekst** -- Kjør `archgate review-context` for å se hvilke ADR-er som gjelder for filene som endres. -2. **Les individuelle ADR-er** -- For full kontekst om en spesifikk beslutning, kjor `archgate adr show ` (for eksempel `archgate adr show ARCH-001`). +2. **Les individuelle ADR-er** -- For full kontekst om en spesifikk beslutning, kjør `archgate adr show ` (for eksempel `archgate adr show ARCH-001`). 3. **Skriv kode** -- Implementer endringer i henhold til begrensningene fra de gjeldende ADR-ene. -4. **Kjor samsvarssjekker** -- Kjor `archgate check --staged` for aa validere at koden samsvarer med alle ADR-regler. +4. **Kjør samsvarssjekker** -- Kjør `archgate check --staged` for å validere at koden samsvarer med alle ADR-regler. ## ADR-drevet avvisning -Naar agenten moter en oppgave som ville kreve brudd paa en ADR, avviser den og forklarer hvilken ADR som ville bli brutt. Den foreslar deretter hvordan man kan oppnaa det samme maalet uten aa bryte reglene. +Når agenten møter en oppgave som ville kreve brudd på en ADR, avviser den og forklarer hvilken ADR som ville bli brutt. Den foreslår deretter hvordan man kan oppnå det samme målet uten å bryte reglene. -Hvis for eksempel en utvikler ber agenten om aa legge til `chalk` som en avhengighet i et prosjekt styrt av en ADR for avhengighetspolicy, vil agenten: +Hvis for eksempel en utvikler ber agenten om å legge til `chalk` som en avhengighet i et prosjekt styrt av en ADR for avhengighetspolicy, vil agenten: 1. Avvise, med henvisning til ADR-en og den godkjente avhengighetslisten -2. Foresla det godkjente alternativet i stedet -3. Tilby aa implementere oppgaven med den samsvarende tilnaermingen +2. Foreslå det godkjente alternativet i stedet +3. Tilby å implementere oppgaven med den samsvarende tilnærmingen -Denne oppforselen er konsistent uavhengig av hvordan utvikleren formulerer forsporselen. ADR-er behandles som obligatoriske begrensninger, ikke forslag. +Denne oppførselen er konsistent uavhengig av hvordan utvikleren formulerer forespørselen. ADR-er behandles som obligatoriske begrensninger, ikke forslag. -## Naar du skal bruke hver agent eller ferdighet +## Når du skal bruke hver agent eller ferdighet -| Scenario | Ferdighet | -| -------------------------------------------------- | ----------------- | -| Starte et nytt prosjekt med Archgate | `onboard` | -| Daglige kodeoppgaver | `developer` | -| Gjennomgaa en PR for ADR-samsvar | `architect` | -| Oppdage et gjentagende monster verdt aa kodifisere | `quality-manager` | -| Opprette eller redigere en ADR | `adr-author` | +| Scenario | Ferdighet | +| ------------------------------------------------- | ----------------- | +| Starte et nytt prosjekt med Archgate | `onboard` | +| Daglige kodeoppgaver | `developer` | +| Gjennomgå en PR for ADR-samsvar | `architect` | +| Oppdage et gjentagende mønster verdt å kodifisere | `quality-manager` | +| Opprette eller redigere en ADR | `adr-author` | -`developer`-agenten orkestrerer ferdighetene automatisk -- den aktiverer `architect` og `quality-manager` som en del av arbeidsflyten. Mesteparten av tiden trenger du bare aa bruke `developer` direkte. +`developer`-agenten orkestrerer ferdighetene automatisk -- den aktiverer `architect` og `quality-manager` som en del av arbeidsflyten. Mesteparten av tiden trenger du bare å bruke `developer` direkte. ## Styringsregel -Styringsregelen i `.cursor/rules/archgate-governance.mdc` bruker `alwaysApply: true`, noe som betyr at Cursor-agenten alltid har styringstilgang tilgjengelig uten manuell aktivering. Den instruerer agenten om aa kjore `archgate review-context` for koding og `archgate check --staged` etterpaa. +Styringsregelen i `.cursor/rules/archgate-governance.mdc` bruker `alwaysApply: true`, noe som betyr at Cursor-agenten alltid har styringstilgang tilgjengelig uten manuell aktivering. Den instruerer agenten om å kjøre `archgate review-context` før koding og `archgate check --staged` etterpå. ## Tilgang til sesjonsutskrifter -Kommandoen `archgate session-context cursor` leser Cursor-agentens sesjonsutskrifter fra disk. Dette lar ferdigheter faa tilgang til historikken til den gjeldende samtalen, noe som er nyttig for aa gjenopprette kontekst som kan ha blitt komprimert eller avkortet. +Kommandoen `archgate session-context cursor` leser Cursor-agentens sesjonsutskrifter fra disk. Dette lar ferdigheter få tilgang til historikken til den gjeldende samtalen, noe som er nyttig for å gjenopprette kontekst som kan ha blitt komprimert eller avkortet. Kommandoen aksepterer to valgfrie flagg: -- `--max-entries ` -- Maksimalt antall oppforinger aa returnere (standard: 200, nyeste oppforinger). -- `--session-id ` -- En spesifikk sesjons-UUID aa lese. Hvis utelatt, brukes den nyeste sesjonen. +- `--max-entries ` -- Maksimalt antall oppføringer å returnere (standard: 200, nyeste oppføringer). +- `--session-id ` -- En spesifikk sesjons-UUID å lese. Hvis utelatt, brukes den nyeste sesjonen. ## Tips for effektiv bruk - **Bruk `developer`-ferdigheten for kodeoppgaver.** Den orkestrerer hele les-valider-fang-opp-arbeidsflyten automatisk. -- **Kjor `onboard` en gang per prosjekt.** Den setter opp de innledende ADR-ene basert paa den faktiske kodebasen og konvensjonene dine. +- **Kjør `onboard` en gang per prosjekt.** Den setter opp de innledende ADR-ene basert på den faktiske kodebasen og konvensjonene dine. - **Bruk `architect` for PR-gjennomganger.** Den validerer strukturelt samsvar utover det automatiserte regler fanger opp. -- **Bruk `quality-manager` etter aa ha lost vanskelige problemer.** Den fanger opp laeringer slik at de samme feilene ikke gjentas. -- **Commit `.cursor/`-mappen.** Dette sikrer at alle teammedlemmer faar den samme styringskonfigurasjonen naar de kloner repositoriet. -- **Hold ADR-regelfiler oppdatert.** Agenten haandterer det reglene sjekker for -- hvis en regel mangler, vil bruddet ikke bli fanget opp. +- **Bruk `quality-manager` etter å ha løst vanskelige problemer.** Den fanger opp læringer slik at de samme feilene ikke gjentas. +- **Commit `.cursor/`-mappen.** Dette sikrer at alle teammedlemmer får den samme styringskonfigurasjonen når de kloner repositoriet. +- **Hold ADR-regelfiler oppdatert.** Agenten håndterer det reglene sjekker for -- hvis en regel mangler, vil bruddet ikke bli fanget opp. diff --git a/docs/src/content/docs/nb/guides/importing-adrs.mdx b/docs/src/content/docs/nb/guides/importing-adrs.mdx index 8adeaeb6..d11025f5 100644 --- a/docs/src/content/docs/nb/guides/importing-adrs.mdx +++ b/docs/src/content/docs/nb/guides/importing-adrs.mdx @@ -1,6 +1,6 @@ --- title: Importere ADR-er -description: Importer kuraterte Architecture Decision Records fra Archgate-registeret eller et hvilket som helst git-repositorium. Start med utprovde konvensjoner i stedet for en blank side. +description: Importer kuraterte Architecture Decision Records fra Archgate-registeret eller et hvilket som helst git-repositorium. Start med utprøvde konvensjoner i stedet for en blank side. --- import { Tabs, TabItem } from "@astrojs/starlight/components"; @@ -11,9 +11,9 @@ En **ADR-pakke** er en kuratert samling av Architecture Decision Records buntet - En `archgate-pack.yaml`-manifestfil med metadata (navn, versjon, vedlikeholdere, tagger) - En eller flere ADR-markdownfiler i en `adrs/`-katalog -- Valgfrie tilhorende `.rules.ts`-filer som haandhever hver beslutning automatisk +- Valgfrie tilhørende `.rules.ts`-filer som håndhever hver beslutning automatisk -Pakker lar deg starte et prosjekt med utprovde arkitekturkonvensjoner i stedet for aa skrive alt fra bunnen av. +Pakker lar deg starte et prosjekt med utprøvde arkitekturkonvensjoner i stedet for å skrive alt fra bunnen av. ## Importere fra registeret @@ -23,11 +23,11 @@ Pakker lar deg starte et prosjekt med utprovde arkitekturkonvensjoner i stedet f archgate adr import packs/typescript-strict ``` -Dette kloner registeret, kopierer ADR-ene til `.archgate/adrs/`-katalogen din, og tilordner ID-er paa nytt for aa passe prosjektets nummereringsskjema. +Dette kloner registeret, kopierer ADR-ene til `.archgate/adrs/`-katalogen din, og tilordner ID-er på nytt for å passe prosjektets nummereringsskjema. -### Laase til en versjon +### Låse til en versjon -Legg til `@` for aa laase til en spesifikk git-tag eller gren: +Legg til `@` for å låse til en spesifikk git-tag eller gren: ```bash archgate adr import packs/typescript-strict@0.3.0 @@ -41,7 +41,7 @@ Du trenger ikke importere en hel pakke. Pek til en spesifikk ADR-fil inni en pak archgate adr import packs/security/adrs/SEC-001-no-secrets-in-code ``` -Bare den ene ADR-en (og dens tilhorende regelfil, hvis den finnes) vil bli importert. +Bare den ene ADR-en (og dens tilhørende regelfil, hvis den finnes) vil bli importert. ## Importere fra tredjepartsrepositorier @@ -55,7 +55,7 @@ Dette kloner `https://github.com/acme/company-adrs.git` og importerer fra den an ## Importere fra en hvilken som helst git-URL -For ikke-GitHub-repositorier eller naar du trenger full kontroll, send en fullstendig URL: +For ikke-GitHub-repositorier eller når du trenger full kontroll, send en fullstendig URL: ```bash archgate adr import https://github.com/org/repo/tree/main/packs/my-pack @@ -67,9 +67,9 @@ CLI-en parser GitHub `/tree//`-formatet automatisk. For andre verter k archgate adr import https://gitlab.com/team/repo.git ``` -## Forhaandsvis med `--dry-run` +## Forhåndsvis med `--dry-run` -Se hva som ville blitt importert uten aa skrive noe: +Se hva som ville blitt importert uten å skrive noe: ```bash archgate adr import packs/typescript-strict --dry-run @@ -89,9 +89,9 @@ Dette leser `.archgate/imports.json` og viser hver kilde, versjon og ADR-ID-ene ## Hvordan ID-nytilordning fungerer -Naar du importerer ADR-er, blir de opprinnelige ID-ene **nytilordnet** for aa matche prosjektets domeneprefikser. Hver ADRs `domain`-felt bestemmer hvilket prefiks den faar -- for eksempel blir en ADR med `domain: frontend` til `FE-XXX`, mens en med `domain: backend` blir `BE-XXX`. Hvert domene har sin egen teller, saa import av en pakke med blandede domener produserer korrekt prefiksede ID-er uten kollisjoner. +Når du importerer ADR-er, blir de opprinnelige ID-ene **nytilordnet** for å matche prosjektets domeneprefikser. Hver ADRs `domain`-felt bestemmer hvilket prefiks den får -- for eksempel blir en ADR med `domain: frontend` til `FE-XXX`, mens en med `domain: backend` blir `BE-XXX`. Hvert domene har sin egen teller, så import av en pakke med blandede domener produserer korrekt prefiksede ID-er uten kollisjoner. -For eksempel, naar du importerer en pakke med tre frontend-ADR-er og to backend-ADR-er inn i et prosjekt som allerede har `FE-001` og `BE-001`, produseres: +For eksempel, når du importerer en pakke med tre frontend-ADR-er og to backend-ADR-er inn i et prosjekt som allerede har `FE-001` og `BE-001`, produseres: - `FE-002`, `FE-003`, `FE-004` (frontend) - `BE-002`, `BE-003` (backend) @@ -119,13 +119,13 @@ Hver import registreres i `.archgate/imports.json`: } ``` -Dette manifestet lar deg spore opprinnelse -- hvor hver importerte ADR kom fra og naar. Commit det til versjonskontroll sammen med ADR-ene dine. +Dette manifestet lar deg spore opprinnelse -- hvor hver importerte ADR kom fra og når. Commit det til versjonskontroll sammen med ADR-ene dine. ## Referanse for kommandoalternativer -| Alternativ | Beskrivelse | -| ----------- | ------------------------------------------- | -| `--yes` | Hopp over bekreftelsesdialogen | -| `--json` | Skriv ut resultater som JSON | -| `--dry-run` | Forhaandsvis endringer uten aa skrive filer | -| `--list` | List tidligere importerte ADR-er | +| Alternativ | Beskrivelse | +| ----------- | ----------------------------------------- | +| `--yes` | Hopp over bekreftelsesdialogen | +| `--json` | Skriv ut resultater som JSON | +| `--dry-run` | Forhåndsvis endringer uten å skrive filer | +| `--list` | List tidligere importerte ADR-er | diff --git a/docs/src/content/docs/nb/guides/opencode-integration.mdx b/docs/src/content/docs/nb/guides/opencode-integration.mdx index 08412e13..64d06eae 100644 --- a/docs/src/content/docs/nb/guides/opencode-integration.mdx +++ b/docs/src/content/docs/nb/guides/opencode-integration.mdx @@ -3,23 +3,23 @@ title: opencode-integrasjon description: Integrer Archgate med opencode for AI-assistert utvikling med arkitekturstyring. Konfigurer agenter og underagenter for ADR-samsvar. --- -Archgate integreres med [opencode](https://opencode.ai) for aa gi AI-agenter en strukturert styringsarbeidsflyt. Agenten leser ADR-ene dine for den skriver kode, validerer etterpaa, og fanger opp nye monstre for teamet -- den samme arbeidsflyten som er tilgjengelig i [Claude Code-pluginet](/guides/claude-code-plugin/). +Archgate integreres med [opencode](https://opencode.ai) for å gi AI-agenter en strukturert styringsarbeidsflyt. Agenten leser ADR-ene dine før den skriver kode, validerer etterpå, og fanger opp nye mønstre for teamet -- den samme arbeidsflyten som er tilgjengelig i [Claude Code-pluginet](/guides/claude-code-plugin/). ## Oppsett -Kjor `archgate init` med `--editor opencode`-flagget for aa konfigurere opencode-integrasjon i prosjektet ditt: +Kjør `archgate init` med `--editor opencode`-flagget for å konfigurere opencode-integrasjon i prosjektet ditt: ```bash archgate init --editor opencode ``` :::note[Betatilgang kreves] -opencode-agentpakken er for oyeblikket i beta. Kjor `archgate login` for aa registrere deg og autentisere. +opencode-agentpakken er for øyeblikket i beta. Kjør `archgate login` for å registrere deg og autentisere. ::: -I motsetning til Claude Code- eller Cursor-integrasjonene skrives opencode-agentene **ikke til prosjekttreet ditt**. De installeres i stedet paa brukernivaa -- saa de bor paa maskinen din, ikke i repositoriet ditt, og er tilgjengelige paa tvers av alle prosjekter du aapner med opencode. +I motsetning til Claude Code- eller Cursor-integrasjonene skrives opencode-agentene **ikke til prosjekttreet ditt**. De installeres i stedet på brukernivå -- så de bor på maskinen din, ikke i repositoriet ditt, og er tilgjengelige på tvers av alle prosjekter du åpner med opencode. -opencode bruker XDG Base Directory-konvensjonen paa alle plattformer (via `xdg-basedir`-pakken), saa installasjonsplasseringen resolves til `$XDG_CONFIG_HOME/opencode/agents/` naar den variabelen er satt, og faller tilbake til `$HOME/.config/opencode/agents/` ellers. Det betyr at Windows-installasjoner havner under `C:\Users\\.config\opencode\agents\`, ikke under `%APPDATA%`: +opencode bruker XDG Base Directory-konvensjonen på alle plattformer (via `xdg-basedir`-pakken), så installasjonsplasseringen resolves til `$XDG_CONFIG_HOME/opencode/agents/` når den variabelen er satt, og faller tilbake til `$HOME/.config/opencode/agents/` ellers. Det betyr at Windows-installasjoner havner under `C:\Users\\.config\opencode\agents\`, ikke under `%APPDATA%`: | Plattform | Installasjonsplassering | | ------------- | ------------------------------------------------ | @@ -28,34 +28,34 @@ opencode bruker XDG Base Directory-konvensjonen paa alle plattformer (via `xdg-b ### Autentisert installasjon -:::caution[opencode maa vaere installert forst] -Installasjonstrinnet kjorer bare naar `opencode`-CLI-en er paa PATH. Archgate maa bekrefte at opencode er tilstede for den skriver filer til brukernivaaets konfigurasjonskatalog -- ellers ville agentene ligge paa en plassering ingenting leser. Installer opencode fra [opencode.ai](https://opencode.ai/docs/) forst, og kjor deretter `archgate init --editor opencode` eller `archgate plugin install --editor opencode` paa nytt. +:::caution[opencode må være installert først] +Installasjonstrinnet kjører bare når `opencode`-CLI-en er på PATH. Archgate må bekrefte at opencode er tilstede før den skriver filer til brukernivåets konfigurasjonskatalog -- ellers ville agentene ligge på en plassering ingenting leser. Installer opencode fra [opencode.ai](https://opencode.ai/docs/) først, og kjør deretter `archgate init --editor opencode` eller `archgate plugin install --editor opencode` på nytt. ::: -Hvis du har logget inn via `archgate login` **og** `opencode` er paa PATH, laster init-kommandoen ned og installerer Archgate-agentpakken for opencode. Pakken tilbyr en ferdigbygd primaer agent og fire underagenter som gir opencode sin AI en komplett styringsarbeidsflyt. +Hvis du har logget inn via `archgate login` **og** `opencode` er på PATH, laster init-kommandoen ned og installerer Archgate-agentpakken for opencode. Pakken tilbyr en ferdigbygd primær agent og fire underagenter som gir opencode sin AI en komplett styringsarbeidsflyt. -For aa eksplisitt installere agentene: +For å eksplisitt installere agentene: ```bash archgate login # engangsoppsett archgate init --editor opencode --install-plugin ``` -For aa installere eller reinstallere paa et allerede initialisert prosjekt: +For å installere eller reinstallere på et allerede initialisert prosjekt: ```bash archgate plugin install --editor opencode ``` -Installasjonstrinnet laster ned en autentisert tarball fra Archgate plugins-tjenesten og pakker ut de fem `archgate-*.md`-agentfilene i opencode brukernivaa-katalogen. +Installasjonstrinnet laster ned en autentisert tarball fra Archgate plugins-tjenesten og pakker ut de fem `archgate-*.md`-agentfilene i opencode brukernivå-katalogen. -### Genererte filer (brukernivaa) +### Genererte filer (brukernivå) -| Fil | Formaal | +| Fil | Formål | | ----------------------------------------------- | ----------------------------------------------------------------------- | -| `/archgate-developer.md` | Primaer agent (velges med Tab) som kjorer den fulle ADR-arbeidsflyten | +| `/archgate-developer.md` | Primær agent (velges med Tab) som kjører den fulle ADR-arbeidsflyten | | `/archgate-architect.md` | Underagent som validerer kodeendringer mot alle prosjektets ADR-er | -| `/archgate-quality-manager.md` | Underagent som fanger opp laeringer og foreslar nye ADR-er | +| `/archgate-quality-manager.md` | Underagent som fanger opp læringer og foreslår nye ADR-er | | `/archgate-adr-author.md` | Underagent som oppretter og redigerer ADR-er i henhold til konvensjoner | | `/archgate-cli-reference.md` | Intern referanseunderagent med Archgate CLI-kommandoguiden (skjult) | @@ -63,76 +63,76 @@ Installasjonstrinnet laster ned en autentisert tarball fra Archgate plugins-tjen ## Hva pakken tilbyr -`archgate-`-prefikset unngaar kollisjoner med brukeropprettede opencode-agenter i samme katalog. Underagenter aktiveres via opencodes `@-mention`-syntaks. +`archgate-`-prefikset unngår kollisjoner med brukeropprettede opencode-agenter i samme katalog. Underagenter aktiveres via opencodes `@-mention`-syntaks. -### Primaer agent +### Primær agent -| Navn | Formaal | -| -------------------- | -------------------------------------------------------------------------- | -| `archgate-developer` | Generell utviklingsagent som leser ADR-er for koding og validerer etterpaa | +| Navn | Formål | +| -------------------- | ------------------------------------------------------------------------- | +| `archgate-developer` | Generell utviklingsagent som leser ADR-er før koding og validerer etterpå | `archgate-developer`-agenten orkestrerer underagentene nedenfor automatisk som en del av arbeidsflyten. ### Underagenter -| Navn | Formaal | +| Navn | Formål | | -------------------------- | ----------------------------------------------------------------------------- | | `archgate-architect` | Validerer kodeendringer mot alle prosjektets ADR-er for strukturell samsvar | -| `archgate-quality-manager` | Gjennomgaar regeldekning og foreslar nye ADR-er naar monstre dukker opp | +| `archgate-quality-manager` | Gjennomgår regeldekning og foreslår nye ADR-er når mønstre dukker opp | | `archgate-adr-author` | Oppretter og redigerer ADR-er i henhold til prosjektets konvensjoner | | `archgate-cli-reference` | Intern referanse for AI-agenter med den komplette Archgate CLI-kommandoguiden | -Disse er de samme rollene som er tilgjengelige i Claude Code-pluginet, tilpasset opencodes opprinnelige primaer-/underagentmodell. +Disse er de samme rollene som er tilgjengelige i Claude Code-pluginet, tilpasset opencodes opprinnelige primær-/underagentmodell. ## Hvordan det fungerer i praksis -Velg `archgate-developer` som din primaere agent (bruk Tab-tasten i opencode) naar du starter en kodeoppgave. Agenten folger en strukturert arbeidsflyt for hver endring: +Velg `archgate-developer` som din primære agent (bruk Tab-tasten i opencode) når du starter en kodeoppgave. Agenten følger en strukturert arbeidsflyt for hver endring: -1. **Les gjeldende ADR-er** -- Agenten kjorer `archgate review-context` for aa se hvilke ADR-er som gjelder for filene som endres. Den skriver ikke kode for den har lest de gjeldende ADR-ene. +1. **Les gjeldende ADR-er** -- Agenten kjører `archgate review-context` for å se hvilke ADR-er som gjelder for filene som endres. Den skriver ikke kode før den har lest de gjeldende ADR-ene. 2. **Skriv kode i henhold til ADR-begrensninger** -- Agenten implementerer endringer i henhold til Do's and Don'ts fra de gjeldende ADR-ene. -3. **Kjor samsvarssjekker** -- Agenten kjorer `archgate check` for aa utfore automatiserte regler. Eventuelle brudd utbedres for man gaar videre. +3. **Kjør samsvarssjekker** -- Agenten kjører `archgate check` for å utføre automatiserte regler. Eventuelle brudd utbedres før man går videre. -4. **Arkitektgjennomgang** -- Agenten nevner `@archgate-architect` for aa validere strukturelt ADR-samsvar utover det automatiserte regler fanger opp. +4. **Arkitektgjennomgang** -- Agenten nevner `@archgate-architect` for å validere strukturelt ADR-samsvar utover det automatiserte regler fanger opp. -5. **Fang opp laeringer** -- Agenten nevner `@archgate-quality-manager` for aa gjennomgaa arbeidet og identifisere monstre som er verdt aa fange opp som nye ADR-er eller oppdateringer til eksisterende. +5. **Fang opp læringer** -- Agenten nevner `@archgate-quality-manager` for å gjennomgå arbeidet og identifisere mønstre som er verdt å fange opp som nye ADR-er eller oppdateringer til eksisterende. ## ADR-drevet avvisning -Naar `archgate-developer` moter en oppgave som ville kreve brudd paa en ADR, avviser den og forklarer hvilken ADR som ville bli brutt. Den foreslar deretter hvordan man kan oppnaa det samme maalet uten aa bryte reglene. +Når `archgate-developer` møter en oppgave som ville kreve brudd på en ADR, avviser den og forklarer hvilken ADR som ville bli brutt. Den foreslår deretter hvordan man kan oppnå det samme målet uten å bryte reglene. -Hvis for eksempel en utvikler ber agenten om aa legge til `chalk` som en avhengighet i et prosjekt styrt av en ADR for avhengighetspolicy, vil agenten: +Hvis for eksempel en utvikler ber agenten om å legge til `chalk` som en avhengighet i et prosjekt styrt av en ADR for avhengighetspolicy, vil agenten: 1. Avvise, med henvisning til ADR-en og den godkjente avhengighetslisten -2. Foresla det godkjente alternativet i stedet -3. Tilby aa implementere oppgaven med den samsvarende tilnaermingen +2. Foreslå det godkjente alternativet i stedet +3. Tilby å implementere oppgaven med den samsvarende tilnærmingen -Denne oppforselen er konsistent uavhengig av hvordan utvikleren formulerer forsporselen. ADR-er behandles som obligatoriske begrensninger, ikke forslag. +Denne oppførselen er konsistent uavhengig av hvordan utvikleren formulerer forespørselen. ADR-er behandles som obligatoriske begrensninger, ikke forslag. -## Naar du skal bruke hver agent eller underagent +## Når du skal bruke hver agent eller underagent -| Scenario | Agent / Underagent | -| -------------------------------------------------- | ------------------------------ | -| Daglige kodeoppgaver | `archgate-developer` (primaer) | -| Gjennomgaa en endring for ADR-samsvar | `@archgate-architect` | -| Oppdage et gjentagende monster verdt aa kodifisere | `@archgate-quality-manager` | -| Opprette eller redigere en ADR | `@archgate-adr-author` | +| Scenario | Agent / Underagent | +| ------------------------------------------------- | ----------------------------- | +| Daglige kodeoppgaver | `archgate-developer` (primær) | +| Gjennomgå en endring for ADR-samsvar | `@archgate-architect` | +| Oppdage et gjentagende mønster verdt å kodifisere | `@archgate-quality-manager` | +| Opprette eller redigere en ADR | `@archgate-adr-author` | -`archgate-developer`-agenten orkestrerer underagentene automatisk -- den nevner `@archgate-architect` og `@archgate-quality-manager` som en del av arbeidsflyten. Mesteparten av tiden trenger du bare aa velge `archgate-developer` og la den kjore. +`archgate-developer`-agenten orkestrerer underagentene automatisk -- den nevner `@archgate-architect` og `@archgate-quality-manager` som en del av arbeidsflyten. Mesteparten av tiden trenger du bare å velge `archgate-developer` og la den kjøre. -## Brukernivaa vs. prosjektnivaa +## Brukernivå vs. prosjektnivå -opencode-pakken bor i opencode-katalogen paa brukernivaa i stedet for i `.opencode/` inne i prosjektet ditt. Konsekvenser: +opencode-pakken bor i opencode-katalogen på brukernivå i stedet for i `.opencode/` inne i prosjektet ditt. Konsekvenser: -- **En installasjon per maskin.** `archgate plugin install --editor opencode` installerer pakken globalt. Alle prosjekter du aapner med opencode ser de samme `archgate-*`-agentene. -- **Repositoriet ditt forblir rent.** Ingen `.opencode/`-mappe opprettes noensinne av `archgate init`. Teammedlemmer som onsker agentene kjorer sin egen `archgate plugin install --editor opencode`. -- **Oppgraderinger er globale.** Aa kjore `archgate plugin install --editor opencode` paa nytt overskriver de eksisterende filene med den nyeste pakken. +- **En installasjon per maskin.** `archgate plugin install --editor opencode` installerer pakken globalt. Alle prosjekter du åpner med opencode ser de samme `archgate-*`-agentene. +- **Repositoriet ditt forblir rent.** Ingen `.opencode/`-mappe opprettes noensinne av `archgate init`. Teammedlemmer som ønsker agentene kjører sin egen `archgate plugin install --editor opencode`. +- **Oppgraderinger er globale.** Å kjøre `archgate plugin install --editor opencode` på nytt overskriver de eksisterende filene med den nyeste pakken. ## Tips for effektiv bruk -- **Velg `archgate-developer` ved starten av kodeokter.** Den orkestrerer hele les-valider-fang-opp-arbeidsflyten automatisk. +- **Velg `archgate-developer` ved starten av kodeøkter.** Den orkestrerer hele les-valider-fang-opp-arbeidsflyten automatisk. - **Bruk `@archgate-architect` for gjennomganger.** Den validerer strukturelt samsvar utover det automatiserte regler fanger opp. -- **Bruk `@archgate-quality-manager` etter aa ha lost vanskelige problemer.** Den fanger opp laeringer slik at de samme feilene ikke gjentas. -- **Hold ADR-regelfiler oppdatert.** Agenten haandterer det reglene sjekker for -- hvis en regel mangler, vil bruddet ikke bli fanget opp. -- **Kjor `archgate plugin install --editor opencode` paa nytt for aa oppgradere.** Tjenesten returnerer den nyeste agentpakken ved hver autentisert nedlasting. +- **Bruk `@archgate-quality-manager` etter å ha løst vanskelige problemer.** Den fanger opp læringer slik at de samme feilene ikke gjentas. +- **Hold ADR-regelfiler oppdatert.** Agenten håndterer det reglene sjekker for -- hvis en regel mangler, vil bruddet ikke bli fanget opp. +- **Kjør `archgate plugin install --editor opencode` på nytt for å oppgradere.** Tjenesten returnerer den nyeste agentpakken ved hver autentisert nedlasting. diff --git a/docs/src/content/docs/nb/guides/pre-commit-hooks.mdx b/docs/src/content/docs/nb/guides/pre-commit-hooks.mdx index 220140b9..769803e4 100644 --- a/docs/src/content/docs/nb/guides/pre-commit-hooks.mdx +++ b/docs/src/content/docs/nb/guides/pre-commit-hooks.mdx @@ -1,17 +1,17 @@ --- title: Pre-commit-hooks -description: Sett opp Archgate pre-commit-hooks for aa automatisk sjekke ADR-samsvar for hver commit. Fang opp arkitekturbrudd for de naar CI. +description: Sett opp Archgate pre-commit-hooks for å automatisk sjekke ADR-samsvar før hver commit. Fang opp arkitekturbrudd før de når CI. --- ## Oversikt -Kommandoen `archgate check --staged` sjekker bare git-stagede filer mot ADR-reglene dine. Fordi den hopper over ustagede og usporede filer, kjorer den raskt nok til aa brukes som en pre-commit-hook uten aa bremse arbeidsflyten din. +Kommandoen `archgate check --staged` sjekker bare git-stagede filer mot ADR-reglene dine. Fordi den hopper over ustagede og usporede filer, kjører den raskt nok til å brukes som en pre-commit-hook uten å bremse arbeidsflyten din. -Naar en sjekk feiler, blokkeres committen. Brudd skrives ut til stderr med filstier og linjenumre slik at du kan finne og fikse dem umiddelbart. +Når en sjekk feiler, blokkeres committen. Brudd skrives ut til stderr med filstier og linjenumre slik at du kan finne og fikse dem umiddelbart. ## Lefthook -[Lefthook](https://github.com/evilmartians/lefthook) er en rask, kryssplattform git-hooks-behandler. Legg til folgende i `lefthook.yml`: +[Lefthook](https://github.com/evilmartians/lefthook) er en rask, kryssplattform git-hooks-behandler. Legg til følgende i `lefthook.yml`: ```yaml # lefthook.yml @@ -29,53 +29,53 @@ lefthook install ## Husky -[Husky](https://typicode.github.io/husky/) er et populaert git-hooks-verktoy for Node.js-prosjekter. Legg til sjekken i pre-commit-hooken din: +[Husky](https://typicode.github.io/husky/) er et populært git-hooks-verktøy for Node.js-prosjekter. Legg til sjekken i pre-commit-hooken din: ```bash # .husky/pre-commit archgate check --staged ``` -Sorge for at hook-filen er kjoerbar: +Sørg for at hook-filen er kjørbar: ```bash chmod +x .husky/pre-commit ``` -## Hva skjer naar sjekker feiler +## Hva skjer når sjekker feiler -Naar `archgate check --staged` finner brudd, avslutter den med kode 1. Dette blokkerer committen. Utskriften inkluderer: +Når `archgate check --staged` finner brudd, avslutter den med kode 1. Dette blokkerer committen. Utskriften inkluderer: - ADR-ID-en og regelnavnet som ble brutt - Filstien der bruddet ble funnet -- Linjenummeret (naar tilgjengelig) +- Linjenummeret (når tilgjengelig) - En beskrivelse av hva regelen forventer -Fiks bruddene, stage filene paa nytt med `git add`, og commit igjen. +Fiks bruddene, stage filene på nytt med `git add`, og commit igjen. ## Ytelse -`--staged`-flagget begrenser sjekker til bare filene i git-stageomraadet. Dette betyr: +`--staged`-flagget begrenser sjekker til bare filene i git-stageområdet. Dette betyr: - Et prosjekt med hundrevis av kildefiler, men bare tre stagede filer, vil bare sjekke de tre filene. - Regler som ikke matcher noen stagede filer, hoppes helt over. -- Typiske pre-commit-sjekker fullores paa under et sekund. +- Typiske pre-commit-sjekker fullføres på under et sekund. -Uten `--staged` skanner `archgate check` alle filer som matcher hver ADRs `files`-globmonster, noe som er nyttig for CI, men tregere for interaktiv bruk. +Uten `--staged` skanner `archgate check` alle filer som matcher hver ADRs `files`-globmønster, noe som er nyttig for CI, men tregere for interaktiv bruk. ## Nyttige flagg -| Flagg | Formaal | -| ------------ | ---------------------------------------------------------------------------------------------------------------------------- | -| `--staged` | Sjekk bare git-stagede filer (paakrevd for pre-commit) | -| `--verbose` | Vis bestaatte regler og tidsinformasjon -- nyttig for aa feilsoke hvorfor en sjekk er treg eller hvilke regler som evalueres | -| `--json` | Skriv ut resultater som JSON -- nyttig for aa pipe til andre verktoy eller egendefinerte rapporteringsskript | -| `--adr ` | Sjekk bare regler fra en spesifikk ADR -- nyttig for aa isolere en enkelt regel under feilsoking | -| `--ci` | Skriv ut GitHub Actions-annotasjoner -- bruk dette i CI-arbeidsflyter i stedet for pre-commit-hooks | +| Flagg | Formål | +| ------------ | -------------------------------------------------------------------------------------------------------------------------- | +| `--staged` | Sjekk bare git-stagede filer (påkrevd for pre-commit) | +| `--verbose` | Vis beståtte regler og tidsinformasjon -- nyttig for å feilsøke hvorfor en sjekk er treg eller hvilke regler som evalueres | +| `--json` | Skriv ut resultater som JSON -- nyttig for å pipe til andre verktøy eller egendefinerte rapporteringsskript | +| `--adr ` | Sjekk bare regler fra en spesifikk ADR -- nyttig for å isolere en enkelt regel under feilsøking | +| `--ci` | Skriv ut GitHub Actions-annotasjoner -- bruk dette i CI-arbeidsflyter i stedet for pre-commit-hooks | ## Kombinere med andre hooks -Pre-commit-hooks kan kjore flere kommandoer. For eksempel med Lefthook: +Pre-commit-hooks kan kjøre flere kommandoer. For eksempel med Lefthook: ```yaml # lefthook.yml @@ -89,4 +89,4 @@ pre-commit: run: archgate check --staged ``` -Hver kommando kjorer uavhengig. Hvis en kommando avslutter med en kode som ikke er null, blokkeres committen. +Hver kommando kjører uavhengig. Hvis en kommando avslutter med en kode som ikke er null, blokkeres committen. diff --git a/docs/src/content/docs/nb/guides/security.mdx b/docs/src/content/docs/nb/guides/security.mdx index 9d882a40..2f7a5148 100644 --- a/docs/src/content/docs/nb/guides/security.mdx +++ b/docs/src/content/docs/nb/guides/security.mdx @@ -1,27 +1,27 @@ --- title: Sikkerhet -description: Forstaa Archgate CLIs tillitsmodell, hvordan regler kjores, og beste praksis for aa kjore sjekker trygt i CI/CD og lokal utvikling. +description: Forstå Archgate CLIs tillitsmodell, hvordan regler kjøres, og beste praksis for å kjøre sjekker trygt i CI/CD og lokal utvikling. --- -Archgate kjorer TypeScript-regler fra `.rules.ts`-filer i repositoriet ditt. Denne siden forklarer tillitsmodellen, hva regler kan og ikke kan gjore, og hvordan du kjorer sjekker trygt. +Archgate kjører TypeScript-regler fra `.rules.ts`-filer i repositoriet ditt. Denne siden forklarer tillitsmodellen, hva regler kan og ikke kan gjøre, og hvordan du kjører sjekker trygt. ## Tillitsmodell -**`.rules.ts`-filer er kjoerbar kode.** Naar du kjorer `archgate check`, importerer CLI-en dynamisk hver `.rules.ts`-folgestykke-fil og kjorer `check`-funksjonene. Dette tilsvarer aa kjore `bun .archgate/adrs/*.rules.ts` -- koden har de samme mulighetene som ethvert annet skript paa maskinen din. +**`.rules.ts`-filer er kjørbar kode.** Når du kjører `archgate check`, importerer CLI-en dynamisk hver `.rules.ts`-følgestykke-fil og kjører `check`-funksjonene. Dette tilsvarer å kjøre `bun .archgate/adrs/*.rules.ts` -- koden har de samme mulighetene som ethvert annet skript på maskinen din. Dette betyr: -- Kjor bare `archgate check` paa repositorier du stoler paa. -- Gjennomgaa `.rules.ts`-filer med samme grundighet som all annen kildekode i prosjektet. +- Kjør bare `archgate check` på repositorier du stoler på. +- Gjennomgå `.rules.ts`-filer med samme grundighet som all annen kildekode i prosjektet. - I open source-prosjekter, behandle `.rules.ts`-endringer i pull requests som sikkerhetssensitive. -### Hva regler kan faa tilgang til +### Hva regler kan få tilgang til Regler mottar et `RuleContext`-objekt med sandkassede filoperasjoner. Alle `RuleContext`-metoder (`readFile`, `readJSON`, `grep`, `grepFiles`, `glob`) er begrenset til prosjektets rotkatalog -- stitraversering via `../`, absolutte stier og symbolske lenker er blokkert og kaster en feil. -I tillegg til kjoringsmiljoets sandkasse kjorer Archgate en **statisk analysesikkerhetsskanner** paa hver `.rules.ts`-fil for den kjores. Skanneren parser regelens AST og blokkerer filer som inneholder farlige monstre: +I tillegg til kjøringsmiljøets sandkasse kjører Archgate en **statisk analysesikkerhetsskanner** på hver `.rules.ts`-fil før den kjøres. Skanneren parser regelens AST og blokkerer filer som inneholder farlige mønstre: -| Monster | Blokkert | +| Mønster | Blokkert | | ------------------------------------------------------------------- | -------- | | Import av `node:fs`, `child_process`, `net`, `http`, `vm`, osv. | Ja | | `Bun.spawn()`, `Bun.write()`, `Bun.file()`, `Bun.$` | Ja | @@ -31,26 +31,26 @@ I tillegg til kjoringsmiljoets sandkasse kjorer Archgate en **statisk analysesik | Dynamisk `import()` med ikke-literal argument | Ja | | Tilordning til `globalThis` eller `process.env` | Ja | -Hvis et forbudt monster finnes, blir regelfilen **ikke importert eller kjoert**, og `archgate check` avslutter med en feil. +Hvis et forbudt mønster finnes, blir regelfilen **ikke importert eller kjørt**, og `archgate check` avslutter med en feil. -**Trygge moduler som er tillatt:** `node:path`, `node:url`, `node:util`, `node:crypto` -- dette er verktoymoduler uten filsystem-, nettverks- eller prosess-I/O-funksjonalitet. +**Trygge moduler som er tillatt:** `node:path`, `node:url`, `node:util`, `node:crypto` -- dette er verktøymoduler uten filsystem-, nettverks- eller prosess-I/O-funksjonalitet. -Skanneren hever terskelen fra "trivielt aa utnytte" til "krever bevisst obfuskering som ser mistenkelig ut i kodegjennomgang." Veloppforte regler bruker bare `RuleContext`-metodene (`ctx.readFile`, `ctx.grep`, `ctx.glob`, osv.) og `ctx.report` for utskrift. +Skanneren hever terskelen fra "trivielt å utnytte" til "krever bevisst obfuskering som ser mistenkelig ut i kodegjennomgang." Veloppførte regler bruker bare `RuleContext`-metodene (`ctx.readFile`, `ctx.grep`, `ctx.glob`, osv.) og `ctx.report` for utskrift. -### Hva regler ikke kan gjore +### Hva regler ikke kan gjøre - **Skrive filer** -- `RuleContext`-API-et er skrivebeskyttet. Regler rapporterer brudd, men kan ikke endre kodebasen. - **Unnslippe 30-sekunders tidsgrensen** -- hver regel termineres etter 30 sekunder veggtid. -- **Paavirke andre regler** -- regler fra forskjellige ADR-er kjorer parallelt, men deler ingen mutbar tilstand gjennom kontekst-API-et. -- **Bruke farlige API-er** -- sikkerhetsskanneren blokkerer import av systemmoduler (`fs`, `child_process`, `net`, osv.), Bun-API-er (`Bun.spawn`, `Bun.file`), nettverkstilgang (`fetch`) og kodegenerering (`eval`, `new Function`). Regelfiler som inneholder disse monstrene avvises for kjoring. +- **Påvirke andre regler** -- regler fra forskjellige ADR-er kjører parallelt, men deler ingen mutbar tilstand gjennom kontekst-API-et. +- **Bruke farlige API-er** -- sikkerhetsskanneren blokkerer import av systemmoduler (`fs`, `child_process`, `net`, osv.), Bun-API-er (`Bun.spawn`, `Bun.file`), nettverkstilgang (`fetch`) og kodegenerering (`eval`, `new Function`). Regelfiler som inneholder disse mønstrene avvises før kjøring. ## Beste praksis for CI/CD -Aa kjore `archgate check` i CI er trygt naar du kontrollerer repositoriets innhold. Ekstra forsiktighet er nodvendig for pull requests fra eksterne bidragsytere. +Å kjøre `archgate check` i CI er trygt når du kontrollerer repositoriets innhold. Ekstra forsiktighet er nødvendig for pull requests fra eksterne bidragsytere. -### Paalitelige grener +### Pålitelige grener -For pushes til `main` eller andre beskyttede grener kjorer `archgate check` kode som allerede er gjennomgaatt og merget. Dette er trygt: +For pushes til `main` eller andre beskyttede grener kjører `archgate check` kode som allerede er gjennomgått og merget. Dette er trygt: ```yaml on: @@ -67,9 +67,9 @@ jobs: ### Pull requests fra forks -Naar en pull request kommer fra en fork, kan `.rules.ts`-filene i PR-en inneholde vilkaarlig kode. Dette er den samme risikoen som aa kjore et hvilket som helst ikke-paalitelig CI-skript. +Når en pull request kommer fra en fork, kan `.rules.ts`-filene i PR-en inneholde vilkårlig kode. Dette er den samme risikoen som å kjøre et hvilket som helst ikke-pålitelig CI-skript. -**Alternativ 1: Krev godkjenning for kjoring.** Bruk GitHubs miljoebeskyttelsesregler eller `pull_request_target` med manuell godkjenning for aa gate CI paa gjennomgang: +**Alternativ 1: Krev godkjenning for kjøring.** Bruk GitHubs miljøbeskyttelsesregler eller `pull_request_target` med manuell godkjenning for å gate CI på gjennomgang: ```yaml on: @@ -86,9 +86,9 @@ jobs: - uses: archgate/check-action@v1 ``` -**Alternativ 2: Kjor bare sjekker paa paalitelige filer.** Bruk en separat arbeidsflyt som sjekker ut basisgrenens `.rules.ts`-filer og kjorer dem mot PR-ens kildefiler. Dette sikrer at bare gjennomgaatte regler kjores. +**Alternativ 2: Kjør bare sjekker på pålitelige filer.** Bruk en separat arbeidsflyt som sjekker ut basisgrenens `.rules.ts`-filer og kjører dem mot PR-ens kildefiler. Dette sikrer at bare gjennomgåtte regler kjøres. -**Alternativ 3: Hopp over sjekker paa fork-PR-er.** Hvis reglene dine hovedsakelig er for intern styring, hopp over automatiserte sjekker paa fork-PR-er og kjor dem manuelt etter gjennomgang: +**Alternativ 3: Hopp over sjekker på fork-PR-er.** Hvis reglene dine hovedsakelig er for intern styring, hopp over automatiserte sjekker på fork-PR-er og kjør dem manuelt etter gjennomgang: ```yaml on: @@ -103,9 +103,9 @@ jobs: - uses: archgate/check-action@v1 ``` -### Minst-privilegium-kjorere +### Minst-privilegium-kjørere -Kjor `archgate check` paa kjorere med minimale tilganger. Jobben trenger bare lesetilgang til repositoriet -- ingen hemmeligheter, distribusjonsnokler eller skrivetilganger er nodvendig: +Kjør `archgate check` på kjørere med minimale tilganger. Jobben trenger bare lesetilgang til repositoriet -- ingen hemmeligheter, distribusjonsnøkler eller skrivetilganger er nødvendig: ```yaml jobs: @@ -120,25 +120,25 @@ jobs: ## Lokal utvikling -### Gjennomgaa regler i nye repositorier +### Gjennomgå regler i nye repositorier -Naar du kloner eller forker et repositorium som bruker Archgate, blokkerer sikkerhetsskanneren automatisk farlige monstre i `.rules.ts`-filer. Du bor likevel gjennomgaa regelfiler for du kjorer `archgate check` for forste gang: +Når du kloner eller forker et repositorium som bruker Archgate, blokkerer sikkerhetsskanneren automatisk farlige mønstre i `.rules.ts`-filer. Du bør likevel gjennomgå regelfiler før du kjører `archgate check` for første gang: -- Skanneren fanger eksplisitt bruk av forbudte API-er, men sofistikert obfuskering (f.eks. `Reflect.get(Bun, "spawn")`) kan omgaa den -- Toppnivaa-kode som kjorer ved import (for `check`-funksjonen kalles) kjores fortsatt hvis den bestaar skanneren -- Veloppforte regler bruker bare `RuleContext`-metodene (`ctx.readFile`, `ctx.grep`, `ctx.glob`, osv.) og `ctx.report` for utskrift +- Skanneren fanger eksplisitt bruk av forbudte API-er, men sofistikert obfuskering (f.eks. `Reflect.get(Bun, "spawn")`) kan omgå den +- Toppnivå-kode som kjører ved import (før `check`-funksjonen kalles) kjøres fortsatt hvis den består skanneren +- Veloppførte regler bruker bare `RuleContext`-metodene (`ctx.readFile`, `ctx.grep`, `ctx.glob`, osv.) og `ctx.report` for utskrift ### Legitimasjon Kommandoen `archgate login` lagrer autentiseringstokenet ditt i operativsystemets legitimasjonsbehandler (macOS Keychain, Windows Credential Manager eller Linux libsecret) via `git credential approve`. Ingen legitimasjon skrives til disk som klartekstfiler. Tokenet brukes for plugin-installasjon og sendes aldri til tredjeparter utover Archgate plugins-tjenesten. -- Del ikke tokenet i CI-logger. Plugin-installasjonskommandoer sender legitimasjon via autentiserte URL-er til git, som kan dukke opp i prosesslister. Unngaa aa kjore `archgate plugin install` med detaljert logging i delte CI-miljoer. -- For aa tilbakekalle tilgang, kjor `archgate login logout`. +- Del ikke tokenet i CI-logger. Plugin-installasjonskommandoer sender legitimasjon via autentiserte URL-er til git, som kan dukke opp i prosesslister. Unngå å kjøre `archgate plugin install` med detaljert logging i delte CI-miljøer. +- For å tilbakekalle tilgang, kjør `archgate login logout`. ### Selvoppdateringsintegritet -Naar du kjorer `archgate upgrade`, laster CLI-en ned utgivelsesbinaeeren fra GitHub Releases og verifiserer SHA256-sjekksummen for den pakkes ut. Hvis sjekksummen ikke stemmer, avbrytes oppgraderingen. Dette beskytter mot manipulerte nedlastinger paa grunn av nettverksavlytting eller kompromitterte speil. +Når du kjører `archgate upgrade`, laster CLI-en ned utgivelsesbinæren fra GitHub Releases og verifiserer SHA256-sjekksummen før den pakkes ut. Hvis sjekksummen ikke stemmer, avbrytes oppgraderingen. Dette beskytter mot manipulerte nedlastinger på grunn av nettverksavlytting eller kompromitterte speil. -## Rapportere saaerbarheter +## Rapportere sårbarheter -Hvis du oppdager et sikkerhetsproblem i Archgate, vennligst rapporter det ansvarlig ved aa aapne en [GitHub-sak](https://github.com/archgate/cli/issues) eller kontakte vedlikeholderne direkte. Ikke inkluder utnyttelseskode i offentlige saker. +Hvis du oppdager et sikkerhetsproblem i Archgate, vennligst rapporter det ansvarlig ved å åpne en [GitHub-sak](https://github.com/archgate/cli/issues) eller kontakte vedlikeholderne direkte. Ikke inkluder utnyttelseskode i offentlige saker. diff --git a/docs/src/content/docs/nb/guides/vscode-plugin.mdx b/docs/src/content/docs/nb/guides/vscode-plugin.mdx index 1f0b9f65..389fd41c 100644 --- a/docs/src/content/docs/nb/guides/vscode-plugin.mdx +++ b/docs/src/content/docs/nb/guides/vscode-plugin.mdx @@ -3,37 +3,37 @@ title: VS Code-plugin description: Installer Archgate VS Code-utvidelsen for AI-assistert utvikling med arkitekturstyring. Sanntids ADR-samsvarskontroll i editoren din. --- -Archgate VS Code-pluginet gir AI-agenter som jobber i [VS Code](https://code.visualstudio.com/) en strukturert styringsarbeidsflyt. Agenter leser ADR-ene dine for de skriver kode, validerer etterpaa, og fanger opp nye monstre for teamet -- den samme arbeidsflyten som er tilgjengelig i [Claude Code-pluginet](/guides/claude-code-plugin/). +Archgate VS Code-pluginet gir AI-agenter som jobber i [VS Code](https://code.visualstudio.com/) en strukturert styringsarbeidsflyt. Agenter leser ADR-ene dine før de skriver kode, validerer etterpå, og fanger opp nye mønstre for teamet -- den samme arbeidsflyten som er tilgjengelig i [Claude Code-pluginet](/guides/claude-code-plugin/). ## Hvordan det fungerer -VS Code stotter **agent-plugins** installert fra git-baserte markedsplasser. Archgate-pluginet serveres fra et git-repositorium paa `plugins.archgate.dev/archgate/vscode.git`. Naar du legger til denne markedsplassen i VS Code-brukerinnstillingene dine, oppdager og installerer VS Code pluginet automatisk. +VS Code støtter **agent-plugins** installert fra git-baserte markedsplasser. Archgate-pluginet serveres fra et git-repositorium på `plugins.archgate.dev/archgate/vscode.git`. Når du legger til denne markedsplassen i VS Code-brukerinnstillingene dine, oppdager og installerer VS Code pluginet automatisk. Pluginet serveres i VS Code Copilots opprinnelige `.github/plugin/`-manifestformat, adskilt fra Claude Code `.claude-plugin/`-formatet. ## Installasjon :::caution[Krav til VS Code-versjon] -Agent-plugins krever **VS Code 1.110 (februar 2026-utgivelsen) eller nyere**. Tidligere versjoner stotter ikke git-baserte agent-plugin-markedsplasser. Sjekk versjonen din med `code --version`. +Agent-plugins krever **VS Code 1.110 (februar 2026-utgivelsen) eller nyere**. Tidligere versjoner støtter ikke git-baserte agent-plugin-markedsplasser. Sjekk versjonen din med `code --version`. ::: :::note[Betatilgang kreves] -VS Code-pluginet er for oyeblikket i beta. Kjor `archgate login` for aa registrere deg og autentisere for du folger trinnene nedenfor. +VS Code-pluginet er for øyeblikket i beta. Kjør `archgate login` for å registrere deg og autentisere før du følger trinnene nedenfor. ::: ### 1. Logg inn med GitHub -Autentiser med GitHub-kontoen din for aa faa et plugin-token: +Autentiser med GitHub-kontoen din for å få et plugin-token: ```bash archgate login ``` -Dette starter en GitHub Device Flow. CLI-en viser en engangskode og URL -- aapne URL-en i nettleseren din, skriv inn koden, og autoriser. Naar det er fullfort, lagres legitimasjonen sikkert i operativsystemets legitimasjonsbehandler via `git credential approve`. +Dette starter en GitHub Device Flow. CLI-en viser en engangskode og URL -- åpne URL-en i nettleseren din, skriv inn koden, og autoriser. Når det er fullført, lagres legitimasjonen sikkert i operativsystemets legitimasjonsbehandler via `git credential approve`. ### 2. Initialiser prosjektet ditt med pluginet -Kjor `archgate init` med `--editor vscode`-flagget: +Kjør `archgate init` med `--editor vscode`-flagget: ```bash archgate init --editor vscode @@ -45,7 +45,7 @@ Hvis du allerede er logget inn, vil denne kommandoen: 2. Legge til den autentiserte markedsplassens URL i VS Code-**brukerinnstillingene** dine 3. Laste ned og installere Archgate VS Code-utvidelsen (`.vsix`) hvis `code`-CLI-en er tilgjengelig -Innstillingen `chat.plugins.marketplaces` er applikasjonsscopet i VS Code, saa den kan ikke settes per arbeidsomraade. CLI-en skriver den automatisk til `settings.json` paa brukernivaa: +Innstillingen `chat.plugins.marketplaces` er applikasjonsscopet i VS Code, så den kan ikke settes per arbeidsområde. CLI-en skriver den automatisk til `settings.json` på brukernivå: | Plattform | Sti til brukerinnstillinger | | --------- | ------------------------------------------------------- | @@ -53,13 +53,13 @@ Innstillingen `chat.plugins.marketplaces` er applikasjonsscopet i VS Code, saa d | macOS | `~/Library/Application Support/Code/User/settings.json` | | Linux | `~/.config/Code/User/settings.json` | -For aa eksplisitt be om plugin-installasjon: +For å eksplisitt be om plugin-installasjon: ```bash archgate init --editor vscode --install-plugin ``` -For aa installere eller reinstallere pluginet paa et allerede initialisert prosjekt: +For å installere eller reinstallere pluginet på et allerede initialisert prosjekt: ```bash archgate plugin install --editor vscode @@ -67,18 +67,18 @@ archgate plugin install --editor vscode ### Genererte filer -Kommandoen oppretter eller oppdaterer folgende: +Kommandoen oppretter eller oppdaterer følgende: -| Fil | Omfang | Formaal | +| Fil | Omfang | Formål | | ---------------------- | ----------- | ------------------------------------------------------- | | Bruker `settings.json` | Bruker | `chat.plugins.marketplaces` med den autentiserte URL-en | | Archgate-utvidelse | Applikasjon | VS Code-utvidelse installert via `.vsix` | -Brukerinnstillingsfilen flettes additivt -- eksisterende innstillinger overskrives aldri. VS Codes innebygde standardmarkedsplasser (`github/copilot-plugins`, `github/awesome-copilot`) bevares naar nokkelen settes for forste gang. +Brukerinnstillingsfilen flettes additivt -- eksisterende innstillinger overskrives aldri. VS Codes innebygde standardmarkedsplasser (`github/copilot-plugins`, `github/awesome-copilot`) bevares når nøkkelen settes for første gang. VS Code-utvidelsen lastes ned fra Archgate plugins-tjenesten og installeres via `code --install-extension`. Hvis `code`-CLI-en ikke er tilgjengelig, skrives instruksjoner for manuell installasjon ut. -Markedsplassinnstillingen paa brukernivaa (lagt til i `settings.json`): +Markedsplassinnstillingen på brukernivå (lagt til i `settings.json`): ```json { @@ -92,7 +92,7 @@ Markedsplassinnstillingen paa brukernivaa (lagt til i `settings.json`): Hvis du foretrekker at CLI-en ikke endrer brukerinnstillingene dine, kan du sette opp ting manuelt: -**Markedsplassens URL:** Aapne VS Codes brukerinnstillinger-JSON (`Ctrl+Shift+P` -> "Preferences: Open User Settings (JSON)") og legg til `chat.plugins.marketplaces`-oppforingen vist ovenfor. Du kan finne den autentiserte URL-en din ved aa kjore `archgate plugin url vscode`. +**Markedsplassens URL:** Åpne VS Codes brukerinnstillinger-JSON (`Ctrl+Shift+P` -> "Preferences: Open User Settings (JSON)") og legg til `chat.plugins.marketplaces`-oppføringen vist ovenfor. Du kan finne den autentiserte URL-en din ved å kjøre `archgate plugin url vscode`. **Utvidelse:** Last ned og installer `.vsix`-filen direkte: @@ -110,39 +110,39 @@ Pluginet legger til en agent og rollebaserte ferdigheter i VS Codes AI. Agenten ### Agent -| Agent | Formaal | -| -------------------- | -------------------------------------------------------------------------- | -| `archgate:developer` | Generell utviklingsagent som leser ADR-er for koding og validerer etterpaa | +| Agent | Formål | +| -------------------- | ------------------------------------------------------------------------- | +| `archgate:developer` | Generell utviklingsagent som leser ADR-er før koding og validerer etterpå | `archgate:developer`-agenten er satt som standardagent via plugin-innstillingene. Den orkestrerer ferdighetene nedenfor automatisk som en del av arbeidsflyten. ### Ferdigheter -| Ferdighet | Formaal | +| Ferdighet | Formål | | -------------------------- | --------------------------------------------------------------------------------------- | | `archgate:architect` | Validerer kodeendringer mot alle prosjektets ADR-er for strukturell samsvar | -| `archgate:quality-manager` | Gjennomgaar regeldekning og foreslar nye ADR-er naar monstre dukker opp | +| `archgate:quality-manager` | Gjennomgår regeldekning og foreslår nye ADR-er når mønstre dukker opp | | `archgate:adr-author` | Oppretter og redigerer ADR-er i henhold til prosjektets konvensjoner | | `archgate:onboard` | Engangsoppsett: utforsker kodebasen, intervjuer utvikleren, oppretter innledende ADR-er | -## Forste oppsett med onboard +## Første oppsett med onboard -Etter installasjon, kjor `archgate:onboard`-ferdigheten i prosjektet ditt en gang. Denne ferdigheten: +Etter installasjon, kjør `archgate:onboard`-ferdigheten i prosjektet ditt en gang. Denne ferdigheten: -1. Utforsker kodebasestrukturen din (mapper, nokkelfiler, pakkekonfigurasjon) +1. Utforsker kodebasestrukturen din (mapper, nøkkelfiler, pakkekonfigurasjon) 2. Intervjuer deg om teamets konvensjoner, begrensninger og arkitekturbeslutninger -3. Oppretter et innledende sett med ADR-er basert paa svarene dine -4. Setter opp `.archgate/`-mappen med de forste reglene dine +3. Oppretter et innledende sett med ADR-er basert på svarene dine +4. Setter opp `.archgate/`-mappen med de første reglene dine -Onboard-ferdigheten er designet for aa kjores en gang per prosjekt. Etter onboarding handterer de andre ferdighetene daglig utvikling. +Onboard-ferdigheten er designet for å kjøres en gang per prosjekt. Etter onboarding håndterer de andre ferdighetene daglig utvikling. ## Hvordan det fungerer i praksis -Pluginet folger en strukturert arbeidsflyt for hver kodeoppgave: +Pluginet følger en strukturert arbeidsflyt for hver kodeoppgave: ### 1. Les gjeldende ADR-er -Naar utvikleren gir en kodeoppgave, kjorer agenten `archgate review-context` for aa lese alle ADR-er som gjelder for filene som endres. Dette gir en komprimert briefing med **Decision**- og **Do's and Don'ts**-seksjonene fra hver relevante ADR. +Når utvikleren gir en kodeoppgave, kjører agenten `archgate review-context` for å lese alle ADR-er som gjelder for filene som endres. Dette gir en komprimert briefing med **Decision**- og **Do's and Don'ts**-seksjonene fra hver relevante ADR. ### 2. Skriv kode i henhold til ADR-begrensninger @@ -150,18 +150,18 @@ Agenten skriver kode som samsvarer med begrensningene fra ADR-ene. Do's and Don' ### 3. Valider endringer -Etter aa ha skrevet kode, kjorer agenten `archgate check` for aa utfore automatiserte regler mot endringene. Eventuelle brudd utbedres for man gaar videre. +Etter å ha skrevet kode, kjører agenten `archgate check` for å utføre automatiserte regler mot endringene. Eventuelle brudd utbedres før man går videre. ### 4. Arkitektgjennomgang -Agenten aktiverer `archgate:architect` for aa validere strukturelt ADR-samsvar utover det automatiserte regler fanger opp. +Agenten aktiverer `archgate:architect` for å validere strukturelt ADR-samsvar utover det automatiserte regler fanger opp. -### 5. Fang opp laeringer +### 5. Fang opp læringer -Agenten aktiverer `archgate:quality-manager` for aa gjennomgaa arbeidet og identifisere monstre som er verdt aa fange opp som nye ADR-er. +Agenten aktiverer `archgate:quality-manager` for å gjennomgå arbeidet og identifisere mønstre som er verdt å fange opp som nye ADR-er. ## Tips -- **Hver utvikler kjorer `archgate init --editor vscode`** etter `archgate login` for aa konfigurere markedsplassens URL paa brukernivaa. -- **Kjor onboard en gang per prosjekt** for aa generere de innledende ADR-ene fra den faktiske kodebasen din. -- **Hold ADR-regelfiler oppdatert** -- agenten haandterer det reglene sjekker for. +- **Hver utvikler kjører `archgate init --editor vscode`** etter `archgate login` for å konfigurere markedsplassens URL på brukernivå. +- **Kjør onboard en gang per prosjekt** for å generere de innledende ADR-ene fra den faktiske kodebasen din. +- **Hold ADR-regelfiler oppdatert** -- agenten håndterer det reglene sjekker for. diff --git a/docs/src/content/docs/nb/reference/adr-schema.mdx b/docs/src/content/docs/nb/reference/adr-schema.mdx index 6e0892d2..de631f29 100644 --- a/docs/src/content/docs/nb/reference/adr-schema.mdx +++ b/docs/src/content/docs/nb/reference/adr-schema.mdx @@ -7,7 +7,7 @@ Hver Archgate ADR er en Markdown-fil lagret i `.archgate/adrs/` med YAML frontma ## Frontmatter-skjema -YAML frontmatter-blokken ligger mellom `---`-skilletegn overst i filen. +YAML frontmatter-blokken ligger mellom `---`-skilletegn øverst i filen. ```yaml --- @@ -21,44 +21,44 @@ files: ["src/commands/**/*.ts"] ### Felt -| Felt | Type | Pakrevd | Beskrivelse | +| Felt | Type | Påkrevd | Beskrivelse | | ------------------ | ---------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `id` | `string` | Ja | Unik identifikator. Ma vaere ikke-tom. Konvensjon: `PREFIX-NNN` (f.eks. `ARCH-001`). | -| `title` | `string` | Ja | Lesbar tittel pa beslutningen. Ma vaere ikke-tom. | -| `domain` | `string` | Ja | Et registrert domenenavn i kebab-case med sma bokstaver. Innebygde: `backend`, `frontend`, `data`, `architecture`, `general`. Egendefinerte domener registreres via [`archgate adr domain add`](/reference/cli/adr/#archgate-adr-domain). | -| `rules` | `boolean` | Ja | Om denne ADR-en har en tilhorende `.rules.ts`-fil med automatiserte kontroller. | -| `files` | `string[]` | Nei | Globmonstre som avgrenser hvilke filer reglene gjelder for. | +| `id` | `string` | Ja | Unik identifikator. Må være ikke-tom. Konvensjon: `PREFIX-NNN` (f.eks. `ARCH-001`). | +| `title` | `string` | Ja | Lesbar tittel på beslutningen. Må være ikke-tom. | +| `domain` | `string` | Ja | Et registrert domenenavn i kebab-case med små bokstaver. Innebygde: `backend`, `frontend`, `data`, `architecture`, `general`. Egendefinerte domener registreres via [`archgate adr domain add`](/reference/cli/adr/#archgate-adr-domain). | +| `rules` | `boolean` | Ja | Om denne ADR-en har en tilhørende `.rules.ts`-fil med automatiserte kontroller. | +| `files` | `string[]` | Nei | Globmønstre som avgrenser hvilke filer reglene gjelder for. | | `respectGitignore` | `boolean` | Nei | Om `.gitignore`-filer skal filtreres bort. Standard er `true`. | ### id ADR-identifikatoren. Etter konvensjon brukes domeneprefikset etterfulgt av et null-utfylt sekvensnummer (f.eks. `ARCH-001`, `BE-003`). Kommandoen `archgate adr create` genererer ID-er automatisk. -Enhver ikke-tom streng er gyldig, men a folge prefikskonvensjonen holder ADR-ene organisert og sorterbare. +Enhver ikke-tom streng er gyldig, men å følge prefikskonvensjonen holder ADR-ene organisert og sorterbare. ### title -Et kort, beskrivende navn for den arkitektoniske beslutningen. Vises i `archgate adr list`-utdata og brukes som overskrift nar AI-agenter refererer til ADR-en. +Et kort, beskrivende navn for den arkitektoniske beslutningen. Vises i `archgate adr list`-utdata og brukes som overskrift når AI-agenter refererer til ADR-en. ### domain -Grupperer relaterte ADR-er sammen. Domenet bestemmer ogsa ID-prefikset som brukes av `archgate adr create`. +Grupperer relaterte ADR-er sammen. Domenet bestemmer også ID-prefikset som brukes av `archgate adr create`. -Prosjekter kan utvide det innebygde settet med egendefinerte domener via [`archgate adr domain add`](/reference/cli/adr/#archgate-adr-domain). Egendefinerte domene-til-prefiks-tilordninger lagres i `.archgate/config.json` og slAs sammen med de innebygde ved lesing. +Prosjekter kan utvide det innebygde settet med egendefinerte domener via [`archgate adr domain add`](/reference/cli/adr/#archgate-adr-domain). Egendefinerte domene-til-prefiks-tilordninger lagres i `.archgate/config.json` og slås sammen med de innebygde ved lesing. ### rules -Sett til `true` nar denne ADR-en har en tilhorende `.rules.ts`-fil. Nar `archgate check` kjorer, hopper den over ADR-er der `rules` er `false`. +Sett til `true` når denne ADR-en har en tilhørende `.rules.ts`-fil. Når `archgate check` kjører, hopper den over ADR-er der `rules` er `false`. ### files -En valgfri matrise med globmonstre som avgrenser regelens fildekning. Nar den er til stede, inneholder `ctx.scopedFiles` i regelfilen kun filer som matcher disse monstrene. Nar den er fravarende, er alle prosjektfiler i omfang. +En valgfri matrise med globmønstre som avgrenser regelens fildekning. Når den er til stede, inneholder `ctx.scopedFiles` i regelfilen kun filer som matcher disse mønstrene. Når den er fraværende, er alle prosjektfiler i omfang. ```yaml files: ["src/commands/**/*.ts"] ``` -Flere monstre kan spesifiseres: +Flere mønstre kan spesifiseres: ```yaml files: ["src/api/**/*.ts", "src/middleware/**/*.ts"] @@ -66,16 +66,16 @@ files: ["src/api/**/*.ts", "src/middleware/**/*.ts"] ### respectGitignore -Styrer om `.gitignore`-filer ekskluderes fra `ctx.scopedFiles`, `ctx.glob()` og `ctx.grepFiles()`. Standard er `true` nar feltet utelates -- gitignorerte filer (f.eks. `node_modules/`, `dist/`) filtreres automatisk bort. +Styrer om `.gitignore`-filer ekskluderes fra `ctx.scopedFiles`, `ctx.glob()` og `ctx.grepFiles()`. Standard er `true` når feltet utelates -- gitignorerte filer (f.eks. `node_modules/`, `dist/`) filtreres automatisk bort. -Sett til `false` nar en regel med vilje trenger a inspisere ignorerte filer, for eksempel for a sjekke strukturen pa byggeutdata: +Sett til `false` når en regel med vilje trenger å inspisere ignorerte filer, for eksempel for å sjekke strukturen på byggeutdata: ```yaml respectGitignore: false files: ["dist/**/*.js"] ``` -Nar `respectGitignore` er `false`, inkluderes alle filer som matcher `files`-globene uavhengig av `.gitignore`-regler. Nar man ikke er inne i et git-repository, har dette feltet ingen effekt -- alle matchede filer inkluderes. +Når `respectGitignore` er `false`, inkluderes alle filer som matcher `files`-globene uavhengig av `.gitignore`-regler. Når man ikke er inne i et git-repository, har dette feltet ingen effekt -- alle matchede filer inkluderes. --- @@ -93,23 +93,23 @@ Hvert domene tilordnes et prefiks som brukes i ADR-ID-konvensjonen. | `architecture` | `ARCH` | `ARCH-001` | | `general` | `GEN` | `GEN-001` | -Kommandoen `archgate adr create` bruker denne tilordningen til a autogenerere ID-er. +Kommandoen `archgate adr create` bruker denne tilordningen til å autogenerere ID-er. ### Egendefinerte domener -Prosjekter kan registrere ytterligere domene-til-prefiks-tilordninger via [`archgate adr domain add`](/reference/cli/adr/#archgate-adr-domain). Nar de er registrert, oppforer egendefinerte domener seg som innebygde: `archgate adr create --domain ` autogenererer ID-er med det tilhorende prefikset, og ADR-er med egendefinerte domener parses uten problemer. +Prosjekter kan registrere ytterligere domene-til-prefiks-tilordninger via [`archgate adr domain add`](/reference/cli/adr/#archgate-adr-domain). Når de er registrert, oppfører egendefinerte domener seg som innebygde: `archgate adr create --domain ` autogenererer ID-er med det tilhørende prefikset, og ADR-er med egendefinerte domener parses uten problemer. -Se [konseptsiden for domener](/concepts/domains/) for veiledning om nar du bor introdusere et egendefinert domene. +Se [konseptsiden for domener](/concepts/domains/) for veiledning om når du bør introdusere et egendefinert domene. --- ## Konvensjon for filnavn -ADR-filer folger en navnekonvensjon som koder inn ID-en og en lesbar slug: +ADR-filer følger en navnekonvensjon som koder inn ID-en og en lesbar slug: ``` {ID}-{slug}.md # Dokumentet -{ID}-{slug}.rules.ts # Den tilhorende regelfilen (valgfri) +{ID}-{slug}.rules.ts # Den tilhørende regelfilen (valgfri) ``` For eksempel: @@ -125,11 +125,11 @@ Slugen er en kebab-case-versjon av tittelen, autogenerert av `archgate adr creat ## Markdown-seksjoner -Etter frontmatter folger ADR-kroppen en standard seksjonsstruktur. Selv om Archgate ikke pahvinger spesifikke seksjoner, anbefales folgende struktur for konsistens. +Etter frontmatter følger ADR-kroppen en standard seksjonsstruktur. Selv om Archgate ikke påtvinger spesifikke seksjoner, anbefales følgende struktur for konsistens. ### Context -Beskriver problemet eller situasjonen som utloste beslutningen. Inkluder alternativer som ble vurdert og hvorfor de ble forkastet. +Beskriver problemet eller situasjonen som utløste beslutningen. Inkluder alternativer som ble vurdert og hvorfor de ble forkastet. ```markdown ## Context @@ -148,7 +148,7 @@ custom formatting. ### Decision -Angir selve beslutningen og dens viktigste begrensninger. Dette er den primaere seksjonen AI-agenter leser for de skriver kode. +Angir selve beslutningen og dens viktigste begrensninger. Dette er den primære seksjonen AI-agenter leser før de skriver kode. ```markdown ## Decision @@ -202,7 +202,7 @@ Delt i tre underseksjoner som dokumenterer avveininger. ### Compliance and Enforcement -Beskriver hvordan beslutningen handheves gjennom automatiserte regler og manuell gjennomgang. +Beskriver hvordan beslutningen håndheves gjennom automatiserte regler og manuell gjennomgang. ```markdown ## Compliance and Enforcement @@ -233,16 +233,16 @@ Lenker til relaterte ADR-er, ekstern dokumentasjon eller designdokumenter. --- -## Tilhorende regelfil +## Tilhørende regelfil -Nar `rules: true`, leter Archgate etter en tilhorende fil med samme navn men `.rules.ts`-endelse. +Når `rules: true`, leter Archgate etter en tilhørende fil med samme navn men `.rules.ts`-endelse. ``` ARCH-002-error-handling.md # rules: true i frontmatter -ARCH-002-error-handling.rules.ts # tilhorende regelfil +ARCH-002-error-handling.rules.ts # tilhørende regelfil ``` -Regelfilen ma eksportere et standard `RuleSet` ved hjelp av et vanlig objekt med `satisfies RuleSet`: +Regelfilen må eksportere et standard `RuleSet` ved hjelp av et vanlig objekt med `satisfies RuleSet`: ```typescript /// @@ -275,11 +275,11 @@ Se [Rule API](/reference/rule-api/) for den komplette TypeScript API-referansen. ## Validering -YAML frontmatter valideres ved parsetidspunkt ved hjelp av et Zod-skjema. Ugyldig frontmatter forarsakar en parsefeil med en beskrivende melding. +YAML frontmatter valideres ved parsetidspunkt ved hjelp av et Zod-skjema. Ugyldig frontmatter forårsaker en parsefeil med en beskrivende melding. -### Pakrevde felt +### Påkrevde felt -Hvis et pakrevd felt mangler, feiler ADR-parsingen: +Hvis et påkrevd felt mangler, feiler ADR-parsingen: ``` Invalid ADR frontmatter in ARCH-001-example.md: @@ -295,7 +295,7 @@ Invalid ADR frontmatter in ARCH-001-example.md: - domain: domain must be lowercase kebab-case (e.g. 'backend', 'ml-ops') ``` -Merk: parseren aksepterer ethvert navn som matcher kebab-case-monsteret. Om et spesifikt navn er "kjent" for prosjektet -- og dermed har et prefiks som `archgate adr create` kan bruke -- avhenger av det innebygde settet pluss eventuelle egendefinerte domener registrert via [`archgate adr domain add`](/reference/cli/adr/#archgate-adr-domain). A opprette en ADR med et uregistrert domenenavn feiler med en "Unknown ADR domain"-feil som foreslar a kjore `archgate adr domain add`. +Merk: parseren aksepterer ethvert navn som matcher kebab-case-mønsteret. Om et spesifikt navn er "kjent" for prosjektet -- og dermed har et prefiks som `archgate adr create` kan bruke -- avhenger av det innebygde settet pluss eventuelle egendefinerte domener registrert via [`archgate adr domain add`](/reference/cli/adr/#archgate-adr-domain). Å opprette en ADR med et uregistrert domenenavn feiler med en "Unknown ADR domain"-feil som foreslår å kjøre `archgate adr domain add`. ### Typefeil diff --git a/docs/src/content/docs/nb/reference/cli/doctor.mdx b/docs/src/content/docs/nb/reference/cli/doctor.mdx index e32ec0ff..3f971f7d 100644 --- a/docs/src/content/docs/nb/reference/cli/doctor.mdx +++ b/docs/src/content/docs/nb/reference/cli/doctor.mdx @@ -1,9 +1,9 @@ --- title: archgate doctor -description: "Sjekk systemmiljoet, installasjonsmetoden og editor-integrasjoner." +description: "Sjekk systemmiljøet, installasjonsmetoden og editor-integrasjoner." --- -Sjekk systemmiljoet, installasjonsmetoden og editor-integrasjoner. Nyttig for å diagnostisere konfigurasjonsproblemer og dele feilsokingskontekst i feilrapporter. +Sjekk systemmiljøet, installasjonsmetoden og editor-integrasjoner. Nyttig for å diagnostisere konfigurasjonsproblemer og dele feilsøkingskontekst i feilrapporter. ```bash archgate doctor [options] diff --git a/docs/src/content/docs/nb/reference/cli/index.mdx b/docs/src/content/docs/nb/reference/cli/index.mdx index efd958ef..45773643 100644 --- a/docs/src/content/docs/nb/reference/cli/index.mdx +++ b/docs/src/content/docs/nb/reference/cli/index.mdx @@ -24,10 +24,10 @@ archgate check --help | [`archgate login`](./login/) | Autentiser med GitHub | | [`archgate init`](./init/) | Initialiser Archgate-styring | | [`archgate plugin`](./plugin/) | Administrer editor-plugins | -| [`archgate check`](./check/) | Kjor ADR-samsvarskontroller | +| [`archgate check`](./check/) | Kjør ADR-samsvarskontroller | | [`archgate adr`](./adr/) | Opprett, list, vis og oppdater ADR-er | | [`archgate review-context`](./review-context/) | Forhåndsberegn gjennomgangskontekst for CI/editor-integrasjoner | | [`archgate session-context`](./session-context/) | Les AI-editor-sesjonslogger | | [`archgate upgrade`](./upgrade/) | Oppgrader Archgate til nyeste versjon | -| [`archgate doctor`](./doctor/) | Sjekk systemmiljo og editor-integrasjoner | +| [`archgate doctor`](./doctor/) | Sjekk systemmiljø og editor-integrasjoner | | [`archgate clean`](./clean/) | Fjern CLI-hurtigbufferkatalogen | diff --git a/docs/src/content/docs/nb/reference/cli/telemetry.mdx b/docs/src/content/docs/nb/reference/cli/telemetry.mdx index 24ddf0ec..1fd80e36 100644 --- a/docs/src/content/docs/nb/reference/cli/telemetry.mdx +++ b/docs/src/content/docs/nb/reference/cli/telemetry.mdx @@ -9,7 +9,7 @@ Administrer anonym bruksdatainnsamling for Archgate CLI. Telemetri er opt-out: a archgate telemetry ``` -Se [CLI-telemetri](/reference/telemetry/) for den fullstendige personvernpolicyen, listen over hendelser som sendes, og hvordan telemetri samhandler med `ARCHGATE_TELEMETRY=0` og CI-miljoer. +Se [CLI-telemetri](/reference/telemetry/) for den fullstendige personvernpolicyen, listen over hendelser som sendes, og hvordan telemetri samhandler med `ARCHGATE_TELEMETRY=0` og CI-miljøer. ## Underkommandoer @@ -57,9 +57,9 @@ archgate telemetry enable Telemetry enabled. Thank you for helping improve Archgate. ``` -## Overstyring via miljovariabel +## Overstyring via miljøvariabel -Å sette `ARCHGATE_TELEMETRY=0` (eller `false`, `no`, `off`, uavhengig av store/små bokstaver) deaktiverer telemetri for en enkelt kjøring uavhengig av den lagrede tilstanden. Bruk dette i CI eller delte miljoer der du ønsker fravalg uten å endre brukerens konfigurasjon: +Å sette `ARCHGATE_TELEMETRY=0` (eller `false`, `no`, `off`, uavhengig av store/små bokstaver) deaktiverer telemetri for en enkelt kjøring uavhengig av den lagrede tilstanden. Bruk dette i CI eller delte miljøer der du ønsker fravalg uten å endre brukerens konfigurasjon: ```bash ARCHGATE_TELEMETRY=0 archgate check @@ -71,4 +71,4 @@ ARCHGATE_TELEMETRY=0 archgate check Telemetry is disabled (ARCHGATE_TELEMETRY environment variable). ``` -Når overstyringen er aktiv og du kjører `archgate telemetry enable`, lagres opt-in, men det skrives ut en merknad om at miljovariabelen fortsetter å deaktivere telemetri til den fjernes. +Når overstyringen er aktiv og du kjører `archgate telemetry enable`, lagres opt-in, men det skrives ut en merknad om at miljøvariabelen fortsetter å deaktivere telemetri til den fjernes. diff --git a/docs/src/content/docs/nb/reference/configuration.mdx b/docs/src/content/docs/nb/reference/configuration.mdx index 98fc18df..ee078fe0 100644 --- a/docs/src/content/docs/nb/reference/configuration.mdx +++ b/docs/src/content/docs/nb/reference/configuration.mdx @@ -1,11 +1,11 @@ --- title: Konfigurasjon -description: Referanse for prosjektkonfigurasjonsfilen .archgate/config.json. Konfigurer egendefinerte ADR-kataloger, domenetilordninger og innstillinger pa prosjektniva. +description: Referanse for prosjektkonfigurasjonsfilen .archgate/config.json. Konfigurer egendefinerte ADR-kataloger, domenetilordninger og innstillinger på prosjektnivå. --- -Filen `.archgate/config.json` lagrer konfigurasjon pa prosjektniva som committes til versjonskontroll og deles pa tvers av teamet. +Filen `.archgate/config.json` lagrer konfigurasjon på prosjektnivå som committes til versjonskontroll og deles på tvers av teamet. -Denne filen opprettes automatisk av `archgate init` (for a lagre den autodetekterte basisgrenen og eventuelle egendefinerte domener) eller nar du legger til konfigurasjon manuelt. Den ligger inne i `.archgate/`-katalogen i prosjektroten din. +Denne filen opprettes automatisk av `archgate init` (for å lagre den autodetekterte basisgrenen og eventuelle egendefinerte domener) eller når du legger til konfigurasjon manuelt. Den ligger inne i `.archgate/`-katalogen i prosjektroten din. ## Skjema @@ -21,29 +21,29 @@ Denne filen opprettes automatisk av `archgate init` (for a lagre den autodetekte Egendefinerte domene-til-prefiks-tilordninger. Se [Egendefinerte domener](/concepts/domains/#custom-domains) for detaljer. -| Nokkel | Type | Beskrivelse | +| Nøkkel | Type | Beskrivelse | | ------ | -------- | --------------------------------------------------------------------------------------------------------- | -| _navn_ | `string` | Domenenavn (kebab-case med sma bokstaver, 2-32 tegn) tilordnes et ID-prefiks (store bokstaver, 2-10 tegn) | +| _navn_ | `string` | Domenenavn (kebab-case med små bokstaver, 2-32 tegn) tilordnes et ID-prefiks (store bokstaver, 2-10 tegn) | -Disse slas sammen med de innebygde domenene (`backend`, `frontend`, `data`, `architecture`, `general`) ved lesing. Egendefinerte oppforinger kan ikke overstyre innebygde navn eller prefikser. +Disse slås sammen med de innebygde domenene (`backend`, `frontend`, `data`, `architecture`, `general`) ved lesing. Egendefinerte oppføringer kan ikke overstyre innebygde navn eller prefikser. ### `baseBranch` -Basisgren for endringsdeteksjon i `archgate check`. Nar dette er satt, hopper `archgate check` over autodeksjonsprobing og bruker denne verdien direkte for populering av `ctx.changedFiles` via `git diff ...HEAD`. +Basisgren for endringsdeteksjon i `archgate check`. Når dette er satt, hopper `archgate check` over autodeksjonsprobing og bruker denne verdien direkte for populering av `ctx.changedFiles` via `git diff ...HEAD`. | Type | Standard | Beskrivelse | | -------- | ---------------- | ------------------------------------------------------------ | | `string` | _(autodetekter)_ | Grennavn eller fjernreferanse (f.eks. `main`, `origin/main`) | -Dette feltet **fylles automatisk** av `archgate init` nar et git-repository detekteres. Autodeteksjonen provar `origin/HEAD`, `origin/main`, `origin/master`, lokal `main` og lokal `master` (forste treff vinner). A kjore `archgate init` pa nytt overskriver ikke en manuelt konfigurert verdi. +Dette feltet **fylles automatisk** av `archgate init` når et git-repository detekteres. Autodeteksjonen prøver `origin/HEAD`, `origin/main`, `origin/master`, lokal `main` og lokal `master` (første treff vinner). Å kjøre `archgate init` på nytt overskriver ikke en manuelt konfigurert verdi. -Du kan ogsa sette den manuelt: +Du kan også sette den manuelt: ```json { "baseBranch": "main" } ``` -Se [`archgate check` -- Deteksjon av endrede filer](/reference/cli/check/#changed-files-detection) for den fullstendige prioritetsrekkfolgen. +Se [`archgate check` -- Deteksjon av endrede filer](/reference/cli/check/#changed-files-detection) for den fullstendige prioritetsrekkefølgen. ### `paths` @@ -54,17 +54,17 @@ Overstyr standardkataloger for ADR-er og regler. | `adrs` | `string` | `.archgate/adrs` | Relativ sti til ADR-katalogen | | `rules` | `string` | `.archgate/lint` | Relativ sti til regel-/lint-katalogen | -Begge feltene er valgfrie. Nar de utelates, brukes standardkatalogene `.archgate/adrs/` og `.archgate/lint/`. +Begge feltene er valgfrie. Når de utelates, brukes standardkatalogene `.archgate/adrs/` og `.archgate/lint/`. #### Stivalidering -- Stier **ma vaere relative** til prosjektroten -- absolutte stier (f.eks. `/docs/adrs`, `C:\docs\adrs`) avvises. -- Stier **ma ikke inneholde `..`-segmenter** -- traversering over prosjektroten er ikke tillatt (f.eks. `../other-repo/adrs` avvises). -- Stier bruker skrastrek (`/`) som skilletegn, i trad med standard globkonvensjoner. +- Stier **må være relative** til prosjektroten -- absolutte stier (f.eks. `/docs/adrs`, `C:\docs\adrs`) avvises. +- Stier **må ikke inneholde `..`-segmenter** -- traversering over prosjektroten er ikke tillatt (f.eks. `../other-repo/adrs` avvises). +- Stier bruker skråstrek (`/`) som skilletegn, i tråd med standard globkonvensjoner. ## Egendefinert ADR-katalog -Som standard ligger ADR-er i `.archgate/adrs/`. For a lagre dem i en annen katalog (f.eks. `docs/adrs/`), legg til en `paths`-seksjon i `.archgate/config.json`: +Som standard ligger ADR-er i `.archgate/adrs/`. For å lagre dem i en annen katalog (f.eks. `docs/adrs/`), legg til en `paths`-seksjon i `.archgate/config.json`: ```json { "paths": { "adrs": "docs/adrs" } } @@ -72,19 +72,19 @@ Som standard ligger ADR-er i `.archgate/adrs/`. For a lagre dem i en annen katal Etter at konfigurasjonen er lagt til: -1. Opprett malkatalogen (f.eks. `mkdir -p docs/adrs`) -2. Flytt eksisterende ADR-filer og deres tilhorende `.rules.ts`-filer fra `.archgate/adrs/` til den nye katalogen -3. Kjor `archgate check` for a verifisere at reglene fortsatt lastes riktig +1. Opprett målkatalogen (f.eks. `mkdir -p docs/adrs`) +2. Flytt eksisterende ADR-filer og deres tilhørende `.rules.ts`-filer fra `.archgate/adrs/` til den nye katalogen +3. Kjør `archgate check` for å verifisere at reglene fortsatt lastes riktig Alle CLI-kommandoer (`archgate adr list`, `archgate adr create`, `archgate check`, `archgate review-context`) leser automatisk den konfigurerte katalogen. :::caution -`.archgate/`-katalogen ma fortsatt eksistere -- den er prosjektmarkoren som CLI-en bruker for a finne prosjektroten din. Ikke slett den etter at du har konfigurert egendefinerte stier. +`.archgate/`-katalogen må fortsatt eksistere -- den er prosjektmarkøren som CLI-en bruker for å finne prosjektroten din. Ikke slett den etter at du har konfigurert egendefinerte stier. ::: ### Eksempel: dokumentasjonsmappe i monorepo -Et vanlig monster er a plassere ADR-er sammen med annen dokumentasjon: +Et vanlig mønster er å plassere ADR-er sammen med annen dokumentasjon: ``` my-project/ @@ -107,6 +107,6 @@ my-project/ ## Merknader -- `paths`-konfigurasjonen er en **teamomfattende innstilling** -- den committes til versjonskontroll og gjelder for alle teammedlemmer. Det finnes ingen brukerniva-overstyring for ADR-stier. -- Endring av konfigurasjonen krever manuell redigering av `.archgate/config.json` etter at `archgate init` er kjort. -- Typedefinisjonfilen `rules.d.ts` skrives automatisk til bade `.archgate/` og foreldrekatalogen til den konfigurerte ADR-katalogen, slik at tilhorende `.rules.ts`-filer loser `/// `-direktivet riktig. +- `paths`-konfigurasjonen er en **teamomfattende innstilling** -- den committes til versjonskontroll og gjelder for alle teammedlemmer. Det finnes ingen brukernivå-overstyring for ADR-stier. +- Endring av konfigurasjonen krever manuell redigering av `.archgate/config.json` etter at `archgate init` er kjørt. +- Typedefinisjonfilen `rules.d.ts` skrives automatisk til både `.archgate/` og foreldrekatalogen til den konfigurerte ADR-katalogen, slik at tilhørende `.rules.ts`-filer løser `/// `-direktivet riktig. diff --git a/docs/src/content/docs/nb/reference/privacy-policy.mdx b/docs/src/content/docs/nb/reference/privacy-policy.mdx index 198c7f92..20d0e724 100644 --- a/docs/src/content/docs/nb/reference/privacy-policy.mdx +++ b/docs/src/content/docs/nb/reference/privacy-policy.mdx @@ -1,13 +1,13 @@ --- -title: Personvernerklaering +title: Personvernerklæring description: Hvordan Archgate behandler dataene dine, hva vi samler inn, og rettighetene dine. --- -For den fullstendige Archgate-personvernerklaering, besok: +For den fullstendige Archgate-personvernerklæringen, besøk: **[archgate.dev/privacy-policy](https://archgate.dev/privacy-policy)** -Seksjonene nedenfor oppsummerer de mest relevante punktene for CLI-brukere. Den kanoniske erklaering pa nettstedet er den juridisk bindende versjonen. +Seksjonene nedenfor oppsummerer de mest relevante punktene for CLI-brukere. Den kanoniske erklæringen på nettstedet er den juridisk bindende versjonen. **Behandlingsansvarlig:** Dasolve AS (Org.nr 936 035 019), Lillogata 5P, 0484 Oslo, Norge. Kontakt: [privacy@archgate.dev](mailto:privacy@archgate.dev). @@ -15,25 +15,25 @@ Seksjonene nedenfor oppsummerer de mest relevante punktene for CLI-brukere. Den ### Hva CLI-en samler inn -Archgate samler inn **anonym bruksanalyse** (via PostHog) og **krasjrapporter** (via Sentry) for a forbedre verktøyet. Ingen personopplysninger, kildekode, filinnhold eller AI-prompter samles noensinne inn av selve CLI-en. Se [Telemetri](/reference/telemetry/)-siden for en detaljert gjennomgang av hvert datapunkt. +Archgate samler inn **anonym bruksanalyse** (via PostHog) og **krasjrapporter** (via Sentry) for å forbedre verktøyet. Ingen personopplysninger, kildekode, filinnhold eller AI-prompter samles noensinne inn av selve CLI-en. Se [Telemetri](/reference/telemetry/)-siden for en detaljert gjennomgang av hvert datapunkt. -**Rettslig grunnlag:** Berettiget interesse under GDPR artikkel 6(1)(f). Se var [Vurdering av berettigede interesser](https://archgate.dev/legitimate-interest-assessment). +**Rettslig grunnlag:** Berettiget interesse under GDPR artikkel 6(1)(f). Se vår [Vurdering av berettigede interesser](https://archgate.dev/legitimate-interest-assessment). ### Datalagring og oppbevaringstid | Tjeneste | Data | Region | Oppbevaringstid | | ------------- | ------------------------- | -------------- | ------------------------- | -| PostHog Cloud | Anonym bruksanalyse | EU (Frankfurt) | 1 ar | +| PostHog Cloud | Anonym bruksanalyse | EU (Frankfurt) | 1 år | | Sentry Cloud | Krasjrapporter | EU (Frankfurt) | 90 dager | | Turso | Plugins Service-kontodata | EU | Til sletting etterspørres | -Data overføres via reverseproksier pa `n.archgate.dev` (analyse) og `s.archgate.dev` (feil) -- transparente videresendere driftet av Dasolve AS pa Cloudflare, uten logging eller lagring. +Data overføres via reverseproksier på `n.archgate.dev` (analyse) og `s.archgate.dev` (feil) -- transparente videresendere driftet av Dasolve AS på Cloudflare, uten logging eller lagring. ### Archgate Plugins Service -Nar du registrerer deg via `archgate login`, samler **Plugins Service** (`plugins.archgate.dev`) inn personopplysninger: din **e-postadresse**, **GitHub-brukernavn**, **editorvalg** og en **beskrivelse av bruksomrade**. Disse dataene brukes til a opprette kontoen din og sende en velkomst-e-post. Autentiseringstokener lagres som SHA-256-hasher pa serverne vare; pa din maskin oppbevares legitimasjonen i operativsystemets legitimasjonsbehandler (aldri som ren tekstfiler). +Når du registrerer deg via `archgate login`, samler **Plugins Service** (`plugins.archgate.dev`) inn personopplysninger: din **e-postadresse**, **GitHub-brukernavn**, **editorvalg** og en **beskrivelse av bruksområde**. Disse dataene brukes til å opprette kontoen din og sende en velkomst-e-post. Autentiseringstokener lagres som SHA-256-hasher på serverne våre; på din maskin oppbevares legitimasjonen i operativsystemets legitimasjonsbehandler (aldri som ren tekstfiler). -Ved a opprette en konto godtar du [tjenestevilkarene](https://archgate.dev/terms-of-service). Se den [fullstendige personvernerklaering](https://archgate.dev/privacy-policy) for komplette detaljer. +Ved å opprette en konto godtar du [tjenestevilkårene](https://archgate.dev/terms-of-service). Se den [fullstendige personvernerklæringen](https://archgate.dev/privacy-policy) for komplette detaljer. ### Slik reserverer du deg @@ -45,13 +45,13 @@ export ARCHGATE_TELEMETRY=0 archgate telemetry disable ``` -Merk: telemetrireservasjon deaktiverer CLI-analyse og krasjrapportering. Det pavirker ikke Plugins Service-kontodataene, som kreves for plugintilgang. For a slette kontodataene dine, kontakt [privacy@archgate.dev](mailto:privacy@archgate.dev). +Merk: telemetrireservasjon deaktiverer CLI-analyse og krasjrapportering. Det påvirker ikke Plugins Service-kontodataene, som kreves for plugintilgang. For å slette kontodataene dine, kontakt [privacy@archgate.dev](mailto:privacy@archgate.dev). ### Dine rettigheter - **Innsyn:** Be om en kopi av dataene dine -- send e-post til [privacy@archgate.dev](mailto:privacy@archgate.dev) med din installasjons-ID (fra `~/.archgate/config.json` eller `archgate telemetry status`). - **Sletting:** Be om sletting av historiske data -- send e-post med din installasjons-ID. Gjennomføres innen 30 dager. -- **Protest:** Deaktiver telemetri nar som helst via `archgate telemetry disable`. +- **Protest:** Deaktiver telemetri når som helst via `archgate telemetry disable`. - **Dataportabilitet:** Be om dataeksport i JSON- eller CSV-format. - **Klage:** Kontakt Datatilsynet ([Datatilsynet](https://www.datatilsynet.no)). @@ -59,4 +59,4 @@ Merk: telemetrireservasjon deaktiverer CLI-analyse og krasjrapportering. Det pav Denne dokumentasjonssiden (`cli.archgate.dev`) bruker [Cloudflare Web Analytics](https://www.cloudflare.com/web-analytics/), en personvernvennlig analysetjeneste. Cloudflare Web Analytics bruker ikke informasjonskapsler, sporer ikke individuelle besøkende og samler ikke inn personopplysninger. Tjenesten gir kun aggregerte sidevisnings- og ytelsesmålinger. -PostHog brukes ogsa pa dette nettstedet med **informasjonskapselløs sporing kun i minnet** (`persistence: "memory"`). Ingen informasjonskapsler settes, ingen localStorage skrives, og ingen data vedvarer mellom sidelastinger. +PostHog brukes også på dette nettstedet med **informasjonskapselløs sporing kun i minnet** (`persistence: "memory"`). Ingen informasjonskapsler settes, ingen localStorage skrives, og ingen data vedvarer mellom sidelastinger. diff --git a/docs/src/content/docs/nb/reference/rule-api.mdx b/docs/src/content/docs/nb/reference/rule-api.mdx index f5373232..0e16c724 100644 --- a/docs/src/content/docs/nb/reference/rule-api.mdx +++ b/docs/src/content/docs/nb/reference/rule-api.mdx @@ -3,7 +3,7 @@ title: Rule API description: TypeScript API-referanse for skriving av Archgate-regler. Lær RuleSet med satisfies, RuleContext, rapportering av brudd, filmatchning og AST-baserte samsvarskontroller. --- -Archgate-regler er TypeScript-filer som eksporterer et vanlig objekt typet med `satisfies RuleSet`. Hver regel mottar en `RuleContext` med verktoy for a soke i filer, lese innhold og rapportere brudd. +Archgate-regler er TypeScript-filer som eksporterer et vanlig objekt typet med `satisfies RuleSet`. Hver regel mottar en `RuleContext` med verktøy for å søke i filer, lese innhold og rapportere brudd. ## RuleSet @@ -23,7 +23,7 @@ export default { } satisfies RuleSet; ``` -En regelfil eksporterer som standard et vanlig objekt med en `rules`-post indeksert etter regel-ID. Noklene blir regel-ID-ene som vises i sjekkutdata og bruddrapporter. Annotasjonen `satisfies RuleSet` gir typekontroll uten a pakke inn i et funksjonskall. +En regelfil eksporterer som standard et vanlig objekt med en `rules`-post indeksert etter regel-ID. Nøklene blir regel-ID-ene som vises i sjekkutdata og bruddrapporter. Annotasjonen `satisfies RuleSet` gir typekontroll uten å pakke inn i et funksjonskall. ```typescript type RuleSet = { rules: Record }; @@ -33,7 +33,7 @@ type RuleSet = { rules: Record }; ## RuleConfig -Hver regel i posten ma samsvare med `RuleConfig`-grensesnittet. +Hver regel i posten må samsvare med `RuleConfig`-grensesnittet. ```typescript interface RuleConfig { @@ -43,7 +43,7 @@ interface RuleConfig { } ``` -| Felt | Type | Pakrevd | Beskrivelse | +| Felt | Type | Påkrevd | Beskrivelse | | ------------- | ------------------------------------- | ------- | ---------------------------------------------------------- | | `description` | `string` | Ja | Lesbar beskrivelse som vises i sjekkutdata | | `severity` | `Severity` | Nei | Standard alvorlighetsgrad for brudd. Standard er `"error"` | @@ -85,7 +85,7 @@ Absolutt sti til prosjektets rotkatalog (der `.archgate/` ligger). scopedFiles: string[]; ``` -Filer som matcher ADR-ens `files`-globmonstre fra frontmatter. Hvis ADR-en ikke har et `files`-felt, inneholder denne alle prosjektfiler. Bruk denne som den primaere fillisten for regelkontrollene dine. +Filer som matcher ADR-ens `files`-globmønstre fra frontmatter. Hvis ADR-en ikke har et `files`-felt, inneholder denne alle prosjektfiler. Bruk denne som den primære fillisten for regelkontrollene dine. #### changedFiles @@ -93,7 +93,7 @@ Filer som matcher ADR-ens `files`-globmonstre fra frontmatter. Hvis ADR-en ikke changedFiles: string[]; ``` -Filer som har blitt endret ifolge git. Som standard fylles denne automatisk med branch-diffen mot den detekterte basisgrenen (f.eks. `origin/main`). Nar `--staged` brukes, inneholder den kun stagede filer. Nar `--base ` brukes, inneholder den alle filer som er endret siden den referansen. Tom nar basisdeteksjon feiler eller ingen endringer finnes. Bruk denne til a bygge regler for avhengigheter mellom filer (f.eks. "hvis fil A endret seg, ma fil B ogsa endres"). +Filer som har blitt endret ifølge git. Som standard fylles denne automatisk med branch-diffen mot den detekterte basisgrenen (f.eks. `origin/main`). Når `--staged` brukes, inneholder den kun stagede filer. Når `--base ` brukes, inneholder den alle filer som er endret siden den referansen. Tom når basisdeteksjon feiler eller ingen endringer finnes. Bruk denne til å bygge regler for avhengigheter mellom filer (f.eks. "hvis fil A endret seg, må fil B også endres"). #### report @@ -101,7 +101,7 @@ Filer som har blitt endret ifolge git. Som standard fylles denne automatisk med report: RuleReport; ``` -Rapporteringsgrensesnittet for a registrere brudd, advarsler og informasjonsmeldinger. Se [RuleReport](#rulereport) nedenfor. +Rapporteringsgrensesnittet for å registrere brudd, advarsler og informasjonsmeldinger. Se [RuleReport](#rulereport) nedenfor. ### Metoder @@ -111,7 +111,7 @@ Rapporteringsgrensesnittet for a registrere brudd, advarsler og informasjonsmeld glob(pattern: string): Promise; ``` -Finn filer som matcher et globmonster relativt til prosjektroten. Returnerer en matrise med filstier. Filer som ignoreres av `.gitignore` er ekskludert som standard. Sett `respectGitignore: false` i ADR-ens frontmatter for a inkludere dem. +Finn filer som matcher et globmønster relativt til prosjektroten. Returnerer en matrise med filstier. Filer som ignoreres av `.gitignore` er ekskludert som standard. Sett `respectGitignore: false` i ADR-ens frontmatter for å inkludere dem. ```typescript const testFiles = await ctx.glob("tests/**/*.test.ts"); @@ -123,7 +123,7 @@ const testFiles = await ctx.glob("tests/**/*.test.ts"); grep(file: string, pattern: RegExp): Promise; ``` -Sok i en enkelt fil etter linjer som matcher et regulaert uttrykk. Returnerer en matrise med `GrepMatch`-objekter med filsti, linjenummer, kolonne og matchet innhold. +Søk i en enkelt fil etter linjer som matcher et regulært uttrykk. Returnerer en matrise med `GrepMatch`-objekter med filsti, linjenummer, kolonne og matchet innhold. ```typescript const matches = await ctx.grep(file, /console\.error\(/); @@ -135,7 +135,7 @@ const matches = await ctx.grep(file, /console\.error\(/); grepFiles(pattern: RegExp, fileGlob: string): Promise; ``` -Sok i flere filer som matcher et globmonster etter linjer som matcher et regulaert uttrykk. Kombinerer `glob` og `grep` i ett enkelt kall. Filer som ignoreres av `.gitignore` er ekskludert som standard. Sett `respectGitignore: false` i ADR-ens frontmatter for a inkludere dem. +Søk i flere filer som matcher et globmønster etter linjer som matcher et regulært uttrykk. Kombinerer `glob` og `grep` i ett enkelt kall. Filer som ignoreres av `.gitignore` er ekskludert som standard. Sett `respectGitignore: false` i ADR-ens frontmatter for å inkludere dem. ```typescript const matches = await ctx.grepFiles(/TODO:/i, "src/**/*.ts"); @@ -171,7 +171,7 @@ const pkg = (await ctx.readJSON("package.json")) as { ## RuleReport -Rapporteringsgrensesnittet for a registrere sjekkresultater. Hver metode aksepterer et detalobjekt som beskriver problemet. +Rapporteringsgrensesnittet for å registrere sjekkresultater. Hver metode aksepterer et detalobjekt som beskriver problemet. ```typescript interface RuleReport { @@ -187,7 +187,7 @@ interface RuleReport { report.violation(detail: ReportDetail): void; ``` -Rapporter et regelbrudd. Brudd far sjekken til a feile med avslutningskode 1. Bruk for harde begrensninger som ikke skal merges. +Rapporter et regelbrudd. Brudd får sjekken til å feile med avslutningskode 1. Bruk for harde begrensninger som ikke skal merges. #### warning @@ -195,7 +195,7 @@ Rapporter et regelbrudd. Brudd far sjekken til a feile med avslutningskode 1. Br report.warning(detail: ReportDetail): void; ``` -Rapporter en advarsel. Advarsler vises i sjekkutdata, men far ikke sjekken til a feile. Bruk for ikke-blokkerende veiledning. +Rapporter en advarsel. Advarsler vises i sjekkutdata, men får ikke sjekken til å feile. Bruk for ikke-blokkerende veiledning. #### info @@ -203,7 +203,7 @@ Rapporter en advarsel. Advarsler vises i sjekkutdata, men far ikke sjekken til a report.info(detail: ReportDetail): void; ``` -Rapporter en informasjonsmelding. Pavirker ikke avslutningskoden for sjekken. Bruk for forslag eller notater. +Rapporter en informasjonsmelding. Påvirker ikke avslutningskoden for sjekken. Bruk for forslag eller notater. ### ReportDetail @@ -220,16 +220,16 @@ interface ReportDetail { } ``` -| Felt | Type | Pakrevd | Beskrivelse | +| Felt | Type | Påkrevd | Beskrivelse | | ----------- | -------- | ------- | -------------------------------------------------------------------------- | | `message` | `string` | Ja | Lesbar beskrivelse av problemet | | `file` | `string` | Nei | Filsti der problemet ble funnet | | `line` | `number` | Nei | Startlinjenummer (1-basert) | -| `endLine` | `number` | Nei | Sluttlinjenummer (1-basert) -- for presis uthevning av omrade i editoren | -| `endColumn` | `number` | Nei | Sluttkolonnenummer (0-basert) -- for presis uthevning av omrade i editoren | -| `fix` | `string` | Nei | Foreslatt rettelse eller utbedringstiltak | +| `endLine` | `number` | Nei | Sluttlinjenummer (1-basert) -- for presis uthevning av område i editoren | +| `endColumn` | `number` | Nei | Sluttkolonnenummer (0-basert) -- for presis uthevning av område i editoren | +| `fix` | `string` | Nei | Foreslått rettelse eller utbedringstiltak | -Nar `endLine` og `endColumn` er oppgitt, kan editorer (VS Code, Cursor) utheve det noyaktige uttrykket som bryter regelen, i stedet for hele linjen. Hvis de utelates, utheves hele linjen ved `line`. +Når `endLine` og `endColumn` er oppgitt, kan editorer (VS Code, Cursor) utheve det nøyaktige uttrykket som bryter regelen, i stedet for hele linjen. Hvis de utelates, utheves hele linjen ved `line`. --- @@ -261,11 +261,11 @@ interface GrepMatch { type Severity = "error" | "warning" | "info"; ``` -| Verdi | Pavirkning pa avslutningskode | Beskrivelse | +| Verdi | Påvirkning på avslutningskode | Beskrivelse | | ----------- | ----------------------------- | ------------------------------------------ | -| `"error"` | Forarsakar avslutningskode 1 | Hard begrensning, blokkerer sammenslainger | -| `"warning"` | Ingen pavirkning | Ikke-blokkerende veiledning | -| `"info"` | Ingen pavirkning | Informasjon, kun forslag | +| `"error"` | Forårsaker avslutningskode 1 | Hard begrensning, blokkerer sammenslåinger | +| `"warning"` | Ingen påvirkning | Ikke-blokkerende veiledning | +| `"info"` | Ingen påvirkning | Informasjon, kun forslag | --- @@ -289,14 +289,14 @@ interface ViolationDetail { | Felt | Type | Beskrivelse | | ----------- | ---------- | ---------------------------------------------------------- | -| `ruleId` | `string` | Regel-ID fra `rules`-objektnokelen | +| `ruleId` | `string` | Regel-ID fra `rules`-objektnøkkelen | | `adrId` | `string` | ADR-ID fra frontmatter | | `message` | `string` | Lesbar beskrivelse | | `file` | `string?` | Filsti der problemet ble funnet | | `line` | `number?` | Startlinjenummer (1-basert) | | `endLine` | `number?` | Sluttlinje (1-basert) -- for presis uthevning i editoren | | `endColumn` | `number?` | Sluttkolonne (0-basert) -- for presis uthevning i editoren | -| `fix` | `string?` | Foreslatt rettelse | +| `fix` | `string?` | Foreslått rettelse | | `severity` | `Severity` | Effektiv alvorlighetsgrad for dette bruddet | --- @@ -316,7 +316,7 @@ En begrunnelse er påkrevd. Filnivå-undertrykkelse bruker `archgate-ignore-file ## RuleSet -Typen brukt med `satisfies` for a typekontrollere regelobjektet ditt. Eksporter et vanlig objekt som samsvarer med denne formen. +Typen brukt med `satisfies` for å typekontrollere regelobjektet ditt. Eksporter et vanlig objekt som samsvarer med denne formen. ```typescript type RuleSet = { rules: Record }; diff --git a/docs/src/content/docs/nb/reference/telemetry.mdx b/docs/src/content/docs/nb/reference/telemetry.mdx index 55c0d198..81aef712 100644 --- a/docs/src/content/docs/nb/reference/telemetry.mdx +++ b/docs/src/content/docs/nb/reference/telemetry.mdx @@ -1,49 +1,49 @@ --- title: Telemetri -description: Hvilke anonyme bruksdata Archgate samler inn, hvordan du kan reservere deg, og vare personvernforpliktelser. +description: Hvilke anonyme bruksdata Archgate samler inn, hvordan du kan reservere deg, og våre personvernforpliktelser. --- -Archgate samler inn **anonyme bruksdata** for a hjelpe oss med a forsta hvordan CLI-en brukes, prioritere funksjoner og fikse krasjer. Denne siden forklarer noyaktig hva som samles inn, hva som ikke samles inn, og hvordan du kan reservere deg. +Archgate samler inn **anonyme bruksdata** for å hjelpe oss med å forstå hvordan CLI-en brukes, prioritere funksjoner og fikse krasjer. Denne siden forklarer nøyaktig hva som samles inn, hva som ikke samles inn, og hvordan du kan reservere deg. ## Hva vi samler inn ### Bruksanalyse (PostHog) -Nar du kjorer en Archgate-kommando, registrerer vi: +Når du kjører en Archgate-kommando, registrerer vi: -- **Kommandonavn** og **hvilke flagg som ble brukt** (f.eks. `check --json` -- kun flaggtilstedevaerelse, aldri flaggverdier) -- **Avslutningskode** (0, 1, 2 eller 130) og **kjoretid** (millisekunder), pluss en kort **utfallstagg** (`success`, `user_error`, `internal_error`, `cancelled`) -- **Miljo**: OS, arkitektur, Bun-versjon, Archgate-versjon, CI-deteksjon (inkludert leverandor: GitHub Actions / GitLab CI / CircleCI / osv.), TTY-deteksjon, WSL-deteksjon, shell (bash, zsh, pwsh...) og locale -- **Installasjonskontekst**: hvordan CLI-en ble installert (binaerfil, proto, lokal dev-avhengighet eller global pakkebehandler) +- **Kommandonavn** og **hvilke flagg som ble brukt** (f.eks. `check --json` -- kun flaggtilstedeværelse, aldri flaggverdier) +- **Avslutningskode** (0, 1, 2 eller 130) og **kjøretid** (millisekunder), pluss en kort **utfallstagg** (`success`, `user_error`, `internal_error`, `cancelled`) +- **Miljø**: OS, arkitektur, Bun-versjon, Archgate-versjon, CI-deteksjon (inkludert leverandør: GitHub Actions / GitLab CI / CircleCI / osv.), TTY-deteksjon, WSL-deteksjon, shell (bash, zsh, pwsh...) og locale +- **Installasjonskontekst**: hvordan CLI-en ble installert (binærfil, proto, lokal dev-avhengighet eller global pakkebehandler) - **Prosjektkontekst**: om et Archgate-prosjekt finnes i gjeldende katalog, hvor mange ADR-er det har, hvor mange som har automatiserte regler, og hvor mange distinkte ADR-domener som brukes - **Repokontekst** (ikke-identifiserende): om gjeldende katalog er et git-repository, vertsboksen (`github` / `gitlab` / `bitbucket` / `azure-devops` / `other`), en **hashet `repo_id`** (SHA-256 av den normaliserte fjern-URL-en, avkortet til 16 heksadesimale tegn -- ikke reverserbar), og standard grennavn -- **Grov lokasjon**: land og region (resolveres pa serversiden fra IP-adressen din, deretter forkastes IP-en -- se [IP-anonymisering](#ip-anonymisering)) -- **Anonym installasjons-ID**: en tilfeldig UUID generert ved forste kjoring -- ikke avledet fra personopplysninger +- **Grov lokasjon**: land og region (resolveres på serversiden fra IP-adressen din, deretter forkastes IP-en -- se [IP-anonymisering](#ip-anonymisering)) +- **Anonym installasjons-ID**: en tilfeldig UUID generert ved første kjøring -- ikke avledet fra personopplysninger I tillegg til de generelle livssyklushendelsene for kommandoer (`command_executed` / `command_completed`), sender spesifikke kommandoer berikede utfallshendelser: -- **`check`**: aggregerte regeltellinger (totalt, bestaatt, feilet, advarsler, feil), brukt utdataformat, om filtre ble brukt, skannede filer, lastetid, sjekktid -- ingen filstier eller bruddinnhold -- **`init`**: editorvalg, om pluginen ble installert, om prosjektet allerede eksisterte. En separat engangshendelse `project_initialized` sendes med repovertsboksen, `repo_is_git` og et `repo_public`-flagg. For repoer bekreftet som offentlige pa GitHub / GitLab / Bitbucket, inneholder denne hendelsen ogsa fjern-URL, eier og reponavn -- se [Repoidentitet](#repoidentitet). Private og selvhostede repoer far aldri identitet delt. -- **`upgrade`**: versjonsovergang (fra -> til), installasjonsmetode, suksess/feil og en valgfri feilarsak -- **`login`**: underkommando brukt (login, logout, refresh, status), suksess/feil og en feilboks (`network`, `tls`, `denied`, `other`) nar det feiler -- **`telemetry_preference_changed`**: utloses en gang nar du aktiverer eller deaktiverer telemetri, slik at vi kan forsta reservasjonsrater +- **`check`**: aggregerte regeltellinger (totalt, bestått, feilet, advarsler, feil), brukt utdataformat, om filtre ble brukt, skannede filer, lastetid, sjekktid -- ingen filstier eller bruddinnhold +- **`init`**: editorvalg, om pluginen ble installert, om prosjektet allerede eksisterte. En separat engangshendelse `project_initialized` sendes med repovertsboksen, `repo_is_git` og et `repo_public`-flagg. For repoer bekreftet som offentlige på GitHub / GitLab / Bitbucket, inneholder denne hendelsen også fjern-URL, eier og reponavn -- se [Repoidentitet](#repoidentitet). Private og selvhostede repoer får aldri identitet delt. +- **`upgrade`**: versjonsovergang (fra -> til), installasjonsmetode, suksess/feil og en valgfri feilårsak +- **`login`**: underkommando brukt (login, logout, refresh, status), suksess/feil og en feilboks (`network`, `tls`, `denied`, `other`) når det feiler +- **`telemetry_preference_changed`**: utløses en gang når du aktiverer eller deaktiverer telemetri, slik at vi kan forstå reservasjonsrater ## Repoidentitet -Archgate sender en **hashet** `repo_id` med hver hendelse slik at vi kan telle distinkte repositorier som bruker CLI-en uten a laere navnene deres. Den ra fjern-URL-en, eieren og reponavnet er **ikke** inkludert i den generelle hendelsesstrommen. +Archgate sender en **hashet** `repo_id` med hver hendelse slik at vi kan telle distinkte repositorier som bruker CLI-en uten å lære navnene deres. Den rå fjern-URL-en, eieren og reponavnet er **ikke** inkludert i den generelle hendelsesstrømmen. -Ved `archgate init` sendes en engangshendelse `project_initialized`. Hvis -- og bare hvis -- repositoriet er bekreftet **offentlig** pa GitHub, GitLab, Bitbucket eller Azure DevOps (via en uautentisert API-probing mot verten), inneholder den hendelsen i tillegg `remote_url`, `repo_owner` og `repo_name`. Dette lar oss se hvilke offentlige repositorier som tar i bruk Archgate uten a noensinne eksponere private. +Ved `archgate init` sendes en engangshendelse `project_initialized`. Hvis -- og bare hvis -- repositoriet er bekreftet **offentlig** på GitHub, GitLab, Bitbucket eller Azure DevOps (via en uautentisert API-probing mot verten), inneholder den hendelsen i tillegg `remote_url`, `repo_owner` og `repo_name`. Dette lar oss se hvilke offentlige repositorier som tar i bruk Archgate uten å noensinne eksponere private. **Hva som aldri deles:** - Private repositorier (API-probing returnerer 404, 401 eller `private: true`) - Selvhostede Git-verter (probingen hopper over disse helt) -- Repositorier der probingen far tidsavbrudd, ratebegrensning eller pa annen mate ikke klarer a returnere et definitivt offentlig svar +- Repositorier der probingen får tidsavbrudd, ratebegrensning eller på annen måte ikke klarer å returnere et definitivt offentlig svar **Vil du ikke ha hendelsen i det hele tatt?** Deaktiver telemetri helt -- hele `project_initialized`-hendelsen undertrykkes da sammen med alt annet: ```bash -# Per shell / per kjoring +# Per shell / per kjøring export ARCHGATE_TELEMETRY=0 # Eller permanent @@ -54,43 +54,43 @@ Se [Slik reserverer du deg](#slik-reserverer-du-deg) nedenfor for fullstendige d ### Feilsporing (Sentry) -Nar CLI-en krasjer (avslutningskode 2), sender vi: +Når CLI-en krasjer (avslutningskode 2), sender vi: - **Feiltype, melding og stacktrace** (filstier strippes til relative stier som `src/cli.ts`) -- **Kjoretidskontekst**: OS, arkitektur, Bun-versjon, Archgate-versjon +- **Kjøretidskontekst**: OS, arkitektur, Bun-versjon, Archgate-versjon - **Anonym installasjons-ID** (samme tilfeldige UUID som analyse) ## Hva vi IKKE samler inn -- **Ingen personopplysninger**: ingen brukernavn, e-postadresser eller IP-adresser. GitHub / GitLab / Bitbucket eier-/reponavn sendes kun pa engangshendelsen `project_initialized` for repositorier som er bekreftet offentlige av verten sin -- se [Repoidentitet](#repoidentitet). Private og selvhostede repoer far aldri identitet delt. +- **Ingen personopplysninger**: ingen brukernavn, e-postadresser eller IP-adresser. GitHub / GitLab / Bitbucket eier-/reponavn sendes kun på engangshendelsen `project_initialized` for repositorier som er bekreftet offentlige av verten sin -- se [Repoidentitet](#repoidentitet). Private og selvhostede repoer får aldri identitet delt. - **Intet filinnhold**: ingen ADR-innhold, kildekode eller filstier - **Ingen prompt- eller AI-kontekst**: ingenting fra agentinteraksjoner, prompter eller AI-generert innhold - **Ingen flaggverdier**: vi registrerer at `--json` ble brukt, ikke hva JSON-utdataene inneholdt -- **Ingen nettverksaktivitet**: ingen URL-er, API-nokler eller tokener +- **Ingen nettverksaktivitet**: ingen URL-er, API-nøkler eller tokener ## IP-anonymisering Archgate bruker PostHogs innebygde IP-anonymisering: 1. CLI-en din sender en hendelse til PostHog med `$ip: null` -2. PostHog resolver IP-adressen din til et **land og en region** (f.eks. "US", "California") pa serversiden +2. PostHog resolver IP-adressen din til et **land og en region** (f.eks. "US", "California") på serversiden 3. IP-adressen **forkastes** deretter -- den lagres aldri i PostHog -For Sentry feilsporing har prosjektet **"Prevent Storing of IP Addresses"** aktivert, slik at IP-adresser fjernes for lagring. +For Sentry feilsporing har prosjektet **"Prevent Storing of IP Addresses"** aktivert, slik at IP-adresser fjernes før lagring. ## Slik reserverer du deg -Du kan deaktivere all telemetri (bade analyse og feilsporing) pa to mater: +Du kan deaktivere all telemetri (både analyse og feilsporing) på to måter: -### Miljovariabel +### Miljøvariabel ```bash export ARCHGATE_TELEMETRY=0 ``` -Aksepterte verdier: `0`, `false`, `no`, `off` (uavhengig av store/sma bokstaver). +Aksepterte verdier: `0`, `false`, `no`, `off` (uavhengig av store/små bokstaver). -Legg dette til i shellprofilen din (`.bashrc`, `.zshrc`, osv.) for a deaktivere permanent. +Legg dette til i shellprofilen din (`.bashrc`, `.zshrc`, osv.) for å deaktivere permanent. ### CLI-kommando @@ -98,50 +98,50 @@ Legg dette til i shellprofilen din (`.bashrc`, `.zshrc`, osv.) for a deaktivere archgate telemetry disable ``` -For a reaktivere: +For å reaktivere: ```bash archgate telemetry enable ``` -For a sjekke gjeldende status: +For å sjekke gjeldende status: ```bash archgate telemetry status ``` -Miljovariabelen har forrang over CLI-innstillingen. Hvis `ARCHGATE_TELEMETRY=0` er satt, er telemetri deaktivert uavhengig av CLI-konfigurasjonen. +Miljøvariabelen har forrang over CLI-innstillingen. Hvis `ARCHGATE_TELEMETRY=0` er satt, er telemetri deaktivert uavhengig av CLI-konfigurasjonen. ## Rettslig grunnlag -Archgate CLI-telemetri opererer pa **reservasjonsbasis** under GDPR artikkel 6(1)(f) og LGPD artikkel 7, IX c/c artikkel 10 -- behandlingsansvarliges berettigede interesser. Vi har publisert en formell [Vurdering av berettigede interesser](https://archgate.dev/legitimate-interest-assessment) som dokumenterer hvorfor dette er forholdsmessig og lovlig. +Archgate CLI-telemetri opererer på **reservasjonsbasis** under GDPR artikkel 6(1)(f) og LGPD artikkel 7, IX c/c artikkel 10 -- behandlingsansvarliges berettigede interesser. Vi har publisert en formell [Vurdering av berettigede interesser](https://archgate.dev/legitimate-interest-assessment) som dokumenterer hvorfor dette er forholdsmessig og lovlig. -Oppsummert: dataene er anonyme (tilfeldig UUID, ingen personopplysninger), pavirkningen pa brukere er minimal, robuste sikkerhetstiltak er pa plass (IP-anonymisering, EU-lagring, begrenset oppbevaringstid, transparens), og brukere beholder full kontroll via en enkel, permanent reservasjonsmulighet. +Oppsummert: dataene er anonyme (tilfeldig UUID, ingen personopplysninger), påvirkningen på brukere er minimal, robuste sikkerhetstiltak er på plass (IP-anonymisering, EU-lagring, begrenset oppbevaringstid, transparens), og brukere beholder full kontroll via en enkel, permanent reservasjonsmulighet. ## Hvor data lagres | Tjeneste | Data | Region | Oppbevaringstid | | ------------- | -------------------------------------- | -------------- | ------------------ | -| PostHog Cloud | Anonym bruksanalyse | EU (Frankfurt) | 1 ar | +| PostHog Cloud | Anonym bruksanalyse | EU (Frankfurt) | 1 år | | Sentry Cloud | Krasjrapporter | EU (Frankfurt) | 90 dager | | Lokal konfig | Telemetripreferanse + installasjons-ID | Din maskin | Til du sletter den | -Analysehendelser rutes gjennom `n.archgate.dev` og feilrapporter gjennom `s.archgate.dev`. Disse er transparente reverseproksier driftet av Dasolve AS pa Cloudflare-infrastruktur -- de videresender foresporsler uten a logge, lagre eller inspisere nyttelast. +Analysehendelser rutes gjennom `n.archgate.dev` og feilrapporter gjennom `s.archgate.dev`. Disse er transparente reverseproksier driftet av Dasolve AS på Cloudflare-infrastruktur -- de videresender forespørsler uten å logge, lagre eller inspisere nyttelast. ## Dine rettigheter - **Rett til innsyn**: Be om en kopi av alle data knyttet til din installasjons-ID. Send e-post til [privacy@archgate.dev](mailto:privacy@archgate.dev) med din installasjons-ID (finnes via `archgate telemetry status` eller i `~/.archgate/config.json`). Svar innen 30 dager. -- **Rett til sletting**: Be om sletting av historiske analyse- og krasjdata. A deaktivere telemetri stopper fremtidig innsamling, men sletter ikke tidligere hendelser. Send e-post til [privacy@archgate.dev](mailto:privacy@archgate.dev) med din installasjons-ID for sletting. -- **Rett til a protestere**: Deaktiver telemetri nar som helst via `archgate telemetry disable` eller `ARCHGATE_TELEMETRY=0`. -- **Rett til a klage**: Kontakt Datatilsynet ([Datatilsynet](https://www.datatilsynet.no)) eller, for brasilianske brukere, ANPD ([www.gov.br/anpd](https://www.gov.br/anpd)). +- **Rett til sletting**: Be om sletting av historiske analyse- og krasjdata. Å deaktivere telemetri stopper fremtidig innsamling, men sletter ikke tidligere hendelser. Send e-post til [privacy@archgate.dev](mailto:privacy@archgate.dev) med din installasjons-ID for sletting. +- **Rett til å protestere**: Deaktiver telemetri når som helst via `archgate telemetry disable` eller `ARCHGATE_TELEMETRY=0`. +- **Rett til å klage**: Kontakt Datatilsynet ([Datatilsynet](https://www.datatilsynet.no)) eller, for brasilianske brukere, ANPD ([www.gov.br/anpd](https://www.gov.br/anpd)). **Behandlingsansvarlig:** Dasolve AS (Org.nr 936 035 019), Lillogata 5P, 0484 Oslo, Norge. Kontakt: [privacy@archgate.dev](mailto:privacy@archgate.dev). -**Brasilianske brukere (LGPD):** For LGPD-spesifikke rettigheter (art. 18), detaljer om internasjonal overforing (art. 33) og ANPD-kontaktinformasjon, se [personvernerklaering pa portugisisk](https://archgate.dev/pt-br/privacy-policy). +**Brasilianske brukere (LGPD):** For LGPD-spesifikke rettigheter (art. 18), detaljer om internasjonal overføring (art. 33) og ANPD-kontaktinformasjon, se [personvernerklæring på portugisisk](https://archgate.dev/pt-br/privacy-policy). -## Apen kildekode +## Åpen kildekode -Telemetriimplementasjonen er fullstendig apen kildekode. Du kan inspisere noyaktig hvilke data som samles inn ved a lese: +Telemetriimplementasjonen er fullstendig åpen kildekode. Du kan inspisere nøyaktig hvilke data som samles inn ved å lese: - [`src/helpers/telemetry.ts`](https://github.com/archgate/cli/blob/main/src/helpers/telemetry.ts) -- PostHog-hendelsessporing - [`src/helpers/sentry.ts`](https://github.com/archgate/cli/blob/main/src/helpers/sentry.ts) -- Sentry-feilfangst diff --git a/docs/src/content/docs/nb/studies/sentry-pr-review-friction-and-adr-pack.mdx b/docs/src/content/docs/nb/studies/sentry-pr-review-friction-and-adr-pack.mdx index 88ee1c9c..0581ec1d 100644 --- a/docs/src/content/docs/nb/studies/sentry-pr-review-friction-and-adr-pack.mdx +++ b/docs/src/content/docs/nb/studies/sentry-pr-review-friction-and-adr-pack.mdx @@ -3,22 +3,22 @@ title: "Studie: Sentry PR-friksjon og ADR-standardisering" description: "En 90-dagers pull request-studie av getsentry/sentry som viser hvor gjennomgangs-friksjon samler seg og hvilke ADR-er/regler som kan redusere gjentatte diskusjoner." --- -Denne studien måler hvor kodegjennomgangsfriksjon konsentrerer seg i [`getsentry/sentry`](https://github.com/getsentry/sentry) og identifiserer hvilke ADR-er som kan redusere gjentatte diskusjonssykluser. +Denne studien måler hvor kodegjennomgangsfriksjon konsentrerer seg i [`getsentry/sentry`](https://github.com/getsentry/sentry) og identifiserer hvilke ADR-er som kan redusere gjentatte diskusjonssykluser. -Målet er ikke å fjerne menneskelig gjennomgang. Målet er å flytte gjentatte, forutsigbare gjennomgangsdebatter inn i eksplisitte beslutninger og maskinsjekbar policy. +Målet er ikke å fjerne menneskelig gjennomgang. Målet er å flytte gjentatte, forutsigbare gjennomgangsdebatter inn i eksplisitte beslutninger og maskinsjekbar policy. -## Høydepunkter +## Høydepunkter -På tvers av **500 sammenslåtte PR-er**, **500 lukket-uten-sammenslåing PR-er** og **251 åpne PR-er** over et 90-dagers vindu: +På tvers av **500 sammenslåtte PR-er**, **500 lukket-uten-sammenslåing PR-er** og **251 åpne PR-er** over et 90-dagers vindu: -- **PR-størrelse er den sterkeste friksjonsindikator** -- store PR-er havner i den høye friksjonskvartilen **57 %** av gangene mot **10 %** for små PR-er. -- **Median tid-til-sammenslåing er ca. 5 timer**, men P90 når **ca. 71 timer** (en 14x-multiplikator). +- **PR-størrelse er den sterkeste friksjonsindikator** -- store PR-er havner i den høye friksjonskvartilen **57 %** av gangene mot **10 %** for små PR-er. +- **Median tid-til-sammenslåing er ca. 5 timer**, men P90 når **ca. 71 timer** (en 14x-multiplikator). - **Gjentatte diskusjonstemaer** samler seg rundt API-semantikk, typesikkerhet, testbevis, UX-flytutvarianter og omfangssplitting. -- **5 foreslåtte ADR-er** adresserer de største friksjonskildene, med tilhørende regler og en faseinndelt utrullingsplan. +- **5 foreslåtte ADR-er** adresserer de største friksjonskildene, med tilhørende regler og en faseinndelt utrullingsplan. ## Les den fullstendige studien -Den komplette studien -- metodikk, grunnlinjemetrikker, friksjonskart, temaanalyse og ADR-forslag -- er publisert på: +Den komplette studien -- metodikk, grunnlinjemetrikker, friksjonskart, temaanalyse og ADR-forslag -- er publisert på: **[studies.archgate.dev/studies/sentry-pr-review-friction](https://studies.archgate.dev/studies/sentry-pr-review-friction/)**