Adopt an older artifact with its history and discussion

An inactive ownership request starts a purpose-bound ownership check for an older consumer artifact. Verified provenance records the snapshot observed by its source owner. It does not copy files, change sharing, activate a writer or make the artifact available through task readers. The existing artifact remains editable through its current owner.

Use your own unrestricted personal write key. The exact first-party consumer bearer is also supported; collaborator, workspace, app, task, restricted and read-only credentials cannot perform this handshake. Reading a request or proof requires write scope too.

1. Run sky artifact adoption request <source> --request-id <stable-id> with a 16–120 character request id. Keep the returned target id.
2. Run sky artifact adoption prepare <source> --target <target> --request-id <stable-id> to bind the current source snapshot.
3. Run sky artifact adoption verify <target>. The result stays inactive. read <target> shows the intent; proof <source> --target <target> --request-id <stable-id> reads the current proof.

Reuse the same request id after an uncertain response. If the content or sharing policy changes, the old proof becomes stale. Run cancel <target> --request-id <stable-id> first, then cancel-source <source> --target <target> --request-id <stable-id>. Create a fresh request with a new id. Retired requests cannot be revived or used to clear a newer request. Cancellation keeps the source unbound; its fence counter may advance on retries. A concurrent stale cancellation may return 409; explicitly re-read before retrying.

The same seven operations have named MCP tools: request_artifact_adoption, read_artifact_adoption, prepare_artifact_adoption, proof_artifact_adoption, verify_artifact_adoption, cancel_artifact_adoption, cancel_source_artifact_adoption. Their public API is documented in the Artifacts reference under /artifacts/adoptions and /consumer/artifact-adoptions.

Activate the explicitly selected file

The inactive handshake above is a prerequisite. Activation is a separate owner action and is default-off (LEGACY_ARTIFACT_ADOPTION); a disabled start is not permission to work around the gate. Existing exact activation requests remain recoverable. These commands describe the source implementation, not a claim that a particular server or published CLI already serves them.

1. Choose a new stable activation request id and run sky artifact activation prepare <target> --request-id <activation-id>. This revalidates and fences the exact source snapshot; late old saves cannot commit through that fence.
2. Run sky artifact activation import <target> --request-id <activation-id> repeatedly while the response is phase: preparing with more: true. Each call imports at most one retained raw revision. Finish when the phase is imported. All retained versions, exact original bytes, restore identities and the common public pin are preserved; staged content is not readable yet.
3. Run sky artifact activation source-forward <source> --target <target> --request-id <activation-id>, then sky artifact activation activate <target> --request-id <activation-id>. Forwarding requires the complete exact import receipt. Activation verifies that permanent source fence before enabling canonical reads and discussion.
4. Use sky artifact inspect <target> for canonical metadata/history and sky artifact original <target> --version <version> --out <path> for exact raw bytes. Existing Library/source identities remain compatible; no task is fabricated.

Use activation read <target>, activation revisions <target>, activation source-proof <source> --target <target> --request-id <activation-id> and source-history to recover status and bounded history. Before import, cancellation closes canonical activation first with activation cancel, then releases the original fence with activation source-cancel. Once imported, finish the same request through forward/activate. Do not switch to a new request or restore the source writer after an uncertain response.

Named MCP tools are read_artifact_activation, prepare_artifact_activation, import_artifact_activation, revisions_artifact_activation, activate_artifact_activation, cancel_artifact_activation, plus original_source_artifact_activation (binary metadata; use CLI/REST for complete raw bytes), prepare_source_artifact_activation, proof_source_artifact_activation, history_source_artifact_activation, forward_source_artifact_activation, cancel_source_artifact_activation. They call /artifacts/adoptions/{targetId}/activation and /consumer/artifact-activations/{sourceId} with the caller's own bearer.

Edit and recover adopted content

sky artifact content prepare <id> --input <json-file> prepares immutable request_id (UUID), base_version, raw_sha256, raw_size_bytes, media_type, site and nullable restored_from. content commit <id> --request-id <uuid> --file <path> sends those exact original bytes. Current edit permission, policy, source claim and base CAS are rechecked at commit. A conflict requires an explicit re-read; there is no silent rebase.

