transform_mode: "rust" silently bypasses host-side paths — no declaration, no warning, no way to detect it from the outside

[iceteaSA]

Summary

Flipping transform_mode to "rust" re-routes ctx_memory/ctx_note to the module and moves historian orchestration module-side. Any host-side behaviour attached to those TypeScript paths stops running — silently. There is no startup declaration of what moved, no warning, and nothing in /ctx-status that distinguishes "this host path is inactive because you are in rust mode" from "this host path ran normally".

The flag reads like a performance/implementation switch. It is also a behavioural surface switch, and that part is undocumented.

Concrete instance (verified)

Downstream we tee memory creations to an external store. Three call sites in ctx-memory/tools.ts plus one in memory/promotion.ts:119:

tools.ts:616 / 668 / 792   →  void teeToExternalBackend("agent", [...])
promotion.ts:119           →  void teeToExternalBackend("historian", teedItems)

In rust mode:

• rust-tool-backends.ts routes ctx_memory to the module once memories authority reports MODULE — the three tool-path tees never execute;
• the historian runs module-side (crates/mc-module/src/historian.rs) — the promotion tee never executes;
• crates/mc-module/src/memory_tool.rs contains 0 references to any external/tee concept, which is correct for upstream but means nothing replaces it.

Net effect: the feature goes quiet and keeps reporting healthy. Only a dreamer-task tee survives, because that path is still host-side.

This specific tee is a fork feature and not upstream's problem. The mechanism — host-side work silently dropped when authority moves — is upstream's, and it is not specific to our tee.

A second instance worth a maintainer's eye

I could not resolve this one and am flagging it rather than asserting it.

Upstream's own post-commit embedding step is host-side:

// memory/promotion.ts:95
export async function embedPromotedFacts(db, sessionId, projectPath, refs, options?) {
    for (const ref of refs) {
        await embedAndStoreMemory(db, sessionId, projectPath, ref.memoryId, ref.content);

The module does promote facts (promote_facts: bool, to_store_fact in historian.rs) but has no embed references in its historian, and structurally cannot call a remote embedder: a resolved cargo tree --workspace over the Rust workspace (239 nodes) contains no HTTP or TLS crate at all — no reqwest/hyper/ureq/isahc/surf/curl/native-tls/openssl/rustls/h2. Only socket2, for the loopback daemon connection.

So in rust mode, either (a) the host still embeds via a callback I did not find, (b) promoted facts land unembedded and wait for /ctx-embed or a dreamer backfill, or (c) it routes through the synapse lane over subc. If it is (b), memories promoted under rust mode are non-recallable by vector search until something backfills them — which would be worth documenting even though it self-heals.

What would fix the class, not the instance

Something that makes the bypass visible, rather than each downstream discovering it by reading rust-tool-backends.ts:

1. Declare it. On authority transition to MODULE, log the host-side paths going inactive — tool backends re-routed, historian orchestration moved. One line at transition, not per-pass.
2. Surface it in /ctx-status. The status output already reports rust-mode module state; adding "host tool backends: ctx_memory, ctx_note → MODULE" makes the switch legible without source reading.
3. Optionally, a registration seam. If a host extension attaches to a path that rust mode replaces, let it register that fact so the transition can warn rather than silently drop it. This is the "fail loud" version; (1) and (2) are the cheap versions and probably sufficient.

I would not propose blocking the flip — the bypass is intentional and correct. The gap is that it is unannounced.

Why this is worth fixing rather than documenting

The failure is invisible in exactly the way that matters: the feature does not error, the module reports healthy, and /ctx-status looks normal. A downstream (or a future upstream feature attached to a host path) discovers it only by noticing an absence — which is the hardest thing to notice. I found it by reading rust-tool-backends.ts while deciding whether to flip a long-lived session, not by observing a symptom.

Environment

Found on a fork carrying two host-side features across the boundary, checking flip-readiness after #376/#378/#379/#381 landed. TS and Rust generations matched (ck-mc rebuilt at current tip, 1160 tests). Not blocking anything on my side — I deferred the flip partly because of this.

[magic-alfonso]

Thanks @iceteaSA — your class analysis was right: Rust authority is a behavioral routing switch for host paths, not merely an implementation/performance switch. We added two visibility surfaces without changing the authority fence. On every settled MODULE transition the host logs one declaration such as authority → MODULE: host backends → MODULE: ctx_memory, ctx_note; historian: module-side; a completed drain logs the matching return to TypeScript. A fresh host that discovers an already-MODULE project also declares it once, while ordinary later passes stay quiet. /ctx-status now shows Host backends → MODULE: ctx_memory, ctx_note; historian: module-side in Rust mode in the OpenCode dialog and chat fallback, and omits it in TypeScript mode.

Your unresolved promoted-fact embedding instance was also real: before August 28, Rust-mode promotions left facts unembedded until a later backfill — option (b). Parity hunt #6 has now landed the mirrored-memory embedding trigger on master: the mirror-back hook embeds promoted facts synchronously with the mirror write and will ride the next release. Your no-HTTP-crate structural bound was the right proof that the old module historian could not have performed remote embedding itself.

We are declining arm 3 for now. context_authority is readable from the host, so a fork can already observe these transitions without a new registration API. A registration seam is heavier than this upstream class needs today; we should revisit it if a second consumer appears.

The external-store tee itself remains fork scope, but the durable attachment point is the mirror-back hook. Memories mirror to context.db regardless of authority, so a tee attached to that mirror path sees both TypeScript and MODULE writes. That is the migration path we recommend rather than attaching to the replaced tool or historian paths.

Merged on master; both visibility surfaces and the hunt-6 embedding fix ride the next release.