@projectpac/operation-jc-box

An operation adapter for the operation the spec names first: submit named sources to a verified executor, encrypted.

The box is a machine both sides can check and neither side owns. A flow drives the session -- propose a public program, approve it, submit, fetch -- but every step that touches material goes through here, because a flow writing a party input would be a flow holding the principal's data. So the flow writes the input's shape, names the sources that fill it, and this adapter substitutes what data management resolved.

• Nothing sensitive goes back. A submit receipt says how many bytes went, a fetch receipt carries this party's own output, and no receipt ever repeats an input.
• Verification is enforced, not decorative. The remote client checks the box's attestation against pinned measurements and refuses a mismatch; the same client against the same box accepts the real value and rejects a wrong one.
• The party key is its own key. The RSA keypair a box requires of a participant belongs to this adapter, beside it -- it is a different key for a different job than the node's identity.

The verbs are party, propose, view, approve, submit, await and fetch, plus the egress allowlist -- the hosts this principal will let a run reach, refused at propose and again at approve. That allowlist is the one place this adapter says no on its principal's behalf: there is no policy layer behind it, and pac-node/core/data is a placeholder that does nothing. mock mode runs a whole box in-process for tests; dstack, gcp, aws, and nitro are the real verification backends, and the vocabulary is the box's own so a settings file written for one is read by the other.