菜单
Use after backend changes that affect the OpenAPI surface — new capabilities, new step types, new connection types, new HTTP routes — so the frontend's generated API client and type definitions stay in sync. The Step Picker, Connection UI, and most forms are driven by these generated types.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | regen-frontend-api |
| description | Use after backend changes that affect the OpenAPI surface — new capabilities, new step types, new connection types, new HTTP routes — so the frontend's generated API client and type definitions stay in sync. The Step Picker, Connection UI, and most forms are driven by these generated types. |
The frontend doesn't manually mirror backend types. It pulls OpenAPI from the running server and codegens TypeScript clients. Two clients, two scripts.
Run this whenever any of these change on the backend:
#[capability] was added/modified/removed (capabilities show up in the Step Picker via this client)inventory::submit! in step_registration.rs#[connection(...)] was added in connection_types.rscrates/runtara-server/src/handler or crates/runtara-connections/src/handlerIf the Step Picker doesn't show your new capability or step, this is almost always why.
The codegen script hits the live server's /openapi/docs.json — the server must be running.
cargo run -p runtara-server
The runtime API is on port 7001, management on 8080 (per the package.json scripts).
From crates/runtara-server/frontend:
cd crates/runtara-server/frontend
# For runtime API changes (capabilities, steps, connections, workflow execution)
npm run generate-api-runtime-local
# For management API changes (tenants, users, configuration)
npm run generate-api-management-local
When in doubt, run both. They're cheap and idempotent.
Output goes to src/generated/RuntaraRuntimeApi.ts and RuntaraManagementApi.ts.
The generated files are checked in. After regeneration, git diff should show only meaningful changes (your additions). Spurious churn (timestamps, reordered fields) suggests the codegen ran against a different server build — rebuild the server and try again.
After regen, the affected UI surface should reflect the change without further frontend edits:
If it doesn't show up, check:
curl http://localhost:7001/api/runtime/openapi/docs.json | jq '.paths' | grep <thing>)inventory::submit! for the new thing isn't gated behind #[cfg(not(target_family = "wasm"))] and accidentally excludedcrates/runtara-server/frontend/src/generated/RuntaraRuntimeApi.tscrates/runtara-server/frontend/src/generated/RuntaraManagementApi.ts(Both committed; review the diff to make sure only intended changes appear.)
Use to verify changes to agents, capabilities, integrations, steps, or runtime end-to-end before declaring a task done. Boots the full server stack with embedded WASM runner and separate DBs, then drives the server HTTP API to create, compile, and execute a workflow and assert observable behavior. Unit tests are not sufficient — agent/runtime changes must e2e-verify.
Use when local dev state has drifted into a weird shape — failing migrations, half-applied schema changes, stale cached binaries, suspended instances clogging the system. Wipes the e2e DBs and data dir and gives you a clean slate. Distinct from e2e-verify which assumes a clean env.
Use to set up the right RUST_LOG filters and tail server + environment logs scoped to a specific tenant, instance, or component. Saves the "what's the right log filter again" lookup. Pair with trace-instance when you need both API state and live log output.
Use when a workflow that uses a connection misbehaves — to see stored params (secrets masked), token state, rate-limit history, and which integration it belongs to. Catches stale OAuth tokens and misconfigured connection params before you blame the agent.
Use to get a quick health view of a workflow — its definition, registered versions, recent instances and their statuses, and which connections it touches. The "is this thing healthy / what does it look like right now" view, distinct from trace-instance which drills into one specific run.
Use for the tight inner loop when developing or debugging a single capability — rebuild only the changed crate, recompile a small test workflow that exercises it, register, run, dump output. ~10s feedback vs full e2e-verify. Use e2e-verify for the final pre-commit check; use this while iterating.