New follow-up section, distinct from the 2026-08-03 "ruled out" static
verification (Aktiv/Standard confirmed on, unchanged). This is about the
save/toggle *action* on CURABIS_DEV's MCP Server Configuration page, not
its resting state - not previously tested.
Observed 2026-08-07 (MID): Internal_CompanyNotFound recurred. VS Code
restart + retry failed (consistent with the already-falsified restart
theory). Toggling the Standard field on CURABIS_DEV and saving, then
retrying, worked immediately. MID reports having seen this same pattern -
restart-retry fails, config-touch-retry succeeds - on prior occasions.
Framed explicitly as a candidate, not a confirmed fix: n>=2 informal
observations, toggle direction untested (MID's own read is that direction
is probably irrelevant, pointing at the save/republish action busting a
server-side cache rather than at the field's value), and no baseline
established against the error's already-documented intermittency. Does
not override the Microsoft-support-escalation guidance - if anything it's
supporting evidence for that escalation, since a CURABIS-side config touch
masking a BC-side symptom points at BC's MCP session/cache layer.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Promotes rules that are already published in community/ to custom/knowledge/,
so they load at every session start instead of only on keyword relevance.
Each file carries extends: pointing back to its community source.
Passed Immanuel's four-test Categorical Imperative validation on 2026-08-07.
The 2026-08-03 follow-up's "restart Claude Code" step was falsified same
day by a full machine reboot that left Internal_CompanyNotFound unchanged.
Records the two theories ruled out with evidence (stale bridge process;
MCP config/company misconfiguration, both screenshot-verified) and states
plainly that this is a client-unfixable, likely BC/SaaS-side condition
requiring Microsoft support escalation.
Internal_CompanyNotFound recurred 2026-08-03 on two machines with the
company header already matching Navn correctly, ruling out the original
header-mismatch cause. Failure was intermittent and appeared to clear after
restarting Claude Code, suggesting a separate, still-unconfirmed session/
bridge staleness issue. Adds a follow-up section with next steps so future
sessions don't re-verify an already-correct header a third time.
Implements every confirmed finding from the workflow-based audit of
CURABIS Standard's agent model (7 finders + adversarial verification,
8 confirmed / 5 refuted):
1. Roemer/Florence phantom wiring - roemer.agent.md claimed Florence's
heartbeat "may summon me when a ward smells of drift" with nothing in
florence.agent.md or HEARTBEAT.md implementing it. Fixed by adding an
explicit "Kald Roemer" instruction to HEARTBEAT.md ward 6 (agent
visibility, his actual domain), mirroring ward 8's existing "Kald
Weber" pattern, and correcting roemer.agent.md's own claim to match.
2. m365.agent.md's "Florence's morning brief pattern" was a one-way
orphaned reference - a full 4-step pattern with nothing in
florence.agent.md implementing it. Added it to florence.agent.md as
an explicit on-demand capability, separate from the timestamp-gated
Round protocol.
3. An Ergasterion "PROCEED WITH CHANGES" ruling had no way to be checked
against the eventual diff - al-review's checklists never referenced
it. Added ERGASTERION_RULING to the [CURABIS-STATE] vocabulary,
wired Ergasterion to write it, and added a BLOCKing checklist item to
al-review's Titus checklist that verifies required changes were
actually implemented.
4. curabis-task-state-check.yml was headered "Deterministic enforcement
(not LLM diligence)" but only checks checkbox order, only blocks
anything if a human separately enabled branch protection (never
verified anywhere), and doesn't exist at all for the PTE track.
Corrected the header's claims and added Roemer station 14 to verify
branch protection is actually configured.
5. Mode C's only safeguard against a support user reaching
Curabis/QualityHub was a single manual eyeball check with no re-check
ever. Strengthened Step 2 to cover team-inherited and org-default
access paths, added an append-only support-user registry, and added
Roemer station 15 to periodically re-verify every registered user
against it.
6. Columbo's persona was presented as genuine autobiography with no
disclosure of its fictional TV origin (Levinson & Link, Peter Falk),
unlike Smiley which discloses explicitly. Added a reader-facing
editorial note - never something Columbo says aloud, since unlike
Smiley he actually performs the persona to customers.
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>
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.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.
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>
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>
Michaels praecisering af workspace-standarden: der findes praecis EET
workspace pr. repo - i apps-mappen, efter referencelayoutet (app-
projekter + .AL-Go + ../docs). Alle oevrige *.code-workspace-filer,
inkl. rodens al.code-workspace, slettes - de er forkerte indgange, og
den forkerte bliver brugt. Apps-mappens navnevariant (.apps/Apps/apps)
er kosmetik; .apps er referencen.
- Regel al-development-must-use-apps-workspace skaerpet: uniqueness-
krav; rod-workspacet overlever ikke laengere til plumbing-formaal
(aabn repo-mappen direkte til det); AL-Go template-opdateringer der
gen-scaffolder rod-workspacet fjernes igen af runden
- roemer.agent.md v4: station 9 tjekker begge retninger og har
sletnings-autorisation (rapporteres bagefter)
- curabis-standard.agent.md v14: Mode B opretter/kompletterer apps-
workspacet og sletter alle oevrige
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Michaels krav: AI skal rejse flagene, naar BCQuality implementeres paa
et repo - ikke naar nogen tilfaeldigvis spoerger. Portefoeje-inventar
2026-07-02 (29 repos): 3 flade repos blokeret for testcases, 11 uden
test-app (een CreateTestApp-koersel hver, ikke migration).
- Ny regel al-go-template-layout-with-test-app-required: template-
layout + test-app-companion er paakraevet; strukturfund er report-
only (migration er aldrig stille korrektion); setup maa fortsaette
paa non-compliant repo, men aldrig tavst
- roemer.agent.md v3: station 10 (AL-Go template-layout) og 11
(test-app pr. main app)
- curabis-standard.agent.md v13: Mode A Step 1b koerer Roemers
strukturstationer FOER konfiguration og kraever at udvikleren
anerkender flagene inden Step 2
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Michaels observation: teamet arbejder i rod-workspacet og mister dermed
udviklingskonteksten - .apps-workspacet er det, der scoper til app-
projekterne + .AL-Go, baerer projektindstillingerne og (per denne regel)
inkluderer docs/, saa Columbo-specs, decisions og cleanup-checklister er
synlige, dér hvor udviklingen sker. Jernpladsen og Wareco er allerede
compliant - reglen kodificerer den eksisterende praksis.
- Ny regel al-development-must-use-apps-workspace (referencelayout:
app-projekter + .AL-Go + ../docs; rod-workspacet er til repo-plumbing)
- roemer.agent.md v2: station 9 - apps-workspace-check; manglende
docs-entry er autoriseret stille korrektion
- curabis-standard.agent.md v12: Mode B validerer docs-entry i
.apps/*.code-workspace
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
