Neither of the bridge's two "clear sessionId and reinitialize" paths ever
told BC the old session was actually done - they just drop the local
sessionId variable and let a fresh session get issued on the next call.
The MCP Streamable HTTP transport spec defines an explicit way to end a
session: an HTTP DELETE to the endpoint carrying the session's
Mcp-Session-Id. The bridge has never called it.
Trying this as a candidate fix for the recurring Internal_CompanyNotFound
pattern documented in bc-mcp-company-header-must-match-exact-company-name.md:
a client-side session reset (clear sessionId + reinitialize) does NOT clear
the error, but a manual save on the BC-side MCP Server Configuration record
does. If BC's server-side session state is what's actually stuck, an
explicit close might do the same job the manual config-save has been doing
by accident.
Committed before live-testing (not after) specifically so it survives the
next sync-bcquality-knowledge.ps1 run instead of being silently overwritten
from the old source - this is a durability commit, not a confirmed-fix
commit. Best-effort and silent on failure: if BC responds 404/405 (DELETE
not implemented), that's evidence for the MS support escalation, not a bug
here. Update this commit's status (confirmed working / confirmed no effect
/ reverted) once tested against a live recurrence.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
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>
Two fixes bundled together, both diagnosed from a live BC MCP failure in
a Jernpladsen (Project Management 365) session:
- 2026-08-05 (previously drafted, never committed): BC rejects a
non-initialize request with a stale/absent Mcp-Session-Id with "A new
session can only be created by an initialize request." The prior retry
just cleared sessionId and resent the same message with no header,
reproducing the identical error. Now replays the client's cached
initialize message first to obtain a fresh session, then retries.
This also fixes dispatchCreateComment's per-chunk fresh-session reset,
which was hitting exactly this failure on every chunk of a >250-char
Task Comment.
- 2026-08-07: the reactive fix above only self-heals after BC has
already rejected a request. A client that opens a fresh session per
call (e.g. a Power Automate flow) never hits staleness at all, which
is why that pattern reads as more reliable than our long-lived
interactive bridge process. Added a proactive refresh: if the cached
session has been idle past a heuristic threshold, re-initialize
before attempting the call instead of waiting for the rejection.
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.
Neither fetch() call had a timeout, and the BC session (Mcp-Session-Id)
plus the underlying HTTP connection were reused for the bridge process's
entire lifetime with no proactive refresh. A long-running Claude Code
session with gaps between calls can leave either stale.
Observed today: a 30-minute hang on one call (no timeout meant it never
failed on its own), and separately an "Internal_CompanyNotFound" on two
machines that likely wasn't a real company problem but a dead session --
Michael noticed the pattern independently: Summatim's frequent quick calls
never have this issue, longer sessions with gaps do.
Added REQUEST_TIMEOUT_MS (30s) via AbortSignal.timeout on both fetch
calls, and wrapped forward() to retry once with sessionId cleared on any
failure -- self-heals a stale session/connection without the developer
noticing. Tested end to end: full initialize + tools/call succeeds
normally (no retry needed), and a forced-failure path correctly retries
once then surfaces the real error if it persists.
Type B gap (Francis): bc-mcp-bridge.js is a Node.js script and the
businesscentral MCP registration launches it via 'node ...', but nothing
in the setup checklist ever verified Node was actually installed. Found
missing on a fresh machine during a full developer onboarding today --
the bridge deployed fine, the MCP server registered fine, and then every
connection attempt would have failed with a generic timeout instead of a
clear "Node missing" message.
Checked first: this is genuinely uncovered, not a documentation-clarity
issue -- ~/.bc-mcp.config.json's path is already stated unambiguously
everywhere it's referenced, so no rule needed there. This is a different,
real gap: no prerequisite check existed at all.
Observed live: a consultant hit "no" reflexively on a setup confirmation
while moving fast through onboarding, and only noticed afterward. Most
of this document's ja/nej gates aren't real choices -- the standard is
company policy, not a per-developer preference -- and a blocking
question with only one sane answer just invites that kind of misclick.
v24 -> v25. Converted to act-and-report (no question) wherever the file
is git-tracked and the replacement is already verified correct: the
v6-era repo-mirror cleanup, CLAUDE.md's obsolete-forms replacement, and
the v24 migration's repo-local agent-file / find-altool.ps1 removal --
all fully recoverable via git revert if anyone ever wants the old
version back. Converted the two genuine multi-developer-coordination
steps (.mcp.json, .claude/settings.json -- whether every developer has
migrated their own machine is a fact only a human knows) from a
blocking question to a safe default (leave in place, report, offer
removal later once a developer explicitly confirms).
Left three gates as real questions, on purpose: uncommitted local
changes on CLAUDE.md (actual risk of lost work), the developer's
personal ~/.claude/CLAUDE.md (not git-tracked, carries personal
customization), and the two "should I commit this?" prompts (commit
timing is a legitimate choice, not a policy with one right answer).
Two related fixes, discovered together while debugging Wareco's duplicated
"Project" scope MCP entries:
1. New custom/setup/machine/settings.json template + a merge-safe deploy
step in sync-bcquality-knowledge.ps1 (section 10): auto-approves the
read-only/already-protocol-gated tool calls across the three
CURABIS-managed MCP servers (businesscentral's 15 static tools, al's
11 dev-loop tools, microsoft-learn's 3 docs tools) via
~/.claude/settings.json's permissions.allow -- merged into whatever
already exists, never overwritten, since that file also carries a
developer's personal settings. Tested against a real 298-entry
settings.json: preserved every existing key/array untouched, added
only the 14 genuinely-missing entries.
Found and fixed two real bugs while building this: -AsHashtable
doesn't exist in Windows PowerShell 5.1 (this script also runs via
`powershell`, not just `pwsh`) -- switched to PSCustomObject +
Add-Member. And Set-Content -Encoding utf8 writes a BOM in PS5.1 with
no utf8NoBOM option -- switched to [System.IO.File]::WriteAllText
with an explicit no-BOM UTF8Encoding, since the original file had no
BOM and a JSON parser choking on one would have silently broken every
developer's settings.json.
2. Wareco's committed .claude/settings.json still has the pre-migration
Dynamic Tool Mode tool names (bc_actions_search/describe) and an
enabledMcpjsonServers entry for al/businesscentral -- the latter is
why the MCP servers panel shows them duplicated under "Project" scope
next to the correct "User" scope registration. Added detection +
confirmed-removal migration step (mirroring the existing .mcp.json
migration's multi-developer coordination caveat) and Roemer station
16 to catch this on other pre-migration repos (gtt-marine likely has
the same file).
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.
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.
Type B gap (Francis): bc-mcp-bridge.js is a Node.js script and the
businesscentral MCP registration launches it via 'node ...', but nothing
in the setup checklist ever verified Node was actually installed. Found
missing on a fresh machine during a full developer onboarding today --
the bridge deployed fine, the MCP server registered fine, and then every
connection attempt would have failed with a generic timeout instead of a
clear "Node missing" message.
Checked first: this is genuinely uncovered, not a documentation-clarity
issue -- ~/.bc-mcp.config.json's path is already stated unambiguously
everywhere it's referenced, so no rule needed there. This is a different,
real gap: no prerequisite check existed at all.
"If asked directly about Smiley... by name" required a user to guess the
right codename to get an honest answer about whether something shapes
the session's behavior -- a concealment regardless of good intent, and
the same "keyed to phrasing instead of the actual thing being asked" bug
already fixed elsewhere in this standard (Columbo/al-complexity split,
Smiley's TDD gate), just applied to disclosure instead of activation.
Raised independently by a Claude session during Linh's onboarding, which
declined to treat "never explain the mechanism" as covering a good-faith
general question. Fixed the wording to match: stay quiet unprompted, but
answer honestly if asked in general terms, name or no name.
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.
Prompted by comparing Jeremy Vyska's "Victor Versioning" persona
(bc-code-intelligence-mcp) against what Microsoft already publishes.
Verified: Victor's ~32k "obsoletions" are a pre-indexed repackaging of
Microsoft's own Obsolete attributes in BCApps, plus BREAKINGCHANGES.md
and the deprecated-features-w1/deprecated-features-platform Learn pages
-- no new information, just faster retrieval.
We already have the same sources (BCApps reference clone, Microsoft
Learn MCP). Rather than add a new persona, sharpened al-triage: an
obsolete/deprecated diagnostic or a post-version-bump symptom now checks
BREAKINGCHANGES.md and the version-specific Learn pages first, instead
of reasoning from source alone.
al-complexity.agent.md's HIGH route says the Ergasterion convenes
automatically, but Smiley's own compressed chain diagram is what actually
drives session behavior, and it never mentioned the branch. Same class of
gap as the Columbo/al-complexity split fix (2026-07-31): a step that only
exists in a file Smiley doesn't quote from is a step that silently never
runs. Added the HIGH-tier branch to the chain and clarified Ergasterion is
NOT on-demand-only like the Court -- it auto-activates as the HIGH route's
architecture sign-off.
Pre-implementation architecture inspection for one proposed design at a
time, distinct from the Court's rulebook-level governance (which already
carries its own "Academy" self-identity in court.agent.md) and from
al-review's post-hoc diff review. Wired into al-complexity's HIGH-tier
route as the actual human architecture sign-off.
- Hickey: what does this model, and what's complected?
- Fowler: does this pay for itself, or borrow against the next change?
- Parnas: is what's likely to change hidden behind a stable interface?
(proactive counterpart to Titus Winters' Hyrum's Law check in al-review)
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>
