Michael: "lad os bygge alle 4" - rangeret efter styrke fra sidste samtale.
1. Smiley v6: close-gaten laeser nu det faktiske [CURABIS-STATE]-spor
tilbage FOER merge, i stedet for at stole paa sessionens egen hukommelse.
Mangler et tidligere checkpoint, blokerer merge - selv hvis testen er
groen og reviewet lige sagde APPROVE nu.
2. al-review v3: "state trail complete?" er nu et Titus-tjekpunkt der giver
BLOCK, ikke bare en note - et ufuldstaendigt spor er i sig selv et
vedligeholdelsesfund.
3. Ny .github/workflows/curabis-task-state-check.yml: reelt deterministisk
haandhaevelse for AppSource (parser PR-body'ens tjekliste, fejler hvis en
senere fase er tjekket mens en tidligere ikke er). Testet mod fire cases
(gyldig raekkefolge, ugyldig, ingen sektion, tom sektion) - alle korrekte.
Kraever et manuelt engangs-trin (branch protection required check) som
filudrulningen ikke selv kan saette.
4. Roemer v6: ny station 13, retrospektiv - stikprover de sidste ~10
afsluttede BC-opgaver/mergede PR'er for spor-fuldstaendighed, fanger
drift ingen enkelt opgaves egen gate fangede. Kun opgaver lukket efter
2026-08-03 flages - reglen fandtes ikke foer.
curabis-standard.agent.md: ny artefakt-raekke + Mode A step 4h (deploy
workflow-filen, mind om branch protection-trinet) + Mode B repo-tabel-raekke.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Michaels retning efter at have set community-vaerktoejets workflow_start/
workflow_next-tilstandsmaskine: han vil inspireres, ikke kopiere - vil have
persisteret, forespoergelig tilstand der overlever et maskin- OG operatoer-
skifte, uden at bygge en ny, parallel opbevaringsmekanisme.
Princippet: brug det obligatoriske spor der allerede findes for den
paagaeldende flowtype, ikke et tredje system.
- PTE: en BC-delopgave er allerede obligatorisk foer udvikling starter
(development-requires-bc-task, ingen undtagelser) - dens kommentarer
(taskComments) ER tilstandslageret. Format: [CURABIS-STATE] <STAGE> —
dato, udvikler.
- AppSource: intet obligatorisk BC-spor i dag - draft PR'en aabnes tidligt
(ved start-gaten, ikke foerst ved review) og dens beskrivelse baerer
tilstanden som en tjekliste.
Samme tilstandsordforraad begge steder: TASK_STARTED, RED_CONFIRMED,
ON_HOLD (altid med hvorfor), GREEN_CONFIRMED, REVIEW: <verdict>, MERGED.
Bevidst IKKE en kopi af community-vaerktoejets workflowSessionManager - den
har reel persisteret tilstand, men INGEN haandhaevelse noget sted (returnerer
bare en instruktion, tiltror agenten at foelge den). CURABIS's reelle styrke
er det modsatte (roed bekraeftet af udvikleren, BLOCK er et haardt stop) -
denne aendring tilfoejer persistens UDEN at rore ved haandhaevelsen.
Wired ind i:
- smiley.agent.md v5: hver gate-overgang skriver nu et tilstands-checkpoint
- bc-mcp.agent.md v3: standard workflow skriver [CURABIS-STATE]-kommentarer
- al-review.agent.md v2: verdict registreres som et checkpoint, ikke kun
som findings
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Live incident i aften: businesscentral MCP fejlede med et generisk
30-sekunders "connection timed out", ingen brugbar fejl. To reelle, adskilte
fejl fundet ved at teste direkte mod BC's endpoint:
1. ~/.bc-mcp.config.json havde "company": "CURABIS ApS" (Vist navn), men BC's
faktiske Navn-felt er "Curabis ApS". BC svarede korrekt og hurtigt (400,
under 200ms) - problemet var aldrig BC.
2. bc-mcp-bridge.js svaelgede det svar stille: en fejl-krop formateret som
almindelig JSON, men markeret content-type text/event-stream, blev sendt
til parseSSE() som kun leder efter "data:"-linjer - fandt ingen, returnerede
en tom liste. Broen skrev derfor INGENTING, hverken stdout eller stderr, og
Claude Code ventede blot sin egen 30-sekunders timeout ud.
Rettet:
- forward() tjekker nu !r.ok FOER content-type-forgrening, ubetinget - en
fejlrespons naar aldrig parseSSE, uanset hvad serveren paastaar om sin
egen content-type. Testet direkte mod det reproducerede scenarie: fejlen
vises nu med det samme (5s test-vindue, ikke 30s timeout), med det fulde
BC-fejlsvar synligt i baade stdout (JSON-RPC error) og stderr.
- bc-mcp.config.template.json matchede slet ikke broens faktiske felter
(tenantId/baseUrl vs. broens tenant/company/configurationName) - enhver ny
udvikler der udfyldte skabelonen efter dens egne feltnavne ville faa en
config der intet virkede med. Rettet til de rigtige feltnavne, plus en
eksplicit advarsel om Navn vs. Vist navn i company-feltet.
- Mode A's opsaetningsbesked (Step 3b) opdateret til at naevne alle
placeholder-felter, ikke kun secret'en.
- To nye BCQuality-videnfiler dokumenterer begge fejl til fremtidig
fejlsoegning.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Fjerde gate i Task Lifecycle - koert efter groent test, foer merge, adskilt
fra den der implementerede aendringen og fra Roemer/Immanuel/Court's
portefoelje-niveau-styring (de spoerger "er selve regelsaettet sundt", ikke
"er DENNE aendring god").
To linser, Michaels egen opdeling:
- Linus Torvalds: BC/AL-domaene-teknisk (respekterer standard-BC/events,
bogfoerings-sideeffekter, opgraderings-holdbarhed, filtre/keys/SetLoadFields,
locking/SQL-performance, permissions/dataklassifikation, forretningslogik
paa forkert sted, testdaekning af forretningsforloeb, lokalt rigtig men
arkitektonisk forkert)
- Titus Winters: generel software-engineering (korrekthed, forstaaelighed,
arkitektonisk sammenhaeng, testbarhed, cyklomatisk/McCabe-kompleksitet -
ingen anden i rosteret vurderer det tal - Hyrum's Law, kodebase-konsistens,
boer det overhovedet bygges saadan)
Wired ind i Smileys Close gate (samme udfaldsbaserede disciplin som resten
af dagens rettelser) - ikke noget udvikleren skal huske at bede om. Verdict
er APPROVE / APPROVE WITH NOTES / BLOCK, aldrig en fjerde "det er kompliceret".
Roster-taeller opdateret alle steder: 22 agent-filer i alt (20 maskin-globale,
2 repo-lokale), 19 filer i ~/.claude/curabis-agents/. sync-bcquality-
knowledge.ps1 testet - al-review.agent.md bekraeftet leveret.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Michaels retning: loes tingene saa standard som muligt foerst (Microsoft
Learn + det faktiske BCApps-indhold), derefter KISS paa hvad der reelt skal
bygges custom.
Ny Step 0 i al-complexity.agent.md, koert FOER klassificering:
- Soeg Microsoft Learn efter forretningsbehovet (ikke "hvordan bygger jeg X i AL")
- Tjek den rigtige BCApps-kildekode via reference-repos-klonen (ikke traenings-
data-antagelser)
- Krav om bevis, ikke en paastand ("jeg tjekkede og fandt intet" er kun
troværdigt hvis du viser hvad du soegte) - samme standard som TDD-rød-
bekraeftelsen
- Ny STANDARD-tier: hvis BC allerede klarer det, ingen kode, kun opsaetning
- KISS goeres til en eksplicit begraensning paa selve routen, ikke kun paa
Step 0 - en HIGH-tier retfaerdiggoer mere PROCES, ikke en mere elaboreret
LOESNING
Smiley v3 (samme commit-serie): rettede ogsaa en snag i selve aktiveringen -
Columbo->al-complexity-kaeden trigges i dag kun naar kravet er UKLART. Men
standard-foerst-tjekket boer koere for ETHVERT nyt custom-arbejde, ogsaa et
krystalklart formuleret et - et klart krav kan stadig vaere noget BC allerede
goer. Samme klasse gap som TDD-triggerfixen i forrige commit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Opdaget i praksis 2026-07-31: en afslappet "det vil jeg gerne have de ting
fikset" (efter en QA/challenge-session, ikke en "lad os starte en opgave"-
formulering) udloeste ikke Task Lifecycle-stopgaten automatisk - den koerte
kun roed/groen fordi et menneske eksplicit skrev "roed/groen-gate" ind i den
efterfoelgende prompt. Det skal ikke vaere paakraevet.
En ordliste kan ikke loese det - der findes uendeligt mange maader at bede om
en rettelse paa. Erstattet med en udfalds-baseret betingelse: gaten aktiveres
naar Claude er ved at skrive/aendre AL-kode der aendrer adfaerd, uanset
brugerens ordvalg. Kalibrerings-eksempler ("fiks det", "kan du ordne det",
et bart "ja, goer det") er illustrationer af raekkevidden, ikke en udtoemmende
liste at matche imod.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
To ting fra QualityHub-sporet:
1. Udviklere faar nu samme Microsoft Learn MCP som Mode C-supportbrugere
allerede havde (https://learn.microsoft.com/api/mcp, HTTP, ingen auth) -
registreret maskin-globalt via sync-bcquality-knowledge.ps1, samme
moenster som al/businesscentral. Lukker hullet hvor udviklere kun havde
den statiske microsoft/-videnfil-snapshot og ingen live dokumentationssoegning.
2. add_repo-mekanismen i curabis-app-sources-must-be-checked-first.md var
kun naevnt, aldrig defineret - intet vaerktoej med det navn findes i
Claude Code CLI. Erstattet med en konkret, testet mekanisme: en
vedvarende, opdateret klon i ~/.claude/reference-repos/<org>/<repo>/,
samme moenster som BCQualitys egen kanal-klon. Testet live mod det
faktiske microsoft/BCApps-repo (shallow clone ~52s, ~36.000 .al-filer,
git pull --depth 1 til opdatering).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
BC MCP-serveren (CURABIS_DEV) er skiftet fra Dynamic til Static Tool Mode -
de generiske bc_actions_search/describe/invoke findes ikke laengere, hver
BC-handling er nu sit eget navngivne, typede MCP-vaerktoej (bekraeftet live
efter et reconnect). Det fjerner navnedrift-risikoen dokumentet selv
tidligere advarede om (consultants/users-forvekslingen).
Samtidig:
- taskResponsible tilfoejet som skrivbar paa activeTasks (matcher AL-rettelsen
i CURMCPActiveTasks.Page.al/CURSubTask.Table.al - opgaveansvarlig kan nu
omfordeles mellem konsulenter via MCP)
- De to hidtil udokumenterede entiteter projectAIScores/projectWeberScores
tilfoejet med korrekt insert-only-regel og ejerskab (Edison hhv. Weber)
- Alle workflow-referencer opdateret til at kalde vaerktoejerne direkte
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
19 af 21 agent-filer, de to standard MCP-servere (al, businesscentral) og
find-altool.ps1 var byte-identiske kopier duplikeret ind i hvert af de 14
CURABIS-repos. De flyttes til ~/.claude/ (én kopi pr. maskine i stedet for
pr. repo), gated paa den eksisterende .github/.agents/bcquality.agent.md-
markoer. Kun bcquality.agent.md og feynman.agent.md forbliver repo-lokale
(Mode C support-brugere har intet ~/.claude/ at laese globalt indhold fra),
og CLAUDE.md's machine-self-heal-blok forbliver repo-lokal (den installerer
selve den globale fil, kan ikke ligge i den).
find-altool.ps1 finder nu repo-roden ved cwd-walkup til en .AL-Go-markoer
i stedet for sin egen placering, og MCP-registrering sker idempotent via
`claude mcp add --scope user`. Mode B faar en engangs-migreringssektion for
de 14 eksisterende v23-repos; .mcp.json-oprydningen kraever eksplicit
bekraeftelse af at alle udviklere paa repoet har migreret foerst, da filen
er delt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- custom/agents/feynman.agent.md: ny support-navigator for ikke-udviklere.
Strengt læsende, svar med kildehenvisning (kildetrappen: docs/specs ->
projectmemory -> decisions -> kode -> Microsoft via MCP), Feynman-testen
på alle svar, struktureret eskalering via Feynman-notatet (Columbo/
al-triage-klar). Aktiveres med trigger-frasen 'Feynman:'.
- curabis-standard.agent.md v23: Feynman i artefakt-tabel, Mode A 4c,
Mode B-tabel og CLAUDE.md-templaten (support-sektion der slår self-heal,
AL MCP og BC MCP fra i support-sessioner + on-demand-entry). Ny MODE C:
'Onboard en supportbruger til CURABIS Standard' — browser-only (claude.ai/
Claude Code på web, ingen VS Code), GitHub read-only, GitHub MCP +
Microsoft Learn MCP, ingen secrets, ingen QualityHub-adgang.
- templates/feynman-onboarding.md: dansk onboarding-dokument til
supportbrugeren ({SUPPORT_NAME}/{REPO_LIST}/{SETUP_DATE}-tokens).
- machine/CLAUDE.md: tredje trigger-kommando tilføjet.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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>
