Code versus specification: external carriers

Headline

No external carrier is both wired through the shipping app and proved end to end: Discord is the only carrier with shipping prepare/place/read/open commands, while Telegram has a live composer-carry receipt but no shipping receive-and-reveal route; every other carrier is a refusal, an unregistered library seam, or a test model. [01-FULL-SPEC.md:98; apps/osl-hub/src/hub_command_surface.rs:884-943; apps/osl-hub/src/claim_state.rs:354-478; TASK 7786]

This audit used the local canonical integration/full worktree at commit 4d13b8a04f48767eb9c72c2432ae9ef01caf814a. The specification says the local canonical branch is the code authority and that checked tasks, fixtures, grep tests, and synthetic events are not shipping proof. [01-FULL-SPEC.md:340; RULING D19]

The roster already disagrees with itself

The specification's V1 roster has 12 external carriers: Discord, Telegram, Signal, WhatsApp, Instagram, Messenger, Gmail, Outlook, Proton, Yahoo, AOL, and iCloud. X is explicitly design-only and out of V1. [01-FULL-SPEC.md:352; 01-FULL-SPEC.md:368; 01-FULL-SPEC.md:376; RULING D20; RULING D35; RULING D36]

The rendered Home design shows 13 live links: the 12 specified carriers plus X. Every link opens Strip.dc.html. That is a false breadth signal because the strip has provider metadata and branding only for Discord, Telegram, and Signal; every other query value falls back to a generic Discord-coloured carrier and the Discord icon. [design/UI-FINAL-INSTRUCTIONS/Home.dc.html:250-257; design/UI-FINAL-INSTRUCTIONS/Strip.dc.html:517-523]

The code catalogue has eight service IDs: discord, telegram, whatsapp, instagram, x, messenger, email, and signal. It collapses all six mail providers into one email row and retains out-of-V1 X. Every row has realTwoPersonProtectedMessaging: false; despite that, Discord, Telegram, WhatsApp, Email, and Signal have launchState: "available". [apps/service-catalogue.json:16-34; TASK 7754; evidence/7754b.md:12-17]

The shipping Rust command surface uses the same eight service kinds. It does not expose separate Gmail, Outlook, Proton, Yahoo, AOL, or iCloud service kinds. [apps/osl-hub/src/hub_command_surface.rs:755-765]

The practical status is:

The row summaries above come from the registered Tauri commands, the native carry-seam map, and the code's own claim table. [apps/osl-hub/src/hub_command_surface.rs:772-943; apps/osl-hub/src/native_apps.rs:3610-3657; apps/osl-hub/src/claim_state.rs:354-478]

Discord

Promise

OSL must bind the exact Discord client, account, conversation, recipient scope, and composer; insert the entire cover in one operation; read the stored Discord row back; and declare success only after that readback. The receiver must watch the exact approved conversation, bind the author and row, decrypt locally, and reveal through the eye overlay. [01-FULL-SPEC.md:100-106; TASK 7761]

Code

Discord is the only external carrier with a product path registered in the shipping command list: prepare_native_discord_overlay_text, send_native_discord_overlay_carrier, rehydrate_native_discord_overlay_history, and open_native_discord_overlay_text. The atomic QA send and receipt commands beside them are compiled only with discord-qa-shell. [apps/osl-hub/src/hub_command_surface.rs:900-930]

prepare_native_discord_overlay_text proves the trusted overlay caller and lock, uploads/encrypts through the broker, binds the current Discord scope, and remembers the generated carrier cover. [apps/osl-hub/src/main.rs:4537-4615]

send_native_discord_overlay_carrier rechecks the overlay, lock, owner, context, and scope, then calls NativeDiscordComposerState::place_carrier. The UI calls that command through sendNativeDiscordOverlayCarrier. [apps/osl-hub/src/main.rs:4090-4149; apps/osl-hub-ui/src/native-overlay-adapter.ts:460-477]

rehydrate_native_discord_overlay_history calls native_discord_adapter::read_visible_message_rows, passes those provider rows to the broker for decoding, and maps decrypted rows onto the overlay. open_native_discord_overlay_text drains received protected text through the broker. [apps/osl-hub/src/main.rs:5475-5675; apps/osl-hub/src/main.rs:5678-5707; apps/osl-hub-ui/src/native-overlay-adapter.ts:526-532]

