Hovedkonklusion

En enkel udgivelsesmodel med offentlige versioner som v4.3 og v4.4 virker mere passende end et tungt versionssystem. Men gennemgangen giver ikke grundlag for at kalde arbejdstræet en ren og komplet v4.3, der er klar til udrulning. Der er stadig åbne spørgsmål om versionskilden, installationen, CI-kontrollerne og flere værtsintegrationer.

Gennemgangen var skrivebeskyttet. Der blev ikke ændret i repoet, opdateret versionsnumre, slettet historik, kørt tests eller foretaget en udrulning.

Versionsnummer og oprydning

Brug gerne versioner med to led, eksempelvis v4.3 og v4.4, udadtil. Behold V4 som den interne identitet for suiten; der er ingen grund til at omdøbe hele mappestrukturen, omskrive historikken eller indføre et kompliceret versionssystem alene for at vise et versionsnummer.

README-filen angiver stadig v4.2.0 (README.md:3), mens suite-indgangen angiver V4.2 (bmad-suite-v4/skills/bmad/SKILL.md:11). Versionskortlægningen i scripts/suite_versions.py:28 genkender kun V4 og giver ikke én fælles kilde til det mindre versionsnummer. Der er heller ikke fremlagt kontrollerbare oplysninger om, hvordan det eksterne v4.3-tag svarer til det lokale commit. Et nyt mærke eller en badge er derfor ikke nok til at fastslå, at versionerne stemmer overens.

Anbefalingen er at have én autoritativ versionskilde, som dokumentation, installationsbeskeder og CI kan kontrollere. Commit-id’er og filhashes bør fortsat bruges til at fastslå oprindelse og beskytte brugerens filer, men behøver ikke blive til et ekstra versionslag.

Der findes en ældre versionscache i .versions/v4.0.0/, som kan vurderes med henblik på oprydning, når det er afklaret, om en eksisterende installation eller et link stadig bruger den. Cacheindgangen i scripts/tag-cache.py:109 afviser allerede automatisk genbrug af caches med ældre tag-navne.

Andre historiske mapper bør ikke uden videre slettes som ubrugelige caches. verification/legacy-bmad-output/ er omtalt i en eksisterende ADR (docs/adrs/ADR-20261012-bmad-solo-anti-bureaucracy-and-programmatic-guards.md:232), og _bmad-solo-source/legacy-skills/ indeholder væsentligt materiale om oprindelsen til de ældre skills. Intet blev slettet under gennemgangen.

1. Installationsscript: gode beskyttelser, men mangler i brugerflowet

Flere vigtige sikkerhedsforanstaltninger er allerede på plads og bør bevares. Installationsindgangen afviser et urent arbejdstræ (install.sh:50); udrulningsindgangen kræver en fast-forward-opdatering og overdrager arbejdet til den nye version af scriptet (bs.sh:298); og den administrerede koordinator undersøger konflikter før skrivning (scripts/deploy-managed-cli.py:104). En enklere versionsmodel kræver ikke, at disse kontroller fjernes.

Der er dog huller i installationen. install.sh:14 accepterer kun kompatibilitetsargumenter for V4 og videresender ikke valg af vært, en skrivebeskyttet forhåndskontrol eller parametre for måltilstand. Krav til afhængigheder står primært i dokumentationen (README.md:30); installationsindgangen har ikke en samlet kontrol af dem.

Kilden bør også kontrolleres tydeligere. Eksisterende installationer bruger det lokale repo som indgang, mens opdateringer benytter den fjernadresse, der er angivet i konfigurationen (bs.sh:305). De gennemgåede indgange kontrollerer ikke, om fjernadressen stadig peger på det forventede repo.

Hold ansvarsfordelingen enkel: Installationsindgangen bør hente fra en betroet kilde, kontrollere forudsætninger og sende parametre videre. Udrulningsindgangen bør håndtere værter, forhåndskontrol, opdatering, afinstallation og beskyttelse af eksisterende filer. Der er ikke behov for endnu et versionsstyringslag.

2. CI håndhæver endnu ikke versionsreglen

