@elevasis/sdk 1.7.0 → 1.8.1

package/reference/claude-config/settings.json

@@ -4,17 +4,6 @@
     "command": "node .claude/scripts/statusline-command.js"
   },
   "hooks": {
-    "PreToolUse": [
-      {
-        "matcher": "Write|Edit|MultiEdit",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node .claude/hooks/pre-edit-vibe-gate.mjs"
-          }
-        ]
-      }
-    ],
     "PostToolUse": [
       {
         "matcher": "Write|Edit|MultiEdit",
@@ -22,6 +11,10 @@
           {
             "type": "command",
             "command": "node .claude/hooks/post-edit-validate.mjs"
+          },
+          {
+            "type": "command",
+            "command": "node .claude/hooks/scaffold-registry-reminder.mjs"
           }
         ]
       }

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

@@ -22,8 +22,6 @@ Recurring, safe-to-re-run org model editor for external projects. Reads the orga
 - `/configure features` -- Enable, disable, or add features; Level A (defaults) or Level B (new extension TS files)
 - `/configure labels` -- Edit inline display labels on enum entries (statuses, stages, categories)
 
-**Distinction from `/org-os manage`:** `/configure` edits structural organizational reality (who the org is, who it serves, what it offers). `/org-os manage` controls feature gating (what platform capabilities are enabled). Use `/configure` for org-model content; use `/org-os manage` for feature flags.
-
 **Distinction from `/setup`:** `/setup` is for first-time bootstrap (placeholder replacement, dependency install, build verification). `/configure` is for recurring org-model updates. After first run, `/setup` delegates here.
 
 ---

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

@@ -7,16 +7,14 @@ items and routes visible; disabling hides them without removing the feature from
 a new feature may require only a config edit (Level A) or a new extension TypeScript file
 (Level B), depending on whether the feature already exists in the platform defaults.
 
-This operation handles both toggling existing features and introducing custom features. For
-surface-level toggles (hiding one sub-section within an already-enabled feature), use
-`/org-os manage` instead.
+This operation handles both toggling existing features and introducing custom features.
 
 ## Background: Level A vs Level B
 
-- **Level A (config-only edit):** The feature exists in the platform defaults
-  (`packages/core/src/organization-model/defaults.ts`). The adapter in
-  `foundations/config/organization-model.ts` overrides its `enabled` flag or adjusts metadata.
-  No new TypeScript files needed.
+- **Level A (config-only edit):** The feature exists in the platform defaults (see
+  `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` for the default feature
+  set). The adapter in `foundations/config/organization-model.ts` overrides its `enabled` flag or
+  adjusts metadata. No new TypeScript files needed.
 
 - **Level B (new extension file):** The feature does not exist in platform defaults. A new
   feature ID and manifest need to be declared. This requires a new TypeScript file under
@@ -25,7 +23,8 @@ surface-level toggles (hiding one sub-section within an already-enabled feature)
 
 ## Schema reference
 
-Source: `packages/core/src/organization-model/domains/features.ts`
+Source: `node_modules/@elevasis/core/organization-model` (published types) or
+`node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` (auto-generated shapes)
 
 ```typescript
 FeatureSchema = z.object({
@@ -42,7 +41,7 @@ FeatureSchema = z.object({
 })
 ```
 
-Platform default feature IDs (from `packages/core/src/organization-model/contracts.ts`):
+Platform default feature IDs (from `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md`):
 `crm`, `lead-gen`, `projects`, `operations`, `monitoring`, `settings`, `seo`
 
 Where this lands in the adapter: `foundations/config/organization-model.ts` under the `features`
@@ -56,8 +55,8 @@ merge), so the adapter must redeclare all features it wants to override.
 ### Step 1: Read current state
 
 Read `foundations/config/organization-model.ts` and extract the current `features` array from the