Delta

The component chain exists, but no real packaged sender-to-receiver run proves the chain as a whole. The code's claim table says Discord has no recorded two-party carry-and-return proof and keeps it at BuiltNeverProvenLive plus NeverProvenLive. TASK 7761 is checked, but its evidence says it is “Not promotable as packaged Discord functionality” and that the packaged two-account send/receive/lifecycle was not observed. [apps/osl-hub/src/claim_state.rs:354-373; evidence/7761.md; RULING D19]

Verdict: closest to working, not working by the project's proof rule. Do not label it Ready until the real run happens. [01-FULL-SPEC.md:368; apps/osl-hub/src/claim_state.rs:354-373]

Telegram

Promise

OSL must bind the Telegram work directory, signed-in account, and exact person or group; place one complete cover using the chosen send trigger; reject newline-risk routes; read the stored Telegram row back; then receive, authenticate, decrypt, and reveal from the bound chat. Composer carry alone is not delivery. [01-FULL-SPEC.md:110-116; RULING D12; TASK 7762; TASK 7762b]

Code

find_active_telegram_conversation_window finds the active conversation, while drive_telegram_composer_placement and the Windows-only place_telegram_desktop_carrier implement direct UIA placement. discover_telegram_composer, discover_telegram_transcript, and extract_telegram_row_candidates implement structural discovery over supplied node data. [apps/osl-hub/src/native_telegram_adapter.rs:86-107; apps/osl-hub/src/native_telegram_adapter.rs:501-579; apps/osl-hub/src/native_telegram_adapter.rs:722-793]

TelegramProtectedCarrier::send_receive_reveal models the complete send/read/reveal transaction behind a TelegramProtectedDriver trait. It is a library seam, not a registered Tauri command. [apps/osl-hub/src/telegram_protected_carrier.rs:76-103; apps/osl-hub/src/telegram_protected_carrier.rs:182-269; apps/osl-hub/src/hub_command_surface.rs:772-943]

The native carry map binds Telegram to drive_telegram_composer_placement. The claim table records ProvenLiveWithReceipt for composer carry but NeverProvenLive for delivery. [apps/osl-hub/src/native_apps.rs:3623-3647; apps/osl-hub/src/claim_state.rs:399-425]

Delta

Telegram can reach and prove a composer carry, but the shipping app exposes no Telegram prepare/send/read/reveal command. The focused TASK 7762 carrier test does not close that product-wiring gap, and the code itself refuses to claim delivery. [apps/osl-hub/src/hub_command_surface.rs:772-943; apps/osl-hub/src/claim_state.rs:417-425; apps/osl-hub/tests/task_7762_telegram_protected_carrier.rs; RULING D19]

Verdict: the carry substrate is ahead of Discord's proof, but the product path is behind Discord's wiring. [apps/osl-hub/src/claim_state.rs:399-425; apps/osl-hub/src/hub_command_surface.rs:772-943]

Signal

Promise

OSL must use an isolated Signal profile, prove the target account and conversation, drive the real composer without clipboard fallback, enumerate real rows, bind author and conversation, decrypt locally, and display the result in OSL. Changed controls or refused input must repair or visibly refuse. [01-FULL-SPEC.md:118-124; TASK 7763; TASK 7763b]

Code

discover_signal_composer, resolve_signal_composer, discover_signal_transcript, and extract_signal_row_candidates operate on Signal node trees. send_signal_cover_direct_command takes an abstract SelectedSignalSendRoute; read_signal_messages_for_scrub takes an abstract SignalOpenScreenSource. [apps/osl-hub/src/native_signal_adapter.rs:197-322; apps/osl-hub/src/signal_send_action.rs:68-76; apps/osl-hub/src/signal_send_action.rs:132-190; apps/osl-hub/src/signal_message_reader.rs:74-112]

The shipping command list exposes only get_signal_protected_send_readiness. It does not register the send function, message reader, or a protected receive/open route. [apps/osl-hub/src/hub_command_surface.rs:884-900]

Delta

