@elevasis/sdk 0.5.1 → 0.5.2

package/dist/types/templates.d.ts

@@ -1 +1,2 @@
-export { claudeMdTemplate, claudeMetaCommandTemplate, claudeDocsCommandTemplate, claudeTutorialCommandTemplate, gitignoreTemplate, claudeSettingsTemplate, starterWorkflowTemplate, platformStatusTemplate, operationsBarrelTemplate, exampleBarrelTemplate, } from './cli/commands/init.js';
+export { claudeMdTemplate, claudeMetaCommandTemplate, claudeWorkCommandTemplate, claudeTutorialCommandTemplate, claudeSettingsTemplate, claudeSdkBoundaryHookTemplate, claudeCredsSkillTemplate, claudeSdkPatternsRuleTemplate, claudeDocsAuthoringRuleTemplate, claudeMemoryConventionsRuleTemplate, claudeProjectMapRuleTemplate, claudeTaskTrackingRuleTemplate, gitignoreTemplate, starterWorkflowTemplate, platformStatusTemplate, operationsBarrelTemplate, exampleBarrelTemplate, } from './cli/commands/init.js';
+export { getManagedTemplates } from './cli/commands/templates/core/index.js';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elevasis/sdk",
-  "version": "0.5.1",
+  "version": "0.5.2",
   "description": "SDK for building Elevasis organization resources",
   "comment:bin": "IMPORTANT: This package shares the 'elevasis' binary name with @repo/cli. They never conflict because @elevasis/sdk must NEVER be added as a dependency of any workspace package (apps/*, packages/*, organizations/*). Workspace projects use @repo/cli for the 'elevasis' binary. External developers (outside the workspace) get this SDK's binary via npm install.",
   "type": "module",
@@ -34,6 +34,11 @@
     "dist/types/templates.d.ts",
     "reference/"
   ],
+  "scripts": {
+    "build": "node -e \"require('fs').rmSync('dist',{recursive:true,force:true})\" && tsc -p tsconfig.core-dts.json && tsc -p tsconfig.build.json && tsup && rollup -c rollup.dts.config.mjs && esbuild src/cli/index.ts --bundle --platform=node --outfile=dist/cli.cjs --format=cjs --external:esbuild --external:jiti --banner:js=\"#!/usr/bin/env node\" && node scripts/copy-reference-docs.mjs && node scripts/generate-navigation.mjs",
+    "check-types": "tsc --noEmit",
+    "test:bundle": "pnpm build && vitest run --config vitest.bundle.config.ts"
+  },
   "dependencies": {
     "esbuild": "^0.25.0",
     "jiti": "^2.0.0"
@@ -42,6 +47,8 @@
     "zod": "^4.1.0"
   },
   "devDependencies": {
+    "@repo/core": "workspace:*",
+    "@repo/typescript-config": "workspace:*",
     "@types/node": "^22.0.0",
     "chalk": "^5.3.0",
     "commander": "^11.0.0",
@@ -52,13 +59,6 @@
     "rollup-plugin-dts": "^6.3.0",
     "tsup": "^8.0.0",
     "typescript": "5.9.2",
-    "zod": "^4.1.0",
-    "@repo/core": "0.0.0",
-    "@repo/typescript-config": "0.0.0"
-  },
-  "scripts": {
-    "build": "node -e \"require('fs').rmSync('dist',{recursive:true,force:true})\" && tsc -p tsconfig.core-dts.json && tsc -p tsconfig.build.json && tsup && rollup -c rollup.dts.config.mjs && esbuild src/cli/index.ts --bundle --platform=node --outfile=dist/cli.cjs --format=cjs --external:esbuild --external:jiti --banner:js=\"#!/usr/bin/env node\" && node scripts/copy-reference-docs.mjs && node scripts/generate-navigation.mjs",
-    "check-types": "tsc --noEmit",
-    "test:bundle": "pnpm build && vitest run --config vitest.bundle.config.ts"
+    "zod": "^4.1.0"
   }
-}
+}

package/reference/_navigation.md

@@ -1,6 +1,6 @@
 # SDK Reference Navigation
 
-Auto-generated from reference file frontmatter. 31 files indexed.
+Auto-generated from reference file frontmatter. 32 files indexed.
 
 All paths are relative to `node_modules/@elevasis/sdk/reference/`.
 
