@keystrokehq/cli 0.1.14 → 0.1.16

package/dist/dist-CEqY8MN8.mjs

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

package/dist/skills-bundle/skills/keystroke-cli/references/api-targets.md

@@ -1,87 +0,0 @@
-# API target routing
-
-The CLI resolves a `baseUrl` before runtime commands (`workflow`, `agent`, `trigger`, `app`, `connect`, `health`). Implementation: `apps/cli/src/resolve-api-target.ts`.
-
-## Mental model
-
-- **Local** = your **keystroke server** (`keystroke dev` / `keystroke start`). Use for authoring, unit/integration tests in the repo, and manual runs while iterating.
-- **Cloud** = **keystroke platform** control plane routes to a deployed keystroke server (`/api/projects/:projectId/*`). Use for live invocation, listing triggers on deploy, webhook URLs, and auditing production runs.
-
-Auth is independent of target. `keystroke auth login` stores a bearer token in the OS keychain keyed by `webUrl` hostname and persists matching `webUrl` / `platformUrl` in config. Cloud API calls attach that token; local dev often runs without auth unless `BETTER_AUTH_SECRET` is set.
-
-## Config (`~/.keystroke`)
-
-| Key               | Default                    | Role                             |
-| ----------------- | -------------------------- | -------------------------------- |
-| `platformUrl`     | `https://api.keystroke.ai` | Keystroke platform control plane |
-| `webUrl`          | `https://keystroke.ai` | Dashboard + device login         |
-| `activeProjectId` | unset                      | Deployed project id (persistent) |
-| `apiTarget`       | inferred                   | `local` or `platform`            |
-
-Local commands use `PUBLIC_PLATFORM_URL` from the project `.env` (dev default `http://localhost:3002` when unset). They do not read `platformUrl` when `apiTarget=local`, so cloud login does not redirect local workflow runs to production.
-
-If `apiTarget` is unset and `activeProjectId` exists, effective target is **platform** (backward compatible). Explicit `apiTarget=local` overrides that without clearing `activeProjectId`.
-
-`keystroke config show` prints effective `apiTarget` and any active dev session.
-
-## Switching without losing cloud state
-
-```bash
-keystroke deploy --project proj_abc     # activeProjectId=proj_abc, apiTarget=platform
-keystroke config use local              # apiTarget=local; proj_abc unchanged
-keystroke workflow run foo --input '{}' # → localhost:3002
-keystroke config use cloud              # apiTarget=platform; same proj_abc
-keystroke trigger list                  # → platform runtime
-```
-
-Swap cloud project:
-
-```bash
-keystroke config use project proj_xyz
-```
-
-Target another project once:
-
-```bash
-keystroke --project proj_xyz workflow runs list my-workflow
-```
-
-## Dev session auto-local
-
-`keystroke dev` writes `dev-session.json` beside config (pid, port, serverUrl). While that process is alive, resolved target is **local** even if `apiTarget=platform`. Stopping dev removes the session; routing falls back to config.
-
-`--project` still wins over the dev session when you need to hit cloud while dev is up.
-
-## Global flags
-
-| Flag             | Effect                                                                     |
-| ---------------- | -------------------------------------------------------------------------- |
-| `--local`        | Force local API (`PUBLIC_PLATFORM_URL` / project `.env`) for this command                  |
-| `--project <id>` | Force platform runtime for that project; does not update `activeProjectId` |
-
-## Platform projects
-
-Platform projects are deploy targets on the control plane. List or create them before the first deploy:
-
-```bash
-keystroke project list
-keystroke project create --name "My app"
-keystroke deploy --project <id>              # activates runtime; sets activeProjectId
-keystroke config use project <id>            # swap default cloud target
-```
-
-New projects start **inactive**. The CLI hints with `keystroke deploy --project <id>` when appropriate.
-
-## When agents should choose local
-
-- User is editing `src/` and wants to test a workflow or agent change
-- `keystroke dev` or `keystroke start` is running (or should be started first)
-- Debugging with fast iteration; no deploy mentioned
-
-## When agents should choose cloud
-
-- User asks about deployed triggers, webhook URLs, or production runs
-- After `keystroke deploy` or when operating an existing platform project
-- Listing or invoking resources on the live environment
-
-If unsure, run `keystroke config show` and prefer **local** when the task is development/testing.

package/dist/skills-bundle/skills/keystroke-gateways/SKILL.md

@@ -1,43 +0,0 @@
----
-name: keystroke-gateways
-description: Chat with keystroke agents from Slack via @keystrokehq/slack — OAuth, dashboard binding, channel attach. Use when setting up messaging for agents.
-metadata:
-  keystroke-domain: gateways
----
-
-# Gateways
-
-Gateways route **Slack (and similar) messages** to an agent — users chat in-channel instead of using the CLI.
-
-## Setup (Slack)
-
-1. Set Slack app env vars in `.env` (see apps skill)
-2. `keystroke start` — open dashboard at `:3000`
-3. Complete Slack OAuth install
-4. **Gateways → Slack → Attach** — pick an agent key + channel
-5. Message the bot in Slack
-
-## What happens at runtime
-
-Inbound Slack event → lookup channel attachment → `runPrompt` for the bound agent → reply in thread.
-
-## Audit agent behavior from gateway traffic
-
-```bash
-keystroke agent sessions list <agent-key> --source gateway
-keystroke agent sessions get <agent-key> <session-id> --include messages,trace
-```
-
-## Troubleshooting
-
-| Issue       | Check                                                               |
-| ----------- | ------------------------------------------------------------------- |
-| Bot silent  | `keystroke agent sessions list` for errors; agent key on attachment |
-| OAuth fails | Slack redirect URLs match your dashboard origin                     |
-| Wrong agent | Re-bind attachment in dashboard                                     |
-
-## Next references
-
-- [slack-setup.md](references/slack-setup.md) — env vars, attach flow
-
-Related: [agents](.agents/skills/keystroke-agents/SKILL.md), [apps](.agents/skills/keystroke-apps/SKILL.md).

package/dist/skills-bundle/skills/keystroke-gateways/references/slack-setup.md

@@ -1,27 +0,0 @@
-# Slack gateway
-
-## .env
-
-Set Slack OAuth provider env vars in `.env` (client id, secret, signing secret) — then connect the Slack app with `keystroke connect slack`.
-
-## Install & bind
-
-1. `keystroke start`
-2. Dashboard → install Slack app (OAuth) — includes `chat:write.customize` for agent-named replies
-3. **Gateways → Slack → Attach** — agent key + channel (attach URLs include `team` + `channel` query params)
-4. Send a test message in Slack
-
-## Audit
-
-```bash
-keystroke agent sessions list <agent-key> --source gateway
-keystroke agent sessions get <agent-key> <session-id> --include messages,trace
-```
-
-## Common fixes
-
-| Issue         | Fix                                                |
-| ------------- | -------------------------------------------------- |
-| 401 on events | Check signing secret in `.env`                     |
-| No reply      | Session errors via `keystroke agent sessions list` |
-| Wrong agent   | Re-attach in dashboard                             |