grix-connector 3.29.2 → 3.30.0

package/openclaw-plugin/skills/grix-admin/SKILL.md

@@ -1,28 +1,27 @@
 ---
 name: grix-admin
-description: Responsible for OpenClaw and grix-connector local configuration, binding, and runtime convergence; can create new remote API agents through the current agent's WS channel, and supports querying, creating, modifying agent categories and assigning categories to agents, reusable across agent creation and management flows.
+description: Responsible for OpenClaw local configuration, binding, and runtime convergence; can create new remote API agents through the current agent's WS channel, and supports querying, creating, modifying agent categories and assigning categories to agents.
 ---
 
 # Grix Agent Admin
 
 `grix-admin` is responsible for three things:
 
-1. Landing existing remote agent parameters into local OpenClaw or grix-connector, and handling runtime convergence after binding.
+1. Landing existing remote agent parameters into local OpenClaw and handling runtime convergence after binding.
 2. When the current main agent is already online and has the corresponding scope, creating new remote API agents through `grix_admin`'s direct actions, then continuing with local landing.
 3. During agent creation or subsequent agent management, reusing `grix_admin`'s direct actions to query categories, create categories, modify categories, and assign categories to agents.
 
 ## Entry Method
 
-1. In most cases, enter this skill from `grix_admin`'s `task` entry; the first line of `task` must clearly state `bind-local`, `create-and-bind`, `category-manage`, `connector-bind-local`, or `create-and-connector-bind`.
-2. Only when executing "remote API agent creation / category query / category creation / category modification / category assignment" remote steps within this skill should you directly call `grix_admin` once, without passing `task` again.
+1. In most cases, enter this skill from `grix_admin`'s `task` entry; the first line of `task` must clearly state `bind-local`, `create-and-bind`, or `category-manage`.
+2. Only when executing remote API agent creation or category operations within this skill should you directly call `grix_admin` once, without passing `task` again.
 3. In new flows, always explicitly pass `action` when directly calling `grix_admin`:
    - `create_agent`
    - `list_categories`
    - `create_category`
    - `update_category`
    - `assign_category`
-4. The legacy direct call format for `create_agent` (passing only `agentName` and other fields without `action`) is still compatible, but should not be used in new flows.
-5. Use `bind-local` / `create-and-bind` for **OpenClaw** local configuration; use `connector-bind-local` / `create-and-connector-bind` for **grix-connector** local configuration. Do not mix the two targets in a single invocation.
+4. The legacy direct call format for `create_agent` is still compatible, but should not be used in new flows.
 
 ## Agent Creation Intake
 
@@ -34,8 +33,8 @@ Before any `create_agent` API call:
    - A concise, professional `agentName` that reflects the Agent's role.
    - A professional `introduction` that states its purpose, core responsibilities, intended users or scenarios, operating expectations, and important boundaries.
 4. Preserve the user's facts and intent. Do not invent permissions, business authority, expertise, or responsibilities that the user did not grant.
-5. Treat `introduction` as the Agent's behavioral specification, not promotional copy. It directly affects how the Agent behaves after creation.
-6. Pass the finalized professional text in the actual `introduction` field of `action=create_agent`; do not leave it only in conversation, a summary, `soulContent`, or local persona files.
+5. Treat `introduction` as the Agent's behavioral specification, not promotional copy.
+6. Pass the finalized professional text in the actual `introduction` field of `action=create_agent`.
 
 ## Direct Action List
 
@@ -45,7 +44,7 @@ Before any `create_agent` API call:
    - `categoryId` and `categoryName` cannot be provided simultaneously
    - When `categoryName` is given, it first checks for duplicates under `parentCategoryId`; if not found, creates and assigns
 2. `action=list_categories`
-   - Required: (none)
+   - Required: none
 3. `action=create_category`
    - Required: `name`, `parentId`
    - Optional: `sortOrder`
