vortex-cli 6.0.0__tar.gz → 6.2.0__tar.gz

{vortex_cli-6.0.0/vortex_cli.egg-info → vortex_cli-6.2.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: vortex_cli
-Version: 6.0.0
+Version: 6.2.0
 Summary: Vortex CLI
 Author-email: Jordan Amos <jordan.amos@gmail.com>
 License: MIT License
@@ -150,15 +150,15 @@ For a full list of commands see `--help`.
 - `code`: Open the workspace in Visual Studio Code (`-s <server>` opens that server's own workspace with exactly its jars on the Java classpath).
 - `use`: Set the default server so you don't need to pass `--server` on every command. e.g. `vortex use production`
 - `list` (or `ls`): List Puakma Applications on the server or cloned locally. (`ls` is an alias for `vortex list --local`)
-- `clone`: Clone Puakma Applications and their design objects into the workspace. Apps can be referenced by ID (`vortex clone 13`), by TemplateName (`vortex clone bettrackr_app`), or by group/name (`vortex clone bettrackr/app`). A bare application group clones **every** application in it (`vortex clone BetTrackr`) - all optionally server-qualified (`dev:13`, `dev:bettrackr/app`, `dev:BetTrackr`). See [Cloning a whole group](#cloning-a-whole-group).
+- `clone`: Clone Puakma Applications and their design objects into the workspace. Apps can be referenced by ID (`vortex clone 13`), by TemplateName (`vortex clone bettrackr_app`), or by group/name (`vortex clone bettrackr/app`). A bare application group clones every active, non-inherited application in it (`vortex clone BetTrackr`; add `--all`/`-a` for the disabled and inherited ones too) - all optionally server-qualified (`dev:13`, `dev:bettrackr/app`, `dev:BetTrackr`). `--reclone` re-clones what is already cloned: every server's clones, or one server's with `--server`. See [Cloning a whole group](#cloning-a-whole-group).
 - `watch`: Watch the workspace for changes to Design Objects and automatically upload them to the server each app was cloned from. Watches all servers at once unless `--server` is given.
 - `clean`: Delete the locally cloned Puakma Application directories in the workspace.
   Takes optional `APP_ID`s to clean just those clones (all of the server's, if none are
-  given). Refuses to delete a clone holding local changes the server doesn't have -
-  naming each file - unless `--force` is given. Verifying that asks the server for its
-  design element hashes, so a non-forced `clean` needs a reachable `backend=gateway`
-  server; a clone it can't verify is refused, not silently deleted (`--force` needs no
-  network).
+  given). Deletes immediately and needs no network - there is no undo. With `--check`
+  it first asks the server for its design element hashes and refuses to delete a clone
+  holding local changes the server doesn't have, naming each file; that needs a
+  reachable `backend=gateway` server, and a clone it can't verify is refused rather
+  than silently deleted.
 - `config`: View and manage configuration. `--check-gateway` reports the agent gateway negotiation and which gateway roles your identity holds.
 - `log`: View the server log.
 - `status`: Show the server status - via the agent gateway when available, otherwise the raw console `status` output.
@@ -176,7 +176,6 @@ For a full list of commands see `--help`.
 - `schema`: Manage the Puakma data dictionary (PMATABLE/ATTRIBUTE): record table/column definitions and print the DDL to run by hand. Never executes DDL.
 - `compile` (or `build`): Compile an application's Java Design Objects into `zbin/` using the Eclipse compiler (ecj).
 - `libs`: Show or refresh the per-server Java library cache (each server's `puakma.jar` and shared libraries, downloaded from the server itself).
-- `agent`: Generate agent/editor support files (CLAUDE.md, Puakma skills, code snippets) in the workspace.
 - `docs`: Open the Tornado Server Blackbook.
 - `execute`: Execute a command on the server.
 
@@ -188,11 +187,16 @@ For a full list of commands see `--help`.
 vortex clone 13                 # by ID
 vortex clone bettrackr_app      # by TemplateName
 vortex clone bettrackr/app      # by group/name
-vortex clone BetTrackr          # every application in the BetTrackr group
+vortex clone BetTrackr          # every active application in the BetTrackr group
+vortex clone -a BetTrackr       # ... including its disabled and inherited ones
 vortex clone dev:BetTrackr      # ... on the 'dev' server
 vortex clone --group BetTrackr  # explicitly a group, never a TemplateName
 ```
 
+A group clone skips disabled and inherited applications (the ones `vortex list`
+hides by default) unless `--all`/`-a` is given. An application you name outright -
+by ID, TemplateName or `group/name` - is always cloned, whatever its state.
+
 Groups are matched the way `vortex list --group` matches them - a
 case-insensitive substring - except that an exact (case-insensitive) group name
 always wins, so cloning `BetTrackr` never drags in `BetTrackrLegacy`. If a
@@ -202,8 +206,8 @@ than cloning the lot.
 A bare word is looked up as **both** a TemplateName and a group. In the rare
 case that it is genuinely both, vortex refuses to guess: use `--group NAME` for
 the group, or the ID / `group/name` for the single application. Every flag
-(`--reclone`, `--get-resources`, `--open-urls`, `--timeout`, `--server`) applies
-to group clones as it does to single apps.
+(`--reclone`, `--all`, `--get-resources`, `--open-urls`, `--timeout`, `--server`)
+applies to group clones as it does to single apps.
 
 ### Working with Multiple Servers
 
@@ -303,7 +307,10 @@ backend = gateway            ; default is 'soap', which never contacts the gatew
 
 With `backend = gateway`, `watch`/`push` uploads, `delete`, `log`, `status`, `db`, `execute`
 and the journal commands route through it, and `agenda`, `pull`, `render` and `undo` become
-available. Check what you are talking to and what you may do:
+available. Everything the gateway does not offer goes to the **webdesign vortex API** (the
+JSON action served by `system/webdesign`) - see [SOAP-free on backend = gateway](#soap-free-on-backend--gateway).
+A `backend = gateway` server never talks to SOAPDesigner at all. Check what you are talking
+to and what you may do:
 
 ```
 vortex config --check-gateway -s dev
@@ -313,8 +320,9 @@ vortex config --check-gateway -s dev
 identity lacks the required role) is reported as an error - vortex never quietly retries the
 same operation over SOAP, because that would let anyone with SOAP access bypass every role,
 journal and guardrail above. Likewise `backend = soap` never contacts the gateway. The one
-deliberate exception is the gateway application's *own* deployments, which always use SOAP so
-that a broken gateway deploy never needs the gateway to fix itself.
+deliberate exception is the gateway application's *own* deployments, which never go through
+the gateway (webdesign on `backend = gateway`, SOAP on `backend = soap`) so that a broken
+gateway deploy never needs the gateway to fix itself.
 
 The gateway application is **not bundled with this CLI** - deploy it to a server with
 `vortex export` / `vortex import`, then run its `Setup` scheduled action. It ships its own
@@ -326,6 +334,55 @@ the running server documents its own endpoints, roles and setup steps.
 > grant itself any role. Keep webdesign access for operators; agent identities should not have
 > it.
 
+### SOAP-free on `backend = gateway`
+
+SOAPDesigner is legacy. On a `backend = gateway` server the commands the gateway does not
+cover use the JSON API of `system/webdesign`'s `vortex` action instead - with the same
+credentials, and the webdesign app's own ACL. SOAP is used only when a server is explicitly
+`backend = soap`. The data dictionary (`schema`, `db --list/--schema`) is the exception that
+proves the rule: the gateway's `dictionary` endpoint runs that same webdesign `vortex` action
+server-side behind `GatewayDBRead`/`GatewayDBWrite`, so an agent identity with no webdesign
+access gets a clean role answer rather than a login page, and a change to `vortex.java`
+needs no change to the gateway.
+
+| Command | `backend = gateway` | `backend = soap` |
+|---|---|---|
+| `push`, `watch` (modify), `compile --upload` | gateway `upload` (journalled); the gateway app itself: webdesign `PUT design` | SOAP `uploadDesign` |
+| `watch` (create / delete) | webdesign `POST` / `DELETE design` | SOAP |
+| `delete` | gateway `delete` (journalled); the gateway app itself: webdesign | SOAP |
+| `copy`, `new object` | webdesign `POST`/`PUT design`, `PUT design/params` | SOAP |
+| `new app` | webdesign `POST vortex` | SOAP `saveApplication` |
+| `new keyword` | gateway `keyword` (upsert) | SOAP `saveKeyword` |
+| `schema`, `db --list`, `db --schema` | gateway `dictionary` (webdesign's `database`/`table`/`column` routes run server-side; `GatewayDBRead`/`GatewayDBWrite`) | SOAP SQL + `savePuakma*` |
+| `export` | webdesign `ExportPMX` action | SOAP `downloadPmx` |
+| `import` | **still SOAP** - webdesign has no import route yet | SOAP `uploadPmx` |
+| `db --sql`, `list`, `log`, `execute`, `status`, `clone`, `pull` | gateway | SOAP |
+
+Where the webdesign API behaves differently from SOAP, the CLI compensates so the commands
+behave as they did. The differences that remain visible:
+
+- **Design element writes are whole-row.** The CLI reads the row back first and re-sends what
+  it does not model (the other blob, `Options`), so a `DATA`-only upload never wipes source.
+  One consequence: every write is one extra `GET`.
+- **Renaming with `new object --update --name` does not rewrite references.** SOAP's
+  `updateDesignObject` also updated design params in the app that referred to the old name;
+  the webdesign route does not. Fix `OpenAction`/`ParentPage`-style params by hand after a rename.
+- **`schema` cannot record `--default`, `--position` or the column half of `--ref`.** The
+  webdesign column write has no `DefaultValue`/`Position`/`RefColumn` fields (SOAP's
+  `savePuakmaAttribute2` had them). `--default`/`--position` are refused with a message;
+  `--ref TABLE.COLUMN` records the table and warns. Updates leave existing values untouched.
+  Extend `POST`/`PUT .../column` in webdesign's `vortex.java` to lift this.
+- **Every write flushes the application's design cache**, where SOAP flushed one element.
+- **No per-application `Developer` role check** - the webdesign app's ACL is the boundary. An
+  identity that can reach `system/webdesign` can edit every application through it.
+- **`db --list` orders by table name** (SOAP's `SELECT DISTINCT` had no order); `--schema`
+  output is identical.
+- **Database-name resolution is app-scoped.** `schema`/`db --list` find the connection whose
+  dictionary holds the tables (as SOAP did by `pmatable` count), asking locally cloned
+  applications first and scanning the server inventory only if none of them has it.
+- **`import` remains SOAP** on every backend until webdesign gains a PMX import route
+  (`SaveImportPMX` is a multipart UI form, not an API).
+
 ### Interactive Wizards
 
 Run `vortex new object` or `vortex new app` without any flags to launch a step-by-step wizard:
@@ -421,22 +478,7 @@ vortex schema mydb --add-column invoice customer_id --type BIGINT --ref customer
 vortex schema mydb --ddl invoice    # print CREATE TABLE from the dictionary
 ```
 
-### Agent Support Files
-
-`vortex agent` copies bundled support files into the workspace `.vscode` directory so they are
-included in the generated code-workspace: an `AGENTS.md` with Puakma ground rules for coding
-agents (including pointers to the bundled Blackbook v2 architecture reference), a `CLAUDE.md`
-that points Claude Code at `AGENTS.md`, a `.claude/skills/` library covering Puakma development
-and the vortex workflow, and a `vortex.code-snippets` file with common Puakma Java/HTML
-snippets. Existing files are never overwritten, so they are safe to customise. These files are
-also generated automatically on `vortex --init` and before `vortex code` opens the workspace.
-
-The guidance is backend-aware: on a `backend = gateway` server the skills teach the explicit
-`vortex compile` + `vortex push` deploy loop (journaled, `undo`-recoverable, no workspace lock),
-and the `vortex watch` save-to-deploy loop is scoped to `backend = soap`. Because existing files
-are never overwritten, workspaces generated before 6.0.0 keep their old watch-centric copies -
-delete a file (or the `.claude/skills` directory) and re-run `vortex agent` to pick up the
-current version.
-
-Workspaces created before AGENTS.md existed keep their full `CLAUDE.md` (existing files are
-never touched); the new `AGENTS.md` is simply added alongside it.
+On a `backend = gateway` server the dictionary is reached through webdesign's vortex API via
+the gateway's `dictionary` endpoint (`GatewayDBRead` to read, `GatewayDBWrite` to change).
+That API cannot record `--default` or `--position` (refused) nor the column half of `--ref`
+(warned) - see [SOAP-free on backend = gateway](#soap-free-on-backend--gateway).

{vortex_cli-6.0.0 → vortex_cli-6.2.0}/README.md

@@ -106,15 +106,15 @@ For a full list of commands see `--help`.
 - `code`: Open the workspace in Visual Studio Code (`-s <server>` opens that server's own workspace with exactly its jars on the Java classpath).
 - `use`: Set the default server so you don't need to pass `--server` on every command. e.g. `vortex use production`
 - `list` (or `ls`): List Puakma Applications on the server or cloned locally. (`ls` is an alias for `vortex list --local`)
-- `clone`: Clone Puakma Applications and their design objects into the workspace. Apps can be referenced by ID (`vortex clone 13`), by TemplateName (`vortex clone bettrackr_app`), or by group/name (`vortex clone bettrackr/app`). A bare application group clones **every** application in it (`vortex clone BetTrackr`) - all optionally server-qualified (`dev:13`, `dev:bettrackr/app`, `dev:BetTrackr`). See [Cloning a whole group](#cloning-a-whole-group).
+- `clone`: Clone Puakma Applications and their design objects into the workspace. Apps can be referenced by ID (`vortex clone 13`), by TemplateName (`vortex clone bettrackr_app`), or by group/name (`vortex clone bettrackr/app`). A bare application group clones every active, non-inherited application in it (`vortex clone BetTrackr`; add `--all`/`-a` for the disabled and inherited ones too) - all optionally server-qualified (`dev:13`, `dev:bettrackr/app`, `dev:BetTrackr`). `--reclone` re-clones what is already cloned: every server's clones, or one server's with `--server`. See [Cloning a whole group](#cloning-a-whole-group).
 - `watch`: Watch the workspace for changes to Design Objects and automatically upload them to the server each app was cloned from. Watches all servers at once unless `--server` is given.
 - `clean`: Delete the locally cloned Puakma Application directories in the workspace.
   Takes optional `APP_ID`s to clean just those clones (all of the server's, if none are
-  given). Refuses to delete a clone holding local changes the server doesn't have -
-  naming each file - unless `--force` is given. Verifying that asks the server for its
-  design element hashes, so a non-forced `clean` needs a reachable `backend=gateway`
-  server; a clone it can't verify is refused, not silently deleted (`--force` needs no
-  network).
+  given). Deletes immediately and needs no network - there is no undo. With `--check`
+  it first asks the server for its design element hashes and refuses to delete a clone
+  holding local changes the server doesn't have, naming each file; that needs a
+  reachable `backend=gateway` server, and a clone it can't verify is refused rather
+  than silently deleted.
 - `config`: View and manage configuration. `--check-gateway` reports the agent gateway negotiation and which gateway roles your identity holds.
 - `log`: View the server log.
 - `status`: Show the server status - via the agent gateway when available, otherwise the raw console `status` output.
@@ -132,7 +132,6 @@ For a full list of commands see `--help`.
 - `schema`: Manage the Puakma data dictionary (PMATABLE/ATTRIBUTE): record table/column definitions and print the DDL to run by hand. Never executes DDL.
 - `compile` (or `build`): Compile an application's Java Design Objects into `zbin/` using the Eclipse compiler (ecj).
 - `libs`: Show or refresh the per-server Java library cache (each server's `puakma.jar` and shared libraries, downloaded from the server itself).
-- `agent`: Generate agent/editor support files (CLAUDE.md, Puakma skills, code snippets) in the workspace.
 - `docs`: Open the Tornado Server Blackbook.
 - `execute`: Execute a command on the server.
 
@@ -144,11 +143,16 @@ For a full list of commands see `--help`.
 vortex clone 13                 # by ID
 vortex clone bettrackr_app      # by TemplateName
 vortex clone bettrackr/app      # by group/name
-vortex clone BetTrackr          # every application in the BetTrackr group
+vortex clone BetTrackr          # every active application in the BetTrackr group
+vortex clone -a BetTrackr       # ... including its disabled and inherited ones
 vortex clone dev:BetTrackr      # ... on the 'dev' server
 vortex clone --group BetTrackr  # explicitly a group, never a TemplateName
 ```
 
+A group clone skips disabled and inherited applications (the ones `vortex list`
+hides by default) unless `--all`/`-a` is given. An application you name outright -
+by ID, TemplateName or `group/name` - is always cloned, whatever its state.
+
 Groups are matched the way `vortex list --group` matches them - a
 case-insensitive substring - except that an exact (case-insensitive) group name
 always wins, so cloning `BetTrackr` never drags in `BetTrackrLegacy`. If a
@@ -158,8 +162,8 @@ than cloning the lot.
 A bare word is looked up as **both** a TemplateName and a group. In the rare
 case that it is genuinely both, vortex refuses to guess: use `--group NAME` for
 the group, or the ID / `group/name` for the single application. Every flag
-(`--reclone`, `--get-resources`, `--open-urls`, `--timeout`, `--server`) applies
-to group clones as it does to single apps.
+(`--reclone`, `--all`, `--get-resources`, `--open-urls`, `--timeout`, `--server`)
+applies to group clones as it does to single apps.
 
 ### Working with Multiple Servers
 
@@ -259,7 +263,10 @@ backend = gateway            ; default is 'soap', which never contacts the gatew
 
 With `backend = gateway`, `watch`/`push` uploads, `delete`, `log`, `status`, `db`, `execute`
 and the journal commands route through it, and `agenda`, `pull`, `render` and `undo` become
-available. Check what you are talking to and what you may do:
+available. Everything the gateway does not offer goes to the **webdesign vortex API** (the
+JSON action served by `system/webdesign`) - see [SOAP-free on backend = gateway](#soap-free-on-backend--gateway).
+A `backend = gateway` server never talks to SOAPDesigner at all. Check what you are talking
+to and what you may do:
 
 ```
 vortex config --check-gateway -s dev
@@ -269,8 +276,9 @@ vortex config --check-gateway -s dev
 identity lacks the required role) is reported as an error - vortex never quietly retries the
 same operation over SOAP, because that would let anyone with SOAP access bypass every role,
 journal and guardrail above. Likewise `backend = soap` never contacts the gateway. The one
-deliberate exception is the gateway application's *own* deployments, which always use SOAP so
-that a broken gateway deploy never needs the gateway to fix itself.
+deliberate exception is the gateway application's *own* deployments, which never go through
+the gateway (webdesign on `backend = gateway`, SOAP on `backend = soap`) so that a broken
+gateway deploy never needs the gateway to fix itself.
 
 The gateway application is **not bundled with this CLI** - deploy it to a server with
 `vortex export` / `vortex import`, then run its `Setup` scheduled action. It ships its own
@@ -282,6 +290,55 @@ the running server documents its own endpoints, roles and setup steps.
 > grant itself any role. Keep webdesign access for operators; agent identities should not have
 > it.
 
+### SOAP-free on `backend = gateway`
+
+SOAPDesigner is legacy. On a `backend = gateway` server the commands the gateway does not
+cover use the JSON API of `system/webdesign`'s `vortex` action instead - with the same
+credentials, and the webdesign app's own ACL. SOAP is used only when a server is explicitly
+`backend = soap`. The data dictionary (`schema`, `db --list/--schema`) is the exception that
+proves the rule: the gateway's `dictionary` endpoint runs that same webdesign `vortex` action
+server-side behind `GatewayDBRead`/`GatewayDBWrite`, so an agent identity with no webdesign
+access gets a clean role answer rather than a login page, and a change to `vortex.java`
+needs no change to the gateway.
+
+| Command | `backend = gateway` | `backend = soap` |
+|---|---|---|
+| `push`, `watch` (modify), `compile --upload` | gateway `upload` (journalled); the gateway app itself: webdesign `PUT design` | SOAP `uploadDesign` |
+| `watch` (create / delete) | webdesign `POST` / `DELETE design` | SOAP |
+| `delete` | gateway `delete` (journalled); the gateway app itself: webdesign | SOAP |
+| `copy`, `new object` | webdesign `POST`/`PUT design`, `PUT design/params` | SOAP |
+| `new app` | webdesign `POST vortex` | SOAP `saveApplication` |
+| `new keyword` | gateway `keyword` (upsert) | SOAP `saveKeyword` |
+| `schema`, `db --list`, `db --schema` | gateway `dictionary` (webdesign's `database`/`table`/`column` routes run server-side; `GatewayDBRead`/`GatewayDBWrite`) | SOAP SQL + `savePuakma*` |
+| `export` | webdesign `ExportPMX` action | SOAP `downloadPmx` |
+| `import` | **still SOAP** - webdesign has no import route yet | SOAP `uploadPmx` |
+| `db --sql`, `list`, `log`, `execute`, `status`, `clone`, `pull` | gateway | SOAP |
+
+Where the webdesign API behaves differently from SOAP, the CLI compensates so the commands
+behave as they did. The differences that remain visible:
+
+- **Design element writes are whole-row.** The CLI reads the row back first and re-sends what
+  it does not model (the other blob, `Options`), so a `DATA`-only upload never wipes source.
+  One consequence: every write is one extra `GET`.
+- **Renaming with `new object --update --name` does not rewrite references.** SOAP's
+  `updateDesignObject` also updated design params in the app that referred to the old name;
+  the webdesign route does not. Fix `OpenAction`/`ParentPage`-style params by hand after a rename.
+- **`schema` cannot record `--default`, `--position` or the column half of `--ref`.** The
+  webdesign column write has no `DefaultValue`/`Position`/`RefColumn` fields (SOAP's
+  `savePuakmaAttribute2` had them). `--default`/`--position` are refused with a message;
+  `--ref TABLE.COLUMN` records the table and warns. Updates leave existing values untouched.
+  Extend `POST`/`PUT .../column` in webdesign's `vortex.java` to lift this.
+- **Every write flushes the application's design cache**, where SOAP flushed one element.
+- **No per-application `Developer` role check** - the webdesign app's ACL is the boundary. An
+  identity that can reach `system/webdesign` can edit every application through it.
+- **`db --list` orders by table name** (SOAP's `SELECT DISTINCT` had no order); `--schema`
+  output is identical.
+- **Database-name resolution is app-scoped.** `schema`/`db --list` find the connection whose
+  dictionary holds the tables (as SOAP did by `pmatable` count), asking locally cloned
+  applications first and scanning the server inventory only if none of them has it.
+- **`import` remains SOAP** on every backend until webdesign gains a PMX import route
+  (`SaveImportPMX` is a multipart UI form, not an API).
+
 ### Interactive Wizards
 
 Run `vortex new object` or `vortex new app` without any flags to launch a step-by-step wizard:
@@ -377,22 +434,7 @@ vortex schema mydb --add-column invoice customer_id --type BIGINT --ref customer
 vortex schema mydb --ddl invoice    # print CREATE TABLE from the dictionary
 ```
 
-### Agent Support Files
-
-`vortex agent` copies bundled support files into the workspace `.vscode` directory so they are
-included in the generated code-workspace: an `AGENTS.md` with Puakma ground rules for coding
-agents (including pointers to the bundled Blackbook v2 architecture reference), a `CLAUDE.md`
-that points Claude Code at `AGENTS.md`, a `.claude/skills/` library covering Puakma development
-and the vortex workflow, and a `vortex.code-snippets` file with common Puakma Java/HTML
-snippets. Existing files are never overwritten, so they are safe to customise. These files are
-also generated automatically on `vortex --init` and before `vortex code` opens the workspace.
-
-The guidance is backend-aware: on a `backend = gateway` server the skills teach the explicit
-`vortex compile` + `vortex push` deploy loop (journaled, `undo`-recoverable, no workspace lock),
-and the `vortex watch` save-to-deploy loop is scoped to `backend = soap`. Because existing files
-are never overwritten, workspaces generated before 6.0.0 keep their old watch-centric copies -
-delete a file (or the `.claude/skills` directory) and re-run `vortex agent` to pick up the
-current version.
-
-Workspaces created before AGENTS.md existed keep their full `CLAUDE.md` (existing files are
-never touched); the new `AGENTS.md` is simply added alongside it.
+On a `backend = gateway` server the dictionary is reached through webdesign's vortex API via
+the gateway's `dictionary` endpoint (`GatewayDBRead` to read, `GatewayDBWrite` to change).
+That API cannot record `--default` or `--position` (refused) nor the column half of `--ref`
+(warned) - see [SOAP-free on backend = gateway](#soap-free-on-backend--gateway).

{vortex_cli-6.0.0 → vortex_cli-6.2.0}/pyproject.toml

@@ -5,7 +5,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "vortex_cli"
-version = "6.0.0"
+version = "6.2.0"
 description = "Vortex CLI"
 requires-python = ">=3.10"
 readme = { file = "README.md", content-type = "text/markdown" }
@@ -41,8 +41,6 @@ vortex = [
     "docs/Blackbook v2.md",
     "docs/index.html",
     "docs/marked.min.js",
-    "templates/agent/*",
-    "templates/agent/skills/*/*",
 ]
 
 [tool.mypy]

{vortex_cli-6.0.0 → vortex_cli-6.2.0}/vortex/cli.py

@@ -410,9 +410,23 @@ def add_clone_parser(
     )
     clone_parser.add_argument(
         "--reclone",
-        help="Reclone locally cloned applications",
+        help=(
+            "Reclone the locally cloned applications: every server's "
+            "clones, or only those of the given --server"
+        ),
         action="store_true",
     )
+    clone_parser.add_argument(
+        "--all",
+        "-a",
+        dest="include_all",
+        action="store_true",
+        help=(
+            "When cloning a group, also clone its disabled and inherited "
+            "applications (skipped by default). An application named "
+            "outright is always cloned"
+        ),
+    )
     clone_parser.add_argument(
         "--get-resources",
         "-r",
@@ -504,8 +518,8 @@ def add_clean_parser(command_parser: _SubParsersAction[ArgumentParser]) -> None:
         "clean",
         help=(
             "Delete the cloned Puakma Application directories in the "
-            "workspace. Refuses to delete a clone holding local changes "
-            "the server doesn't have, without --force"
+            "workspace. There is no undo; --check first asks the server "
+            "whether a clone holds local changes it doesn't have"
         ),
     )
     clean_parser.add_argument(
@@ -525,11 +539,13 @@ def add_clean_parser(command_parser: _SubParsersAction[ArgumentParser]) -> None:
         action="store_true",
     )
     clean_parser.add_argument(
-        "--force",
+        "--check",
         action="store_true",
         help=(
-            "Delete even clones with local changes the server doesn't "
-            "have (or that can't be verified against it). There is no undo"
+            "Before deleting, verify each clone against the server's design "
+            "element hashes and refuse any holding local changes the server "
+            "doesn't have (or that can't be verified). Needs a reachable "
+            "backend=gateway server"
         ),
     )
     clean_parser.add_argument(
@@ -1183,17 +1199,6 @@ def add_compile_parser(command_parser: _SubParsersAction[ArgumentParser]) -> Non
     _add_server_option(compile_parser)
 
 
-def add_agent_parser(command_parser: _SubParsersAction[ArgumentParser]) -> None:
-    command_parser.add_parser(
-        "agent",
-        help=(
-            "Generate agent/editor support files in the workspace "
-            "(AGENTS.md + CLAUDE.md pointer, Puakma skills, code snippets). "
-            "Existing files are never overwritten"
-        ),
-    )
-
-
 def add_execute_parser(command_parser: _SubParsersAction[ArgumentParser]) -> None:
     execute_parser = command_parser.add_parser(
         "execute",

{vortex_cli-6.0.0 → vortex_cli-6.2.0}/vortex/commands/clean.py

@@ -9,20 +9,21 @@ the same 'app_ids: list[int] | None' convention 'vortex pull' and
 'vortex push' use, APPLICATION ids, not the design-element ids
 'vortex delete' takes - narrows it to those clones.
 
-THE SAFETY GATE. There is no undo and no git inside an app folder, so
-clean refuses to delete a clone holding local work the server does not
-have, naming each file, unless --force is given. Deciding that is the
+THE OPT-IN SAFETY GATE. There is no undo and no git inside an app
+folder. With --check, clean refuses to delete a clone holding local
+work the server does not have, naming each file. Deciding that is the
 same three-way comparison pull makes (see pull.local_modifications)
 and it CANNOT be done offline: 'vortex push' does not move the
 manifest baseline, so after a push the local file differs from the
 baseline while matching the server. Telling 'already pushed, safe'
-from 'unsaved work' needs the server's hashes, which makes a
-non-forced clean a network operation. When the server can't answer -
-unreachable, refusing, or backend=soap, which has no hash endpoint at
-all - the clone is UNVERIFIABLE and clean refuses it rather than
-silently skipping the gate exactly when it matters; --force is the
-escape hatch (as is 'vortex clean --force' for an offline machine).
---force needs no network at all.
+from 'unsaved work' needs the server's hashes, which makes --check a
+network operation - one round trip per clone, and slow on a workspace
+with many. That is why it is opt-in: a plain 'vortex clean' deletes
+without asking the server anything (and so works offline). When
+--check is given and the server can't answer - unreachable, refusing,
+or backend=soap, which has no hash endpoint at all - the clone is
+UNVERIFIABLE and clean refuses it rather than silently skipping the
+gate exactly when it was asked for.
 """
 
 from __future__ import annotations
@@ -100,7 +101,7 @@ def _apply_gate(
         logger.error(
             f"{len(blocked)} application(s) hold unsaved local work (or could "
             "not be verified against the server) - push or pull them, or "
-            "re-run with --force to discard them. There is no undo"
+            "re-run without --check to discard them. There is no undo"
         )
     return blocked
 
@@ -112,7 +113,7 @@ def clean(
     include_libs: bool = False,
     app_ids: list[int] | None = None,
     *,
-    force: bool = False,
+    check: bool = False,
 ) -> int:
     cloned_apps = workspace.listapps(None if include_all else server)
 
@@ -124,7 +125,7 @@ def clean(
             return 1
         cloned_apps = [app for app in cloned_apps if app.id in wanted]
 
-    if not force and cloned_apps:
+    if check and cloned_apps:
         if _apply_gate(workspace, cloned_apps):
             return 1