clawdi 0.14.70 → 0.14.73

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "clawdi",
-	"version": "0.14.70",
+	"version": "0.14.73",
 	"description": "The best home for all your AI agents. Run them in the cloud or connect your own—with their context and tools in one place.",
 	"license": "MIT",
 	"type": "module",

package/skills/clawdi/SKILL.md

@@ -72,9 +72,11 @@ Three read-only tools expose the caller's visible Project context:
 - `project_list` — List visible Projects.
 - `project_get` — Read one visible Project by UUID.
 
-Hosted runtimes see only their bound Project. Treat a not-found response as an
-access boundary as well as a possible unknown UUID; do not try to bypass it
-through another tool.
+Strict-v2 Hosted runtimes can read their own Workspace and explicitly linked Projects
+that remain readable by the owner. `project_current_get` returns that Workspace;
+writes, new Vaults, and credential requests are limited to that Workspace. Legacy
+Agent-bound keys retain their narrower bound-Project read scope. Treat not-found as
+an access boundary as well as a possible unknown UUID; never bypass it with another tool.
 
 ## Vault
 
@@ -83,19 +85,19 @@ Vault read tools expose metadata and exact references:
 - `vault_list` — List Vault attachments and key counts for visible Projects.
 - `vault_get` — List key names, provenance, and exact `clawdi://` references for one attached Vault.
 
-Use `vault_resolve` only when the current task requires one referenced plaintext value. Pass
-the exact Project-scoped reference. Treat the result as sensitive: never echo it, save it to
-Memory, or include it in logs.
+Honor an explicit Vault/source or known local mapping first. Otherwise use `vault_list` /
+`vault_get` metadata to reuse a Vault suited to the task's purpose and access. Create in
+your own Workspace only when none is appropriate and the task authorizes creation.
+Clarify ambiguous sources; never create duplicates or write to linked Projects to bypass access.
 
-The metadata tools never resolve or return plaintext. Never imply that a returned key name
-is a secret value. Preserve their exact references for `vault_resolve` or when passing them
-to an authorized runtime:
+Use `vault_resolve` only when the authorized task requires plaintext. The metadata tools return
+key names and exact references, never secret values. Preserve those references when
+passing them to an authorized runtime:
 
 - `clawdi://project/<project-id>/vault/<vault>/field/<field>`
 - `clawdi://project/<project-id>/vault/<vault>/section/<section>/field/<field>`
 
-Use the live schemas from the `clawdi` MCP server as authoritative; the local
-stdio command only transports the protocol.
+Use the live schemas from the `clawdi` MCP server as authoritative.
 
 Vault write tools are available for explicit user requests:
 
@@ -107,9 +109,61 @@ Follow the live schema and supply every required Project, Vault, section, and fi
 never infer an overwrite or deletion. Treat field values as sensitive inputs and never echo
 them, save them to Memory, or include them in logs. Environment-bound callers may write only
 their bound Project, and field deletion is rejected when a Vault is attached to multiple
-Projects. Whole-Vault deletion, attach/detach, bulk import, and credential profiles remain
+Projects. Whole-Vault deletion, attach/detach, and credential profiles remain
 foreground operator workflows; never bypass that boundary through raw HTTP or daemon RPC.
 
+### Request missing credentials
+
+Use `vault_request_create` with exact `project_id`, `vault_id`, canonical `slug`, optional
+`section`, and a batch of environment field names in `fields`. A Vault is a key bundle:
+request related keys together under one link. Supplied or already-pending fields are rejected.
+Show the returned `url` unchanged to the user; do not ask them to paste secrets into chat.
+Opening the link does not consume it. Saving all requested fields consumes it once.
+
+Check `vault_request_status` with its `request_id` after the user finishes. `pending` is not
+a secret value; `supplied` means the exact references are ready. On `expired` or `conflict`,
+inspect the Vault and request only still-missing fields; never replace an existing value to
+retry. If creation times out, use `vault_get` to find recent request IDs before retrying.
+If submission times out, inspect status before repeating a mutation.
+
+### Save and refresh credentials locally
+
+Hosted runtime supplies `.clawdi/vaults/` under the native workspace automatically.
+Connected macOS/Linux/WSL Agents receive the same layout only in the workspace explicitly
+confirmed by setup. Use that configured path, which may differ from the current repository;
+do not guess from HOME, daemon CWD, or scanned sessions. Existing registrations without a
+Vault workspace do not download values. Native Windows daemon/file delivery is unsupported.
+
+Inspect only the configured `.clawdi/vaults/index.json` to select the intended Vault/section.
+Load its JSON file inside the authorized process or SDK without printing values or returning
+them to model/tool-result context merely to save them. These are generated files: do not
+edit, move or commit them. Hosted agents must not invoke/install the tenant Clawdi CLI.
+Connected operators configure delivery with `clawdi setup --agent <type> --vault-workspace <path>`;
+that changes only the Vault destination, never every repository scanned by the daemon.
+
+After a credential request is supplied, wait for the expected fields in index metadata before
+claiming delivery. If delivery is unavailable, report that state and any missing workspace
+binding instead of inventing a destination. Preserve unrelated local configuration.
+
+### Optional CLI environment files
+
+For an explicit operator-run compatibility workflow outside Hosted, use the available CLI.
+Choose a target outside the generated `.clawdi/vaults` directory:
+
+```bash
+clawdi vault materialize --vault <vault-uuid> --project <project-uuid> --out /absolute/project/.env
+clawdi vault pull --out /absolute/project/.env
+```
+
+The first command binds the exact source; later pulls reuse it and preserve unrelated
+assignments. Optional `--section <name>` selects one section. Files must be untracked,
+Git-ignored, and not symlinks. Source changes and local edits fail without overwriting.
+Report only the path, status, and counts. This does not upload local edits, run in the
+background, or reload a running process's environment.
+
+For explicit import/write, pass fields to `vault_item_upsert`; use
+`vault_item_delete` for exact batch deletions. Never upload local edits automatically.
+
 ## Wallet Funding
 
 Use `clawdi wallet status --json` to inspect the authenticated Wallet balance, verified