@@ -56,69 +55,37 @@ Before any `create_agent` API call:
    - Required: `agentId`, `categoryId`
    - `categoryId=0` means clear the category
 
-## Mode A: bind-local (Initial Handoff from grix-register)
+## Mode A: bind-local (OpenClaw Local Binding)
 
-Input fields (written in `grix_admin.task`, all required):
+Input fields (written in `grix_admin.task`):
 
 1. First line must be `bind-local`
-2. `agent_name`
-3. `agent_id`
-4. `api_endpoint`
-5. `api_key`
+2. `agent_name` (required)
+3. `agent_id` (required)
+4. `api_endpoint` (required)
+5. `api_key` (required)
 
 Execution rules:
 
-1. Do not perform remote creation; execute local binding directly. Do not call any script that directly modifies `openclaw.json`.
-2. Prepare local directories first:
+1. Do not perform remote creation; execute local binding directly. Do not call scripts that directly modify `openclaw.json`.
+2. Prepare local directories:
    - `workspace=~/.openclaw/workspace-<agent_name>`
    - `agentDir=~/.openclaw/agents/<agent_name>/agent`
-   - Persona files go only in the `workspace` root: `IDENTITY.md`, `SOUL.md`, `AGENTS.md`, and optionally `USER.md` / `MEMORY.md`
-   - Do not put persona files in `agentDir`; `agentDir` is the per-agent runtime state directory managed by OpenClaw
-   - If `workspace` is missing required persona files, add minimal files to avoid an empty workspace for the new agent
-3. Read existing configuration; if paths do not exist, treat as empty object / empty array:
-   - `channels.grix.accounts`
-   - `agents.list`
-   - `tools.profile`
-   - `tools.alsoAllow`
-   - `tools.sessions.visibility`
-   - To confirm existing Grix bindings, additionally use `openclaw agents bindings --agent <agent_name> --json` to view the current binding list
-4. Calculate target values for this operation:
-   - `channels.grix.accounts.<agent_name>`: write `name`, `enabled=true`, `apiKey`, `wsUrl`, `agentId`
-   - `agents.list`: ensure entry exists with `id=<agent_name>`, `name=<agent_name>`, `workspace`, `agentDir`, `model`
-   - Grix binding: ensure the target agent is ultimately bound to `grix:<agent_name>`
-   - `tools.profile`: set to `"coding"`
-   - `tools.alsoAllow`: must include at least `message`, `grix_query`, `grix_group`, `grix_register`, `grix_message_send`, `grix_message_unsend`
-   - If the current binding target is the main agent, also ensure that agent's own `tools.alsoAllow` retains `grix_admin`, `grix_egg`, `grix_update`, `openclaw_memory_setup`; this set goes only at the agent level, not in global `tools.alsoAllow`
-   - `tools.sessions.visibility`: set to `"agent"`
-   - If `channels.grix.enabled=false`, change it back to `true`
-5. Rules for determining `model`:
-   - First reuse the existing `model` from that local agent's entry
-   - If the existing entry has none, use `agents.defaults.model.primary`
-   - If still unavailable, clearly state that model is missing, stop execution, do not guess
-6. Write using official CLI item by item; do not overwrite the entire config:
-   - `openclaw config set channels.grix.accounts.<agent_name> '<ACCOUNT_JSON>' --strict-json`
-   - `openclaw config set agents.list '<NEXT_AGENTS_LIST_JSON>' --strict-json`
-   - `openclaw agents bind --agent <agent_name> --bind grix:<agent_name>`
-   - `openclaw config set tools.profile '"coding"' --strict-json`
-   - `openclaw config set tools.alsoAllow '["message","grix_query","grix_group","grix_register","grix_message_send","grix_message_unsend"]' --strict-json`
-   - If the current binding target is the main agent, also merge `grix_admin`, `grix_egg`, `grix_update`, `openclaw_memory_setup` into that agent's own `agents.list` record's `tools.alsoAllow`; do not put this set in global `tools.alsoAllow`
-   - `openclaw config set tools.sessions.visibility '"agent"' --strict-json`
-   - Only when the current config explicitly has `channels.grix.enabled` turned off, execute `openclaw config set channels.grix.enabled true --strict-json`
-7. After writing, must perform static validation:
+   - Persona files belong only in the workspace root; add minimal `IDENTITY.md`, `SOUL.md`, and `AGENTS.md` if required files are missing.
+3. Read the current account, agent, tool profile, tool allowlist, session visibility, and binding configuration.
+4. Resolve `model` by reusing the existing agent model, then `agents.defaults.model.primary`; if neither exists, report the missing model and stop.
+5. Merge the account and agent entries, bind the agent to `grix:<agent_name>`, set the coding tool profile and required Grix tools, and restore `channels.grix.enabled=true` only if it is explicitly disabled.
+6. Use official OpenClaw CLI commands item by item; do not overwrite the entire config.
+7. Perform static validation:
    - `openclaw config validate`
    - `openclaw config get --json channels.grix.accounts.<agent_name>`
    - `openclaw config get --json agents.list`
    - `openclaw agents bindings --agent <agent_name> --json`
