skarbiec rename

Invocation#

skarbiec rename <id> <new-id>

Purpose#

Change one item's id while preserving everything that is not the id. Before it existed the only route was get, then set-json under a new id, then delete — a copy wearing a rename's clothes, because that resets revision and history, drops the tags a new id has no previous entry to preserve, and needs the plaintext in hand.

Required inputs and options#

• Requires two positionals, the current id and the new id. There is no command-specific option.

Output and state effects#

• Moves the stored envelope whole under the new key, so item_uid, history, revision, created_at, tags, recipients, management, and the ciphertext itself are the same bytes at the new id; nothing is decrypted or re-encrypted, because the id is a map key rather than part of the sealed payload. An item with no identifier is stamped with one here, since that identifier is what lets a route table or a consumer config work out where the item went. It appends item-renamed and prints ok, from, to, and item_uid.

Refusals#

• Owner-controlled items only, the same bar retag and delete apply: a lifecycle-controlled or externally managed item is refused with use the item's controlling lifecycle instead of direct owner rename, because its controller holds references keyed by the id and this command cannot update them. It also refuses a new id equal to the current one, a new id that is not one exact name of 1 to 128 characters with no NUL, newline or carriage return, a new id that already exists because renaming onto a live item would replace it, an unknown source id, and an item still on the legacy envelope until migrate-v2 has run. The references a rename does break — capability routes, consumer grants, and acquisition bearers in flight — break loudly rather than silently.