01
Mandat och produktägarskap
Devportalen och golden paths behöver en uppdragsgivare, en produktägare och mandat att definiera gemensamma produktionsgrindar.
dev.sundsvall.se
När AI är utgångspunkten i utvecklingen, och idéer prövas som prototyper i stället för att utredas, kortas vägen från behov till testad lösning från veckor till timmar. Devportalen är grunden som gör det möjligt — samma regler, mallar och kontrakt för både människor och agenter. Tillsammans stärker det kommunens förmåga att driva förändring med stöd av det digitala.
Sundsvalls kommun bör göra utvecklarportalen till organisationens gemensamma ingång för att förstå, bygga, integrera, leverera och förvalta digitala produkter. Samma strukturerade fakta ska fungera för människor och AI-agenter, utan att hemligheter, personuppgifter eller administratörsrättigheter flyttas in i portalen.
Devportalen och golden paths behöver en uppdragsgivare, en produktägare och mandat att definiera gemensamma produktionsgrindar.
Teamet äger upplevelsen, katalogmodellen, templates, CI-baseline, agentpaket och självservice, men inte varje verksamhets produktkod.
Systemregistret, Git, WSO2, identitetsplattformen och OpenShift måste få tydliga ansvarsgränser och integrationsvägar.
Varje system ägs av ett team, med personer som kontaktvägar. Ett personbyte får inte göra systemet ägarlöst.
Prototyper ska kunna skapas, testas, återställas och lämnas över utan att använda produktionsdata eller fria klusterrättigheter.
Strict typing, tester, tillgänglighet, säkerhet, dokumentationskontroller och reproducerbara builds ska följa med från start.
Central logghantering, gemensamt backupsystem, secrets/certifikat, GitOps och observability som varje ny tjänst ansluter till automatiskt.
En reviewagent i CI-flödet granskar varje leverans, även från den som inte är utvecklare, innan överlämning och produktion. Människan fattar besluten.
Åtkomst, verktyg, AI-uppsättning, golden path och första pull requesten.
Öppna området → Designsystem & UXUI-vägval, tokens, Figma, accessibility, responsivitet och skrivregler.
Öppna området → FrontendReact, TypeScript, teststrategi, identitet, state och repoarkitektur.
Öppna området → Backenddept44, API-kontrakt, servicekatalog, domänkunskap och driftkrav.
Öppna området → IntegrationerUpptäckt, prenumeration, promotion, kontrakt och säkra agentgränssnitt.
Öppna området → CI/CDTester, scanners, evidence, artifacts, promotion, rollback och release.
Öppna området → SecuritySecrets, supply chain, agentidentitet, audit och cybersäkerhetsbevis.
Öppna området → DevOps & PlattformPreview, loggar, metrics, backup, GitOps, SLO och återställning.
Öppna området → Data & AIGodkänd agentkonfiguration, capability-åtkomst och informationsgränser.
Öppna området → Dokumentation & processDocs-as-code, redaktionellt stöd, lifecycle, aktualitet och bidragsmodell.
Öppna området →Hur beställer jag domän och certifikat? Vilken webbprofil gäller? Hur ansluter jag SSO? Vilket API finns redan? Hur ser jag loggar? Hur begär jag en testmiljö?
Vilket team äger systemet? Är dokumentationen aktuell? Finns återställning? Vilken data används? Vilka säkerhetsgrindar passerade releasen? Är komponenten på väg att avvecklas?
Gör portalen till en gemensam produkt och ett organisationskontrakt. Då får en ny utvecklare tillgång till de fakta som i dag bara finns i erfarna kollegors huvuden.
AI-first är inte en chattbot bredvid dagens process, utan ett sätt att strukturera kunskap, kodbaser, API:er, leveransvägar och ansvar så att både människor och agenter kan leverera med samma kvalitets- och säkerhetskrav.
Kommunen behöver möta fler utvecklingsbehov utan att bemanningen ökar i samma takt. Befintlig kompetens måste därför räcka till fler uppgifter, samtidigt som återkommande arbete automatiseras.
Viss information finns i Confluence, viss i GitHub, viss i verktyg och mycket i personers minne. Den som inte redan känner rätt person tappar tid.
Certifikat, domäner, identitet, WSO2, miljöer, loggar och promotion kräver återkommande manuella kontakter och specialkunskap.
Verksamhetsnära roller kan skapa mycket, men överlämningen blir dyr om prototypen saknar gemensam struktur, tester och tydliga gränser.
När en nyckelperson byter roll eller slutar kan ägarskap, driftkunskap och dokumentation försvinna eller bli inaktuella.
En intern utvecklarportal med fyra egenskaper:
Bredden ska växa där uppgiften kräver det, med stöd av dokumenterade arbetssätt, tillgänglig kunskap och gemensamma verktyg. Det är en av vägarna till att möta fler behov med befintlig bemanning.
Kommunen genomför redan innovationssprintar och sätter samman grupperna tvärfunktionellt när det går. Med olika kompetenser i samma grupp delas kunskapen mellan deltagarna, och alla tar med sig något tillbaka.
Deltagarna behöver kunna prova idéer, nå en testmiljö utan väntetid och hitta interna lösningar att återanvända. Det lämnar mer av sprinttiden till lärande och gemensam problemlösning.
Att arbeta utanför sitt eget område kräver recept, golden paths och kontrakt som går att hitta och lita på. Saknas de blir bredd en fråga om vem man känner.
Agenten kan förklara ett okänt kodområde, föreslå ett första utkast och peka på rätt mall. Det hjälper utvecklaren att snabbare komma igång i ett nytt teknikområde.
Den största risken är inte att välja fel frontendbibliotek, utan att bygga en portal utan mandat, ägare, integrationsrättigheter och skyldighet för teamen att hålla sina fakta aktuella.
| Förutsättning | Vad som måste beslutas | Vad som ska finnas på plats |
|---|---|---|
| Uppdragsgivare och mandat | Vem kan kräva gemensamma produktionsgrindar, metadata och golden paths? | Uppdragsbeskrivning och beslutande forum. |
| Portal som produkt | Vilken funktion äger roadmap, användarupplevelse, drift och support? | Produktägare, förvaltningsansvarig och teamkapacitet. |
| Huvudkällor | Vilket system äger varje typ av fakta och hur synkroniseras den? | Fastställt vilket system som äger vad, med API- och eventåtkomst. |
| Teamkontrakt | Vilka uppgifter måste varje team publicera och hur ofta granskas de? | Gemensam scorecard och ansvarsfördelning. |
| AI- och datapolicy | Vilka verktyg, modeller och dataklasser får användas i vilka miljöer? | Godkänd policy, datazoner och undantagsprocess. |
| Plattformskontrakt | Vad erbjuder drift som självservice och vad kräver godkännande? | Krav på OpenShift/GitOps, backup, secrets och observability. |
| Kvalitetsbas | Vilka kontroller är alltid hårda och vilka är riskbaserade? | Gemensam CI-profil som kan köras lokalt och centralt. |
| Första användarresor | Vilka konkreta problem ska lösas först för att visa nyttan? | Valda användarresor med mätbart utgångsläge och exitkriterium. |
Portal, katalogschema, sök, templates, CI-baseline, integrationsramverk, agentpaket, scorecards och användarstöd.
Syfte, domänregler, API-kontrakt, docs, lifecycle, support, runbook, risk och operativt ansvar.
Runtime, identitet, nätverk, datazoner, backup, incidentkrav, policy, undantag och plattforms-SLO.
Portalteamet ska inte bli kommunens dokumentationssekreterare. Teamen ska kunna bidra genom Git, formulär och AI-assisterade PR:er; portalteamet förvaltar modellen och automatiken som gör bidragen enkla och kvalitetssäkrade.
En utvecklare ska kunna börja från en uppgift, ett team, ett område eller ett system och ändå nå samma källor, relationer och självserviceoperationer.
Innan något byggs bör vi räkna hem vad en OpenShift-nära Backstage-distribution som Red Hat Developer Hub ger direkt. Den kan täcka en stor del av portalens grundfunktioner, vilket flyttar vårt arbete från plattformsbygge till kommunens egna kopplingar och innehåll.
| Behov i propositionen | Finns i plattformen | Vad vi själva behöver göra |
|---|---|---|
| Katalog över system, team, API:er och resurser | Software catalog med relationsmodell och discovery | Provider mot kommunens systemregister och indexering av GitLab och GitHub |
| Dokumentation nära koden | TechDocs med rendering och sök | Innehållet, granskningspolicyn och aktualitetskontrollerna |
| Nya projekt från golden path | Software templates med självservice | Kommunens templates, designsystem och kvalitetsgrindar i dem |
| Behörighetsfiltrerad åtkomst | RBAC och konfigurerbar autentisering | Koppling mot MobilityGuard och kommunens rollmodell |
| Maskinläsbar ingång för agenter | MCP-serverintegration och inbyggd AI-assistent | Avgränsning av vilka resurser som exponeras och mot vilka scopes |
| Portalhälsa och uppföljning | Scorecards, audit logs och användningsstatistik | Våra egna krav på ägarskap, aktualitet och produktionsgrindar |
| Utökning över tid | Dynamiska plugins | Plugin mot WSO2, testbädden och systemregistret |
Det här är inte ett produktbeslut. Poängen är att jämförelsen ska göras tidigt: en färdig distribution tar bort en stor del av grundbygget men kostar licens och binder oss till dess uppgraderingstakt, medan ren Backstage ger mer frihet mot mer eget underhåll. Beslutet hör hemma i beslutspunkt B.
Starta webbapp, koppla SSO, beställa certifikat, konsumera API, skapa testmiljö, läsa loggar, begära databas, publicera API eller lämna över prototyp.
Utforska område, team, domän, system, komponent, API, resurs, template, capability, skill, MCP-server, pipeline eller runbook.
Filter på team, lifecycle, typ, domän, klassning och portalhälsa.
SystemSyfte, team, stack, komponenter, API:er, miljöer, docs och agenttillgångar.
TeamUppdrag, kontakter, system, repositories, boards, standards och support.
ReceptEn enda väg för certifikat, domän, SSO, WSO2, databas och deploy.
TemplateRepo, dokumentationsskal, CI, preview, katalogpost och agentkontext.
Agentllms.txt, sök-API, manifest, skills, MCP och samma behörigheter som användaren.
| Fakta | Huvudkälla | Portalens ansvar |
|---|---|---|
| Systemidentitet, lifecycle, kritikalitet och övergripande ägarskap | Kommunens systemregister | Synka, relatera och flagga konflikter eller saknade ägare. |
| Team, medlemskap och organisatorisk tillhörighet | Identitets-/HR-källa (MobilityGuard + HR) | Visa Group/User-relationer och reagera på offboarding. |
| Kod, build, tekniska docs, ADR och runbook | Produktens Git-repo (internt GitLab eller GitHub-organisationen Sundsvallskommun) | Rendera TechDocs, verifiera schema och länka till PR-flöde. |
| API-kontrakt och exempel | OpenAPI/AsyncAPI i Git | Indexera, poängsätta kvalitet och länka konsumenter. |
| Publicerad API-status, plans och subscriptions | WSO2 API Manager | Visa levande status och leda till kontrollerad självservice. |
| Miljöer, deployment och release | GitOps/OpenShift | Visa status, evidence, loggar, SLO och säkra commands. |
| Secrets, privata nycklar och certifikatmaterial | Secret-/certifikatsystem | Visa process och metadata, aldrig själva värdet. |
| Skills, MCP och plugins | Versionshanterade agentregister | Visa kompatibilitet, ägare, scopes, version och installväg. |
Startvyn kan visa verkliga resultat från automatiska kontroller. Antal och status ska räknas från katalogen och aldrig skrivas in manuellt.
Autonom kontroll ska mäta portalens fullständighet, inte medarbetares prestation. Ett stopp är antingen en dokumentations-/plattformsdefekt som ska tas bort eller en medveten mänsklig grind som ska finnas kvar.
Backstages kärnmodell är en bra start: Group, Domain, System, Component, API, Resource och Template. Sundsvall bör först använda dessa typer väl och bara införa egna kinds när ett verkligt behov inte kan uttryckas med typ och metadata.
Undvik schema-sprawl. En skill kan initialt vara en Component med type: agent-skill, en MCP-server en Component med type: mcp-server och ett plugin en Component med type: agent-plugin. Skapa inte tre nya katalog-kinds innan sök, ägarskap och relationer är bevisat otillräckliga.
Posterna ovan är illustrativa och innehåller inga verkliga interna ägar- eller miljöuppgifter. I skarp portal ska dessa hämtas från huvudkällorna.
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: example-webapp
description: Kort, verksamhetsorienterad beskrivning
annotations:
backstage.io/techdocs-ref: dir:.
sundsvall.se/system-id: SYS-0000
sundsvall.se/golden-path: web-vnext
spec:
type: website
lifecycle: experimental
owner: group:default/team-example
system: system:default/example-system
consumesApis:
- api:default/example-api
Katalogfilen ska inte duplicera allt. Den bär tekniska relationer och pekare; systemregistret fortsätter äga systemets officiella registeruppgifter.
Den rekommenderade modellen är en federerad dokumentationsyta: innehållet lagras nära sin källa, granskas genom Git och sammanställs i portalen. Någon ny central CMS-databas behövs inte.
Arkitektur, runbook, domän, ADR, setup och felsökning versionshanteras tillsammans med koden och visas i portalen.
Onboarding, certifikatrecept, WSO2-flöde och policies kan ligga i egna Git-repon men registreras som sökbara docsobjekt.
Ägare, deployment, API-status och medlemskap hämtas från respektive källa och ska inte skrivas i löptext.
För personer som inte vill redigera Markdown direkt bör portalen erbjuda Redigera sidan och Föreslå med AI. Båda ska skapa en branch eller pull request mot den kanoniska Git-källan.
| Alternativ | Styrka | Risk / villkor | Rekommendation |
|---|---|---|---|
| Backstage/RHDH TechDocs + GitHub-redigering | Minst ny teknik; docs nära kod; PR-review; sökbart i portalen. | Redigeringsupplevelsen är teknisk för vissa roller. | Startpunkt. Lägg till formulär och AI-assisterat PR-utkast. |
| Git-backed editor, exempelvis Decap CMS | Enkel redaktionsvy; editorial workflow kan skapa branches och PR:er. | Ytterligare drift, auth och innehållsmodell; passar bäst för välstrukturerade docs. | Utvärdera om användartest visar att Git-flödet blockerar bidrag. |
| Git-backed visual editor, exempelvis TinaCMS/TinaDocs | Visuell redigering med Markdown i Git och preview. | Produkt-/licens-/hostingbeslut och tätare frontendkoppling. | Kandidat för rikare redaktionell upplevelse, inte förhandsvalt. |
| Confluence som fortsatt huvudkälla | Bekant för många och låg initial förändring. | Svårare att hålla dokumentation och kod i synk; sämre stöd för schema, PR-granskning och agentkontext; risk för motstridiga uppgifter. | Indexera under övergång, men markera legacy och flytta teknisk kanonisk kunskap. |
Agenten analyserar diff, kontrakt, katalogpost och befintliga docs.
ut: dokumentationspåverkanUppdaterar relevanta sidor, exempel, changelog och agentreferenser.
ut: PR-diff, inte direktpubliceringSchema, länkar, kodexempel, OpenAPI-referenser, ägare och aktualitet.
ut: verifierad dokumentationDen som äger fakta godkänner och portalen indexerar efter merge.
ut: publicerad och spårbar kunskap| Läge | Minsta dokumentation | Vad som inte krävs ännu |
|---|---|---|
| Utforskning | Syfte, skapare, repo, datatyp, TTL och tydlig prototypmarkering. | Full ADR-historik, SLO, förvaltningsplan och komplett klassning. |
| Handoff-kandidat | Spec, acceptanskriterier, integrationer, data, kända gap, testresultat och föreslaget ägarskap. | Slutlig prod-runbook om kandidaten ännu inte är godkänd. |
| Produktion | Ägare, lifecycle, klassning, ADR, runbook, rollback, backup, API/dataflöden, säkerhets- och accessibilitybevis. | Inga undantag utan synligt och tidsbegränsat beslut. |
Organisationsadministratörer ska förvalta baspolicy och gemensamma verktyg. Teamledare ska förvalta sitt teams system, dokumentation och agentprofil. Produktrepon ska endast beskriva sina lokala avvikelser.
Teamnamn, syfte, ansvarsområde, supportkanal, beredskap och kontaktvägar.
System, components, APIs, resources, templates, docs och data products.
Golden paths, kodstandard, boards, repoorganisation, release- och incidentprocess.
Plugins, skills, MCP-servrar, scopes, testuppgifter, evalresultat och ägare.
Ändringen görs i systemregister, repo eller plattforms-API, inte i en separat portaldatabas.
Schema, relationer, säkerhetsklass, länkar, ägare och agentmetadata kontrolleras.
Rätt team godkänner fakta och portalteamet granskar endast plattformsmodell och gemensamma standarder.
Portalen ska ha ett onboarding-recept som tar en ny utvecklare, eller en utvecklare som byter team, hela vägen från åtkomst till första godkända pull request. Allt som beskrivs här ska finnas som klickbara recept i portalen, inte som muntlig kunskap hos en kollega.
Konto via MobilityGuard, medlemskap i rätt team samt åtkomst till internt GitLab, GitHub-organisationen och portalens katalog.
ut: inloggad med rätt behörigheterIDE, Claude Code eller Codex, organisationens plugin från marketplace och teamets plugin med domänkunskap.
ut: fungerande AI-uppsättningSkapa eller klona ett golden path-repo, kör lokalt med syntetisk data och skapa en preview i testbädden.
ut: körande app med preview-URLGör en liten ändring, låt reviewagenten och kvalitetsgrindarna köra och få den granskad av teamet.
ut: första merge, med bevisKommunens kod bor på två platser, och portalens katalog binder ihop dem. En ny utvecklare ska aldrig behöva gissa var ett repo ligger eller vem som förvaltar det.
| Verktyg | Roll i dag | Kommentar |
|---|---|---|
| Claude Code | Rekommenderad för utveckling i IDE | Stöd för plugins, skills, MCP och marketplace-distribution, vilket gör organisationens och teamets kontext enkel att distribuera. |
| Codex | Rekommenderad för CI-flöden och granskning | Stöd för AGENTS.md och skills, och mönstret används redan i kommunens säkerhetsgranskning. |
| opencode | Dokumenterat alternativ | Öppen källkod och modellagnostiskt. Finns med i dokumentationen för att visa att arbetssättet inte är låst till en leverantör. |
Kunskapen ska ligga i portalen, i AGENTS.md, i skills enligt den öppna Agent Skills-standarden och i MCP-servrar med öppna kontrakt. Då blir valet av verktyg ett litet beslut som kan omprövas när marknaden förändras, utan att kommunens samlade kontext går förlorad.
Mätetal: tid från första arbetsdag till första mergade pull request. Den siffran ska synas i portalens hälsovy och pressas nedåt med bättre recept, inte med sänkta krav.
När AI skriver mer kod flyttas flaskhalsen från tangentbordet till behovsförståelse, beslut och verifiering. Därför ska processen optimera för snabba iterationer utan att låta prototypgenvägar smyga in i produktion.
Verksamhet och teknisk roll bygger fungerande prototyper från samma grund, med syntetisk eller offentlig data.
utfall: bekräftad riktning och feedbackAI hjälper till att omvandla prototyp och feedback till spec, acceptanskriterier, kontrakt, datamodell och risker.
utfall: mänskligt ägd specBeslut fattas om koden ska härdas eller regenereras. Fulla quality gates, arkitektur- och säkerhetsreview aktiveras.
utfall: förvaltad releasekandidatRutinarbete kan lämnas till agenter i sandlådor som skapar PR:er. Större förändringar går tillbaka till utforskning.
utfall: kontinuerlig förbättringPrototypen är byggd på golden path, arkitekturen håller och genvägarna är tydliga. Koden tas vidare genom fulla grindar.
Prototypen bär konceptuell skuld efter många iterationer. Spec och tester behålls, implementationen skapas om på samma mall.
Det finns ingen dogm om att prototypkod alltid ska kastas eller alltid ska behållas. Tillgången som måste överleva är verksamhetsinsikten, specen, kontrakten och de godkända testkriterierna.
Utvecklarens uppgift ska vara att granska arkitektur, dataflöden, skalbarhet, säkerhet och produktionsmognad, inte att börja om eftersom prototypen saknar gemensam grund.
Den interna testbädden bör återskapa Dokploys viktigaste användarupplevelse (snabb deploy, tydlig status och tillgängliga loggar) ovanpå kommunens identitet, OpenShift, policy och GitOps.
Från repo och vald golden path, med namespace, URL, quotas och TTL.
Realistisk syntetisk data och reproducerbar återställning till känt läge.
Scope-begränsat till tjänst, miljö och kort tidsperiod, med masking.
Tidsbegränsad URL, tydlig prototypbanner och användartest utan proddata.
Samla repo, spec, integrationer, testresultat, screenshots och kända gap.
TTL och kostnadsstyrning minskar skuggdrift och glömda miljöer.
| Profil | Användning | Backupkrav | Återställningsbevis |
|---|---|---|---|
| Stateless preview | UI, mockar och kortlivad demo. | Ingen databasbackup; allt återskapas från Git och seed. | Ny miljö kan skapas reproducerbart. |
| Disposable data | Prototyp med syntetisk databas. | Seed/reset i stället för traditionell backup. | Automatiskt resettest. |
| Persistent non-prod | Längre pilot eller integrationstest. | Schemalagd backup/snapshot enligt klass och värde. | Periodiskt restoretest till isolerad miljö. |
| Production state | Förvaltad verksamhetsprodukt. | Fastställda RPO/RTO, retention, kryptering och ansvar. | Dokumenterad och övad återställning med evidence. |
Alla prototyper behöver inte produktionsklassad backup. Kravet ska styras av stateprofil, data och hur dyrt det är att återskapa läget. Överkrav i utforskning skapar bara en ny beställningskö.
Dagens externa Dokploy-miljö är en del av utgångsläget för testbädden. Den hanterar endast icke-känslig data och beskrivs tillsammans med den interna målbilden under Förutsättningar från drift och DevOps.
Portal, golden paths och reviewagenten får full effekt först när driften erbjuder ett antal gemensamma tjänster som varje ny app ansluter till automatiskt. Detta är beställningslistan till drift och DevOps, formulerad som förmågor snarare än produktnamn och i en ordning som kan tas stegvis.
| # | Förmåga | Vad som behöver finnas | Varför |
|---|---|---|---|
| 01 | Central logghantering | Gemensam loggplattform dit alla appar och tjänster skickar strukturerade loggar med trace-/correlation-id. Behörighetsstyrd sökning per tjänst, team och miljö. Retention och masking per informationsklass. | Felsökning utan serveråtkomst, incidentunderlag enligt cybersäkerhetslagen och säker logläsning för både människa och agent. |
| 02 | Gemensamt backupsystem | Backup-as-a-service för databaser och persistent lagring: schemalagda backuper, retention, kryptering och återkommande restoretester. Anslutning sker via golden path i stället för manuell beställning. | Ingen tjänst ska produktionssättas utan verifierad återställning; överlämningar och kommunens kontinuitetskrav förutsätter det. |
| 03 | Secrets och certifikat | Bygg vidare på det som redan finns i OpenShift: Secrets som bas, External Secrets Operator för att hämta värden från ett centralt valv, och cert-manager-operatorn för utfärdelse och förnyelse. Domänbeställning läggs till som spårbart workflow. | Inga hemligheter i repo eller agentkontext. Cert och domän slutar vara personberoende specialistarbete, och vi slipper införa en ny produkt för något plattformen redan stödjer. |
| 04 | GitOps-motor | OpenShift GitOps eller Argo CD, där Git är huvudkällan. Promotion, rollback och konfigändringar som granskade change sets. | Reproducerbar deploy, spårbarhet och en säker väg för agentinitierade förändringar. |
| 05 | Container- och artifactregistry | Godkända basimages, image scanning, SBOM, signering/provenance och retention. Admission control som stoppar overifierade images. | Supply chain-säkerhet och samma leveransform i test och produktion. |
| 06 | CI-kapacitet | Runners för internt GitLab CI och GitHub Actions i Sundsvallskommun-organisationen, delade pipeline-templates och cache. | Gemensamma kvalitetsgrindar förutsätter att pipelines har kapacitet att köra snabbt. |
| 07 | Observability utöver logg | Metrics, traces, dashboards, alerting och SLO kopplade till katalogens entities. En statusvy per tjänst i portalen. | ”Är det nere?” ska besvaras av en sida, inte av en person. |
| 08 | Testbädd och preview | Namespace-självservice med TTL, quotas, syntetisk data och databaser on demand. Automatisk rivning. | Prototyper och användartester utan väntetid och utan skuggdrift. |
| 09 | Identitet som självservice | OIDC-klientregistrering mot MobilityGuard som workflow, service accounts, kortlivade tokens och miljöseparerade klienter. | SSO-anslutning är i dag ett manuellt moment i varje projekt; det ska ta minuter, inte ärenden. |
| 10 | WSO2 non-prod och API-flöde | Dev-/testmiljöer i WSO2 och ett apictl-baserat CI-flöde så att API-uppdateringar promotas från Git i stället för att klickas in manuellt. | API-publicering blir spårbar och AI kan förbereda ändringarna som change requests. |
| 11 | Sandbox för AI-agenter | Isolerade körmiljöer där agenter kan bygga, testa och verifiera utan produktionsåtkomst, med resurstak och audit. | AI-first utveckling kräver att agenten kan verifiera sitt eget arbete säkert. |
| 12 | Incident- och larmvägar | Larm kopplade till ägande team enligt katalogen, eskaleringsvägar och incidentprocess som även täcker AI-relaterade händelser. | Övervakning utan mottagare är bara lagring. |
Numreringen är också en grov prioritetsordning: logg (01), backup (02) och secrets/certifikat (03) är förutsättningar för nästan allt annat och bör beställas först. Inget kräver ett nytt produktinköp per rad; flera förmågor kan levereras av det som redan finns i OpenShift-plattformen och Red Hats ekosystem, om de paketeras som självservice.
Hur de beställda förmågorna sedan exponeras för utvecklarna beskrivs på en egen sida: Självservice i tre nivåer. Här beställs förmågorna, och självservicemodellen avgör hur de används utan väntetid och utan att säkerhetskraven sänks.
Snabb deploy, tydlig status, loggar och schemalagda backuper för appar utan känslig data. Dokploys officiella MCP-server visar dessutom hur en hel deployplattform kan göras agentstyrbar.
Den interna plattformen ska matcha Dokploy-upplevelsen (deploy, status, loggar, backup) men med MobilityGuard-identitet, WSO2-koppling, katalogregistrering och kommunens policy.
Mål: att utvecklare väljer den interna vägen för att den är enklast, inte för att policyn kräver det. Mät andelen nya projekt som startar internt och tiden till en fungerande miljö. Fram till dess är varje kvarvarande skäl att gå externt en konkret backlogpost för driften.
Självservice betyder inte fri åtkomst. Det betyder att säkerheten flyttar från väntetid och ärendekö till förhandsgodkända mönster, policy som kod och audit på allt. Varje förmåga i DevOps-beställningslistan placeras på en av tre nivåer.
Skillnaden är inte hur mycket vi litar på medarbetaren. Den är vem eller vad som fattar beslutet, och varför det är försvarbart att göra det på just den nivån.
| Nivå | Vem fattar beslutet | Varför det är säkert |
|---|---|---|
| 1 · Full självservice | Beslutet är fattat i förväg, som policy. Plattformen kontrollerar ramarna och utför direkt. | Ramarna begränsar konsekvensen i sig: non-prod, TTL, quota, syntetisk data och läsning som är begränsad till egna tjänster. Går något fel är skadan liten och reversibel. |
| 2 · Automatisk kontroll | Automatiken bedömer. Begäran valideras mot förhandsgodkända mönster och godkänns eller avslås maskinellt, med motivering. | Ett verkligt beslut fattas, men kriterierna går att uttrycka som regler: godkänd domän, känd zon, giltigt kontrakt, tak som inte överskrids. |
| 3 · Mänskligt godkännande | En namngiven människa bedömer. | Beslutet kräver en avvägning som inte går att koda: verksamhetsrisk, sekretess, exponering utåt eller åtkomst till skarp data. |
En förmåga hör alltså till nivå 1 när gränserna gör bedömningen onödig, till nivå 2 när bedömningen går att formulera som regler, och till nivå 3 när den kräver omdöme. Det gör placeringen till en fråga om kriterier, som ansvariga funktioner fastställer och omprövar, i stället för en förhandling om förtroende.
Även nivå 3 är självservice i formen: en strukturerad begäran med all kontext, spårbarhet och tydlig mottagare. Skillnaden mot nivå 1 och 2 är att ett människobeslut ingår, inte att processen är ett mejl. Målet över tid är att flytta ärenden från nivå 3 till nivå 2 genom att koda fler förhandsgodkända mönster, utan att någonting flyttas förbi säkerhetsgrindarna.
Kommunens nuvarande web-app-starter har redan tagit viktiga steg med strict TypeScript, type-aware ESLint, Knip, Vitest och Playwright. Rekommendationen är att bygga vidare på den basen i stället för att byta testramverk igen.
strict| Lager | Verktyg / metod | Vad som ska testas | Vad som ska undvikas |
|---|---|---|---|
| Typer och statik | TypeScript strict, ESLint, Knip, formattering | Ogiltiga states, dead code, unsafe async, imports och kontrakt. | Att tysta fel med any, ts-ignore eller breda disables. |
| Unit | Vitest | Ren domänlogik, transformationsregler och felhantering. | Tester av implementationens privata detaljer. |
| Komponent | RTL/Vitest och Storybook browser tests | Beteende, keyboard, loading, empty, error och permissions. | En E2E per prop eller variant. |
| Tillgänglighet | axe + manuella checklistor | Automatiskt detekterbara fel plus riktiga centrala flöden. | Att påstå WCAG-compliance enbart från axe. |
| Responsivitet | Storybook viewports och Playwright screenshot/smoke | Utvalda brytpunkter, overflow, navigation och formulär. | Alla sidor i alla skärmstorlekar på varje commit. |
| E2E | Playwright | Ett fåtal kritiska användarresor och integrationer. | Lång, flakig svit som duplicerar unit- och komponenttester. |
| Kontrakt | OpenAPI/AsyncAPI diff och consumer tests | Breaking changes, auth, schemas och examples. | Handskrivna dubbletter av API-typer. |
Använd acceptance-first som standard: innan större implementation godkänner människan beteenden, edge cases och kontrakt. AI genererar tester mot dessa kriterier. TDD är särskilt värdefullt för domänlogik, buggrättningar och kontrakt, men en täckningssiffra får inte driva fram meningslösa tester.
Försök inte klassificera om kod är AI-genererad. Sådana klassificerare är opålitliga och frågan är sekundär. Blockera eller flagga i stället konkreta kvalitetslukter.
Unused code/deps, any, ts-ignore, tomma catch, hardcoded secrets/URLs, debugloggar, mock endpoints i prod och trasiga imports.
Cirkulära beroenden, lagerbrott, duplicerade komponenter, för hög komplexitet, för stora filer och avvikande katalogstruktur.
Placeholdertext, onödiga abstraktioner, osammanhängande naming, saknade states, upprepade kommentarer och tester som bara speglar implementationen.
SOLID, maintainability och robusthet bör uttryckas som konkreta arkitekturregler, dependency boundaries, felhanteringsmönster och reviewrubriker. En subjektiv ”SOLID-linter” bör inte vara hård grind.
Eneos säkerhetsreview bygger på att en betrodd person kommenterar /review på en pull request. Mönstret är prövat för säkerhetsgranskning, men internt bör granskningen gå ett steg längre: reviewagenten körs automatiskt när en pull request öppnas eller markeras som redo, och /review finns kvar som manuell omkörning efter större ändringar. Ingen ska behöva komma ihåg att be om granskning för att få den.
Samma strukturerade review täcker säkerhet, tillgänglighet, responsiv design, arkitektur och testkvalitet. Deterministiska verktyg som axe, secret scanning och SAST är fortsatt hårda grindar; agenten förklarar, prioriterar och fångar det som verktygen missar.
Första passet tar fram kandidatfynd; andra passet försöker aktivt motbevisa dem. Bara fynd som överlever det andra passet publiceras, utan stilkommentarer och vaga möjligheter. Fingerprints hindrar att samma fynd upprepas vid varje ny commit.
En strukturerad kommentar med severity-sammanfattning, spårbara fynd och en kopierbar åtgärdslista som en kodagent kan ta vidare. Fyndregistret sparar mänskliga beslut som false positive och accepted risk. Agenten läser enbart diffen och saknar shell-, webb- och skrivåtkomst.
Samma grind före överlämning. När en IT-strateg eller projektledare har byggt en prototyp med Claude Code körs granskningen automatiskt på den avslutande pull requesten. Utvecklaren tar emot en kandidat med kända fynd och en färdig åtgärdslista i stället för en okänd kodmassa. Även den som inte är utvecklare får sin kod granskad, och det ansvariga teamet bedömer fynden.
Automatisk körning kräver enkel brus- och kostnadskontroll: kör alltid på produktions- och överlämningsflöden, riskbaserat på små ändringar, och låt en oförändrad bedömning vara tyst. En review som kommenterar allt lär folk att ignorera den.
| Kontroll | PR | Release / schemalagt |
|---|---|---|
| Secret scanning | Hård grind före merge | Repo- och historikscan enligt policy |
| CodeQL/SAST | Hård eller riskbaserad grind | Omkörning vid release av känsliga komponenter |
| Dependencies/licenser | Known critical/high blocker enligt policy | Kontinuerlig bevakning och auto-PR |
| Container/IaC | Konfiguration och image scan | Admission och verifierad artifact |
| Codex Security | Selektivt vid säkerhetskritiska diffar | Djupscan, periodisk scan och verifiering av fixes |
| Mänsklig review | All produktionskod med ansvarig ägare | Releaseapproval enligt riskklass |
Codex Security kan vara ett värdefullt extra lager om åtkomst, licens och databehandling godkänns. Kommunens kärn-CI får inte vara beroende av en enda generativ scanner och verktyget ersätter inte CodeQL, secrets, dependency-, image- eller IaC-scanning.
Agenten och utvecklaren ska använda en säker plattforms-API ovanpå OpenShift. Den ska ge enkla, avgränsade operationer och GitOps-baserade förändringar utan generell kubectl, pod-exec eller produktionskubeconfig.
De gemensamma tjänster som plattformen förutsätter (central logghantering, backupsystem, secrets, GitOps, registry och CI-kapacitet) finns samlade som konkret beställningslista under Förutsättningar från drift och DevOps, och hur de exponeras beskrivs i Självservice i tre nivåer.
| Förmåga | Minimikrav |
|---|---|
| Self-service | Repo, namespace, preview, URL, quotas, standardresurser och katalogregistrering via portal/API. |
| GitOps | Git är huvudkällan; promotion och rollback är change sets med policy och approval. |
| Identitet | SSO/OIDC via MobilityGuard, team- och rollstyrning, workload identities och kortlivade tokens. |
| Secrets/certifikat | Central hantering, rotation och injection; agenten ser referenser och status, inte värden. |
| Observability | Strukturerade loggar till central loggplattform, metrics, traces, dashboards och SLO kopplade till katalogentity. |
| Backup/restore | Gemensamt backupsystem med stateprofiler, schemaläggning, policy, RPO/RTO där relevant och verifierbara restoretester. |
| Supply chain | Godkända basimages, SBOM, signering/provenance, image/IaC scan och admission. |
| Audit | Användare, agent, tool, commit, miljö, parametrar, resultat och approval. |
| Isolation | Network policies, quotas, pod security och tydlig miljöseparation. |
list_services
get_deployment_status
query_logs
read_metrics
read_slo
explain_policy_failure
create_preview
refresh_preview
stop_preview
reset_synthetic_data
run_smoke_test
request_promotion
request_rollback
request_config_change
request_restore_test
apply_arbitrary_yaml, fri shell eller pod-exec.Målet är den upplevelse som beskrivs under Drift och DevOps, fast i kommunens kontrollzon. En intern plattforms-MCP ska exponera ett smalt, behörighetsstyrt urval av operationer i stället för hela plattforms-API:t.
Innan API:erna görs agentstyrda behöver katalogen hålla. Syfte, ägare, kontrakt, auth, lifecycle och relationer ska finnas på plats, och vägen från OpenAPI till WSO2 ska vara automatiserad.
Tjänstens kontrakt och API-metadata i Git är den granskningsbara källan.
ut: versionerad API-definitionBreaking change, security scheme, examples, lint och WSO2 governance dry-run.
ut: godkänd change setapictl uppdaterar dev/test med miljöparametrar och verifiering.
PR/approval, artifact promotion, smoke och kataloguppdatering.
ut: spårbar WSO2-releaseWSO2 API Controller stödjer CI/CD, flytt av API:er mellan miljöer och OpenAPI-baserade API projects. Sundsvall bör paketera detta som en golden path och dölja repetitiva kommandon bakom portalens template och pipeline.
En verksamhetsförmåga ska först beskrivas genom kontrakt, policy och ägarskap. Därefter kan den exponeras genom SDK, CLI, portal och, där det ger nytta, en smal MCP-adapter. MCP är ett klientgränssnitt, inte kommunens verksamhetsarkitektur.
Sundsvall har en värdefull central package-modell i SK Web GUI, men också kostnad för egen komponentutveckling, dokumentationsgap och behov av bättre responsivitet och accessibility. Beslutet är därför inte svart eller vitt.
Kvalitets- och leveranskontraktet kan beslutas nu, oberoende av vilket UI-paket som väljs. Det gör mönstren konsekventa när fler personer och agenter utvecklar, och gör det svårare att göra fel.
| Förmåga | Föreslagen standard | Princip |
|---|---|---|
| Framework | Next.js App Router + React | Gemensam routerprofil för nya appar; separat SPA-profil först vid bevisat behov. |
| Språk | TypeScript strict | Strikta flaggor, generated types och allowJs: false i nya appar. |
| Server state | TanStack Query vid interaktiva behov | Server Components där de är enklare; serverdata dubbellagras inte. |
| Formulär | React Hook Form + gemensamt schema | Ett mönster för validation, errors, focus och tillgänglighet. |
| Client state | Zustand endast vid tydligt lokalt behov | URL- och serverstate dupliceras inte i globala stores. |
| Kontrakt | Genererade OpenAPI-klienter | Typad kedja hela vägen genom BFF. |
| Workspace | En installation, en lockfil | Reproducerbar workspace är kravet, inte ett visst verktygsmärke. |
Route / Server Component
→ feature/use-case
→ generated API client eller BFF
→ vald central UI-package
→ appägda blocks och komposition
Bibliotek införs där de tar bort återkommande komplexitet, inte som krav för enkla vyer som redan löses väl av React, serverkomponenter och semantisk HTML.
| Väg | Fördelar | Nackdelar | Vad som måste bevisas |
|---|---|---|---|
| Härda SK Web GUI | Minst migration, central uppdatering, etablerat API och visuellt språk. | Fortsatt eget underhåll; gap inom komponentbredd, responsivitet och accessibility. | Att kvaliteten kan höjas tillräckligt med dokumentation, primitives, tester, MCP och contribution. |
| Behåll API, byt internals selektivt | Konsumenter påverkas lite; mogna headless primitives kan minska buggyta. | Kompatibilitetslager kan bli långlivat; alla komponenter passar inte samma strategi. | Att intern ersättning faktiskt minskar underhåll och inte bara flyttar komplexitet. |
| Ny central shadcn-kompatibel plattform | Stort ekosystem, AI-familiaritet, registry/MCP/skills och fler färdiga blocks. | Migrering, nytt Figmaflöde, central package-modell måste återbyggas och kvalitet verifieras. | Att agentkvalitet, komponenttäckning och underhållsvinst överstiger migrationskostnaden. |
Oavsett UI-väg ska kärnkomponenter levereras som ett centralt, versionshanterat package. En knappfix publiceras som patch och rullas ut genom automatiska PR:er med apparnas egna tester. Kärnprimitives ska inte kopieras in i varje produktrepo.
Om en shadcn-kompatibel väg väljs kan ett privat registry användas för blocks, templates, migrationsstöd och appägda kompositioner, medan centrala primitives ligger i ett package. Det kombinerar central förvaltning med agentvänlig installation.
Betalda eller community-förvaltade shadcn-baserade Figma-/blockkit, där shadcncraft endast är ett exempel, kan användas som upstream seed. De ersätter inte kommunens egen källa.
Rätt att modifiera, lagra internt, exportera och fortsätta förvalta om leverantören försvinner.
Adoption, releasehistorik, community, issuehantering och versionskompatibilitet.
Figma, React, tokens, variants, responsive states, dark mode, accessibility och Storybook.
export type ButtonSize = "sm" | "md" | "lg";
export type ButtonVariant =
| "primary"
| "secondary"
| "tertiary"
| "destructive";
export interface ButtonProps
extends React.ButtonHTMLAttributes<HTMLButtonElement> {
size?: ButtonSize;
variant?: ButtonVariant;
loading?: boolean;
}
CSS-variabler sköter rendering och teman. TypeScript-exports, tokenunions och package subpath exports ger autocomplete, go-to-definition och compile-time-fel. En egen språkserver behövs inte.
dept44, Spring Boot, OpenAPI, testmönster och befintliga agentkonventioner ger mycket att bygga vidare på. Nästa steg är att katalogisera tjänster och domänkunskap samt förenkla hela vägen genom WSO2 och drift.
När ska en ny mikrotjänst skapas, när ska befintlig utökas och hur undviks agentdriven service-sprawl?
Vilka datalagerprofiler stöds, vem äger schema, migration, backup och data retention?
AsyncAPI, idempotens, retry, dead-letter, schema registry och observability.
Service identities, användardelegering, scopes och gemensam authorizationmodell.
Standardresurser, health, SLO, autoscaling, loggning, traces och graceful shutdown.
Versionering, deprecation, consumer notification och WSO2-promotion.
En gemensam plugin kan paketera skills och MCP-konfiguration, men den ska inte duplicera hela portalen i prompttext. Stabil kunskap ligger i docs/skills; aktuellt tillstånd hämtas via sök, API och smala MCP-resurser.
En plugin paketerar skills, MCP-konfiguration, kommandon och regler till en installerbar enhet. Sundsvall har redan en tidig plugin-distribution på GitHub; nästa steg är att förvalta den som en marketplace med tydligt ägarskap och granskning.
En versionshanterad katalog i Git där plattformsteamet granskar och publicerar. Claude Codes marketplace-format är ett färdigt spridningssätt i dag, och en egen enkel variant är fullt möjlig eftersom formatet i grunden är ett repo med manifest.
Varje team äger sin plugin med domänskills, MCP-servrar och regler. Teamledaren förvaltar innehållet och organisationsnivån förvaltar baspolicyn, så att den som byter team får rätt kontext direkt.
Skills skrivs enligt Agent Skills-standarden och fungerar då i Claude Code, Codex och andra verktyg. En källa per skill; adapters genereras i stället för att innehållet kopieras.
Formatet avgör bara hur plugins sprids, inte var kunskapen låses fast. Claude Codes plugin-marketplace och OpenAI:s pluginformat är båda rimliga kanaler, och en egen minimal marketplace kan komplettera. Det som inte får låsas in är innehållet: skills enligt öppen standard, AGENTS.md och MCP-kontrakt ska kunna flyttas mellan verktyg utan omskrivning.
search_catalogSök system, team, API, recept, templates och agentassets med permission filter.
get_entityHämta aktuell entity, relationer, owner, lifecycle och länkar.
get_documentHämta en avgränsad, versionsmärkt TechDocs-sida eller sektion.
get_recipeSteg för exempelvis certifikat, SSO, WSO2 eller deploy.
list_templatesGolden paths med inputschema, status och ägare.
get_scorecardVisa vilka portal-/produktionskrav en produkt uppfyller.
Börja read-only. Dokumentationsuppdatering sker genom Git-PR. Plattformshandlingar ligger i en separat MCP med egna scopes och approvals. En gigantisk ”Sundsvall MCP” ökar attackyta och gör ägarskap otydligt.
SKILL.md kort och handlingsorienterad.Ett BI-gränssnitt som kör fri SQL ger agenten mer åtkomst än någon kan överblicka. Bygg i stället ett semantiskt lager med godkända mått, dimensioner och åtkomstregler. Varje svar ska gå att härleda.
Individdata får bara nås genom en särskilt godkänd capability med ändamålsbunden åtkomst, och ska normalt inte läggas i en generativ modells kontext.
För metakatalogen bör de capabilities som införs först vara avgränsade och tydligt namngivna.
current-user.profile ger den inloggade sina egna uppgifter.organization.unit.search söker förvaltning, avdelning och enhet.service.owner.lookup slår upp vilket team som äger en tjänst.role.entitlements visar vilka behörigheter en roll ger.data-product.search söker dataprodukter med ägare och kontrakt.resident.search eller en capability som listar alla användare.Sveriges cybersäkerhetslag (2025:1506), som genomför NIS2, gäller sedan den 15 januari 2026. Portalen kan samla och verifiera tekniska bevis för riskhantering, ägarskap, incidentvägar och återställning, men metadata i portalen är inte i sig juridisk compliance.
Öppen källkod, publika API:er, generella patterns och icke-känsliga docs.
Interna systemrelationer, guider, team och lågkänslig driftmetadata.
Klassade runbooks, sårbarhetsdetaljer, dataflöden och incidentmaterial.
Tokens, privata nycklar, lösenord, rå persondata och produktionsdump.
Laglig grund, sekretessbedömning, DPIA, tillämpningsområde och slutlig riskacceptans kan stödjas av formulär och AI-utkast men måste avgöras av behöriga funktioner.
Varje steg får gå vidare när föregående förmåga fungerar i en verklig användarresa. Det ger en roadmap som kan pitchas och beslutas utan att lova tidsåtgång innan organisationens kapacitet och integrationsförutsättningar är kända.
Uppdragsgivare, portalproduktägare, plattformsteam, teamansvar, AI-/datapolicy och beslutande forum.
Det är tydligt vem som får kräva metadata, produktionsgrindar och teamägarskap.
Portalbas och portalmodell, systemregisterprovider, GitLab-/GitHub-discovery, Group-sync via MobilityGuard/HR, API-katalog och permissionmodell.
En ny utvecklare kan hitta ett system, dess team, repo, API:er och support utan att fråga en person.
En moderniserad webbstarter, dept44-profil, syntetiska data, preview, logs, TTL och handoff.
En idé kan bli en delbar preview och lämnas över i samma repo utan manuell serverkopiering.
Strict checks, tester, accessibility, security, docs, SBOM, provenance, signering och scorecards.
En utvecklare kan verifiera en kandidat och se exakt vilka krav som saknas före produktion.
WSO2 API-as-code, safe platform APIs, cert/domain/identityrecept, GitOps-promotion och rollback.
Återkommande manuella beställningar har blivit spårbara workflows med rätt approvals.
Teamytor, agentprofiler, aktualitetskontroller, orphan detection, contribution och områdesvis anslutning.
Team kan själva hålla sin yta korrekt utan att portalteamet blir flaskhals.
Fler verksamhetsdrivna P0/P1-produkter, riskbaserade write-tools och migrering av legacyflöden.
Golden path är mätbart snabbare och minst lika säker som dagens manuella alternativ.
Portalägare, plattformsteam, källsystem, teamkontrakt, datazoner, prodgrindar och undantag.
Central logghantering, gemensamt backupsystem, secrets-/certworkflows, registry och runner-kapacitet enligt DevOps-beställningslistan.
Systemregistersync, GitHub discovery, TechDocs, sök, team-/systemsidor och portal-ready schema.
Template, repo, agentprofil, syntetisk data, OpenShift-preview, logs och handoff.
Uppgiftsbaserade recept först, automatiserade workflows efter att processen är standardiserad.
Current starter-bas, accessibility, responsive, security, docs och artifact supply chain.
Org/team/repo-agentkonfig, owner sync, stale checks och contribution workflow.
Tid till rätt system/API/ägare, tid till första lyckade PR och andel frågor som löses utan personberoende.
Idé till preview, deployment frequency, change failure rate, restore/rollback och manuella driftärenden.
Escaped defects, accessibility/security findings, testflakighet, stale docs, orphaned entities och undantagsålder.
Tid till användartest, prototyp till produktion, återanvändning, andel återkommande arbete som automatiseras och leveranskapacitet vid oförändrad bemanning.
Förslagen i propositionen är inte låsta. De ska ge en tillräckligt samlad bild för att ledningen ska kunna fatta beslut, och enskilda vägval kan omprövas när förutsättningarna är utredda.
Sundsvalls kommun etablerar en gemensam, intern och AI-läsbar utvecklarportal samt ett plattformsteam som förvaltar katalog, golden paths, testbädd, kvalitetspipelines och säker självservice som gemensamma produkter, med federerat innehållsansvar hos respektive team och mänskligt ansvar för all produktion.
Dokumentet kombinerar Sundsvalls befintliga devportal-koncept, publika repositories och den information som har lämnats om kommunens arbetssätt med officiell dokumentation för de tekniska plattformar som nämns. Exakta interna ägare, miljöer, klassningar och processer måste verifieras i organisationen.
En föreslagen agentingång till målbilden. I den skarpa portalen ska innehållet genereras från katalogen och peka vidare till behörighetsfiltrerade huvudkällor.
# dev.sundsvall.se > Intern utvecklarportal för Sundsvalls kommun. Samma katalog och dokumentation > används av människor och agenter. Läs endast innehåll som din identitet har rätt till. ## Börja här - /catalog: system, teams, components, APIs, resources och templates - /docs: TechDocs, recipes, runbooks och standards - /create: förvaltade golden paths - /agent/index.json: versionerat maskinindex - /mcp/catalog: read-only search och entity lookup ## Grundregler - Huvudkällor är systemregister, Git, kontrakt och plattforms-API, inte chatthistorik. - Läs AGENTS.md och vald skill innan implementation. - Sök befintlig component, API och recipe innan du skapar nytt. - Använd endast deklarerade capabilities och scopes. - Produktionsförändringar ska bli PR/change set och kräver rätt approval. - Hemligheter och rå persondata får aldrig läggas i modellkontext. - Kör project check och verify innan du föreslår merge. - Dokumentation och katalogmetadata uppdateras tillsammans med ändringen. ## Om något saknas - Skapa en portaldefekt med den uppgift du försökte lösa och var du fastnade.