-8. If this invocation already has real verification conditions, must immediately perform a real routing verification; prefer reusing the current install/acceptance context, do not invent a new probe. The following situations are all considered as binding runtime not yet switched successfully:
-   - Reply falls to the main agent
-   - Reply behaves as the default assistant
-   - Reply still shows old persona, old config, or obvious ID mismatch
-9. Only when this `bind-local` invocation itself handles real verification, and step 7 static validation passed but step 8 real routing verification still fails, is one `openclaw gateway restart` allowed as targeted remediation; after restart, must redo the same round of real routing verification.
-10. Success definition:
-    - Can perform real verification: only "static validation passed + real routing verification passed" counts as `bind-local` complete
-    - This invocation cannot yet perform real verification: can only clearly state "config has been written, runtime not yet tested, needs subsequent upper-level flow to continue verification"; do not claim it has fully taken effect
+8. If real routing verification is available, perform it immediately. Falling back to the main agent, default assistant behavior, an old persona, or an ID mismatch means the runtime has not switched.
+9. Only when static validation passes but real routing verification fails may one `openclaw gateway restart` be used as targeted remediation; then repeat the same verification once.
+10. If real verification is unavailable, state “config has been written, runtime not yet tested, needs subsequent upper-level flow to continue verification”.
 
-## Mode B: create-and-bind (Subsequent Management When Main Channel and Scope Are Available)
+## Mode B: create-and-bind (Create Remote Agent Then Bind Locally)
 
 Fields written in `grix_admin.task`:
 
@@ -126,175 +93,71 @@ Fields written in `grix_admin.task`:
 2. `agentName` (required)
 3. `introduction` (required; professionally organized according to **Agent Creation Intake**)
 4. `isMain` (optional, default `false`)
-5. `categoryId` (optional): assign the new agent directly to an existing category
-6. `categoryName` (optional): create if not exists, then assign
-7. `parentCategoryId` (optional): only used in the `categoryName` approach, default `0`
-8. `categorySortOrder` (optional): only used when creating a category
+5. `categoryId` (optional)
+6. `categoryName` (optional)
+7. `parentCategoryId` (optional, default `0`)
+8. `categorySortOrder` (optional)
 
 Execution rules:
 
 1. Confirm the current session is bound to a valid Grix account; cross-account execution is prohibited.