-adapter. Also read `packages/core/src/organization-model/defaults.ts` to see what the platform
-defaults look like.
+adapter. Also read `node_modules/@elevasis/sdk/reference/scaffold/reference/contracts.md` to see
+what the platform defaults look like.
 
 Present a combined view:
 

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.
@@ -142,7 +132,7 @@ After a successful push, mark any linked project task as `submitted`. This is a
 2. **Fire the transition** (only when a single confident task ID is resolved):
 
    ```bash
-   pnpm -C operations exec elevasis-sdk project:task:update <task-id> --status submitted
+   pnpm elevasis-sdk project:task:update <task-id> --status submitted
    ```
 
 3. **Failure handling.** If the CLI call errors, no task ID can be resolved, or the user declines, emit a single warning line and continue:

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

@@ -40,7 +40,7 @@ For dev vs prod targeting:
 Validate all resource definitions (schemas, contracts, config):
 
 ```bash
-pnpm -C operations exec elevasis-sdk check
+pnpm elevasis-sdk check
 ```
 
 Reports: resource count, validation errors, schema serialization warnings. Exit code 0 = pass.
@@ -49,12 +49,8 @@ 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]
+pnpm elevasis-sdk deploy [--prod]
 ```
 
 Replace `[--prod]` with `--prod` when targeting production.
@@ -72,10 +68,10 @@ Deploy replaces the previous active deployment. Resources become executable imme
 **Always run before executing.** Shows resource metadata, input/output schemas, and step chain:
 
 ```bash
-pnpm -C operations exec elevasis-sdk describe <resourceId>
+pnpm elevasis-sdk describe <resourceId>
 
 # JSON output for programmatic use
-pnpm -C operations exec elevasis-sdk describe <resourceId> --json
+pnpm elevasis-sdk describe <resourceId> --json
 ```
 
 Output includes: type, name, version, status, domains, input schema (required/optional fields with types), output schema, step definitions with entry point and routing.
@@ -86,14 +82,14 @@ Run a deployed resource. **Always `describe` first to see the input schema.**
 
 ```bash
 # Simple input (inline JSON)
-pnpm -C operations exec elevasis-sdk exec <resourceId> -i '{"key": "value"}'
+pnpm elevasis-sdk exec <resourceId> -i '{"key": "value"}'
 
 # Complex input (temp file -- PREFERRED for non-trivial payloads)
 # Write input to a temp file first, then reference it with -f
-pnpm -C operations exec elevasis-sdk exec <resourceId> -f .tmp-input.json
+pnpm elevasis-sdk exec <resourceId> -f .tmp-input.json
 
 # Async execution (for long-running workflows -- polls until complete)
-pnpm -C operations exec elevasis-sdk exec <resourceId> -f .tmp-input.json --async
+pnpm elevasis-sdk exec <resourceId> -f .tmp-input.json --async
 ```
 
 **When to use `-f` (file input):**
@@ -122,10 +118,10 @@ pnpm -C operations exec elevasis-sdk exec <resourceId> -f .tmp-input.json --asyn
 View all deployed resources:
 
 ```bash
-pnpm -C operations exec elevasis-sdk resources
+pnpm elevasis-sdk resources
 
 # JSON output
-pnpm -C operations exec elevasis-sdk resources --json
+pnpm elevasis-sdk resources --json
 ```
 
 Shows: resource ID, type (workflow/agent), name, description, status.
@@ -136,19 +132,19 @@ View past executions for a resource:
 
 ```bash
 # List recent executions (default: last 50)
-pnpm -C operations exec elevasis-sdk executions <resourceId>
+pnpm elevasis-sdk executions <resourceId>
 
 # Filter by status
-pnpm -C operations exec elevasis-sdk executions <resourceId> --status failed --limit 10
+pnpm elevasis-sdk executions <resourceId> --status failed --limit 10
 
 # View specific execution (full detail with logs)
-pnpm -C operations exec elevasis-sdk execution <resourceId> <executionId>
+pnpm elevasis-sdk execution <resourceId> <executionId>
 
 # Logs only (skip metadata)
-pnpm -C operations exec elevasis-sdk execution <resourceId> <executionId> --logs-only
+pnpm elevasis-sdk execution <resourceId> <executionId> --logs-only
 
 # Include input and result data
-pnpm -C operations exec elevasis-sdk execution <resourceId> <executionId> --input --result
+pnpm elevasis-sdk execution <resourceId> <executionId> --input --result
 ```
 
 **`executions` flags:** `--limit <n>` (default 50), `--status running|completed|failed`, `--json`
@@ -162,7 +158,7 @@ Execution detail shows: status, start/end times, duration, input, result, error
 View deployment history:
 
 ```bash
