[Feat]: The CLI offers operations a name cannot support, and fails only after the user has signed

Component

Other

Priority

P1

Summary

register, transfer, delegate and release are offered on every name regardless of whether the chain will accept them. When it will not, the user finds out after committing or signing, as a decoded revert rather than a refusal.

Three cases today, and they recur for the same reason: a name's provenance (minted through the gateway, granted from the whitelist, registered publicly) and its lifecycle phase (live, released and redeemable, released and reclaimable) now determine which operations are legal, and the CLI is blind to this.

• Registration inside a redeem window. #244 added a phase after release in which only the previous holder may act, and made DotnsRegistrar.available report false throughout, precisely so no registrant burns a commit-reveal cycle. redeem appears nowhere in packages/cli/src/, so a user still starts the cycle and fails at reveal.
• Transfer or delegate of a soulbound name. Once #212 lands, gateway provenance makes a name non-transferable. Nothing in packages/cli/src/cli/transfer.ts reads provenance, so both commands will fail late with a decoded revert instead of saying the name cannot move.
• Release of a name with no escrow position. Broken today: gateway and whitelist names carry no position, so releaseName submits an approve and only then reverts.

Proposal

Every command that can be refused should check before it submits, and say what it found. Whether that means one shared read or a check per command is up to the implementation.

• Release lifecycle. Expose redeem, report the three phases: redeemable by the holder, awaiting the window, reclaimable by anyone.
• Release with no escrow position. Refuse. Whether a position exists is a fact rather than a policy, and attempting leaves an approval on chain before the release reverts. Broken today for gateway and whitelist names.
• Provenance on transfer and delegate. Warn rather than refuse. #212 has not settled whether soulbound covers full-person names as well as lite identities, or whether a governance or recovery path exists, so a hard refusal would encode an undecided rule and block any exception later added on chain. A failed transfer is one reverted transaction with no residue, so attempting is cheap.

Worth checking with #212. An isTransferable(node) view would let clients refuse safely instead. If that lands, this item becomes a refusal like the other two.

Acceptance criteria

• No path submits an approve or a commitment for an operation the contract already reports as impossible.
• A refusal or warning states why, and where there is one, the time it changes.
• The CLI refuses only on answers the contracts publish, not on rules it re-implements; anything requiring the CLI to apply its own rule warns and lets the user proceed.