The code has parser and contract pieces but no runnable Signal carrier. The claim table says the adapter has never been driven against the live client, and TASK 7763 remains open. [apps/osl-hub/src/claim_state.rs:375-386; TASK 7763]

Verdict: unavailable. Do not spend time on its isolated-profile ceremony until the real composer can be driven and read back. [apps/osl-hub/src/claim_state.rs:375-386; TASK 7763]

WhatsApp

Promise

OSL must prove the account and conversation, put the cover into WhatsApp's real message document rather than only its accessibility Value, read the actual document and sent row back, and then bind and decrypt a real inbound row. Failed placement must leave the provider untouched and show Retry. [01-FULL-SPEC.md:126-132; TASK 7764; TASK 7764b]

Code

discover_whatsapp_pair, place_whatsapp_carrier, read_whatsapp_box_state, and drive_whatsapp_composer_placement implement structural and live UIA operations. read_whatsapp_messages_for_scrub is a separate reader over a supplied browser-message source. [apps/osl-hub/src/native_whatsapp_adapter.rs:302-458; apps/osl-hub/src/native_whatsapp_adapter.rs:1030-1137; apps/osl-hub/src/whatsapp_message_reader.rs:60-147]

The command list exposes claim_whatsapp_qa_window, visual binding, QA prepare, and QA open commands, not a shipping WhatsApp carrier send/receive route. The native seam map binds the placement function, but the claim table records MeasuredAndRefused: accessibility changed while no real message row was created. [apps/osl-hub/src/hub_command_surface.rs:892-900; apps/osl-hub/src/native_apps.rs:3623-3657; apps/osl-hub/src/claim_state.rs:388-397; evidence/7764.md]

Delta

The required failure was measured, so refusal is correct. Calling TASK 7764 “done” must not be read as a working carrier; it established that the attempted mechanism does not send. [evidence/7764.md; RULING D19]

Verdict: honestly unavailable. Do not add lifecycle features around a placement path that does not reach the message document. [apps/osl-hub/src/claim_state.rs:388-397; evidence/7764.md]

Instagram

Promise

Only private Direct messages count. OSL must prove the signed-in account and exact DM, insert into the real private composer, read the provider row back, receive from a second identity, and never substitute an internal acknowledgement for delivery. [01-FULL-SPEC.md:134-140; TASK 7766; TASK 7766b]

Code

prepare_instagram_triggered_cover and prepare_instagram_cover create cover data. InstagramDirectMessageInbox stores deliveries in vectors, and dispatch_prepared_instagram_direct_message only calls an abstract receiving job; its comment explicitly says successful dispatch is not delivery proof. [apps/osl-hub/src/instagram_send.rs:169-239; apps/osl-hub/src/instagram_direct_message.rs:38-110]

No Instagram carrier command is registered, and the claim table says NotBuilt and NeverProvenLive. [apps/osl-hub/src/hub_command_surface.rs:772-943; apps/osl-hub/src/claim_state.rs:427-435]

Delta

There is no provider adapter, composer drive, stored-row readback, or inbound product job. TASK 7766 remains open, and the second isolated identity was deferred. [apps/osl-hub/src/claim_state.rs:427-435; TASK 7766; RULINGS.txt:2135-2139]

Verdict: model code only; keep the tile unavailable. [apps/osl-hub/src/claim_state.rs:427-435]

Messenger

Promise

OSL must attach to the exact real private Messenger thread, place and read back cover, receive and bind real provider rows, decrypt locally, and never count an internal pending envelope as a sent message. [01-FULL-SPEC.md:142-148; TASK 7767; TASK 7767b]

Code

MessengerTestAccount stores sent and received envelopes in vectors. MessengerTestMachine::send_marked_cover pushes an envelope into an in-memory pending queue, and LiveMessengerReceivingJob consumes that queue. read_messenger_messages_for_scrub is a separate abstract reader. [apps/osl-hub/src/messenger_delivery.rs:37-127; apps/osl-hub/src/messenger_message_reader.rs:43-59]

