Feat/cli extended functionality

[stanlou]

Description

This PR extends the Proto-Kit CLI with new commands for environment setup, bridge , settlement deployment, and explorer management.

New Commands

Environment Management

env:create

• Creates a new environment configuration with an interactive guided wizard
• Example: proto-kit env:create

Bridge Operations

bridge:deposit <tokenId> <fromKey> <toKey> <amount>

• Deposits tokens to the bridge
• Parameters:
  • tokenId - Token identifier
  • fromKey - Sender's private key (or environment variable name)
  • toKey - Recipient's public key (or environment variable name)
  • amount - Amount to deposit (in whole units)
• Example: proto-kit bridge:deposit 1 SENDER_KEY RECIPIENT_KEY 100

bridge:redeem <tokenId> <toKey> <amount>

• Redeems tokens from the bridge
• Parameters:
  • tokenId - Token identifier
  • toKey - Recipient's public key (or environment variable name)
  • amount - Amount to redeem
• Example: proto-kit bridge:redeem 1 RECIPIENT_KEY 100

bridge:withdraw <tokenId> <senderKey> <amount>

• Withdraws tokens
• Parameters:
  • tokenId - Token identifier
  • senderKey - Sender's private key (or environment variable name)
  • amount - Amount to withdraw
• Example: proto-kit bridge:withdraw 1 SENDER_KEY 100

Settlement Deployment

settlement:deploy

• Deploys settlement contracts
• Example: proto-kit settlement:deploy

settlement:token:deploy <tokenSymbol> <feepayerKey> <receiverPublicKey> [mintAmount]

• Deploys custom fungible tokens for settlement
• Parameters:
  • tokenSymbol - Symbol for the token (e.g., "USDC")
  • feepayerKey - Private key for paying deployment fees
  • receiverPublicKey - Public key to receive minted tokens
  • [mintAmount] - Amount to mint initially (default: 0)
• Example: proto-kit settlement:token:deploy USDC FEEPAYER_KEY RECEIVER_KEY 1000

Lightnet Utilities

lightnet:wait-for-network

• Waits for the lightnet network to be ready before proceeding
• No positional parameters
• Example: proto-kit lightnet:wait-for-network

lightnet:faucet <publicKey>

• Sends MINA from the lightnet faucet to an account
• Parameters:
  • publicKey - Destination public key (or environment variable name)
• Example: proto-kit lightnet:faucet B62qnzbXQcUoQFnjvF4Kog6KfNsuuSoo7LSLvomPeak2CLvEYiUqT

lightnet:initialize

• Complete lightnet setup: waits for network, funds test accounts, deploys settlement
• No positional parameters
• Example: proto-kit lightnet:initialize

Developer Tools

generate-keys [count]

• Generates private/public key pairs for development
• Parameters:
  • [count] - Number of key pairs to generate (default: 1)
• Example: proto-kit generate-keys 5

explorer:start

• Starts the explorer UI
• No positional parameters
• Options:
  • -p, --port - Port to run on (default: 5003)
  • --indexer-url - GraphQL endpoint URL for the indexer
• Example: proto-kit explorer:start -p 3000 --indexer-url http://localhost:8081/graphql

All commands that interact with environment variable can be handled through two options:

Option 1: --env-path (File-based)

Loads environment variables from a .env file

proto-kit settlement:deploy --env-path ./my-config/.env

Option 2: --env KEY=value

Passes environment variables directly as command-line arguments. Can be used multiple times.

proto-kit settlement:deploy --env PROTOKIT_SETTLEMENT_CONTRACT_PRIVATE_KEY=EK... 

closes #353

[rpanic]

let's change this to protokit. I know I'd get really mad about that dash in the middle :)

[rpanic]

So - I don't really like the structure of this file - it's just a long spaghetti of commands.
We should find a pattern that allows this to be structured in a more modular way.
An idea would be that every file (command) implements a interface with a function command<T, R>(argv: Argv<T>): Argv<R> and internally calls return argv.command(....)
Then this file would only collect all those implementations and iterate over them

[rpanic]

So I had imagined this as a bit more reusable. Something like protokit run deposit where run says "execute a script" and deposit is the name of the script.
Where the script can either be one of our predefined scripts or a user-supplied one from the starter kit.
Now to realize this we have a few tools available that yargs gives us:
We can do nested commands: https://github.com/yargs/yargs/blob/main/example/nested.mjs
We can also let yargs go through the directories automatically and scaffold the command structure: https://github.com/yargs/yargs/blob/main/example/command_hierarchy.mjs
Some combination of this would be the most intuitive, create a mechanism to structure this on the framework side and then plug in the starter-kit side into the same mechanism

[rpanic]

More information on the folder stuff: https://github.com/yargs/yargs/blob/main/docs/advanced.md#providing-a-command-module

[rpanic]

The namings like we talked