IEmailSender has no Cc/Bcc — a message with copied recipients cannot be delivered as one mail

[rbuergi]

IEmailSender.SendEmail(toAddress, subject, htmlBody, attachments, delivery) takes ONE recipient and no Cc/Bcc, and SendDocumentDispatch.ExportAndSend therefore sends one mail per recipient. A client mail with a To and seven Cc — the ordinary shape of a business mail — cannot be delivered as the one message the sender approved: the recipients would each get a separate mail with no Cc line, and replies would not reach the copied people. The Graph implementation builds a Message that supports Cc, so the gap is the contract, not the transport.

Ask: an overload (or an EmailMessage record) carrying To, Cc, Bcc, Subject, HtmlBody, Attachments, EmailDelivery, with the no-op and SMTP senders refusing (not silently dropping) Cc they cannot honour. This is what would let Essentials/Email's Send actually deliver — through the user's connected mailbox, with the PDF exports of its attachments — instead of only recording the send, and show the plan (from, to, cc, subject, attachments) before the click.

🤖 Generated with Claude Code

[rbuergi]

Core half in flight: #3493 (paired with #3450 — both change IEmailSender,
so they land as one contract change rather than two cross-repo cycles).

What landed in core

EmailMessage carries the whole envelope — To, Cc, Bcc, Subject, HtmlBody, Attachments,
Delivery — and IEmailSender.SendEmail(EmailMessage) (plus hub.SendEmail(EmailMessage)) sends it
as ONE mail. VisibleRecipients is To ⧺ Cc, de-duplicated case-insensitively, and never Bcc; a
blind address appearing there would be the disclosure the field exists to prevent.

