@elevasis/sdk 0.5.1 → 0.5.2

package/dist/templates.js

@@ -1,6 +1,17 @@
 // package.json
 
 // src/cli/commands/templates/core/workspace.ts
+var TEMPLATE_VERSION = 21;
+function configTemplate() {
+  return `import type { ElevasConfig } from '@elevasis/sdk'
+
+export default {
+  templateVersion: ${TEMPLATE_VERSION},
+  // defaultStatus: 'dev',     // Default status for new resources ('dev' | 'production')
+  // dev: { port: 5170 },      // Local API port (internal development only)
+} satisfies ElevasConfig
+`;
+}
 function gitignoreTemplate(ctx = {}) {
   let content = `node_modules/
 .env
@@ -19,7 +30,157 @@ ui/dist/
 
 // src/cli/commands/templates/core/claude.ts
 function claudeSettingsTemplate() {
-  return JSON.stringify({ autoCompact: false }, null, 2) + "\n";
+  return JSON.stringify({
+    autoCompact: false,
+    hooks: {
+      PreToolUse: [
+        {
+          matcher: "Write|Edit|MultiEdit|Bash",
+          hooks: [
+            {
+              type: "command",
+              command: "node .claude/hooks/enforce-sdk-boundary.mjs"
+            }
+          ]
+        }
+      ]
+    }
+  }, null, 2) + "\n";
+}
+function claudeSdkBoundaryHookTemplate() {
+  return String.raw`#!/usr/bin/env node
+// enforce-sdk-boundary.mjs
+// Blocks gh CLI, destructive git operations, and file writes outside the project root.
+// Allows git add, commit, push, pull, fetch -- used by /meta deploy.
+
+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 ?? "";
+
+    // GitHub CLI -- blocked (affects shared remote state, user-initiated only)
+    if (/\bgh\b/.test(cmd)) {
+      deny(
+        "BLOCKED: GitHub CLI (gh) command detected.\n" +
+        "WHY: GitHub CLI operations affect shared remote state (PRs, issues, releases). These must be user-initiated.\n" +
+        "INSTEAD: Ask the user to run this gh command manually."
+      );
+      process.exit(0);
+    }
+
+    // Destructive git -- blocked
+    if (/(?<!-)\bgit\s+reset\b/.test(cmd) && /--hard/.test(cmd)) {
+      deny(
+        "BLOCKED: git reset --hard detected.\n" +
+        "WHY: Hard resets destroy uncommitted work and cannot be undone. This must be user-initiated.\n" +
+        "INSTEAD: Ask the user to run this git command manually."
+      );
+      process.exit(0);
+    }
+
+    if (/(?<!-)\bgit\s+clean\b/.test(cmd) && /-[a-zA-Z]*f/.test(cmd)) {
+      deny(
+        "BLOCKED: git clean -f detected.\n" +
+        "WHY: Force-cleaning the working tree permanently removes untracked files. This must be user-initiated.\n" +
+        "INSTEAD: Ask the user to run this git command manually."
+      );
+      process.exit(0);
+    }
+
+    if (/(?<!-)\bgit\s+(rebase|merge)\b/.test(cmd)) {
+      deny(
+        "BLOCKED: git rebase/merge detected.\n" +
+        "WHY: Rebase and merge rewrite history or combine branches in ways that require user judgment.\n" +
+        "INSTEAD: Ask the user to run this git command manually."
+      );
+      process.exit(0);
+    }
+
+    // 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 -->
@@ -41,8 +202,10 @@ At the start of every session:
 3. Check installed \`@elevasis/sdk\` template version against \`templateVersion\`
    in \`elevasis.config.ts\`. If newer, notify and suggest \`/meta update\`.
 4. If \`.claude/memory/\` does not exist, suggest \`/meta init\`.
-5. If user TypeScript level is beginner (from skills.md) and
+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.
 
@@ -70,8 +233,10 @@ proactivity -- to their assessed levels.
 | Interaction guidance | \`reference/developer/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-view.mdx\` | Deploying or building resources that invoke other resources |
+| Command Center UI reference | \`reference/deployment/command-center-ui.mdx\` | User asks about post-deployment UI or Command Center navigation |
 | SDK error reference | \`reference/troubleshooting/common-errors.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 ? `
@@ -86,6 +251,7 @@ SDK patterns (imports, source structure, platform tools) are auto-loaded from
 \`.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
 
@@ -114,10 +280,10 @@ 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.
-- Show complete, working files for users below intermediate programming.
-  Never show code fragments they can't place.
+- 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 code, focus on SDK-specific patterns.
+- 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.
@@ -130,9 +296,8 @@ For detailed per-dimension adaptation rules, read
 | Command | Purpose |
 | --- | --- |
 | \`/meta\` | Project lifecycle: init, status, fix, deploy, health |
-| \`/docs\` | Documentation lifecycle: create, review, verify |
 | \`/work\` | Task tracking: create, save, resume, complete |
-| \`/tutorial\` | Progressive learning path |
+| \`/tutorial\` | Progressive learning path (7 core lessons + 9 modules) |
 
 ## Skills
 
@@ -178,122 +343,539 @@ Do not store in \`.claude/memory/\`:
 - If an error pattern recurs 3+ times, promote to Rules above
 `;
 }