Messenger can open its fixed messages URL through the generic Firefox service launcher. That opening-only route is not a carrier: no Messenger-specific send, row-read, decrypt, or Scrub command is registered. [apps/osl-hub/src/native_apps.rs:292-300; apps/osl-hub/src/native_apps.rs:864-875; apps/osl-hub/src/native_apps.rs:1728-1758; apps/osl-hub/src/hub_command_surface.rs:772-943]

The claim table says NotBuilt and NotDeliverable. [apps/osl-hub/src/claim_state.rs:445-452]

Delta

The implementation is exactly the internal queue the specification says not to treat as delivery. TASK 7767 remains open. [01-FULL-SPEC.md:144; apps/osl-hub/src/messenger_delivery.rs:92-127; TASK 7767]

Verdict: opening-only plus a test machine; keep the carrier unavailable. [apps/osl-hub/src/messenger_delivery.rs:92-127; apps/osl-hub/src/claim_state.rs:445-452]

Shared mail reality

Promise

Each of Gmail, Outlook, Proton, Yahoo, AOL, and iCloud must independently bind an existing signed-in host, exact sender and recipient set, composer, stored body, provider row, and inbound message. One provider's proof cannot promote another. Email expiry is key-only for the recipient copy. [01-FULL-SPEC.md:150-200; RULING D25; TASK 7768]

Code shared by the six providers

ProtectedMailProviderAdapter names the required verbs, but the concrete WebView2MailAdapter stores rows, recipient keys, delete receipts, and row counters in process-local BTreeMaps. run_six_provider_protected_mail_seam exercises that adapter contract, including insertion, list/readback, recipient fetch, decrypt, and sender delete. [apps/osl-hub/src/protected_mail_seam.rs:335-397; apps/osl-hub/src/protected_mail_seam.rs:650-697]

The one registered shipping mail command, read_protected_email_open_message, launches RealBrowserWebsiteDriver and reads the currently selected page twice. It returns a message ID, cover body, and conversation identity; it does not send, receive through a background job, fetch the encrypted payload, or decrypt it. [apps/osl-hub/src/main.rs:236-250; apps/osl-hub/src/hub_command_surface.rs:38-122; apps/osl-hub/src/hub_command_surface.rs:775-808]

The claim table marks every web mail carrier NotBuilt and NotDeliverable, and marks Outlook desktop the same. [apps/osl-hub/src/claim_state.rs:455-478; apps/osl-hub/src/claim_state.rs:507-518]

Gmail

Promise

Gmail must bind the selected browser profile and To/CC/BCC/thread, insert directly into the real body editor, read the body back, activate named Send only after the OSL trigger, read real Inbox rows, decrypt locally, and use explicit sender-owned Trash/Bin deletion. [01-FULL-SPEC.md:150-156; TASK 7769]

Code and delta

run_gmail_protected_mail is a thin provider check around the in-memory shared seam. read_shipping_gmail_inbox and GmailApiTransport can list/fetch Gmail Inbox data with an OAuth bearer token, but their call sites are focused tests, not the registered shipping command surface. [apps/osl-hub/src/gmail_protected_mail.rs:8-32; apps/osl-hub/src/shipping_gmail_mailbox_receive.rs:138-170; apps/osl-hub/src/shipping_gmail_mailbox_receive.rs:233-285; apps/osl-hub/tests/task_7769_gmail_protected_mail.rs; apps/osl-hub/src/hub_command_surface.rs:772-943]

There is no product command that composes, sends, reads back, receives, and decrypts Gmail. Verdict: useful Inbox transport, no carrier lifecycle. [apps/osl-hub/src/hub_command_surface.rs:772-943; apps/osl-hub/src/claim_state.rs:473-478]

Outlook

Promise

Outlook web and Outlook desktop are separate selectable surfaces; each must independently prove its signed-in profile, recipients, conversation, editor, insertion, readback, named Send, inbound reader, and deletion behavior. [01-FULL-SPEC.md:158-164; TASK 7770; TASK 7770b]

Code and delta

run_outlook_protected_mail_lifecycle operates through OutlookProtectedMailAdapter, which holds its own provider lifecycle state. OutlookDesktopMailbox provides folder/message/open operations, while OutlookDesktopTask1286Fixture exposes fake place/read/send counters. The native carry map explicitly returns NoCarryPath for Outlook. [apps/osl-hub/src/outlook_provider_lifecycle.rs:234-341; apps/osl-hub/src/native_outlook_adapter.rs:313-396; apps/osl-hub/src/native_outlook_adapter.rs:457-550; apps/osl-hub/src/native_apps.rs:3623-3630]