@@ -27,6 +27,7 @@ All paths are relative to `node_modules/@elevasis/sdk/reference/`.
 | Resource | Location | Description | When to Load |
 | --- | --- | --- | --- |
 | Execution API | `deployment/api.mdx` | REST endpoints for executing resources, querying execution history, and managing deployments via the Elevasis external API | Calling the API directly or debugging API responses |
+| Command Center UI | `deployment/command-center-ui.mdx` | Reference for the Elevasis Command Center -- what each page does, when to use it post-deployment, and how SDK concepts map to UI actions | User asks about the Command Center UI, post-deployment workflow, or monitoring deployed resources |
 | Command View | `deployment/command-view.mdx` | How the Command View graph works -- node types, relationships, what is enforced vs decorative, and what the platform needs to render your resource graph | Deploying resources or building resources that invoke other resources |
 | Deploying Resources | `deployment/index.mdx` | How to deploy your Elevasis SDK resources to the platform using elevasis deploy, including configuration, validation, and environment setup | Preparing to deploy or debugging deploy failures |
 
@@ -34,7 +35,7 @@ All paths are relative to `node_modules/@elevasis/sdk/reference/`.
 
 | Resource | Location | Description | When to Load |
 | --- | --- | --- | --- |
-| Interaction Guidance | `developer/interaction-guidance.mdx` | Full dimensional adaptation rules per skill axis -- programming, TypeScript, API integration, automation concepts, domain expertise -- with growth tracking protocol | Unsure how to adapt for a skill combination |
+| Interaction Guidance | `developer/interaction-guidance.mdx` | Full dimensional adaptation rules per skill axis -- platform navigation, API integration, automation concepts, domain expertise -- with growth tracking protocol | Unsure how to adapt for a skill combination |
 
 ## Framework
 

package/reference/deployment/command-center-ui.mdx

