@keystrokehq/cli 0.1.149 → 0.1.151

package/dist/skills-bundle/_AGENTS.mcp.md

@@ -75,7 +75,7 @@ Workflows also render as an interactive **canvas** in the platform. Keep durable
 - **Search the catalog, then research the system** — check `keystroke apps search` thoroughly before assuming an integration is missing. For anything custom or unfamiliar, web-fetch/search the real docs — `llms.txt`, OpenAPI/GraphQL specs, API reference — before mirroring endpoints or payloads. Never guess.
 - **Run before you claim you are finished** — deploy with `keystroke deploy` via `exec_command`, run it in the cloud, and read the real output before activating live triggers or claiming you are finished. Chat with agents and run workflows to confirm they behave correctly.
 - **Cover obvious edge cases** and write simple tests as needed (null field, empty array, a step that throws).
-- **Verify integration prerequisites** — before composing a catalog action into a workflow, run it once with `keystroke apps execute` (via `exec_command`) to confirm the IDs and fields exist in the connected account.
+- **Verify integration prerequisites** — before composing a **catalog** action into a workflow, run it once with `keystroke apps execute` (via `exec_command`) to confirm the IDs and fields exist in the connected account. Custom org apps (`{org}/{name}`) cannot use `apps execute` — smoke-test with deploy + `keystroke workflows run` on a thin workflow that calls `defineApp(...).action(...)`.
 - **Connect integrations in the web app** — use the `connect_app` tool to get a link for the user (a browser cannot open in this workspace). Keystroke projects don't use `.env`.
 - **Filtered deploys** — determine if you should do a full vs filtered deploy, or use WIP ignore directives (`search_docs "filtered deploy"`).
 - **Dependencies** — use the project's existing package manager (`package.json` `packageManager` field or lockfile); default to npm only on a freshly created project with no lockfile. Deploy uploads only the built `dist/` artifact — a lockfile is not part of what ships to the platform.
@@ -125,7 +125,7 @@ keystroke apps execute <app> <tool> --input '{...}'  # run a connected catalog a
 keystroke credentials list                          # what's already connected — check before asking the user to connect
 ```
 
-Custom org apps (`{org}/{name}`) do not have catalog toolkit actions — use `apps get` / `apps sync` / `defineApp(...).action(...)` instead.
+Custom org apps (`{org}/{name}`) do not have catalog toolkit actions — use `apps get` / `apps sync` / `defineApp(...).action(...)` instead. Do **not** use `apps execute` for them (catalog-only); smoke-test with a thin workflow via `keystroke workflows run <slug> --input '{...}' --wait` after deploy.
 
 **Gateway / channel binding:** use the `setup_agent_slack` tool (kind `keystroke` or `custom`), then follow its `nextCommands` via `exec_command` and share any OAuth/wizard URLs with the user. Keystroke path: OAuth for the Keystroke Slack App (catalog slug `slackbot`) if needed, then `keystroke channels setup <slug> [--channel <name>]`. Custom @handle: `keystroke channels setup <slug> --custom --print-url` and share the wizard link — user finishes in the browser. Do not use a Personal Slack Account (catalog slug `slack`, user token) for External Channels. Full detail: `search_docs "external channels"` → `/learn/agents/external-channels`.
 

package/dist/skills-bundle/_AGENTS.md

@@ -89,7 +89,7 @@ pnpm test                   # same — package.json scripts call the CLI
 Build, ship, then run and inspect what's live. Deploy often.
 
 1. **Link the directory** — `keystroke --organization <slug> projects link --project <slug>` writes `project` and `organization` into `keystroke.config.ts` (or pass the flags on every command). Commands that need auth tell you how to log in.
-2. **Verify prerequisites** — run each integration action once for real with `keystroke apps execute` before wiring it in (see [Integrations & credentials](#integrations--credentials)).
+2. **Verify prerequisites** — for **catalog** integrations, run each action once for real with `keystroke apps execute` before wiring it in. Custom org apps (`{org}/{name}`) are different — smoke-test via a thin workflow (see [Integrations & credentials](#integrations--credentials)).
 3. **Edit** primitives under `src/`. Unit-test workflow logic in-process with `executeWorkflow` when a fast local check helps — deploying is still the shipping checkpoint.
 4. **Deploy** — `keystroke deploy` (full) or `keystroke deploy --filter agents/support` (one module).
 5. **Run** — `keystroke workflows run <slug> --input '{...}' --wait` / `keystroke agents prompt <slug> --message "..." --wait`. Prefer `--wait` over `sleep`-and-recheck loops and choose its duration with `--timeout <seconds>`. A timeout means it is still running, not that it failed; continue with `keystroke workflows runs get <slug> <runId> --wait` or `keystroke agents sessions get <slug> <sessionId> --wait`.
@@ -261,7 +261,11 @@ Keystroke has 1,000+ built-in integrations, and it's easy to build a custom one
 
 Discover apps and actions with the CLI — the docs integration index is **not** reliable for discovery. One `<app> <tool>` shape flows through discovery → inspect → run for **catalog** apps; `apps actions get` / `apps actions list` print the next step after their output. Custom org apps (`{org}/{name}` from `apps create`) differ by source: non-MCP custom apps return `kind:"custom"` guidance (actions live in project code via `defineApp(...).action(...)`); **MCP** apps (`source:"mcp"`) return `kind:"mcp"` with the live tool registry after connect. Always `keystroke docs search` Keystroke docs first for custom/MCP patterns.
 
-Think about testing as you build. Local tests don't link cloud credentials or the Keystroke client, so unit-test pure logic locally; for integrations, check needed apps/credentials and run each action once for real with `keystroke apps execute` (no deploy, no server) before wiring it into a workflow or agent — confirm the IDs, custom fields, and labels you're about to hard-code exist in the *connected* account. Schema inspection and dry-run flags prove nothing about the mutating path.
+Think about testing as you build. Local tests don't link cloud credentials or the Keystroke client, so unit-test pure logic locally.
+
+**Catalog apps** — check needed apps/credentials and run each action once for real with `keystroke apps execute` (no deploy, no server) before wiring it into a workflow or agent — confirm the IDs, custom fields, and labels you're about to hard-code exist in the *connected* account. Schema inspection and dry-run flags prove nothing about the mutating path.
+
+**Custom org apps** (`{org}/{name}` from `apps create` / `apps sync`) — `apps execute` is catalog-only and will fail with a clear error. Actions live in project code as `defineApp(...).action(...)`. Smoke-test by deploying a thin workflow that calls the action, then `keystroke workflows run <workflow-slug> --input '{...}' --wait`. For MCP custom apps, use `keystroke apps actions list <org>/<name>` after connect for the live tool registry, then the same workflow smoke-test for anything you wrap in `app.action(...)`.
 
 ```bash
 keystroke apps list                          # all registered apps
