What the message says

You write it. Message is the whole body, and three things are filled in:

• {name} — the name you chose for that person
• {event} — whatever you called this event
• {photos} — the lines about each picture, one per paragraph

The default reads:

Dear Maggie,

>

Here are your photos from the Christmas party.

>

Maggie and Tom are mid-laugh by the tree.

⚠ A message with no {photos} is refused. Without it the pictures would arrive with nothing said about them, and nothing downstream would notice.

{event} works in the subject too.

What gets sent

One message carrying this person's approved photos — up to fifty of them. Beyond that they receive the rest on the next send, in a second message.

A fresh copy of each picture is made at the moment of sending with its embedded details removed, and that copy is what is attached. Your originals are untouched and are not what travels — a photograph taken at someone's home carries that home's location, and it should not go out with it.

Those copies stay in your Files. They are stored by their contents, so sending the same photo again reuses the same copy rather than making another one; the count grows with the photos you have sent, not with how often you send. Delete them from Files when you want to — deliberately, on the surface where deleting is what you came to do.

⚠ They used to be deleted here, and that was worse. Deleting is the one kind of action Recued asks you to confirm even when you are driving it yourself, so tidying up meant a second approval after every send — raised once the message had already gone, about files you no longer had any decision to make about.

Before it will send

The person needs an email address and a mailbox to send from, and at least one of their photos must be approved. Any of those missing and it stops rather than sending a partial message.

Two numbers to read

Photos attached against what you expected. An attachment over the size limit is dropped before the message is built, so a message can go out successfully carrying fewer pictures than you meant.

One message stays a message

Somebody who appears in thirty photos would otherwise get all thirty in one email. At a realistic few megabytes each that is a hundred-megabyte message, and every mail provider refuses one: Gmail stops at 25 MB, Outlook at 20. Each photo is individually fine, so nothing would have warned you — the refusal arrives from the provider, after Recued has told you the send worked.

So photos are attached until Largest message to build is used up, and the rest wait for the next send. Only the photos that will actually go are copied and re-encoded; the ones held back are not touched until the send that carries them. Recued works out how many will fit by preparing the first one and measuring it, so when the photos are of a piece — which they are, coming off one camera at one event — splitting a batch across several messages costs no more than sending it in one. They stay exactly as they were: still waiting, still attached to that person, picked up the next time you send to them. **Held back for the next send** on the card is how many, and it is not a failure — send again and they go.

⚠ Picture quality re-encodes, and that can make a photo BIGGER. Every attachment is written out fresh at the quality you set (92 by default) with the camera details stripped. A photo that was already saved at a lower quality comes out larger than the file on disk — no sharper, just bigger, because detail thrown away once cannot come back. It matters at the edge: a photo a little under the 3 MB attachment limit can cross it after re-encoding, and an over-limit photo is dropped while the message sends anyway. If you are attaching large photos and the count looks short, lower the quality before suspecting anything else.

⚠ Sent but not recorded should be zero. It means the message went but some records still read as waiting, so a later run would try again. Each message carries a reconciliation key that prevents a duplicate delivery, but fix the records before the next send rather than after.

Not offered to an AI, and why that is not enough on its own

Sending is kept out of the chat and MCP tool catalog. The pack already treats approving a photo as a human act (the review card is closed too); putting someone's picture in their inbox is the larger version of that decision. An AI can still say who is ready to hear from (send-photos); a person presses send.

Be clear about what that buys. Leaving the catalog means an AI is not handed this as a tool — it does not mean the recipe cannot be reached, since a caller that already knows its name can use the generic runner.

Sending always asks first — including when you do it yourself. Recued holds the run at the send and shows you what is about to go out; the message does not leave until you approve it. That is not the ordinary write approval (an ordinary write of yours is never gated); it is a rule specifically about mail crossing out of your trust boundary, and it applies to you and to an AI alike, for different reasons. Measured in mail-send-gate-position.test.ts, which asserts which step holds rather than merely that one did.

⚠ An earlier version of this note said the opposite — that the mail left and the pause landed on the following step. That reading came from a test harness that drives the engine directly and therefore has no approval gate wired at all; an absent gate and an admitting gate look identical from inside a run. Sending is gated. It is kept out of the catalog anyway, because the pack already treats approving a photo as a human act and putting someone's picture in their inbox is the larger version of that decision.