PR #9's fix was wrong: 'workflows' is not a real GitHub Actions permission
scope (verified list: actions, contents, issues, pull-requests, etc. - no
'workflows'). Merging it broke workflow_dispatch outright:
Invalid Argument - failed to parse workflow: (Line: 21, Col: 3):
Unexpected value 'workflows'
GITHUB_TOKEN can never push .github/workflows/* changes - that's a hard
GitHub restriction, not something the permissions: block controls. The
correct fix is to never let the sync branch carry workflow-file changes in
the first place: after a clean merge, restore .github/workflows from
origin/main and amend. This also closes a latent risk - a clean upstream
merge could otherwise silently overwrite QualityHub's own CI files
(including this one) with whatever microsoft/BCQuality ships under the same
paths.
Confirmed via both REST API and gh CLI: promote-stable.yml has been on main
since 2026-07-03 but GitHub Actions never listed it as a dispatchable
workflow (404 on both). File content is valid, no encoding issues - a known
GitHub indexing gap. A no-op touch to the file forces re-discovery.
INDEX.md keyword matching against the task's own wording misses the two
domains where a miss is expensive: breaking changes (costly for both
customer apps and CURABIS AppSource apps) and Microsoft's core AI-code
anti-patterns (unbounded FindSet, missing SetLoadFields, explicit Commit()
inside a transaction). Requests rarely say "breaking" or "performance" even
when they trigger one. Added an explicit, object-type-triggered gate to the
bcquality.agent.md template so it rolls out to every CURABIS project via the
setup agent, plus applied it directly to Summatim's own copy.
The last two scheduled runs (2026-07-13, 2026-07-20) failed silently: merge
was clean and validators green, but the push of the sync branch was rejected
by GitHub because upstream commits touch .github/workflows/*.yml and the
default token lacked the workflows scope. No issue was opened for this
failure mode, so the drift (now 3+ weeks / 31 commits) went unnoticed.
Immanuel's GitHub PR workflow and Francis's field-routing section both
pointed the "full pipeline" (Michael's machine) at Curabis/BCQuality for
branch/PR/knowledge-file operations. That repo is a public fork of
microsoft/BCQuality kept clean for upstream tracking, not CURABIS's rule
repo — Curabis/QualityHub (private) is. Step 5's report line already
said QualityHub; steps 1-4 and the verification step never matched it.
Consequence: a session followed the doc literally and opened a branch +
PR against the public fork, naming two CURABIS projects in the PR body,
before catching and remediating it (closed PR, deleted branch).
Added an explicit "never target Curabis/BCQuality" warning to both agent
files so this can't recur silently.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- bc-mcp.agent.md-templaten fik en manglende "preload de tre bc_actions_*
værktøjer via ToolSearch select:"-sektion, som ellers kun levede i
bc-mcp-tools-must-be-preloaded.md og derfor aldrig blev håndhævet.
- Rettet forkert antaget navnemønster (ListUpdate<entity>_PAG<id> ->
Modify_<Entity>_PAG<id>, bekræftet empirisk via bc_actions_search).
Ny regel bc-mcp-naming-convention-must-be-reverified.md kræver at
navnekonventioner altid markeres som "forvent, reverificér" fremover.
- francis.agent.md + immanuel.agent.md: hand-off fra Francis til Immanuel
er nu eksplicit automatisk. Michael er ikke et mellemstop i pipelinen -
han involveres først når PR'en er klar til merge.
Observeret 2026-07-04: en session brugte ToolSearch med keyword-søgning
i stedet for select: (fandt irrelevante værktøjer), ledte derefter efter
et ListUpdate-værktøj der ikke findes, og spurgte om lov til at fortsætte
til Immanuel midt i pipelinen.
Roemers station 8 (agent-synlighed, reglen claude-md-must-reference-
all-agents) flagede korrekt lincoln/aurelius/munger/algo-settings paa
hvert repo - fordi den GENEREREDE CLAUDE.md manglede dem. Symptomet var
loyalt; kilden var templaten.
- De tre dommere tilfoejet som under-punkter til court-entryen (relation
bevaret: de ER Rettens dommere, ikke loesrevne agenter)
- algo-settings tilfoejet som egen on-demand-linje
Dermed genererer Mode A en komplet CLAUDE.md, og Roemer stopper med at
stille det samme spoergsmaal paa hvert repo. Rod-aarsag lukket i stedet
for symptom-besvaret pr. repo.
Michaels instinkt (Florence som upstream-vagt) realiseret efter ugens
staffing-lektion: opdagelse er mekanik, doemmekraft er menneske. En
cron ER et heartbeat - Florence gaar runden hver mandag 05:00 (eller
paa workflow_dispatch: Florence, gaa din runde) og taender lampen:
- Nye upstream-commits + rent merge + begge validatorer groenne over
det mergede korpus -> faerdigvalideret sync-PR (validatorer koerer
I workflowet, da GITHUB_TOKEN-PRs ikke trigger CI)
- Konflikt eller validator-fejl -> Issue med commit-liste og manuel
procedure
- Intet nyt -> een linje i summary, lampen forbliver slukket
(CURABIS-ROEMER-004-stil: orden faar tavshed)
Review, merge og promote forbliver Michaels. Florence lyser kun.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Rasmus-casen: en maskine der sover gennem en konsumtionsmigrering
(ferie/orlov) vaagner op med en CLAUDE.md der peger paa doede kilder -
og onboarding-scriptet roerer bevidst aldrig en eksisterende CLAUDE.md,
saa den heler ikke sig selv.
Self-heal-triggeren i projekt-CLAUDE.md-templaten udvidet: udloeser nu
ogsaa naar maskinens CLAUDE.md baerer legacy-markoerer
(raw.githubusercontent / Curabis/BCQuality). I stale-tilfaeldet
refreshes maskinens CURABIS-sektioner fra templaten i kanal-klonen -
diff vises, Identity og personlige sektioner bevares, bekraeftelse
kraeves (det er udviklerens personlige fil).
Dermed reparerer Rasmus foerste session sig selv om halvanden uge -
og enhver fremtidig sovende maskine ved naeste modelskift.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1. text-artifacts-require-explicit-utf8-handling (Type B): to
produktionshaendelser, samme sygdom - smiley double-encodet via
HTTP-streng, og en Mode B-batch der skrev mojibake i tre CLAUDE.md
fordi PS 5.1 laeser BOM-loese .ps1 som cp1252. Reglen: raa bytes
ved transfer, eksplicit UTF-8 ved write, tekst-transformation i
Python, grep for maerket foer commit.
2. log-writes-must-survive-rollback (Type B): fejl-logs skrevet i
samme transaktion forsvinder ved rollback - loggen mister praecis
de fejl den findes for. Isoleret session (StartSession -> insert +
commit) er moensteret. Evidens: Wareco IC web-service-log
2026-07-02; havde tidligere kostet en udvikler det meste af en dag.
3. Skaerpelse af setup-doc-must-not-reference-unpromoted-stable-files:
kanal-tilstand verificeres via git (ls-remote/klon), aldrig CDN;
to sande observationer kan modsige hinanden naar verden flytter
sig imellem dem - tidsstempl al kanal-evidens. Felt-verificeret
af Conzept-sessionens selvkorrektion 2026-07-03.
Foerste PR foedt direkte i QualityHub.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Michaels arkitektur: den offentlige fork bestaar - uden custom-laget -
som intake fra og bidragsvej til microsoft/BCQuality; QualityHub er
produktet og opdateres fra forken via rent git-merge (delt ancestry).
Ny vedligeholdsbevaegelse: Opdater QualityHub fra BCQuality =
fetch -> merge-PR -> CI validerer det mergede korpus -> merge ->
promote. Aldrig upstream direkte i stable.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Michaels beslutning: det private repo hedder Curabis/QualityHub.
Fordele: ingen omdoebnings-dans med den gamle fork (frisk repo, frisk
navn), og QualityHub er brandbart som CURABIS-produkt - det er ikke
laengere bare en BCQuality-fork, det er hjemstedet for hele
kvalitetsapparatet (regler + agenter + setup + governance).
Navneskel: repoet og kanal-klonen hedder QualityHub
(%USERPROFILE%\.claude\QualityHub); STANDARDEN indeni hedder fortsat
BCQuality (Microsofts tre-lags koncept, som 40+ regelfiler og alle
agenter refererer). Kun infrastruktur-referencer er skiftet:
git-URL'er og klon-stier i sync, onboarding, setup v19, maskin-
CLAUDE.md, CONSUMPTION, agent-fallbacks og Francis' felt-routing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Beslutning: BCQuality skal vaere privat. En fork af et offentligt repo
kan ikke goeres privat, saa flyttet sker via detach/nyoprettelse - men
FOERST omlaegges al konsumtion fra tokenfri raw-URLs til git-baseret
adgang, shippet mens kanalen stadig er offentlig, saa flaaden aldrig
oplever et hul. GCM er token-haandteringen: udviklerne er allerede
autentificeret.
Kernen er KANAL-KLONEN: %USERPROFILE%\.claude\BCQuality, pinned til
stable. Alt kopieres derfra (filsystem-kopi = raa bytes; ingen
CDN-cache, ingen API-limits).
- sync-bcquality-knowledge.ps1 v2: git-baseret (klon/fetch/checkout
stable, mirror bygges lokalt, skriver selv versionsmarkoeren)
- Install-CurabisMachine.ps1 v2: onboarding = git clone + script fra
klonen; foerste GCM-login ER autentificeringen
- curabis-standard.agent.md v19: SRC/BASE-tokens peger paa klonen;
fetch betyder copy; Mode B Step 0 freshener klonen; ny Mode B-
sektion opdaterer maskin-CLAUDE.md ved konsumtionsmodel-skift
(gated, Identity bevares); CLAUDE.md-templatens self-heals er
git-baserede
- machine/CLAUDE.md v2: auto-update gater paa git fetch/rev-parse
i stedet for GitHub API; setup laeses fra klonen
- Ishikawa + al-triage + Francis: fallbacks peger paa mirror/klon;
al-triages hardcodede URL-liste fjernet (samme sygdom som Ishikawa
havde). Aerlig konsekvens: Copilot mister live custom-fallback
- CONSUMPTION.md: Access model-sektion + to-linjers onboarding
- Invoke-CurabisEvidence: RawBase markeret legacy/doed
Nul raw.githubusercontent-referencer tilbage i forbrugerkritiske filer.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Efter genstart var al stadig Failed. MCP-loggen gav beviskaeden:
cwd = .apps\PrebenZ (app-mappen - one-workspace-standarden binder
sessionen dertil), og CLAUDE_PROJECT_DIR er IKKE sat for MCP-launches,
saa ${CLAUDE_PROJECT_DIR:-.} faldt tilbage til app-mappen hvor .vscode
ikke findes. Workspace-standarden og .mcp.json-antagelsen var i
konflikt.
Fix - og en forbedring af standarden:
- find-altool.ps1 v3: cwd-agnostisk anker ($PSScriptRoot), og nyt
auto-argument der selv opdager alle AL-projektmapper (app.json under
.apps/Apps/apps) og substituerer dem i launchmcpserver-kaldet
- Setup v18, 4b: al-entryen er nu BYTE-IDENTISK paa tvaers af alle
repos - -Command med walk-up fra cwd til .vscode\find-altool.ps1 +
launchmcpserver auto. Ingen {APP_FOLDER}-substitution.
- Mode B check 4: aeldre former erstattes stille med den universelle
Live-testet fra praecis den cwd der fejlede (.apps\PrebenZ): serveren
overlever. PrebenZ + JP haandrettet paa Michaels maskine.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
/mcp viste al som Failed paa to maskiner efter korrekt deployment af
find-altool.ps1. Aarsag fundet via altool --help: signaturen er
launchmcpserver <projects> - projektmapperne er PAAKRAEVEDE argumenter,
og uden dem doer serveren straks. Kun Wareco passede stierne med
(haandlavet), alle andre .mcp.json-entries og selve setup-templaten
kaldte uden. Roegtestet i Jernpladsen: med stier overlever serveren.
- Setup v17, 4b: .mcp.json-templaten inkluderer {APP_FOLDER}-stierne
med eksplicit advarsel; een linje pr. app-projekt
- Mode B .mcp.json-validering, nyt check 4: manglende projektstier
mellem launchmcpserver og --transport korrigeres stille (een sti pr.
app-projekt) + genstartspaamindelse
- find-altool.ps1-templatens eksempel rettet tilsvarende
JP + PrebenZ .mcp.json er rettet direkte paa Michaels maskine;
Conzept faar rettelsen via Mode B efter promote.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Merge til main er kvalitetsgaten; promote er udrulningsgaten - og
udrulningsgaten skal ikke kraeve en git-klon og fire kommandoer, isaer
ikke fra en strandkant. Actions -> Promote to stable -> Run workflow:
- Naegter at koere hvis stable er divergeret fra main (aldrig force;
divergens er en finding)
- Idempotent: intet at promovere = pæn besked, ingen fejl
- Skriver job-summary med de udrullede commits
- Kun write-adgang kan dispatche; ved kommende stable-ruleset skal
GitHub Actions paa bypass-listen
CONSUMPTION.md: de tre ligevaerdige promote-former dokumenteret
(knappen, een-linjeren, den eksplicitte form).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Foerste felt-session med gh installeret foreslog en PR der ville have
committet direkte mod stable - den spurgte foerst (godt), men
beslutningen skal ikke improviseres. Routing nu eksplicit:
- Michaels maskine: fuld pipeline lokalt (branch + PR)
- Alle andre maskiner: GitHub Issue paa Curabis/BCQuality med komplet
Ferencz-format brief; universalisering og PR sker paa governance-
siden. Uden gh: brief til udvikleren, som paster som issue.
- Felt-sessioner aabner ALDRIG PRs mod stable (ff-only-kanal),
pusher aldrig regler direkte, falder aldrig tilbage til main ved
dokumenteret stable-404
Forudsaetter at Issues aktiveres paa repoet (Settings -> Features ->
Issues - deaktiveret som fork-default; Michaels klik).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Foerste felt-genererede regelforslag i BCQualitys historie: en session
paa en udviklermaskine (ConzeptALGo, 2026-07-03) ramte 404 paa
{BASE}/templates/find-altool.ps1 - setup v16 var merged til main, men
promoten laa efter, saa dokumentets egen stable-sti kunne ikke serveres.
Sessionen verificerede begge grene med curl, naegtede korrekt at falde
tilbage til main (kanaldisciplinen er selve pointen), og udformede
observation, evidens og filnavn selv.
Reglen: fil + reference shipper i samme PR; merge og promote er EEN
operation for reference-introducerende aendringer; forbrugere der
rammer 404 paa en dokumenteret stable-sti rapporterer gabet og omgaar
aldrig kanalen.
Rute: Francis (feltsession) -> Immanuel (denne universalisering) ->
Michael (merge). Promoten der lukkede det konkrete vindue er allerede
koert (stable @ 470524e).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Felttest paa fremmed maskine afsloerede at VS Code-kommandoen
AL: Configure MCP Server IKKE FINDES - den har staaet i setup-
dokumentationen siden v6 og er blevet gentaget ukritisk siden,
inkl. af Claude i dag. find-altool.ps1 var i virkeligheden
haandlavet i Jernpladsen/Wareco (funktionelt identiske kopier).
- custom/setup/templates/find-altool.ps1: kanonisk template med
robust versionssortering ([version]-parse i stedet for leksikalsk)
og klar fejlbesked ved manglende/for gammel AL-extension
- Setup v16: 4b deployer filen fra templaten (raa bytes) og skriver
ALTID al-entryen i .mcp.json; det betingede spor og fantom-noten
er fjernet. Mode B: ny raekke deployer filen hvis den mangler
- Install-CurabisMachine.ps1 + CONSUMPTION.md: pr.-repo-trinnet er nu
bare Opdater CURABIS Standard - AL-extensionen fra Marketplace er
eneste maskinforudsaetning
- Roemer v5, station 12: AL MCP-wiring paa runden med autoriseret
stille korrektion. Evidens: en session skrev AL-kode den ikke
kunne compile og flagede det foerst ved forespoergsel (Conzept)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Setup v15: projekt-CLAUDE.md-templatens self-heal udvidet fra kun
mirror til hele maskinen - mangler ~/.claude/CLAUDE.md eller bridgen,
koerer sessionen Install-CurabisMachine.ps1 fra stable selv
(idempotent, identitet fra git config), rapporterer de manuelle
rest-trin (personlig secret, AL: Configure MCP Server) og beder om
Claude Code-genstart. Mirror-only-staleness beholder det lette
self-heal.
CONSUMPTION.md: Auto-trigger-afsnit - een-linjes-kommandoen er
fallback, ikke procedure; foerste session i et klonet repo goer
arbejdet.
Torsten-scenariet (frisk maskine, manuel onboarding-viden paakraevet)
forsvinder dermed for alle fremtidige udviklere.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Torsten er den foerste friske udvikler paa kaeden, og maskinlaget
self-healer ikke: global CLAUDE.md, bridge og personlig BC-secret
skulle haandopsaettes uden procedure. Nu:
- custom/setup/machine/Install-CurabisMachine.ps1: idempotent
onboarding - global CLAUDE.md fra template (identitet fra git
config), bridge, config-template (personlig secret manuel),
sync-script + mirror, versionsmarkoer. Roerer ALDRIG eksisterende
CLAUDE.md eller config. Alt hentes som raa bytes fra stable.
- CONSUMPTION.md: Machine onboarding-sektion med een-linjes-kommandoen
og de to manuelle efterfoelgende trin (client secret + AL: Configure
MCP Server pr. repo).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
