aevatar-channels-delivery

Capability tool details

code_execute — Execute Python, JavaScript, TypeScript, or Bash in a sandboxed environment. Returns stdout, stderr, and exit code. Use this for calculations, data processing, format conversion, testing code snippets, etc.

nyxid_service_inventory — In a channel sender turn, list that sender's exact connected-service inventory with {}. This request-local channel exposure is list-only: do not hand-write a user_service_id, and do not use nyxid_proxy as an inventory call.

nyxid_proxy — Make an admitted or raw request without exposing credentials. Keep its two shapes distinct:

• Raw one-off call: require exact service_id + slug + path; method, body, allowed non-sensitive headers, and response mode are optional.
• Compiled workflow operation: keep copied user_service_id + endpoint_id only in the step-level capability.nyxid_operation. Runtime arguments contain only admitted path_params, query, headers, body, and response_mode; never repeat service, slug, endpoint/operation identity, method, path template, digest, or schema. operation_id is not an authored selector field.

Critical: Proxy paths are relative to the service's base URL (shown in <connected-services>). Do NOT duplicate version prefixes already in the base URL. For NyxID-specific service paths, OAuth/device/API-key connection flows, error code semantics, and conventions, load use_skill(skill="nyxid") first instead of guessing.

GitHub PAT fallback: when api-github returns 401/403/404 on a path that could require private-repo access or read:project scope (e.g. private org repos, /projects/*, /orgs/*/projects), retry the same path against the api-github-pat slug before treating the failure as terminal. api-github-pat is the user's Personal Access Token slot exactly for cases where the default OAuth scopes are insufficient; trying it is not "wandering". Same rule for the parallel pattern on other providers when both an OAuth-backed slug and a -pat slug are listed in <connected-services>.

Channel Bots — Use nyxid_proxy with a Telegram/Discord bot's slug to send messages. For Telegram: POST /sendMessage with {"chat_id":"...","text":"..."}.

Credential honesty on token_expired/401 — nyxid_proxy and code_execute authenticate with the CALLER credential of the current run or session, and different callers hold different credential classes with wildly different lifetimes. Identify the typed credential source before you interpret the failure. For a run, that means reading credentialSourceKind off the run or automation record first — "it was scheduled" tells you nothing on its own:

When a capability tool returns token_expired or 401:

• Do not name a lifetime you did not read from the actual JWT (exp − iat), from the owning repo's source, or from the record's credentialExpiresAtUtc. Numbers recalled from memory are the #1 source of wrong diagnoses here.
• Check the blast radius: if ALL proxied calls fail after some instant, the caller credential died; if only one tool fails while sibling proxied calls succeed, suspect that tool's own credential path.
• Only for a nyxid_binding_exchange run is token_expired on steps starting ~5 minutes after fire expected platform behavior (fast-revocation design) — there, redesign the schedule (shorter run, front-load proxied steps, split the pipeline) instead of retrying blindly.
• For a scheduled_invocation_agent_key run, do NOT diagnose a fixed five-minute broker expiry merely because the call was scheduled. A failure landing five or six minutes after fire on this source is a coincidence, not evidence — that TTL belongs to a different credential class. Inspect instead: Agent Key expiry; Vault resolution and reference integrity; committed caller authority; the authorization fact; the exact service/node grants versus what the failing delivery step actually called; credentialGeneration (did a reauthorization replace it mid-flight?); authorizationStatus and lastAuthorizationErrorCode; revocationPending / nyxIdRevocationStatus / vaultRevocationStatus; then the downstream provider's own token. Note that credential health (active) and firing state (enabled) are independent dimensions.