@receiz/mcp-server/docs/mcp-uploaded-artifact-verification.md

MCP server for agents building and verifying Receiz proof-native applications through the canonical Receiz SDK rails.

# Uploaded artifact verification

`receiz_verify_uploaded_artifact` accepts the original selected attachment through
OpenAI's `_meta["openai/fileParams"]` contract. The four declared reference fields
are `download_url`, `file_id`, `mime_type`, and `file_name`; only the first two are
required. Protocol reference: https://developers.openai.com/plugins/reference .

The authenticated hosted endpoint handles connection discovery and uploaded
verification directly, without waiting for the device worker or its request queue.
It reuses `readAuthorizedUploadedArtifact` and the existing canonical offline
verifier. The default platform origins are the exact HTTPS origins shared with
the qualified file-delivery adapter in `RECEIZ_CHATGPT_FILE_ORIGINS`. An explicitly
configured `RECEIZ_ATTACHMENT_DOWNLOAD_ORIGINS` replaces those defaults; remote
requests cannot select an origin or read a server path. OAuth access checks remain transport access,
not proof authority. No signing identity or device workspace is opened.

Hosted and local attachment transport retrieve the capability URL without cookies
or OAuth headers, retaining only bounded received bytes in memory. No artifact file
or custody file is written by URL verification.
The transport SHA-256 and byte length describe the received bytes; neither grants
ownership or proves validity. `verifyReceizOfflineSealedFile` receives that same
buffer and establishes the canonical result. No SDK verifier or signing rule changes.

## Device host configuration

Set `RECEIZ_ATTACHMENT_DOWNLOAD_ORIGINS` to comma-separated **exact HTTPS origins**
confirmed from authorized platform file references. This is host configuration,
never a tool parameter. The shared hosted defaults contain only the exact platform
origins recorded in `RECEIZ_CHATGPT_FILE_ORIGINS`; local runtime deployments must
configure their own origins. An origin outside the deployment configuration fails closed with
`attachment_authorization_failed`. Do not configure wildcard, arbitrary proxy,
local-network or user-controlled origins. Capability URLs must not be logged.

Codex local hosts may instead supply `file` as an absolute staged attachment
path. `RECEIZ_ATTACHMENT_LOCAL_ROOTS` is a host-configured JSON array of exact
staging roots; tool arguments cannot configure it. The plugin launcher defaults
to `codex-remote-attachments` beneath the host temporary directory and, on Unix,
`/tmp/codex-remote-attachments`, matching the observed Codex attachment handoff.
Canonical path containment, regular-file checks, no-follow opens and hard-link
rejection keep attachment transport separate from private device custody.
All filename extensions reach the same canonical verifier with exact original
bytes. Neither transport produces proof authority. Both retain the existing
32 MiB bound and report retrieval failures separately from canonical verdicts.
The plugin forwards both attachment host configuration variables.

The URL-only adapter was introduced in `533dd289b` on September 26, 2026.
The observed Codex pathname handoff returned `attachment_authorization_failed`
before canonical verification. There is no evidence here establishing when a
previous ChatGPT client workflow changed.

Downloads reject redirects, exceed neither 32 MiB nor a 15-second retrieval deadline,
and never substitute thumbnails or rendered images. File names are parser hints,
not device paths. Workspace verification retains existing path and custody bounds.
Download, authorization, file-read and canonical-verifier exceptions return
`verdictObtained: false`; canonical negative verdicts remain canonical results.

The existing full owner runtime and authenticated relay remain available for
custody operations, including Memory Crystal append/open. Explicitly rejected
busy admission permits at most twenty 250 ms waits; accepted jobs are never
replayed. Existing owner slots, exact claims, completion and attempt-result lookup
remain unchanged. Discovery and uploaded verification do not enter this queue.

## Observed image handoff failure, October 5, 2026

The user supplied `IMG_8098.PNG` by AirDrop. Its exact 1,267,138 bytes (1200 × 1680)
have SHA-256
`507e1de9d8d628abd68f6c6237ce4e616fa37aa38936d8fb6809db56cb323bd2`.
The installed Receiz plugin obtained a positive canonical PNG proof and integrity
verdict on those bytes.

