Merge pull request #35 from Curabis/fix/bc-mcp-restart-theory-falsified

[BCQuality] Retract restart theory, confirm MS-support escalation for BC MCP company error

custom/knowledge/mcp/bc-mcp-company-header-must-match-exact-company-name.md

@@ -62,25 +62,37 @@ The `Internal_CompanyNotFound` symptom recurred on 2026-08-03 on two
 independent developer machines, both with `company` already set to the
 correct `Navn` value (`"Curabis ApS"`) per this rule. The header-mismatch
 cause above was confirmed absent both times — yet the error still occurred,
-intermittently, within the same working day. Restarting Claude Code (which
+intermittently, within the same working day.
-respawns the `bc-mcp-bridge.js` process and re-establishes the MCP session)
-was observed to restore working state, though this has not been root-caused.
 
-This means a correct `Navn`-matching header is **necessary but not proven
+This means a correct `Navn`-matching header is **necessary but not
-sufficient**: the same-looking error can have a second, distinct cause tied
+sufficient**: the same-looking error can have a second cause unrelated to
-to the long-running bridge/session rather than a static config value. A
+the header value. When this happens, the header-match check (Verification,
-developer who has already verified the header matches `Navn` character for
+above) has nothing left to find — do not keep re-checking that same field.
-character should not keep re-checking that same field. Next steps, in order:
 
-1. Restart Claude Code once and retry.
+**Ruled out on 2026-08-03, with evidence — do not re-investigate these:**
-2. If it recurs, check BC-side state that a config file can't reveal: the
+- **Stale client process.** A theory that a long-running `bc-mcp-bridge.js`
-   Entra app registration's (`BC_DevelopmentMCP`) company-permission
+  process was running pre-fix code from before its 2026-08-01 update, and
-   assignment, and whether the relevant MCP Server Configuration
+  that restarting Claude Code would pick up the fix. **Falsified same day:**
-   (`Model Context Protocol (MCP) Server Configurations`, BC page 8351) is
+  a full machine reboot (strictly stronger than a Claude Code restart — kills
-   still Active.
+  every process, clears all in-memory state, re-establishes every network
-3. If it recurs across restarts and BC-side checks pass, treat it as a
+  connection) left the exact same error unchanged immediately after. An
-   SaaS-side incident and escalate to Microsoft support rather than
+  earlier apparent "it works after a restart" observation was very likely
-   re-diagnosing the client config a third time.
+  coincidental with an intermittent server-side state, not causal.
+- **MCP Server Configuration misconfigured.** Verified via BC UI screenshot:
+  `CURABIS_DEV` configuration is `Aktiv` (Active) = on, `Standard` (Default)
+  = on, with the expected tool set and permissions present.
+- **Company record wrong or `Navn` mismatched.** Verified via BC UI
+  screenshot of the company list: `Navn` = `Curabis ApS` exactly (matches
+  config character-for-character), `Vist navn` = `CURABIS ApS` (confirming
+  why the original 2026-07-31 mix-up was easy to make), setup status
+  `Completed`.
 
-Root cause of the session/restart-correlated failure mode is still open —
+**Conclusion:** with the header confirmed correct, the MCP configuration
-this section records the observed correlation, not a confirmed mechanism.
+confirmed active/default, and the company record confirmed correct — all
+via direct BC UI inspection, not inference — and the error still recurring
+intermittently, immune even to a full machine reboot, this is not a client-
+fixable condition. Escalate to Microsoft support with the evidence bundle
+(exact error text, `~/.bc-mcp.config.json` values, both BC UI screenshots,
+and timestamps of both failing and working calls) rather than continuing
+local troubleshooting. Root cause of the intermittent failure itself remains
+unconfirmed — likely a BC/SaaS-side condition outside CURABIS's visibility.