Metadata-Version: 2.4
Name: transilience-cli
Version: 0.1.0
Summary: Command-line access to Transilience product capabilities
Project-URL: Homepage, https://mcp.transilience.cloud
Requires-Python: >=3.12
Requires-Dist: httpx<1,>=0.28
Requires-Dist: jsonschema<5,>=4.26
Requires-Dist: mcp<3,>=2.2
Requires-Dist: pydantic<3,>=2
Description-Content-Type: text/markdown

# Transilience CLI

Use your existing Transilience organization from a terminal. The CLI connects
to the same product-owned capabilities used by MCP; it does not connect directly
to your clouds or contain cloud credentials.

## Install

Python 3.12 or newer is required. With `uv`, one install command selects the
supported Python version automatically:

```sh
uv tool install --python 3.12 transilience-cli
transilience --version
transilience login
transilience whoami
transilience denali inventory-summary
transilience denali findings-summary
transilience denali connections
```

For a one-off run, or an existing `pipx` installation:

```sh
uvx --python 3.12 --from transilience-cli transilience --help
pipx install --python python3.12 transilience-cli
```

Login opens a browser-based organization consent flow. Choose the organization
you already use in the apps. No Clerk key, machine secret, cloud credential or
manual token export is needed. Credentials are stored in a private local file;
no Keychain integration is required. Use `transilience logout` to remove the
local session.

## Discover product capabilities

```sh
transilience tools list
transilience tools describe denali_inventory_summary
transilience tools call denali_inventory_summary --args-json '{}'
transilience --help
transilience denali --help
transilience brandmonitor --help
```

The generic tools commands discover the gateway's current MCP catalog. New
products can appear without duplicating their backend logic in the CLI. Product
availability and authorization depend on your organization and the deployed
gateway, not merely the presence of a command in this package.

Read access is the default. Existing guarded Denali operations require the
appropriate consent, org permissions and explicit confirmation. Connecting and
scanning a cloud does not require customer-cloud remediation permissions.

## Development and configuration

The production command is `transilience`; the compatible development command is
`transilience-dev`. Production and dev sessions remain separate. See
`transilience --help` and `transilience login --help` for OAuth options;
production uses published server configuration by default. The legacy dev
command still requires explicit development environment settings.

To build the public client from a reviewed private checkout:

```sh
python -m pip install 'build>=1.2,<2' 'hatchling>=1.27,<2'
python -m build cli
python scripts/check_cli_distribution.py cli/dist --version 0.1.0
```

Only seven explicitly allowlisted client modules and the reviewed BrandMonitoring
JSON contract are distributed. The backend,
database access, Modal deployment code, machine credentials and provider SDKs
are excluded. Source files remain canonical under `src/transilience_platform`;
there is no second copied CLI implementation. The sdist contains those same
modules and the exact schema resource so it builds without access to the private
repository. Named BrandMonitoring commands remain subject to gateway enablement,
fresh consent, tenant selection and existing product permissions.

## Release maintainers

The `cli-release.yml` workflow is manual, main-only and uses PyPI Trusted
Publishing. Before the first release:

1. Create a pending PyPI Trusted Publisher for project `transilience-cli`, owner
   `transilienceai`, repository `transilience-platform`, workflow
   `cli-release.yml`, environment `pypi`.
2. Restrict GitHub's `pypi` environment to `main`. Add a release reviewer when
   the GitHub plan supports environment reviewers for this private repository.
   Otherwise the reviewed main commit, passing CI, exact release tag and a
   maintainer's manual workflow dispatch provide the release approval. Review
   the public module/resource allowlist and README before dispatching.
3. Merge the reviewed release, create the immutable tag `cli-v0.1.0` on that
   exact main commit, and run the workflow from main with version `0.1.0`.
4. The workflow checks the version, tag/commit binding, complete wheel and sdist
   contents, clean installation and SHA-256 artifacts before the separate
   main-restricted publishing job. No PyPI API token is stored in GitHub.
5. Verify PyPI metadata/digests and a clean `pipx install transilience-cli` from
   the public index before announcing availability. Packaging CI passing is
   not proof that a package has been published.

For upgrades, run `uv tool upgrade transilience-cli` or
`pipx upgrade transilience-cli`. PyPI
versions cannot be overwritten; publish a new reviewed version for changes.
