@elevasis/sdk 1.0.2 → 1.2.0

package/dist/templates.js

@@ -1,2253 +0,0 @@
-// package.json
-
-// src/cli/commands/templates/core/workspace.ts
-var TEMPLATE_VERSION = 34;
-function configTemplate() {
-  return `import type { ElevasConfig } from '@elevasis/sdk'
-
-export default {
-  templateVersion: ${TEMPLATE_VERSION},
-  // defaultStatus: 'dev',     // Default status for new resources ('dev' | 'prod')
-  // dev: { port: 5170 },      // Local API port (internal development only)
-} satisfies ElevasConfig
-`;
-}
-function gitignoreTemplate(ctx = {}) {
-  let content = `node_modules/
-.env
-dist/
-__elevasis_worker.ts
-.claude/settings.local.json
-.claude/memory/
-package-lock.json
-`;
-  if (ctx.hasUI) {
-    content += `ui/node_modules/
-ui/dist/
-`;
-  }
-  return content;
-}
-
-// src/cli/commands/templates/core/claude.ts
-function claudeSettingsTemplate() {
-  return JSON.stringify(
-    {
-      autoCompact: false,
-      statusLine: {
-        type: "command",
-        command: "node .claude/scripts/statusline-command.js"
-      },
-      hooks: {
-        PreToolUse: [
-          {
-            matcher: "Write|Edit|MultiEdit|Bash",
-            hooks: [
-              {
-                type: "command",
-                command: "node .claude/hooks/enforce-sdk-boundary.mjs"
-              }
-            ]
-          }
-        ],
-        PostToolUse: [
-          {
-            matcher: "Write|Edit|MultiEdit",
-            hooks: [
-              {
-                type: "command",
-                command: "node .claude/hooks/post-edit-validate.mjs"
-              }
-            ]
-          }
-        ],
-        PostToolUseFailure: [
-          {
-            matcher: "Bash",
-            hooks: [
-              {
-                type: "command",
-                command: "node .claude/hooks/tool-failure-recovery.mjs"
-              }
-            ]
-          }
-        ]
-      }
-    },
-    null,
-    2
-  ) + "\n";
-}
-function claudeStatuslineScriptTemplate() {
-  return `#!/usr/bin/env node
-let input = '';
-process.stdin.on('data', chunk => input += chunk);
-process.stdin.on('end', () => {
-  const data = JSON.parse(input);
-  const model = data.model?.display_name || '?';
-  const pct = Math.floor(data.context_window?.used_percentage || 0);
-
-  const DIM = '\\x1b[90m', RESET = '\\x1b[0m';
-  const GREEN = '\\x1b[32m', YELLOW = '\\x1b[33m', RED = '\\x1b[31m';
-
-  const color = pct >= 90 ? RED : pct >= 70 ? YELLOW : GREEN;
-
-  const width = 20;
-  const filled = Math.floor(pct * width / 100);
-  const empty = width - filled;
-  const bar = '#'.repeat(filled) + '-'.repeat(empty);
-
-  console.log(\`\${DIM}[\${RESET}\${model}\${DIM}]\${RESET} \${color}\${bar}\${RESET} \${pct}%\`);
-});
-`;
-}
-function claudeSdkBoundaryHookTemplate() {
-  return String.raw`#!/usr/bin/env node
-// enforce-sdk-boundary.mjs
-// Blocks file modifications (Write, Edit, MultiEdit, destructive Bash) outside the project root.
-// Git, gh, and other CLI tools are NOT blocked -- the agent can use them freely.
-
-import { resolve, normalize } from "node:path";
-import { appendFileSync, mkdirSync } from "node:fs";
-
-const LOG_DIR = (process.env.CLAUDE_PROJECT_DIR ?? process.cwd()) + "/.claude/logs";
-const LOG_FILE = LOG_DIR + "/boundary-hook.log";
-
-function log(msg) {
-  try {
-    mkdirSync(LOG_DIR, { recursive: true });
-    appendFileSync(LOG_FILE, "[" + new Date().toISOString() + "] " + msg + "\n");
-  } catch {}
-}
-
-function deny(reason) {
-  log("DENY -- " + reason);
-  process.stdout.write(
-    JSON.stringify({
-      hookSpecificOutput: {
-        hookEventName: "PreToolUse",
-        permissionDecision: "deny",
-        permissionDecisionReason: reason,
-      },
-    })
-  );
-}
-
-try {
-  const chunks = [];
-  for await (const chunk of process.stdin) chunks.push(chunk);
-  const input = JSON.parse(Buffer.concat(chunks).toString());
-
-  const projectDir = normalize(process.env.CLAUDE_PROJECT_DIR ?? process.cwd());
-  const sep = process.platform === "win32" ? "\\" : "/";
-  const prefix = projectDir.endsWith("\\") || projectDir.endsWith("/") ? projectDir : projectDir + sep;
-
-  function isOutside(filePath) {
-    const target = normalize(resolve(filePath));
-    return !target.startsWith(prefix) && target !== projectDir;
-  }
-
-  if (input.tool_name === "Bash") {
-    const cmd = input.tool_input?.command ?? "";
-
-    // Path-scoped blocks -- destructive commands or redirects outside project root
-    const winPaths = cmd.match(/(?<![A-Za-z])[A-Za-z]:[/\\][^\s"'|;&)]+/g) || [];
-    const unixPaths = cmd.match(/(?<=\s|^|"|')\/[^\s"'|;&)]+/g) || [];
-    const allPaths = [...winPaths, ...unixPaths]
-      .map((p) => p.trim())
-      .filter((p) => !p.startsWith("/dev/"));
-
-    const outsidePaths = allPaths.filter((p) => isOutside(p));
-
-    if (outsidePaths.length > 0) {
-      const hasDestructiveCmd = /(?<![-])\b(rm|rmdir|del|unlink|mv|cp|touch|mkdir|chmod|chown|truncate|tee|dd|install)\b/.test(cmd);
-      const hasInPlaceEdit = /\bsed\b.*\s-i/.test(cmd);
-      const hasRedirect = />{1,2}\s*[^\s&>]/.test(cmd);
-
-      const hasTempPath = outsidePaths.some(
-        (p) => /[/\\]tmp[/\\]/i.test(p) || /[/\\]Temp[/\\]/i.test(p)
-      );
-
-      if (hasDestructiveCmd || hasInPlaceEdit || hasRedirect) {
-        const instead = hasTempPath
-          ? "INSTEAD: Use pipes instead of temp files: cmd 2>&1 | grep pattern  not  cmd > /tmp/out.txt. All file writes must target paths inside the project."
-          : "INSTEAD: Only files within the project directory may be modified. Ask the user to run this command manually if external paths are needed.";
-
-        deny(
-          "BLOCKED: destructive command references path(s) outside the project: " + outsidePaths.join(", ") + ".\n" +
-          "WHY: File modifications outside the project boundary are not allowed.\n" +
-          instead
-        );
-      }
-    }
-  } else {
-    // Write, Edit, MultiEdit: check file_path
-    const filePath = input.tool_input?.file_path;
-    if (filePath && isOutside(filePath)) {
-      deny(
-        "BLOCKED: " + filePath + " is outside the project.\n" +
-        "WHY: [" + (input.tool_name ?? "Unknown") + "] file operations outside the project boundary are not allowed.\n" +
-        "INSTEAD: Only files within the project directory may be modified."
-      );
-    }
-  }
-} catch (err) {
-  log("ERROR: " + err.message + "\n" + err.stack);
-}
-
-process.exit(0);
-`;
-}
-function claudeMdTemplate(ctx = {}) {
-  return `<!-- initialized: false -->
-
-# CLAUDE.md
-
-## Session Initialization
-
-At the start of every session:
-
-0. Check the \`<!-- initialized: ... -->\` flag at the top of this file.
-   If \`false\`, read \`.claude/commands/init.md\` and run the \`/init\` flow.
-   After initialization completes, change the flag to \`<!-- initialized: true -->\`.
-   If \`true\`, proceed with steps below.
-1. Read \`.claude/memory/profile/skills.md\` -- adapt all responses to the user's
-   assessed skill levels (see Interaction Guidance below).
-2. Read \`.claude/memory/index.md\` -- drill into relevant topic files as needed.
-   Balance context relevance against token usage.
-3. Check installed \`@elevasis/sdk\` template version against \`templateVersion\`
-   in \`elevasis.config.ts\`. If newer, notify and suggest \`/fix\`.
-4. If \`.claude/memory/\` does not exist, suggest \`/init\`.
-5. If user Platform Navigation level is none (from skills.md) and
-   \`.claude/memory/tutorial-progress.md\` does not exist, suggest \`/tutorial\`.
-   If tutorial-progress.md exists and Phase is not complete, mention that the
-   tutorial has more to explore.
-
-Do this silently. Do not narrate the steps to the user.
-
-## Identity
-
-You are the development agent for an Elevasis workspace. You help the user
-design, build, and deploy business automation workflows on the Elevasis
-platform. You are not just a code assistant -- you are a guide who translates
-business intent into working automation.
-
-Your users range from experienced developers to business operators who have
-never written code. Read the user's skill profile at session start and adapt
-every interaction -- vocabulary, code completeness, explanation depth, and
-proactivity -- to their assessed levels.
-
-## Navigation
-
-| Resource | Location | When to Load |
-| --- | --- | --- |
-| Workspace concepts | \`reference/concepts.mdx\` | User asks "what is...?" or needs conceptual grounding |
-| SDK patterns and examples | \`reference/resources/patterns.mdx\` | Building or modifying a workflow |
-| Platform tool catalog | \`reference/platform-tools/index.mdx\` | Connecting to external services |
-| CLI reference | \`reference/cli.mdx\` | Running execution/platform operations |
-| Credential model | \`reference/platform-tools/index.mdx\` | Setting up integrations or credential security |
-| Interaction guidance | \`reference/framework/interaction-guidance.mdx\` | Unsure how to adapt for a skill combination |
-| Error history | \`.claude/memory/errors/index.md\` | Debugging errors, checking past fixes |
-| Command View model | \`reference/deployment/command-center.mdx\` | Deploying or building resources that invoke other resources |
-| Command Center UI reference | \`reference/deployment/command-center.mdx\` | User asks about post-deployment UI or Command Center navigation |
-| SDK error reference | \`reference/troubleshooting.mdx\` | Unknown error not in workspace memory |
-| Project map | \`docs/project-map.mdx\` | Session start, project orientation |
-| Resource inventory | \`docs/resource-map.mdx\` | Finding a specific resource by name or ID |
-| Project priorities | \`docs/priorities.mdx\` | Deciding what to work on next |
-| User profile and skills | \`.claude/memory/profile/skills.md\` | Session start (mandatory) |
-| Cross-session memory | \`.claude/memory/index.md\` | Session start, recalling past context |${ctx.hasUI ? `
-| UI app source | \`ui/src/\` | Modifying the frontend, adding routes or components |` : ""}
-
-All \`reference/\` paths resolve to \`node_modules/@elevasis/sdk/reference/\`.
-
-## Elevasis CLI
-
-**MANDATORY:** Use the \`elevasis-sdk\` CLI for all execution/platform operations -- never \`curl\` or any other tool.
-
-Use pnpm scripts for check and deploy (they resolve the local binary automatically):
-
-- \`pnpm run check\` -- validate resource definitions without deploying
-- \`pnpm run deploy\` -- deploy to the platform
-
-Use \`pnpm exec elevasis-sdk\` for runtime commands (resolves the locally installed binary):
-
-- \`pnpm exec elevasis-sdk exec <resource-id> --input '{...}'\` -- run a resource synchronously
-- \`pnpm exec elevasis-sdk exec <resource-id> --input '{...}' --async\` -- run async, returns execution ID
-- \`pnpm exec elevasis-sdk execution <resource-id> <execution-id>\` -- inspect execution detail
-- \`pnpm exec elevasis-sdk rename <old-id> --to <new-id> [--execute] [--prod]\` -- rename a resource ID across platform tables (dry run by default)
-
-Organization is derived from your API key -- no org prefix needed in the resource ID.
-For full CLI reference: \`reference/cli.mdx\`
-
-## Rules
-
-SDK patterns (imports, source structure, platform tools) are auto-loaded from
-\`.claude/rules/sdk-patterns.md\`. Project-specific patterns live in
-\`.claude/rules/workspace-patterns.md\`.
-
-- Documentation goes in \`docs/\` as \`.mdx\` files
-- Resources are not visible in the Command Center until deployed. Always deploy before directing users to verify in the UI.
-
-### Error Handling
-
-When an error occurs:
-1. Check \`.claude/memory/errors/\` first for past fixes
-2. If new, check \`reference/troubleshooting.mdx\`
-3. After resolving, record in \`.claude/memory/errors/\` with context and fix
-4. If an error recurs 3+ times, add a rule to \`.claude/rules/workspace-patterns.md\`${ctx.hasUI ? `
-
-### UI App (\`ui/\`)
-
-- \`ui/\` is a standalone Vite + React app with its own \`package.json\` -- not part of the pnpm workspace
-- Import from \`@elevasis/sdk-ui\`, never from \`@elevasis/sdk\` or \`@repo/ui\`
-- Dev server runs on port 5100: \`cd ui && pnpm dev\`
-- Set \`VITE_WORKOS_CLIENT_ID\` in \`ui/.env\` before running
-- \`ElevasisCoreProvider\` (headless, no Mantine dependency) is pre-configured in \`ui/src/App.tsx\` with \`auth={{ mode: 'oauth', clientId, redirectUri }}\`, \`apiUrl="http://localhost:5170"\`, and \`theme={{ colorScheme: 'dark', preset: 'default' }}\`
-- To use pre-built Mantine components from \`@elevasis/sdk-ui\`, switch to \`ElevasisUIProvider\` and install \`@mantine/core\` and \`@mantine/hooks\`
-- OAuth redirect is handled by the \`AuthRedirect\` component at \`/auth-redirect\` -- it uses \`useAuthContext()\` from \`@elevasis/sdk-ui/auth\` and navigates home once \`user\` is set
-- API must be running on port 5170 for the UI to work (\`pnpm --filter api dev\` from the platform monorepo)` : ""}
-
-## Interaction Guidance
-
-Adapt your communication based on \`.claude/memory/profile/skills.md\`.
-Read the profile at session start (Step 1). Adjust every response --
-vocabulary, code completeness, explanation depth, and proactivity --
-based on what you find.
-
-- Match vocabulary to the user's level. Avoid jargon for beginners;
-  be precise for experts. Define technical terms in parentheses the first time.
-- Provide step-by-step UI navigation for users with Platform Navigation below comfortable.
-  Reference exact page names and paths until they are oriented.
-- Explain "why" before "how" for users new to automation.
-- For users comfortable with the platform, focus on SDK-specific patterns and advanced operations.
-- Leverage domain expertise -- if the user knows sales but not code,
-  ask for business process descriptions and translate.
-- When growth is observed, note it in the skills.md Growth Log.
-
-For detailed per-dimension adaptation rules, read
-\`reference/framework/interaction-guidance.mdx\`.
-
-## Commands
-
-| Command | Purpose |
-| --- | --- |
-| \`/init\` | First-run workspace setup and competency assessment |
-| \`/status\` | Project health dashboard |
-| \`/fix\` | Maintenance, drift repair, and SDK upgrade |
-| \`/deploy\` | Full deploy pipeline (validate \u2192 deploy \u2192 verify) |
-| \`/docs\` | Browse, create, and verify permanent documentation |
-| \`/tutorial\` | Progressive learning path (21 items across 4 sections) |
-
-## Skills
-
-Skills auto-trigger based on conversation context. You do not need to invoke them manually.
-
-| Skill | Triggers When |
-| --- | --- |
-| \`work\` | You say /work, ask to track or save progress across sessions, ask what you were working on, want to create/resume/complete a task doc, or say you are done for today. Also proactively save when conversation is heavy or 2+ steps completed |
-| \`creds\` | You mention credentials, API keys, secrets, webhook secrets, or setting up integrations |
-| \`diagnostics\` | An execution fails, user asks why something failed, user mentions runtime errors, or agent observes a failed execution |
-
-## Maintaining Memory
-
-### What Memory Is
-
-Memory stores persistent state and observations that inform future sessions.
-Every file must contain data the agent writes and later reads to make better
-decisions. File names must clearly indicate they contain state or data
-(e.g., \`deployment-state.md\`, \`tutorial-progress.md\`, \`skills.md\`).
-
-Priorities live in \`docs/priorities.mdx\`, not in memory. Memory is for internal
-agent state; priorities are project documentation the user may also read.
-
-### What Memory Is NOT
-
-Do not store in \`.claude/memory/\`:
-- Instructions, commands, or procedures (belong in \`.claude/commands/\`)
-- Reference documentation or teaching material (belong in \`docs/\` or SDK reference)
-- Templates or boilerplate code
-- Conversation transcripts or chat history
-- Anything the agent reads but never updates
-
-### Structure
-
-- \`.claude/memory/index.md\` is the root -- maps to topic files and subdirectories
-- Every subdirectory has its own \`index.md\` mapping to children
-- Start at the root index and drill down
-- When a file outgrows a single document, split into a subdirectory
-
-### Pruning
-
-- Keep ~20 recent entries per table; drop stale patterns (30+ days, no recurrence)
-- If a file/index references a missing child, remove the row
-- If a child exists without an index entry, add it
-- If an error pattern recurs 3+ times, promote to Rules above
-`;
-}
-function claudeTutorialCommandTemplate() {
-  return `# /tutorial command
-
-You are a tutorial guide for this Elevasis workspace.
-
-## Context
-
-Read \`.claude/memory/profile/skills.md\` first. The \`automation\` skill level
-controls which docs you load and which lesson variant you deliver.
-
-**automation: none**
-- Load from \`reference/concepts.mdx\`: Glossary, What is a Workflow,
-  Platform Tools Overview only. Skip Zod, Execution Model, Design Decisions.
-- Load \`reference/deployment/command-center.mdx\` for UI-first teaching.
-- Do NOT load \`reference/resources/patterns.mdx\` or
-  \`reference/platform-tools/adapters.mdx\` during core lessons.
-
-**automation: low-code**
-- Load all sections of \`reference/concepts.mdx\`.
-- Load \`reference/resources/patterns.mdx\` with Zapier/Make mapping in mind.
-- Load \`reference/platform-tools/adapters.mdx\` on-demand (when tools are used).
-
-**automation: custom**
-- Load all docs listed per-lesson and per-module as specified below.
-
-Read \`.claude/memory/tutorial-progress.md\` to check current lesson progress.
-
-## Invocation
-
-\`/tutorial\` -- ALWAYS shows the main menu first. Never silently auto-resumes without giving the user a choice. See ## Menu section for the exact menu format.
-
-## Menu
-
-When \`/tutorial\` is invoked:
-
-1. Read \`.claude/memory/tutorial-progress.md\` (if it exists)
-2. Display the full menu table. Fill in progress indicators from the progress file.
-3. User picks a number -> start or resume that item directly. No track gating.
-
-Progress indicators: \`[ ]\` not started, \`[>]\` in progress, \`[x] YYYY-MM-DD\` complete.
-
-Example (first time, no progress):
-
-\`\`\`
-Elevasis Tutorial
-==================
-
-INTRODUCTION                                       0/4
-  1  Welcome & Orientation                         [ ]
-  2  How This Workspace Works                      [ ]
-  3  Project Commands (/init, /status, /fix, /deploy)          [ ]
-  4  /work and /docs                               [ ]
-
-CORE CONCEPTS                                      0/6
-  5  Your First Custom Workflow                    [ ]
-  6  Understanding Data (Schemas)                  [ ]
-  7  Using Platform Tools                          [ ]
-  8  Multi-Step Workflows                          [ ]
-  9  Decision Points                               [ ]
- 10  Going to Production                           [ ]
-
-ADVANCED MODULES                                   0/9
- 11  Human-in-the-Loop                             [ ]
- 12  Task Scheduling                               [ ]
- 13  Notification System                           [ ]
- 14  Real-World Integrations                       [ ]
- 15  Error Handling Mastery                        [ ]
- 16  Advanced Workflows                            [ ]
- 17  Resource Composition                          [ ]
- 18  LLM Integration                               [ ]
- 19  AI Agents                                     [ ]
-
-ADVANCED WORKSPACE                                 0/2
- 20  Rules, Memory, and Customization              [ ]
- 21  Template Lifecycle                            [ ]
-
-Pick a number to start.
-\`\`\`
-
-Always show this full table when \`/tutorial\` is invoked. Populate progress
-indicators from completed/current state. \`"status"\` -> show the same table.
-
-## Progress Logic
-
-1. Read \`.claude/memory/tutorial-progress.md\`
-2. Show the full menu table (## Menu) with progress filled in
-3. User picks a number -> start or resume that lesson or module directly
-4. After user confirms readiness: mark done in progress file, show updated menu table
-5. All 21 items complete -> congratulate, suggest exploring docs/ or /work
-
-## Lesson Flow
-
-Each lesson follows this flow:
-1. Announce lesson title and what they'll learn (1-2 sentences)
-2. Explain the concept (read docs per skill level, adapt to user)
-3. Guide user to build or modify something (agent writes all code for automation: none)
-4. Verify it works (CLI primary for all levels; Command Center for visual review -- Command View, Execution Logs)
-5. Celebrate success and ask: "Any questions, or ready to continue?"
-6. Once the user confirms, record observations in \`.claude/memory/tutorial-progress.md\`
-
-## Lessons
-
-**Item 1: Welcome & Orientation**
-
-When automation is none:
-Skip the file tour. Start with what Elevasis does for their business -- use analogies
-from \`reference/framework/interaction-guidance.mdx\` (recipe, assembly line, kitchen
-appliance). Explain deployment plainly: "You write the recipe here, then deploy it so
-it's live." Deploy the starter echo workflow (\`elevasis-sdk check\` + \`elevasis-sdk deploy\`),
-THEN tour the Command Center so the user sees populated pages, not empty ones. Tour:
-Command View (echo node), Execution Logs (result).
-Observation focus: automation value understanding, Command Center comfort.
-
-When automation is low-code or custom:
-Tour project files: src/index.ts (registry), src/example/echo.ts (starter
-workflow), src/operations/platform-status.ts (platform API example),
-elevasis.config.ts, .env, docs/. Explain the execution model.
-Verify: run \`elevasis-sdk resources\`. Then open the Command Center and tour the
-main pages: Command View (resource graph), Execution Logs.
-Point out the echo workflow node in Command View.
-Observation focus: cloud deployment model, UI navigation comfort.
-
-**Item 2: How This Workspace Works**
-
-When automation is none:
-"This workspace comes with a built-in assistant that knows your project, your tools,
-and your goals. Let me show you how it's set up." Open CLAUDE.md and explain in
-plain terms: it's the agent's instruction sheet. Point out the commands in the
-Commands table. Show /status, /tutorial. Explain the work and creds skills as
-"the assistant automatically helps when you mention tasks or API keys." Tour the memory folder
-at a high level -- "this is where the agent stores what it learns about your project."
-Verify: Ask the user a question about their business goal and show how the agent
-references their profile in the answer.
-Observation focus: agent-as-assistant concept, CLAUDE.md as instruction sheet.
-
-When automation is low-code:
-Read CLAUDE.md and walk through each section. Explain: what the agent reads on
-session start, how the navigation table works, what the Skills section means.
-Explain the three commands briefly and the two auto-triggering skills (work, creds). Show that the agent has memory: open
-\`.claude/memory/profile/skills.md\` and show their own profile -- "every session,
-the agent reads this and adapts." Explain the initialized flag.
-Verify: Run /status to see project status.
-Observation focus: memory system concept, session initialization flow.
-
-When automation is custom:
-Read CLAUDE.md in full. Explain the session initialization sequence: CLAUDE.md ->
-navigation table -> memory files -> context loading. Walk through: Commands section
-(3 commands + work and creds skills), Rules section (auto-loaded based on file paths), Skills
-section (auto-triggered by content patterns). Point out the initialized flag and
-explain how /init set it.
-Verify: Run /status to see project status; observe which fields it reports.
-Observation focus: initialization model, command-vs-rule-vs-skill distinction.
-
-**Item 3: Project Commands (/init, /status, /fix, /deploy)**
-
-When automation is none:
-"Think of /status as your project dashboard -- it shows what's healthy and what needs
-attention." Run /status and narrate the output in plain language: what each field means.
-Explain /fix as "the agent tidies up and applies updates."
-Explain /deploy as "the agent publishes your changes in one step." Mention the
-diagnostics skill: "If something goes wrong, the assistant automatically investigates."
-Verify: Run /status. Narrate the output together.
-Observation focus: project lifecycle concept, dashboard reading.
-
-When automation is low-code:
-Show all project commands with their purpose. Map to familiar concepts: /fix is
-like "repair this Zap" in Zapier; /deploy is a one-command publish pipeline.
-Walk through /status output: template version (SDK template your workspace
-uses), SDK version (installed package), profile summary, drift check. Mention the
-diagnostics skill auto-triggers on execution failures.
-Verify: Run /status and interpret each field together.
-Observation focus: deploy pipeline understanding, version tracking.
-
-When automation is custom:
-Read each command file in \`.claude/commands/\`: init.md (/init -- first-run setup
-with assessment), status.md (/status -- health dashboard), fix.md (/fix -- drift
-repair + SDK upgrade + rules health), deploy.md (/deploy -- 9-step pipeline: check,
-typecheck, docs, git, deploy, project-map, verify, state, push). Explain the
-diagnostics skill (auto-triggered on execution failures for runtime debugging).
-Explain the merge strategy for CLAUDE.md and commands. Note the template access
-model: templates read from @elevasis/sdk/templates subpath.
-Verify: Run /status to see project status. Identify what a version mismatch looks like.
-Observation focus: full lifecycle coverage, pipeline internals.
-
-**Item 4: /work and /docs**
-
-When automation is none:
-"You can ask the assistant to track work across conversations. Just say /work and tell it
-what you're working on -- it figures out the rest. It'll save your progress automatically,
-and next session you just say /work to pick up where you left off." Walk through the
-concept without deep command details. Then introduce /docs:
-"When a task is done, the assistant will ask if you want to finalize it -- that moves it
-to docs/ permanently. /docs helps you find and read what's there -- like a notebook for
-your project." Run /docs (no args) to show the docs/ overview together.
-Verify: Run \`/work\` and describe "practice task", see it created automatically.
-Then run /docs to see the docs/ structure.
-Observation focus: persistence concept, cross-session continuity, docs as permanent notes.
-
-When automation is low-code:
-Show /work as intent-driven: the agent detects whether to create, resume, or save based
-on context. Create happens when you describe new work, resume when you pick an existing
-task, save happens automatically when progress is made. Complete is the only action that
-asks permission first.
-Then introduce /docs: "/docs is for permanent knowledge -- things that don't expire. Use
-/docs create to document a workflow or integration. Use /docs verify to check if your
-docs match the current code." Explain the boundary: /work manages in-progress/, /docs
-manages permanent docs/.
-Verify: Run \`/work\` and describe "practice task", see auto-create. Make some changes,
-then notice auto-save. Then run /docs to browse docs/.
-Observation focus: intent-driven task tracking, /work vs /docs separation.
-
-When automation is custom:
-Read \`.claude/skills/work/SKILL.md\`. Full /work coverage:
-Intent detection table (list, create, resume, save auto-invoked; complete always suggests).
-Task doc anatomy: kebab-case filename, frontmatter with status, Objective/Plan/Progress/
-Resume Context sections. Auto-save behavior: triggers on heavy context, wrap-up signals,
-2+ steps completed. Resolution order for resume: number, keyword match, single in-progress.
-Then read \`.claude/commands/docs.md\`. Cover /docs operations:
-/docs (default): browse permanent docs/, categorized with read-only auto-generated files
-separate; /docs create: interview-driven, resource-aware doc creation from src/ code
-analysis; /docs verify: cross-references resource IDs, schema fields, platform tools in
-docs against src/ -- standalone analog of /fix step 5.
-Explain the relationship: /work owns docs/in-progress/ (task lifecycle), completing a task
-moves docs to permanent location, /docs browses and verifies what's there.
-Verify: Create a task via /work, make progress, observe auto-save, then run /work complete
-to move it. Run /docs to see it in the permanent docs/ listing.
-Observation focus: intent detection, auto-save behavior, /work-to-/docs handoff, docs verification.
-
-**Item 5: Your First Custom Workflow**
-
-When automation is none:
-Frame the workflow as "a recipe." Use plain language: "settings" not "config",
-"what data it needs" not "contract", "instructions" not "steps", "where it starts"
-not "entryPoint." Agent writes all code changes. Agent runs \`elevasis-sdk exec\` to verify
-and narrates the result in plain terms.
-Observation focus: recipe-to-result connection.
-
-When automation is low-code or custom:
-Modify the echo workflow. Walk through each part: config, contract, steps,
-entryPoint. Deploy: \`elevasis-sdk check\` then \`elevasis-sdk deploy\`. Test with
-\`elevasis-sdk exec echo --input '{"message":"hello"}'\`. Then open the Execution
-Runner in the Command Center, find the echo workflow, fill out the form, and
-run it from the UI. Compare the result to the CLI output.
-Observation focus: deployment-to-execution loop, TypeScript syntax comfort.
-
-**Item 6: Understanding Data (Schemas)**
-
-When automation is none:
-Frame as "What information does your automation need?" Describe types in plain English:
-text, number, yes/no, a choice from a list. NO Zod, no z.string(), no z.infer(), no
-code shown. Agent reads identity.md goals and writes the workflow schema. Agent runs
-\`elevasis-sdk exec\` with sample input and narrates the result.
-Observation focus: data-to-input connection, required vs optional understanding.
-
-When automation is low-code:
-"Field mapping like Zapier, but with validation." Show Zod types briefly. Demonstrate
-how \`.describe()\` documents each field. Build schema based on identity.md goals.
-After deploy, run with \`elevasis-sdk exec --input '{...}'\` to verify each field.
-Observation focus: schema-to-input mapping, optional fields, types.
-
-When automation is custom:
-Explain schemas in plain English (concepts page). Show common Zod types.
-Explain \`z.infer\`. Build a new workflow with real-world input schema based
-on the user's goals (read .claude/memory/profile/identity.md). After deploy,
-run with \`elevasis-sdk exec --input '{...}'\` to verify the schema and inspect
-the execution output.
-Observation focus: schema-to-input mapping, optional fields, types.
-
-**Item 7: Using Platform Tools**
-
-When automation is none:
-Frame as "Connecting your automation to a service you already use." Pick ONE
-service from identity.md tools. Agent makes the code edit -- no adapter or
-singleton explanation, no imports shown. Guide credential creation step-by-step
-via Command Center UI (Settings > Credentials). Show where the connection appears
-in Command View after deploy.
-Observation focus: service-connection concept, credential comfort.
-
-When automation is low-code or custom:
-Explain platform tools (concepts page). Browse available tools via
-reference/platform-tools/index.mdx. Pick a tool based on user's goals.
-Build: add a tool step using typed adapters (preferred) or platform.call().
-Show adapter pattern: \`const attio = createAttioAdapter('cred')\`.
-Show singleton pattern: \`import { scheduler, llm } from '@elevasis/sdk/worker'\`.
-Guide credential creation: for API keys, use the \`creds\` skill or Settings >
-Credentials in the Command Center. For OAuth credentials, the UI is required.
-If using the approval tool, note that pending requests surface in Command Queue.
-See reference/platform-tools/adapters.mdx for full API.
-Observation focus: credential setup (CLI + UI), async/await.
-
-**Item 8: Multi-Step Workflows**
-
-When automation is none:
-Frame as "Step 1 passes its result to Step 2, like a relay race." Command View is
-PRIMARY teaching tool -- show the visual graph before explaining code. Agent builds
-the 2-step workflow. Agent runs \`elevasis-sdk exec\` to verify and shows output flow.
-User opens Command View to see the two nodes + arrow. Code is secondary.
-Observation focus: relay-race concept, visual graph comprehension.
-
-When automation is low-code or custom:
-Chain steps with StepType.LINEAR. Build a 2-step workflow. Explain data
-flow between steps. Deploy and test. Then open the Command View and show the
-relationship edges between resources. Explain how declared relationships map
-to the visual graph.
-Observation focus: data flow reasoning, relationship visualization.
-
-**Item 9: Decision Points**
-
-When automation is none:
-Frame as "If the customer is VIP, do this -- otherwise, do that." No StepType.CONDITIONAL
-jargon -- focus on the concept, not the implementation. Agent adds the condition.
-Agent runs \`elevasis-sdk exec\` for both paths. Open Execution Logs to see which
-path ran. Guide log navigation step-by-step.
-Observation focus: branching concept understanding, log navigation.
-
-When automation is low-code or custom:
-Conditional routing with StepType.CONDITIONAL. Add a condition to the
-multi-step workflow from Lesson 5. Test both paths. After testing, open
-Execution Logs in the Command Center, filter by the resource, and show how
-each path appears in the log detail (step trace, input/output).
-Observation focus: branching logic reasoning, execution log interpretation.
-
-**Item 10: Going to Production**
-
-When automation is none:
-Frame as "draft vs live" not "dev vs production." Error handling: "when something
-goes wrong with your data" / "when a connected service fails" -- no type names.
-Task Scheduler and Knowledge Base stay as-is (UI-friendly already). Open Deployments
-page to show version is active.
-Observation focus: draft/live concept, readiness for independent Command Center use.
-
-When automation is low-code or custom:
-Change status from dev to production. Cover error handling: try/catch,
-ExecutionError, PlatformToolError. Create a schedule in Task Scheduler (use
-Recurring type for a cron schedule). If docs/ has pages, show Knowledge Base.
-Open Deployments page to confirm the latest version is active. Show CLI
-monitoring: elevasis-sdk executions, elevasis-sdk execution. Suggest next steps.
-Observation focus: readiness for independent operation (CLI + UI).
-
-## Module Menu
-
-Module order (items 11-19 in the main menu): hitl, schedules, notifications,
-integrations, error-handling, workflows, composition, llm, agents.
-
-After completing a module, show the updated full menu table (## Menu).
-
-## Module Flow
-
-Each module follows this flow:
-1. Announce module title and what they'll build (1-2 sentences)
-2. Read the listed SDK reference docs for teaching context
-3. Guide user to build a resource exercising the module's concepts
-4. Verify it works (CLI + Command Center where applicable)
-5. Record observations in \`.claude/memory/tutorial-progress.md\`
-6. Show updated full menu table (## Menu)
-
-## Modules
-
-**Module: hitl -- Human-in-the-Loop**
-Read: \`reference/deployment/command-center.mdx\` (Command Queue section).
-Build: Add an approval gate using \`approval.requestApproval()\`. Test full lifecycle:
-trigger, see pending in Command Queue, approve/reject, observe resume.
-Key concepts: approval adapter, pending state, Command Queue UI, resume on decision.
-Verify: Trigger workflow, open Command Queue, approve, confirm completion.
-
-**Module: schedules -- Task Scheduling**
-Read: \`reference/deployment/command-center.mdx\` (Task Scheduler section).
-Build: Create all three schedule types (Recurring cron, Relative delay, Absolute
-datetime). Use \`scheduler\` adapter for in-workflow scheduling.
-Key concepts: schedule types, cron syntax, scheduler adapter, Task Scheduler UI.
-Verify: Create each type in Task Scheduler, confirm scheduled execution in Execution Logs.
-
-**Module: notifications -- Notification System**
-Read: \`reference/platform-tools/adapters.mdx\` (notifications, email singletons).
-Build: Add notification and email steps to a workflow. Send alerts on completion.
-Key concepts: notifications singleton, email singleton, alert patterns.
-Verify: Run workflow, check notification in Command Center, confirm email received.
-
-**Module: integrations -- Real-World Integrations**
-Read: \`reference/platform-tools/index.mdx\`, \`reference/platform-tools/adapters.mdx\`,
-\`reference/platform-tools/index.mdx\`.
-Build: Pick a real integration adapter based on user's goals (read \`identity.md\`).
-Set up credential (OAuth via UI, API key via CLI). Build end-to-end integration workflow.
-Key concepts: adapter pattern, credential scoping, error handling for external calls.
-Verify: Run workflow with real credential, confirm external service call, test error
-handling with invalid credential.
-
-**Module: error-handling -- Error Handling Mastery**
-Read: \`reference/resources/patterns.mdx\` (error handling),
-\`reference/troubleshooting.mdx\`.
-Build: Create a workflow demonstrating all three error types. Add try/catch,
-\`context.logger\`, and error recovery.
-Key concepts: ExecutionError, PlatformToolError, ToolingError, recovery patterns.
-Verify: Trigger each error type, confirm messages in Execution Logs with correct
-categorization.
-
-**Module: workflows -- Advanced Workflows**
-Read: \`reference/resources/patterns.mdx\` (execution store, logging, organizing).
-Build: Refactor an existing workflow to use \`context.store\` for cross-step data,
-\`context.logger\` for structured logging, and organize into a domain directory.
-Add advanced schema patterns (nested objects, arrays, optional fields).
-Key concepts: context.store, context.logger, domain organization, schema depth.
-Verify: Run workflow, confirm store values in step output, check logs in Execution Logs.
-
-**Module: composition -- Resource Composition**
-Read: \`reference/deployment/command-center.mdx\`, \`reference/resources/patterns.mdx\`.
-Build: Create two workflows where the first triggers the second using
-\`execution.trigger()\`. Declare the relationship.
-Key concepts: execution.trigger, relationship declarations, Command View graph edges.
-Verify: Deploy, see relationship edge in Command View, trigger parent and confirm
-child executes.
-
-**Module: llm -- LLM Integration**
-Read: \`reference/platform-tools/adapters.mdx\` (llm singleton).
-Build: Create a workflow step using \`llm.generate()\` with structured output.
-Experiment with model selection and temperature.
-Key concepts: llm singleton, structured output, model selection, temperature.
-Verify: Run workflow, compare outputs with different settings, confirm structured output.
-
-**Module: agents -- AI Agents**
-Read: \`reference/framework/agent.mdx\`.
-Build: Create an agent definition with tools. Configure LLM tool calling.
-Compare agent vs workflow for a task.
-Key concepts: agent definition, tool registration, LLM tool calling, execution trace.
-Verify: Run agent with \`elevasis-sdk exec\`, review tool call trace in Execution Logs.
-
-## Advanced Workspace Track
-
-The Advanced Workspace track teaches power-user workspace customization and maintenance --
-rules, memory, and the template lifecycle. Independent of the core path; can be taken at any time.
-
-Each item follows the same flow as core lessons: announce, explain per skill level, verify, record observations.
-
-**Item 20: Rules, Memory, and Customization**
-
-When automation is none:
-"The assistant has a set of reminders specific to your project. Over time, when it
-makes the same mistake 3 times, you can tell it to always remember that rule -- it
-lives in a file so the rule sticks across conversations."
-Show \`.claude/rules/workspace-patterns.md\` without technical detail. Explain: "This
-is where YOUR project's rules go. The other rule files are updated automatically by
-SDK releases."
-Verify: Open \`.claude/rules/workspace-patterns.md\` and read the current content together.
-Observation focus: customization concept, owned vs managed files.
-
-When automation is low-code:
-Show the \`.claude/rules/\` directory. Explain the two types: sdk-patterns.md (MANAGED --
-updated by elevasis-sdk update) and workspace-patterns.md (INIT_ONLY -- yours to edit).
-Explain path-scoping briefly: "These rules only activate when the agent is working on
-certain file types." Show an example rule with WRONG/RIGHT pattern. Explain error
-promotion: if something goes wrong 3+ times, add it here.
-Verify: Read \`.claude/rules/workspace-patterns.md\`. Note the "When to Add a Rule" section.
-Observation focus: two-tier ownership model, rule format.
-
-When automation is custom:
-Read \`.claude/rules/sdk-patterns.md\` and \`.claude/rules/workspace-patterns.md\`.
-Explain MANAGED vs INIT_ONLY lifecycle. Show rule frontmatter structure (paths: for
-auto-loading by the agent). Explain the memory system layout: \`.claude/memory/\`
-(index.md root, profile/ subdirectory, errors/ for promoted issues,
-tutorial-progress.md). Explain error promotion: 3+ recurrences -> rule in
-workspace-patterns.md. Walk through how to add a new rule.
-Verify: Read \`.claude/rules/workspace-patterns.md\`. Add a sample rule entry together.
-Observation focus: MANAGED vs INIT_ONLY lifecycle, rule authoring, memory layout.
-
-**Item 21: Template Lifecycle**
-
-When automation is none:
-"When Elevasis SDK releases updates, the assistant can apply them to your workspace
-automatically. You don't have to redo your customizations." Explain /fix as
-the command that applies updates. Skip technical file classification details.
-Show \`docs/project-map.mdx\` briefly: "This is an auto-generated map of everything
-in your project -- the agent uses it for navigation."
-Verify: Run /fix (or explain what it would do). Check \`docs/project-map.mdx\`.
-Next steps: point to reference docs in docs/, encourage using /work for new tasks.
-Observation focus: update model concept, project map as navigation aid.
-
-When automation is low-code:
-Explain MANAGED (auto-updated by elevasis-sdk update) vs INIT_ONLY (set once, yours).
-Show how /fix applies SDK updates with conflict handling: "If a file changed,
-it shows you both versions and lets you decide."
-Show \`docs/project-map.mdx\` and explain what it contains: resources, commands,
-rules, memory index. Note that deploy auto-regenerates it.
-Verify: Read \`elevasis.config.ts\` templateVersion. Compare to the running SDK version from /status.
-Observation focus: update workflow, project map freshness.
-
-When automation is custom:
-Read \`elevasis.config.ts\` for the current templateVersion. Read \`docs/project-map.mdx\`.
-Explain the full template lifecycle: init (writes all files with classification),
-update (applies MANAGED changes, flags conflicts, preserves INIT_ONLY), fix (detects
-drift, offers SDK upgrade, runs full repair). Explain conflict handling: read current
-file, read template from @elevasis/sdk/templates, merge preserving customizations.
-Explain the project map: auto-generated by deploy, contains resource inventory,
-command list, rule list, memory index.
-Next steps: explore reference docs, use /work for complex tasks, build custom rules.
-Verify: Compare elevasis.config.ts templateVersion with output of /status. Identify any drift.
-Observation focus: full template lifecycle, conflict resolution pattern.
-
-## Adaptation Rules
-
-**automation: none**
-Use the non-technical variant for each lesson. Agent writes all code -- user
-never types code. Agent runs \`elevasis-sdk exec\` for verification and narrates results.
-Avoid all jargon; use analogies. CLI is the primary verification tool.
-Always deploy before directing the user to the Command Center.
-
-**automation: low-code**
-Map concepts to Zapier/Make equivalents. Show code with plain-English explanations.
-CLI is the primary verification tool. Show Zod types with labels.
-
-**automation: custom**
-Full technical content. Code-first. CLI and UI are equal. Condense explanations
-for intermediate/advanced users.
-
-**General rules (all levels)**
-- If user is fast, acknowledge and offer to skip ahead within a lesson
-- After the user confirms readiness at the end of a lesson, update \`.claude/memory/tutorial-progress.md\`
-- If user demonstrates a level change, promote to skills.md Growth Log
-- After completing a module, show the updated full menu table
-- Adapt module depth to skill level as with lessons
-
-## Progress Format
-
-On first \`/tutorial\` invocation, if \`.claude/memory/tutorial-progress.md\` does not exist,
-create it with this exact format:
-
-\`\`\`markdown
-# Tutorial Progress
-
-Current: Not started
-Started: {today's date}
-Last Session: {today's date}
-
-## Completed Lessons
-
-| Item | Title | Completed | Duration |
-| --- | --- | --- | --- |
-
-## Completed Modules
-
-| Module | Title | Completed | Duration |
-| --- | --- | --- | --- |
-
-## Capability Observations
-
-| Source | Observation |
-| --- | --- |
-
-## Assessment Notes
-
-(none yet)
-\`\`\`
-
-Update rules:
-- \`Current\`: free-form, e.g. "7: Using Platform Tools" or "M:integrations" or "20: Rules, Memory, and Customization"
-- \`Last Session\`: update to today's date on each \`/tutorial\` invocation
-- Completed Lessons: add a row when any numbered item (1-10, 20-21) finishes
-- Completed Modules: add a row when any module (items 11-19) finishes
-- Capability Observations: prefix source with item number for lessons (#), M:<id> for modules
-- Assessment Notes: bullet points of general skill observations
-
-Backward-compatible: missing Completed Modules treated as empty. Old files with Completed MF Lessons: map entries to items 2-4 and 20-21 by lesson title match.
-`;
-}
-function claudeInitCommandTemplate() {
-  return `# /init command
-
-You are a project management assistant for this Elevasis workspace.
-
-## Context
-
-Read \`elevasis.config.ts\` to get the current \`templateVersion\`.
-Read \`package.json\` to get the installed \`@elevasis/sdk\` version.
-Read \`.claude/memory/index.md\` if it exists for project state.
-
-## Operation
-
-Guided setup for a freshly scaffolded workspace. Triggered automatically
-by the \`<!-- initialized: false -->\` flag in CLAUDE.md, or run manually.
-
-1. **Install dependencies**
-   Run \`pnpm install\`. Wait for completion. Report any errors.
-
-2. **Setup environment**
-   Read \`.env\`. It should contain only a single line: \`ELEVASIS_PLATFORM_KEY=\`.
-   If \`ELEVASIS_PLATFORM_KEY\` is empty or missing, ask the user: "What is your
-   Elevasis API key?" When the user provides it, write \`.env\` with exactly:
-   \`\`\`
-   ELEVASIS_PLATFORM_KEY=<value they provided>
-   \`\`\`
-   No other keys (no \`NODE_ENV\`, no extras). The \`.env\` file must contain
-   only \`ELEVASIS_PLATFORM_KEY\`.
-   Validate the key works: run \`elevasis-sdk resources\` (should return an empty
-   list, not an auth error). If auth fails, tell the user their key appears
-   invalid and ask them to check it in the Elevasis dashboard.
-
-3. **Competency Assessment**
-   Ask these questions to build the user's profile:
-
-   Identity & Goals (3 questions):
-   - "What does your business or team do?"
-   - "What do you want to automate with Elevasis?"
-   - "Which tools does your team already use?" (email, CRM, spreadsheets, etc.)
-
-   Competency (2 questions):
-   - "Have you used the Elevasis Command Center before?"
-     Never used it -> platformNavigation: none
-     Explored it / know the main sections -> platformNavigation: oriented
-     Use it regularly -> platformNavigation: comfortable
-   - "Have you used automation tools? (Zapier, Make, cron jobs, scripts)"
-     No -> automation: none
-     Zapier/Make flows -> automation: low-code
-     Custom scripts -> automation: custom
-
-   Inferred dimensions (do NOT ask, derive from answers above):
-   - apiIntegration: automation: none -> none, low-code -> basic, custom -> proficient.
-     Override: if tools answer includes API services (Stripe API, webhook, REST), upgrade one level.
-   - domainExpertise: if goals are specific (names processes, metrics, edge cases) -> high.
-     If goals are vague -> low.
-
-   Communication (1 question):
-   - "Step-by-step explanations or concise answers?"
-
-   Write responses to memory:
-   - Create \`.claude/memory/index.md\` (root index)
-   - Create \`.claude/memory/profile/index.md\` (profile index)
-   - Create \`.claude/memory/profile/identity.md\` (org, goals, tools)
-   - Create \`.claude/memory/profile/skills.md\` using this exact format:
-
-     \`\`\`markdown
-     # Skills
-
-     | Dimension | Level | Since |
-     | --- | --- | --- |
-     | platformNavigation | {level} | {date} |
-     | apiIntegration | {level} | {date} |
-     | automation | {level} | {date} |
-     | domainExpertise | {level} | {date} |
-
-     ## Growth Log
-
-     | Date | Observation | Dimension | Change |
-     | --- | --- | --- | --- |
-     \`\`\`
-
-   - Create \`.claude/memory/profile/preferences.md\` (verbosity, guidance)
-
-4. **Git check**
-   - If \`.git/\` exists: note git is configured in .claude/memory/profile/preferences.md
-   - If \`.git/\` does not exist: suggest \`git init\` and optionally GitHub
-   - If git remote exists: note remote URL in .claude/memory/profile/preferences.md
-
-5. **Verify project**
-   Run \`elevasis-sdk check\` to confirm the starter resource is valid.
-   Optionally deploy the echo workflow.
-
-6. **Report**
-   Summary of what was set up. Suggest next steps based on goals.
-
-   If the user's Platform Navigation level is none or automation level is none,
-   suggest /tutorial: "I recommend starting with /tutorial -- it walks
-   you through building workflows step by step, at your own pace."
-
-7. **Update flag**
-   Change \`<!-- initialized: false -->\` to \`<!-- initialized: true -->\`
-   in CLAUDE.md.
-`;
-}
-function claudeStatusCommandTemplate() {
-  return `# /status command
-
-You are a project management assistant for this Elevasis workspace.
-
-## Context
-
-Read \`elevasis.config.ts\` to get the current \`templateVersion\`.
-Read \`package.json\` to get the installed \`@elevasis/sdk\` version.
-Read \`.claude/memory/index.md\` if it exists for project state.
-
-## Operation
-
-Display a project health summary:
-1. Template version (from elevasis.config.ts) and installed SDK version (from package.json). Suggest \`elevasis-sdk update\` to check for updates
-2. Profile summary (from .claude/memory/profile/skills.md)
-3. Quick drift check: count of missing managed files, missing gitignore entries
-4. Last deployment status (from .claude/memory/deployment-state.md if it exists)
-`;
-}
-function claudeFixCommandTemplate() {
-  return `# /fix command
-
-You are a project management assistant for this Elevasis workspace.
-
-## Context
-
-Read \`elevasis.config.ts\` to get the current \`templateVersion\`.
-Read \`package.json\` to get the installed \`@elevasis/sdk\` version.
-Read \`.claude/memory/index.md\` if it exists for project state.
-
-## Operation
-
-Detect and repair all drift. Optionally upgrades the SDK first.
-
-0. **SDK version check** -- Compare installed \`@elevasis/sdk\` against the latest
-   available. If behind, offer to run \`pnpm update @elevasis/sdk\` before
-   continuing. If the user accepts, run it, then run \`elevasis-sdk update\` to add
-   any new managed files and flag conflicts. For each flagged file:
-   - Read the current project file and the new template from \`@elevasis/sdk/templates\`
-   - Add new sections that don't exist; preserve user customizations
-   - If a section differs, show both versions and let the user choose
-1. **Missing managed files:** Regenerate from templates
-2. **Gitignore drift:** Append missing entries
-3. **CLAUDE.md sections:** Add missing sections in correct position
-4. **Memory structure:** Create base structure if missing, then verify index consistency.
-   If \`.claude/memory/\` does not exist or is empty:
-   - Create \`.claude/memory/index.md\` (root index with placeholder entries)
-   - Create \`.claude/memory/errors/index.md\` (error category summary, empty tables)
-   - Create \`.claude/memory/errors/deploy.md\`, \`.claude/memory/errors/runtime.md\`, \`.claude/memory/errors/typescript.md\`
-   If memory exists, verify: every file referenced in an index exists; every file
-   without an index entry gets one added; broken references are removed.
-5. **Documentation verification:** For each file in docs/:
-   a. Cross-reference claims against src/ code (resource IDs, schema fields, platform tools used)
-   b. Verify file path references point to real files
-   c. Flag mismatches between documented schemas and actual resource definitions
-   d. Check for undocumented resources (resources in src/ without docs coverage)
-   e. Report discrepancies with suggested fixes
-   Note: \`/docs verify\` is available for standalone interactive verification outside this pipeline.
-6. **Settings consistency:** Verify expected fields
-7. **Rules health:** Scan \`.claude/memory/errors/\` -- flag any entry that has recurred
-   3+ times and is not yet in \`.claude/rules/workspace-patterns.md\`.
-   If \`workspace-patterns.md\` has no rules yet and 5+ resources exist in \`src/\`,
-   suggest adding patterns. Surface suggestions only -- do not auto-generate.
-8. **Project map freshness:** Check whether \`docs/project-map.mdx\` reflects the
-   current project state (resources, commands, rules, skills, memory files).
-   Compare filesystem state against the map. If stale, run \`elevasis-sdk deploy\`
-   to regenerate, or patch inline for minor drift.
-
-Each step reports its result. Steps 1-8 run even if step 0 is skipped.
-
-## Merge Strategy
-
-- **CLAUDE.md:** Add new sections in correct position. Preserve customizations.
-- **Commands:** Usually additive. Show diff for changes.
-- **.gitignore:** Append-only -- never remove existing entries.
-
-## Template Access
-
-The agent reads current templates from the installed SDK:
-\`@elevasis/sdk/templates\` subpath exports all template functions.
-`;
-}
-function claudeDeployCommandTemplate() {
-  return `# /deploy command
-
-You are a project management assistant for this Elevasis workspace.
-
-## Context
-
-Read \`elevasis.config.ts\` to get the current \`templateVersion\`.
-Read \`package.json\` to get the installed \`@elevasis/sdk\` version.
-Read \`.claude/memory/index.md\` if it exists for project state.
-
-## Operation
-
-0. Read \`reference/deployment/command-center.mdx\` -- understand the Command View
-   model, relationship declarations, and what deploy-time validation checks.
-   This context is essential for diagnosing validation failures in steps 1-2.
-1. Run \`elevasis-sdk check\` (validation)
-2. Type check if \`tsconfig.json\` exists
-3. Verify docs reflect current resources
-4. If git configured: stage changes, commit with deploy message
-5. Run \`elevasis-sdk deploy\`
-6. \`docs/project-map.mdx\` is auto-regenerated by deploy (no manual bump needed)
-7. Verify deployment via platform
-8. Update \`.claude/memory/deployment-state.md\` with count, timestamp, inventory
-9. If git configured and remote exists: optionally push
-
-Each step reports its result. Pipeline stops on failure with suggested fix.
-If validation fails with relationship errors, re-read \`reference/deployment/command-center.mdx\`
-for the enforcement model and common fixes.
-`;
-}
-function claudeDiagnosticsSkillTemplate() {
-  return `---
-name: diagnostics
-description: "Execution diagnostics and runtime debugging. TRIGGER when: an execution fails, user asks why something failed or errored, user mentions runtime errors or unexpected behavior, or agent observes a failed execution result. DO NOT TRIGGER when: user is discussing errors in code (type errors, lint errors) or build failures -- those are development issues, not runtime diagnostics."
----
-
-# Execution Diagnostics
-
-You are a runtime diagnostics assistant for this Elevasis workspace.
-
-## Context
-
-Read \`.claude/memory/errors/index.md\` if it exists for past error patterns.
-Read \`.claude/memory/deployment-state.md\` if it exists for deployment context.
-
-## When Triggered
-
-Diagnose runtime failures and environment issues:
-
-1. **Identify the failure** -- get the execution ID and resource ID from the error or conversation context
-2. **Pull execution details** -- run \`elevasis-sdk execution <resource-id> <execution-id>\` to get logs
-3. **Cross-reference** -- check \`.claude/memory/errors/\` for known patterns
-4. **Check deployment status** -- is the resource deployed? Is it the latest version?
-5. **Verify environment** -- API key valid, required credentials accessible
-6. **Diagnose root cause** -- analyze logs, identify the failing step, trace the error
-7. **Record** -- save new error patterns to \`.claude/memory/errors/\` with context and fix
-8. **Suggest fix** -- propose a concrete fix or next step
-
-If the error has occurred before (found in memory/errors/), apply the known fix directly.
-If it recurs 3+ times, suggest adding a rule to \`.claude/rules/workspace-patterns.md\`.
-`;
-}
-function claudeWorkSkillTemplate() {
-  return `---
-name: work
-description: "Task tracking and progress persistence. TRIGGER when: user says /work, asks to track or save progress across sessions, asks what they were working on, wants to create/resume/complete a task doc, or says they are done for today. DO NOT TRIGGER when: user is just doing work without wanting to track it in docs/in-progress/."
----
-
-# Task Tracking
-
-You are a task tracking assistant for this Elevasis workspace. \`/work\` is the primary interface for managing all work and projects.
-
-Your job is to **intelligently manage tasks without requiring the user to know subcommands**. Detect what the user needs from context and act accordingly.
-
-## Context
-
-Read \`docs/priorities.mdx\` if it exists for current priorities.
-Scan \`docs/in-progress/\` recursively for \`.mdx\` files with \`status\` frontmatter.
-
-## Directory Structure
-
-Task docs live in \`docs/in-progress/\`. Organize intelligently:
-
-- **Small standalone tasks**: \`docs/in-progress/<slug>.mdx\`
-- **Multi-file tasks**: \`docs/in-progress/<slug>/index.mdx\` (+ supporting docs)
-- **Related tasks**: group under the same directory
-
-When scanning, treat \`index.mdx\` as the primary task doc for a directory.
-
-## Status Values
-
-Enforce exactly three values in frontmatter: \`planned\`, \`in-progress\`, \`complete\`.
-
-## Intent Detection
-
-When \`/work\` is invoked (with or without arguments), detect intent from context:
-
-| Signal | Action |
-|--------|--------|
-| No arguments, no active conversation context | **List** tasks, then let user pick |
-| User picks a number or names a task | **Resume** that task automatically |
-| User describes new work (not matching existing tasks) | **Create** a task doc automatically |
-| \`/work\` with a description that matches no existing task | **Create** automatically |
-| \`/work\` with a keyword/name matching an existing task | **Resume** automatically |
-| Conversation is getting heavy, user wrapping up, or 2+ steps completed | **Save** automatically |
-| All plan steps are COMPLETE | **Suggest** \`/work complete\` (never auto-invoke) |
-
-**Key principle:** Create, save, and resume are auto-invoked. Complete always asks permission first.
-
-## Behaviors
-
-### List and Pick (default when no context)
-
-1. Scan \`docs/in-progress/\` recursively for \`.mdx\` files with \`status\` frontmatter
-2. For directories, read \`index.mdx\` as the primary task doc
-3. Display a numbered list sorted by status (\`in-progress\` first, then \`planned\`, then \`complete\`):
-
-\`\`\`
-Active Tasks
-============
-
-1. [in-progress] SDK Adapter Migration
-   Last saved: 2026-03-02 | Step 3/5: Building factory adapters
-
-2. [planned] Email Template System
-   Created: 2026-03-01 | Not started
-
-3. [complete] CRM Integration
-   Completed: 2026-03-03
-
-Pick a task by number or name, or describe new work to start.
-\`\`\`
-
-4. Cross-reference with \`docs/priorities.mdx\` if it exists
-5. When the user picks a number or describes a task, auto-invoke the appropriate flow (resume or create)
-6. If no tasks found, ask: "What are you trying to accomplish?"
-
-### Create (auto-invoked when new work detected)
-
-1. If the user's intent is clear, skip the interview and create directly
-2. If ambiguous, ask 1-2 focused questions:
-   - "What does success look like?" (acceptance criteria)
-   - "Do we need to investigate anything first, or is the path clear?"
-3. Scan \`docs/in-progress/\` for existing directories related to the topic
-4. Determine directory placement:
-   - If related to existing directory, create as a file within it
-   - If new concept that may grow, create \`docs/in-progress/<slug>/index.mdx\`
-   - If small/standalone, create \`docs/in-progress/<slug>.mdx\`
-5. Create the doc with \`status: planned\` and structured sections:
-
-\`\`\`yaml
----
-title: {Task Title}
-description: {Concise description}
-status: planned
----
-\`\`\`
-
-Sections: Objective (what and why), Plan (numbered steps), Progress (per-step tracking with PENDING markers), Resume Context (current state, key docs, "To continue" prompt).
-
-6. Update \`docs/priorities.mdx\` if it exists
-7. Report what was created with location and step count
-
-### Save (auto-invoked when progress detected)
-
-Auto-save triggers (do NOT ask, just save):
-- 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
-
-Save flow:
-1. Identify the current task from conversation context
-2. If not working on a tracked task, offer to create a new one
-3. Update Progress section:
-   - Mark completed steps as \`COMPLETE\` with: what was done, key decisions, files changed
-   - Mark current step as \`IN PROGRESS\` with current state
-   - Leave future steps as \`PENDING\`
-4. Update Resume Context section with:
-   - Current State ({today's date}): summary of accomplishments and next steps
-   - Files Modified: table of file paths and descriptions of changes
-   - Key docs to read on resume: file paths with why they matter
-   - To continue: copy-pasteable prompt for the next session
-5. Set \`status\` appropriately (\`in-progress\` if ongoing)
-6. Briefly confirm: "Progress saved to {path}."
-
-### Resume (auto-invoked when existing task detected)
-
-**Resolution order:**
-1. If a number is given, map to the numbered list from the task list
-2. If a name/keyword is given, substring match against task titles and filenames in \`docs/in-progress/\`
-3. If no argument, scan for \`status: in-progress\` docs -- if one found, use it; if multiple, list and ask
-4. If multiple matches, list them and ask which to resume
-
-**Resume flow:**
-1. Read the target task doc
-2. Parse the Resume Context section
-3. Load key docs listed in "Key docs to read on resume" in parallel
-4. Quick verify: check that referenced files exist (Glob), report warnings for missing files
-5. Present resume summary:
-
-\`\`\`
-Resuming: {task title}
-========================
-
-Last completed: Step {N}: {title}
-Next: Step {M}: {title}
-
-Key context loaded:
-- {doc 1}
-- {doc 2}
-
-Ready to continue. {Copy of "To continue" prompt}
-\`\`\`
-
-### Complete (NEVER auto-invoked -- always suggest)
-
-When all plan steps are COMPLETE, suggest: "All steps for '{task}' look done. Want me to finalize it?"
-
-Only proceed after explicit user confirmation. Then:
-
-1. **Validate readiness:** Check that all plan steps are marked COMPLETE. If not, warn and ask for confirmation.
-2. **Clean up the doc:**
-   - Strip \`## Resume Context\` section entirely (header through next \`##\` or EOF)
-   - Strip progress markers: \`COMPLETE\`, \`IN PROGRESS\`, \`PENDING\` from step headings
-   - Remove steps still marked PENDING entirely (header + body) -- they were never done
-   - Remove \`status\` from frontmatter (keep \`title\` and \`description\`)
-   - Target 200-400 lines; flag if result exceeds 500 lines
-3. **Determine destination:**
-   - Scan \`docs/\` (excluding \`docs/in-progress/\`) for existing directories related to this work
-   - If a related directory exists, propose merging into it
-   - If no related directory, propose \`docs/<slug>/\` or \`docs/<slug>.mdx\`
-   - Present the proposed destination and ask user to confirm
-4. **Move the doc(s):**
-   - Single file: move from \`docs/in-progress/\` to destination
-   - Directory: move entire directory
-5. **Verify and report:**
-   - Confirm destination exists, source removed
-   - Check no leftover \`status:\` or \`## Resume Context\` in moved files
-   - Update \`docs/priorities.mdx\` if it exists
-   - Report: task title, cleanup stats (lines before/after), destination path
-`;
-}
-function claudeDocsCommandTemplate() {
-  return `# /docs command
-
-You are a documentation assistant for this Elevasis workspace. \`/docs\` manages the
-permanent \`docs/\` tree -- browsing, creating reference content, and verifying accuracy
-against code.
-
-**Scope:** Everything in \`docs/\` EXCEPT:
-- \`docs/in-progress/\` -- \`/work\`'s territory
-- \`docs/project-map.mdx\` and \`docs/resource-map.mdx\` -- auto-generated, read-only
-
-## Context
-
-Read \`.claude/memory/profile/skills.md\` first. The \`automation\` skill level controls
-how results are presented.
-
-## Operations
-
-### \`/docs\` (no arguments) -- Browse
-
-Scan \`docs/\` recursively. Display:
-
-\`\`\`
-Your Docs
-=========
-
-Auto-generated (read-only):
-  project-map.mdx      Updated 2026-03-03
-  resource-map.mdx     Updated 2026-03-03
-
-Reference (3):
-  1. index.mdx              Workspace overview
-  2. priorities.mdx         Current priorities
-  3. crm-integration/       CRM integration guide (2 files)
-
-Pick a number to read and discuss, or say:
-  "create" to write a new doc
-  "verify" to check docs against current code
-\`\`\`
-
-Steps:
-1. Scan \`docs/\` recursively for \`.mdx\` files, excluding \`in-progress/\`
-2. Separate auto-generated files (\`project-map.mdx\`, \`resource-map.mdx\`) into a
-   read-only group -- show modification date, no number
-3. Number all user-maintained docs. For directories, show \`index.mdx\` as primary
-   with file count
-4. Sort: \`index.mdx\` first, \`priorities.mdx\` second, then alphabetical
-5. When user picks a number: read the file and present a summary. Ask what they
-   want -- discuss, update, or go back
-6. If only auto-generated files and \`index.mdx\` exist, suggest: "Your docs/ is
-   mostly empty. Run \`/docs create\` to add reference documentation."
-
-**automation: none** -- Frame as "your project's knowledge base." Plain language:
-"These are your project's permanent notes. Pick one to read or discuss."
-
-**automation: low-code** -- Standard presentation. Map to "like a wiki for your automations."
-
-**automation: custom** -- Compact. Show file sizes and last-modified dates.
-
----
-
-### \`create [description]\` -- Reference Doc Creation
-
-Interview-driven creation for permanent documentation. Task docs go through \`/work\`.
-
-1. If no description given, ask: "What do you want to document?"
-2. Determine doc type (infer or ask):
-   - **Resource guide** -- documents a specific workflow or agent
-   - **Integration guide** -- how a specific external tool is used
-   - **Architecture notes** -- design decisions, system diagrams
-   - **Process doc** -- operational procedures, runbooks
-   - **General reference** -- glossaries, onboarding, anything else
-3. If the doc is about a specific resource: scan \`src/\` for matching resource IDs.
-   If found, pre-populate with resource config, schemas, step names, and platform
-   tools used. The user does not need to describe what the resource does.
-4. Determine placement:
-   - Scan \`docs/\` for existing directories related to the topic
-   - If related to an existing directory, propose adding to it
-   - If the topic may grow into multiple files, create \`docs/<slug>/index.mdx\`
-   - If small and standalone, create \`docs/<slug>.mdx\`
-5. Create with proper frontmatter:
-   \`\`\`yaml
-   ---
-   title: Guide Title
-   description: What this covers
-   ---
-   \`\`\`
-   Sections by doc type:
-   - **Resource guide:** Overview, Input/Output, How It Works, Platform Tools Used, Configuration
-   - **Integration guide:** Overview, Setup (credentials), Data Model, Usage Patterns, Troubleshooting
-   - **Architecture notes:** Context, Decision, Consequences, Alternatives Considered
-   - **Process doc:** Purpose, Prerequisites, Steps, Recovery
-   - **General reference:** determined by content
-6. Report what was created and suggest next steps.
-
-**automation: none** -- Agent writes the full doc from code analysis. User reviews and
-approves. "I've written a guide for your CRM integration based on the code. Take a look
-and tell me if anything is missing."
-
-**automation: low-code** -- Agent drafts, highlights sections the user should customize.
-Shows what was auto-detected vs what needs human input.
-
-**automation: custom** -- Agent scaffolds structure and fills in code-derived content.
-Leaves technical prose to the user. Concise.
-
----
-
-### \`verify [file?]\` -- Interactive Documentation Verification
-
-Standalone interactive version of \`/fix\` step 5. Checks docs against current code.
-
-**Without argument -- verify all:**
-
-1. Scan \`docs/\` for user-maintained \`.mdx\` files (skip \`in-progress/\`,
-   \`project-map.mdx\`, \`resource-map.mdx\`)
-2. For each file: cross-reference resource IDs, schema fields, and platform tools
-   mentioned against \`src/\`
-3. Check for undocumented resources: resources in \`src/\` without docs coverage
-4. Present results interactively:
-
-\`\`\`
-Docs Verification
-=================
-
-crm-integration/index.mdx:
-  - Line 23: references resourceId "attio-sync" but src/ has "attio-sync-v2"
-  - Line 45: schema field "companyName" no longer exists in input schema
-
-onboarding-guide.mdx:
-  - No issues found
-
-Undocumented resources (2):
-  - email-sender (src/communications/email-sender.ts)
-  - lead-scorer (src/scoring/lead-scorer.ts)
-
-Fix crm-integration issues now? (yes/no/skip)
-\`\`\`
-
-5. When user says yes: read source code, apply fixes to doc, show the diff
-6. For undocumented resources: offer to create a doc for each one (invokes \`create\` flow)
-
-**With argument -- verify one file:**
-
-Same but scoped to a single file. Resolves by substring match against \`docs/\` file names.
-
-\`\`\`
-/docs verify crm-integration
-\`\`\`
-
-**automation: none** -- Plain language: "Your CRM guide mentions a field called
-'companyName' but that field was renamed to 'company'. Want me to fix it?"
-
-**automation: low-code** -- Standard presentation with suggested fixes.
-
-**automation: custom** -- Compact diff-style. Auto-fix obvious issues, ask only for
-ambiguous ones.
-
----
-
-## What /docs Does NOT Do
-
-- Touch \`docs/in-progress/\` -- \`/work\`'s territory
-- Handle task lifecycle (planned / in-progress / complete)
-- Edit \`project-map.mdx\` or \`resource-map.mdx\` -- auto-generated, read-only
-- Replace \`/fix\` step 5 -- it supplements it with interactivity
-`;
-}
-function claudeCredsSkillTemplate() {
-  return `---
-name: creds
-description: "Credential management assistant. TRIGGER when: user mentions credentials, API keys, secrets, webhook secrets, or asks to set up integrations that need authentication. DO NOT TRIGGER when: user is discussing code that references credentials without needing to manage them."
----
-
-# Credential Management
-
-You are a credential management assistant for this Elevasis workspace.
-
-## Context
-
-Credentials are stored encrypted (AES-256-GCM) on the Elevasis platform and scoped to your
-organization. They are used by workflows and agents at runtime via \`platform.getCredential()\`
-or the \`credential:\` field on tool steps.
-
-The SDK CLI (\`elevasis-sdk creds\`) manages credentials via API key authentication.
-Your \`ELEVASIS_PLATFORM_KEY\` in \`.env\` determines the organization.
-
-## Credential Types
-
-| Type | Value Format | Example Providers |
-| --- | --- | --- |
-| \`api-key\` | \`{"apiKey": "sk-..."}\` | Stripe, Resend, Apify, Attio, Instantly |
-| \`webhook-secret\` | \`{"signingSecret": "whsec_..."}\` | Cal.com, Stripe webhooks |
-| \`oauth\` | N/A (browser flow only) | Notion, Google Sheets, Dropbox |
-
-OAuth credentials **cannot** be created via CLI. Redirect the user to the Command Center UI.
-
-## Naming Rules
-
-- Lowercase letters, digits, and hyphens only (\`[a-z0-9-]\`)
-- No consecutive hyphens (\`--\`)
-- 1-100 characters
-- Convention: \`{org}-{provider}\` (e.g., \`tester-stripe-key\`, \`my-project-resend\`)
-
-## Operations
-
-**No arguments (default):** Show this reference and list credentials.
-
-**\`list\`:** List all credentials for the organization.
-\`\`\`bash
-elevasis-sdk creds list
-\`\`\`
-Display the output. Note which are \`oauth\` (not modifiable via CLI).
-
-**\`create\`:** Guided credential creation flow:
-1. Ask credential type (\`api-key\` or \`webhook-secret\`). Not \`oauth\`.
-2. Ask credential name. Validate naming rules before proceeding.
-3. Ask the user to paste the credential value directly in chat.
-   - For \`api-key\`: ask for the API key, construct \`{"apiKey": "..."}\`
-   - For \`webhook-secret\`: ask for the signing secret, construct \`{"signingSecret": "..."}\`
-4. Pipe to CLI: \`echo '{"apiKey":"..."}' | elevasis-sdk creds create --name {name} --type {type}\`
-5. Confirm success. **NEVER echo the credential value back.**
-
-**\`update\`:** Update credential value:
-1. Run \`elevasis-sdk creds list\` to confirm the credential exists.
-2. Ask the user to paste the new value.
-3. Pipe to CLI: \`echo '{"apiKey":"..."}' | elevasis-sdk creds update {name}\`
-4. Confirm success. **NEVER echo the value.**
-
-**\`rename\`:** Rename a credential:
-1. Run \`elevasis-sdk creds list\` to confirm it exists.
-2. Ask for the new name. Validate naming rules.
-3. Run: \`elevasis-sdk creds rename {name} --to {newName}\`
-
-**\`delete\`:** Delete a credential:
-1. Run \`elevasis-sdk creds list\` to confirm it exists.
-2. Confirm with user before proceeding.
-3. Run: \`elevasis-sdk creds delete {name} --force\`
-
-**\`webhook-url\`:** Generate a webhook URL:
-Ask for provider, org UUID, resource ID, and credential name. Construct:
-\`POST https://api.elevasis.io/api/webhooks/{provider}?org={uuid}&resource={resourceId}&credential={credentialName}\`
-
-**\`audit\`:** Scan project for credential references:
-1. Search \`src/**/*.ts\` for \`credential:\` patterns and \`platform.getCredential()\` calls.
-2. Extract all credential names referenced.
-3. Run \`elevasis-sdk creds list\` to get the actual credential list.
-4. Report: missing credentials (referenced but not created), unused credentials (created but not referenced).
-
-## Security Rules (MANDATORY)
-
-- **NEVER** log, repeat, or display credential values after the user provides them
-- **NEVER** store credential values in files, memory, or command history
-- If an API call fails, ask the user to **re-paste** rather than retrying with a cached value
-- Always confirm name and type **before** asking for the value
-- OAuth credentials cannot be created via CLI -- redirect to Command Center UI
-`;
-}
-function claudeSdkPatternsRuleTemplate() {
-  return `---
-description: Elevasis SDK patterns -- imports, source structure, runtime, and platform tools
-paths:
-  - src/**
-  - elevasis.config.ts
----
-
-# SDK Patterns
-
-## Imports
-
-- \`@elevasis/sdk\` -- types and constants: \`WorkflowDefinition\`, \`StepType\`, \`ExecutionError\`, \`ToolingError\`
-- \`@elevasis/sdk/worker\` -- runtime: \`platform\`, \`PlatformToolError\`, typed adapters
-- **Never import from \`@repo/core\`** -- monorepo-internal, not available in external projects
-
-## Source Structure
-
-- All resource definitions live in \`src/\` and are exported via \`src/index.ts\`
-- Organize by business domain: \`src/<domain>/\` (e.g., \`src/operations/\`, \`src/acquisition/\`)
-- Each domain barrel (\`src/<domain>/index.ts\`) exports \`workflows\` and \`agents\` arrays
-- Cross-domain utilities go in \`src/shared/\`; domain-specific utilities in \`src/<domain>/shared/\`
-- The default export in \`src/index.ts\` must be a \`DeploymentSpec\` object
-- \`resourceId\` must be lowercase with hyphens, unique per organization
-- \`dist/\` is generated by deploy -- never commit it
-
-## Runtime
-
-- \`.env\` contains only \`ELEVASIS_PLATFORM_KEY\` for CLI auth -- never deployed, never in worker memory
-- Integration credentials are managed via the \`creds\` skill or Command Center UI
-
-## Platform Tools
-
-Prefer typed adapters over raw \`platform.call()\`.
-
-### Singleton adapters (no credential needed)
-
-\`\`\`typescript
-import { scheduler, storage, llm, notifications, acqDb, pdf, approval, execution, email } from '@elevasis/sdk/worker'
-\`\`\`
-
-### Factory adapters (credential-bound)
-
-\`\`\`typescript
-import { createAttioAdapter, createResendAdapter } from '@elevasis/sdk/worker'
-const attio = createAttioAdapter('credential-name')
-\`\`\`
-
-Use \`platform.call()\` directly only for tools without adapters: \`supabase\`, \`session-memory\`, \`hitl\`, \`status\`, \`http\`.
-`;
-}
-function claudeDocsAuthoringRuleTemplate() {
-  return `---
-description: Documentation conventions for docs/ files -- MDX escaping, frontmatter, structure
-paths:
-  - docs/**/*.mdx
----
-
-# Docs Authoring
-
-## MDX Escaping
-
-- Less-than \`<\` must be \`\\<\` (MDX interprets bare \`<\` as JSX tag)
-- Curly braces \`{var}\` must be in backticks or escaped: \`\\{var\\}\`
-- Greater-than \`>\` must be \`\\>\`
-
-## Frontmatter
-
-Every \`.mdx\` file requires \`title\` and \`description\`:
-
-\`\`\`yaml
----
-title: Feature Name
-description: Concise description
----
-\`\`\`
-
-## Structure
-
-- \`docs/project-map.mdx\` is auto-generated -- do not edit manually
-- \`docs/in-progress/\` for task tracking docs
-- Sort order via \`order\` frontmatter field (lower = earlier)
-`;
-}
-function claudeMemoryConventionsRuleTemplate() {
-  return `---
-description: Memory system conventions -- what to store, structure, pruning
-paths:
-  - .claude/memory/**
----
-
-# Memory Conventions
-
-## What Memory Is
-
-Memory stores persistent agent state: skills, errors, tutorial progress.
-It is NOT for instructions (commands), reference docs, or templates.
-
-## Structure
-
-- \`index.md\` at every level maps to children
-- Start at root index and drill down
-- When a file outgrows a single document, split into a subdirectory
-
-## Pruning
-
-- Keep ~20 recent entries per table; drop stale patterns (30+ days)
-- If an error recurs 3+ times, promote to \`.claude/rules/workspace-patterns.md\`
-`;
-}
-function claudeProjectMapRuleTemplate() {
-  return `---
-description: Project map conventions -- auto-generated, do not edit, maintained by deploy and /fix
-paths:
-  - docs/project-map.mdx
-  - docs/resource-map.mdx
----
-
-# Project Map
-
-- \`docs/project-map.mdx\` and \`docs/resource-map.mdx\` are fully auto-generated by \`elevasis-sdk deploy\`
-- Do not edit either file manually -- changes are overwritten on next deploy
-- \`/fix\` step 8 checks for drift and patches the map
-- If a new command, rule, skill, or memory file is added, run \`/fix\` or \`elevasis-sdk deploy\` to update
-`;
-}
-function claudeTaskTrackingRuleTemplate() {
-  return `---
-description: In-progress task conventions -- /work command, doc format, status values, auto-save behavior
-paths:
-  - docs/in-progress/**
----
-
-# Task Tracking
-
-## Status Values
-
-Exactly three values for frontmatter \`status\`: \`planned\`, \`in-progress\`, \`complete\`.
-
-## Doc Format
-
-- Frontmatter: \`title\`, \`description\`, \`status\`
-- 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.
-
-## 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?"
-
-## Directory Conventions
-
-- \`docs/in-progress/\` for all active task docs
-- Small tasks: \`<slug>.mdx\` directly in \`docs/in-progress/\`
-- Multi-file tasks: \`<slug>/index.mdx\` with supporting docs alongside
-- Completed tasks move OUT of \`docs/in-progress/\` to \`docs/<relevant-dir>/\`
-`;
-}
-function claudeLoggingRuleTemplate() {
-  return `---
-description: Logging conventions for workflow and agent handlers
-paths:
-  - src/**
----
-
-# Logging
-
-## Always Use \`context.logger\` in Handlers
-
-**Never use \`console.log\`, \`console.warn\`, or \`console.error\` in step/agent handlers.**
-The platform does not capture \`console.*\` output \u2014 it will not appear in execution logs.
-
-\`\`\`typescript
-// \u274C WRONG \u2014 invisible in Command Center
-handler: async (rawInput) => {
-  console.log('Processing...')
-}
-
-// \u2705 CORRECT \u2014 visible in Command Center
-handler: async (rawInput, context) => {
-  context.logger.info('Processing...')
-}
-\`\`\`
-
-## Logger Methods
-
-\`\`\`typescript
-context.logger.debug('Verbose detail \u2014 shown in debug mode only')
-context.logger.info('Normal progress messages')
-context.logger.warn('Non-fatal issue \u2014 skipped, retried, partial result')
-context.logger.error('Fatal error or unexpected failure')
-\`\`\`
-
-## Extensive Logging Standard
-
-Every handler should log:
-
-1. **Entry** \u2014 step name + key input params (category, count, domain, etc.)
-2. **Progress** \u2014 inside loops: per-item status (processed, skipped, failed)
-3. **Decisions** \u2014 idempotency skips, early exits, conditional branches
-4. **Summary** \u2014 counts at the end (X processed, Y skipped, Z errors)
-
-\`\`\`typescript
-handler: async (rawInput, context) => {
-  const data = rawInput as SomeType
-  context.logger.info(\`[step-name] Starting \u2014 \${data.items.length} items\`)
-
-  let processed = 0, skipped = 0
-  for (const item of data.items) {
-    if (item.alreadyDone) {
-      skipped++
-      context.logger.info(\`[step-name] Skipping \${item.name} \u2014 already complete\`)
-      continue
-    }
-    // ...
-    processed++
-    context.logger.info(\`[step-name] Processed \${item.name}\`)
-  }
-
-  context.logger.info(\`[step-name] Done \u2014 \${processed} processed, \${skipped} skipped\`)
-}
-\`\`\`
-
-## Warnings vs Errors
-
-- \`warn\`: skipped item, not found in DB, LLM timeout on one domain (processing continues)
-- \`error\`: step-level failures that propagate as thrown errors (log before throwing if possible)
-`;
-}
-function claudePostEditValidateHookTemplate() {
-  return `#!/usr/bin/env node
-// post-edit-validate.mjs
-// PostToolUse hook \u2014 auto-formats with prettier, type-checks .ts/.tsx files.
-// Fires after Edit|Write|MultiEdit succeeds.
-
-import { existsSync } from 'node:fs'
-import { resolve, normalize, extname, join, dirname } from 'node:path'
-import { execSync } from 'node:child_process'
-
-const ROOT = process.env.CLAUDE_PROJECT_DIR ?? process.cwd()
-
-// Extensions prettier should format
-const PRETTIER_EXTENSIONS = new Set([
-  '.ts', '.tsx', '.js', '.jsx', '.mjs', '.cjs', '.json', '.css', '.md', '.mdx'
-])
-
-// Extensions that trigger type-checking
-const TS_EXTENSIONS = new Set(['.ts', '.tsx'])
-
-function findNearestTsconfig(startDir) {
-  let dir = startDir
-  const root = normalize(ROOT)
-  while (dir.length >= root.length) {
-    const candidate = join(dir, 'tsconfig.json')
-    if (existsSync(candidate)) return candidate
-    const parent = dirname(dir)
-    if (parent === dir) break
-    dir = parent
-  }
-  return null
-}
-
-try {
-  const chunks = []
-  for await (const chunk of process.stdin) chunks.push(chunk)
-  const input = JSON.parse(Buffer.concat(chunks).toString())
-
-  const filePath = input.tool_input?.file_path
-  if (!filePath) process.exit(0)
-
-  const ext = extname(filePath).toLowerCase()
-  const absPath = normalize(resolve(filePath))
-  if (!existsSync(absPath)) process.exit(0)
-
-  const results = []
-
-  // 1. Prettier
-  if (PRETTIER_EXTENSIONS.has(ext)) {
-    try {
-      execSync('pnpm exec prettier --write "' + absPath + '"', {
-        cwd: ROOT,
-        stdio: ['pipe', 'pipe', 'pipe'],
-        timeout: 10_000
-      })
-    } catch (err) {
-      const stderr = err.stderr?.toString().trim() || ''
-      if (stderr && !/ignored/i.test(stderr)) {
-        results.push('Prettier error: ' + stderr.slice(0, 300))
-      }
-    }
-  }
-
-  // 2. Type-check for .ts/.tsx
-  if (TS_EXTENSIONS.has(ext)) {
-    const tsconfig = findNearestTsconfig(dirname(absPath))
-    if (tsconfig) {
-      try {
-        execSync('pnpm exec tsc --noEmit -p "' + tsconfig + '"', {
-          cwd: ROOT,
-          stdio: ['pipe', 'pipe', 'pipe'],
-          timeout: 30_000,
-          env: { ...process.env, NODE_OPTIONS: '--max-old-space-size=4096' }
-        })
-      } catch (err) {
-        if (err.killed) process.exit(0) // Don't block on timeout
-        const stdout = err.stdout?.toString() || ''
-        if (stdout.includes('error TS')) {
-          const errorLines = stdout
-            .split('\\n')
-            .filter(l => l.includes('error TS'))
-            .slice(0, 10)
-          results.push('Type errors after editing ' + filePath + ':\\n' + errorLines.join('\\n'))
-        }
-      }
-    }
-  }
-
-  // Output errors to Claude's context (silence = success)
-  if (results.length > 0) {
-    process.stderr.write(results.join('\\n\\n'))
-    process.exit(2) // Exit 2 = send stderr as feedback to Claude
-  }
-} catch {}
-
-process.exit(0)
-`;
-}
-function claudeToolFailureRecoveryHookTemplate() {
-  return `#!/usr/bin/env node
-// tool-failure-recovery.mjs
-// PostToolUseFailure hook \u2014 pattern-matches known Bash errors and returns
-// recovery advice via stderr + exit 2 (feedback to Claude).
-
-const RECOVERY_TABLE = [
-  {
-    test: r => /JavaScript heap out of memory/i.test(r),
-    advice: 'Out of memory.',
-    fix: 'Run the command with NODE_OPTIONS="--max-old-space-size=4096".',
-    why: 'Large TypeScript projects can exceed Node default heap limit.',
-  },
-  {
-    test: r => /boundary hook/i.test(r) && /block|denied/i.test(r),
-    advice: 'Command blocked by SDK boundary hook.',
-    fix: 'Ask the user to run this command manually.',
-    why: 'The boundary hook blocks file modifications (Write, Edit, destructive Bash) outside the project boundary.',
-    see: 'CLAUDE.md',
-  },
-  {
-    test: r => /ENOENT/.test(r) && /node_modules/.test(r),
-    advice: 'Missing node_modules dependency.',
-    fix: 'Run: pnpm install',
-    why: 'Dependencies are not installed or were cleared.',
-  },
-  {
-    test: r => /ERR_MODULE_NOT_FOUND/.test(r) && /@elevasis\\/sdk/.test(r),
-    advice: '@elevasis/sdk module not found.',
-    fix: 'Run: pnpm install \u2014 then verify @elevasis/sdk is in package.json dependencies.',
-    why: 'The SDK package is not installed or the version is mismatched.',
-  },
-  {
-    test: r => /ERR_MODULE_NOT_FOUND/.test(r),
-    advice: 'Module not found at import path.',
-    fix: 'Check the import path and verify the package is installed (pnpm install).',
-    why: 'The import path does not match any installed package or local file.',
-  },
-  {
-    test: r => /TS2307/.test(r) || (/cannot find/i.test(r) && /declaration/i.test(r)),
-    advice: 'TypeScript cannot resolve module or declaration file.',
-    fix: 'Check that the package is installed and tsconfig paths are correct.',
-    why: 'Missing dependency or incorrect TypeScript configuration.',
-  },
-  {
-    test: r => /EPERM/.test(r) || /permission denied/i.test(r),
-    advice: 'Permission denied (EPERM).',
-    fix: 'Close the file in any other process (editor, terminal, or dev server) and retry.',
-    why: 'On Windows, files locked by another process cannot be written to.',
-  },
-  {
-    test: r => /lockfile/i.test(r) && /conflict|outdated|ERR_PNPM/i.test(r),
-    advice: 'pnpm lockfile conflict or outdated.',
-    fix: 'Run: pnpm install to regenerate the lockfile.',
-    why: 'The lockfile is out of sync with package.json changes.',
-  },
-  {
-    test: r => /elevasis-sdk check/.test(r) || /elevasis-sdk deploy/.test(r),
-    advice: 'elevasis-sdk CLI command failed.',
-    fix: 'Check the error output above. Common causes: missing .env ELEVASIS_API_KEY, invalid resource schemas, or network issues.',
-    why: 'The SDK CLI validates resources and communicates with the platform API.',
-  },
-  {
-    test: r => /EADDRINUSE/.test(r),
-    advice: 'Port already in use.',
-    fix: 'Find and kill the process using the port, or use a different port.',
-    why: 'A previous dev server or process is still holding the port.',
-  },
-]
-
-function formatRecovery(entry) {
-  let msg = 'FAILED: ' + entry.advice + '\\nFIX: ' + entry.fix
-  if (entry.why) msg += '\\nWHY: ' + entry.why
-  if (entry.see) msg += '\\nSEE: ' + entry.see
-  return msg
-}
-
-try {
-  const chunks = []
-  for await (const chunk of process.stdin) chunks.push(chunk)
-  const input = JSON.parse(Buffer.concat(chunks).toString())
-
-  const response = input.tool_response ?? ''
-
-  for (const entry of RECOVERY_TABLE) {
-    if (entry.test(response)) {
-      process.stderr.write(formatRecovery(entry))
-      process.exit(2)
-    }
-  }
-} catch {}
-
-process.exit(0)
-`;
-}
-
-// src/cli/commands/templates/core/resources.ts
-function starterWorkflowTemplate() {
-  return `import type { WorkflowDefinition } from '@elevasis/sdk'
-import { z } from 'zod'
-
-const echoInput = z.object({ message: z.string() })
-const echoOutput = z.object({ echo: z.string() })
-type EchoInput = z.infer<typeof echoInput>
-
-export const echo: WorkflowDefinition = {
-  config: {
-    resourceId: 'echo',
-    name: 'Echo',
-    type: 'workflow',
-    description: 'Echoes the input message back',
-    version: '1.0.0',
-    status: 'dev',
-  },
-  contract: {
-    inputSchema: echoInput,
-    outputSchema: echoOutput,
-  },
-  steps: {
-    echo: {
-      id: 'echo',
-      name: 'Echo Message',
-      description: 'Returns the input message',
-      handler: async (input) => {
-        const { message } = input as EchoInput
-        return { echo: message }
-      },
-      inputSchema: echoInput,
-      outputSchema: echoOutput,
-      next: null,
-    },
-  },
-  entryPoint: 'echo',
-}
-`;
-}
-function platformStatusTemplate() {
-  return `import type { WorkflowDefinition } from '@elevasis/sdk'
-import { StepType } from '@elevasis/sdk'
-import { platform } from '@elevasis/sdk/worker'
-import { llm } from '@elevasis/sdk/worker'
-import { z } from 'zod'
-
-const input = z.object({
-  timeRange: z.enum(['1h', '24h', '7d']).default('24h').describe('Time window for status data'),
-})
-
-const statusData = z.object({
-  raw: z.unknown().describe('Raw status overview from platform'),
-})
-
-const output = z.object({
-  raw: z.unknown().describe('Raw status overview from platform'),
-  summary: z.string().describe('Natural language status summary'),
-})
-
-type Input = z.infer<typeof input>
-
-export const platformStatus: WorkflowDefinition = {
-  config: {
-    resourceId: 'platform-status',
-    name: 'Platform Status',
-    type: 'workflow',
-    description: 'Gathers cross-system platform status and compiles a natural language summary',
-    version: '1.0.0',
-    status: 'dev',
-  },
-  contract: { inputSchema: input, outputSchema: output },
-  steps: {
-    'gather-status': {
-      id: 'gather-status',
-      name: 'Gather Status',
-      description: 'Queries platform status overview (executions, pending items, schedules, credentials)',
-      handler: async (rawInput) => {
-        const { timeRange } = rawInput as Input
-        const raw = await platform.call({
-          tool: 'status',
-          method: 'overview',
-          params: { timeRange },
-        })
-        return { raw }
-      },
-      inputSchema: input,
-      outputSchema: statusData,
-      next: { type: StepType.LINEAR, target: 'compile-report' },
-    },
-    'compile-report': {
-      id: 'compile-report',
-      name: 'Compile Report',
-      description: 'Generates a natural language summary from raw status data',
-      handler: async (rawInput) => {
-        const { raw } = rawInput as z.infer<typeof statusData>
-        const result = await llm.generate({
-          provider: 'google',
-          model: 'gemini-3-flash-preview',
-          messages: [
-            {
-              role: 'user',
-              content: [
-                'Summarize this platform status overview in 3-5 concise bullet points.',
-                'Focus on: execution health, pending items needing attention, upcoming schedules, and credential coverage.',
-                'Be specific with numbers. Flag any issues.',
-                '',
-                JSON.stringify(raw, null, 2),
-              ].join('\\n'),
-            },
-          ],
-          responseSchema: {
-            type: 'object',
-            properties: {
-              summary: { type: 'string', description: 'Natural language status summary with bullet points' },
-            },
-            required: ['summary'],
-          },
-          temperature: 0,
-        })
-        const summary = (result as any)?.summary ?? String(result)
-        return { raw, summary }
-      },
-      inputSchema: statusData,
-      outputSchema: output,
-      next: null,
-    },
-  },
-  entryPoint: 'gather-status',
-}
-`;
-}
-function operationsBarrelTemplate() {
-  return `import { platformStatus } from './platform-status.js'
-
-export const workflows = [platformStatus]
-export const agents = []
-`;
-}
-function exampleBarrelTemplate() {
-  return `import { echo } from './echo.js'
-
-export const workflows = [echo]
-export const agents = []
-`;
-}
-
-// src/cli/commands/templates/core/index.ts
-function getManagedTemplates(ctx = {}) {
-  return {
-    "elevasis.config.ts": configTemplate,
-    ".gitignore": () => gitignoreTemplate(ctx),
-    "CLAUDE.md": () => claudeMdTemplate(ctx),
-    ".claude/settings.json": claudeSettingsTemplate,
-    ".claude/scripts/statusline-command.js": claudeStatuslineScriptTemplate,
-    ".claude/hooks/enforce-sdk-boundary.mjs": claudeSdkBoundaryHookTemplate,
-    ".claude/hooks/post-edit-validate.mjs": claudePostEditValidateHookTemplate,
-    ".claude/hooks/tool-failure-recovery.mjs": claudeToolFailureRecoveryHookTemplate,
-    ".claude/commands/tutorial.md": claudeTutorialCommandTemplate,
-    ".claude/commands/init.md": claudeInitCommandTemplate,
-    ".claude/commands/status.md": claudeStatusCommandTemplate,
-    ".claude/commands/fix.md": claudeFixCommandTemplate,
-    ".claude/commands/deploy.md": claudeDeployCommandTemplate,
-    ".claude/skills/diagnostics/SKILL.md": claudeDiagnosticsSkillTemplate,
-    ".claude/skills/work/SKILL.md": claudeWorkSkillTemplate,
-    ".claude/commands/docs.md": claudeDocsCommandTemplate,
-    ".claude/skills/creds/SKILL.md": claudeCredsSkillTemplate,
-    ".claude/rules/sdk-patterns.md": claudeSdkPatternsRuleTemplate,
-    ".claude/rules/docs-authoring.md": claudeDocsAuthoringRuleTemplate,
-    ".claude/rules/memory-conventions.md": claudeMemoryConventionsRuleTemplate,
-    ".claude/rules/project-map.md": claudeProjectMapRuleTemplate,
-    ".claude/rules/task-tracking.md": claudeTaskTrackingRuleTemplate,
-    ".claude/rules/logging.md": claudeLoggingRuleTemplate
-  };
-}
-
-export { claudeCredsSkillTemplate, claudeDeployCommandTemplate, claudeDiagnosticsSkillTemplate, claudeDocsAuthoringRuleTemplate, claudeFixCommandTemplate, claudeInitCommandTemplate, claudeMdTemplate, claudeMemoryConventionsRuleTemplate, claudeProjectMapRuleTemplate, claudeSdkBoundaryHookTemplate, claudeSdkPatternsRuleTemplate, claudeSettingsTemplate, claudeStatusCommandTemplate, claudeTaskTrackingRuleTemplate, claudeTutorialCommandTemplate, claudeWorkSkillTemplate, exampleBarrelTemplate, getManagedTemplates, gitignoreTemplate, operationsBarrelTemplate, platformStatusTemplate, starterWorkflowTemplate };