@elevasis/sdk 1.6.0 → 1.8.0

package/reference/claude-config/skills/configure/operations/techStack.md

@@ -0,0 +1,139 @@
+# Configure: techStack
+
+Guides the user through reviewing and updating the tech stack metadata on resource mapping entries
+in the organization model.
+
+Tech stack information lives as an optional `techStack` extension field on each `ResourceMapping`
+entry -- not as a standalone top-level domain. This keeps all integration metadata co-located with
+the resource mapping that represents it, while adding fields that agents need for cross-integration
+automation and system-of-record resolution.
+
+## Schema reference
+
+Source: `packages/core/src/organization-model/domains/shared.ts`
+
+```typescript
+TechStackEntrySchema = z.object({
+  platform:         z.string().trim().min(1).max(200),
+  purpose:          z.string().trim().min(1).max(500),
+  credentialStatus: z.enum(['configured', 'pending', 'expired', 'missing']),
+  isSystemOfRecord: z.boolean().default(false)
+})
+```
+
+`credentialStatus` values:
+
+- `configured` -- credential present and valid
+- `pending` -- not yet set up
+- `expired` -- credential existed but has lapsed
+- `missing` -- expected but not present
+
+`isSystemOfRecord: true` means this integration is the authoritative data source for its domain
+(e.g. HubSpot is the system of record for contacts).
+
+`techStack` is an optional field on `ResourceMappingSchema`. It is added to individual resource
+mapping entries whose `resourceType` is `'integration'` or `'external'`.
+
+Where this lands in the adapter: `foundations/config/organization-model.ts` inside the
+`resourceMappings` array of `defineOrganizationModel({...})`. The `techStack` field is set on the
+matching `ResourceMapping` object.
+
+---
+
+## Process
+
+### Step 1: Read current state
+
+Read `foundations/config/organization-model.ts` and extract the `resourceMappings` array. Filter
+to entries that either already have a `techStack` field or have `resourceType: 'integration'` or
+`'external'`. Present as a summary:
+
+```
+Resource mappings with integration context (N):
+  {label} ({id}) -- resourceType: {type}
+    techStack: {platform} | {credentialStatus} | SoR: {yes/no}
+    (no techStack yet)
+
+Other resource mappings (M total, K without techStack):
+  {list by label}
+```
+
+If there are no resource mappings at all, note that the user should add resource mappings through
+the SDK deployment process before configuring tech stack metadata here.
+
+### Step 2: Establish intent
+
+Ask whether the user wants to:
+
+- **Add or update** tech stack metadata on an existing resource mapping
+- **Update credential status** on an existing tech stack entry
+- **Mark or unmark** an integration as the system of record
+- **Review all** integration health
+
+For adding or updating, the user selects a resource mapping from the list.
+
+### Step 3: Gather tech stack details
+
+For each resource mapping being updated:
+
+**If no `techStack` field yet:**
+
+- "What external platform does this resource mapping represent? (e.g. 'HubSpot', 'Stripe',
+  'Notion', 'Apify')"
+- "What is this integration used for? (free-form description)"
+- "What is the current credential status? Options: configured, pending, expired, missing."
+- "Is this the system of record for its domain? (e.g. HubSpot is SoR for contacts)"
+
+**If `techStack` already exists:**
+
+Show the current values and ask which fields to update.
+
+Credential status shortcut: if the user only wants to mark a credential as configured or expired,
+skip directly to that field.
+
+### Step 4: Confirm before writing
+
+Present a diff scoped to the affected resource mapping entry:
+
+```
+Proposed techStack change:
+
+UPDATE resourceMapping "HubSpot CRM Integration" (rm-hubspot):
+  techStack:
+    platform:         "HubSpot"
+    purpose:          "CRM for contacts, companies, and deal pipeline"
+    credentialStatus: "pending" -> "configured"
+    isSystemOfRecord: false -> true
+
+Apply? (yes/no)
+```
+
+### Step 5: Codify
+
+Execute `.claude/skills/configure/operations/codify-level-a.md` with the proposed change to the
+`resourceMappings` array. Only the targeted entry (matched by `id`) is modified -- all other
+entries are left unchanged.
+
+The write edits the `techStack` field on the matching `ResourceMapping` object inside the
+`defineOrganizationModel({...})` call.
+
+### Step 6: Report
+
+After successful validation:
+
+```
+Tech stack updated.
+  Integrations: {total with techStack} ({N updated})
+  foundations/config/organization-model.ts -- resourceMappings updated
+  Type-check: PASS
+  Schema validation: PASS
+```
+
+If validation failed and rollback occurred:
+
+```
+Tech stack update rolled back.
+  Reason: {error message}
+  foundations/config/organization-model.ts -- restored to previous state
+  No changes persisted.
+```