The earlier ChatGPT mobile Camera Roll upload delivered a 337,425-byte JPEG
(1097 × 1536), SHA-256
`d2620a3fb5fc7a9384a278424c9d7aee30ae0810cd662f84632cba75c6a98d64`.
The proof was absent. A new ChatGPT web file-picker upload of the same original PNG
delivered 1,399,845 bytes, SHA-256
`cdb234e352a6a376f985b1f126ce9dc011dc31411409dd4e4cecaf4419cc8c40`.
That PNG also lacked the proof bundle chunk. The actual worker result confirms
the latter digest and canonical negative verdict; these are not model-only claims.

Both received representations differ from the valid sealed source. The attachment
adapter applies no conversion. A PNG filename or MIME claim does not establish
preservation of the enclosing proof object. No QR, image appearance, transport hash,
registry response or reseal may substitute for the missing enclosing proof.
The exact client change that introduced conversion is not established here.

### October 6 attachment-routing diagnosis

The exact AirDropped original was verified again with the unchanged canonical
verifier. The same bytes also verified with the filename `IMG_8098.bin` and MIME
`application/octet-stream`. A filename change does not remove embedded proof.

An actual ChatGPT Files upload of a 3,955-byte sealed text proof obtained a
positive canonical verdict with the exact original length and SHA-256. An actual
PNG upload still failed attachment authorization before obtaining a verdict.
For diagnosis only, ChatGPT made a temporary byte-for-byte binary copy of its
selected image and submitted that copy through the existing file parameter.
This reached canonical verification and reported the same 1,399,845-byte PNG
representation and digest recorded above, with a missing-proof negative verdict.
The temporary copy did not restore proof already removed from the received image.

That explicit diagnostic establishes a working byte handoff; it does not qualify
automatic routing from a short image-verification request. The hosted adapter's
authorization failure now reports only reference type/shape and field-presence
booleans. It never echoes file IDs, client paths, capability URLs, unknown field
names or artifact bytes. This allows the actual handoff failure to be diagnosed
without widening attachment access or opening signer custody.

A later original-image invocation returned `UNREGISTERED_FILE_REFERENCE` from
ChatGPT's file-reference conversion before plugin execution. Hosted tool discovery
now explains this client boundary and directs an assistant with authorized
selected-byte access to make and check a temporary binary transport copy. The
same instructions apply after a received bare file ID, client-path failure or
platform file-object authorization failure. A fresh ordinary PNG request on
October 6 still failed with a platform file object. An explicit byte-copy handoff
then obtained a canonical negative verdict for the exact received bytes, which
were missing the embedded proof. Automatic instructions now attempt that
read-only handoff once before reporting an authorization failure. This does not
restore proof stripped by the client; fresh short-prompt qualification remains
required.
No server path, caller-supplied origin, new verifier, signer or proof is admitted.
Actual short-command acceptance remains required after tool metadata refresh.

Separately, an initialize request at 11:26:30 ET waited until 11:35:30 for the Mac
worker. The Mac entered maintenance sleep at 11:24:59 and woke at 11:35:23.
This establishes the unnecessary device wait for discovery; it does not establish
that the canonical verifier timed out. `oidcResource.test.ts` now requires discovery
and positive/negative canonical uploaded verification to work while device queue
storage is unavailable. Existing private device signer custody remains unchanged.

## Full hosted runtime

The selected deployment is the existing full nonfinancial plugin on Receiz
infrastructure, with ChatGPT as frontend. The smaller source-only hosted candidate
was removed before deployment. Discovery preserves every canonical marketplace
name, including Memory Crystal append/open, private AI subjects and SDK application
workflows. A larger catalog does not qualify missing execution prerequisites.

See [the full deployment contract](integrations/receiz-hosted-full-runtime.md).
The thin Node service composes the existing genuine Identity Seal admission,
original owner signer, source workspace, durable subject store and full canonical
relay. It does not enroll a new signer or replace the identity with OAuth.
Private custody relocation requires authorization and an available durable host.
The primary owner's explicitly approved original custody was relocated, admitted,
qualified after restart, and promoted on the existing Receiz infrastructure.
That qualification does not provision custody for a different owner.