@@ -0,0 +1,151 @@
+---
+title: Command Center UI
+description: Reference for the Elevasis Command Center -- what each page does, when to use it post-deployment, and how SDK concepts map to UI actions
+loadWhen: "User asks about the Command Center UI, post-deployment workflow, or monitoring deployed resources"
+---
+
+The Command Center is the browser UI for interacting with deployed resources. After you run `elevasis deploy`, this is where you run workflows, monitor executions, manage approvals, schedule tasks, and review logs. This reference covers each page and how it connects to your SDK code.
+
+---
+
+## Quick Reference
+
+| Task                                               | Page           | Path                    |
+| -------------------------------------------------- | -------------- | ----------------------- |
+| Browse deployed resources, view the resource graph | Command View   | `/command-view`         |
+| Approve or reject pending HITL requests            | Command Queue  | `/queue`                |
+| Browse deployed documentation                      | Knowledge Base | `/knowledge-base`       |
+| Search execution history across all resources      | Execution Logs | `/logs`                 |
+| Create API key and OAuth credentials               | Credentials    | `/settings/credentials` |
+| View deployment history and active version         | Deployments    | `/settings/deployments` |
+
+---
+
+## Command View
+
+The Command View is a visual graph of your deployed resources. Each node is a resource (workflow, agent, trigger, integration). Edges are the relationships you declared in `OrganizationResources`.
+
+**What you can do here:**
+
+- See all deployed resources at a glance
+- Trace data flow between resources via declared relationships
+- Identify which resources depend on which integrations
+- Click a node to view resource details (ID, status, type)
+
+**Graph accuracy:** The graph reflects your `relationships` declarations, not runtime behavior. If your handler calls another resource without a declared relationship, the edge is missing from the graph. Keep declarations in sync with your code.
+
+For the full relationship model and what is enforced vs. decorative, see `reference/deployment/command-view.mdx`.
+
+> **SDK takeaway:** Declare relationships in `OrganizationResources` to keep the Command View accurate as your system grows.
+
+---
+
+## Command Queue
+
+The Command Queue surfaces all pending Human-in-the-Loop (HITL) approval requests from running workflows.
+
+**What you can do here:**
+
+- View pending approval requests with context provided by the workflow
+- Filter by resource, status, or date
+- Approve or reject with an optional comment
+- See the history of past decisions
+
+**How it connects to your code:** Approval requests appear here when a workflow step calls `approval.requestApproval()`. The workflow pauses at that step and waits for a decision before continuing.
+
+```typescript
+import { approval } from '@elevasis/sdk/worker'
+
+const result = await approval.requestApproval({
+  title: 'Approve proposal before sending',
+  context: { dealId, proposalUrl },
+})
+
+if (result.approved) {
+  // continue
+}
+```
+
+> **SDK takeaway:** Use `approval.requestApproval()` to create approval gates that surface here. Provide rich `context` so reviewers have what they need to decide.
+
+---
+
+## Knowledge Base
+
+The Knowledge Base renders the `docs/` directory of your deployed workspace as browsable documentation.
+
+**What you can do here:**
+
+- Browse pages you created in `docs/*.mdx`
+- Search across all documentation
+- Share links to specific pages with team members
+
+**How it connects to your code:** Every `.mdx` file in your workspace's `docs/` directory is bundled at deploy time and rendered here. Pages appear in the order defined by their `order` frontmatter field.
+
+> **SDK takeaway:** Write `docs/*.mdx` pages for your team -- business process docs, schema references, usage guides. They appear here automatically after each deploy.
+
+---
+
+## Execution Logs
+
+The Execution Logs page shows the history of all executions across every deployed resource.
+
+**What you can do here:**
+
+- Search and filter by resource, status (completed/failed/running), date range
+- Click any execution to view full detail: input, output, step-level trace, duration
+- Identify failed executions and see error messages with stack traces
+- Navigate from a log entry directly to the resource in Command View
+
+**Filtering tips:**
+
+- Filter by resource name to debug a specific workflow
+- Filter by `failed` status to triage production issues
+- Use date range to narrow down incidents
+
+> **SDK takeaway:** Every `elevasis exec` and every scheduled run appears here. Use this page to verify behavior after deploy and to diagnose failures before opening code.
+
+---
+
+## Credentials
+
+The Credentials page manages encrypted API keys and OAuth tokens used by your workflows at runtime.
+
+**What you can do here:**
+
+- Create API key and webhook-secret credentials via a form
+- Connect OAuth providers (Notion, Google Sheets, Dropbox) via browser flow
+- View existing credentials (values are never shown after creation)
+- Delete credentials that are no longer needed
+
+**Two credential types:**
+
+| Type                     | Created via                                  | Notes                                                  |
+| ------------------------ | -------------------------------------------- | ------------------------------------------------------ |
+| API key / webhook secret | CLI (`elevasis-sdk creds create`) or UI form | Either method works                                    |
+| OAuth                    | UI only                                      | Requires browser redirect -- cannot be created via CLI |
+
+**OAuth credentials require the UI.** When a workflow uses an OAuth-connected service, the user must complete the OAuth flow here first. The CLI `creds` skill handles API keys; redirect OAuth credential setup to this page.
+
+> **SDK takeaway:** Reference credentials in your code by name (`credential: 'my-cred-name'`). Create API keys via CLI or UI; OAuth credentials require this page.
+
+---
+
+## Deployments
+
+The Deployments page shows the history of all deployments for your organization.
+
+**What you can do here:**
+
+- View a chronological list of past deployments
+- See which resources changed in each deployment
+- Identify the currently active version
+- Compare resource counts across deployments
+
+**How it connects to your code:** Each `elevasis deploy` run creates a new deployment entry. The platform activates the new version atomically -- in-flight executions complete against the previous version while new executions start against the new one.
+
+> **SDK takeaway:** Check this page after `elevasis deploy` to confirm your resources are active. If something behaves unexpectedly, look here to confirm the latest version is live.
+
+---
+
+**Last Updated:** 2026-03-03

package/reference/developer/interaction-guidance.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Interaction Guidance"
-description: "Full dimensional adaptation rules per skill axis -- programming, TypeScript, API integration, automation concepts, domain expertise -- with growth tracking protocol"
+description: "Full dimensional adaptation rules per skill axis -- platform navigation, API integration, automation concepts, domain expertise -- with growth tracking protocol"
 loadWhen: "Unsure how to adapt for a skill combination"
 ---
 
@@ -10,61 +10,28 @@ This reference defines how to adapt every interaction based on the dimensions in
 
 ## Skill Dimensions
 
