Other carriers: viability, implementation truth, and V1 cut

Headline

Gmail and Outlook are the only remaining carriers worth taking straight to a working V1; Signal is the next credible chat experiment, while WhatsApp, Instagram, Messenger, and X should stay unavailable because none has a working carrier and their personal-messaging surfaces have no supported automation path. [RULINGS.txt:44-54, 68-72; 01-FULL-SPEC.md:118-200; TASKS 7763-7774]

What “viable” means here

A carrier is viable only if OSL can put cover text into an exact owner-controlled destination, read back what the carrier stored, read the same row from a second owner-controlled identity, and reveal the protected text locally. A unit test, an in-memory mailbox, a DOM fixture, opening an app, or writing only to an accessibility Value is not carrier proof. OSL must never message a real third party and must never report a proof that did not happen. [01-FULL-SPEC.md:15, 69-82; TASK 7760; TASKS 7763-7774]

The carrier does not see the private text. It sees an ordinary cover message plus its normal sender, recipient or audience, time, size, thread, and social-graph metadata. Anyone who can see that carrier surface sees the cover; OSL’s reveal changes only the local OSL view. [01-FULL-SPEC.md:9, 41, 79-82]

This report inspected canonical integration/full at 4d13b8a04f48767eb9c72c2432ae9ef01caf814a. Code citations below name files in that tree. [01-FULL-SPEC.md:3]

Ranked by effort to a working product

The order reflects the shortest path to one honest two-account run, not market size. None of the first six has a shipping-reachable send-and-receive path; Gmail’s real-capable GET reader is exported but not connected to the app, and the shared send seam remains in-memory. Ranks 1-6 are opportunities, not implementation claims. [CODE apps/osl-hub/src/shipping_gmail_mailbox_receive.rs:138-199, 230-323; CODE apps/osl-hub/src/protected_mail_seam.rs:385-406; CODE apps/osl-hub-ui/src/services.ts:592-597; TASKS 7768-7774]

Instagram

