openclaw - 💡(How to fix) Fix Architecture: prevent sales/logist cross-talk in the shared MAX bridge [1 comments, 1 participants]

Summary

We already have the right high-level direction:

• avito-intake should stay Avito-only
• maxlogist should own driver dialogs in MAX
• sales should own client dialogs in MAX
• the shared bridge should own Radist/MAX transport, Bitrix sync, dialog ownership, and replay/idempotency

The remaining architectural risk is not that sales and maxlogist share one bridge. A shared bridge is the correct design. The real risk is cross-talk / state mixing between the client and driver domains if the bridge does not separate identity and routing strongly enough.

Problem

Both sales and maxlogist will send and receive through the same Bitrix/Radist bridge.

That is safe only if bridge identity, routing, and idempotency are domain-safe.

If the bridge treats messages too generically, we can end up with:

• a driver dialog affecting client dialog state
• a client event being routed into driver logic
• shared dedupe/idempotency keys suppressing the wrong outbound
• dialog_mode changes on one domain pausing or resuming the other
• Bitrix links or Radist chat bindings being reused across the wrong subject type

Main risks to guard against

1. Subject identity collision

subject_id cannot be assumed unique unless it is globally namespaced.

Examples:

• driver:12345
• client:12345

If the bridge stores only a bare subject_id and both domains can produce the same value, state can collide.

2. Routing by chat without domain ownership

A raw Radist/MAX chat must resolve to one current bridge subject with an explicit domain owner.

The bridge should not deliver an inbound event to sales or maxlogist just because both know how to process MAX messages. Routing must happen after bridge subject resolution, not by package heuristics.

3. Shared idempotency / dedupe collisions

Outbound idempotency keys must be namespaced by domain and subject.

Bad shape:

• followup:123

Safer shape:

• sales:client:123:followup:2026-04-22T10
• maxlogist:driver:123:route-offer:456

Otherwise one domain may accidentally suppress valid outbound from the other.

4. dialog_mode attached to the wrong entity

dialog_mode must live on the resolved subject / operational record, not on a generic chat bucket.

If a MAX chat or Bitrix record can be rebound ambiguously, then operator takeover and AI resume become unsafe.

5. Bitrix operational-record ambiguity

For each subject there must be exactly one operator-facing authoritative Bitrix operational record for ownership edits.

• sales: Lead/Deal side
• maxlogist: Driver SPA side

Contacts can mirror metadata, but must not become a competing source of truth for dialog_mode.

Required bridge invariants

Before sales and maxlogist both rely on the same bridge, we should lock in these invariants:

1. Every bridge subject has an explicit subject_type = client | driver.
2. Subject identity is globally collision-safe.
3. Every Radist binding is attached to exactly one current subject owner.
4. Routing from bridge -> domain package is based on resolved subject ownership, not message shape.
5. Idempotency keys are domain-namespaced.
6. dialog_mode and handoff state are scoped to one resolved subject.
7. One Bitrix operational record is authoritative per subject for resume/takeover.
8. Bridge message log and replay entries remain partition-safe across domains.

Suggested implementation guardrails

• Prefer either:
  • globally namespaced subject_id values, or
  • composite uniqueness on (subject_type, subject_id) everywhere important
• Add unique constraints that prevent silent rebinding across domains
• Keep bridge send API domain-aware at the call boundary even if transport is shared
• Keep bridge tables transport/state-oriented only; no driver/client business logic inside the bridge
• Make tests cover both domains on the same bridge DB, not only one domain in isolation

Minimum cross-domain tests worth adding

1. client:123 and driver:123 can coexist without state collision
2. A driver MAX inbound cannot be routed to sales
3. A client MAX inbound cannot be routed to maxlogist
4. A sales idempotency key cannot suppress a logist outbound
5. Switching dialog_mode on a sales record does not affect a driver subject
6. Rebinding a Radist chat from one domain subject to another fails loudly unless explicitly migrated

Why this matters now

packages/sales/ already has a reasonable package-local scaffold and assumes the bridge will provide:

• subject abstraction
• dialog ownership
• send API
• webhook/state exports

So the remaining risk is not mostly inside sales anymore. It is in the shared bridge contract that both sales and maxlogist will depend on.

Scope note

This is specifically about the shared MAX/Bitrix bridge for sales and maxlogist.

avito-intake should not need Bitrix/Radist transport ownership if it stays Avito-only and only prepares handoff into MAX.