-2. If both `categoryId` and `categoryName` are provided, report an error and stop immediately to avoid ambiguity.
-3. Call `grix_admin` only once with `action=create_agent`, delegating remote creation and optional category handling to it; pass:
-   - `action=create_agent`
-   - `agentName`
-   - Required `introduction`
-   - Optional `isMain`
-   - Optional `categoryId`
-   - Optional `categoryName`
-   - Optional `parentCategoryId`
-   - Optional `categorySortOrder`
-4. After remote creation succeeds, read `createdAgent.id`, `createdAgent.agent_name`, `createdAgent.api_endpoint`, `createdAgent.api_key` from the return result.
-5. If the request included category information, check whether the return already includes the category assignment result; if not, proceed with supplementary steps according to `categoryId` / `categoryName` rules and explain the reason.
-6. In the `categoryName` flow, if multiple categories with the exact same name appear under the same parent, stop and ask the owner to clean up categories or use an explicit `categoryId` instead.
-7. After remote creation and optional category steps succeed, immediately transition to the `bind-local` local binding steps; if this invocation already has real verification context, follow the same "static validation -> real routing verification -> one restart if needed -> same-round retest" convergence rules; otherwise explicitly hand the "continue real verification" responsibility back to the upper-level flow.
-8. `isMain=true` should only be used when actually creating a new main API agent; generally subsequent new agents should not enable this by default.
-9. Throughout the `create-and-bind` flow, do not treat "config written successfully" as completion; only when this invocation itself handles real routing verification and verification fails should one `openclaw gateway restart` be treated as targeted remediation.
+2. If both `categoryId` and `categoryName` are provided, report an error and stop.
+3. Call `grix_admin` once with `action=create_agent`, passing `agentName`, `introduction`, and the supplied optional fields.
+4. Read `createdAgent.id`, `createdAgent.agent_name`, `createdAgent.api_endpoint`, and `createdAgent.api_key` from the result.
+5. If category assignment was requested but not completed by the return result, supplement it through the appropriate direct category actions.
+6. In the `categoryName` flow, if multiple exact matches exist under the same parent, stop and ask the owner to use an explicit `categoryId`.
+7. Continue immediately with `bind-local` using the returned parameters.
+8. `isMain=true` should only be used when actually creating a new main API agent.
+9. Do not claim completion until static validation and any available real routing verification pass.
 
 ## Mode C: category-manage (Category Management)
 
 Fields written in `grix_admin.task`:
 
 1. First line must be `category-manage`
-2. `operation` (required): only `list`, `create`, `update`, `assign` are allowed
+2. `operation` (required): `list`, `create`, `update`, or `assign`
 3. `name` (`create` / `update` required)
 4. `parentId` (`create` / `update` required)
 5. `sortOrder` (`create` / `update` optional)
-6. `categoryId` (`update` / `assign` required; for `assign`, `0` means clear)
+6. `categoryId` (`update` / `assign` required; `0` clears an assignment)
 7. `agentId` (`assign` required)
 
 Execution rules:
 
-1. Strictly bound to the current session account; cross-account execution is prohibited.
-2. All remote steps must only be completed through `grix_admin`'s direct actions; hand-written HTTP and temporary scripts are prohibited.
-3. `operation=list`
-   - Call `action=list_categories`
-4. `operation=create`
-   - Call `action=create_category`
-5. `operation=update`
-   - Call `action=update_category`
-6. `operation=assign`
-   - Call `action=assign_category`
-   - `categoryId=0` explicitly means clear the agent's current category
-7. If the current management task also includes "creating a new agent", prefer using `create-and-bind`; do not split remote creation into other custom flows.
-
-## Mode D: connector-bind-local (grix-connector Local Binding)
-
-Input fields (written in `grix_admin.task`, all required):
-
-1. First line must be `connector-bind-local`
-2. `agent_name`
-3. `agent_id`
-4. `api_endpoint`
-5. `api_key`
-6. `client_type` (optional, default `pi`)
+1. Strictly bind all operations to the current session account; cross-account execution is prohibited.
+2. Complete all remote steps through `grix_admin` direct actions; do not hand-write HTTP or temporary scripts.
+3. Map operations directly: `list_categories`, `create_category`, `update_category`, or `assign_category`.
+4. If the task also creates a new agent, use `create-and-bind` instead.
 
