stratonext 0.0.1__tar.gz

stratonext-0.0.1/.gitignore

@@ -0,0 +1,57 @@
+*.swp
+*.*~
+.DS_Store
+*.pyc
+nupkg/
+.claude/
+.kiro/
+_temp/
+
+# Visual Studio Code
+.vscode/*
+!.vscode/settings.json
+
+# Visual Studio
+.vs/
+
+# Code Rush
+.cr/
+
+# User-specific files
+*.suo
+*.user
+*.userosscache
+*.sln.docstates
+
+# Build results
+[Dd]ebug/
+[Dd]ebugPublic/
+[Rr]elease/
+[Rr]eleases/
+x64/
+x86/
+build/
+bld/
+[Bb]in/
+[Oo]bj/
+[Oo]ut/
+msbuild.log
+msbuild.err
+msbuild.wrn
+
+*.sh
+
+# typescript
+node_modules/
+
+!**/*/scripts/*.sh
+
+!.claude/
+!.claude/skills/*
+settings.local.json
+appsettings.local.json
+
+# cached M2M tokens from local dev/test scripts
+.agent_caller_token.json
+src/platform/tools/db-helper/scripts/query-db.sh
+_AGENT

stratonext-0.0.1/PKG-INFO

@@ -0,0 +1,20 @@
+Metadata-Version: 2.4
+Name: stratonext
+Version: 0.0.1
+Summary: Command-line interface to the StratoNext platform, for coding agents (Claude Code, Kiro, OpenAI) and humans.
+Requires-Python: >=3.14
+Requires-Dist: httpx>=0.28
+Requires-Dist: stratonext-core
+Description-Content-Type: text/markdown
+
+# StratoNext CLI
+
+Command-line interface to [StratoNext](https://app.stratonext.com), for interactive
+agents (Claude Code, Kiro, OpenAI) and humans.
+
+StratoNext is an Agentic Operations Platform: it lets trusted AI operators
+perform production work — projects, tasks, environments, assets, agents,
+approvals — alongside human teams. This CLI drives those resources from your
+terminal or from an agent's tool calls.
+
+Learn more at [www.stratonext.com](https://www.stratonext.com).

stratonext-0.0.1/PROMPT.md

@@ -0,0 +1,48 @@
+# StratoNext agent setup
+
+You are being configured to work with the StratoNext platform. Work through these
+steps in order, then continue with the installed skill.
+
+## 1. Install the CLI
+
+```bash
+pip install stratonext
+```
+
+Confirm it is available: `stratonext --help`.
+
+## 2. Authenticate (requires a human)
+
+Login is browser-based (OAuth2 + PKCE), so you cannot complete it yourself. Ask the
+human to run:
+
+```bash
+stratonext login
+```
+
+This opens a browser, authenticates, and caches credentials in
+`~/.stratonext/credentials`. Wait for them to confirm, then verify:
+
+```bash
+stratonext whoami
+```
+
+If `whoami` returns an identity, you are connected. The CLI targets **prod** by default.
+
+## 3. Install the skill
+
+Fetch the StratoNext skill into the directory your agent loads skills from (for Claude
+Code that is `.claude/skills/stratonext/SKILL.md`):
+
+```bash
+mkdir -p .claude/skills/stratonext
+curl -sSL https://app.stratonext.com/skill.md -o .claude/skills/stratonext/SKILL.md
+```
+
+Then **read that file and follow it**. It defines how to work with StratoNext — the
+core rule is that every piece of work is a task: claim it, move it to `WORKING`, do the
+work, and report the outcome (`stratonext task complete` / `task fail`) with a result.
+
+## 4. You are ready
+
+Use the `stratonext` CLI for all StratoNext work from here on, following `SKILL.md`.

stratonext-0.0.1/README.md

@@ -0,0 +1,11 @@
+# StratoNext CLI
+
+Command-line interface to [StratoNext](https://app.stratonext.com), for interactive
+agents (Claude Code, Kiro, OpenAI) and humans.
+
+StratoNext is an Agentic Operations Platform: it lets trusted AI operators
+perform production work — projects, tasks, environments, assets, agents,
+approvals — alongside human teams. This CLI drives those resources from your
+terminal or from an agent's tool calls.
+
+Learn more at [www.stratonext.com](https://www.stratonext.com).

stratonext-0.0.1/RELEASING.md

@@ -0,0 +1,228 @@
+# Releasing the `stratonext` CLI
+
+How the CLI gets built, versioned, and published to PyPI — and the one-time setup
+you need to do first.
+
+- **Repo:** `stratonext/artemis`
+- **Workflows:** [`.github/workflows/cli-release.yml`](../../../../.github/workflows/cli-release.yml),
+  [`.github/workflows/cli-test.yml`](../../../../.github/workflows/cli-test.yml)
+
+---
+
+## TL;DR
+
+```bash
+# pre-release / testing  → TestPyPI + prerelease GitHub Release
+git tag cli-v1.3.0rc1 && git push origin cli-v1.3.0rc1
+
+# prod             → PyPI + GitHub Release
+git tag cli-v1.3.0   && git push origin cli-v1.3.0
+```
+
+Nothing else. The version comes from the tag. Tests run first; publish only happens
+if they pass. You do **not** publish on every commit — only when you push a tag.
+
+---
+
+## What gets published
+
+`uv tool install stratonext` gives you the CLI, which pulls a chain of three packages —
+all published together (same version, in lockstep):
+
+```
+stratonext        (the CLI)              src/libs/skills/public-stratonext/
+   └── stratonext-core  (skills library) src/agents/tools/stratonext_core/
+          └── stratonext-sdk  (GraphQL SDK) src/libs/sdks/python/
+```
+
+> **Why all three?** `stratonext` imports `stratonext-core`, which imports
+> `stratonext-sdk`. A `uv tool install stratonext` resolves these from PyPI, so they must
+> all exist there.
+
+> **SKILL.md is not published.** The agent skill (`SKILL.md`) is a plain markdown
+> prompt, hosted on a public website — not a pip package. It lives in this repo next
+> to the CLI as the source of truth; copy it to the site when it changes.
+
+---
+
+## How a release flows (`cli-release.yml`)
+
+Triggered by pushing a tag matching `cli-v*`:
+
+| Job | What it does |
+|-----|--------------|
+| **test** | `python -m pytest` for the CLI. **Gate** — nothing publishes if this fails. |
+| **build** | Parses the version from the tag; builds sdist+wheel for all three packages into `dist/<pkg>/` (`sdk`/`core`/`cli`). |
+| **publish** | Matrix leg per package — each uploads its own files to PyPI (or TestPyPI for a pre-release tag) via OIDC, from its own environment. |
+| **github-release** | Creates a GitHub Release with the CLI's wheel+sdist attached. |
+
+**pre-release vs prod** is decided purely by the tag:
+
+| Tag example | Track | Index | GitHub Release |
+|-------------|-------|-------|----------------|
+| `cli-v1.3.0` | prod | PyPI | normal |
+| `cli-v1.3.0rc1` / `...b1` / `...a1` | pre-release | TestPyPI | prerelease |
+
+---
+
+## Versioning
+
+Versions are **derived from the git tag** — you never edit a version in
+`pyproject.toml`. Each of the three packages declares `dynamic = ["version"]` with
+`hatch-vcs`:
+
+```toml
+[build-system]
+requires = ["hatchling", "hatch-vcs"]
+build-backend = "hatchling.build"
+
+[tool.hatch.version]
+source = "vcs"
+raw-options = { tag_regex = '^cli-v(?P<version>\d+\.\d+\.\d+([abrc]+\d+)?)$', fallback_version = "0.0.0" }
+```
+
+- Tag `cli-v1.3.0` → version `1.3.0`. Tag `cli-v1.3.0rc1` → `1.3.0rc1`.
+- **`fallback_version`** keeps local `uv sync` / `uv build` working when your checkout
+  has no release tag — you'll just get `0.0.0` locally, which is fine for dev.
+- In CI, the workflow exports `SETUPTOOLS_SCM_PRETEND_VERSION` from the tag. This is
+  required because `uv build` runs in an isolated tree without `.git`, so `hatch-vcs`
+  can't read the tag on its own. The workflow handles this — you don't have to.
+
+---
+
+## One-time setup (before the first release)
+
+Do this once. It has no code; it's account/settings config on PyPI, TestPyPI, and GitHub.
+
+### 1. Reserve the project names (6 total)
+
+Create empty projects — or use "pending publishers" (step 2) which create them on first
+publish — for all three names on **both** indexes:
+
+| Name | https://pypi.org | https://test.pypi.org |
+|------|------------------|------------------------|
+| `stratonext-sdk` | ✅ | ✅ |
+| `stratonext-core` | ✅ | ✅ |
+| `stratonext` | ✅ | ✅ |
+
+### 2. Register Trusted Publishers (OIDC — no API tokens)
+
+This lets GitHub Actions publish without any stored secret. For **each** of the 6
+project/index combinations:
+
+- **PyPI:** project → *Manage → Publishing → Add a new publisher* (or, before the project
+  exists, *Your account → Publishing → Add a pending publisher*).
+- **TestPyPI:** same flow at https://test.pypi.org.
+
+Owner `stratonext`, repository `artemis`, workflow `cli-release.yml` are the same every
+time. **The environment name is per package** — each package gets its own, because a
+*pending* publisher must be unique on `(owner, repo, workflow, environment)`. A shared
+environment is what triggers *"a pending trusted publisher matching this configuration has
+already been registered for a different project name."*
+
+| PyPI project | Environment on pypi.org | Environment on test.pypi.org |
+|--------------|-------------------------|------------------------------|
+| `stratonext-sdk` | `pypi-sdk` | `testpypi-sdk` |
+| `stratonext-core` | `pypi-core` | `testpypi-core` |
+| `stratonext` | `pypi-cli` | `testpypi-cli` |
+
+> Each environment name **must** match the one the matrix leg runs in (step 3), or PyPI
+> rejects the upload.
+
+### 3. Create the GitHub Environments
+
+Repo → *Settings → Environments → New environment*. Create all six:
+
+- `pypi-sdk`, `pypi-core`, `pypi-cli` — prod releases.
+- `testpypi-sdk`, `testpypi-core`, `testpypi-cli` — pre-release/test releases.
+
+Optional but recommended: on the three `pypi-*` environments, add a **required reviewer**
+(Deployment protection rules). That makes every prod publish pause for a human click — a
+cheap prod gate.
+
+### 4. Confirm public exposure
+
+`stratonext-sdk` and `stratonext-core` become **world-readable** on PyPI. Confirm that's
+acceptable.
+
+---
+
+## Cutting a release
+
+### Pre-release (test the packaged CLI first)
+
+```bash
+git tag cli-v1.3.0rc1
+git push origin cli-v1.3.0rc1
+```
+
+Watch the run in the repo's Actions tab. When it's green, install from TestPyPI and
+smoke-test:
+
+```bash
+# install the pre-release from TestPyPI (extra-index so runtime deps resolve from PyPI)
+uv tool install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ stratonext
+
+# copy credentials
+
+stratonext --help
+stratonext whoami          # targets prod by default
+```
+
+The CLI targets **prod** by default. To smoke-test against a non-prod backend, set the
+`STRATONEXT_*` env vars (see `SKILL.md` → Authentication) before `stratonext login`.
+
+Not happy? Fix, then bump the pre-release number (`rc2`, `rc3`, …) and re-tag.
+
+### Prod
+
+Once the release candidate checks out:
+
+```bash
+git tag cli-v1.3.0
+git push origin cli-v1.3.0
+```
+
+Then verify a clean install from real PyPI:
+
+```bash
+uv tool install stratonext
+stratonext --help
+```
+
+---
+
+## Version numbering
+
+Use [PEP 440](https://peps.python.org/pep-0440/) / semver:
+
+- `cli-v1.3.0` — a normal prod release.
+- `cli-v1.3.0rc1` — release candidate (pre-release → TestPyPI). Also valid: `a1` (alpha), `b1` (beta).
+- Bump `MAJOR.MINOR.PATCH` as usual. Each release must use a **new** version — PyPI
+  refuses to overwrite an existing one.
+
+---
+
+## Troubleshooting
+
+| Symptom | Cause / fix |
+|---------|-------------|
+| Publish job fails with `invalid-publisher` / 403 | Trusted Publisher not registered for that project/index, or the **Environment name** doesn't match. Recheck step 2 & 3. |
+| `A pending trusted publisher matching this configuration has already been registered for a different project name` | You reused one environment across packages. Pending publishers must be unique on `(owner, repo, workflow, environment)` — give each package its own environment (`pypi-<pkg>` / `testpypi-<pkg>`), per step 2. |
+| Wheel version is `0.0.0` | The build didn't get `SETUPTOOLS_SCM_PRETEND_VERSION`. In CI this is set from the tag automatically; locally it means no release tag is present (expected). |
+| `File already exists` on upload | That version was already published. Bump the version and re-tag — you can't reuse one. |
+| Went to PyPI when you wanted TestPyPI | The tag had no `aN`/`bN`/`rcN` suffix, so it's treated as prod. Use a pre-release tag (`rcN`) for TestPyPI. |
+| Tests fail → nothing published | Working as designed. The `publish` job depends on `test`. |
+
+---
+
+## Notes for maintainers
+
+- `src/agents/packages/stratonext_sdk/` is a **generated copy** of `src/libs/sdks/python/`
+  (via `task gen_sdk_python`). Releases build from the canonical `src/libs/sdks/python/`,
+  so the copy doesn't affect published artifacts; it re-syncs on the next codegen run.
+- The CLI targets **prod by default** — there is no separate per-environment build.
+  A pre-release is just an earlier CLI version published to TestPyPI; running it against
+  a non-prod backend is done with the `STRATONEXT_*` env vars. See `SKILL.md` → *Installing*.
+- Headless/CI machine auth for the CLI isn't supported yet; releases are published by
+  the workflow via OIDC, not by a human running the CLI.