package/reference/claude-config/skills/deploy/SKILL.md

@@ -38,17 +38,6 @@ Read the current version from `package.json`, then bump it:
 
 Use the Edit tool to update the `"version"` field in `package.json` directly. Do not use `npm version` or any CLI command.
 
-### Step 1c: Regenerate Documentation
-
-Run both doc generators in sequence (resources first so the nav index picks up `resources.md`):
-
-```bash
-pnpm exec elevasis-sdk generate-resources
-pnpm exec elevasis-sdk generate-docs
-```
-
-This ensures autogenerated files (`docs/resources.md`, `docs/index.md`) reflect the current resource state before they are committed. These must run after the version bump so any version references in generated output are correct.
-
 ### Step 2: Run Tests
 
 ```bash
@@ -133,8 +122,9 @@ After a successful push, mark any linked project task as `submitted`. This is a
    - The most recent in-progress task on the most-recently-touched project, via:
 
      ```bash
-     pnpm -C operations exec elevasis-sdk project:list --status active,blocked --format brief
-     pnpm -C operations exec elevasis-sdk project:task:list --project <project-id> --status in_progress
+     pnpm elevasis-sdk project:list --status active --pretty
+     pnpm elevasis-sdk project:list --status blocked --pretty
+     pnpm elevasis-sdk project:task:list --project <project-id> --status in_progress --pretty
      ```
 
    - If the session produced an ambiguous or empty result, PROMPT the user once: "Mark a project task as submitted? (task UUID, or 'skip')". Default is skip.

package/reference/claude-config/skills/dsp/SKILL.md

@@ -13,13 +13,13 @@ Parallel agent dispatch for implementation tasks. Orchestrate, then delegate to
 
 1. **Always dispatch, never self-execute** -- the purpose is to offload work to subagents
 2. **Parallel within waves** -- all agents in a wave dispatched in a SINGLE message
-3. **Read docs first** -- always read `docs/index.md` before planning to understand project structure
+3. **Orient first** -- read `.claude/rules/agent-start-here.md` before planning to understand project structure and task routing
 
 ## Process
 
 ### Step 1: Understand Context
 
-1. Read `docs/index.md` for project structure and navigation
+1. Read `.claude/rules/agent-start-here.md` for project structure, task-class routing, and boundary resolution
 2. Read relevant architecture/feature docs based on the task domain
 3. If the task touches code, explore the relevant `src/` directories
 

package/reference/claude-config/skills/elevasis/SKILL.md

@@ -49,11 +49,7 @@ Reports: resource count, validation errors, schema serialization warnings. Exit
 
 Bundle and deploy resources to the Elevasis platform.
 
-Before calling the SDK deploy, run both doc generators in sequence so the uploaded docs reflect the current resource state (resources first, then nav so `docs/index.md` picks up `resources.md`):
-
 ```bash
