@elevasis/sdk 0.5.10 → 0.5.12

package/dist/templates.js

@@ -1,13 +1,13 @@
 // package.json
 
 // src/cli/commands/templates/core/workspace.ts
-var TEMPLATE_VERSION = 23;
+var TEMPLATE_VERSION = 27;
 function configTemplate() {
   return `import type { ElevasConfig } from '@elevasis/sdk'
 
 export default {
   templateVersion: ${TEMPLATE_VERSION},
-  // defaultStatus: 'dev',     // Default status for new resources ('dev' | 'production')
+  // defaultStatus: 'dev',     // Default status for new resources ('dev' | 'prod')
   // dev: { port: 5170 },      // Local API port (internal development only)
 } satisfies ElevasConfig
 `;
@@ -19,6 +19,7 @@ dist/
 __elevasis_worker.ts
 .claude/settings.local.json
 .claude/memory/
+package-lock.json
 `;
   if (ctx.hasUI) {
     content += `ui/node_modules/
@@ -273,13 +274,18 @@ All \`reference/\` paths resolve to \`node_modules/@elevasis/sdk/reference/\`.
 
 ## Elevasis CLI
 
-**MANDATORY:** Use the \`elevasis\` CLI for all execution/platform operations -- never \`npx\`, \`curl\`, or any other tool.
+**MANDATORY:** Use the \`elevasis-sdk\` CLI for all execution/platform operations -- never \`curl\` or any other tool.
 
-- \`elevasis exec <resource-id> --input '{...}'\` -- run a resource synchronously
-- \`elevasis exec <resource-id> --input '{...}' --async\` -- run async, returns execution ID
-- \`elevasis execution <resource-id> <execution-id>\` -- inspect execution detail
-- \`elevasis check\` -- validate resource definitions without deploying
-- \`elevasis deploy\` -- deploy to the platform
+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
 
 Organization is derived from your API key -- no org prefix needed in the resource ID.
 For full CLI reference: \`reference/cli/index.mdx\`
@@ -431,32 +437,34 @@ Example (first time, no progress):
 Elevasis Tutorial
 ==================
 
-ORCHESTRATION CONCEPTS                              0/7
-  1  Welcome & Orientation                          [ ]
-  2  Your First Custom Workflow                     [ ]
-  3  Understanding Data (Schemas)                   [ ]
-  4  Using Platform Tools                           [ ]
-  5  Multi-Step Workflows                           [ ]
-  6  Decision Points                                [ ]
-  7  Going to Production                            [ ]
-
-EXAMPLES & ADVANCED MODULES                        0/9
-  8  Human-in-the-Loop                              [ ]
-  9  Task Scheduling                                [ ]
- 10  Notification System                            [ ]
- 11  Real-World Integrations                        [ ]
- 12  Error Handling Mastery                         [ ]
- 13  Advanced Workflows                             [ ]
- 14  Resource Composition                           [ ]
- 15  LLM Integration                               [ ]
- 16  AI Agents                                     [ ]
-
-META-FRAMEWORK                                     0/5
- 17  The Agent Framework                            [ ]
- 18  The /meta Command                              [ ]
- 19  /work and /docs                                [ ]
- 20  Rules, Memory, and Customization               [ ]
- 21  Template Lifecycle                             [ ]
+INTRODUCTION                                       0/4
+  1  Welcome & Orientation                         [ ]
+  2  How This Workspace Works                      [ ]
+  3  The /meta Command                             [ ]
+  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.
 \`\`\`
@@ -469,7 +477,7 @@ indicators from completed/current state. \`"status"\` -> show the same table.
 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 completion: mark done in progress file, show updated menu table
+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
@@ -479,18 +487,18 @@ Each lesson follows this flow:
 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, record observations in \`.claude/memory/tutorial-progress.md\`
-6. Ask: "Ready for the next lesson, or want to practice more?"
+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
 
-**Lesson 1: Welcome & Orientation**
+**Item 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\`),
+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.
@@ -499,52 +507,153 @@ 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\`. Then open the Command Center and tour the
+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.
 
-**Lesson 2: Your First Custom Workflow**
+**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 /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.
+
+**Item 3: The /meta Command**
+
+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.
+
+**Item 4: /work and /docs**
+
+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. Then introduce /docs:
+"When a task is finished, /work complete moves it to docs/ permanently. After that, /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: Create a task with \`/work create "practice task"\`, then run /work to see it listed.
+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 operations: create (task doc with frontmatter + sections), save (updates
+Progress + Resume Context), resume (loads context for next session), complete (moves
+to permanent docs/).
+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: Create a task with \`/work create "practice task"\`, run /work save, inspect the
+file. Then run /docs to browse docs/.
+Observation focus: task tracking workflow, /work vs /docs separation.
+
+When automation is custom:
+Read \`.claude/commands/work.md\`. Full /work 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).
+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 /meta fix step 5.
+Explain the relationship: /work owns docs/in-progress/ (task lifecycle), /work complete
+moves docs to permanent location, /docs browses and verifies what's there.
+Verify: Create a task doc, save progress, run /work complete to move it. Then run /docs
+to see it in the permanent docs/ listing.
+Observation focus: task doc anatomy, /work-to-/docs handoff, docs verification as standalone tool.
+
+**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 exec\` to verify
+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 check\` then \`elevasis deploy\`. Test with
-\`elevasis exec echo --input '{"message":"hello"}'\`. Then open the Execution
+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.
 
-**Lesson 3: Understanding Data (Schemas)**
+**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 exec\` with sample input and narrates the result.
+\`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 exec --input '{...}'\` to verify each field.
+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 exec --input '{...}'\` to verify the schema and inspect
+run with \`elevasis-sdk exec --input '{...}'\` to verify the schema and inspect
 the execution output.
 Observation focus: schema-to-input mapping, optional fields, types.
 
-**Lesson 4: Using Platform Tools**
+**Item 7: Using Platform Tools**
 
 When automation is none:
 Frame as "Connecting your automation to a service you already use." Pick ONE
@@ -566,12 +675,12 @@ 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**
+**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 exec\` to verify and shows output flow.
+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.
 
@@ -582,12 +691,12 @@ relationship edges between resources. Explain how declared relationships map
 to the visual graph.
 Observation focus: data flow reasoning, relationship visualization.
 
-**Lesson 6: Decision Points**
+**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 exec\` for both paths. Open Execution Logs to see which
+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.
 
@@ -598,7 +707,7 @@ 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**
+**Item 10: Going to Production**
 
 When automation is none:
 Frame as "draft vs live" not "dev vs production." Error handling: "when something
@@ -612,12 +721,12 @@ 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.
+monitoring: elevasis-sdk executions, elevasis-sdk execution. Suggest next steps.
 Observation focus: readiness for independent operation (CLI + UI).
 
 ## Module Menu
 
-Module order (items 8-16 in the main menu): hitl, schedules, notifications,
+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).
@@ -700,116 +809,16 @@ 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.
+Verify: Run agent with \`elevasis-sdk exec\`, review tool call trace in Execution Logs.
 
-## Meta-Framework Track
+## Advanced Workspace 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.
+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.
 
-**MF1: The Agent Framework -- How This Workspace Works**
+Each item follows the same flow as core lessons: announce, explain per skill level, verify, record observations.
 
-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 and /docs -- Task and Documentation 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. Then introduce /docs:
-"When a task is finished, /work complete moves it to docs/ permanently. After that, /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: Create a task with \`/work create "practice task"\`, then run /work to see it listed.
-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 operations: create (task doc with frontmatter + sections), save (updates
-Progress + Resume Context), resume (loads context for next session), complete (moves
-to permanent docs/).
-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: Create a task with \`/work create "practice task"\`, run /work save, inspect the
-file. Then run /docs to browse docs/.
-Observation focus: task tracking workflow, /work vs /docs separation.
-
-When automation is custom:
-Read \`.claude/commands/work.md\`. Full /work 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).
-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 /meta fix step 5.
-Explain the relationship: /work owns docs/in-progress/ (task lifecycle), /work complete
-moves docs to permanent location, /docs browses and verifies what's there.
-Verify: Create a task doc, save progress, run /work complete to move it. Then run /docs
-to see it in the permanent docs/ listing.
-Observation focus: task doc anatomy, /work-to-/docs handoff, docs verification as standalone tool.
-
-**MF4: Rules, Memory, and Customization**
+**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
@@ -823,7 +832,7 @@ 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).
+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.
@@ -840,7 +849,7 @@ 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**
+**Item 21: Template Lifecycle**
 
 When automation is none:
 "When Elevasis SDK releases updates, the assistant can apply them to your workspace
@@ -853,7 +862,7 @@ Next steps: point to reference docs in docs/, encourage using /work for new task
 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).
+Explain MANAGED (auto-updated by elevasis-sdk 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,
@@ -877,7 +886,7 @@ Observation focus: full template lifecycle, conflict resolution pattern.
 
 **automation: none**
 Use the non-technical variant for each lesson. Agent writes all code -- user
-never types code. Agent runs \`elevasis exec\` for verification and narrates results.
+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.
 
@@ -891,7 +900,7 @@ 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\`
+- 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
@@ -910,7 +919,7 @@ Last Session: {today's date}
 
 ## Completed Lessons
 
-| Lesson | Title | Completed | Duration |
+| Item | Title | Completed | Duration |
 | --- | --- | --- | --- |
 
 ## Completed Modules
@@ -918,11 +927,6 @@ Last Session: {today's date}
 | Module | Title | Completed | Duration |
 | --- | --- | --- | --- |
 
-## Completed MF Lessons
-
-| Lesson | Title | Completed | Notes |
-| --- | --- | --- | --- |
-
 ## Capability Observations
 
 | Source | Observation |
@@ -934,13 +938,14 @@ Last Session: {today's date}
 \`\`\`
 
 Update rules:
-- \`Current\`: free-form, e.g. "L4: Using Platform Tools" or "M:integrations" or "MF2"
+- \`Current\`: free-form, e.g. "4: Using Platform Tools" or "M:integrations" or "20: Rules, Memory, and Customization"
 - \`Last Session\`: update to today's date on each \`/tutorial\` invocation
-- Completed tables: add a row when a lesson/module/MF lesson finishes
-- Capability Observations: prefix source with L# for lessons, M:<id> for modules, MF# for MF lessons
+- 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 or Completed MF Lessons sections treated as empty.
+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 claudeMetaCommandTemplate() {
@@ -973,7 +978,7 @@ by the \`<!-- initialized: false -->\` flag in CLAUDE.md, or run manually.
    \`\`\`
    No other keys (no \`NODE_ENV\`, no extras). The \`.env\` file must contain
    only \`ELEVASIS_PLATFORM_KEY\`.
-   Validate the key works: run \`elevasis resources\` (should return an empty
+   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.
 
@@ -1034,7 +1039,7 @@ by the \`<!-- initialized: false -->\` flag in CLAUDE.md, or run manually.
    - If git remote exists: note remote URL in memory/profile/preferences.md
 
 5. **Verify project**
-   Run \`elevasis check\` to confirm the starter resource is valid.
+   Run \`elevasis-sdk check\` to confirm the starter resource is valid.
    Optionally deploy the echo workflow.
 
 6. **Report**
@@ -1051,8 +1056,7 @@ by the \`<!-- initialized: false -->\` flag in CLAUDE.md, or run manually.
 ### \`/meta\` (no arguments) -- Project Status
 
 Display a project health summary:
-1. Current template version vs latest available
-2. SDK package version from package.json
+1. Template version (from elevasis.config.ts) and installed SDK version (from package.json). Suggest \`elevasis-sdk update\` to check for updates
 3. Profile summary (from memory/profile/skills.md)
 4. Quick drift check: count of missing managed files, missing gitignore entries
 5. Last deployment status (from memory/deployment-state.md if it exists)
@@ -1063,7 +1067,7 @@ 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 update\` to add
+   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
@@ -1092,7 +1096,7 @@ Detect and repair all drift. Optionally upgrades the SDK first.
    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 deploy\`
+   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.
@@ -1102,11 +1106,11 @@ Each step reports its result. Steps 1-8 run even if step 0 is skipped.
 0. Read \`reference/deployment/command-view.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 check\` (validation)
+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 deploy\`
+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 \`memory/deployment-state.md\` with count, timestamp, inventory
@@ -1668,10 +1672,10 @@ description: Project map conventions -- auto-generated, do not edit, maintained
 
 # Project Map
 
-- \`docs/project-map.mdx\` and \`docs/resource-map.mdx\` are fully auto-generated by \`elevasis deploy\`
+- \`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
 - \`/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
+- If a new command, rule, skill, or memory file is added, run \`/meta fix\` or \`elevasis-sdk deploy\` to update
 `;
 }
 function claudeTaskTrackingRuleTemplate() {