The refusal is the part this issue asked for explicitly, and it is honoured. The default
implementation forwards to the existing single-address overload when the message fits one (To of
exactly one, no copies) — so every sender written before this member keeps serving every call it
could already serve — and otherwise faults with a NotSupportedException naming the counts. It
never delivers a quietly smaller mail: doing so is the same class of defect as stamping an
undelivered mail Sent (#2023).

NoOpEmailSender is the one deliberate exception, and for the reason the issue implies rather than
against it: it delivers nothing to anybody and says so, so there is no smaller message for it to
deliver silently. It accepts the full envelope, names every count in its log line, and still refuses
outright on a mail-enabled-but-unconfigured install. Refusing Cc there would break every local-dev
and test send while protecting a delivery that is not happening either way.

Purely additive — scripts/check-type-forwards.py --base HEAD reports removed: [] (0 public types,
0 public members), so the cross-repo pair gate does not fire.

Numbers, both arms (real monolith mesh, no mocking, no Task.Delay, no .ToTask()):

• fixed shape — 1 send carrying 4 recipients, 3 mutually visible, 1 blind;
• the shape it replaces — 4 sends carrying 1 each, 0 able to see anyone, Bcc
  inexpressible. That is TheOldPerRecipientShape_SplitsOneMailIntoFour, kept as the control that
  gives the first set its meaning;
• making the default silently drop copies fails the refusal test with "Expected value to be OnError
  … but found OnNext" — a smaller success — and crashes AMessageWithNoRecipients_IsRefused.

What remains — in MeshWeaver.Plugins, which builds -warnaserror against a core checkout at
MW_PLATFORM_REF and so cannot compile until the pin carries these members (order:
core → pin → Plugins; this session was fenced from moving any pin):

File	Change
GraphEmailSender.cs	Override SendEmail(EmailMessage) to build ONE Graph Message with ToRecipients/CcRecipients/BccRecipients — the SDK already supports all three, which is why the issue is right that the gap is the contract, not the transport.
SendDocumentDispatch.cs	Replace SendToAll's per-recipient SelectMany with one hub.SendEmail(EmailMessage), and give ExportAndSend cc/bcc beside rawEmails.

That table is committed to Doc/Architecture/SendingEmail, not only here.

The issue's second ask — that Essentials/Email's Send actually deliver, and show the plan
(from, to, cc, subject, attachments) before the click — is now expressible, since the envelope it
would render is a first-class type. It is not built in #3493 and is worth its own issue once the
Plugins half lands.

Staying open until then — #3493 is Refs, not Closes.

[rbuergi]

The core half is merged — PR #3493, merge commit 91ef23179, verified an ancestor of origin/main.

This issue stays open on purpose. The half a person can actually see lives in MeshWeaver.Plugins (SendDocumentLayoutArea, SendDocumentDispatch, GraphEmailSender), which compiles against core at MW_PLATFORM_REF = bbcb22f2 — a pin that does not carry the new members. So closing now would bury the remaining work behind a green checkbox.

Order is: core (done) → the platform pin moves → the Plugins half. The pin move is the maintainer's, and it is the integration test for this change: a dependent that PINS core gets no signal from core's release event, so nothing before the pin bump has compiled the new contract against a real consumer.

[rbuergi]

STAYS OPEN — the core contract is merged and verified; the user-visible half is not delivered and is untracked

Independently measured 2026-09-07 07:2x-07:3xZ from a worktree at origin/main 67bd3d064.

Settled: the core half is on main

$ git merge-base --is-ancestor 91ef23179 origin/main && echo YES
YES
$ git log -1 --format='%H %ci %s' 91ef23179
91ef23179f874b35ee5d2c6c352a0bd1fd7c276a  2026-09-06 22:43:48 +0000
Merge pull request #3493 … fix/3450-3473-email-send-as-three-state-and-copied-recipients

Read back on origin/main — src/MeshWeaver.Mesh.Contract/IEmailSender.cs exists
(git cat-file -e exits 0) and carries IObservable<bool> SendEmail(EmailMessage message) at
L127-148, plus the new src/MeshWeaver.Mesh.Contract/EmailMessage.cs with To / Cc / Bcc,
VisibleRecipients (To ⧺ Cc, Bcc deliberately excluded), AllRecipients, HasCopiedRecipients,
FitsASingleAddressSender and DescribeUnsupportedEnvelope. The default implementation forwards a
single-address message to the old overload and otherwise faults with a NotSupportedException
naming the counts — i.e. it refuses what it cannot honour rather than silently fanning out, which
is the shape this issue asked for.

So the "Ask:" paragraph of this issue is satisfied as a contract.

Not settled: nothing a person can see has changed, and no one is tracking it

src/MeshWeaver.Markdown.Export/ no longer exists in this repository
(git ls-tree origin/main src/MeshWeaver.Markdown.Export/ is empty; only
MeshWeaver.Markdown.Export.Contract remains), so every consumer is in MeshWeaver.Plugins,
behind an MW_PLATFORM_REF pin move. The committed handover in
src/MeshWeaver.Documentation/Data/Architecture/SendingEmail.md → "🚧 The consumers live in
MeshWeaver.Plugins, and land after the pin moves" names exactly two files for this issue:

File (MeshWeaver.Plugins)	Change
src/MeshWeaver.Mail.MicrosoftGraph/GraphEmailSender.cs	Override SendEmail(EmailMessage) to build ONE Graph Message with ToRecipients/CcRecipients/BccRecipients
src/MeshWeaver.Markdown.Export/Handlers/SendDocumentDispatch.cs	Replace SendToAll's per-recipient SelectMany with one hub.SendEmail(EmailMessage); give ExportAndSend cc/bcc parameters

🚨 I searched for a Plugins counterpart and there is none. The only Plugins pull request
referencing #3473 is #1424
("feat(Email): Send really sends…", merged 2026-09-06T23:27:52Z) — and it does not consume the new
contract; it routes around it, in its own words:

Until now Send only stamped the record. The platform's IEmailSender takes one recipient and no
Cc (MeshWeaver#3473), so a client mail with copied recipients could not go through it as one
message. The due-diligence mail on 2026-09-06 went out through a hand-written kernel script; this
PR makes that script the type's own.

So on both portals today, a client mail with a To and seven Cc still cannot leave through
IEmailSender as the one message the sender approved — the opening sentence of this issue is
still true of the running system, and closing this would delete the only record of that.

Proposed re-scope

SendEmail(EmailMessage) has no consumer — GraphEmailSender and SendDocumentDispatch still send one mail per recipient (Plugins half of #3473)

Not doing the rename myself: it changes what the issue is, and the core half's author may prefer
to close this and open a Plugins issue instead. Either is fine — what must not happen is closing it
with nothing on the other side, which is where it stands right now.

Measured 2026-09-07 07:2x-07:3xZ. Artefacts: 91ef23179 (PR #3493),
src/MeshWeaver.Mesh.Contract/IEmailSender.cs:127-148,
src/MeshWeaver.Mesh.Contract/EmailMessage.cs,
src/MeshWeaver.Documentation/Data/Architecture/SendingEmail.md:330-340,
MeshWeaver.Plugins#1424.

[rbuergi]

The Plugins half is written and verified — held on a MEASURED portal condition, not on work

MeshWeaver.Plugins#1431 (15958cec) now carries the consumers this issue's own handover names,
and closes it (Closes Systemorph/MeshWeaver#3473). It stays draft on purpose; the two things
that keep it there are measured below, not assumed.

What is written

file (MeshWeaver.Plugins)	change
src/MeshWeaver.Mail.MicrosoftGraph/GraphEmailSender.cs	overrides SendEmail(EmailMessage), building ONE Graph Message with ToRecipients/CcRecipients/BccRecipients. The single-address overloads become the DEGENERATE CASE of that envelope rather than a second send path, so one place builds the message, one enforces the 4 MB sendMail ceiling and one turns off transport retry.
src/MeshWeaver.Markdown.Export/Handlers/SendDocumentDispatch.cs	SendToAll's per-recipient SelectMany → SendOneMessage; ExportAndSend gains cc/bcc beside rawEmails. A refusal is reported as the sender's own words, never folded into "sent to 3 of 8" — for one message that is not a state that exists.

Bcc addresses are counted in the log line, never named: a log listing blind recipients beside the
visible ones is the same disclosure in a different medium.

The #1424 workaround: its stated reason is dead, and that is now written where it lived

This issue's last comment is right that #1424 routed AROUND the gap, and the reason was compiled into
Essentials/Email/Source/EmailScript.cs — "the platform's IEmailSender takes one recipient and no
Cc (MeshWeaver #3473)" — where it would have outlived the defect and taught the next reader to build
another GraphServiceClient. That paragraph is corrected in #1431.

🚨 But the script is NOT fully removed, and the remaining reason is a real gap, not inertia.
IEmailSender has no DRAFT member at all, so "Save as Outlook draft" — leaving the message in the
person's own Drafts for them to press Send, the shape AGENTS.md requires of an assistant — cannot be
expressed through it. Routing Send through the platform while Save-as-draft stayed on Graph would
fork one plan into two unrelated paths and break that type's stated guarantee, that the plan a reader
sees IS the code that runs. Secondarily, EmailMessage carries bare addresses while that record's
recipients are written Name <address>, and display names belong on a client mail. Closing that
needs a draft seam on IEmailSender, here in core — recorded in
src/MeshWeaver.Mail.MicrosoftGraph/README.md, not only in this thread.

src/MeshWeaver.AI/Data/Skill/share-email.md carried the gap in agent-facing form (a sample with no
cc/bcc) and is corrected too — an agent following that skill would otherwise have kept fanning
out.

Why it is still draft — both conditions measured 2026-09-07 08:0xZ

1. The pin does not carry the seam.

$ git merge-base --is-ancestor 91ef23179 aa40758329216d57dcefc2d8e8a52101efd5f225   # ci.yml MW_PLATFORM_REF
(exit 1)
$ gh variable list --repo Systemorph/MeshWeaver.Plugins | grep MW_PLATFORM_REF
(no rows)                                   # so the ci.yml env default IS the effective pin
$ git rev-list --count aa407583..origin/main
113

The pin is from 2026-09-06 20:27Z, ~2h16m before 91ef23179. So the Mail and Export modules cannot
compile in that repo's CI, and that PR's CI is expected red. The pin is deliberately not moved
inside it: a pin move cannot make it mergeable (condition 2 is independent), and it would drag 113
unrelated core commits into a change set about two email seams.

2. A portal cannot load it yet — the #1430 mechanism (a main run registers the publication,
each instance syncs sources from main's HEAD and compiles them against its RUNTIME core):

portal	running core	carries 91ef23179?
memex-cloud (memex.meshweaver.cloud)	525a1c489	yes
memex (memex.systemorph.com, staff/control)	e36f04c71 — 2026-09-03, 3.0.0-rc9	NO

Merging today would put Mail and Export into compile Error on the staff portal.

So this issue closes when the staff portal rolls

Un-draft #1431 when both portals run a set ≥ 3.0.0-ci.7962, and the merge closes this. Compilation
is already proven against a core worktree at that sealed set (6577052de): Release
-warnaserror, 0 Error(s), 0 Warning(s) on MeshWeaver.Markdown.Export,
MeshWeaver.Mail.MicrosoftGraph and both test projects; 201/201 and 155/155 green.

The guard was checked by MUTATION, not asserted — restoring the fan-out reds exactly the two envelope
tests, naming the numbers:

FAILED ADocumentWithCopiedRecipients_LeavesAsOneMailCarryingThemAll
  Expected collection to contain a single item because a To with two Cc and a Bcc is ONE message
  — the per-recipient shape would have made it four, but found 4.
FAILED SendDeckToContacts_EmailsPdfAttachment_ToUserAndRawAddress
  … but found 2.

🤖 Filed from Claude Code.

[rbuergi]

The symptom is fixed; this issue's literal subject is not — leaving it open

Systemorph/MeshWeaver.Plugins#1431 merged 2026-09-08T11:45:48Z and does deliver the user-facing
outcome: a shared document now leaves as one mail carrying its copied recipients, with
SendDocumentDispatch handling Cc/Bcc (6 references on main) and new tests in
SendDocumentToContactsTest / SendDocumentIdentityPanelTest.

But this issue is titled after the interface, and the interface is unchanged. Measured on core
origin/main, src/MeshWeaver.Mesh.Contract/IEmailSender.cs:

IObservable<bool> SendEmail(string toAddress, string subject, string htmlBody);
IObservable<bool> SendEmail( … attachments … );
// sends with an explicit sender identity …

No cc, no bcc, on any overload. So the fix was made above IEmailSender, in the Plugins
mail path, and every other caller of the core interface — the invitation flow, Blazor click actions,
mesh scripts via HubEmailExtensions.SendEmail — still cannot copy a recipient.

The question this leaves, which is a decision rather than a repair

1. Was routing around the interface deliberate? If copied recipients belong to the document-share
   flow and not to system mail, then this issue is superseded and should close saying so — the
   remainder is a documentation line on IEmailSender explaining why it deliberately has no Cc.
2. Or is the interface still owed the parameter? Then a remainder exists, and it is the one the
   title names.

🚨 Closing this as done on #1431 would be the "five of six" error: the visible symptom resolved
while the stated subject stayed live, and nobody would look again because the issue was green.

Note also that adding a member to a public interface here obliges its implementers — the
Interface additions (implementers declared) gate exists for exactly that — so option 2 is a
cross-repo change and not a one-line addition. NoOpEmailSender and GraphEmailSender are the two
implementers to declare.

[rbuergi]

Closing as completed after verifying BOTH merged halves: core #3493 (91ef23179f874b35ee5d2c6c352a0bd1fd7c276a) and Systemorph/MeshWeaver.Plugins#1431 (669b09a95fb051b8e648c38026a15f004dd4c2a9).

Correction to the preceding comment: the core interface is not unchanged. IEmailSender.SendEmail(EmailMessage) exists, and EmailMessage carries To/Cc/Bcc, subject, HTML body, attachments and delivery identity. Its default implementation refuses envelopes a single-address sender cannot honour instead of dropping copied recipients.

Current Plugins main implements this overload in GraphEmailSender, maps CcRecipients/BccRecipients onto one Graph message, and has SendDocumentDispatch.SendOneMessage call hub.SendEmail(message) once. This is the requested shared interface and transport/consumer implementation, not a workaround above an unchanged interface.

Verified core CI 34064105451 and Plugins CI 34217254000: both completed/success, with core's six test shards and Plugins' four portal-host shards executed successfully. The merged PR records the regression test ADocumentWithCopiedRecipients_LeavesAsOneMailCarryingThemAll and its failing fan-out control.

The separate Outlook-draft/display-name extension described in the mail module README is outside this issue's requested Cc/Bcc envelope. No email was sent as part of this audit.