No Outlook web or desktop carrier command is registered. Verdict: lifecycle and desktop models, no provider-wired carrier on either surface. [apps/osl-hub/src/hub_command_surface.rs:772-943; apps/osl-hub/src/claim_state.rs:455-478]

Proton Mail

Promise

Proton must use the existing selected browser session, its floating composer, real recipients/body/Send control, real folder/thread reads, local decrypt, and provider-specific delete. A generic webmail fixture is insufficient. [01-FULL-SPEC.md:166-172; TASK 7771]

Code and delta

ProtonMailHost is a trait and run_proton_protected_mail_transaction is an in-process transaction over supplied sender and recipient hosts. Its shipping command is absent; TASK 7771 evidence describes its external-host stand-in rather than a credentialed Proton run. [apps/osl-hub/src/protected_mail_seam.rs:764-842; apps/osl-hub/src/hub_command_surface.rs:772-943; evidence/7771.md]

Verdict: executable provider contract, no live Proton adapter. [apps/osl-hub/src/protected_mail_seam.rs:764-842; apps/osl-hub/src/claim_state.rs:473-478]

Yahoo Mail

Promise

Yahoo must use a selected signed-in browser profile, real recipients and body composer, direct insertion, stored readback, named Send, real inbound rows, and measured selector repair or refusal. [01-FULL-SPEC.md:174-180; TASK 7772; TASK 7772b]

Code and delta

YahooWebMailAdapter owns its own sender/recipient mailbox model and test mutations; run_yahoo_protected_mail_lifecycle executes that model. It has no registered shipping command. [apps/osl-hub/src/yahoo_protected_mail.rs:112-224; apps/osl-hub/src/yahoo_protected_mail.rs:529-587; apps/osl-hub/src/hub_command_surface.rs:772-943]

Verdict: focused provider-port model, no signed-in Yahoo carrier. [apps/osl-hub/src/yahoo_protected_mail.rs:112-224; apps/osl-hub/src/claim_state.rs:473-478]

AOL Mail

Promise

AOL must use the selected real browser session, prove recipients and the composer, insert and read back the exact body, invoke named Send, read real inbound rows, decrypt, and delete only explicitly selected sender-owned messages. [01-FULL-SPEC.md:182-188; TASK 7773; TASK 7773b]

Code and delta

AolShippingMailSurface is a trait and run_aol_protected_mail runs a transaction against a supplied implementation. The focused TASK 7773 tests call it, but no shipping command does. The repository still contains the explicit AolFakePageFixture boundary the specification says must be replaced. [apps/osl-hub/src/shipping_aol_protected_mail.rs:45-64; apps/osl-hub/src/shipping_aol_protected_mail.rs:166-238; apps/osl-hub/tests/task_7773_aol_protected_mail.rs; apps/osl-hub/src/aol_fake_page.rs; apps/osl-hub/src/hub_command_surface.rs:772-943]

Verdict: testable interface, no live AOL carrier. [apps/osl-hub/src/shipping_aol_protected_mail.rs:45-64; apps/osl-hub/src/claim_state.rs:473-478]

iCloud Mail

Promise

iCloud must bind a selected browser profile, recipients, conversation, composer, stored body, named Send, real inbound mailbox rows, local decrypt, and explicit sender-owned deletion. Its proof needs two isolated live identities. [01-FULL-SPEC.md:190-196; TASK 7774; TASK 7774b]

Code and delta

read_icloud_shared_mailbox_folders, read_icloud_shared_mailbox_messages, and open_icloud_shared_mailbox_message are wrappers over the shared mailbox snapshot model. There is no iCloud send transaction or registered iCloud carrier command, and TASK 7774 remains open. [apps/osl-hub/src/icloud_mailbox_reader.rs:21-74; apps/osl-hub/src/hub_command_surface.rs:772-943; TASK 7774]