Surfaces. Instagram has one-to-one DMs, group DMs, story replies, post and Reel comments, and broadcast channels. OSL’s specified carrier is private DM only; a comment, story, or channel post would change the audience and is not an acceptable fallback. Instagram’s official messaging API is for professional accounts, requires the recipient to have messaged the professional account first, and does not support group messaging. [01-FULL-SPEC.md:134-140; TASK 7766] [Instagram group chats](https://www.facebook.com/help/113882968962608) [Instagram API limitations](https://www.postman.com/meta/instagram/documentation/6yqw8pt/instagram-api)

What an onlooker sees. A DM recipient or every member of a group DM sees the cover in the thread. Story viewers, channel members, and the audience of a post or Reel see cover placed on those broader surfaces, which is exactly why OSL must not fall back from a DM to them. People outside the chosen carrier audience see nothing from OSL. [01-FULL-SPEC.md:9, 15, 41; TASKS 7766, 7766b]

Overlay. A local overlay is technically possible only by continuously binding to Instagram’s changing browser DOM and row geometry. There is no carrier-specific Instagram overlay in the design or code: Home routes Instagram to the generic Strip, whose unknown-app fallback is Discord-shaped. The current Instagram module only holds received covers in a Vec and dispatches them to a trait; it never finds a browser, composer, account, conversation, or row. [DESIGN Home.dc.html:244-257; DESIGN Strip.dc.html:410, 517-529; CODE apps/osl-hub/src/instagram_direct_message.rs:45-64, 104-117; TASK 7766]

What breaks carriage and how hostile automation is. Instagram can route unknown senders to message requests and can hide comments or message requests through Hidden Words and spam filtering. Meta requires prior written permission for automated data collection and may restrict automation; its supported API does not solve personal DMs or groups. Image recompression is irrelevant to the specified text-cover carrier and was not established as a text transformation. [01-FULL-SPEC.md:17, 45, 134-140; TASK 7766] [Instagram message controls](https://www.facebook.com/help/instagram/1435783229983256) [Hidden Words](https://www.facebook.com/help/instagram/700284123459336) [Meta automated collection terms](https://www.facebook.com/legal/automated_data_collection_terms)

Verdict. Not worth V1. comingSoon is honest, but reading: true in the catalogue is not: no live reader exists. Leave it unavailable until a real private-DM send and second-account receive are observed; do not spend V1 on a brittle browser bot to satisfy the current overlay spec. [CODE apps/service-catalogue.json:30; CODE apps/osl-hub-ui/src/services.ts:590; TASKS 4256, 4265, 7766]

X

Surfaces. X has one-to-one DMs, group DMs, public posts, and public replies. It has no current story surface and no OSL-appropriate channel surface. OSL may use a private DM only; a post or reply is a public audience change and must never be used as fallback. [01-FULL-SPEC.md:15; TASKS 4255, 4264, 7765b] [X Direct Messages](https://help.x.com/en/using-x/direct-messages)

What an onlooker sees. The recipient or all group members see the cover, sender, time, and surrounding thread. A public post or reply exposes the cover to the post’s audience, so exact private-conversation binding is a safety requirement, not process overhead. [01-FULL-SPEC.md:9, 15, 41; TASK 7765b]

Overlay. An overlay would require a browser DOM reader tied to the exact account, DM, row, and author. No such implementation exists. XPrivateConversationDriver is only a trait, while task_7765_x_private_carrier.rs stores the composer and rows in Vecs and assigns the enum value ProductionPrivateComposer itself. That proves contract behavior, not X carriage. [CODE apps/osl-hub/src/x_private_carrier.rs:67-88; CODE apps/osl-hub/tests/task_7765_x_private_carrier.rs:20-59, 69-82; TASK 7765]

What breaks carriage and how hostile automation is. X rewrites submitted links through t.co, so a link carrier cannot assume byte preservation. Its automation rules say non-API website scripting can lead to permanent suspension, and automated DMs require prior user action or opt-in. Plain word-only cover avoids t.co, but it does not remove the automation ban or the risk of message-request filtering. Image recompression is irrelevant to the specified text carrier. [01-FULL-SPEC.md:17, 45; TASK 7765] [X link shortening](https://help.x.com/en/using-x/url-shortener) [X automation rules](https://help.x.com/en/rules-and-policies/x-automation?lang=browser)

Verdict. Not worth V1 and the least attractive carrier in this report. comingSoon is honest, but reading: true is not. TASK 7765’s checked state must not be treated as live proof because its “production” driver never leaves process memory. [CODE apps/service-catalogue.json:31; CODE apps/osl-hub-ui/src/services.ts:589; CODE apps/osl-hub/tests/task_7765_x_private_carrier.rs:20-82; TASKS 4255, 4264, 7765]

Facebook Messenger

Surfaces. Messenger has one-to-one chats, group chats, community chats, and stories. Facebook post comments are a Facebook surface, not a private Messenger carrier. OSL’s acceptable V1 surface would be a private one-to-one chat only; group, community, story, or comment fallback would change the audience. [01-FULL-SPEC.md:142-148; TASK 7767] [Messenger group chats](https://www.facebook.com/help/messenger-app/1759354747722950) [Messenger communities](https://www.facebook.com/help/messenger-app/464461661975166) [Messenger stories](https://www.facebook.com/help/messenger-app/1723687361292230)

What an onlooker sees. A direct recipient, every group member, a community audience, or the selected story audience sees the cover on the surface used. They also see the carrier identity, time, and conversation context; the private payload remains in OSL. [01-FULL-SPEC.md:9, 41, 142-148; TASK 7767b]

Overlay. A browser overlay is possible in principle but has no implementation. The current file literally defines MessengerTestAccount and MessengerTestMachine and stores sent, received, and pending covers in vectors. Home again opens the generic Discord-shaped Strip rather than a Messenger row overlay. [CODE apps/osl-hub/src/messenger_delivery.rs:37-48, 92-102; DESIGN Home.dc.html:254-257; DESIGN Strip.dc.html:517-529; TASK 7767]

What breaks carriage and how hostile automation is. Meta supports automated Messenger chats for Pages through Meta APIs; that is not a supported personal-account carrier. Meta’s terms prohibit automated access or collection without permission, so a personal-chat browser bot carries account-enforcement and breakage risk. Spam and message-request routing can keep a cover out of the main inbox. No text rewrite or image transformation relevant to OSL’s word-only carrier was established. [01-FULL-SPEC.md:45, 53, 142-148; TASK 7767] [Automated Page chats](https://www.facebook.com/help/messenger-app/1127097651266653/Automated%2Band%2BAI%2Bchats%2Bwith%2BPages%2Bon%2BMessenger) [Meta terms](https://www.facebook.com/terms/)

Verdict. Not worth V1. comingSoon is accurate, while reading: true is unsupported. Build no Messenger overlay until a supported personal-message route exists or the owner explicitly accepts a fragile web-only adapter as an experiment. [CODE apps/service-catalogue.json:32; CODE apps/osl-hub-ui/src/services.ts:591; TASKS 4257, 4265, 7767]

Signal

Surfaces. Signal has one-to-one chats, group chats, and stories, including stories shared to groups. It has no public comment system or broadcast-channel carrier. V1 should use one-to-one chat only; group support adds author, membership, and scope work without proving the core carrier. [01-FULL-SPEC.md:118-124; TASK 7763] [Signal groups](https://support.signal.org/hc/en-us/articles/360007319331-Group-chats) [Signal stories](https://support.signal.org/hc/en-us/articles/5008009166234-Stories)

What an onlooker sees. The direct recipient or group members see cover text, the Signal sender, time, reactions, replies, and thread context. Story audiences see the cover as story content. Signal itself still carries the cover and normal metadata; OSL’s private text appears only in the local reveal. [01-FULL-SPEC.md:9, 41, 79-82; TASK 7763]

Overlay and implementation. Signal is the most plausible chat overlay because it has a supported linked Windows desktop client and the code has a Windows UI Automation tree snapshot. That UIA adapter is not working end to end: it says it does not discover windows, read names or text, place input, or attest a destination, and paint_targets returns AccessibilityUnavailable. Separate code can execute an account-holder-provisioned signal-cli linked-device send and requires a Signal timestamp, but it is exported without a runtime caller and has no live proof or receive path. The official desktop client being open source helps diagnosis but is not an automation API. [CODE apps/osl-hub/src/adapters/signal.rs:1-5, 198-200, 261-278; CODE apps/osl-hub/src/signal_extra_device_sender.rs:1-6, 77-88, 155-191; CODE apps/osl-hub/src/lib.rs:1123-1124; TASK 7763] [Signal linked devices](https://support.signal.org/hc/en-us/articles/360007320551-Linked-Devices) [Signal Desktop source](https://github.com/signalapp/Signal-Desktop)

What breaks carriage and how hostile automation is. No supported Signal messaging automation API was established. Desktop updates can change its accessibility tree, which the owner’s Signal ruling already treats as a known breakage source. No documented text rewriting was established; word-only cover should avoid link and image transformations, while media recompression would matter only for an unplanned image carrier. [RULINGS.txt:68-72; 01-FULL-SPEC.md:118-124; TASKS 7763, 7763b]

Verdict. Viable as the next chat experiment, not available now and not a V1 commitment. The dormant linked-device sender makes Signal materially closer than the other chats, but the catalogue’s available state is still false: the app’s own service registry says comingSoon, neverProvenLive, protected mode unavailable, and overlay unsupported. Wire and prove one direct owner-controlled send and receive; only then decide whether row overlay is worth the maintenance. [CODE apps/service-catalogue.json:34; CODE apps/osl-hub/src/signal_extra_device_sender.rs:77-88, 155-191; CODE apps/osl-hub-ui/src/services.ts:559, 587; TASK 7763]

WhatsApp

Surfaces. WhatsApp has one-to-one chats, groups, Communities and announcement groups, Channels, and 24-hour Status posts. Channels are one-way broadcast surfaces with reactions; Status is the story-like surface. OSL must use an exact one-to-one chat for the first carrier proof and must never fall into group, announcement, Channel, or Status. [01-FULL-SPEC.md:126-132; TASK 7764] [WhatsApp Channels](https://about.fb.com/news/2023/09/whatsapp-channels-heres-everything-you-need-to-know/) [WhatsApp Status](https://about.fb.com/news/2023/02/new-whatsapp-status-features/) [WhatsApp community announcements](https://about.fb.com/news/2024/05/events-in-whatsapp-communities/)

What an onlooker sees. A direct recipient, group or Community members, Channel followers, or Status audience sees the cover on the chosen surface. Link Status posts can receive automatic visual previews, which changes presentation even when the underlying URL survives. OSL’s intended word-only direct-chat cover avoids that surface. [01-FULL-SPEC.md:9, 41, 126-132; TASK 7764] [WhatsApp Status](https://about.fb.com/news/2023/02/new-whatsapp-status-features/)

Overlay. The code has a real OSL-owned composer window that can sit over verified WhatsApp composer geometry, but its preparation receipt explicitly says automaticPlacement: false and realMessageSent: false. It is not a carrier-row reveal overlay. The live write has failed: the accessibility value changes while WhatsApp’s real message document remains empty. This is a useful measured refusal, not a nearly finished adapter. [CODE apps/osl-hub/src/native_whatsapp_overlay.rs:1-11, 68-109; CODE apps/osl-hub-ui/src/whatsapp-overlay-prepare.ts:1-10, 25-43; CODE apps/osl-hub-ui/src/whatsapp-send.ts:35-48; CODE apps/osl-hub-ui/src/services.ts:560-563; EVIDENCE 7764.md:1-10; TASKS 7764, 7764b]

What breaks carriage and how hostile automation is. Meta’s supported WhatsApp Cloud API is a Business Platform: it requires a business portfolio, WhatsApp Business Account, and business phone number rather than controlling a user’s personal chats. Business messaging requires opt-in, restricts business-initiated messages to approved templates outside the service window, and can restrict accounts; WhatsApp also detects automated and bulk messaging. No direct-chat word rewrite was established, and image recompression is outside the text-cover design. [01-FULL-SPEC.md:126-132; TASK 7764] [WhatsApp Cloud API](https://www.postman.com/meta/whatsapp-business-platform/documentation/wlk6lh4/whatsapp-cloud-api) [WhatsApp Business policy](https://business.whatsapp.com/policy) [Meta on WhatsApp automated-message enforcement](https://about.fb.com/news/2022/02/how-meta-is-prepared-to-protect-the-upcoming-state-elections-in-india/)

Verdict. Not worth V1 unless a short experiment finds a real document insertion route. available is false: placing is already false in the catalogue, while the app’s own registry marks the carrier comingSoon, measured-and-refused, and unable to send. Do not turn repeated retries against a refused technique into a schedule. [CODE apps/service-catalogue.json:29; CODE apps/osl-hub-ui/src/services.ts:560-563, 588; TASK 7764]

Mail: the common shape

All six mail carriers offer direct mail, multi-recipient mail, and conversation or thread views. They do not offer carrier-native stories or comments; mailing lists and multi-recipient threads are the group-like surface, not an OSL channel. The onlooker sees sender, recipients visible to them, subject, time, cover body, attachments, and quoted thread history. OSL cannot remove the recipient’s carrier email; expiry can only destroy OSL decryption authority. [RULING D36 at RULINGS.txt:1869-1886; 01-FULL-SPEC.md:41, 47, 86; TASKS 7768-7774]

For a working product, use provider APIs or authenticated IMAP/SMTP for carriage and an OSL-owned message/reveal pane for display. A provider API can prove the account, message ID, stored MIME body, recipient mailbox arrival, and thread without driving a web composer. It cannot paint inside Gmail, Outlook, or another mail client; pixel-matched in-client overlay is a separate browser-extension or accessibility project. [01-FULL-SPEC.md:69-82, 150-200; TASK 7768]

The current “WebView2” adapter is not a WebView2 mail carrier. It stores rows, keys, and receipts in BTreeMaps and synthesizes sender and recipient row IDs. A separate Gmail module contains a genuine GET-only REST reader, but code search finds it only at its export, definition, and mock-server tests; no app command reaches it. Therefore TASKS 7768-7773 being checked do not establish a real send, a shipping reader, or a two-account proof. [CODE apps/osl-hub/src/protected_mail_seam.rs:385-406, 492-512; CODE apps/osl-hub/src/shipping_gmail_mailbox_receive.rs:1-7, 138-199, 230-323; CODE apps/osl-hub/src/lib.rs:1114; CODE apps/osl-hub-ui/src/services.ts:592-597; TASKS 7768-7773]

Gmail

Gmail’s useful surfaces are a message, multi-recipient message, and conversation thread. Google’s Gmail API can list and read messages and threads, send MIME messages or drafts, and watch mailbox changes. Current code already has an OAuth-authenticated GET-only Gmail Inbox reader that validates provider message and thread IDs, but it is not wired to the app and its tests use a local HTTP server. The common Gmail send still uses the in-memory mail seam. None of this provides an in-Gmail OSL overlay. [01-FULL-SPEC.md:150-156; CODE apps/osl-hub/src/shipping_gmail_mailbox_receive.rs:138-199, 230-323, 370-419; CODE apps/osl-hub/src/gmail_protected_mail.rs:14-31; TASK 7769] [Gmail API overview](https://developers.google.com/workspace/gmail/api/guides) [sending Gmail messages](https://developers.google.com/workspace/gmail/api/guides/sending)

Gmail can classify mail as spam or reject it because of content, links, or attachments. OAuth scopes for reading and composing mail are sensitive or restricted and can require verification and a security assessment when server-side handling is involved. Those are production onboarding costs, not reasons to fake the carrier with a browser fixture. Image recompression is not relevant to a text MIME body. [01-FULL-SPEC.md:45, 53, 150-156; TASK 7769] [Gmail spam behavior](https://support.google.com/mail/answer/6596) [Gmail OAuth scopes](https://developers.google.com/workspace/gmail/api/auth/scopes)

Verdict: first build. Use two owner-controlled Google accounts, send a word-only cover through the API, read the exact stored body and recipient message ID, and reveal it in OSL. Do not require Gmail-pixel overlay for the first proof. [TASKS 7768, 7769; 01-FULL-SPEC.md:69-82]

Outlook

Outlook offers messages, recipient sets, folders, and conversation threads. Microsoft Graph supports authorized personal and work mailboxes, MIME or JSON send, message read, reply, forward, and thread identifiers. Build the Graph path first; the spec’s simultaneous Outlook-web-and-desktop demand is not needed to prove carriage. [01-FULL-SPEC.md:158-164; TASK 7770] [Microsoft Graph mail overview](https://learn.microsoft.com/en-us/graph/api/resources/mail-api-overview?view=graph-rest-1.0) [Graph sendMail](https://learn.microsoft.com/en-us/graph/api/user-sendmail?view=graph-rest-1.0)

Microsoft 365 Safe Links can rewrite URLs in protected organizations, so any URL carrier needs post-delivery readback. A word-only MIME cover avoids that rewrite, though spam and organizational mail policy can still reject or quarantine it. Graph does not create an Outlook UI overlay. [01-FULL-SPEC.md:45, 158-164; TASK 7770] [Microsoft Safe Links](https://learn.microsoft.com/en-us/defender-office-365/safe-links-policies-configure)

Verdict: second build. The current registry is correct that no Outlook carrier is wired, despite TASK 7770 being checked; the native Outlook code is a read-only window/title probe and snapshot reader, not a send path. Support Graph/web semantics in V1 and defer desktop-client visual parity. [CODE apps/osl-hub/src/native_outlook_adapter.rs:1-7, 57-129, 297-420; CODE apps/osl-hub-ui/src/services.ts:564, 593; TASK 7770]

Yahoo Mail

Yahoo offers ordinary messages, multi-recipient threads, and authenticated IMAP/SMTP access with SSL and an app password. Its spam filter runs before user filters, so a delivered cover can be diverted before it reaches the expected folder. Standard mail protocols make carriage possible; an in-Yahoo overlay still requires separate browser work. [01-FULL-SPEC.md:174-180; TASK 7772] [Yahoo IMAP/SMTP settings](https://help.yahoo.com/kb/imap-internet-message-access-protocol-sln4075.html) [Yahoo spam/filter order](https://help.yahoo.com/kb/SLN36744.html)

Verdict: viable through the shared mail adapter, but not worth adding before Gmail and Outlook prove the product. The current Yahoo code’s BTreeMap rows are a model, not Yahoo. [CODE apps/osl-hub/src/yahoo_protected_mail.rs:113-157; CODE apps/osl-hub-ui/src/services.ts:595; TASK 7772]

AOL Mail

AOL offers ordinary messages and threads through authenticated IMAP/SMTP with SSL and app passwords. This is enough for a standard mail carrier but not an in-AOL overlay, and AOL may require explicit third-party-client authorization. No AOL-specific link rewrite or image transformation was established. [01-FULL-SPEC.md:182-188; TASK 7773] [AOL IMAP settings](https://help.aol.com/articles/download-your-email-from-aol-mail-with-imap) [AOL third-party access](https://help.aol.com/articles/allow-apps-that-use-less-secure-sign-in)

Verdict: viable after Yahoo as another shared-protocol provider, not V1. TASK 7773’s checked state cannot promote it because its evidence compiles a local test and the shipping registry still says there is no reader. [EVIDENCE 7773.md:19-27; CODE apps/osl-hub-ui/src/services.ts:596; TASKS 7773, 7773b]

iCloud Mail

iCloud offers messages and threads through authenticated IMAP/SMTP. Apple documents SSL, SMTP authentication, and app-specific-password or supported Outlook authorization on Windows. That is a real carrier route, but the required second owner-controlled account proof remains open and no iCloud reader exists in code. [01-FULL-SPEC.md:190-196; TASKS 7774, 7774b; CODE apps/osl-hub-ui/src/services.ts:597] [Apple iCloud Mail server settings](https://support.apple.com/en-us/102525)

No iCloud-specific text rewriting or image recompression relevant to word-only cover was established. Standard junk filtering and account throttling still require a delivery timeout and honest refusal, not an assumed inbox arrival. [01-FULL-SPEC.md:45, 53, 190-196; TASK 7774]

Verdict: viable through the shared mail adapter, but after Gmail, Outlook, Yahoo, and AOL because the account setup and missing second identity add work without teaching a new carrier mechanism. [TASKS 7768, 7774]

Proton Mail

Proton offers ordinary messages and threads. Proton Mail Bridge exposes a signed-in paid account as local IMAP/SMTP on Windows and performs encryption and decryption locally, which gives OSL a supported mail-client boundary without automating Proton’s web UI. Bridge is paid-plan-only and must be installed and running. [01-FULL-SPEC.md:166-172; TASK 7771] [Proton Bridge setup](https://proton.me/support/imap-smtp-and-pop3-setup) [why Bridge is required](https://proton.me/support/why-you-need-bridge)

Proton uses spam filtering. Its terms permit automated access only when it behaves like a normal client and is not abusive, so Bridge-backed normal mail access is materially safer than browser automation. No text rewrite relevant to a word-only body was established; an in-Proton overlay remains separate work. [01-FULL-SPEC.md:45, 166-172; TASK 7771] [Proton spam filtering](https://proton.me/support/avoid-spam) [Proton terms](https://proton.me/legal/terms)

Verdict: technically viable, but last among mail for V1 because it adds a paid-plan and helper-install dependency. The current provider test admits that its fixture stands in for the external host; it is not live Proton proof. [EVIDENCE 7771.md:11-25; CODE apps/osl-hub-ui/src/services.ts:594; TASKS 7771, 7771b]

Catalogue truth

apps/service-catalogue.json and the shipping UI registry disagree. The catalogue labels WhatsApp and Signal available, labels Instagram, X, and Messenger comingSoon, and claims reading: true for all five. The shipping registry labels all five unavailable or coming later and explicitly says there is no live proof. [CODE apps/service-catalogue.json:29-34; CODE apps/osl-hub-ui/src/services.ts:559-563, 587-591]

• Instagram: comingSoon is accurate; reading: true is false. The implementation is an in-memory receiving contract with no Instagram reader. [CODE apps/service-catalogue.json:30; CODE apps/osl-hub/src/instagram_direct_message.rs:45-64; TASK 7766]
• X: comingSoon is accurate; reading: true is false. The only alleged production driver is inside a test and mutates vectors. [CODE apps/service-catalogue.json:31; CODE apps/osl-hub/tests/task_7765_x_private_carrier.rs:20-82; TASK 7765]
• Messenger: comingSoon is accurate; reading: true is false. MessengerTestMachine never touches Messenger. [CODE apps/service-catalogue.json:32; CODE apps/osl-hub/src/messenger_delivery.rs:37-48, 92-102; TASK 7767]
• WhatsApp: available is false. The catalogue itself says placing: false, and the live measurement says the message document stays empty. [CODE apps/service-catalogue.json:29; CODE apps/osl-hub-ui/src/services.ts:560-563, 588; EVIDENCE 7764.md:1-10; TASK 7764]
• Signal: available is false. A real-capable signal-cli sender exists but is not connected or live-proven; the partial UIA snapshot cannot place input or attest a destination, and overlay painting refuses. [CODE apps/service-catalogue.json:34; CODE apps/osl-hub/src/signal_extra_device_sender.rs:77-88, 155-191; CODE apps/osl-hub/src/adapters/signal.rs:1-5, 198-200; TASK 7763]
• Email: although not asked in the catalogue question, its available label is also false. The six UI rows say there is no mailbox reader. Gmail has an unwired GET-only reader, while the shared send seam is in-process storage; no provider has a shipping send-and-receive path. [CODE apps/service-catalogue.json:33; CODE apps/osl-hub-ui/src/services.ts:592-597; CODE apps/osl-hub/src/shipping_gmail_mailbox_receive.rs:138-199, 230-323; CODE apps/osl-hub/src/protected_mail_seam.rs:385-406; TASK 7768]

The fix is not to soften the word “available.” Make the static catalogue consume the same unavailable state as services.ts, and promote one carrier only after its real two-account receipt exists. [RULINGS.txt:44-54; TASKS 4265, 7763-7774]

Requirements to cut or defer

1. Defer pixel-perfect in-carrier overlays. The ruling requires live-carrier visual comparison and universal appearance self-repair, but that work does not make carriage work and does not stop a wrong send. Use an unmistakable OSL-owned reveal pane for V1. Keep exact app/account/conversation/row binding and refuse on ambiguity; those stop user harm. [RULINGS.txt:129-146, 187-225; 01-FULL-SPEC.md:15, 69-82]

2. Cut the all-six-mail gate. TASK 7768 asks for one six-provider seam before any provider has a shipping send-and-receive path. Build Gmail end to end, reuse the adapter for Outlook, and only then add the IMAP/SMTP providers. Simultaneous breadth has already produced checked tasks backed by memory maps instead of working mail. [TASKS 7768-7774; CODE apps/osl-hub/src/shipping_gmail_mailbox_receive.rs:1-7; CODE apps/osl-hub/src/protected_mail_seam.rs:385-406]

3. Cut browser-composer purity for mail. Official Gmail and Outlook APIs and authenticated IMAP/SMTP provide stronger account, stored-row, and recipient proof than a fragile browser DOM. The product requirement is exact carriage and readback, not reenacting a click on Send. [01-FULL-SPEC.md:69-75, 150-200; TASKS 7769, 7770]

4. Defer Outlook desktop parity. A Graph-backed Outlook carrier proves the protected-mail product. A second UI-specific desktop adapter adds maintenance without preventing harm or a false claim. [01-FULL-SPEC.md:158-164; TASK 7770]

5. Defer universal automatic repair. Detection and fail-closed refusal must stay; automatic selector and visual repair on every carrier can wait. Refusal prevents a wrong destination or false success. Self-modifying UI repair does not. [RULINGS.txt:68-72, 129-146; 01-FULL-SPEC.md:53, 75]

6. Keep only the proof gates that stop harm or a lie. Exact destination binding, no plaintext fallback, stored-output readback, second owner-controlled receiving identity, and an honest unavailable label stay. Native-looking pixels, every surface at once, and duplicate desktop/web implementations do not. Never test by messaging a real third party, and never convert a fixture result into a live receipt. [01-FULL-SPEC.md:15, 35, 69-82; TASK 7760; TASKS 7763-7774]

Recommended build order

Build one vertical Gmail path: OAuth, exact sender account, send word-only MIME cover to a second owner-controlled account, read back the sent body, observe the recipient message, resolve the pointer, and reveal in an OSL pane. Then repeat through Microsoft Graph for Outlook and extract a shared mail contract from two real implementations, not from a BTreeMap. After those work, decide whether user demand justifies Yahoo/AOL/iCloud/Proton and a Signal spike. Keep WhatsApp, Instagram, Messenger, and X visibly unavailable for V1. [01-FULL-SPEC.md:69-82, 150-200; TASKS 7763-7774]