-The user profile stores five independent skill dimensions. Each dimension has its own adaptation rules. Do not collapse them into a single beginner/intermediate/advanced rating.
+The user profile stores four independent skill dimensions. Each dimension has its own adaptation rules. Do not collapse them into a single beginner/intermediate/advanced rating.
 
-### Programming Fundamentals (none / minimal / comfortable / advanced)
+### Platform Navigation (none / oriented / comfortable)
 
-**none** -- Has not written code. May have used no-code tools.
+**none** -- Never used the Command Center. Does not know where pages are.
 
-- Explain what functions, variables, and objects are when they appear in code
-- Use analogies for every technical concept (see Analogies section below)
-- Show complete, working files with every import included
-- Never show code fragments they cannot place
-- Walk through each line in plain English before showing code
-- Do not assume they can read code independently
+- Walk through each page step by step before directing the user there
+- Provide exact navigation paths (e.g., "Open the Command Center, then click Execution Runner in the left sidebar")
+- Explain what each page does before asking them to use it
+- Do not assume they can find a page by name alone
 
-**minimal** -- Has written HTML, CSS, Excel formulas, or simple scripts.
+**oriented** -- Has explored the Command Center, knows the main sections.
 
-- Briefly explain language constructs that differ from what they know
-- Show complete files with inline comments on non-obvious parts
-- Avoid assuming they know what async/await, imports, or type annotations do
-- Skip explanations of basic web/formula concepts they likely know
+- Reference pages by name (Execution Runner, Command Queue, Task Scheduler)
+- Briefly remind the user what a page does on first mention in a session
+- Trust them to navigate once you name the destination
 
-**comfortable** -- Has written programs in at least one general-purpose language.
+**comfortable** -- Regularly uses the Command Center without guidance.
 