content read <id> --request-id <uuid> --operation status recovers the same result after lost commit/settlement responses. The exact source admission steps also have named content source-reserve, source-claim, source-settle, source-close commands with --target and --request-id. Canonical content close cannot cancel an already committed version. Claimed capacity stays charged until canonical commit is impossible and actual generations are reclaimed; timeout, missing local bytes or failed deletion never releases it.

MCP exposes prepare_artifact_content, read_artifact_content_request, commit_artifact_content, close_artifact_content_request, and reserve_source_artifact_content, claim_source_artifact_content, settle_source_artifact_content, close_source_artifact_content. The unique capacity owner remains the original owner's existing source admission aggregate, including other publishers. The real editor is recorded separately from that owner.

Policy and discussion

Use sky artifact policy read <id> and policy change <id> --input <json-file> or MCP read_artifact_policy / change_artifact_policy. A change contains a stable UUID, current base_policy_version, current base_version and one change (share, place, alias, retire). Only the actual owner may manage policy; ordinary private readers cannot inspect it. Exact workspace incarnation, independent alias revisions/member grants and common public pins remain enforced. Change a public pin only with its previous from_public_version; null follows current. Current policy token receipts can recover matching raw tokens; initially imported source tokens remain held by the source issuer.

Private content readers may read the existing discussion. Only current edit authority may add feedback, reply, resolve or reopen; public links grant no discussion access. Use existing sky artifact comments and named discussion tools. Replies require a parent in the viewed current version. Historical roots remain attached to their version and can still resolve/reopen using the current artifact base_version plus resolution CAS; new replies do not move old threads. Task artifacts retain historical zero/negative safe integer versions; newly adopted source versions stay positive. Discussion never starts an agent or publishes content.

Publisher and sealed public-read proof endpoints are protocol attestations, not user-grant minting operations. Issuer sealing stays private; there is no CLI or MCP operation that manufactures an unsafe public seal.

Find active adopted files with sky artifact list-adopted or MCP list_adopted_artifacts. Optional filters are --limit (1–50), --cursor, --q, --visibility all|only_me|public, --scope all|mine|workspace:<64-hex key>, --folder artifacts|meetings, --kind design_system. The response includes current live permissions, total and next cursor; shared links do not expand the list. Existing task artifact list remains separate. Adopted design systems retain the existing read/token/file-save tools and commands through the canonical content owner.

After explicit owner retirement, use sky artifact reclamation reclaim <id> --request-id <uuid> (MCP reclaim_artifact) to reclaim retained bytes and their existing capacity admissions. Resume the same UUID after any uncertain response; reclamation read / read_artifact_reclamation reports durable progress. Both require the retired owner's write credential. Pending work closes first; actual canonical objects must be deleted and checked before source admission release. Failed or unknown deletion stays charged; the retired file cannot revive.

To inspect only a managed alias under its exact credential ceiling, use sky artifact policy read <id> --alias-id <alias> or MCP read_artifact_policy with alias_id. It returns the current name/content/policy bases and only that alias's policy/token receipts; other placement/grants/tokens stay private. Omitting alias_id requires full owner inspection.

A normal alias change (unify_public omitted/false) also returns a selected-alias receipt. Its null placement/public pin fields are a narrowed view, not a reset of global policy. Never replace whole-file policy with that response. Global/unified changes require full management and return the complete receipt.

Fresh public/shared URL tokens and new alias IDs are generated by the server. Leave alias.id out when creating an alias; supply it only to update an existing alias on this file. The policy input has no public_token or shared_token fields; supplying either is an unknown-field error (400). Existing slots are retained by default; use normal enable/rotation actions for new server-generated URLs. Token output receipts and existing imported links remain available. Each source workspace slug, including Only me/null, has at most one alias; unknown IDs/unification or a move colliding with another alias returns 409. Same-ID updates remain valid.