-pnpm -C operations exec elevasis-sdk deployments
+pnpm elevasis-sdk deployments
 ```
 
 Shows: deployment ID, SDK version, status (active/deploying/failed/stopped), created timestamp.
@@ -173,19 +169,19 @@ Manage integration credentials (API keys, webhook secrets):
 
 ```bash
 # List credentials (metadata only, secrets not exposed)
-pnpm -C operations exec elevasis-sdk creds list
+pnpm elevasis-sdk creds list
 
 # Create a credential
-pnpm -C operations exec elevasis-sdk creds create --name my-api-key --type api-key --value '{"apiKey":"sk-..."}'
+pnpm elevasis-sdk creds create --name my-api-key --type api-key --value '{"apiKey":"sk-..."}'
 
 # Update a credential value
-pnpm -C operations exec elevasis-sdk creds update my-api-key --value '{"apiKey":"new-key"}'
+pnpm elevasis-sdk creds update my-api-key --value '{"apiKey":"new-key"}'
 
 # Rename a credential
-pnpm -C operations exec elevasis-sdk creds rename old-name --to new-name
+pnpm elevasis-sdk creds rename old-name --to new-name
 
 # Delete a credential
-pnpm -C operations exec elevasis-sdk creds delete my-api-key --force
+pnpm elevasis-sdk creds delete my-api-key --force
 ```
 
 Credential names: lowercase, digits, hyphens only (`^[a-z0-9]+(-[a-z0-9]+)*$`). Types: `api-key`, `webhook-secret`.
@@ -196,10 +192,10 @@ Rename a resource ID across all platform tables:
 
 ```bash
 # Dry run (preview only)
-pnpm -C operations exec elevasis-sdk rename old-id --to new-id
+pnpm elevasis-sdk rename old-id --to new-id
 
 # Apply rename
-pnpm -C operations exec elevasis-sdk rename old-id --to new-id --execute
+pnpm elevasis-sdk rename old-id --to new-id --execute
 ```
 
 Always dry-run first to see affected tables and row counts.
@@ -210,10 +206,10 @@ Mark execution errors as resolved:
 
 ```bash
 # Resolve a specific error
-pnpm -C operations exec elevasis-sdk error resolve <errorId>
+pnpm elevasis-sdk error resolve <errorId>
 
 # Resolve all errors for an execution
-pnpm -C operations exec elevasis-sdk error resolve-execution <executionId>
+pnpm elevasis-sdk error resolve-execution <executionId>
 ```
 
 ## Standard Workflow

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

@@ -35,6 +35,38 @@ allowed-tools: Bash, Read, Write, Edit, Glob, Grep
 - `/project checklist <client> "<milestone>"` — View checklist for a milestone.
 - `/project delete <client>` — Delete project (cascades milestones, tasks, notes).
 
+---
+
+## Ambient Vibe Integration
+
+This skill is the landing point for three of the seven vibe intent types. Agents arriving from the ambient layer should behave identically to a direct invocation — vibe is a classifier, not a different code path.
+
+| Vibe intent | What vibe detected | What to do here |
+|---|---|---|
+| **Capture** | "add a task", "remember to", "track this" | Draft the task/note, confirm with user, then `project:task:create` or `project:note:create` |
+| **Transition** | "done", "stuck", "blocked", "finished" | Resolve current task from session context, confirm status, then `project:task:update --status <new>` |
+| **Navigate** | "focus on", "switch to", "back to" | Resolve target via `project:resolve <query>` or `project:work <query>`, update scope, narrate new context |
+
+**The full continuity loop** — how work flows across sessions:
+
+```
+vibe (Capture) → /project task:create → task in DB
+                         ↓
+                    work happens
+                         ↓
+              /save → project:task:save → prj_tasks.resume_context
+                         ↓
+              next session: /project work <query>
+                         ↓
+              project:work → resume brief (current state + next steps)
+                         ↓
+              agent picks up exactly where it left off
+```
+
+When a session begins with an ambiguous opening, check `project:work` before asking the user to re-explain. The resume brief is the canonical continuity payload — trust it.
+
+---
+
 ## Prerequisites
 
 **Run from the project root** (the directory containing `.elevasis`). Before issuing any other commands, run:
@@ -317,7 +349,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

@@ -19,7 +19,7 @@ Auto-manage project documentation from conversation context, and fan out convers
 
 Before doing anything else, determine the active project / task:
 
-1. Look for an active task-doc frontmatter in the current conversation or the most recently edited file under `docs/`. Expected frontmatter:
+1. Look for an active task-doc frontmatter in the current conversation or the most recently edited file. Expected frontmatter:
 
    ```yaml
    ---
