Run Composio normalisation and storage on a driver that is not TinyCortex (#18 §B3)

[YellowSnnowmann]

Stacked on #40. Once that merges this reduces to one commit.

Summary

#40 extracted the Composio normalisers into an engine-neutral crate. This asserts that the result is actually reachable without an engine, which is the only thing that makes the extraction worth anything.

A raw Composio Gmail payload goes through tinymemory_sync::gmail_post_process, and each normalised message is stored into a bound provider. The test file's entire dependency list is the facade, the conformance reference driver, and the sync crate — it names no engine, and before §B3 it could not have compiled.

That is §B3's stated purpose ("so a non-TinyCortex engine gets Composio sync for free") turned into something that fails if it stops being true.

Two drivers, not one

"A non-TinyCortex engine" is a claim about drivers in general, not about whichever one was convenient. So the identical path runs against:

• the reference driver — which retains, and is asserted to round-trip the normalised body
• the null driver — whose retention semantics are the opposite, and whose empty read is asserted for exactly that reason

Provenance is asserted on the path where it matters

The payload came off somebody's inbox, so it is stored ExternalSync and the read-back checks the driver did not launder it to Internal. That is the single failure the taint argument exists to prevent, and this is the path where externally-sourced content actually arrives.

What this does not prove

Written into the module docs rather than left to be inferred.

§B5's full acceptance drives a live Composio API through the sync pipeline, and that pipeline still sits behind engine-owned state (§B1, §B2). What is testable today is that the transform and the storage tier have no engine between them — the part §B3 was responsible for.

The first draft failed, usefully

The fixture used the reshaped field names rather than the upstream ones, so the normaliser emitted nothing:

assertion `left == right` failed: one message was written
  left: []
 right: ["msg-1"]

It caught an empty result rather than a wrong one. The fixture now uses the upstream shape (messageId, sender, messageTimestamp) and the assertions use the reshaped one (id) — which is precisely the transform under test, and would not have been exercised by the original.

Public API changes

None. One integration test, and a dev-dependency on tinymemory-sync.

Validation

Command	Result
cargo fmt --all -- --check	pass
cargo clippy --all-targets --all-features -- -D warnings	pass
cargo build --all-targets --all-features	pass
cargo test --all-features	1219 passed, 0 failed
RUSTDOCFLAGS="-D warnings" cargo doc --no-deps --all-features	pass
./scripts/ci/dependency-budget.sh	pass
module crate cargo test --lib	pass — 35

Note on §B4

I started on §B4 ("core/src/sources/types.rs stops being a TinyCortex re-export shim") and stopped, because it is not the repoint it appears to be.

SourceItem and SourceKind exist in both the contract and the engine, and they are different types wearing the same names:

	contract	engine
SourceItem	item_id, title, content, mime, url, updated_at_ms, tags	id, title, updated_at_ms, …
SourceKind	Chat, Email, Document — a content class	Composio, Conversation, Folder, GithubRepo, TwitterQuery — an origin

Repointing the shim would silently change semantics. The engine's sources module is extractable in principle — 27 files, 6,045 lines, no SQL — but it depends on MemoryConfig (7 sites), MemoryEngineResult/MemoryError (5) and RawKind (2), which is the §A3 boundary in another guise. Flagging rather than guessing.

Related

Part of #18 (§B3), and the first movement on acceptance criterion 6.

[coderabbitai]

Important

Review available on request

• 🔍 Trigger review

Reviews should be triggered manually for repositories with fewer than 10 stars. Select Trigger review above or comment @coderabbitai review to review the latest changes. For a full review, comment @coderabbitai full review.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b1712256-5b49-48d9-898a-75cbf8ddc461

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[tinysweeper]

tinysweeper found nothing blocking. Approving.

$0.0000 · 0 in / 0 out

[tinysweeper]

How this change flows

1 changed behaviour across 4 relationships. 3 surrounding behaviours are shown (60 graph nodes walked). 21 further behaviours left out to keep the diagram readable.

flowchart LR
  n0["assert_awkward_content_round_trips<br/>changed"]:::changed
  n1["MemoryProvider"]:::impacted
  n2["push"]:::impacted
  n3["ingest_into"]:::impacted
  n0 -->|uses| n1
  n0 -->|calls| n2
  n3 -->|calls| n2
  n3 -->|tests| n2
  classDef changed fill:#0d4429,stroke:#238636,color:#e6edf3
  classDef impacted fill:#161b22,stroke:#6e7681,color:#c9d1d9
  classDef flagged fill:#5a1e02,stroke:#d93f0b,color:#ffffff
  classDef blocking fill:#67060c,stroke:#f85149,color:#ffffff

Loading

_{Green: changed behaviour. Grey: surrounding behaviour. Arrows name the call, use, implementation, or test relationship. Orange: has findings. Red: has a finding that blocks the merge.}