package/skills/hosted-versions/1/clawdi/SKILL.md

@@ -57,17 +57,24 @@ generic web fetcher for Clawdi share URLs.
 - `project_list` — List Projects visible to the caller.
 - `project_get` — Read one visible Project by UUID.
 
-A Hosted runtime is restricted to its bound Project. Treat not-found as an access boundary
-as well as a possible unknown UUID; do not try to bypass it through another tool.
+Strict-v2 Hosted runtimes can read their own Workspace and explicitly linked Projects
+that remain readable by the owner. `project_current_get` returns that Workspace; writes,
+new Vaults, and credential requests are limited to it. Legacy Agent-bound keys retain
+their narrower bound-Project read scope. Treat not-found as an access boundary as well
+as a possible unknown UUID; do not bypass it through another tool.
 
 ## Vault
 
 - `vault_list` — List attached Vaults and key counts for visible Projects.
 - `vault_get` — List key names, provenance, and exact references for an attached Vault.
 
-Use `vault_resolve` only when the current task requires one referenced plaintext value. Pass
-the exact Project-scoped reference. Treat the result as sensitive: never echo it, save it to
-Memory, or include it in logs.
+Honor an explicit Vault/source or known local mapping first. Otherwise use `vault_list` /
+`vault_get` metadata to reuse a Vault suited to the task's purpose and access. Create in
+your own Workspace only when none is appropriate and the task authorizes creation.
+Clarify ambiguous sources; never create duplicates or write to linked Projects to bypass access.
+
+Use `vault_resolve` only for authorized credential use, with exact Project-scoped
+reference(s) following its live schema. Never echo values, save them to Memory, or log them.
 
 The metadata tools never return plaintext secret values. Preserve exact references for
 `vault_resolve` or when passing them to an authorized runtime:
@@ -77,17 +84,55 @@ The metadata tools never return plaintext secret values. Preserve exact referenc
 
 Vault write tools are available for explicit user requests:
 
-- `vault_create` — Create a Vault attached to the runtime-bound Project.
+- `vault_create` — Create a Vault attached to your own Workspace.
 - `vault_item_upsert` — Create or replace exact fields in an attached Vault.
 - `vault_item_delete` — Delete exact fields from a single-Project Vault.
 
 Follow the live schema and supply every required Project, Vault, section, and field identity;
 never infer an overwrite or deletion. Treat field values as sensitive inputs and never echo
-them, save them to Memory, or include them in logs. Hosted writes are restricted to the
-runtime-bound Project, and field deletion is rejected when a Vault is attached to multiple
-Projects. Whole-Vault deletion, attach/detach, bulk import, and credential profiles remain
+them, save them to Memory, or include them in logs. Hosted writes are restricted to their
+own Workspace (the runtime-bound Project). Field deletion is rejected when a Vault is
+attached to multiple Projects. Whole-Vault deletion, attach/detach, and credential profiles remain
 unavailable through Agent MCP; do not bypass that boundary through raw HTTP.
 
+### Request missing credentials
+
+Use `vault_request_create` with exact `project_id`, `vault_id`, canonical `slug`, optional
+`section`, and a batch of environment field names in `fields`. A Vault is a key bundle:
+request related keys together under one link. Supplied or already-pending fields are rejected.
+Show the returned `url` unchanged to the user; do not ask them to paste secrets into chat.
+Opening the link does not consume it. Saving all requested fields consumes it once.
+
+Check `vault_request_status` with its `request_id` after the user finishes. `pending` is not
+a secret value; `supplied` means the exact references are ready. On `expired` or `conflict`,
+inspect the Vault and request only still-missing fields; never replace an existing value to
+retry. If creation times out, use `vault_get` to find recent request IDs before retrying.
+If submission times out, inspect status before repeating a mutation.
+
+### Use runtime-supplied credentials
+
+Clawdi runtime synchronizes readable Vaults from your own Workspace and explicitly linked,
+still-readable Projects into `.clawdi/vaults/` beneath your native workspace. Inspect only
+`.clawdi/vaults/index.json` for Vault IDs, section names, exact references, field names and files.
+Each section has a separate JSON file; equal field names in different sections stay separate.
+Select by the user's intended Vault and section, never by an ambiguous field name alone.
+
+Load the selected JSON file inside the authorized process or SDK without printing values.
+For example, Python can use `json.load(open(path))` and pass the selected key directly to
+its SDK. Do not read plaintext into model/tool-result context merely to save or copy it.
+Do not invoke or install the Clawdi CLI from the tenant. Runtime owns these generated files:
+do not edit, chmod, move, commit, or create your own files in `.clawdi/vaults/`. Preserve
+unrelated configuration in its `.clawdi` parent. Connected installations use this same
+layout on macOS/Linux only after an explicit workspace binding; do not assume an arbitrary
+repo is bound. Files remain readable by authorized programs running as the same user.
+
+After a credential request is supplied, inspect index metadata for the requested fields.
+Pending requests are metadata only, never empty pseudo-secrets. If delivery is delayed,
+report that state without claiming the credentials are saved. Runtime refreshes files;
+already-running processes must explicitly reload them. Offline delivery retains last good
+files; confirmed access removal removes generated files. Authorized code can read these
+files, so do not claim that subsequent plaintext exposure is impossible.
+
 ## Connector Routing
 
 Respect an explicit user choice. Otherwise inspect installed service CLIs, direct MCP tools