Den nuværende workflow-fil (.github/workflows/ci.yml:3) kører ved push til hovedgrenen og ved pull requests, men ikke ved publiceringstags. Plugin-kontrollen (.github/workflows/ci.yml:41) undersøger struktur og navne, ikke formatet på udgivelsesversioner.

Tag-kontrollen i scripts/suite_versions.py:99 ser kun efter tegn på hovedversionen. De eksisterende tests (tests/roo_distribution/test_suite_versions.py:80) tillader både versioner med tre led og tags, der ikke er versionsnumre. Det er derfor ikke dækkende at sige, at reglen om to led allerede bliver fulgt.

Som minimum bør CI kontrollere, at nye udgivelsestags følger formatet v4.tal, at tagget stemmer med den autoritative versionskilde, og at versionsangivelserne i den aktuelle dokumentation er ens. Historikken behøver ikke omskrives, og reglen behøver ikke gælde tredjepartsafhængigheder.

CI bør også kontrollere, at skill-pakkerne er komplette. Der findes en validator (bmad-suite-v4/skills/bmad/scripts/validate-solo-package.py:5), men den bliver ikke kaldt i den nuværende CI (.github/workflows/ci.yml:55). Kontrollen bør desuden undersøge referencer efter installation, ikke kun referencer inde i repoet.

3. Upstream-skills: lokale tilpasninger, ikke en live-afhængighed

De aktive indgange fører i dag til suitens egne workflows (bmad-suite-v4/skills/bmad/references/capability-map.md:3). Distributionskortlægningen samler suite-mapperne (scripts/deployment_source.py:64), men ikke den eksterne mappe med historiske skills. Der blev heller ikke fundet nogen aktiv kæde, der løbende tjekker eller opdaterer skills fra upstream.

Det betyder, at upstream-skills ikke er en direkte kørselsafhængighed for de gennemgåede lokale indgange. Til gengæld opdateres lokale workflows, der er udtrukket og omskrevet fra upstream, ikke automatisk, når kilden ændrer sig. Det er en risiko for vedligeholdelsesdrift – ikke dokumentation for, at forskellene allerede håndteres automatisk.

De historiske skills kan heller ikke bare kobles til igen og erklæres klar. Den tidligere hjælpeskill afhænger eksempelvis af konfiguration, en oversigt over mapper og et parserprogram (_bmad-solo-source/legacy-skills/bmad-help/SKILL.md:25). Den tidligere build-skill bruger et renderprogram (_bmad-solo-source/legacy-skills/bmad-build-auto/SKILL.md:6). Det er ikke nok at kopiere en enkelt instruktionsfil.

En mere robust løsning er at bevare stabile lokale indgange til analyse og engineering og kun koble godkendte upstream-skills på, når de passer til capability-mappingen. Registrér kildecommit og nødvendige ledsagefiler. Ved opdatering bør forskelle i tilføjelser, sletninger og afhængigheder kontrolleres, før den nye version tages i brug. Opgaver i gang bør ikke læse direkte fra en upstream-hovedgren, der ændrer sig løbende.

Det er også værd at skelne mellem at opdage en opdatering og automatisk at skifte til den. En kontrol ved installation eller opdatering – eventuelt suppleret med en periodisk påmindelse – er en lettere løsning end en baggrundsproces, der hele tiden overvåger upstream.

4. Cline: CLI og plugin findes, men repoet er ikke tilpasset færdigt

Cline tilbyder både en CLI og IDE-plugins. Dokumentationen skelner mellem global konfiguration, der gælder på tværs af applikationer, og projektkonfiguration for det aktuelle workspace. 41

Repoet indeholder indtil videre kun en tynd routingskabelon, som ikke er aktiveret (bmad-suite-v4/cline/templates/bmad-router.md:3). En test af distributionen (tests/roo_distribution/test_host_adaptation.py:85) kræver, at skabelonen forbliver i et ikke-aktiveret spejl og ikke skrives til en aktiv Cline-regelindgang.

En anbefalet retning er at genbruge det samme metodiske indhold, men generere en tynd, tilpasset integration til henholdsvis CLI og plugin. Analyse- og engineering-roller kan mappes til Clines indbyggede Plan/Act-funktioner. Brugerne bør ikke være nødt til at huske særlige skill-kommandoer, og Roo-tilstandskonfiguration bør ikke importeres direkte.

