@checkstack/automation-common 0.2.0

package/CHANGELOG.md

@@ -0,0 +1,442 @@
+# @checkstack/automation-common
+
+## 0.2.0
+
+### Minor Changes
+
+- e2d6f25: feat(automation): connection picker for integration actions + restore Integrations menu
+
+  Connection-backed automation actions (Jira, Teams, Webex) now render a
+  working connection picker plus cascading provider dropdowns in the
+  visual editor, and the Integrations entry is back in the user menu.
+
+  **Contract.** `ActionDefinition` gained an optional
+  `connectionProviderId` (and it is surfaced on `ActionInfoSchema` and
+  mapped in the `listActions` router). It carries the integration
+  provider's fully-qualified id, derived from the provider plugin's own
+  `pluginMetadata.pluginId` (never a hardcoded string), so the editor
+  knows which provider backs an action's dropdowns and it matches the
+  `qualifiedId` the integration provider registry assigns.
+
+  **Providers.** Jira, Teams and Webex each export
+  `*_PROVIDER_LOCAL_ID` / `*_PROVIDER_QUALIFIED_ID`, register their
+  provider with the local id, and add a `CONNECTION_OPTIONS`
+  (`"connectionOptions"`) resolver name. Their `post_message` /
+  issue actions set `connectionProviderId` and expose `connectionId`
+  as an `x-options-resolver` dropdown instead of a hidden field.
+
+  **Frontend bridge.** A new `useConnectionOptionResolvers` hook
+  (`@checkstack/automation-frontend`, which now depends on
+  `@checkstack/integration-common`) turns an action's
+  `x-options-resolver` schema fields into live data: the
+  `connectionOptions` resolver lists the provider's connections via
+  `listConnections`, and every other resolver name is forwarded to
+  `getConnectionOptions` for the selected `connectionId`, passing the
+  live form values as `context` for dependent fields. `ProviderActionBody`
+  now passes this map to `DynamicForm` (it was previously missing
+  entirely, so connection-backed actions had no working dropdowns).
+
+  **frontend-api.** `usePluginClient` procedures now also expose a typed
+  imperative `.call(input)` alongside `.useQuery` / `.useMutation`, for
+  async callbacks that cannot host a hook (such as a `DynamicForm`
+  options resolver). Additive, non-breaking.
+
+  **Integrations menu.** Re-added `IntegrationMenuItem` and a new
+  `IntegrationsLandingPage`, wired into `integration-frontend` as a list
+  route and a `UserMenuItemsSlot` entry under the "Configuration" group.
+
+  **Action card polish.** The action editor's secondary metadata (id,
+  description, failure behaviour) is now grouped into one quiet settings
+  panel with consistent small uppercase "eyebrow" labels, so the action's
+  own configuration stays the focal point. The raw failure checkbox was
+  replaced with the standard `Checkbox` control, and the provider action
+  picker / configuration sections gained consistent section headers and a
+  divider. The per-step "type" dropdown was removed: an action's kind is
+  fixed at creation, so changing it now means adding a new step and
+  deleting the old one (avoids the surprising full-config reset that
+  switching kinds used to trigger).
+
+  **Add-step picker.** Adding a step now opens a Home-Assistant-style
+  dialog where the operator decides the step type up front: an "Actions"
+  tab lists the registered provider actions grouped by category
+  (searchable; picking one presets the step's `action`), and a "Blocks"
+  tab lists the structural building blocks (choose / parallel / repeat /
+  etc.). Because the concrete action is chosen here, the in-card action
+  switcher was removed - a step's action is fixed once created. Composite
+  blocks now start with an empty child list (filled via the nested
+  add-step picker) instead of seeding an unconfigurable empty action.
+
+- e1a2077: feat(automation): reference artifacts by explicit action id (`artifacts.<id>.<name>`)
+
+  Multiple actions of the same type (e.g. two "create Jira issue" steps) used
+  to collide: both produced the artifact type `integration-jira.issue`, so a
+  template could only ever reach "the most recent one of that type". Artifacts
+  are now addressed by the producing action's instance `id` instead.
+
+  - Templates reference a produced artifact solely as
+    `{{ artifacts.<actionId>.<localArtifactName>.<field> }}`, e.g.
+    `{{ artifacts.open_jira.issue.issueKey }}`. The local artifact name is the
+    producing action's `produces` id with the owning plugin prefix stripped
+    (`integration-jira.issue` -> `issue`).
+  - `@checkstack/automation-backend`: the dispatch engine nests each produced
+    artifact under `artifacts[actionId][localName]` in the template scope and
+    records the `actionId` on the artifact row. `validate-definition` now
+    enforces that action ids are unique within an automation and that every
+    artifact-producing action carries an id.
+  - `@checkstack/automation-common`: action `id` is constrained to an
+    identifier (`/^[a-zA-Z_][a-zA-Z0-9_]*$/`) so it is always usable as a
+    plain template segment. The variable-scope resolver surfaces
+    `artifacts.<id>.<name>` (with full field completion) in the editor.
+  - `@checkstack/automation-frontend`: the action editor now has editable `Id`
+    and `Description` inputs (previously settable only via the YAML view), and
+    new steps get an auto-assigned, unique, log-friendly default id that the
+    operator can rename. Action ids are recorded on every run step, so run
+    logs are parseable by id regardless of kind.
+
+  **BREAKING (beta):** the previous flat, type-keyed scope form
+  `{{ artifacts["integration-jira.issue"] }}` is removed. Reference artifacts
+  by the producing action's id instead. Action ids may no longer contain
+  hyphens or dots (identifier characters only). Artifacts are per-run and
+  ephemeral, so no stored-data migration is needed.
+
+- 41c77f4: feat(automation): native per-editor context for script actions (typed `context` for TS, `$ENV` for shell)
+
+  Script action editors had a confusing dual system: the TypeScript editor
+  type-checked `{{ }}` template text as code (so `{{ artifact.x }}` errored
+  with "Cannot find name"), and the runtime never actually populated the
+  `context` object. This standardises on a single, native context-access
+  mechanism per editor kind.
+
+  **Run scope reaches actions.** `ActionExecutionContext` gains a `scope`
+  (`{ trigger, artifacts, vars, repeat? }`), populated by the dispatch
+  engine from the same scope it already uses for `{{ }}` rendering. Actions
+  that need broad context (the script actions) read from it instead of
+  having to declare every artifact type in `consumes`. Additive and
+  optional, so existing actions are unaffected.
+
+  **TypeScript / JavaScript → typed `context`.** `run_script` now builds
+  `context` from the run scope, so `context.trigger.payload`,
+  `context.artifacts`, `context.var`, `context.repeat`, and
+  `context.automation` are populated at run time (previously
+  `context.trigger` was always empty). The editor types match via
+  `generateAutomationContextTypes`.
+
+  **Shell → `$CHECKSTACK_*` env vars.** `run_shell` flattens the run scope
+  into environment variables (e.g. `$CHECKSTACK_TRIGGER_PAYLOAD_TITLE`,
+  `$CHECKSTACK_ARTIFACT_INTEGRATION_JIRA_ISSUE_ISSUEKEY`). Arrays become a
+  single newline-separated var (iterate with `while IFS= read -r x; do …;
+done <<< "$VAR"`). Every value is a plain string — no JSON blob, since
+  the container has no `jq` to parse one. A shared `toShellEnvKey`
+  helper (in `@checkstack/automation-common`) derives the names so the
+  shell editor's `$` autocomplete lists exactly what the runtime injects.
+
+  **One syntax per field kind (editor + runtime).** `MultiTypeEditorField`
+  no longer offers `{{ }}` autocomplete in `typescript` / `javascript` /
+  `shell` editors, and the dispatch engine no longer template-renders
+  native-code config fields (those whose `x-editor-types` is a code type) —
+  so `{{ }}` can't be used in a script by accident. Text / markup editors
+  (`raw`, `json`, `yaml`, `xml`, `markdown`, `formdata`) and plain string
+  fields keep `{{ }}` as before. Because both the automation and
+  health-check editors share `MultiTypeEditorField`, they behave
+  identically.
+
+  **Script-editor IntelliSense polish.** The code editors got a few
+  ergonomic fixes so the typed context is actually usable: the suggestion
+  **details panel auto-opens** (so long completion names are legible
+  on-focus, not hidden behind the chevron); word-based keyword noise is
+  disabled in favour of language-service + provider completions; and a
+  TS/JS completion provider makes `context.artifacts.` list the in-scope
+  artifact ids and **auto-convert the dot to bracket notation** —
+  `context.artifacts["integration-jira.issue"]` — since those ids aren't
+  valid identifiers. (Driven by a new opt-in `dottedKeyCompletions` prop on
+  the editor / `DynamicForm`.)
+
+  **BREAKING (beta):** `{{ }}` interpolation inside a script action's
+  `script` field (shell or TypeScript) is no longer expanded at run time —
+  read run data via the typed `context` object (TS) or `$CHECKSTACK_*` env
+  vars (shell) instead. Non-script config fields are unchanged.
+
+  Also fixes: switching a provider action in the visual editor now resets
+  its config, so the validator no longer reports the previous action's keys
+  as unrecognised.
+
+- 41c77f4: feat(automation): Phase 11 — editor primitives + context type generation
+
+  Lays the UI + type-generation groundwork for Phase 12's visual automation
+  editor. Every primitive reuses the existing Monaco wrapper / template
+  engine / `jsonSchemaToTypeScript` helper rather than building parallel
+  infrastructure.
+
+  **`@checkstack/automation-common` — `resolveVariableScope`**
+
+  Pure walker that returns the in-scope `{{ … }}` paths at a given action
+  position. Conservative scoping rules: linear-upstream variables /
+  artifacts only (no leaking across `choose` / `parallel` / `repeat`
+  branches), `repeat.index` / `repeat.item` exposed only inside a `repeat`,
+  and trigger.payload modelled as a **discriminated union over
+  `trigger.event`** — every payload field surfaces; ones that come from a
+  subset of subscribed triggers carry a `conditionalOnTriggers` annotation
+  so the picker can render an "Only when …" hint. Earlier draft used
+  schema-intersection; switched to discriminated unions per review
+  feedback so Monaco can narrow correctly inside event-gated branches.
+
+  **Condition-aware narrowing.** When the path descends through a
+  `choose-when`, the resolver parses the branch's `when:` expression and
+  statically pins `trigger.event` to the set the condition allows —
+  patterns covered are `trigger.event == "X"` (either operand order),
+  `trigger.event != "X"`, `||`/`&&` of those, and `{ and: [...] }` /
+  `{ or: [...] }` combinators. So an action inside
+  `when: 'trigger.event == "incident.created"'` sees only the
+  `incident.created` variant in scope, the `conditionalOnTriggers`
+  annotation disappears, and other-trigger fields drop out entirely.
+  Nested choose branches compound (intersection). Anything outside the
+  covered patterns falls back to the full union — better to show every
+  field than guess wrong.
+
+  **`@checkstack/template-engine`**
+
+  The expression AST (`Expr`, `BinaryExpr`, `MemberExpr`, etc.) is now a
+  public export — the resolver's condition-narrowing walker needs to
+  inspect parsed condition trees. `ParsedCondition.root` is tightened
+  from `unknown` to `Expr` so consumers don't need to cast.
+
+  **`@checkstack/automation-frontend` — `generateAutomationContextTypes`**
+
+  Consumes `resolveVariableScope`'s output + the trigger / artifact
+  registries and emits the `declare const context: { … }` TS declaration
+  that `integration-script.run_script`'s Monaco editor injects via
+  `addExtraLib`. The emitted shape:
+
+  ```ts
+  type AutomationTrigger =
+    | { event: "incident.created"; payload: { … } }
+    | { event: "incident.resolved"; payload: { … } };
+
+  declare const context: {
+    trigger: AutomationTrigger;
+    artifacts: { "jira.issue"?: { key: string; … }; … };
+    var: { foo?: string; … };
+    repeat: { index: number; item: unknown };  // only when inside a repeat
+  };
+  ```
+
+  `jsonSchemaToTypeScript` from `@checkstack/ui` is reused via a deep
+  import (rather than the barrel) so the bun test runner doesn't try to
+  load Monaco's Vite-only `?worker` modules during unit tests.
+
+  **`@checkstack/ui` — new editor primitives**
+
+  - `TemplateValueInput` — single-line `{{ }}` autocomplete input.
+    Extracted from `DynamicForm/KeyValueEditor`'s previously-private
+    `TemplateInput` so other editor surfaces can share it without
+    rebuilding the picker UX. `KeyValueEditor` is now a one-line
+    delegation; `detectTemplateContext` is also exported.
+  - `VariablePicker` — hierarchical popover for the explicit "fx" /
+    "Insert variable" workflow. Renders a filterable tree of
+    `VariableNode`s with type chips and `Only when …` hints sourced from
+    the resolver's `conditionalOnTriggers`. Defaults to a small "fx" pill
+    trigger; callers can pass a custom one.
+  - `TemplateInput` — high-level mode switcher: `text` mode delegates to
+    `TemplateValueInput`, all other modes (`code` / `bash` / `json` /
+    `yaml`) delegate to `CodeEditor` with the matching language so the
+    action editor can swap widgets purely from the action's
+    `x-editor-types` annotation without touching the consuming code.
+  - `TemplateInputToggle` — the small "fx" pill that flips a typed input
+    (number / select / date / …) into template mode and back. Auto-infers
+    template mode when the saved value already starts with `{{`, so
+    round-tripping a previously-templated automation works out of the
+    box. Render-prop API for the typed editor so consumers keep control
+    over their own input shape.
+  - `ActionCard` — collapsible card that hosts a single action in the
+    visual editor. Decoupled from `DynamicForm` so container blocks
+    (`ChooseBlock` / `ParallelBlock` / `RepeatBlock` in Phase 12) can use
+    it as a structural shell over their own children. Toggle / delete /
+    drag handle are conditionally rendered on their callback's presence.
+
+  Storybook stories shipped for each of the new primitives.
+
+  **`@checkstack/integration-script-backend`**
+
+  `ScriptContext` docstring and the `scriptRunConfigSchema.script` field
+  description now point at `generateAutomationContextTypes` so the Phase
+  12 editor wiring is unambiguous — the runtime payload type stays
+  `Record<string, unknown>` (the runner can't know the trigger schema),
+  but the **editor** narrows it per-automation from the subscribed
+  triggers' payload schemas.
+
+- 41c77f4: feat(automation): backend RPC router with the full 15-endpoint contract
+
+  Wires up `core/automation-backend/src/router.ts` covering automation CRUD,
+  definition validation, manual runs, run history, registry introspection,
+  and a template playground. The contract is refactored to use the
+  project's `proc()` pattern so `autoAuthMiddleware` enforces `read` /
+  `manage` access automatically, and `AutomationApi` is exported via
+  `createClientDefinition` for the frontend client.
+
+- 41c77f4: feat(automation): one-time migration of webhook subscriptions + remove legacy integration backend
+
+  **BREAKING CHANGES** (platform is in BETA — no major bump):
+
+  - `IntegrationProvider` no longer carries `config` (subscription
+    config) or `deliver`. The interface now models a connection provider
+    only: connection schema + `getConnectionOptions` + `testConnection`.
+  - The legacy subscription / delivery-log / event endpoints
+    (`listSubscriptions`, `createSubscription`, `getDeliveryLogs`,
+    `listEventTypes`, …) are removed from `integrationContract`.
+  - `delivery-coordinator`, `hook-subscriber`, `event-registry`, and the
+    `integrationEventExtensionPoint` are deleted. Plugins that
+    previously called `integrationEvents.registerEvent(...)` now
+    register their hooks as automation triggers via
+    `automationTriggerExtensionPoint.registerTrigger(...)`.
+  - Frontend pages `IntegrationsPage` and `DeliveryLogsPage` are gone;
+    the integration plugin's only remaining UI is connection
+    management. Subscription management lives under `/automation/...`.
+  - `webhook_subscriptions` and `delivery_logs` tables stay in the
+    database for one release as a safety net (no code reads or writes
+    them), and will be dropped in a follow-up migration.
+
+  **New**:
+
+  - `jira.create_issue`, `teams.post_message`, `webex.post_message`,
+    `webhook.send`, `integration-script.run_shell`, and
+    `integration-script.run_script` actions registered against the
+    Automation Platform with matching `*.message`, `*.delivery`,
+    `shell.result`, and `script.result` artifact types. The script
+    plugin exposes **two** actions — `run_shell` runs bash via the
+    shared `ShellScriptRunner` (Monaco `shell` editor), `run_script`
+    runs an ESM module in a Bun subprocess via `EsmScriptRunner`
+    (Monaco `typescript` editor + `defineIntegration` helper) — to
+    preserve the legacy provider split. `jira.create_issue` keeps the
+    dynamic field-mapping dropdown (driven by
+    `JIRA_RESOLVERS.FIELD_OPTIONS`).
+  - One-time data migration runs on boot in
+    `automation-backend.afterPluginsReady`. It reads
+    `webhook_subscriptions` via a new service RPC
+    `IntegrationApi.listLegacySubscriptions`, translates each row into
+    a single-trigger / single-action automation (marked with
+    `managed_by = "migrated-subscription:<id>"`), and is idempotent
+    across restarts.
+  - Failed translations are recorded in a new
+    `automation_migration_failures` table and surfaced via
+    `AutomationApi.listMigrationFailures` /
+    `acknowledgeMigrationFailure` so admins can review and re-create
+    failed entries by hand.
+
+- 4832e33: fix(automation): insert runtime-parseable `templateRef` from editor autocomplete + variable picker, with array indexing
+
+  The automation editor's `{{ }}` autocomplete and the `fx` variable picker
+  previously inserted the canonical dotted path (e.g.
+  `artifact.integration-jira.issue.issueKey`), which the template engine
+  cannot parse when an artifact id contains dots or hyphens, and which used
+  the singular `artifact`/`var` namespaces the runtime template context does
+  not expose. They now insert the runtime-parseable `templateRef` form -
+  plural top-level namespace (`artifacts`/`variables`) plus bracket notation
+  for non-identifier segments, e.g. `artifacts["integration-jira.issue"].issueKey`.
+
+  - `@checkstack/automation-common`: `VariableEntry` gains `templateRef`
+    (runtime-parseable insertion form) and `referenceable`, alongside the
+    unchanged canonical `path`. New exported helpers `isTemplateIdentifier`,
+    `appendTemplateSegment`, and `appendArrayIndex` build the form. Scope
+    derivation now descends into `array` schemas, offering both the whole
+    array and a representative element subtree (`tags[0]`, `comments[0].author`,
+    nested `matrix[0][0]`).
+  - `CompletionField` / `TemplateProperty` / `VariableNode` carry a
+    `templateRef` alongside the canonical `path`.
+  - The staged completion provider's field label, filter/match, insert text,
+    and value-stage field lookup all operate in `templateRef` space. The
+    expression tokenizer now emits bracket tokens and reconstructs the full
+    `foo["bar"].baz` / `foo["bar"].list[0]` access chain (normalising single
+    quotes to the stored double-quoted form, and supporting bare numeric array
+    indices) so value-stage enum suggestions resolve for bracket-notation and
+    indexed fields.
+  - `VariablePicker` and the `DynamicForm` template inserters write the
+    `templateRef` (falling back to `path` when absent).
+  - Shell-env (`$CHECKSTACK_*`) name derivation deliberately keeps using the
+    canonical dotted `path`, so the suggested env names stay byte-identical
+    to the backend's path-based injection. Script-context type generation is
+    unchanged.
+  - `@checkstack/integration-script-backend`: shell-script actions now also
+    expose array elements as indexed `$CHECKSTACK_*_<i>` env vars (and
+    `$CHECKSTACK_*_<i>_<field>` for object elements), alongside the existing
+    whole-array newline-joined var, so the runtime injects exactly the
+    array-element names the editor now suggests.
+
+- 6d52276: feat(automation): expose `trigger.actor` so automations can filter on who/what caused an event
+
+  Every platform event now carries an **actor** - the user, application (API
+  client), service (backend-to-backend), or `system` (background /
+  unauthenticated) that caused it - and the automation engine surfaces it to
+  automations as `trigger.actor`. This lets a trigger filter gate on the
+  origin of the event it reacts to:
+
+  ```text
+  {{ trigger.actor.type == "system" }}      # auto-created by the platform
+  {{ trigger.actor.type == "user" }}         # a human
+  {{ trigger.actor.id == "app-deploybot" }}  # a specific application
+  ```
+
+  `trigger.actor` is available on **every** trigger - it is injected by the
+  platform, not declared per trigger - and editor autocomplete + Run Script
+  context types include `trigger.actor.{type,id,name}`.
+
+  How it works:
+
+  - **`@checkstack/common`** adds the canonical `Actor` type / `ActorSchema`
+    and `SYSTEM_ACTOR`.
+  - **`@checkstack/backend-api`** adds `resolveActor(user)` and a
+    `HookEventMeta` envelope. The hook listener / `onHook` signature gains an
+    optional second `meta` argument (additive, backward compatible).
+  - **`@checkstack/backend`** wraps emitted hooks in an envelope so the actor
+    travels with the payload through the distributed queue, unwrapping it
+    before delivery. The RPC emit path captures the authenticated caller;
+    background emits default to the system actor. Raw/legacy queue data is
+    treated as a system-actor payload, so delivery stays backward compatible.
+  - **`@checkstack/automation-backend`** threads the actor into the dispatch
+    scope (`trigger.actor`), available to trigger filters, top-level
+    conditions, and all run templates, and persisted in the run's scope
+    snapshot. Manual runs are attributed to the invoking user.
+  - **`@checkstack/automation-common`** / **`@checkstack/automation-frontend`**
+    expose `trigger.actor` in the editor variable scope and the generated
+    Run Script `context.trigger.actor` types.
+
+  No database migration and no per-trigger schema changes: the actor rides as
+  event-envelope metadata and in the run scope snapshot.
+
+- 6d52276: feat(automation): expose `trigger.id` and reconcile the trigger scope so multiple triggers are distinguishable
+
+  Automations with more than one trigger could not tell which trigger fired:
+  the trigger id wasn't queryable, and scripts only received `trigger.event`
+  (so two triggers on the same event were indistinguishable). This exposes a
+  consistent trigger contract everywhere - `trigger.id`, `trigger.event`,
+  `trigger.actor`, `trigger.payload` - in templates, shell, and TypeScript
+  scripts.
+
+  - **`trigger.id` is now available** in templates (`{{ trigger.id }}`) and in
+    the script context (`context.trigger.id`). It is typed as the **literal
+    union** of the automation's trigger ids, so it discriminates triggers -
+    including two subscribed to the same `event`.
+  - **Auto-generated trigger ids.** The editor now assigns a unique, log-
+    friendly id to every trigger (derived from its event, e.g.
+    `incident_created`, deduped as `incident_created_2`), mirroring action ids:
+    seeded on the starter automation, assigned on add, and re-filled on blur.
+  - **Scripts now receive `trigger.id` and `trigger.actor`.** The
+    `ActionRunScope` projection previously dropped both (it only forwarded
+    `event` + `payload`), so `context.trigger.actor` was typed but never
+    populated - that gap is fixed.
+  - **Scope key reconciled.** The internal dispatch scope now exposes
+    `trigger.event` as the canonical key (matching the editor and script
+    contract) instead of leaking `trigger.eventId`; `trigger.eventId` is kept
+    as a back-compat alias, so `{{ trigger.event }}` now resolves in template
+    fields where it previously returned `undefined`.
+
+  No database migration: the actor and id ride in the run scope snapshot. A
+  shared `deriveTriggerId` is exported from `@checkstack/automation-common` so
+  the editor, generated script types, and the runtime all agree on derived ids.
+
+### Patch Changes
+
+- Updated dependencies [41c77f4]
+- Updated dependencies [6d52276]
+  - @checkstack/template-engine@0.2.0
+  - @checkstack/common@0.12.0
+  - @checkstack/signal-common@0.2.5

package/package.json

@@ -0,0 +1,33 @@
+{
+  "name": "@checkstack/automation-common",
+  "version": "0.2.0",
+  "license": "Elastic-2.0",
+  "type": "module",
+  "exports": {
+    ".": {
+      "types": "./src/index.ts",
+      "import": "./src/index.ts"
+    }
+  },
+  "dependencies": {
+    "@checkstack/common": "0.11.0",
+    "@checkstack/signal-common": "0.2.4",
+    "@checkstack/template-engine": "0.1.0",
+    "@orpc/contract": "^1.13.14",
+    "zod": "^4.0.0"
+  },
+  "devDependencies": {
+    "@checkstack/scripts": "0.3.3",
+    "@checkstack/tsconfig": "0.0.7",
+    "typescript": "^5.7.2"
+  },
+  "scripts": {
+    "typecheck": "tsgo -b",
+    "lint": "bun run lint:code",
+    "lint:code": "eslint . --max-warnings 0",
+    "test": "bun test"
+  },
+  "checkstack": {
+    "type": "common"
+  }
+}

package/src/access.ts

@@ -0,0 +1,32 @@
+import { access } from "@checkstack/common";
+
+/**
+ * Access rules for the Automation plugin.
+ */
+export const automationAccess = {
+  /**
+   * Read access to automations and run history. Required to list automations
+   * and inspect past runs.
+   */
+  read: access(
+    "automation",
+    "read",
+    "View automations and run history",
+  ),
+  /**
+   * Manage automations: create, edit, enable/disable, delete, manually run.
+   */
+  manage: access(
+    "automation",
+    "manage",
+    "Create, edit, enable, disable, delete, and manually run automations",
+  ),
+};
+
+/**
+ * All access rules for registration with the plugin system.
+ */
+export const automationAccessRules = [
+  automationAccess.read,
+  automationAccess.manage,
+];

package/src/index.ts

@@ -0,0 +1,8 @@
+export * from "./access";
+export * from "./plugin-metadata";
+export * from "./routes";
+export * from "./schemas";
+export * from "./rpc-contract";
+export * from "./signals";
+export * from "./variable-scope";
+export * from "./shell-env";

package/src/plugin-metadata.ts

@@ -0,0 +1,9 @@
+import { definePluginMetadata } from "@checkstack/common";
+
+/**
+ * Plugin metadata for the automation plugin.
+ * Exported from the common package so both backend and frontend can reference it.
+ */
+export const pluginMetadata = definePluginMetadata({
+  pluginId: "automation",
+});

package/src/routes.ts

@@ -0,0 +1,19 @@
+import { createRoutes } from "@checkstack/common";
+
+/**
+ * Route definitions for the automation plugin.
+ */
+export const automationRoutes = createRoutes("automation", {
+  /** Automation list page */
+  list: "/",
+  /** Create new automation */
+  create: "/new",
+  /** Edit a single automation */
+  edit: "/:automationId",
+  /** Run history for a single automation */
+  runs: "/:automationId/runs",
+  /** Drill into a single run */
+  runDetail: "/:automationId/runs/:runId",
+  /** Template playground (live preview of templates with sample payloads) */
+  playground: "/playground",
+});