@superglue/cli 1.1.96 → 1.1.98

package/dist/skills/superglue/SKILL.md

@@ -208,27 +208,27 @@ Optional flags:
 
 ### Tool Translation (web agent tool → CLI command)
 
-Agents familiar with the web tool names can map them directly to CLI commands:
+Agents familiar with the web agent (its native tools and the `superglue` node module used inside `run_command`) can map them directly to CLI commands:
 
 | Web agent tool                                   | CLI command                                    | Notes                                                              |
 | ------------------------------------------------ | ---------------------------------------------- | ------------------------------------------------------------------ |
-| `build_tool`                                     | `sg tool build --config '{...}'`               | CLI is not AI-powered — you provide the full JSON config           |
-| `edit_tool`                                      | `sg tool edit --tool <id> --patches '[...]'`   | JSON Patch (RFC 6902). Use `--draft <id>` for drafts               |
+| `tools.writeTool` (superglue module; new id)     | `sg tool build --config '{...}'`               | CLI is not AI-powered — you provide the full JSON config           |
+| `tools.writeTool` (superglue/approved; saved id) | `sg tool edit --tool <id> --patches '[...]'`   | JSON Patch (RFC 6902). Use `--draft <id>` for drafts               |
 | `run_tool`                                       | `sg tool run --tool <id>` / `--draft <id>`     | Add `--include-step-results` to inspect per-step data              |
 | `run_command` with `vfs` for `/org/tools/`       | `sg tool find --id <id>` / `sg tool find <q>`  | Full config with `--id`, compact search with a query string        |
-| `create_system`                                  | `sg system create --name "..." --url "..."`    | Use `--template <id>` when available                               |
-| `edit_system`                                    | `sg system edit --id <id> ...`                 | Edits the system with that exact ID                                |
+| `tools.writeSystem` (superglue module; new id)   | `sg system create --name "..." --url "..."`    | Use `--template <id>` when available                               |
+| `tools.writeSystem` (superglue/approved; saved)  | `sg system edit --id <id> ...`                 | Edits the system with that exact ID                                |
 | `run_command` with `vfs` for `/org/systems/`     | `sg system find <query>` / `--id <id>`         | Returns secret-key presence and the system URL                     |
 | Credentials VFS / saved credentials              | `sg system credentials get/set/clear`          | Manage the current user's credentials for a system                 |
-| `call_system`                                    | `sg system call --url "..." --system-id <id>`  | Authenticated ad-hoc calls for testing / schema introspection      |
+| `tools.callSystem`                               | `sg system call --url "..." --system-id <id>`  | Authenticated ad-hoc calls for testing / schema introspection      |
 | `run_command search`                             | `sg system search-docs --system-id <id> -k`    | Targeted keyword search over ingested system docs                  |
 | `authenticate_oauth`                             | `sg system oauth --system-id <id> [--scopes]`  | Opens browser flow. Supports `--grant-type client_credentials` too |
 | `run_command` with `vfs` for `/org/runs/`        | `sg run list` / `sg run get <runId>`           | Filter `list` by `--tool`, `--status`, `--source`, `--limit`       |
 | `run_command` with `vfs` for `/org/mcp-servers/` | `sg mcp list` / `sg mcp find --id <id>`        | Returns endpoint, auth mode, selected tool IDs, and client config  |