@@ -382,7 +386,7 @@ Invoke/inspect commands print JSON to stdout (exit 0 on success, 1 on failure)
 - [ ] Deployed the change and read the real run output/trace — not just "it should work".
 - [ ] Prompted agents / ran workflows with realistic input and verified behavior.
 - [ ] Researched real APIs before mirroring them in custom integration actions — no guessed endpoints or payloads.
-- [ ] Executed each mutating integration action once via `keystroke apps execute` before composing it — a passing dry-run flag doesn't count.
+- [ ] Catalog: executed each mutating integration action once via `keystroke apps execute` before composing it — a passing dry-run flag doesn't count. Custom org apps: smoke-tested via deploy + `workflows run` on a thin workflow that calls the action (not `apps execute`).
 - [ ] Covered obvious edge cases (null field, empty array, a step that throws) with a simple test where warranted.
 - [ ] Checked `keystroke credentials list` before connecting; connected any new apps with `keystroke connect`.
 - [ ] Tested manually before deploying attached cron/polling triggers, or used `triggers disable` to pause until ready.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@keystrokehq/cli",
-  "version": "0.1.149",
+  "version": "0.1.151",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/keystrokehq/keystroke.git",
@@ -40,10 +40,10 @@
     "es-module-lexer": "^2.1.0",
     "tsdown": "^0.22.0",
     "tsx": "^4.22.3",
+    "@keystrokehq/oxlint-config": "0.0.4",
     "@keystrokehq/tsconfig": "0.0.3",
     "@keystrokehq/tsdown-config": "0.0.5",
-    "@keystrokehq/vitest-config": "0.0.7",
-    "@keystrokehq/oxlint-config": "0.0.4"
+    "@keystrokehq/vitest-config": "0.0.7"
   },
   "engines": {
     "node": "^22.18.0 || >=24.0.0"

package/dist/dist-BlsDG7kb.mjs

@@ -1,3 +0,0 @@
-#!/usr/bin/env node
-import { a as buildApp } from "./dist-DJQnugPi.mjs";
-export { buildApp };