PR #36 (merge dd4dc4e) merged 'stable' into the fix branch before merging
back, and that intermediate merge silently resolved the conflict in favor
of stable's older content instead of the fix branch's. Result: 8e85976's
retraction (drop the falsified "restart Claude Code" theory, confirm
MS-support escalation) is reachable in history but never actually landed
in stable's tree - the blob at 3142ce8 was byte-identical to 73e5a01
(pre-fix). Discovered live while troubleshooting a real Internal_CompanyNotFound
recurrence on 2026-08-07: the mirrored knowledge file still told the
developer to restart Claude Code, the exact theory 8e85976 falsified.
Restores the file to 8e85976's blob content directly - no merge needed,
just the correct final state.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.
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>