-function claudeDocsCommandTemplate() {
-  return `# /docs command
+function claudeTutorialCommandTemplate() {
+  return `# /tutorial command
 
-You are a documentation assistant for this Elevasis workspace.
+You are a tutorial guide for this Elevasis workspace.
 
 ## Context
 
-Read the project's CLAUDE.md and all files in docs/ to understand the project.
-Read src/index.ts and the domain directories (src/operations/, src/example/, etc.) to understand the resource definitions.
+Read \`.claude/memory/profile/skills.md\` first. The \`automation\` skill level
+controls which docs you load and which lesson variant you deliver.
 
-## Operations
+**automation: none**
+- Load from \`reference/concepts/index.mdx\`: Glossary, What is a Workflow,
+  Platform Tools Overview only. Skip Zod, Execution Model, Design Decisions.
+- Load \`reference/deployment/command-center-ui.mdx\` for UI-first teaching.
+- Do NOT load \`reference/resources/patterns.mdx\` or
+  \`reference/platform-tools/adapters.mdx\` during core lessons.
 
-**No arguments (default):** Review existing docs/ files and suggest improvements.
-Identify undocumented resources, missing descriptions, and structural gaps.
+**automation: low-code**
+- Load all sections of \`reference/concepts/index.mdx\`.
+- Load \`reference/resources/patterns.mdx\` with Zapier/Make mapping in mind.
+- Load \`reference/platform-tools/adapters.mdx\` on-demand (when tools are used).
 
-**\`create <page-name>\`:** Create a new documentation page in docs/.
-Use the frontmatter schema (title, description, order).
-Populate with content based on the resource definitions in src/.
+**automation: custom**
+- Load all docs listed per-lesson and per-module as specified below.
 
-**\`review\`:** Review all docs/ files for accuracy against the actual resource
-definitions. Flag mismatches between documented schemas and code.
+Read \`.claude/memory/tutorial-progress.md\` to check current lesson progress.
 
-**\`verify [path]\`:** Cross-reference documentation with the codebase.
-Read the specified doc (or all docs if no path), compare claims against actual
-code (resource IDs, schema fields, platform tools used), and report
-discrepancies. Useful before \`/meta deploy\` to ensure docs are accurate.
-`;
-}
-function claudeTutorialCommandTemplate() {
-  return `# /tutorial command
+## Invocation
 
-You are a tutorial guide for this Elevasis workspace.
+\`/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.
 
-## Context
+## Menu
 
-Read \`.claude/memory/profile/skills.md\` to adapt lesson pacing and vocabulary.
-Read \`.claude/memory/tutorial-progress.md\` to check current lesson progress.
-Read \`reference/concepts/index.mdx\` for teaching vocabulary and concept definitions.
+When \`/tutorial\` is invoked:
 
-## Invocation
+1. Read \`.claude/memory/tutorial-progress.md\` (if it exists)
+2. Display the appropriate menu:
+
+**No progress (first time):**
+
+\`\`\`
+Welcome to the Elevasis Tutorial!
+==================================
+
+What would you like to learn?
+
+1. Orchestration Concepts (Core Path)
+   Build workflows step-by-step: data schemas, platform tools,
+   multi-step flows, decision points, and production deployment.
+   7 lessons -- estimated 2-3 hours total.
+
+2. Examples & Advanced Modules
+   Hands-on deep-dives: human-in-the-loop, scheduling,
+   notifications, integrations, LLM, agents, and more.
+   9 standalone modules -- pick any order.
+
+3. Meta-Framework
+   Learn the Claude Code context system: /meta, /work,
+   rules, memory, and how to customize your workspace.
+   5 lessons -- estimated 1-2 hours total.
+
+Pick a number to start, or say "status" to see your progress.
+\`\`\`
+
+**With existing progress:**
 
-- \`/tutorial\` -- Resume from current lesson. If no progress exists, start Lesson 1.
-- \`/tutorial start\` -- Reset progress and begin from Lesson 1.
-- \`/tutorial <number>\` -- Jump to a specific lesson (1-7).
+Show active tracks at the top, then offer resume options alongside new choices. Example:
+
+\`\`\`
+Progress: Core Path (Lesson 4/7) | Meta-Framework (MF2/5)
+
+1. Resume Orchestration Concepts (Lesson 4)
+2. Orchestration Concepts (Core Path -- start over)
+3. Examples & Advanced Modules
+4. Resume Meta-Framework (MF2)
+5. Meta-Framework (start over)
+6. Show full status
+
+Pick a number, or describe what you'd like to learn.
+\`\`\`
+
+After user picks:
+- Orchestration Concepts: Resume or start core lesson flow
+- Examples & Advanced Modules: Show module menu (see ## Module Menu)
+- Meta-Framework: Resume or start MF1 (see ## Meta-Framework Track)
+- "status": Display Phase, current position, completion counts
+
+## Progress Logic
+
+1. Read \`.claude/memory/tutorial-progress.md\`
+2. Show the menu (## Menu section) with progress summary if progress exists
+3. After user picks a track:
+   - **Orchestration Concepts**: If Completed Lessons < 7 -> start/resume at Current Lesson; if 7 complete -> note completion, offer module menu or repeat
+   - **Examples & Advanced Modules**: Show module menu (## Module Menu section)
+   - **Meta-Framework**: If Current MF Lesson is set -> resume at that lesson; otherwise start MF1
+4. Track completion: mark the track done in progress file when all lessons/modules complete
+5. If all three tracks complete -> set Phase to \`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 concepts page, adapt to skill level)
-3. Guide user to build or modify something (show complete code for beginners)
-4. Verify it works (run CLI command, check output)
+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 (Execution Runner is primary for none; CLI + UI are equal for others)
 5. Celebrate success, record observations in \`.claude/memory/tutorial-progress.md\`
 6. Ask: "Ready for the next lesson, or want to practice more?"
 
 ## Lessons
 
 **Lesson 1: Welcome & Orientation**
+
+When automation is none:
+Skip the file tour. Start with what Elevasis does for their business -- use analogies
+from \`reference/developer/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 check\` + \`elevasis deploy\`),
+THEN tour the Command Center so the user sees populated pages, not empty ones. Tour:
+Command View (echo node), Execution Runner (run echo from form), 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 resources\`. Observation focus: cloud deployment model.
+Verify: run \`elevasis resources\`. Then open the Command Center and tour the
+main pages: Command View (resource graph), Execution Runner, Execution Logs.
+Point out the echo workflow node in Command View.
+Observation focus: cloud deployment model, UI navigation comfort.
 
 **Lesson 2: 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. Execution Runner form is PRIMARY
+verification -- show user how to fill the form and run it. CLI is secondary:
+"here's the power user way." Observation focus: recipe-to-result connection, form comfort.
+
+When automation is low-code or custom:
 Modify the echo workflow. Walk through each part: config, contract, steps,
 entryPoint. Deploy: \`elevasis check\` then \`elevasis deploy\`. Test with
-\`elevasis exec echo --input '{"message":"hello"}'\`.
-Observation focus: TypeScript syntax comfort.
+\`elevasis 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.
 
 **Lesson 3: Understanding Data (Schemas)**
+
+When automation is none:
+Frame as "What information does your automation need?" Each piece becomes a form
+field. 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. User fills the form in Execution Runner to verify.
+Observation focus: data-to-form connection, required vs optional understanding.
+
+When automation is low-code:
+"Field mapping like Zapier, but with validation." Show Zod types briefly. Demonstrate
+how \`.describe()\` sets the form field label. Build schema based on identity.md goals.
+After deploy, open Execution Runner and point out each field.
+Observation focus: schema-to-form connection, 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).
-Observation focus: optional fields, types, suggesting own fields.
+on the user's goals (read .claude/memory/profile/identity.md). After deploy,
+open the Execution Runner and show how each Zod field becomes a form control.
+Point out how \`.describe()\` sets the field label.
+Observation focus: schema-to-form connection, optional fields, types.
 
 **Lesson 4: 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'\`.
-Explain credential setup. See reference/platform-tools/adapters.mdx for full API.
-Observation focus: credential model, async/await.
+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.
 
 **Lesson 5: 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. User verifies in Command View (see the two nodes + arrow) and
+Execution Runner (see output flow). 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.
-Observation focus: data flow reasoning.
+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.
 
 **Lesson 6: 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.
+User tests both paths via Execution Runner, then opens 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.
-Observation focus: branching logic reasoning.
+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.
 
 **Lesson 7: Going to Production**
-Change status from dev to production. Show monitoring: elevasis executions,
-elevasis execution. Cover error handling: try/catch, ExecutionError,
-PlatformToolError. Suggest next steps based on goals.
-Observation focus: readiness for independent development.
+
+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 executions, elevasis execution. Suggest next steps.
+Observation focus: readiness for independent operation (CLI + UI).
+
+## Module Menu
+
+Fixed module order: hitl, schedules, notifications, integrations, workflows,
+composition, llm, agents, error-handling.
+
+Show the next 2-3 uncompleted modules from the list. Format:
+
+"Core path complete! Here are your next modules:"
+1. <Title> -- <one-line description>
+2. <Title> -- <one-line description>
+3. <Title> -- <one-line description>
+"Pick a number to start, or say 'show more' to see additional modules."
+
+If all 9 modules are complete -> set Phase to \`complete\`, congratulate.
+
+## 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. Return to module menu (show next uncompleted modules)
+
+## Modules
+
+**Module: hitl -- Human-in-the-Loop**
+Read: \`reference/deployment/command-center-ui.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-ui.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/security/credentials.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: 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-view.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 exec\`, review tool call trace in Execution Logs.
+
+**Module: error-handling -- Error Handling Mastery**
+Read: \`reference/resources/patterns.mdx\` (error handling),
+\`reference/troubleshooting/common-errors.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.
+
+## Meta-Framework Track
+
+The Meta-Framework track teaches you how the Claude Code workspace works -- the commands,
+rules, memory system, and customization model. It is independent of the core path and
+can be taken in any order.
+
+**MF1: The Agent Framework -- 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 /meta, /tutorial, /work. Explain the creds skill as
+"the assistant automatically helps when you mention 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 four commands briefly. 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 /meta 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
+(4 commands + creds skill), Rules section (auto-loaded based on file paths), Skills
+section (auto-triggered by content patterns). Point out the initialized flag and
+explain how /meta init set it.
+Verify: Run /meta to see project status; observe which fields it reports.
+Observation focus: initialization model, command-vs-rule-vs-skill distinction.
+
+**MF2: The /meta Command -- Project Lifecycle**
+
+When automation is none:
+"Think of /meta as your project dashboard -- it shows what's healthy and what needs
+attention." Run /meta (no arguments) and narrate the output in plain language: what
+each field means. Explain /meta fix as "the agent tidies up and applies updates."
+Explain /meta deploy as "the agent publishes your changes in one step." Briefly note
+/meta health shows what happened when something goes wrong.
+Verify: Run /meta (no arguments). Narrate the output together.
+Observation focus: project lifecycle concept, dashboard reading.
+
+When automation is low-code:
+Show all /meta operations with their purpose. Map to familiar concepts: /meta fix is
+like "repair this Zap" in Zapier; /meta deploy is a one-command publish pipeline.
+Walk through the /meta (no-args) output: template version (SDK template your workspace
+uses), SDK version (installed package), profile summary, drift check.
+Verify: Run /meta and interpret each field together.
+Observation focus: deploy pipeline understanding, version tracking.
+
+When automation is custom:
+Read \`.claude/commands/meta.md\`. Walk through each operation: init (first-run setup
+with assessment), (no-args) (status dashboard), fix (drift repair + SDK upgrade +
+rules health), deploy (7-step pipeline: check, typecheck, docs, git, deploy,
+project-map, verify), health (runtime diagnostics). Explain the merge strategy for
+CLAUDE.md and commands. Note the template access model: templates read from
+@elevasis/sdk/templates subpath.
+Verify: Run /meta to see project status. Identify what a version mismatch looks like.
+Observation focus: full lifecycle coverage, pipeline internals.
+
+**MF3: /work -- Task Lifecycle**
+
+When automation is none:
+"You can ask the assistant to track work across conversations. When you start something
+complex, use /work create to save your place. Next session, /work resume picks up where
+you left off." Walk through the concept without deep command details. Show docs/ -- explain
+it's where project notes live.
+Verify: Create a task with \`/work create "practice task"\`, then run /work to see it listed.
+Observation focus: persistence concept, cross-session continuity.
+
+When automation is low-code:
+Show /work operations: create (task doc with frontmatter + sections), save (updates
+Progress + Resume Context), resume (loads context for next session).
+Explain how task docs persist: they're workspace files, not memory -- they survive
+session compaction.
+Verify: Create a task with \`/work create "practice task"\`, run /work save, inspect the file.
+Observation focus: task tracking workflow, doc creation pattern.
+
+When automation is custom:
+Read \`.claude/commands/work.md\`. Full coverage:
+/work create (kebab-case filename, frontmatter with status, Objective/Plan/Progress/
+Resume Context sections), /work save (Progress + Resume Context update), /work resume
+(multiple-task disambiguation), /work complete (moves to final location).
+Explain how Resume Context serves as the session handoff artifact.
+Verify: Create a task doc, save progress, inspect the generated file structure.
+Observation focus: task doc anatomy, resume context as handoff pattern.
+
+**MF4: 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 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.
+
+**MF5: Advanced -- Template Lifecycle and Extending**
+
+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 /meta 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 /meta 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 update) vs INIT_ONLY (set once, yours).
+Show how /meta 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 /meta.
+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 /meta. Identify any drift.
+Observation focus: full template lifecycle, conflict resolution pattern.
 
 ## Adaptation Rules
 
-- If user is intermediate/advanced (from skills.md), condense explanations
-- If user struggles, slow down with more plain-English explanation
-- If user is fast, acknowledge and offer to skip ahead
+**automation: none**
+Use the non-technical variant for each lesson. Agent writes all code -- user
+never types code. User verifies visually (Execution Runner, Command View, Logs).
+Avoid all jargon; use analogies. Execution Runner 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.
+Execution Runner and CLI are equal verification tools. 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 each lesson, update \`.claude/memory/tutorial-progress.md\`
 - If user demonstrates a level change, promote to skills.md Growth Log
+- After completing a module, return to the module menu
+- Adapt module depth to skill level as with lessons
 
 ## Progress Format
 
 Store in \`.claude/memory/tutorial-progress.md\`:
-- Current Lesson number
+- Phase (core | modules | meta-framework | complete)
+- Current Lesson number (during core phase)
+- Current Module (module id during modules phase)
+- Current MF Lesson (MF1-MF5, during meta-framework phase)
 - Started and Last Session dates
 - Completed Lessons table (lesson, title, completed, duration)
-- Capability Observations table (lesson, observation)
+- Completed Modules table (module, title, completed, duration)
+- Completed MF Lessons table (lesson, title, completed, notes)
+- Capability Observations table (lesson/module, observation) -- prefix L# for lessons, M:<id> for modules, MF# for meta-framework lessons
 - Assessment Notes (bullet points)
+
+Backward-compatible: missing Phase is inferred from lesson count;
+missing Completed Modules is treated as empty;
+missing Completed MF Lessons is treated as empty.
 `;
 }
 function claudeMetaCommandTemplate() {
@@ -318,10 +900,17 @@ by the \`<!-- initialized: false -->\` flag in CLAUDE.md, or run manually.
    Run \`pnpm install\`. Wait for completion. Report any errors.
 
 2. **Setup environment**
-   Check if \`.env\` has \`ELEVASIS_API_KEY\` set.
-   If not, ask the user for their API key and write it to \`.env\`.
-   Validate the key works: run \`elevasis resources\` (should return empty list,
-   not an auth error).
+   Read \`.env\`. It should contain only a single line: \`ELEVASIS_API_KEY=\`.
+   If \`ELEVASIS_API_KEY\` is empty or missing, ask the user: "What is your
+   Elevasis API key?" When the user provides it, write \`.env\` with exactly:
+   \`\`\`
+   ELEVASIS_API_KEY=<value they provided>
+   \`\`\`
+   No other keys (no \`NODE_ENV\`, no extras). The \`.env\` file must contain
+   only \`ELEVASIS_API_KEY\`.
+   Validate the key works: run \`elevasis 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:
@@ -331,16 +920,11 @@ by the \`<!-- initialized: false -->\` flag in CLAUDE.md, or run manually.
    - "What do you want to automate with Elevasis?"
    - "Which tools does your team already use?" (email, CRM, spreadsheets, etc.)
 
-   Competency (2-3 questions with conditional skipping):
-   - "Have you written code before? If so, what kind?"
-     No code -> programming: none, skip next question
-     HTML/CSS/Excel -> programming: minimal, skip next question
-     Scripts/websites -> programming: intermediate, ask next question
-     Production apps -> programming: advanced, ask next question
-   - (Only if scripts+) "Have you used TypeScript or a typed language?"
-     No -> typescript: none
-     Read it / used typed language -> typescript: exposure
-     Written TypeScript projects -> typescript: proficient
+   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
@@ -368,8 +952,8 @@ by the \`<!-- initialized: false -->\` flag in CLAUDE.md, or run manually.
 6. **Report**
    Summary of what was set up. Suggest next steps based on goals.
 
-   If the user's TypeScript level is beginner or automation level is new,
-   suggest /tutorial start: "I recommend starting with /tutorial -- it walks
+   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**
@@ -399,8 +983,19 @@ Detect and repair all drift. Optionally upgrades the SDK first.
 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:** Verify index consistency
-5. **Doc cross-references:** Scan for broken links
+4. **Memory structure:** Create base structure if missing, then verify index consistency.
+   If \`.claude/memory/\` does not exist or is empty:
+   - Create \`memory/index.md\` (root index with placeholder entries)
+   - Create \`memory/errors/index.md\` (error category summary, empty tables)
+   - Create \`memory/errors/deploy.md\`, \`memory/errors/runtime.md\`, \`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
 6. **Settings consistency:** Verify expected fields
 7. **Rules health:** Scan \`memory/errors/\` -- flag any entry that has recurred
    3+ times and is not yet in \`.claude/rules/workspace-patterns.md\`.
@@ -452,6 +1047,421 @@ The agent reads current templates from the installed SDK:
 \`@elevasis/sdk/templates\` subpath exports all template functions.
 `;
 }