Skabelonens metode-sti fortolkes relativt til repoets rod (bmad-suite-v4/cline/templates/bmad-router.md:8). Ved installation i et andet projekt skal placeringen af ressourcer derfor beregnes på ny; man kan ikke kopiere stien uændret og regne med, at linket stadig virker.

5. Roo og Gemini: filer på disk er ikke det samme som en fuld integration

For Roo indeholder distributionskortlægningen globale regler og udvalgte modes (scripts/deployment_source.py:86). Men at filerne findes på disk beviser ikke, at værten har indlæst dem. Derudover angiver ingen af de to custom modes tilladelser til MCP (bmad-suite-v4/roo/settings/custom_modes.yaml:5), mens validatoren fastlåser tilladelsesgrupperne (scripts/validate-roo-contracts.py:158). En integration med et destilleringsværktøj kræver derfor, at både konfiguration og validator gennemgås – ikke kun prompten.

Gemini er i dag et fysisk spejl af plugin- og regelmapperne (scripts/deployment_source.py:81), ikke en kontrolleret installation af en native udvidelse. Geminis native udvidelser kan samle skills og MCP, installeres som kopier og opdateres separat. 119 Den eksisterende spejlmekanisme og den native Gemini CLI-vej bør derfor behandles som to forskellige integrationsmål.

Der blev også fundet et problem med referencer efter installation. De globale kerneregler henviser relativt til skills (bmad-suite-v4/rules/bmad-core.md:38), men distributionskortlægningen placerer regelsættet og skills forskellige steder (scripts/deployment_source.py:83). Hvis stien fortolkes i forhold til filen, fører henvisningen ikke direkte til den installerede skill.

Projektstyringen bruger desuden både nye og gamle indgange. Projektets aktuelle indgang bygger på én fokuspind (specs/tasks/_active.md:10), mens den distribuerede kerneregel stadig leder efter en ældre aktiv plan (bmad-suite-v4/roo/rules/02-bmad-core.md:8). Analyse-modens redigeringsområde omfatter heller ikke de nye projektmapper (bmad-suite-v4/roo/settings/custom_modes.yaml:8).

Den ønskede grænse bør være tydelig: Global installation indeholder genbrugelig metode, skills og værtsintegration. Projektmapper indeholder kun det enkelte projekts indgang, faglige regler, beslutninger og opgaver. Kildesamlingen i scripts/deployment_source.py:64 sender ikke hele repoets projektmateriale ud, og den grænse bør bevares.

6. solo-distill-mcp: lokal, selvstændig tjeneste som udgangspunkt

Den anbefalede model er en selvstændig lokal MCP-tjeneste, som værten kan kalde. Tjenesten læser godkendte projektfiler og danner forslag til materiale, der derefter sendes gennem en godkendt dokumentindgang til projektet. Metodedistributionen bør beskrive forbindelsen og dens krav, ikke indlejre hele tjenestens kildekode i regelpakken.

Tilgængelighed skal vurderes ud fra konkrete capabilities. Den eksisterende brownfield-procedure (bmad-suite-v4/skills/bmad/references/procedures/brownfield-distill-governance.md:22) kræver blandt andet kontrol af version, værktøjsdeklaration, sprogunderstøttelse, forbrugere og evnen til at dele indhold op. Tjenestens aktuelle kildekode blev ikke gennemgået her, så der er ikke grundlag for at love, at et bestemt interface eller automatisk registrering virker.

For almindelig analyse og kodning bør MCP være en ekstra mulighed. For et initialiseringsflow, der udtrykkeligt kræver destilleringsmotoren, kan den være en nødvendig forudsætning. Hvis tjenesten mangler, bør kun de trin, der afhænger af den, sættes på pause – ikke hele metoden. Almindelig fillæsning må heller ikke fremstilles som en godkendt test af destilleringsmotoren.

Offline scanning, kontrol af kildens troværdighed og eventuel modelbaseret analyse bør være adskilte lag. Hvis modellen ikke er tilgængelig, bør strukturel evidens og ukendte forhold stadig bevares; man bør ikke love fuld semantisk destillering uden modellen. Det følger også af offline-grænsen i proceduren (brownfield-distill-governance.md:24).

