deploy doesn't compile persona.ts (requires prebuilt persona.json); `persona compile` subcommand missing in 3.0.22

[khaliqgant]

Summary

agentworkforce deploy does not compile a TypeScript persona — it reads the path and JSON.parses it, so it requires a pre-built persona.json. Passing a persona.ts fails. Meanwhile the documented compile step (agentworkforce persona compile) is not present in the CLI version I have (3.0.22), so there's no first-party way to produce the persona.json that deploy needs. This bites any persona that does work at module-evaluation time (e.g. embedding a sibling file into an input at compile).

Environment

• CLI: agentworkforce 3.0.22 (also 3.0.21 via npx)
• @agentworkforce/persona-kit / @agentworkforce/runtime: ^3.0.24

Repro

# 1) deploy does not compile .ts — it JSON-parses the path
$ agentworkforce deploy ./churn-digest/persona.ts --mode cloud --dry-run --no-prompt
workforce deploy → .../churn-digest/persona.ts
agentworkforce deploy failed: persona JSON at .../churn-digest/persona.ts is not valid JSON:
  Unexpected token 'i', "import { r"... is not valid JSON

# 2) but the compile subcommand the docs/examples assume doesn't exist
$ agentworkforce persona compile ./churn-digest/persona.ts
Unknown subcommand "persona".

For reference, deploy's preflight is readFile(path) → JSON.parse(raw) (packages/deploy preflight.js), and the bundler copies persona.json verbatim (require('./persona.json')), so a JSON spec is mandatory.

The published examples assume the subcommand exists — e.g. agents/package.json:

"compile": "for d in */persona.ts; do agentworkforce persona compile \"$d\"; done"

Impact

There's no supported path from persona.ts → persona.json with this CLI, so deploy can't be used with TS-authored personas without hand-writing JSON or shipping your own build step. (Workaround I'm using: a small tsx-based script that imports each persona.ts from its real path and serializes the default export — this also preserves import.meta.url, which matters for personas that read sibling files at compile time.)

Requests (any one would resolve it)

1. deploy accepts a .ts path and compiles it in-process (detect extension; evaluate the module; serialize the default export) before preflight.
2. Ship/restore agentworkforce persona compile so the documented/example workflow works, and make deploy suggest it when handed a .ts.
3. At minimum, document the required compile step and ensure the example repos don't reference a subcommand the CLI doesn't provide.

Secondary: trigger-registry drift (confusing lint warnings)

Deploy-time trigger lint (CLI 3.0.22) disagrees with persona-kit 3.0.24's KNOWN_TRIGGERS:

• slack: deploy lint says known: app_mention, message.channels and warns on message.created, but persona-kit 3.0.24 lists message.created (and message.updated/deleted) as valid. Authors don't know which name actually fires at runtime.
• google-mail: deploy lint reports provider "google-mail" is not in the known-trigger registry (it's keyed as gmail in persona-kit's catalog, while the connect/provider id is google-mail).

These are non-fatal warnings, but the slack one is alarming because the event name determines whether the agent fires at all. Aligning the deploy CLI's registry with the shipped persona-kit catalog (or documenting the canonical event names per provider) would remove the ambiguity.

[khaliqgant]

Root cause of the secondary item (slack message.created "unknown trigger") — traced across repos

The Slack trigger warning is a stale-lint-data bug in the deploy CLI, not a problem with message.created. message.created is correct end-to-end:

Layer	Slack message event name	Source
Raw Slack Events API → Nango subscription	message.channels / message.groups / message.im / message.mpim, app_mention	cloud nango-integrations/slack-relay/syncs/fetch-channel-history.ts (MESSAGE_WEBHOOK_SUBSCRIPTIONS)
Adapter normalized event	message.created (.updated/.deleted)	relayfile-adapters packages/slack/src/slack-adapter.ts SUPPORTED_EVENTS + webhook-normalizer.ts mapSlackEventType
Generated trigger catalog	message.created	relayfile-adapters packages/core/src/triggers/catalog.generated.ts (sync-tested vs supportedEvents())
Cloud webhook router	stamps _webhook.eventType = "message.created"	cloud packages/web/lib/integrations/nango-webhook-router.ts
Cloud trigger → VFS path scope	message.created ✓ resolves to /slack/channels/*/messages + /slack/users/*/messages	cloud packages/core/src/relayfile/provider-contracts.ts (RESOURCE_TOKEN_ALIASES.message = ["message","messages","direct-messages","replies"])

So message.channels / app_mention are the raw upstream Slack webhook subscriptions; the whole stack normalizes them to message.created, which is what personas should declare (and what the cloud path-scope matcher accepts).

The drift: the deploy CLI lint pulls its registry from a stale persona-kit. Concretely, with CLI agentworkforce@3.0.22:

pear/node_modules/@agentworkforce/deploy/node_modules/@agentworkforce/persona-kit  →  3.0.15
  KNOWN_TRIGGERS.slack = ["app_mention", "message.channels"]      ← stale, raw Slack names

@agentworkforce/persona-kit@3.0.25 (current)
  KNOWN_TRIGGERS.slack = [ …, "message.created", "message.deleted", "message.updated", "reaction.added", … ]   ← correct

packages/persona-kit KNOWN_TRIGGERS (current) already matches the generated @relayfile/core catalog. The fix is to bump the @agentworkforce/persona-kit that @agentworkforce/deploy bundles (≥ 3.0.25) and cut a new CLU release, so deploy lints against the same normalized catalog the runtime/cloud use. (Same root cause covers the google-mail "unknown provider" warning — older catalog keys it as gmail.)

Net: non-fatal today (lint only warns), but it tells authors the wrong event name. No persona change needed — message.created is canonical.