Verdict: snapshot readers only; not a carrier. [apps/osl-hub/src/icloud_mailbox_reader.rs:21-74; apps/osl-hub/src/claim_state.rs:473-478]

X

Promise

X is not a V1 carrier. The higher-authority ruling says later fixture or task work cannot promote it. [01-FULL-SPEC.md:376; RULING D20; TASK 7765]

Code and delta

prepare_x_cover, check_x_private_count, and XPrivateCarrierAdapter::send_and_reveal exist as library abstractions. No X carrier command is registered, the native carry map says NoCarryPath, and the claim table says live carry and delivery have not passed. [apps/osl-hub/src/x_send.rs:99-181; apps/osl-hub/src/x_private_composer.rs:102-143; apps/osl-hub/src/x_private_carrier.rs:203-272; apps/osl-hub/src/native_apps.rs:3623-3630; apps/osl-hub/src/claim_state.rs:436-443]

Verdict: cut X from the actionable Home roster and do not spend first-carrier time completing it. [design/UI-FINAL-INSTRUCTIONS/Home.dc.html:254-257; 01-FULL-SPEC.md:376]

Scrub is narrower than the catalogue, and its shipping path reads no provider

The known lead is true in the UI adapter layer: hosted Scrub names only gmail-web, discord, and telegram-web, and the preload registry contains only those three providers. The eight-row catalogue separately names Discord, Telegram, WhatsApp, Instagram, X, Messenger, Email, and Signal. [apps/osl-hub-ui/src/scrub-hosted-session-port.ts:1-3; apps/osl-hub-ui/src/scrub-provider-preloads.ts:31-64; apps/service-catalogue.json:16-34]

Other Scrub-adjacent allowlists are different again: autoscrub-contract.ts, mass-cleanup.ts, and the adapter parser accept Discord, Telegram, Email, Signal, WhatsApp, and Messenger, omitting catalogue entries Instagram and X. [apps/osl-hub-ui/src/autoscrub-contract.ts:146; apps/osl-hub-ui/src/mass-cleanup.ts:32; apps/osl-hub-ui/src/adapters.ts:2239]

The rendered Scrub page is a third roster: Discord, Gmail, Outlook, X, and Reddit demo accounts. Its run loop uses fixed synthetic counts. [design/UI-FINAL-INSTRUCTIONS/Scrub.dc.html:87; design/UI-FINAL-INSTRUCTIONS/Scrub.dc.html:110-158]

The shipping backend is worse than all three rosters imply. list_scrub_accounts returns accounts from the local owner registry. read_scrub_discovery_page explicitly has no provider authentication; it returns readable: 1, exposures: 0, and complete: true for the selected registry row without reading provider content. [apps/osl-hub/src/main.rs:1351-1396; apps/osl-hub/src/services.rs:2564-2600]

The reachable account-creation route makes that registry narrower still: create_service_account rejects the native Discord, Telegram, Signal, and WhatsApp services, while create_with_provider_for_owner rejects every comingSoon catalogue service, which covers Instagram, X, and Messenger. Through the registered product route, Email is therefore the only catalogue category that can acquire the registry record consumed by Scrub. [apps/osl-hub/src/main.rs:6167-6190; apps/osl-hub/src/services.rs:1079-1090; apps/osl-hub/src/hub_command_surface.rs:938-959]

scrub_real_discovery::discover and verify_report exist, but the shipping route does not call them. TASK 7972's checked evidence says no signed-in provider adapter is reached, provider exercises equal zero, and the result is non-pass. TASK 7784's checked evidence also says the provider/browser finish line was not completed. [apps/osl-hub/src/scrub_real_discovery.rs:33-67; apps/osl-hub/src/scrub_real_discovery.rs:100-176; evidence/7972.md:7-11; evidence/7972.md:54-64; evidence/7784.md:61-66]

Therefore Scrub currently scans no live carrier at all. The three named hosted adapters are unused capability fragments, not three working sources. [proof/7972-scrub-scope-register.md:13-28; RULING D19]

What to cut or defer now