-Execution rules:
+## Remote Creation Fallback
 
-1. Do not perform remote creation; execute local grix-connector binding directly. Do not invoke any OpenClaw CLI commands in this mode.
-2. Target file: `~/.grix/config/agents.json`. If the file or directory does not exist, initialize it as `{ "agents": [] }`.
-3. Read the existing `agents` array. If an entry with the same `name` as `agent_name` already exists, update it in place; otherwise append a new entry.
-4. Write the following fields into the entry:
-   - `name`: `agent_name`
-   - `ws_url`: `api_endpoint`
-   - `agent_id`: `agent_id`
-   - `api_key`: `api_key`
-   - `client_type`: `client_type` (default `pi`)
-5. Preserve valid JSON and set file permissions to `0o600`. Before writing, create a timestamped backup at `~/.grix/config/agents.json.bak.<YYYYMMDDHHMMSS>` and also set the backup file permissions to `0o600`.
-6. If `grix-connector` daemon is running (`grix-connector status` returns `daemon_state=running`), trigger reload via the daemon Admin API:
-   - Default endpoint: `POST http://127.0.0.1:19580/api/reload`
-   - The actual admin port may be overridden by `GRIX_ADMIN_PORT` or `--admin-port`; if the default fails, read `~/.grix/data/admin-port` for the current port.
-   - This endpoint is synchronous: it waits for `manager.reload()` to finish and returns `{ ok: true, result }` or an error. Unlike the CLI `grix-connector reload`, it does not suffer from "signal sent but config not yet applied" race conditions, and it surfaces JSON parse errors or `RELOAD_UNSAFE` failures to the caller.
-   - If the reload request returns an error, report the error and stop; do not proceed to verification.
-7. After reload succeeds, verify that the daemon has loaded the new entry via `GET /api/agents`:
-   - Find an entry where `name === agent_name`.
-   - Confirm the entry exists and reports `alive === true`.
-   - **Important**: `alive=true` only means the daemon has started the Agent instance; it does **not** prove the Agent has successfully connected to the Grix platform or that the API key is valid. Authentication failures do not flip `alive` to `false`.
-   - Therefore, perform a secondary convergence check: inspect the latest daemon log in `~/.grix/log/` (files are named `grix-connector-<YYYY-MM-DD>.log`; list the directory and open the most recent one) for WebSocket connection success / authentication failure messages for this Agent, or ask the owner to send a test message to the Agent.
-   - If the secondary check fails, state "config loaded and instance started, but platform connection not yet verified"; do not claim full convergence.
-8. If this invocation cannot perform real verification, clearly state "config has been written, reload completed, runtime not yet tested, needs subsequent flow to continue verification"; do not claim it has fully taken effect.
-9. Success definition:
-   - Can perform real verification: "config written + reload succeeded + Agent entry exists with `alive=true` + platform connection verified (log or test message)" counts as `connector-bind-local` complete.
-   - Cannot perform real verification: only "config written + reload succeeded" can be claimed.
-
-## Mode E: create-and-connector-bind (Create Remote Agent Then Bind to grix-connector)
+If the task has neither existing agent parameters nor an online main channel with `agent.api.create`, stop and ask the owner to create the remote agent through the backend admin path. After obtaining the parameters, proceed with `bind-local`.
 
-Fields written in `grix_admin.task`:
+## Guardrails
 
-1. First line must be `create-and-connector-bind`
-2. `agentName` (required)
-3. `introduction` (required; professionally organized according to **Agent Creation Intake**)
-4. `isMain` (optional, default `false`)
-5. `clientType` (optional, default `pi`)
-6. `categoryId` (optional): assign the new agent directly to an existing category
-7. `categoryName` (optional): create if not exists, then assign
-8. `parentCategoryId` (optional): only used in the `categoryName` approach, default `0`
-9. `categorySortOrder` (optional): only used when creating a category
+1. Never ask for a website account or password.
+2. `bind-local` must not call back to `grix-register`.
+3. All remote creation and category actions must go through `grix_admin` direct actions via the current account's WS channel.
+4. Never repeatedly echo the complete `api_key` in plaintext.
+5. Do not manually modify `openclaw.json`; use official OpenClaw CLI commands.
+6. Do not claim full convergence until static validation and any available real routing verification pass.
+7. Use at most one targeted gateway restart, only under the failure conditions defined by `bind-local`.
 