-| `create_mcp_server`                              | `sg mcp create --name <n> --tool <id>`         | Creates a named MCP endpoint for selected saved tools              |
-| `edit_mcp_server`                                | `sg mcp edit --id <id> ...`                    | Edits name, auth mode, description, or selected tool IDs           |
-| `create_schedule`                                | `sg schedule create --tool <id> --cron <expr>` | Creates a cron schedule for a saved tool                           |
-| `edit_schedule`                                  | `sg schedule edit --tool <id> --id <schedule>` | Updates, enables, or disables an existing schedule                 |
+| `tools.writeMcpServer` (superglue module; new)   | `sg mcp create --name <n> --tool <id>`         | Creates a named MCP endpoint for selected saved tools              |
+| `tools.writeMcpServer` (superglue/approved)      | `sg mcp edit --id <id> ...`                    | Edits name, auth mode, description, or selected tool IDs           |
+| `tools.writeSchedule` (superglue module; new)    | `sg schedule create --tool <id> --cron <expr>` | Creates a cron schedule for a saved tool                           |
+| `tools.writeSchedule` (superglue/approved; id)   | `sg schedule edit --tool <id> --id <schedule>` | Updates, enables, or disables an existing schedule                 |
 | (no direct equivalent)                           | `sg login`, `sg update`, `sg skill`            | CLI-specific setup, updater, and this reference system             |
 
 Web-agent-only concepts with no CLI equivalent: `run_command`'s virtual filesystem (CLI uses concrete `sg` subcommands), `authenticate_oauth`'s dedicated MCP `authenticate` tool (CLI uses `sg system oauth`).

package/dist/skills/superglue/references/access-rules.md