GitHub med en SSH-tunnel anbefales ikke som standardarkitektur. Kildens placering og tjenestens driftssted bør behandles hver for sig. En fjerntliggende tjeneste kan være et valg, når der er et konkret behov, men så skal dataafsendelse, godkendelse, projektafgrænsning, afbrydelser og afhængighed af modeltjenester håndteres særskilt. En tunnel løser ikke i sig selv de spørgsmål.

Automatisk tilknytning kan opdeles i tre trin: registrering med godkendelse ved installation, kontrol af capabilities ved brug og binding til en bestemt tjenesteversion ved opgavestart. Det bør ikke betyde automatisk download, opstart af eksperimentel software eller bredere tilladelser.

Foreslået rækkefølge

1. Fastlæg den faktiske oprindelse for v4.3, én autoritativ versionskilde og en tydelig liste over, hvad der eventuelt skal ryddes op. Bevar materiale, der stadig har en funktion eller dokumenterer oprindelsen.
2. Ret først installationsreferencer, de nye og gamle projektindgange samt afgrænsningen af dokumenttilladelser. Udvid derefter CI med versions- og integritetskontroller for skills.
3. Tilpas Cline, Roo og Gemini hver for sig. Kontrollér for hver vært global indlæsning, projektoverstyring, tilladte og afviste handlinger, opdatering og beskyttelse af tredjepartsfiler.
4. Integrér til sidst den lokale destilleringstjeneste, og afprøv relevante forløb, når den virker, mangler, er inkompatibel, ikke har adgang til en model eller afbrydes undervejs.

Det er forslag til kommende arbejde, ikke ændringer, der allerede er gennemført. Hovedproblemet er ikke, at versionsnumrene er for strenge, men at kilde, distributionsstier, indlæsning i værterne og projektstyring endnu ikke hænger helt sammen. v4.3 bør først regnes som leveret, når de nødvendige kontroller er på plads – ikke blot når versionsmærket er ændret.

Hovedkonklusion

En enkel udgivelsesmodel med offentlige versioner som v4.3 og v4.4 virker mere passende end et tungt versionssystem. Men gennemgangen giver ikke grundlag for at kalde arbejdstræet en ren og komplet v4.3, der er klar til udrulning. Der er stadig åbne spørgsmål om versionskilden, installationen, CI-kontrollerne og flere værtsintegrationer.

Gennemgangen var skrivebeskyttet. Der blev ikke ændret i repoet, opdateret versionsnumre, slettet historik, kørt tests eller foretaget en udrulning.

Versionsnummer og oprydning

Brug gerne versioner med to led, eksempelvis v4.3 og v4.4, udadtil. Behold V4 som den interne identitet for suiten; der er ingen grund til at omdøbe hele mappestrukturen, omskrive historikken eller indføre et kompliceret versionssystem alene for at vise et versionsnummer.

README-filen angiver stadig v4.2.0 (README.md:3), mens suite-indgangen angiver V4.2 (bmad-suite-v4/skills/bmad/SKILL.md:11). Versionskortlægningen i scripts/suite_versions.py:28 genkender kun V4 og giver ikke én fælles kilde til det mindre versionsnummer. Der er heller ikke fremlagt kontrollerbare oplysninger om, hvordan det eksterne v4.3-tag svarer til det lokale commit. Et nyt mærke eller en badge er derfor ikke nok til at fastslå, at versionerne stemmer overens.

Anbefalingen er at have én autoritativ versionskilde, som dokumentation, installationsbeskeder og CI kan kontrollere. Commit-id’er og filhashes bør fortsat bruges til at fastslå oprindelse og beskytte brugerens filer, men behøver ikke blive til et ekstra versionslag.

Der findes en ældre versionscache i .versions/v4.0.0/, som kan vurderes med henblik på oprydning, når det er afklaret, om en eksisterende installation eller et link stadig bruger den. Cacheindgangen i scripts/tag-cache.py:109 afviser allerede automatisk genbrug af caches med ældre tag-navne.