-Execution rules:
+## Error Handling
 
-1. Confirm the current session is bound to a valid Grix account; cross-account execution is prohibited.
-2. If both `categoryId` and `categoryName` are provided, report an error and stop immediately to avoid ambiguity.
-3. Call `grix_admin` only once with `action=create_agent`, delegating remote creation and optional category handling to it; pass:
-   - `action=create_agent`
-   - `agentName`
-   - Required `introduction`
-   - Optional `isMain`
-   - Optional `categoryId`
-   - Optional `categoryName`
-   - Optional `parentCategoryId`
-   - Optional `categorySortOrder`
-4. After remote creation succeeds, read `createdAgent.id`, `createdAgent.agent_name`, `createdAgent.api_endpoint`, `createdAgent.api_key` from the return result.
-5. If the request included category information, check whether the return already includes the category assignment result; if not, proceed with supplementary steps according to `categoryId` / `categoryName` rules and explain the reason.
-6. In the `categoryName` flow, if multiple categories with the exact same name appear under the same parent, stop and ask the owner to clean up categories or use an explicit `categoryId` instead.
-7. After remote creation and optional category steps succeed, immediately transition to the `connector-bind-local` local binding steps using the returned parameters and `clientType`.
-8. Trigger reload via the synchronous Admin API `POST /api/reload` (see Mode D for port resolution and failure handling); then verify the new Agent entry exists and `alive=true` via `GET /api/agents`, and perform the secondary platform-connection verification (log inspection or test message).
-9. `isMain=true` should only be used when actually creating a new main API agent; generally subsequent new agents should not enable this by default.
-10. Throughout the `create-and-connector-bind` flow, do not treat "config written successfully" as completion; only when this invocation handles real verification and verification passes is it complete.
-
-## Remote Creation Fallback Conditions
-
-If the current task has neither an existing `agent_name`, `agent_id`, `api_endpoint`, `api_key`, nor an available online main channel or `agent.api.create` permission, stop this skill first and clearly prompt the user to create the remote agent through the backend admin path. After obtaining these parameters:
-
-- For OpenClaw target, proceed with `bind-local`.
-- For grix-connector target, proceed with `connector-bind-local`.
-
-## Guardrails (Applicable to All Modes)
-
-1. Never ask user for website account/password.
-2. `bind-local` mode must not call back to `grix-register` to avoid circular routing.
-3. All remote creation / category-related actions must only go through `grix_admin` direct actions via the current account's WS channel; do not hand-write HTTP or fall back to legacy scripts.
-4. The complete `api_key` is only passed back once; do not repeatedly echo it in plaintext.
-5. Before local `openclaw config set` / `validate` succeeds, do not claim config is complete; when this invocation can perform real verification, do not claim `bind-local` / `create-and-bind` is complete until real routing verification passes.
-6. During an install private chat, do not manually modify `openclaw.json` and then execute `openclaw gateway restart`.
-7. Do not reference or call `grix_agent_bind.py`; for OpenClaw modes this skill only uses official OpenClaw CLI commands.
-8. For `connector-bind-local` / `create-and-connector-bind`, directly reading and writing `~/.grix/config/agents.json` is the intended mechanism; this is grix-connector's own configuration domain, not a third-party product.
-9. When writing `~/.grix/config/agents.json`, always create a timestamped backup first, preserve valid JSON, and set both the config file and the backup file permissions to `0o600`.
-10. After writing grix-connector config, trigger reload through the synchronous Admin API `POST /api/reload` (not the CLI `grix-connector reload`) so that reload errors are visible to the caller. Verify the Agent entry exists and reports `alive=true`, and perform a secondary platform-connection check before claiming full convergence.
-
-## Error Handling Rules
-
-1. `bind-local` / `connector-bind-local` missing fields: clearly state which field is missing and stop.
-2. `create-and-bind` / `create-and-connector-bind` missing `agentName` or `introduction`: do not call the creation API; ask for the Agent's purpose, core responsibilities, intended users, and boundaries, then professionally organize both fields.
-3. `create-and-bind` / `create-and-connector-bind` with both `categoryId` and `categoryName`: clearly state the conflict and stop.
-4. `category-manage` missing `operation` or operation-specific fields: clearly state which field is missing and stop.
-5. Remote returns `code=4003` or message explicitly mentions `agent.api.create`: tell the owner to grant `agent.api.create` on the Agent permissions page.
-6. Remote returns `code=4003` or message explicitly mentions `agent.category.list` / `agent.category.create` / `agent.category.update` / `agent.category.assign`: tell the owner to grant the corresponding scope on the Agent permissions page.
-7. Missing remote agent parameters and current account cannot create: clearly require backend admin creation first.
-8. Local config failure (OpenClaw): return the failed command and result, then stop; emphasize which `get` / `set` / `validate` step failed.
-9. Local config failure (grix-connector): report the exact JSON parse error, write error, or `~/.grix/config/agents.json` state, then stop.
-10. Synchronous Admin API reload failed (e.g., returns non-2xx, `RELOAD_UNSAFE`, JSON parse error in agents.json): report the error body and daemon status; do not proceed to verification or claim the Agent is online.
-11. Admin API verification failed (Agent entry missing or not `alive=true`): report the observed entry or missing entry, then stop.
-12. Secondary platform-connection verification failed (log shows authentication/connection errors, or test message not delivered): state "config loaded and instance started, but platform connection not verified"; converge as partially complete, do not claim full convergence.
-13. This invocation handles real routing verification, and after one `openclaw gateway restart` retest still fails: clearly state "static config has been written, but runtime has not yet switched successfully"; converge as failed or partially complete, do not write it as success.
+1. For missing fields, clearly state which field is missing and stop.
+2. If `agentName` or a usable `introduction` is missing, ask for the Agent's purpose, responsibilities, intended users, and boundaries before remote creation.
+3. If both `categoryId` and `categoryName` are supplied, report the conflict and stop.
+4. For `code=4003`, report the exact missing `agent.api.create` or `agent.category.*` scope.
+5. Report the exact failed OpenClaw CLI command and validation result.
+6. If one permitted restart and retest still fail, report the flow as failed or partially complete.
 
 ## Response Style
 
-1. Clearly state whether the current execution is `bind-local`, `create-and-bind`, `category-manage`, `connector-bind-local`, or `create-and-connector-bind`.
-2. Report in phases: remote creation / category handling (if any) / local config writing / reload / validation results.
-3. Clearly state whether local config has taken effect; if only static config succeeded but this invocation cannot perform real verification, can only write "config has been written, runtime not yet tested, needs subsequent flow to continue verification"; if only the category step succeeded, also state that clearly.
-4. For grix-connector flows, explicitly report whether the synchronous Admin API reload succeeded, whether the Admin API shows the Agent entry exists with `alive=true`, and the result of any secondary platform-connection verification.
-5. If remote creation succeeded but category or local binding subsequently failed, clearly state it is "partially complete"; do not generically write it as success.
+1. Clearly state whether the execution is `bind-local`, `create-and-bind`, or `category-manage`.
+2. Report remote creation, category handling, local config writing, and validation as separate phases when applicable.
+3. Clearly distinguish static configuration success from verified runtime convergence.
+4. If a later phase fails after remote creation, report the overall result as partially complete.
 
 ## References