@@ -46,7 +46,7 @@ Current configured role access and ownership grants are generally stored as `edi
 
 - `access_rule` — explicit admin/Access Rules edit.
 - `ownership` — authorization projection from the resource creator.
-- `share` — explicit user-to-user sharing through the app/agent sharing flow.
+- `share` — explicit sharing with an organization user or role.
 
 Ownership source of truth remains the tool/system row. Ownership grants are a permission projection and should be preserved by ordinary role edits.
 
@@ -82,24 +82,28 @@ Users can also have additional custom roles on top of their base role. Custom ro
 
 ## Personal Roles
 
-Personal roles are per-user containers for ownership, share, and explicit access-rule grants.
+Personal roles are per-user containers for ownership and user-targeted share grants.
 
 - Each user can have at most one personal role.
 - Ownership grants are added automatically when a user creates a tool or system.
 - Personal role grants are unioned with the user's other roles.
-- Managed via the Personal Roles tab in Access Rules and backend role APIs.
+- Ordinary role edits preserve personal roles and their ownership/share grants.
 
 ## Sharing Semantics
 
-V1 sharing targets organization users only. It does not share directly to base roles or custom roles.
-
-- Sharing writes `source: "share"` grants into the target user's personal role.
-- A user can grant only permissions up to their own effective access: viewer can grant viewer, editor can grant viewer or editor.
-- If the target already has the requested permission or stronger from any active grant, sharing is redundant and should be blocked.
-- If the target has viewer access and the acting user can grant editor, sharing can promote the user to editor through the personal `source: "share"` grant.
-- Sharing a tool also grants viewer access to required systems when the recipient lacks system access.
-- Tool sharing is atomic. If any selected user or required system grant cannot be applied, nothing is shared.
-- Normal users cannot unshare in V1. Admin cleanup should use Access Rules/admin grant management.
+Sharing supports saved tools, systems, credentials, projects, playbooks, artifacts, and files.
+
+- Targets are organization users or roles. The admin role and personal roles cannot be role targets.
+- User-targeted shares live on personal roles; role-targeted shares live on the selected role.
+- Sharing requires resource `editor` access. Direct shares grant `viewer` or `editor` through `source: "share"`.
+- Editors can update or remove direct shares. Removing one preserves ownership, access-rule grants, and access from other roles.
+- Credential sharing and revocation require the credential owner or an admin, even when another user has credential `editor`.
+- Recipients can remove their own direct share, including credential shares, without editor access.
+- Tool sharing grants missing system `viewer` access when the actor can pass it on. Otherwise, nothing is shared.
+- Tool sharing does not share credentials. Credential sharing also grants missing viewer access to its owning system.
+- Removing a tool or credential share does not remove the required-system shares it created.
+- Sharing systems or playbooks does not cascade to their tools, systems, or credentials.
+- Project sharing can include manageable current members when requested. It does not share future members or revoke member shares later.
 
 ## Auto-Grant On Resource Creation
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@superglue/cli",
-  "version": "1.1.96",
+  "version": "1.1.98",
   "bin": {
     "sg": "./dist/cli.js"
   },

package/skills/superglue/SKILL.md

@@ -208,27 +208,27 @@ Optional flags:
 
 ### Tool Translation (web agent tool → CLI command)
 
-Agents familiar with the web tool names can map them directly to CLI commands:
+Agents familiar with the web agent (its native tools and the `superglue` node module used inside `run_command`) can map them directly to CLI commands:
 
 | Web agent tool                                   | CLI command                                    | Notes                                                              |
 | ------------------------------------------------ | ---------------------------------------------- | ------------------------------------------------------------------ |
-| `build_tool`                                     | `sg tool build --config '{...}'`               | CLI is not AI-powered — you provide the full JSON config           |
-| `edit_tool`                                      | `sg tool edit --tool <id> --patches '[...]'`   | JSON Patch (RFC 6902). Use `--draft <id>` for drafts               |
+| `tools.writeTool` (superglue module; new id)     | `sg tool build --config '{...}'`               | CLI is not AI-powered — you provide the full JSON config           |
+| `tools.writeTool` (superglue/approved; saved id) | `sg tool edit --tool <id> --patches '[...]'`   | JSON Patch (RFC 6902). Use `--draft <id>` for drafts               |
 | `run_tool`                                       | `sg tool run --tool <id>` / `--draft <id>`     | Add `--include-step-results` to inspect per-step data              |
 | `run_command` with `vfs` for `/org/tools/`       | `sg tool find --id <id>` / `sg tool find <q>`  | Full config with `--id`, compact search with a query string        |
-| `create_system`                                  | `sg system create --name "..." --url "..."`    | Use `--template <id>` when available                               |
-| `edit_system`                                    | `sg system edit --id <id> ...`                 | Edits the system with that exact ID                                |
+| `tools.writeSystem` (superglue module; new id)   | `sg system create --name "..." --url "..."`    | Use `--template <id>` when available                               |
+| `tools.writeSystem` (superglue/approved; saved)  | `sg system edit --id <id> ...`                 | Edits the system with that exact ID                                |
 | `run_command` with `vfs` for `/org/systems/`     | `sg system find <query>` / `--id <id>`         | Returns secret-key presence and the system URL                     |
 | Credentials VFS / saved credentials              | `sg system credentials get/set/clear`          | Manage the current user's credentials for a system                 |
-| `call_system`                                    | `sg system call --url "..." --system-id <id>`  | Authenticated ad-hoc calls for testing / schema introspection      |
+| `tools.callSystem`                               | `sg system call --url "..." --system-id <id>`  | Authenticated ad-hoc calls for testing / schema introspection      |
 | `run_command search`                             | `sg system search-docs --system-id <id> -k`    | Targeted keyword search over ingested system docs                  |
 | `authenticate_oauth`                             | `sg system oauth --system-id <id> [--scopes]`  | Opens browser flow. Supports `--grant-type client_credentials` too |
 | `run_command` with `vfs` for `/org/runs/`        | `sg run list` / `sg run get <runId>`           | Filter `list` by `--tool`, `--status`, `--source`, `--limit`       |
 | `run_command` with `vfs` for `/org/mcp-servers/` | `sg mcp list` / `sg mcp find --id <id>`        | Returns endpoint, auth mode, selected tool IDs, and client config  |
-| `create_mcp_server`                              | `sg mcp create --name <n> --tool <id>`         | Creates a named MCP endpoint for selected saved tools              |
-| `edit_mcp_server`                                | `sg mcp edit --id <id> ...`                    | Edits name, auth mode, description, or selected tool IDs           |
-| `create_schedule`                                | `sg schedule create --tool <id> --cron <expr>` | Creates a cron schedule for a saved tool                           |
-| `edit_schedule`                                  | `sg schedule edit --tool <id> --id <schedule>` | Updates, enables, or disables an existing schedule                 |
+| `tools.writeMcpServer` (superglue module; new)   | `sg mcp create --name <n> --tool <id>`         | Creates a named MCP endpoint for selected saved tools              |
+| `tools.writeMcpServer` (superglue/approved)      | `sg mcp edit --id <id> ...`                    | Edits name, auth mode, description, or selected tool IDs           |
+| `tools.writeSchedule` (superglue module; new)    | `sg schedule create --tool <id> --cron <expr>` | Creates a cron schedule for a saved tool                           |
+| `tools.writeSchedule` (superglue/approved; id)   | `sg schedule edit --tool <id> --id <schedule>` | Updates, enables, or disables an existing schedule                 |
 | (no direct equivalent)                           | `sg login`, `sg update`, `sg skill`            | CLI-specific setup, updater, and this reference system             |
 
 Web-agent-only concepts with no CLI equivalent: `run_command`'s virtual filesystem (CLI uses concrete `sg` subcommands), `authenticate_oauth`'s dedicated MCP `authenticate` tool (CLI uses `sg system oauth`).

package/skills/superglue/references/access-rules.md

@@ -46,7 +46,7 @@ Current configured role access and ownership grants are generally stored as `edi
 
 - `access_rule` — explicit admin/Access Rules edit.
 - `ownership` — authorization projection from the resource creator.
