@elevasis/sdk 1.21.0 → 1.22.1

package/reference/claude-config/rules/platform.md

@@ -1,42 +1,42 @@
----
-description: Platform conventions -- SDK workflows, agents, deployment, resource registry
-paths:
-  - operations/**
----
-
-# Platform (Elevasis SDK)
-
-## Safety Invariants
-
-- Every workflow implements `WorkflowDefinition` from `@elevasis/sdk` with: `config`, `contract` (Zod schemas), `steps` map, and `entryPoint`
-- Input/output schemas MUST come from `@shared/types` -- never define inline Zod schemas in workflow files
-- `operations/src/index.ts` default-exports a `DeploymentSpec` with `workflows` and `agents` arrays -- every resource must be registered here
-- Always run `check` before `deploy`
-
-## Imports
-
-- `@elevasis/sdk` for types (`WorkflowDefinition`, `DeploymentSpec`)
-- `@elevasis/sdk/worker` for runtime utilities (`platform`, adapters: `llm`, `storage`, `scheduler`, `notifications`, `acqDb`, `list`)
-- `@shared/*` resolves to `../shared/*` for shared type imports
-- Never import from `ui/src/` -- separate runtimes
-
-## Key Rules
-
-- Use typed adapters over raw `platform.call()` whenever a typed adapter exists
-- `version` in resource config is semver -- bump on contract changes
-- `status` is `'dev'` or `'prod'` -- new resources start as `'dev'`
-
-## CLI Commands
-
-| Command                              | Purpose                       |
-| ------------------------------------ | ----------------------------- |
-| `pnpm -C operations run check`       | Validate resource definitions |
-| `pnpm -C operations run deploy`      | Deploy to dev                 |
-| `pnpm -C operations run deploy:prod` | Deploy to production          |
-
-## Detailed Reference
-
-- `node_modules/@elevasis/sdk/reference/scaffold/operations/workflow-recipes.md` -- workflow anatomy, adapter patterns, trigger patterns
-- `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-resource.md` -- end-to-end resource authoring guide
-- `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md` -- lead-gen UI, hooks, list/member state, artifacts, and workflow adapter extension guide
-- SDK reference docs: `operations/node_modules/@elevasis/sdk/reference/` (concepts, framework, platform-tools, runtime, CLI)
+---
+description: Platform conventions -- SDK workflows, agents, deployment, resource registry
+paths:
+  - operations/**
+---
+
+# Platform (Elevasis SDK)
+
+## Safety Invariants
+
+- Every workflow implements `WorkflowDefinition` from `@elevasis/sdk` with: `config`, `contract` (Zod schemas), `steps` map, and `entryPoint`
+- Input/output schemas MUST come from `@core/types` or browser-safe sibling schema files -- never define reusable workflow contracts inline in Node-only workflow files
+- `operations/src/index.ts` default-exports a `DeploymentSpec` with `workflows` and `agents` arrays -- every resource must be registered here
+- Always run `check` before `deploy`
+
+## Imports
+
+- `@elevasis/sdk` for types (`WorkflowDefinition`, `DeploymentSpec`)
+- `@elevasis/sdk/worker` for runtime utilities (`platform`, adapters: `llm`, `storage`, `scheduler`, `notifications`, `acqDb`, `list`)
+- `@core/*` resolves to `../core/*` for shared type and org-model imports
+- Never import from `ui/src/` -- separate runtimes
+
+## Key Rules
+
+- Use typed adapters over raw `platform.call()` whenever a typed adapter exists
+- `version` in resource config is semver -- bump on contract changes
+- `status` is `'dev'` or `'prod'` -- new resources start as `'dev'`
+
+## CLI Commands
+
+| Command                              | Purpose                       |
+| ------------------------------------ | ----------------------------- |
+| `pnpm -C operations run check`       | Validate resource definitions |
+| `pnpm -C operations run deploy`      | Deploy to dev                 |
+| `pnpm -C operations run deploy:prod` | Deploy to production          |
+
+## Detailed Reference
+
+- `node_modules/@elevasis/sdk/reference/scaffold/operations/workflow-recipes.md` -- workflow anatomy, adapter patterns, trigger patterns
+- `node_modules/@elevasis/sdk/reference/scaffold/recipes/add-a-resource.md` -- end-to-end resource authoring guide
+- `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md` -- lead-gen UI, hooks, list/member state, artifacts, and workflow adapter extension guide
+- SDK reference docs: `operations/node_modules/@elevasis/sdk/reference/` (concepts, framework, platform-tools, runtime, CLI)

package/reference/claude-config/rules/shared-types.md

@@ -1,46 +1,49 @@
----
-description: Shared type boundary -- what belongs in core/types, import rules, schema conventions
-paths:
-  - core/types/**
----
-
-# Shared Types
-
-`shared/` is the type boundary between the frontend (`src/`) and platform (`operations/`). Both runtimes import from here but never from each other.
-
-## What Belongs Here
-
-- Zod schemas for workflow input/output contracts
-- TypeScript types inferred from those schemas (`z.infer<typeof schema>`)
-- Domain types referenced by both runtimes (status enums, entity shapes)
-- Shared constants
-
-## What Does NOT Belong Here
-
-- React components, hooks, or anything importing `react`
-- SDK runtime code or anything importing `@elevasis/sdk/worker`
-- Browser APIs or Node-specific APIs
-- Implementation logic -- types and constants only
-
-## Schema Convention
-
-Define Zod schemas first, then infer the type:
-
-```typescript
-export const fooInputSchema = z.object({ ... })
-export type FooInput = z.infer<typeof fooInputSchema>
-```
-
-Name schemas `<name>InputSchema` / `<name>OutputSchema`. Name types `<Name>Input` / `<Name>Output`.
-
-## File Organization
-
-Types live in `shared/types/`. The directory structure:
-
-- `shared/types/index.ts` -- Main entry point, re-exports from domain files
-- As the project grows: split into domain files within the directory (e.g., `shared/types/billing.ts`, `shared/types/auth.ts`)
-- Re-export new domain files from `shared/types/index.ts`
-
-## Path Alias
-
-Both tsconfigs resolve `@shared/*` to `shared/*`. Always use `@shared/types` (not relative paths) when importing from `src/` or `operations/src/`.
+---
+description: Core type boundary -- what belongs in core/types, import rules, schema conventions
+paths:
+  - core/types/**
+---
+
+# Core Types
+
+`core/types/` is the browser-safe type boundary between the frontend (`ui/`) and platform runtime (`operations/`). Both runtimes import from here but never from each other.
+
+Keep this as a standalone rule because it autoloads only for `core/types/**` edits. Operations workflow rules can reference this boundary, but shared browser-safe contract guidance belongs here.
+
+## What Belongs Here
+
+- Zod schemas for workflow input/output contracts
+- TypeScript types inferred from those schemas (`z.infer<typeof schema>`)
+- Domain types referenced by both runtimes (status enums, entity shapes)
+- Shared constants
+
+## What Does NOT Belong Here
+
+- React components, hooks, or anything importing `react`
+- SDK runtime code or anything importing `@elevasis/sdk/worker`
+- Browser APIs or Node-specific APIs
+- Implementation logic -- types and constants only
+
+## Schema Convention
+
+Define Zod schemas first, then infer the type:
+
+```typescript
+export const fooInputSchema = z.object({ ... })
+export type FooInput = z.infer<typeof fooInputSchema>
+```
+
+Name schemas `<name>InputSchema` / `<name>OutputSchema`. Name types `<Name>Input` / `<Name>Output`.
+
+## File Organization
+
+Types live in `core/types/`. The directory structure:
+
+- `core/types/index.ts` -- Main entry point, re-exports from domain files
+- `core/types/entities.ts` -- Entity contracts extending published base entities
+- As the project grows: split into domain files within the directory (e.g., `core/types/billing.ts`, `core/types/auth.ts`)
+- Re-export new domain files from `core/types/index.ts`
+
+## Path Alias
+
+Project tsconfigs resolve `@core/*` to `core/*`. Always use `@core/types` or `@core/types/entities` (not relative paths) when importing shared contracts from `ui/` or `operations/src/`.

package/reference/claude-config/rules/task-tracking.md

@@ -1,47 +1,47 @@
----
-description: In-progress task conventions -- doc format, status values, auto-save behavior
----
-
-# Task Tracking
-
-## Status Values
-
-Exactly three values for frontmatter `status`: `planned`, `in-progress`, `complete`.
-
-## Doc Format
-
-- Frontmatter: `title`, `description`, `status` only -- nothing else belongs in task-doc frontmatter; `resume_context` is DB-canonical on `prj_tasks`
-- Sections: Objective, Plan, Progress, Resume Context
-- Progress subsections use markers: `### Step N: Title -- PENDING`, `-- IN PROGRESS`, `-- COMPLETE`
-
-## Auto-Update Behavior
-
-- When working on a tracked task, update the Progress section when a plan step transitions:
-  - PENDING -> IN PROGRESS (starting work on a step)
-  - IN PROGRESS -> COMPLETE (finishing a step)
-- Do NOT update on every action -- only on step transitions
-
-## Auto-Save Behavior
-
-The agent auto-saves progress (no user action needed) when:
-
-- The conversation context is getting heavy (many tool calls, large file reads)
-- The user appears to be wrapping up (thanks, goodbye, switching topics)
-- Significant progress has been made (2+ steps completed without saving)
-- Before a context reset
-
-Auto-save updates the task doc's Progress and Resume Context sections silently, then briefly confirms. The canonical persistence path is `pnpm elevasis-sdk project:task:save` -- the CLI writes through to `prj_tasks.resume_context` (JSONB) so another agent can resume without re-deriving intent.
-
-## Completion Suggestions
-
-When all plan steps are marked COMPLETE, **suggest** completing the task -- never auto-invoke. Ask: "All steps for '{task}' look done. Want me to finalize it?"
-
-## Where Tasks Live
-
-Project tasks for this template live in the `prj_tasks` Supabase table, not in repo-local files. Operate on them via the SDK CLI:
-
-- `pnpm elevasis-sdk project:work` -- entrypoint for task work (resume / new intent detection)
-- `pnpm elevasis-sdk project:list` -- portfolio / task listing
-- `pnpm elevasis-sdk project:task:save` -- persist progress + `resume_context` to the DB
-
-The monorepo-side `/work` slash command still exists for monorepo task docs under `apps/docs/content/docs/in-progress/**`; that flow is unchanged. What went away is the external template's own `/work` skill and its `docs/in-progress/` directory -- external projects now route through the DB-backed `project:*` surface above.
+---
+description: In-progress task conventions -- doc format, status values, auto-save behavior
+---
+
+# Task Tracking
+
+## Status Values
+
+Exactly three values for frontmatter `status`: `planned`, `in-progress`, `complete`.
+
+## Doc Format
+
+- Frontmatter: `title`, `description`, `status` only -- nothing else belongs in task-doc frontmatter; `resume_context` is DB-canonical on `prj_tasks`
+- Sections: Objective, Plan, Progress, Resume Context
+- Progress subsections use markers: `### Step N: Title -- PENDING`, `-- IN PROGRESS`, `-- COMPLETE`
+
+## Auto-Update Behavior
+
+- When working on a tracked task, update the Progress section when a plan step transitions:
+  - PENDING -> IN PROGRESS (starting work on a step)
+  - IN PROGRESS -> COMPLETE (finishing a step)
+- Do NOT update on every action -- only on step transitions
+
+## Auto-Save Behavior
+
+The agent auto-saves progress (no user action needed) when:
+
+- The conversation context is getting heavy (many tool calls, large file reads)
+- The user appears to be wrapping up (thanks, goodbye, switching topics)
+- Significant progress has been made (2+ steps completed without saving)
+- Before a context reset
+
+Auto-save updates the task doc's Progress and Resume Context sections silently, then briefly confirms. The canonical persistence path is `pnpm elevasis-sdk project:task:save` -- the CLI writes through to `prj_tasks.resume_context` (JSONB) so another agent can resume without re-deriving intent.
+
+## Completion Suggestions
+
+When all plan steps are marked COMPLETE, **suggest** completing the task -- never auto-invoke. Ask: "All steps for '{task}' look done. Want me to finalize it?"
+
+## Where Tasks Live
+
+Project tasks for this template live in the `prj_tasks` Supabase table, not in repo-local files. Operate on them via the SDK CLI:
+
+- `pnpm elevasis-sdk project:work` -- entrypoint for task work (resume / new intent detection)
+- `pnpm elevasis-sdk project:list` -- portfolio / task listing
+- `pnpm elevasis-sdk project:task:save` -- persist progress + `resume_context` to the DB
+
+The monorepo-side `/work` slash command still exists for monorepo task docs under `apps/docs/content/docs/in-progress/**`; that flow is unchanged. What went away is the external template's own `/work` skill and its `docs/in-progress/` directory -- external projects now route through the DB-backed `project:*` surface above.