-pnpm exec elevasis-sdk generate-resources
-pnpm exec elevasis-sdk generate-docs
 pnpm -C operations exec elevasis-sdk deploy [--prod]
 ```
 

package/reference/claude-config/skills/explore/SKILL.md

@@ -26,11 +26,11 @@ Before orienting, scan the user's query for Organization OS terminology. If any
 
 **If OS-relevant:**
 
-1. Read `docs/reference/active-change-index.md` immediately. If the target area is flagged as under active refactor, surface the watch-area warning to the user before proceeding — include the "Load:" doc paths listed in that entry so investigation does not rely on stale scaffold prose.
+1. Read `.claude/rules/active-change-index.md` immediately. If the target area is flagged as under active refactor, surface the watch-area warning to the user before proceeding — include the "Load:" doc paths listed in that entry so investigation does not rely on stale scaffold prose.
 2. Build the OS context bundle to pass into Step 3:
-   - Always: `node_modules/@elevasis/sdk/reference/scaffold/reference/glossary.md`, `docs/reference/active-change-index.md`, `docs/agent-start-here.md`
+   - Always: `node_modules/@elevasis/sdk/reference/scaffold/reference/glossary.md`, `.claude/rules/active-change-index.md`, `.claude/rules/agent-start-here.md`
    - Features / Shell / Gating queries: add `node_modules/@elevasis/sdk/reference/scaffold/ui/feature-flags-and-gating.md` + `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md`
-   - Workflow / Operations queries: add `docs/operations/index.md` + `docs/resources.md`
+   - Workflow / Operations queries: add `.claude/rules/operations.md` + glob `operations/resources/**`
    - Organization-model queries: add `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` + `foundations/config/README.md`
 
 **OS layer → query intent map** (guides which reference docs the investigator loads first):
@@ -40,12 +40,12 @@ Before orienting, scan the user's query for Organization OS terminology. If any
 | "Why doesn't my feature show up?"        | Features + UI Shell Runtime      | `glossary.md` (accessFeatureKey, FEATURE_KEY_ALIASES), `feature-flags-and-gating.md`     |
 | "How do I add a nav item?"               | Features + Toolkit               | `feature-flags-and-gating.md`, `contracts.md`                                            |
 | "How does admin gating work?"            | Features + UI Shell Runtime      | `glossary.md` (AdminGuard, requiresAdmin, ProtectedRoute), `feature-flags-and-gating.md` |
-| "What runs when this workflow triggers?" | Platform Public API + Operations | `operations/index.md`, `resources.md`                                                    |
+| "What runs when this workflow triggers?" | Platform Public API + Operations | `.claude/rules/operations.md`, `resources.md`                                            |
 | "Why does the foundations adapter fail?" | Foundations                      | `glossary.md` (domain vs surface, settings asymmetry), `foundations/config/README.md`    |
 
 ### Step 1: Orient
 
-1. Read `docs/index.md` for the full project structure
+1. Read `.claude/rules/agent-start-here.md` for project structure, task-class routing, and boundary resolution
 2. Determine which domain the user's question falls into
 
 ### Step 2: Load Domain Context

package/reference/claude-config/skills/project/SKILL.md

@@ -317,7 +317,7 @@ For progress detail (milestones/tasks), follow up with `project:milestone:list`
 Wraps `project:work` for fuzzy-matched resume. Used by intent-detection "resume" classification.
 
 ```bash
-pnpm elevasis-sdk project:work <query> --pretty
+pnpm elevasis-sdk project:work <query>
 ```
 
 Prints the matched project/task brief with current `resume_context`. If multiple matches, show top 3 and ask which.

package/reference/claude-config/skills/save/SKILL.md

@@ -88,10 +88,6 @@ No other fields. Do NOT add `resume_context`, `files_modified`, or `next_steps`
 
 **Doc structure rules:**
 
-- `docs/ui/` -- frontend features, auth, components, hooks, charts, pages
-- `docs/operations/` -- platform workflows, agents, deployment, resource registry
-- `docs/knowledge/` -- project knowledge, research, reference material, domain context
-- New sections auto-detected -- any subdirectory of `docs/` becomes a section
 - All docs are `.md` (not .mdx)
 - Keep docs focused -- one topic per file
 - Use markdown tables for structured data
@@ -115,11 +111,11 @@ Dispatch a `general-purpose` subagent with the plan, conversation context, and t
 If Step 1 resolved a task ID, save the current state to `prj_tasks.resume_context` via the SDK CLI. This is the canonical persistence step and must run every `/save` invocation that has a task in scope:
 
 ```bash
-pnpm exec elevasis-sdk project:task:save <task-uuid> \
+pnpm elevasis-sdk project:task:save <task-uuid> \
   --current-state "<concise prose summary of where we are>" \
   --next-steps "<concise prose of the next concrete action>" \
   --files-modified '["path/one.ts","path/two.tsx"]' \
-  --key-docs '["docs/knowledge/foo.md"]' \
+  --key-docs '["operations/resources/foo/index.ts"]' \
   --tools '["project:task:save","project:note:create"]'
 ```
 
@@ -138,7 +134,7 @@ The endpoint is `PATCH /api/external/tasks/<id>/resume-context` and merges (does
 For each signal event identified in Step 2, create a typed `prj_note`. One CLI call per note:
 
 ```bash
-pnpm exec elevasis-sdk project:note:create \
+pnpm elevasis-sdk project:note:create \
   --project <project-uuid> \
   --task <task-uuid>          # optional, omit if not scoped to a task \
   --type <note-type> \
@@ -169,17 +165,7 @@ Rules:
 - **Idempotent** -- if the task is already `blocked`, the update is a no-op. Fire it anyway; do not pre-check.
 - **Order** -- the `blocker` note (Step 5) creates first; this transition follows. Keeps the note attached to the task even if the status update later fails.
 
-### Step 6: Regenerate Docs Index
-
-After the Step 3 subagent completes all doc file changes, regenerate `docs/index.md`:
-
-```bash
-pnpm exec elevasis-sdk generate-docs
-```
-
-This deterministically scans `docs/`, reads frontmatter, and rebuilds the navigation hub. Never edit `docs/index.md` manually.
-
-### Step 7: Report
+### Step 6: Report
 
 Summarize:
 
@@ -194,4 +180,4 @@ Summarize:
 
 - **No task in scope + user declines to provide one:** proceed with Steps 2, 3, 6, 7; skip Step 4; still allow Step 5 if a `--project` UUID is available.
 - **`project:task:save` returns non-2xx:** surface the error in the report, do not retry silently; Step 5 and Step 6 still run.
-- **`generate-docs` fails:** surface the error; doc edits from Step 3 are already on disk, so they are not lost -- the operator can re-run the index regeneration manually.
+- **Knowledge doc edits fail to write:** surface the error; any edits already applied are on disk and not lost.

package/reference/claude-config/skills/setup/SKILL.md

@@ -1,35 +1,51 @@
 ---
 name: setup
-description: First-time project setup — detect and replace template placeholders, install dependencies, verify build
+description: First-time project setup — detect and replace template placeholders, install dependencies, verify build, then hand off to /configure for org-model configuration
 argument-hint: ""
 ---
 
 # Setup
 
-First-time project setup for projects cloned directly from the template.
+First-time project setup for projects cloned directly from the template. Handles placeholder replacement, dependency install, and build verification. After bootstrap, delegates org-model configuration to `/configure`.
 
 **Usage:** `/setup`
 
-## Process
+---
 
-### Step 1: Detect State
+## State Detection (Run Before Anything Else)
 
-Scan these key files for unresolved placeholders:
+Before collecting any information or running any steps, determine which state the project is in. Read these files:
 
 - `package.json` — look for `__PROJECT_SLUG__` in the `name` field
-- `CLAUDE.md` — look for `TEMPLATE_PROJECT_NAME`
+- `CLAUDE.md` — look for `TEMPLATE_PROJECT_NAME` AND check whether `{CLIENT_CONTEXT}` and `{USER_PREFERENCES}` are still literal placeholder strings
 - `ui/package.json` — look for `__PROJECT_SLUG__`
 - `ui/index.html` — look for `__PROJECT_NAME__`
 
-If NO placeholders are found, the project is already configured. Print:
+**State A — Virgin (placeholders present):** One or more of the above placeholder strings is found. Run the full bootstrap flow (Steps 1–7 below), then hand off to `/configure`.
+
+**State B — Already bootstrapped, org-model at defaults:** No placeholders found, but `foundations/config/organization-model.ts` contains only the default branding override (just `branding.organizationName`, `branding.productName`, `branding.shortName` — no identity, customers, offerings, roles, goals, or techStack overrides). Print:
 
 ```
-Project is already configured. Running verification...
+This project is already set up. The organization model has not been configured yet.
+Running /configure to set up your organization profile...
 ```
 
-Then skip directly to Step 4 (Install) or Step 5 (Verify) as appropriate.
+Then execute `/configure` (the full layered flow) and stop.
 
-### Step 2: Collect Info
+**State C — Fully configured:** No placeholders found AND `foundations/config/organization-model.ts` has at least one non-branding domain populated (identity, customers, offerings, roles, goals, or techStack present). Print:
+
+```
+This project is already configured. To update your organization profile, run /configure.
+To re-verify the build, run the checks below.
+```
+
+Offer to run the verification checks (Steps 6b–6e) if the user wants them. Do not re-ask any questions. Do not re-run placeholder replacement. Stop after verification.
+
+---
+
+## Full Bootstrap Flow (State A Only)
+
+### Step 1: Collect Project Info
 
 Ask the user for three values:
 
@@ -49,7 +65,7 @@ Configuring project with:
 Proceed? (yes/no)
 ```
 
-### Step 3: Get to Know the User and Client
+### Step 2: Get to Know the User and Client
 
 Transition naturally after confirming the project values: "Now let me learn a bit about you and the client so I can be more helpful going forward."
 
@@ -86,7 +102,7 @@ Client: {company}
 Look good?
 ```
 
-### Step 4: Replace Placeholders
+### Step 3: Replace Placeholders
 
 Search ALL files in the project matching these extensions: `.ts`, `.tsx`, `.js`, `.mjs`, `.json`, `.md`, `.mdx`, `.html`, `.yaml`, `.yml`, `.css`, `.env.example`
 
@@ -105,21 +121,19 @@ For each matching file, replace all occurrences of:
 
 Use the Read tool to read each file, then the Edit tool (with `replace_all: true`) or Write tool to apply the replacements. Read each file before writing.
 
-After all replacements, re-scan the four key files from Step 1 to verify zero placeholders remain. If any are still present, report them by file and fix immediately.
+After all replacements, re-scan the four key files from State Detection to verify zero placeholders remain. If any are still present, report them by file and fix immediately.
 
-### Step 5: Populate Knowledge
+### Step 4: Populate CLAUDE.md Knowledge Sections
 
-Knowledge is split between `CLAUDE.md` (essentials loaded every turn) and `docs/knowledge/client.md` (detailed context loaded on demand).
+**Idempotency check (MANDATORY before writing):** Read `CLAUDE.md` and check whether `{CLIENT_CONTEXT}` and `{USER_PREFERENCES}` are still literal placeholder strings. Only write if they are still placeholders. If either section is already filled in (user or a previous run already populated it), skip that section entirely — do not overwrite.
 
-#### 5a: CLAUDE.md — lightweight summary
-
-**`{CLIENT_CONTEXT}`** -- replace with a single line:
+**`{CLIENT_CONTEXT}`** -- replace with a single line (only if still a placeholder):
 
 ```markdown
 **{company name}** — {what they do, one sentence}
 ```
 
-**`{USER_PREFERENCES}`** -- replace with a table:
+**`{USER_PREFERENCES}`** -- replace with a table (only if still a placeholder):
 
 ```markdown
 | Name   | Role   | Technical Level | Communication |
@@ -129,28 +143,47 @@ Knowledge is split between `CLAUDE.md` (essentials loaded every turn) and `docs/
 
 If the user skipped any knowledge questions, fill in what was provided and omit what wasn't -- don't leave placeholder text behind.
 
-#### 5b: docs/knowledge/client.md — full client context
+### Step 5: Write Client Brief to Org Model
 
-Create `docs/knowledge/client.md` with the detailed info:
+**Idempotency check:** Read `foundations/config/organization-model.ts` and inspect `identity.clientBrief`. If the field is already a non-empty string, skip this step entirely — do not overwrite.
 
-```markdown
----
-title: Client Context
-description: Company background, industry, stakeholders, and business goals
----
-
-# Client Context
+If the field is empty or absent, compose the client brief from the information gathered in Step 2:
 
+```markdown
 **Company:** {company name}
 **Industry:** {industry}
 **Description:** {what they do}
 
 ## Additional Context
 
-{any additional context shared -- key stakeholders, business goals, constraints, etc. If nothing was shared, write "No additional context provided yet. Update this as the project evolves."}
+{any additional context shared — key stakeholders, business goals, constraints, etc. If nothing was shared, write "No additional context provided yet. Update this as the project evolves."}
+```
+
+Propose the composed content to the user before writing (read → propose → confirm → write — the same ceremony `/configure` uses):
+
+```
+Here's the client brief I'll write into identity.clientBrief:
+
+---
+{composed content}
+---
+
+Write this? (yes/no)
+```
+
+On confirmation, use the Edit tool to replace the `clientBrief: ''` value in `foundations/config/organization-model.ts` with a template literal containing the composed markdown. Use a regular string (backtick or single-quoted multi-line) — ensure the closing quote and trailing comma are correct TypeScript.
+
+After the edit, run:
+
+```bash
+pnpm -C foundations check-types
 ```
 
-### Step 6: Install Dependencies
+If type-check fails, report the error and do not proceed to Step 6 until it is resolved.
+
+### Step 6: Install and Verify
+
+#### Step 6a: Install Dependencies
 
 ```bash
 pnpm install
@@ -158,7 +191,7 @@ pnpm install
 
 This generates the project's own `pnpm-lock.yaml`. Report success or any errors.
 
-### Step 7: Verify
+#### Step 6b–6e: Verify Build
 
 Run all checks sequentially (stop and report on first failure, but attempt all):
 
@@ -171,7 +204,7 @@ pnpm -C operations check-types
 
 For each check, record PASS or FAIL. If a check fails, read the output and report the error clearly. Do not silently skip failures.
 
-### Step 8: Report
+### Step 7: Bootstrap Report
 
 ```
 You're all set, {name}!
@@ -185,16 +218,23 @@ Verification:
   [PASS/FAIL] Production build (ui)
   [PASS/FAIL] Resource validation (operations)
   [PASS/FAIL] Type-check (operations)
+```
+
+If any verification step failed, add an Errors section listing each failure with its output.
+
+### Step 8: Hand Off to /configure
+
+After a successful bootstrap, transition to the org-model configuration flow. Print:
 
-Next steps:
-1. Copy root .env.example to .env and fill in ELEVASIS_PLATFORM_KEY
-2. Copy ui/.env.example to ui/.env and fill in VITE_WORKOS_CLIENT_ID
-3. See TODO.md for WorkOS dashboard setup and branding
-4. pnpm -C ui dev  (start dev server on port 4300)
-5. (If client-workspace/ exists) Open it in Claude Code and run /setup
 ```
+Bootstrap complete. Now let's set up your organization profile.
+```
+
+Then execute `/configure` (the full layered flow, no argument). This is where identity, customers, offerings, roles, goals, and techStack are configured. Do not attempt to collect or write org-model data here — that ceremony belongs entirely to /configure.
 
-If any verification step failed, add an Errors section listing each failure with its output before the Next steps.
+If the user wants to skip org-model setup for now, they can stop here and run `/configure` later.
+
+---
 
 ## Error Recovery
 
@@ -207,4 +247,29 @@ Remaining: <list files and placeholders>
 Action: Re-applying replacements to affected files...
 ```
 
-Fix each remaining occurrence before proceeding to Step 6.
+Fix each remaining occurrence before proceeding to Step 6a.
+
+---
+
+## Idempotency Guarantees
+
+Running `/setup` more than once is safe:
+
+- **Placeholder replacement** only runs when placeholders are detected (State A). It is skipped entirely in States B and C.
+- **CLAUDE.md knowledge sections** (`{CLIENT_CONTEXT}`, `{USER_PREFERENCES}`) are checked before writing. If already replaced, the write is skipped.
+- **`identity.clientBrief`** is only written when the field is empty. A non-empty field is never overwritten by `/setup`. The write uses a read → propose → confirm ceremony before touching the file.
+- **All other org-model fields** (`foundations/config/organization-model.ts`) are never written by `/setup`. All other org-model edits go through `/configure`, which has its own diff-preview and confirm ceremony.
+
+---
+
+## Relationship to /configure
+
+`/setup` is a thin bootstrap wrapper. It:
+
+1. Replaces scaffold placeholders (project name, slug, description)
+2. Fills lightweight CLAUDE.md knowledge sections (user and client basics, idempotent)
+3. Writes the client brief into `identity.clientBrief` in the org model (confirm-before-write, idempotent)
+4. Installs dependencies and verifies the build
+5. Hands off to `/configure` for full org-model configuration
+
+`/configure` owns all other structural org-model editing (identity fields beyond clientBrief, customers, offerings, roles, goals, techStack, features, labels). It is idempotent, confirm-before-overwrite, and includes a runtime validation gate. Re-run `/configure` any time organizational reality changes — no need to re-run `/setup`.

package/reference/claude-config/skills/status/SKILL.md

@@ -20,10 +20,9 @@ Run in parallel:
 3. `pnpm test` - test results
 4. `pnpm lint` - type check
 
-### Step 2: Check Docs + Active Work
+### Step 2: Check Active Work
 
-1. Read `docs/index.md` - verify doc structure is current
-2. Query active project work via `pnpm -C operations exec elevasis-sdk project:list --status active,blocked --format brief` - active project/task count lives in the DB, not in `docs/in-progress/`
+1. Query active project work via `pnpm elevasis-sdk project:list --status active --pretty` and `pnpm elevasis-sdk project:list --status blocked --pretty` - active project/task count lives in the DB
 
 ### Step 3: Report
 

package/reference/claude-config/skills/submit-request/SKILL.md

@@ -154,7 +154,7 @@ Once confirmed (or `--auto`), write the assembled JSON body to a temp file then
 # Write the report body to a temp file
 # (Use the Write tool to create request-report.json at the project root)
 
-pnpm exec elevasis-sdk request:submit --input-file ./request-report.json --pretty
+pnpm elevasis-sdk request:submit --input-file ./request-report.json --pretty
 ```
 
 Delete the temp file after submission succeeds or fails.

package/reference/deployment/command-center.mdx

@@ -14,7 +14,6 @@ The Command Center is the browser UI for interacting with deployed resources. Af
 | -------------------------------------------------- | -------------- | ----------------------- |
 | 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` |
@@ -147,22 +146,6 @@ const task = await approval.create({
 
 ---
 
-## 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.
-
-> **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.

package/reference/framework/project-structure.mdx

@@ -45,7 +45,7 @@ Cross-runtime types, schemas, constants, and organization-model configuration sh
 
 ### `operations/elevasis.config.ts`
 
-Project-level configuration. The scaffolded file includes commented-out options (`defaultStatus`, `dev.port`) and sets `docsDir` to point at the workspace-level `docs/` directory:
+Project-level configuration. The scaffolded file includes commented-out options (`defaultStatus`, `dev.port`):
 
 ```ts
 import type { ElevasConfig } from '@elevasis/sdk'
@@ -53,13 +53,9 @@ import type { ElevasConfig } from '@elevasis/sdk'
 export default {
   // defaultStatus: 'dev',     // Default status for new resources ('dev' | 'prod')
   // dev: { port: 5170 },      // Local API port (internal development only)
-
-  docsDir: '../docs' // Scan the template's top-level docs/ directory
 } satisfies ElevasConfig
 ```
 
-The `docsDir` option (relative to CWD) overrides where the CLI scans for documentation files. Use `false` to disable documentation scanning entirely.
-
 ---
 
 ## Documentation