Andre historiske mapper bør ikke uden videre slettes som ubrugelige caches. verification/legacy-bmad-output/ er omtalt i en eksisterende ADR (docs/adrs/ADR-20261012-bmad-solo-anti-bureaucracy-and-programmatic-guards.md:232), og _bmad-solo-source/legacy-skills/ indeholder væsentligt materiale om oprindelsen til de ældre skills. Intet blev slettet under gennemgangen.

1. Installationsscript: gode beskyttelser, men mangler i brugerflowet

Flere vigtige sikkerhedsforanstaltninger er allerede på plads og bør bevares. Installationsindgangen afviser et urent arbejdstræ (install.sh:50); udrulningsindgangen kræver en fast-forward-opdatering og overdrager arbejdet til den nye version af scriptet (bs.sh:298); og den administrerede koordinator undersøger konflikter før skrivning (scripts/deploy-managed-cli.py:104). En enklere versionsmodel kræver ikke, at disse kontroller fjernes.

Der er dog huller i installationen. install.sh:14 accepterer kun kompatibilitetsargumenter for V4 og videresender ikke valg af vært, en skrivebeskyttet forhåndskontrol eller parametre for måltilstand. Krav til afhængigheder står primært i dokumentationen (README.md:30); installationsindgangen har ikke en samlet kontrol af dem.

Kilden bør også kontrolleres tydeligere. Eksisterende installationer bruger det lokale repo som indgang, mens opdateringer benytter den fjernadresse, der er angivet i konfigurationen (bs.sh:305). De gennemgåede indgange kontrollerer ikke, om fjernadressen stadig peger på det forventede repo.

Hold ansvarsfordelingen enkel: Installationsindgangen bør hente fra en betroet kilde, kontrollere forudsætninger og sende parametre videre. Udrulningsindgangen bør håndtere værter, forhåndskontrol, opdatering, afinstallation og beskyttelse af eksisterende filer. Der er ikke behov for endnu et versionsstyringslag.

2. CI håndhæver endnu ikke versionsreglen

Den nuværende workflow-fil (.github/workflows/ci.yml:3) kører ved push til hovedgrenen og ved pull requests, men ikke ved publiceringstags. Plugin-kontrollen (.github/workflows/ci.yml:41) undersøger struktur og navne, ikke formatet på udgivelsesversioner.

Tag-kontrollen i scripts/suite_versions.py:99 ser kun efter tegn på hovedversionen. De eksisterende tests (tests/roo_distribution/test_suite_versions.py:80) tillader både versioner med tre led og tags, der ikke er versionsnumre. Det er derfor ikke dækkende at sige, at reglen om to led allerede bliver fulgt.

Som minimum bør CI kontrollere, at nye udgivelsestags følger formatet v4.tal, at tagget stemmer med den autoritative versionskilde, og at versionsangivelserne i den aktuelle dokumentation er ens. Historikken behøver ikke omskrives, og reglen behøver ikke gælde tredjepartsafhængigheder.

CI bør også kontrollere, at skill-pakkerne er komplette. Der findes en validator (bmad-suite-v4/skills/bmad/scripts/validate-solo-package.py:5), men den bliver ikke kaldt i den nuværende CI (.github/workflows/ci.yml:55). Kontrollen bør desuden undersøge referencer efter installation, ikke kun referencer inde i repoet.

3. Upstream-skills: lokale tilpasninger, ikke en live-afhængighed

De aktive indgange fører i dag til suitens egne workflows (bmad-suite-v4/skills/bmad/references/capability-map.md:3). Distributionskortlægningen samler suite-mapperne (scripts/deployment_source.py:64), men ikke den eksterne mappe med historiske skills. Der blev heller ikke fundet nogen aktiv kæde, der løbende tjekker eller opdaterer skills fra upstream.

Det betyder, at upstream-skills ikke er en direkte kørselsafhængighed for de gennemgåede lokale indgange. Til gengæld opdateres lokale workflows, der er udtrukket og omskrevet fra upstream, ikke automatisk, når kilden ændrer sig. Det er en risiko for vedligeholdelsesdrift – ikke dokumentation for, at forskellene allerede håndteres automatisk.