@@ -56,7 +56,7 @@ Review the current conversation to identify:
 
 ### Step 3: Update Knowledge Docs
 
-Scan `docs/` for unindexed or stale knowledge docs and draft creates / updates / moves. All edits are on knowledge/architecture/feature docs -- NOT on task resume state (that flows to the DB in Step 4).
+Scan for unindexed or stale knowledge docs and draft creates / updates / moves. This template does not have a `docs/` tree — look for any local knowledge files (`.claude/rules/`, `operations/src/README.md`, `foundations/`, or project-specific docs the user has created). All edits are on knowledge/architecture/feature docs -- NOT on task resume state (that flows to the DB in Step 4).
 
 Determine what needs to happen:
 
@@ -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> \
@@ -159,7 +155,7 @@ If no signal rises to note-worthy, skip this step entirely. Do not create filler
 Run this ONLY when Step 5 created a `blocker` note AND Step 1 resolved a task ID. It's the second half of the "I'm stuck" fanout: the note captures the why, this call flips the task's lifecycle state so it surfaces as blocked in portfolio views.
 
 ```bash
-pnpm -C operations exec elevasis-sdk project:task:update <task-uuid> --status blocked
+pnpm elevasis-sdk project:task:update <task-uuid> --status blocked
 ```
 
 Rules:
@@ -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

@@ -143,29 +143,44 @@ After all replacements, re-scan the four key files from State Detection to verif
 
 If the user skipped any knowledge questions, fill in what was provided and omit what wasn't -- don't leave placeholder text behind.
 
-### Step 5: Create Client Knowledge Doc
+### Step 5: Write Client Brief to Org Model
 
-**Idempotency check:** Check whether `docs/knowledge/client.md` already exists. If it exists and is non-empty, skip this step entirely -- do not overwrite.
+**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.
 
-If it does not exist, create `docs/knowledge/client.md`:
+If the field is empty or absent, compose the client brief from the information gathered in Step 2:
 
 ```markdown
----
-title: Client Context
-description: Company background, industry, stakeholders, and business goals
----
-
-# Client Context
-
 **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
+```
+
+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
@@ -242,8 +257,8 @@ 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.
-- **`docs/knowledge/client.md`** is only created if it does not exist. An existing file is never overwritten by `/setup`.
-- **Org-model fields** (`foundations/config/organization-model.ts`) are never written by `/setup`. All org-model edits go through `/configure`, which has its own diff-preview and confirm ceremony.
+- **`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.
 
 ---
 
@@ -253,7 +268,8 @@ Running `/setup` more than once is safe:
 
 1. Replaces scaffold placeholders (project name, slug, description)
 2. Fills lightweight CLAUDE.md knowledge sections (user and client basics, idempotent)
-3. Installs dependencies and verifies the build
-4. Hands off to `/configure` for org-model configuration
+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 structural org-model editing (identity, 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`.
+`/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

package/reference/packages/ui/src/hooks/README.md

@@ -8,7 +8,7 @@ The hooks barrel is the published headless hook surface for the UI package.
 - Scheduling hooks
 - Monitoring, observability, and notification hooks
 - Session and SSE hooks
-- Operations hooks, including command-view and knowledge-base helpers
+- Operations hooks, including command-view helpers
 - Feature access, table state, and service helpers
 - Acquisition and delivery hooks
 
@@ -21,4 +21,3 @@ The hooks barrel is the published headless hook surface for the UI package.
 ## Notes
 
 - This barrel is intentionally headless. It should not pull in the visual component layer.
-