Module vault 

The vault family’s ask shape: the draft one vault call parks for the reader’s approval, the answer a person gives it, and the tools those calls name.

No secret value is a field here. The draft carries what a card draws: the tool, the item, the field being revealed or changed, a masked diff, and an attachment’s name and size. Nothing here is a value a person would learn by reading it. The value itself never leaves the process except through the tool’s own result after an approval.

The shared session’s lock state is not frozen into the draft: the core fills VaultDraft::needs_unlock when it builds the card from the live session, so a second parked call re-bases to an ordinary approve card the moment another call unlocks the session.

Re-exports

use serde::Deserialize; 🔒

use serde::Deserialize; 🔒

use serde::Serialize; 🔒

use serde::Serialize; 🔒

use uuid::Uuid; 🔒

use zeroize::Zeroize; 🔒

use zeroize::Zeroize; 🔒

Structs

VaultAskAnswer

The reader’s answer to a held vault call, including the unlock material when the card asked for it.

VaultAttachmentDraft

One attachment a held call names, as the card draws it: the file name and size, and the attachment a replace would remove. The bytes never ride the draft.

VaultDraft

One vault call held for the reader’s approval.

VaultReleased

The material a client released through its platform authenticator, which is what a start sends instead of the master password: the refresh token the enrolment wrapped and the user key itself.

Enums

VaultAskDecision

What the reader decided about a held vault call.

VaultAskEnding

What ended a held vault call, which a view that did not answer it has no other way to learn. The tool result carries the operation’s own outcome; this says only how the card was settled.

VaultTool

One vault tool a held call can name. The wire spelling is the MCP tool name, so the card and the agent’s request cannot disagree about which operation is being approved.