Cut the global 13-carrier release gate. TASK 7786 requires 13 real-carrier lifecycles even though X is out of V1, and TASK 7791 requires all carrier receipts in one 61-area release gate. Those gates prevent learning from one working carrier and do not stop a wrong-recipient send; per-carrier enablement already requires each actionable carrier's own evidence. [todo/49-native-surfaces-release.txt:185-207; TASK 7791; 01-FULL-SPEC.md:368; 01-FULL-SPEC.md:376]

Defer timers, view once, attachments, burn scopes, multi-device expiry, the nine-step coach, pixel matching, support-policy work, and desktop/web breadth until one basic protected round trip works. Those features do not create the missing composer-to-provider-to-recipient path. [01-FULL-SPEC.md:69-82; 01-FULL-SPEC.md:86-90; 01-FULL-SPEC.md:252; RULING D20; RULING D22]

Defer the five-fact first-send risk ceremony and Scrub's terms-link/account-switch/profile-consent matrices until a carrier sender or provider reader exists. Keep explicit owner-controlled account selection and exact target binding, because those stop a real third party being contacted. Keep an exact reviewed-item confirmation before any future destructive Scrub delete. [TASK 3109-3115; TASK 6210; TASK 6296; TASK 7785; RULING D38]

Keep three hard gates for the first carrier: exact sender account and destination binding before placement; refusal on ambiguous or changed composer/row; and no Ready/proof claim until the carrier-stored row and recipient decrypt have actually been observed. These prevent harm or a false claim. [01-FULL-SPEC.md:69-82; 01-FULL-SPEC.md:98; RULING D30; RULING D38]

Shortest path to one carrier working end to end

Use Discord. It already has the only shipping UI-to-Rust prepare, placement, provider-row read, broker decrypt, and overlay-open chain, and the owner has three verified Discord identities available for a private acceptance run. [apps/osl-hub-ui/src/native-overlay-adapter.ts:269-277; apps/osl-hub-ui/src/native-overlay-adapter.ts:460-477; apps/osl-hub-ui/src/native-overlay-adapter.ts:526-532; apps/osl-hub/src/main.rs:4090-4149; apps/osl-hub/src/main.rs:4537-4615; apps/osl-hub/src/main.rs:5475-5707; RULING D59]

Do only this:

1. Launch the packaged integration build with one owner-controlled Discord sender account and one owner-controlled receiver account. Record both identities before the run. [RULING D38; RULING D59; TASK 3902]

2. Bind the sender executable/account, the one intended DM, its recipient, and exactly one composer. If the account, DM, recipient, or composer is ambiguous, refuse before writing any carrier bytes. [01-FULL-SPEC.md:69; apps/osl-hub/src/main.rs:4098-4139]

3. Prepare one short protected text through prepare_native_discord_overlay_text. Do not enable attachments, timer, view once, or burn. [apps/osl-hub/src/main.rs:4537-4615]

4. Place and send the cover through send_native_discord_overlay_carrier with the selected trigger. Do not use the QA-only atomic command as the product proof. [apps/osl-hub/src/main.rs:4090-4149; apps/osl-hub/src/hub_command_surface.rs:900-918]

5. Read the exact carrier-stored sender row back and compare it byte-for-byte with the placed cover. A mismatch is a refusal, not a receipt. [01-FULL-SPEC.md:74-75; TASK 7761]

6. On the second owner-controlled account, observe the real Discord row, bind its author and conversation, run the shipping rehydrate/open path, and show the exact original private text. [apps/osl-hub/src/main.rs:5475-5707; 01-FULL-SPEC.md:79-82]

7. Run one negative case with the wrong DM or an ambiguous composer and prove that no carrier message was sent. This is the minimum evidence that protects the no-third-party line. [01-FULL-SPEC.md:69-70; RULING D38]

8. Save the packaged build hash, account aliases, conversation alias, placed cover hash, carrier-stored row hash, recipient-observed row hash, decrypted-text hash, timestamps, and negative-case result. Only then change Discord's claim from unproven. [apps/osl-hub/src/claim_state.rs:354-373; RULING D19; RULING D63]

Stop there. A real Discord round trip is more valuable than more carrier abstractions, consent prose, or checked tasks. It preserves both non-negotiable lines: both accounts are owner-controlled, and no proof is claimed before the carrier-stored and recipient-decrypted results exist. [RULING D38; RULING D19]