De historiske skills kan heller ikke bare kobles til igen og erklæres klar. Den tidligere hjælpeskill afhænger eksempelvis af konfiguration, en oversigt over mapper og et parserprogram (_bmad-solo-source/legacy-skills/bmad-help/SKILL.md:25). Den tidligere build-skill bruger et renderprogram (_bmad-solo-source/legacy-skills/bmad-build-auto/SKILL.md:6). Det er ikke nok at kopiere en enkelt instruktionsfil.

En mere robust løsning er at bevare stabile lokale indgange til analyse og engineering og kun koble godkendte upstream-skills på, når de passer til capability-mappingen. Registrér kildecommit og nødvendige ledsagefiler. Ved opdatering bør forskelle i tilføjelser, sletninger og afhængigheder kontrolleres, før den nye version tages i brug. Opgaver i gang bør ikke læse direkte fra en upstream-hovedgren, der ændrer sig løbende.

Det er også værd at skelne mellem at opdage en opdatering og automatisk at skifte til den. En kontrol ved installation eller opdatering – eventuelt suppleret med en periodisk påmindelse – er en lettere løsning end en baggrundsproces, der hele tiden overvåger upstream.

4. Cline: CLI og plugin findes, men repoet er ikke tilpasset færdigt

Cline tilbyder både en CLI og IDE-plugins. Dokumentationen skelner mellem global konfiguration, der gælder på tværs af applikationer, og projektkonfiguration for det aktuelle workspace. 41

Repoet indeholder indtil videre kun en tynd routingskabelon, som ikke er aktiveret (bmad-suite-v4/cline/templates/bmad-router.md:3). En test af distributionen (tests/roo_distribution/test_host_adaptation.py:85) kræver, at skabelonen forbliver i et ikke-aktiveret spejl og ikke skrives til en aktiv Cline-regelindgang.

En anbefalet retning er at genbruge det samme metodiske indhold, men generere en tynd, tilpasset integration til henholdsvis CLI og plugin. Analyse- og engineering-roller kan mappes til Clines indbyggede Plan/Act-funktioner. Brugerne bør ikke være nødt til at huske særlige skill-kommandoer, og Roo-tilstandskonfiguration bør ikke importeres direkte.

Skabelonens metode-sti fortolkes relativt til repoets rod (bmad-suite-v4/cline/templates/bmad-router.md:8). Ved installation i et andet projekt skal placeringen af ressourcer derfor beregnes på ny; man kan ikke kopiere stien uændret og regne med, at linket stadig virker.

5. Roo og Gemini: filer på disk er ikke det samme som en fuld integration

For Roo indeholder distributionskortlægningen globale regler og udvalgte modes (scripts/deployment_source.py:86). Men at filerne findes på disk beviser ikke, at værten har indlæst dem. Derudover angiver ingen af de to custom modes tilladelser til MCP (bmad-suite-v4/roo/settings/custom_modes.yaml:5), mens validatoren fastlåser tilladelsesgrupperne (scripts/validate-roo-contracts.py:158). En integration med et destilleringsværktøj kræver derfor, at både konfiguration og validator gennemgås – ikke kun prompten.

Gemini er i dag et fysisk spejl af plugin- og regelmapperne (scripts/deployment_source.py:81), ikke en kontrolleret installation af en native udvidelse. Geminis native udvidelser kan samle skills og MCP, installeres som kopier og opdateres separat. 119 Den eksisterende spejlmekanisme og den native Gemini CLI-vej bør derfor behandles som to forskellige integrationsmål.

Der blev også fundet et problem med referencer efter installation. De globale kerneregler henviser relativt til skills (bmad-suite-v4/rules/bmad-core.md:38), men distributionskortlægningen placerer regelsættet og skills forskellige steder (scripts/deployment_source.py:83). Hvis stien fortolkes i forhold til filen, fører henvisningen ikke direkte til den installerede skill.

Projektstyringen bruger desuden både nye og gamle indgange. Projektets aktuelle indgang bygger på én fokuspind (specs/tasks/_active.md:10), mens den distribuerede kerneregel stadig leder efter en ældre aktiv plan (bmad-suite-v4/roo/rules/02-bmad-core.md:8). Analyse-modens redigeringsområde omfatter heller ikke de nye projektmapper (bmad-suite-v4/roo/settings/custom_modes.yaml:8).

