Problem
microsoft-365@1.0.0 manifest version 0.2.0 declares this output for outlook.mail.send:
outputs:
type: single
schema:
message-id: stringThe command documentation says it calls Microsoft Graph POST /me/sendMail (or /users/{from}/sendMail). Microsoft documents a successful call as 202 Accepted with no response body. The installed agent package contains no alternate contract explaining how a durable message id is produced.
This makes the declared output unprovable and prevents an at-most-once consumer from distinguishing a confirmed provider acceptance from an ambiguous run.
Reproduction
$env:AWARE_HOME='<empty temp directory>'
aware agent install microsoft-365@1.0.0
aware agent describe microsoft-365 --json
Inspect <AWARE_HOME>/agents/microsoft-365/manifest.yaml and commands/outlook.mail.send.md:
- the manifest requires
message-id: string
- the implementation note names Graph
sendMail
- Graph's documented success response is empty
202 Accepted
Reference: https://learn.microsoft.com/en-us/graph/api/user-sendmail?view=graph-rest-1.0
Expected
The runtime command should have a truthful, testable success contract suitable for durable side-effect recording. One of:
- create a draft first, capture its Graph message id, then send it and return that id;
- return a clearly named bounded acceptance receipt that the transport can actually prove; or
- change the schema to express that no message id is available and document how consumers must classify successful-but-unidentified sends.
The manifest, command docs, implementation, dry-run output, and real output must agree.
Observed
The published manifest requires message-id, while the named provider endpoint cannot supply it in the success response. A consumer that requires the declared field will classify every successful Outlook send as indeterminate; a consumer that ignores it loses the durable acceptance evidence the schema promises.
Related downstream work
FloLess RFI connected-mailbox delivery: pawellisowski/floless.app#1090. Gmail's users.messages.send does return a message resource/id, so this mismatch is specific to the Outlook path.
Problem
microsoft-365@1.0.0manifest version0.2.0declares this output foroutlook.mail.send:The command documentation says it calls Microsoft Graph
POST /me/sendMail(or/users/{from}/sendMail). Microsoft documents a successful call as202 Acceptedwith no response body. The installed agent package contains no alternate contract explaining how a durable message id is produced.This makes the declared output unprovable and prevents an at-most-once consumer from distinguishing a confirmed provider acceptance from an ambiguous run.
Reproduction
Inspect
<AWARE_HOME>/agents/microsoft-365/manifest.yamlandcommands/outlook.mail.send.md:message-id: stringsendMail202 AcceptedReference: https://learn.microsoft.com/en-us/graph/api/user-sendmail?view=graph-rest-1.0
Expected
The runtime command should have a truthful, testable success contract suitable for durable side-effect recording. One of:
The manifest, command docs, implementation, dry-run output, and real output must agree.
Observed
The published manifest requires
message-id, while the named provider endpoint cannot supply it in the success response. A consumer that requires the declared field will classify every successful Outlook send as indeterminate; a consumer that ignores it loses the durable acceptance evidence the schema promises.Related downstream work
FloLess RFI connected-mailbox delivery: pawellisowski/floless.app#1090. Gmail's
users.messages.senddoes return a message resource/id, so this mismatch is specific to the Outlook path.