archetech / archon / 29549780023

90%

push

github

feat: return vault items and dmail attachments as resource blocks (#726) (#736)

* feat: return vault items and dmail attachments as resource blocks (#726)

The last two tools returning binary data as base64 inside a private JSON
object now return an embedded resource block. inlineDataFromBuffer is deleted:
no tool returns the private inline shape any more, and it survives only on the
input side, where MCP has no content blocks to offer.

#726 asked two questions and both premises turned out to be wrong.

"No mimeType is available" -- it is. addVaultItem records `type` from
getMimeType (magic-number detection) at write time, and addDmailAttachment
delegates to it, so every item has one; list_vault_items already reports it.
I wrote that claim from getVaultItem's bare-Buffer signature without reading
the write path. The tools now report the stored type rather than re-sniffing
the bytes, so they cannot disagree with list_vault_items about an item.

"Neither has a DID-shaped URI" -- neither has a DID, but both have a DID URL:
an item is keyed by (container DID, name), which is exactly a fragment. One
template covers both tools because a dmail IS a vault -- addDmailAttachment and
getDmailAttachment both delegate to the vault methods. Names allow any
printable character including '#' and spaces, so the fragment is
percent-encoded.

resources/read dereferences those URIs, so they are real rather than
decorative -- emitting a URI nothing can resolve is the problem #725 existed to
fix, and this would have repeated it. The vault-item template MUST register
before the asset one: the SDK returns the first template whose URI matches and
did:cid:{id} matches greedily, so it would otherwise swallow did:cid:vault#item
as id='vault#item'. Pinned by a test on template order.

Callers resolve the container DID once and pass it down, so the URI names a DID
rather than an alias and the keymaster calls skip their own lookups.

Breaking: both tools' result shape changes.

C... (continued)

2951 of 3500 branches covered (84.31%)

Branch coverage included in aggregate %.

25 of 25 new or added lines in 2 files covered. (100.0%)

6153 of 6579 relevant lines covered (93.52%)

834.67 hits per line