Den ønskede grænse bør være tydelig: Global installation indeholder genbrugelig metode, skills og værtsintegration. Projektmapper indeholder kun det enkelte projekts indgang, faglige regler, beslutninger og opgaver. Kildesamlingen i scripts/deployment_source.py:64 sender ikke hele repoets projektmateriale ud, og den grænse bør bevares.

6. solo-distill-mcp: lokal, selvstændig tjeneste som udgangspunkt

Den anbefalede model er en selvstændig lokal MCP-tjeneste, som værten kan kalde. Tjenesten læser godkendte projektfiler og danner forslag til materiale, der derefter sendes gennem en godkendt dokumentindgang til projektet. Metodedistributionen bør beskrive forbindelsen og dens krav, ikke indlejre hele tjenestens kildekode i regelpakken.

Tilgængelighed skal vurderes ud fra konkrete capabilities. Den eksisterende brownfield-procedure (bmad-suite-v4/skills/bmad/references/procedures/brownfield-distill-governance.md:22) kræver blandt andet kontrol af version, værktøjsdeklaration, sprogunderstøttelse, forbrugere og evnen til at dele indhold op. Tjenestens aktuelle kildekode blev ikke gennemgået her, så der er ikke grundlag for at love, at et bestemt interface eller automatisk registrering virker.

For almindelig analyse og kodning bør MCP være en ekstra mulighed. For et initialiseringsflow, der udtrykkeligt kræver destilleringsmotoren, kan den være en nødvendig forudsætning. Hvis tjenesten mangler, bør kun de trin, der afhænger af den, sættes på pause – ikke hele metoden. Almindelig fillæsning må heller ikke fremstilles som en godkendt test af destilleringsmotoren.

Offline scanning, kontrol af kildens troværdighed og eventuel modelbaseret analyse bør være adskilte lag. Hvis modellen ikke er tilgængelig, bør strukturel evidens og ukendte forhold stadig bevares; man bør ikke love fuld semantisk destillering uden modellen. Det følger også af offline-grænsen i proceduren (brownfield-distill-governance.md:24).

GitHub med en SSH-tunnel anbefales ikke som standardarkitektur. Kildens placering og tjenestens driftssted bør behandles hver for sig. En fjerntliggende tjeneste kan være et valg, når der er et konkret behov, men så skal dataafsendelse, godkendelse, projektafgrænsning, afbrydelser og afhængighed af modeltjenester håndteres særskilt. En tunnel løser ikke i sig selv de spørgsmål.

Automatisk tilknytning kan opdeles i tre trin: registrering med godkendelse ved installation, kontrol af capabilities ved brug og binding til en bestemt tjenesteversion ved opgavestart. Det bør ikke betyde automatisk download, opstart af eksperimentel software eller bredere tilladelser.

Foreslået rækkefølge

1. Fastlæg den faktiske oprindelse for v4.3, én autoritativ versionskilde og en tydelig liste over, hvad der eventuelt skal ryddes op. Bevar materiale, der stadig har en funktion eller dokumenterer oprindelsen.
2. Ret først installationsreferencer, de nye og gamle projektindgange samt afgrænsningen af dokumenttilladelser. Udvid derefter CI med versions- og integritetskontroller for skills.
3. Tilpas Cline, Roo og Gemini hver for sig. Kontrollér for hver vært global indlæsning, projektoverstyring, tilladte og afviste handlinger, opdatering og beskyttelse af tredjepartsfiler.
4. Integrér til sidst den lokale destilleringstjeneste, og afprøv relevante forløb, når den virker, mangler, er inkompatibel, ikke har adgang til en model eller afbrydes undervejs.

Det er forslag til kommende arbejde, ikke ændringer, der allerede er gennemført. Hovedproblemet er ikke, at versionsnumrene er for strenge, men at kilde, distributionsstier, indlæsning i værterne og projektstyring endnu ikke hænger helt sammen. v4.3 bør først regnes som leveret, når de nødvendige kontroller er på plads – ikke blot når versionsmærket er ændret.