Update to Corezoid

{
  "description": "API connector builder. Use when the user wants a Corezoid process that calls ONE endpoint of ANY HTTP API — external (Stripe, OpenWeather, Google, banks, CRMs), internal (Simulator.Company, own services) or Corezoid itself — built from a text description, a documentation link, an OpenAPI/Swagger file, or a list of endpoints produced while reasoning about a task. Produces an atomic connector: input contract, validation when needed, a single API Call, Reply to Process on every outcome, unified response format, test, and Smart API registration. Activate on: \"create a connector\", \"API connector\", \"integrate with <API>\", \"connect to <API>\", \"wrap this endpoint\", \"connector from this openapi.yaml\", \"сделай коннектор\", \"коннектор к API\", \"интеграция с\", \"подключи API\", \"обёртка над API\", \"зроби конектор\", \"конектор до API\", \"інтеграція з\", \"підключи API\". NOT for processes with business logic or several calls — use /corezoid-create.\n",
  "included_files": [
    {
      "relative_path": "references/contract-template.md",
      "size_in_bytes": 2515
    },
    {
      "relative_path": "references/process-skeleton.md",
      "size_in_bytes": 3655
    },
    {
      "relative_path": "references/registration.md",
      "size_in_bytes": 4870
    },
    {
      "relative_path": "references/reply-format.md",
      "size_in_bytes": 3344
    },
    {
      "relative_path": "references/test-rules.md",
      "size_in_bytes": 1829
    }
  ],
  "name": "corezoid-connector-create",
  "skill_md_contents": "---\nname: corezoid-connector-create\ndescription: >\n  API connector builder. Use when the user wants a Corezoid process that calls ONE endpoint\n  of ANY HTTP API — external (Stripe, OpenWeather, Google, banks, CRMs), internal\n  (Simulator.Company, own services) or Corezoid itself — built from a text description, a\n  documentation link, an OpenAPI/Swagger file, or a list of endpoints produced while\n  reasoning about a task. Produces an atomic connector: input contract, validation when\n  needed, a single API Call, Reply to Process on every outcome, unified response format,\n  test, and Smart API registration. Activate on: \"create a connector\", \"API connector\",\n  \"integrate with <API>\", \"connect to <API>\", \"wrap this endpoint\",\n  \"connector from this openapi.yaml\", \"сделай коннектор\", \"коннектор к API\",\n  \"интеграция с\", \"подключи API\", \"обёртка над API\", \"зроби конектор\", \"конектор до API\",\n  \"інтеграція з\", \"підключи API\".\n  NOT for processes with business logic or several calls — use /corezoid-create.\n---\n\n# Create an API Connector Process\n\nYou build **connector processes**: a Corezoid process that atomically calls **one endpoint**\n(method + path) of a Target API and always answers its caller.\n\nA connector is called by other processes through `api_rpc`, so it MUST reply on every path.\nAfter a successful test it is registered as a Smart API Connector in Simulator.Company.\n\n## Routing — check first\n\n| The request is… | Use |\n|---|---|\n| the user explicitly called `/corezoid-api-connector` | that skill — do not intercept |\n| a process with business logic, several calls, orchestration | `/corezoid-create` — stop here |\n| one endpoint of any HTTP API, Corezoid API included (or several endpoints → several connectors) | **this skill** |\n| an endpoint that needs files, git or a protocol the API Call node does not support | this skill, the call node is `git_call` (read `/corezoid-gitcall` first) |\n\n## Hard rules (every connector, no exceptions)\n\n1. **One process = one endpoint.** Several operations → several processes, one by one.\n2. **Input contract in `params`.** Every business parameter is declared with type, `required`\n   flag and regex where the format is known. Output fields are declared too (flag `output`).\n3. **No secrets, hosts or keys in task data or hardcoded.** Host, API keys, tokens — stage\n   variables only: `{{env_var[@<name>]}}` (create with `cz-variables`).\n4. **Validation when the contract needs it** (required fields, formats, ranges) — before the\n   API Call, with its own Reply. A Code node is allowed for validation.\n5. **Exactly one call node**: `api`, or `git_call` only by the exception in Routing.\n6. **`debug_info: true`** on the API Call node — the connector reads `__conveyor_api_debug__`\n   (HTTP code, timings) to build its response.\n7. **Reply to Process before EVERY final** — success, validation error, API error, connection\n   error, timeout. A path that reaches a final without `api_rpc_reply` hangs the caller.\n8. **Unified response format** — see `references/reply-format.md`. Result fields are named\n   after the endpoint (`customer`, `forecast`, `items` + `total`), never a generic\n   `data` / `response`.\n9. **No Sum nodes, no metric sub-processes.** Metrics are collected outside the connector\n   (HTTP-worker logs → Elasticsearch).\n10. **A connector is ready only after a successful positive test** (Step 9).\n\n## Workflow\n\n```\n1 Intake → 2 Contract → 3 Duplicate check → 4 Create process, params, variables\n→ 5 Build nodes → 6 Layout → 7 Lint → 8 Push → 9 Test → 10 Register → 11 Report\n```\n\nDo the steps in order. Do not skip Contract confirmation, Test or Register.\n\n---\n\n## Step 1: Intake\n\nAccept any of:\n\n- a text description of the API / endpoint;\n- a documentation link or an OpenAPI / Swagger URL — fetch and read it;\n- an OpenAPI / Swagger / Postman file — read it;\n- a list of connectors produced earlier in the conversation (\"which connectors does this task need\").\n\nOutput of the step — a numbered list of endpoints: `METHOD path — purpose`. Show it to the\nuser. If there are several, confirm which to build and build them **one at a time**\n(Steps 2–11 per endpoint).\n\nAlso ask (if not obvious): target folder for the process, Corezoid stage (default: develop).\n\n## Step 2: Contract\n\nFill the contract table from `references/contract-template.md` for the chosen endpoint:\nendpoint, provider + base host, input, output, expected errors, auth, test data.\n\nRules:\n\n- Take everything you can from the documentation; ask the user only for what is missing.\n- Auth goes to variables, never to input params (e.g. `stripe-api-key` variable,\n  header `Authorization: Bearer {{env_var[@stripe-api-key]}}`).\n- Decide **\"validation needed?\"**: yes if there are required fields, formats (email, UUID,\n  dates, enums) or ranges that the Target API would reject.\n- **Show the contract to the user and get explicit confirmation** before building.\n\nKeep the confirmed contract — Steps 9 and 10 use it.\n\n## Step 3: Duplicate check\n\nSearch the exported `.conv.json` files of the project (run `pull-folder` if needed) for an\n`api` node with the same method and the same host + path (after resolving variables).\nIf found — tell the user and offer: reuse it, update it (→ `/corezoid-edit`), or build a new\none anyway.\n\n## Step 4: Create the process, params and variables\n\n1. **Variables.** For host, keys and tokens: list existing ones (`cz-variables`\n   `list-variables`), create missing ones (`create-variable`; secrets as secret variables).\n   Naming: `<provider>-api-host`, `<provider>-api-key`.\n2. **Process.** Call `create-process` with `process_name` = `<Provider>: <METHOD> <path>`\n   (e.g. `Stripe: GET /v1/customers/{id}`) and the target `folder_path`. Check\n   `scheme.nodes` of the created file — do not add a second Start.\n3. **Description.** 1–2 sentences, starting with a verb: what the endpoint does and what it\n   returns (see Description Update Rule in `corezoid/SKILL.md`).\n4. **Params.** Declare input and output params in the full shape:\n\n```json\n{\"name\": \"customer_id\", \"type\": \"string\", \"descr\": \"Stripe customer id\",\n \"flags\": [\"required\", \"input\"], \"regex\": \"^cus_[A-Za-z0-9]+$\",\n \"regex_error_text\": \"customer_id must look like cus_...\"}\n```\n\nOutput params: same shape with `\"flags\": [\"output\"]`, one per result field of the reply.\n\n## Step 5: Build the nodes\n\nUse the skeleton in `references/process-skeleton.md`. Main path:\n\n```\nStart\n→ [Validate input]            (Code node, only if validation is needed)\n→ [Check validation]          (Condition: invalid → Reply validation error)\n→ [Prepare request]           (Code / Set Parameters, only if the body/query needs building)\n→ API Call                    (single api node, debug_info: true, time semaphore)\n→ Reply ok                    (result = ok + named result fields + http_code)\n→ Final\n```\n\nError paths (each with its own Reply and a named Error final):\n\n| Failure | How it is caught | Reply |\n|---|---|---|\n| input invalid | Condition after validation | `error_type: validation` + `invalid_params` |\n| Target API answered non-2xx | `err_node_id` → Condition on `__conveyor_api_return_type_tag__` = `api_bad_answer` (also `api_bad_answer_format`) | `error_type: api` |\n| connection / DNS / TLS | same Condition, tag `api_connection_error` | `error_type: connection` |\n| Target API call itself timed out (hardware) | same Condition, tag `api_timeout` — routes to the same Reply as the semaphore below | `error_type: timeout` |\n| no answer within the process-level wait | time semaphore of the API Call (default 30 s) | `error_type: timeout` |\n| anything else from the API Call | same Condition, default branch | `error_type: api` |\n\nNode rules — follow the **Core rules** of `/corezoid-create` (Step 4 there), especially:\n24-hex temporary node IDs; connect only via `go`; every `err_node_id` / semaphore target is\n`obj_type: 3`; never mix an action logic with `go_if_const` in one node; error clusters\ncollapsed and named after the failure (`Customer Not Found Error`, not `Error`); a dedicated\nerror cluster per failing node (validation Code node, prepare node, API Call).\n\nAPI Call node — author the **full canonical `api` logic** (see `docs/nodes/api-call-node.md`,\n\"Required node shape\"); the reference shape is in `references/process-skeleton.md`.\n`debug_info` MUST be `true`.\n\n## Step 6: Layout\n\nLeave coordinates at `x: 0, y: 0` while building, then call `layout-process`.\n\n## Step 7: Lint\n\nCall `lint-process` (with `profile: \"connector\"` once the plugin supports it). Fix every\nerror and re-run until clean. In addition, check by hand until the profile exists:\n\n- [ ] exactly one `api` (or `git_call`) node;\n- [ ] `debug_info: true` on it;\n- [ ] every final is reachable only through an `api_rpc_reply`;\n- [ ] no hardcoded `http://` / `https://` host in the URL, no keys in params;\n- [ ] no `api_sum` nodes.\n\n## Step 8: Push\n\nCall `push-process`. Then `pull-process` to get canonical node IDs (needed for `nodeId` in\nStep 10).\n\n## Step 9: Test\n\nFollow `references/test-rules.md`. In short:\n\n1. Build test data from the contract (docs examples; ask the user for what is missing).\n2. **Positive test** via `run-task` — expect `result = ok`, the expected `http_code`, result\n   fields matching the output params by name and type.\n3. **Negative validation test** (if validation exists) — invalid input → `error_type =\n   validation` + `invalid_params`, no API call made.\n4. Unsafe methods (POST / PUT / PATCH / DELETE) — only after the user confirms, or against a\n   sandbox host variable.\n5. On failure — show the node where the task stopped and the reply, propose a fix, re-test.\n6. Record the test result: `conv_id`, task ref, time, result.\n\n**No successful positive test → the connector is not ready. Do not register it.**\n\n## Step 10: Register the Smart API Connector\n\nFollow `references/registration.md`. In short:\n\n1. Find the receiver in the current workspace by names: project short_name \"smart-api\" → its\n   stage \"production\" → alias \"api-gw-create-smart-api\" → the process it points to. A missing\n   project/stage/alias is an expected outcome, not an error — the user may lack access, or\n   the resource may have been renamed/removed; don't guess which. Stop here and finish: the\n   connector is ready, Smart API was not registered (not found). Never block.\n2. `run-task` into the receiver process, exactly ONCE, with the task data in\n   `references/registration.md`. Task ref = `conv_id` of the connector.\n3. Report whatever comes back, verbatim, and stop there: a successful Reply → show the user\n   the Smart API actor id; any error, rejection, timeout, or no answer → tell the user Smart\n   API was not registered and why, quoting the receiver's own error. **Never** retry, guess a\n   different payload and resend, or pull/inspect the receiver process or any of its\n   sub-processes to \"fix\" a rejection — that is debugging someone else's production system,\n   not this skill's job. One attempt, one honest report, done.\n\n## Step 11: Report\n\nTell the user, briefly: process name and link, contract summary (method, path, inputs,\noutputs), test result, Smart API id (or why it was not registered), variables created.\n\nThen do the **Final Step: Update Git Context** exactly as in `/corezoid-create`.\n\n---\n\n## References\n\n| Path | When |\n|---|---|\n| `references/contract-template.md` | Step 2 — contract table and examples |\n| `references/process-skeleton.md` | Step 5 — node skeleton, API Call shape, error routing |\n| `references/reply-format.md` | Steps 5, 9 — response format, error mapping |\n| `references/test-rules.md` | Step 9 |\n| `references/registration.md` | Step 10 |\n| `${CLAUDE_PLUGIN_ROOT}/skills/corezoid-create/SKILL.md` | Core rules for nodes and error clusters |\n| `${CLAUDE_PLUGIN_ROOT}/docs/nodes/api-call-node.md` | API Call fields, error tags, semaphores |\n| `${CLAUDE_PLUGIN_ROOT}/docs/nodes/reply-to-process-node.md` | Reply formats, stringification |\n| `${CLAUDE_PLUGIN_ROOT}/docs/process/process-with-parameters.md` | `params` shape |\n| `${CLAUDE_PLUGIN_ROOT}/docs/variables-guide.md` | Variables |\n| `${CLAUDE_PLUGIN_ROOT}/samples/api-post.json` | HTTP POST example (note: its `debug_info: false` and generic `response` reply do NOT meet the rules above) |\n"
}