-- `share` — explicit user-to-user sharing through the app/agent sharing flow.
+- `share` — explicit sharing with an organization user or role.
 
 Ownership source of truth remains the tool/system row. Ownership grants are a permission projection and should be preserved by ordinary role edits.
 
@@ -82,24 +82,28 @@ Users can also have additional custom roles on top of their base role. Custom ro
 
 ## Personal Roles
 
-Personal roles are per-user containers for ownership, share, and explicit access-rule grants.
+Personal roles are per-user containers for ownership and user-targeted share grants.
 
 - Each user can have at most one personal role.
 - Ownership grants are added automatically when a user creates a tool or system.
 - Personal role grants are unioned with the user's other roles.
-- Managed via the Personal Roles tab in Access Rules and backend role APIs.
+- Ordinary role edits preserve personal roles and their ownership/share grants.
 
 ## Sharing Semantics
 
-V1 sharing targets organization users only. It does not share directly to base roles or custom roles.
-
-- Sharing writes `source: "share"` grants into the target user's personal role.
-- A user can grant only permissions up to their own effective access: viewer can grant viewer, editor can grant viewer or editor.
-- If the target already has the requested permission or stronger from any active grant, sharing is redundant and should be blocked.
-- If the target has viewer access and the acting user can grant editor, sharing can promote the user to editor through the personal `source: "share"` grant.
-- Sharing a tool also grants viewer access to required systems when the recipient lacks system access.
-- Tool sharing is atomic. If any selected user or required system grant cannot be applied, nothing is shared.
-- Normal users cannot unshare in V1. Admin cleanup should use Access Rules/admin grant management.
+Sharing supports saved tools, systems, credentials, projects, playbooks, artifacts, and files.
+
+- Targets are organization users or roles. The admin role and personal roles cannot be role targets.
+- User-targeted shares live on personal roles; role-targeted shares live on the selected role.
+- Sharing requires resource `editor` access. Direct shares grant `viewer` or `editor` through `source: "share"`.
+- Editors can update or remove direct shares. Removing one preserves ownership, access-rule grants, and access from other roles.
+- Credential sharing and revocation require the credential owner or an admin, even when another user has credential `editor`.
+- Recipients can remove their own direct share, including credential shares, without editor access.
+- Tool sharing grants missing system `viewer` access when the actor can pass it on. Otherwise, nothing is shared.
+- Tool sharing does not share credentials. Credential sharing also grants missing viewer access to its owning system.
+- Removing a tool or credential share does not remove the required-system shares it created.
+- Sharing systems or playbooks does not cascade to their tools, systems, or credentials.
+- Project sharing can include manageable current members when requested. It does not share future members or revoke member shares later.
 
 ## Auto-Grant On Resource Creation