Takumi Guard setup scripts v0.5.0 add subcommand mode and one-token-per-device deployment
Takumi Guard setup scripts v0.5.0 add five primitive subcommands that let administrators compose custom rollout flows, plus a new one-token-per-device deployment example built on top of them. The v0.4.x positional-argument invocation continues to work unchanged, so existing rollouts upgrade transparently.
Overview
v0.5.0 adds five primitive subcommands to the setup script. Each subcommand performs one step of the previously-monolithic setup flow, so administrators can compose rollouts that match their environment instead of being constrained to the per-(device, user) flow the legacy invocation implements.
| Subcommand | Purpose | API call |
|---|---|---|
precheck [SCOPES] | Report whether anything is configurable on this machine. | No |
discover | Enumerate existing Guard tokens already present in local config files. | No |
verify <TOKEN> | Classify a token against the Guard API as active, revoked, or unknown. | Yes |
issue <USER_IDENTIFIER> | Mint a new token for the given identifier. | Yes |
install <TOKEN> [SCOPES] | Write the token into every package-manager config in scope. | No |
Only verify and issue need bot API credentials, so a wrapper can keep the admin API key out of individual developers' shells while still performing discover and install in those shells. See I/O contract for subcommand mode for the stdout / stderr / exit-code semantics.
The invocation shape of each subcommand:
# precheck -- is anything configurable on this machine? (no API call)
./setup.sh precheck
# discover -- list existing Guard tokens already present in local configs
./setup.sh discover
# verify -- classify a token's status against the Guard API (needs bot creds)
TG_BOT_ID=BTxxxxxxxxxxxxxxxxxxxxxxxxxxx \
TG_BOT_API_KEY=shisho_apikey_xxxxxxxxxxxxx \
./setup.sh verify tg_org_xxxxxxxxxxxxxxxxx
# issue -- mint a fresh token for the given identifier (needs bot creds)
TG_BOT_ID=BTxxxxxxxxxxxxxxxxxxxxxxxxxxx \
TG_BOT_API_KEY=shisho_apikey_xxxxxxxxxxxxx \
./setup.sh issue acme-laptop-042
# install -- write a known token into every in-scope package-manager config
./setup.sh install tg_org_xxxxxxxxxxxxxxxxx
./setup.sh install tg_org_xxxxxxxxxxxxxxxxx npm,pypi
Note: new deployment example for one token per device
The setup scripts shipped so far mint one token per (device, user) pair. On machines that host multiple developer accounts (shared workstations, an MDM-managed administrator account coexisting with a developer's regular account, an IdP-provisioned cloud profile alongside a built-in local account, ...), the consumed license count quickly diverges from the actual number of physical devices.
v0.5.0 includes a new deployment example, built on top of the subcommands above, that mints one token per device instead. The wrapper walks the user profiles on the device in turn, reuses an existing active Guard token if any is found, mints exactly one new token only when nothing usable exists, and then installs the same token for every developer account.
See Deployment Examples: one token per device for the concrete script. The original Deployment Examples: one token per user flow remains available, and both reuse a valid token on subsequent runs, so periodic re-execution from your management tool stays safe with either model.
Note: backward compatibility
Upgrading from v0.4.x requires no action on the administrator's side. The pre-v0.5.0 BOT_ID USER_IDENTIFIER [SCOPES] positional-argument invocation continues to work bit-for-bit, including stdout log lines, exit codes, and backup/rollback semantics. Existing tokens minted under the per-user model remain valid and are reused on subsequent runs. Switching to the one-token-per-device wrapper at any point discovers and reuses an active token already on the device before minting a new one, so no license is wasted during migration.