-- Brief inline comments for non-obvious SDK-specific parts
-- Skip explanations of variables, functions, loops, and basic data structures
-- Focus on what is different about TypeScript and the SDK API
-
-**advanced** -- Writes production software professionally.
-
-- Concise code, no commentary on language features
-- Focus only on SDK-specific patterns and constraints
-- Trust them to infer context from types and naming
-
----
-
-### TypeScript (none / exposure / proficient)
-
-**none** -- Has not used TypeScript or any statically typed language.
-
-- Show complete files with every import
-- Explain type annotations as "labels that describe what kind of data this is"
-- Never use generics without a plain-English explanation
-- Explain `z.infer` every time it appears: "This creates a TypeScript type from the schema so you get autocomplete and error checking"
-- Explain the difference between runtime validation (Zod) and compile-time checking (TypeScript)
-
-**exposure** -- Has read TypeScript or used a typed language (Java, C#, Go).
-
-- Show code with brief type annotation comments for SDK-specific types
-- Explain `WorkflowDefinition`, `StepType`, and `OrganizationResources` on first use
-- Trust them to understand basic type syntax
-
-**proficient** -- Has written TypeScript projects.
-
-- Types without explanation
-- Focus on SDK API surface, not language features
-- Trust them to read type definitions
+- Reference pages by name only, no reminders needed
+- Focus on advanced filtering, schedule types, and log detail navigation
+- Trust them to explore and navigate independently
 
 ---
 
@@ -163,9 +130,11 @@ Choose the analogy that fits the user's domain. A sales operations person will r
 During each session, note behaviors that reveal skill level changes. Examples:
 
 - User wrote a handler without asking for help
-- User independently caught a type error before you pointed it out
 - User suggested using StepType.CONDITIONAL without prompting
 - User asked a question that shows they now understand the execution model
+- User navigated to the correct Command Center page without being directed
+- User filtered Execution Logs by resource independently to diagnose a failure
+- User created a Task Scheduler entry unassisted
 
 ### Promotion Rules
 
@@ -181,7 +150,7 @@ When updating `.claude/memory/profile/skills.md` Growth Log:
 
 ```
 | Date | Observation | Skill Updated |
-| 2026-03-01 | Wrote complete handler with correct types independently | TypeScript: none -> exposure |
+| 2026-03-01 | Navigated to Execution Logs and filtered by resource without direction | Platform Navigation: none -> oriented |
 ```
 
 Also update the dimension's Level field and Evidence field to reflect the new assessment.
@@ -190,7 +159,7 @@ Also update the dimension's Level field and Evidence field to reflect the new as
 
 When growth is observed, acknowledge it briefly:
 
-- "You just wrote that handler without any help -- your TypeScript is definitely improving."
+- "You found that on your own -- looks like you've got the Command Center navigation down."
 - "Good catch on the optional field -- that is exactly the kind of thing that trips people up."
 
 Keep it natural. One sentence is enough. Do not over-celebrate.

package/reference/framework/agent.mdx

@@ -42,14 +42,13 @@ At the start of every session the agent runs these steps silently before respond
 
 Slash commands are short Markdown instruction files in `.claude/commands/`. When you type `/command-name` in a Claude Code session, the agent reads the corresponding file and follows its instructions.
 
-Four commands and one skill are scaffolded by `elevasis init` and committed to version control so collaborators get the same experience:
+Three commands and one skill are scaffolded by `elevasis init` and committed to version control so collaborators get the same experience:
 
 | Command | File | Purpose |
 | --- | --- | --- |
-| `/meta` | `meta.md` | Project lifecycle -- init, status, fix, deploy, health |
-| `/docs` | `docs.md` | Documentation lifecycle -- create, review, verify |
-| `/work` | `work.md` | Task tracking -- create, save, resume, complete |
-| `/tutorial` | `tutorial.md` | Progressive 7-lesson learning path |
+| `/meta` | `meta.md` | Project lifecycle -- init, status, fix (incl. docs verification), deploy, health |
+| `/work` | `work.md` | Task tracking -- list, create, save, resume, complete |
+| `/tutorial` | `tutorial.md` | Progressive learning path -- 3 tracks, menu-driven |
 
 The `/creds` skill (`.claude/skills/creds/SKILL.md`) is also scaffolded. It auto-triggers when the agent detects credential-related context and manages credential storage and retrieval.
 
@@ -63,28 +62,19 @@ The `/meta` command namespace manages the full project lifecycle. It has five op
 - **`/meta deploy`** -- Full 9-step deploy pipeline: validate, type-check, verify docs, commit, deploy (auto-regenerates `docs/project-map.mdx`), verify platform, update deployment state, and optionally push.
 - **`/meta health`** -- Execution debugging and resource status; shows recent executions, analyzes failures, and checks environment connectivity.
 
-### `/docs` Command
-
-The `/docs` command manages documentation in `docs/`. It has four operations:
-
-- **`/docs`** (no arguments) -- Review existing `docs/` files and suggest improvements. Identifies undocumented resources, missing descriptions, and structural gaps.
-- **`/docs create <page-name>`** -- Scaffold a new documentation page with correct frontmatter, populated from resource definitions in `src/`.
-- **`/docs review`** -- Review all `docs/` files for accuracy against actual resource definitions. Flags mismatches between documented schemas and code.
-- **`/docs verify [path]`** -- Cross-reference documentation with the codebase. Reads the specified doc (or all docs if no path provided) and reports discrepancies against actual resource IDs, schema fields, and platform tools.
-
 ### `/work` Command
 
-The `/work` command manages in-progress task tracking across sessions. It uses `docs/in-progress/` for task documents with standardized frontmatter (`status: planned | in-progress | blocked | complete`). Operations:
+The `/work` command manages in-progress task tracking across sessions. It uses `docs/in-progress/` for task documents with standardized frontmatter (`status: planned | in-progress | complete`). Operations:
 
-- **`/work`** (no arguments) -- List all task documents sorted by status and last updated.
-- **`/work create <description>`** -- Create a new task document with Objective, Plan, Progress, and Resume Context sections.
-- **`/work save`** -- Update the current task document with progress made this session. Useful before clearing context.
-- **`/work resume [<name>]`** -- Load a task document and continue from where it left off.
-- **`/work complete`** -- Mark the current task as complete and optionally move the doc to a `completed/` archive.
+- **`/work`** (no arguments) -- Numbered list sorted by status (`in-progress` first) with last-saved date and current step. Pick by number to auto-resume.
+- **`/work create`** -- Guided interview (3-4 questions) to create a task document with intelligent placement in `docs/in-progress/`.
+- **`/work save`** -- Comprehensive snapshot: progress markers, files modified table, key docs to read on resume, and a "To continue" prompt. Proactively suggested before context pressure builds.
+- **`/work resume [<name>]`** -- Load a task by number, keyword, or auto-detect. No file paths required.
+- **`/work complete`** -- Seven-step pipeline: validate readiness, clean doc, determine destination in `docs/`, confirm with user, move, verify.
 
 ### `/tutorial` Command
 
-The `/tutorial` command runs a 7-lesson guided learning path adapted to the user's skill profile. Each lesson teaches a concept, guides the user to build something, and verifies it works. Lessons cover: project orientation, first custom workflow, schemas, platform tools, multi-step workflows, conditional routing, and going to production.
+The `/tutorial` command shows a track menu on every invocation and runs a progressive learning path adapted to the user's skill profile. Three tracks: Orchestration Concepts (7 lessons), Examples & Advanced Modules (9 standalone modules), and Meta-Framework (5 lessons). Two skill dimensions tracked: `automation` (none / low-code / custom) and `platformNavigation` (none / oriented / comfortable).
 
 ## Developer Profile
 

package/reference/framework/index.mdx

@@ -16,10 +16,11 @@ Running `elevasis init my-project` produces the following agent infrastructure a
 .claude/
 ├── settings.json               # autoCompact: false
 ├── commands/
-│   ├── docs.md                 # Documentation lifecycle
 │   ├── meta.md                 # Project lifecycle (init, fix, deploy, health)
-│   ├── tutorial.md             # Progressive 7-lesson learning path
+│   ├── tutorial.md             # Progressive learning path (3 tracks)
 │   └── work.md                 # Task tracking
+├── hooks/
+│   └── enforce-sdk-boundary.mjs  # Blocks destructive git, gh CLI, external writes
 ├── skills/
 │   └── creds/SKILL.md          # Credential management (auto-triggers)
 └── rules/
@@ -51,7 +52,7 @@ The agent reads `memory/index.md` at session start and drills into `memory/profi
 
 The `CLAUDE.md` file drives all agent behavior. It contains the session initialization instructions, adaptive guidance tiers, memory maintenance rules, and slash command definitions. No hooks, no code enforcement -- everything is instruction-driven so non-technical users never need to configure anything.
 
-The `/meta` command manages the project lifecycle: `/meta init` for guided setup, `/meta fix` for SDK upgrades and drift repair, `/meta deploy` for deployments, `/meta health` for debugging executions. `/docs` handles documentation maintenance, `/work` tracks tasks across sessions, and `/tutorial` guides new developers through a 7-lesson learning path. A `creds` skill auto-triggers when credential setup is needed.
+The `/meta` command manages the project lifecycle: `/meta init` for guided setup, `/meta fix` for SDK upgrades, drift repair, and documentation verification, `/meta deploy` for deployments, `/meta health` for debugging executions. `/work` tracks tasks across sessions, and `/tutorial` guides new developers through a menu-driven multi-track learning path. A `creds` skill auto-triggers when credential setup is needed.
 
 See [Agent System](agent.mdx) for CLAUDE.md sections, slash command reference, developer profile, and adaptive guidance tiers.
 

package/reference/framework/project-structure.mdx

@@ -96,7 +96,7 @@ This file is NOT scaffolded by default. The agent creates it the first time you
 
 ### `docs/in-progress/`
 
-Work-in-progress documentation created by `/docs checkpoint`. Each file represents an active work item with current state, decisions made, and remaining tasks. `/docs cleanup` moves completed items to their final location in `docs/`. `/docs resume` reviews these files at session start.
+Work-in-progress task documents created by `/work create`. Each file represents an active work item with objective, plan, progress markers, and resume context. `/work complete` moves finished items to their permanent location in `docs/`.
 
 This directory is NOT deployed -- it is filtered out during the doc scan in `elevasis deploy`.
 
@@ -112,7 +112,7 @@ Only `src/` and `docs/` are scaffolded by `elevasis init`. The following directo
 | `src/example/` | `elevasis init` (default) | Always -- echo starter workflow lives here (replace with your own) |
 | `src/shared/` | `elevasis init` (default) | Always -- cross-domain shared utilities (starts empty) |
 | `docs/` | `elevasis init` (default) | Always |
-| `docs/in-progress/` | Agent (on first `/docs checkpoint`) | When you save work-in-progress across sessions |
+| `docs/in-progress/` | Agent (on first `/work create`) | When you create a task doc for in-progress work |
 | `docs/project-map.mdx` | `elevasis deploy` | Auto-generated on every deploy |
 | `docs/priorities.mdx` | Agent (on first goal discussion) | When you discuss project goals or priorities |
 | `data/` | Agent (on demand) | When you connect a database |
@@ -229,7 +229,7 @@ This directory is gitignored -- it is personal to you and not shared with collab
 
 ## Slash Commands
 
-The `.claude/commands/` directory contains four commands covering the core development loop. Invoke them in Claude Code with `/meta`, `/docs`, `/work`, and `/tutorial`.
+The `.claude/commands/` directory contains three commands covering the core development loop. Invoke them in Claude Code with `/meta`, `/work`, and `/tutorial`.
 
 ### `/meta` -- Project Lifecycle
 
@@ -241,15 +241,6 @@ Manages the full lifecycle of your workspace. Five operations:
 - **`deploy`** -- Full 9-step deploy pipeline: validate, type-check, verify docs, commit, deploy (auto-regenerates `docs/project-map.mdx`), verify platform, update deployment state, and optionally push.
 - **`health`** -- Execution debugging and resource status; shows recent executions, analyzes failures, and checks environment connectivity.
 
-### `/docs` -- Documentation Lifecycle
-
-Manages documentation creation and maintenance for `docs/`. Four operations:
-
-- **No arguments** -- Review existing `docs/` files and suggest improvements. Identifies undocumented resources, missing descriptions, and structural gaps.
-- **`create <page-name>`** -- Scaffold a new documentation page with correct frontmatter, populated from your resource definitions.
-- **`review`** -- Review all `docs/` files for accuracy against actual resource definitions. Flags mismatches between documented schemas and code.
-- **`verify [path]`** -- Cross-reference documentation with the codebase. Reports discrepancies against actual resource IDs, schema fields, and platform tools.
-
 ### `/work` -- Task Tracking
 
 Manages in-progress task tracking across sessions using `docs/in-progress/` task documents. Five operations:
@@ -281,7 +272,8 @@ Not all scaffolded files participate in template updates. Files fall into two ca
 
 **MANAGED** (14 files) -- Written during `elevasis init` and checked/updatable by `elevasis update`:
 - `elevasis.config.ts`, `.gitignore`, `CLAUDE.md`, `.claude/settings.json`
-- Four command files: `.claude/commands/docs.md`, `.claude/commands/meta.md`, `.claude/commands/tutorial.md`, `.claude/commands/work.md`
+- One hook: `.claude/hooks/enforce-sdk-boundary.mjs`
+- Three command files: `.claude/commands/meta.md`, `.claude/commands/tutorial.md`, `.claude/commands/work.md`
 - One skill: `.claude/skills/creds/SKILL.md`
 - Five rule files: `.claude/rules/sdk-patterns.md`, `.claude/rules/docs-authoring.md`, `.claude/rules/memory-conventions.md`, `.claude/rules/project-map.md`, `.claude/rules/task-tracking.md`
 

package/reference/runtime/limits.mdx

@@ -28,13 +28,11 @@ Hard limits to prevent abuse and ensure platform stability:
 
 | Limit | Value |
 | ----- | ----- |
-| Max resources per org | 50 |
 | Max execution duration (workflows) | 300s (5 min) |
 | Max execution duration (agents) | 600s (10 min) |
 | Max log volume | 100MB/day |
 | Max deploy frequency | 60/day |
 
-- **Resources per org:** The combined count of all workflows and agents across your organization cannot exceed 50.
 - **Execution duration:** Executions exceeding the timeout are terminated by the platform. The execution is marked failed with a timeout reason.
 - **Log volume:** Total log output across all executions is capped at 100MB per day. Logs beyond this threshold may be truncated.
 - **Deploy frequency:** 60 deploys per day is generous for normal development. This limit prevents accidental deploy loops (for example, a CI pipeline misconfigured to deploy on every commit).
@@ -74,4 +72,4 @@ Organization creation is currently admin-only. If you need a new organization pr
 
 ---
 
-**Last Updated:** 2026-02-25
+**Last Updated:** 2026-03-03