Saving reuses the canonical owner-runtime private chunk handoff. The existing
branded Receiz proof card checks complete bytes, uses ChatGPT's optional file API,
and checks the returned file bytes before reporting byte preservation. It never
signs or repeats a history append and adds no proof storage service. Supabase is
not used by canonical verification or SDK sealing. The card does not embed Offline
Studio or execute a sealer. The primary user confirmed creation and original-file
download on iPhone with the v22 save flow. ChatGPT Library UI persistence and
image-upload proof preservation remain separate acceptance boundaries; a returned
HTTPS link alone does not establish them.

## Owner-runtime offline sealing handoff

`receiz_offline_seal_file` accepts a `file` input that reuses the exact authorized
byte retrieval above and passes those bytes to the existing device-held SDK
offline sealer. Its `text` input supplies exact UTF-8 bytes for a response or bounded
transcript. Neither input path accepts an owner claim, signing key, temporal
override, or model-chosen download origin. After one-time canonical enrollment,
both operations seal and verify without network access, then write a new private
proof object in the configured device workspace. Source transport hashes are
consistency evidence beneath the sealed artifact. Text supplied by a model
does not prove authorship or completeness of a chat history.

The MCP result returns the saved device path, digest-bound `receiz:file:`
reference and canonical verification. The existing device material host
reopens that reference against exact file bytes and verifies the enclosing
artifact before use; the reference itself grants no authority. On the native
ChatGPT connection, the existing branded proof card calls
`receiz_offline_artifact_chunk` for bounded canonically verified segments under the
same authenticated owner. It checks their offsets and complete artifact SHA-256,
then hands the exact binary file to ChatGPT's optional file-library API. Raw
segments remain in component-only MCP metadata. A delayed result is inspected by
exact attempt; signing and Crystal append are never repeated for delivery.
Successful sealing alone does
not prove delivery or download. A single ChatGPT
request can generate an image and seal it only when the generated original is
provided to the tool as an authorized file object. A sealed image is a proof
object; a Memory Crystal additionally requires complete carried state, not
merely a rendered image or model summary.

`receiz_offline_crystal_append` builds an intelligence-source Memory Crystal
from one verified sealed source and an optional complete predecessor. The
successor carries exact source and predecessor bytes, stable identity, signer
continuity, canonical history and a local KKS proof. `receiz_offline_crystal_open`
verifies that complete chain before returning a bounded source projection.
The trusted-host `readVerifiedReceizOfflineCrystalSources` API supplies exact
verified bytes to another intelligence runtime without putting them in model
output. This contract is separate from Receiz Mind's desktop-observation
Crystal parser. Creation retains private local custody; it does not append to
a public profile or sync globally.

## Remaining live acceptance

### Everyday commands and execution location

The marketplace skill and tool descriptions route ordinary requests in the
user's language. "Verify this" selects uploaded or workspace verification;
"seal this" and "Receiz this" select the exact source; "remember this" composes
Memory Crystal append/open under the same admitted signer. The user need not
supply a technical prompt. Source ambiguity requires one short source question.
A bare Record Moment request still requires its actual existing Record primitive
adapter; never turn the request text into a fabricated observation.

Execution location must be reported exactly. After the full worker is deployed,
its SDK logic executes on Receiz infrastructure. Installing the connection does
not install Node or private signer custody on iPhone. No embedded Offline Studio
is part of the repair. The canonical SDK, MCP and AI skills remain implementation;
exact Identity Seal admission and enclosing artifact verification retain authority.

Live language acceptance must use short English and translated requests,
including exact uploaded bytes, a sealed response and a Crystal append. Test with
the Mac worker stopped and reopen the existing Crystal after host restart. Native
file delivery must be qualified through ChatGPT. Metadata validation alone does
not prove model selection, mobile execution or preservation of original bytes.

Refresh ChatGPT tool metadata after deployment. Confirm an actual platform download
origin without copying its signed URL into logs. Test the
same original artifact through workspace and uploaded routes, comparing byte count,
SHA-256 and canonical results. Repeat on ChatGPT web and iPhone. Test altered signed
content, a proof-stripped image, an expired reference and a sleeping device. Unit
tests do not establish mobile acceptance. The image upload handoff remains failing
until ChatGPT supplies the exact original sealed bytes. The timeout repair alone
does not restore proof removed by the platform.