skarbiec grant retarget

Invocation#

skarbiec grant retarget <consumer> --from <item> --to <item>

Purpose#

Make a grant follow an item to its new id after rename, or point it at the item that replaced one, without rotating its bearer.

Required inputs and options#

• Requires exactly a consumer, --from naming the item its capabilities name now and --to naming the item they should name. rename and grant list --dangling name the grants that need it.

Output and state effects#

• Rewrites every capability of that grant naming --from to name --to, keeping its action and field; each rewritten capability is parsed again against --to as grant issue parses it, and one that is then already held is kept once. Saves the vault, appends a grant-retargeted journal record naming consumer, from, to and how many moved, and prints ok, consumer, status moved, moved (the new capabilities) and decided_against_vault. A grant holding nothing for --from is answered status absent and the vault is not written. The bearer, the other capabilities and the lifetime stay as they were. POST /v1/operator/grants/retarget takes consumer, from and to. Only a typed concurrent-generation conflict causes a fresh read and reapplication.

Refusals#

• A missing consumer, --from or --to exits 2 with `usage: grant retarget <consumer> --from <item> --to <item>`. Refuses names that are not exact with `grant retarget requires exact consumer, --from and --to names`, the same item twice with `--from and --to both name <item>; there is nothing to move`, a consumer with no grant with `consumer <name> has no grant in <vault>`, a legacy grant that is not v2, and a capability --to cannot take with `<capability> cannot replace <consumer>'s capability on <from>` followed by grant issue's own reason; nothing is written when any capability is refused.