+function claudeWorkCommandTemplate() {
+  return `# /work command
+
+You are a task tracking assistant for this Elevasis workspace. \`/work\` is the primary command for managing all work and projects.
+
+## 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\`.
+
+## Operations
+
+### No arguments (default) -- List and Pick
+
+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 to resume, or say:
+- "create" to start new work
+- "complete <name>" to finish a task
+\`\`\`
+
+4. Cross-reference with \`docs/priorities.mdx\` if it exists
+5. When the user picks a number or describes a task in natural language, auto-invoke the **resume** flow on that task
+6. If no tasks found, suggest \`/work create\`
+
+### \`create [description]\`
+
+Guided task creation with interview:
+
+1. If no description given, ask: "What are you trying to accomplish?"
+2. Ask 2-3 focused questions:
+   - "What does success look like?" (acceptance criteria)
+   - "Is this related to any existing work?" (scan \`docs/in-progress/\` and \`docs/\` for related topics)
+   - "Do we need to investigate anything first, or is the path clear?" (suggest investigation if needed)
+3. Determine directory placement:
+   - Scan \`docs/in-progress/\` for existing directories related to the topic
+   - 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\`
+4. 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).
+
+5. Update \`docs/priorities.mdx\` if it exists
+6. Report what was created with location and step count
+
+### \`save\`
+
+Update the current task doc's Progress and Resume Context:
+
+1. Identify the current task from conversation context (which in-progress doc was loaded/discussed)
+2. If not working on a tracked task, list available docs and ask which to save to, or 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, \`complete\` if all steps done)
+6. Report: task title, status, completed steps count, last step, and the resume command
+
+### \`resume [name-or-number]\`
+
+Resume in-progress work. Designed for non-technical users who may not know file paths.
+
+**Resolution order:**
+1. If a number is given (e.g., \`/work resume 2\`), map to the numbered list from the default list operation
+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 [name]\`
+
+Mark task complete, clean up, and move to permanent docs:
+
+1. Resolve target (same as resume: number, name, or scan for \`status: complete\`)
+2. **Validate readiness:** Check that all plan steps are marked COMPLETE. If not, warn and ask for confirmation.
+3. **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
+4. **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
+5. **Move the doc(s):**
+   - Single file: move from \`docs/in-progress/\` to destination
+   - Directory: move entire directory
+6. **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
+
+## Completion Suggestions
+
+When the agent observes that all plan steps for a task are marked COMPLETE and the user seems to be moving on, proactively suggest: "All steps for '{task}' are complete. Run \`/work complete\` to finalize it."
+`;
+}
+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_API_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 |
+| \`trello\` | \`{"apiKey": "...", "token": "..."}\` | Trello |
+| \`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\`, \`webhook-secret\`, or \`trello\`). 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": "..."}\`
+   - For \`trello\`: ask for API key AND user token, construct \`{"apiKey": "...", "token": "..."}\`
+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
+---
+
+# 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 an \`OrganizationResources\` object
+- \`resourceId\` must be lowercase with hyphens, unique per organization
+- \`dist/\` is generated by deploy -- never commit it
+
+## Runtime
+
+- \`.env\` contains only \`ELEVASIS_API_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, lead, 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
+---
+
+# 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
+---
+
+# 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 /meta fix
+---
+
+# Project Map
+
+- \`docs/project-map.mdx\` and \`docs/resource-map.mdx\` are fully auto-generated by \`elevasis deploy\`
+- Do not edit either file manually -- changes are overwritten on next deploy
+- \`/meta fix\` step 8 checks for drift and patches the map
+- If a new command, rule, skill, or memory file is added, run \`/meta fix\` or \`elevasis deploy\` to update
+`;
+}
+function claudeTaskTrackingRuleTemplate() {
+  return `---
+description: In-progress task conventions -- /work command, doc format, status values, auto-save behavior
+---
+
+# Task Tracking
+
+## Status Values
+
+Exactly three values for frontmatter \`status\`: \`planned\`, \`in-progress\`, \`complete\`.
+
+## Doc Format
+
+- Frontmatter: \`title\`, \`description\`, \`status\`
+- 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
+
+## Save Suggestions
+
+Proactively suggest \`/work save\` 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 \`/clear\` or context reset
+
+## Completion Suggestions
+
+When all plan steps are marked COMPLETE, suggest \`/work complete\` to finalize the task.
+
+## 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>/\`
+`;
+}
 
 // src/cli/commands/templates/core/resources.ts
 function starterWorkflowTemplate() {
@@ -600,4 +1610,24 @@ export const agents = []
 `;
 }
 
-export { claudeDocsCommandTemplate, claudeMdTemplate, claudeMetaCommandTemplate, claudeSettingsTemplate, claudeTutorialCommandTemplate, exampleBarrelTemplate, gitignoreTemplate, operationsBarrelTemplate, platformStatusTemplate, starterWorkflowTemplate };
+// 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/hooks/enforce-sdk-boundary.mjs": claudeSdkBoundaryHookTemplate,
+    ".claude/commands/tutorial.md": claudeTutorialCommandTemplate,
+    ".claude/commands/meta.md": claudeMetaCommandTemplate,
+    ".claude/commands/work.md": claudeWorkCommandTemplate,
+    ".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
+  };
+}
+
+export { claudeCredsSkillTemplate, claudeDocsAuthoringRuleTemplate, claudeMdTemplate, claudeMemoryConventionsRuleTemplate, claudeMetaCommandTemplate, claudeProjectMapRuleTemplate, claudeSdkBoundaryHookTemplate, claudeSdkPatternsRuleTemplate, claudeSettingsTemplate, claudeTaskTrackingRuleTemplate, claudeTutorialCommandTemplate, claudeWorkCommandTemplate, exampleBarrelTemplate, getManagedTemplates, gitignoreTemplate, operationsBarrelTemplate, platformStatusTemplate, starterWorkflowTemplate };