@descix/cli 1.0.1 → 1.0.3

package/README.md

@@ -21,12 +21,15 @@ npm install -g @descix/cli
     ```
     This will guide you through connecting your Google Drive and setting up your local environment.
 
-    **Development Mode**:
-    If you are developing locally or against a test environment, you can use the `--dev` flag:
+    **Choosing an environment**:
+    The `--dev` flag has been REMOVED. Its absence silently meant production, so the most common
+    invocation targeted PROD without saying so. Name the environment instead:
     ```bash
-    npx descix setup --dev
+    descix config init --env dev      # or demo, or prod
     ```
-    This defaults to `https://localhost:4000` unless configured otherwise.
+    An unconfigured workspace resolves to the declared default, PROD, and every network-bound
+    command prints the environment, origin and source it resolved on stderr. For a local backend,
+    name the URL: `descix config set-env dev --url https://localhost:4000`.
 
 3.  **Check your status**:
     ```bash
@@ -90,6 +93,42 @@ For apps managed via CLI (Git Mode), use the following commands to process your
 1.  Create your App in the PWA (Workspace Builder).
 2.  Run `descix setup` to hydrate your local folder structure.
 
+## Airdrop Admin Operations (WS-ADMIN-B1)
+
+Admin-only commands for triggering airdrop migration batch runs. Per CEO-D-MANUAL-TRIGGER-NO-CRON (2026-04-20), Cloud Scheduler cron was dropped from Round B in favor of operator-invoked manual triggers via this CLI.
+
+**Access:** requires platform-admin membership (enforced server-side via `isPlatformAdmin(user)`).
+
+### `descix airdrop execute-queue`
+
+Manually trigger the server-side `airdrop_execute_queue` command on the target environment. Assembles `pending_migrations` rows into per-community batches and (when `BATCH_UPDATE_BALANCES_BROADCAST_ENABLED=true`) broadcasts to the Powch HD wallet. When the broadcast flag is off (default for DEV), batches are assembled but the downstream Powch handler returns `stopped_at_broadcast_boundary` — useful for verifying queue shape without spending MATIC.
+
+**Options:**
+
+- `--batch-size <n>`: Cap on users processed this run (server caps at `AIRDROP_MAX_RUN_USERS`; a larger `--batch-size` is clamped).
+- `--dry-run`: Assemble batches but skip the broadcast call entirely. Emits an `on_chain_log` row with `status: dry_run` for audit.
+
+**Examples:**
+
+```bash
+# Dry run against DEV — safe to run repeatedly; no broadcast, no MATIC
+descix airdrop execute-queue --env dev --dry-run
+
+# Execute a capped real run (10 users max this invocation)
+descix airdrop execute-queue --env dev --batch-size 10
+
+# Execute a full queue run (still gated by BATCH_UPDATE_BALANCES_BROADCAST_ENABLED)
+descix airdrop execute-queue --env dev
+```
+
+**Audit trail:** every invocation (dry-run or real) writes one `on_chain_log` row with `op.kind = "airdrop_execute_queue_trigger"` and `caller.operator_email = <invoking admin email>`.
+
+**Testing:**
+
+```bash
+cd DeSciX_Core/descix-cli && npm test
+```
+
 ## Documentation
 
 For full documentation, please refer to the [DeSciX SDK Documentation](../../SERVICE_README_sdk.md).

package/agent-assets/guides/README.md

@@ -34,7 +34,7 @@ Does the user need a public website?
 ### Knowledge-Only
 - Just docs/content for RAG search
 - No `site/` or `microservice/` folders needed
-- Commands: `descix kb pull/push/chunk/sync`
+- Commands: `descix drive pull` / `descix drive push` / `descix kb corpus sync`
 
 ### Static Site
 - Built HTML/CSS/JS deployed to CDN
@@ -49,7 +49,7 @@ Does the user need a public website?
 ### Dynamic Site
 - SSR app where microservice serves the site
 - Everything in `microservice/` (no separate `site/`)
-- Commands: `descix deploy service`
+- Commands: `descix microservice deploy` (ADMIN/LOCAL only — public deploy is not open yet)
 
 ## Two-Tier Template System
 

package/agent-assets/guides/dynamic-site-pattern.md

@@ -33,23 +33,32 @@ my-dynamic-app/
 ├── site/
 │   └── README.md               # "Site served by microservice"
 ├── microservice/
+│   ├── app.js                  # Entry point (from the scaffold)
 │   ├── manifest.json
 │   ├── SERVICE_README_myapp.md
 │   ├── package.json
 │   ├── Dockerfile
 │   ├── app.yaml
-│   └── src/
-│       ├── index.js
-│       ├── pages/              # SSR routes
-│       │   ├── index.js
-│       │   └── dashboard.js
-│       ├── api/                # API routes
-│       │   └── ...
-│       └── views/              # Templates
-│           └── ...
+│   ├── services/               # From the scaffold — NOT src/
+│   │   ├── utils.js            # Config bootstrap over @descix/cloud-core
+│   │   ├── apiFront.js
+│   │   └── commandHandlers/
+│   ├── pages/                  # YOU add these: SSR routes
+│   │   ├── index.js
+│   │   └── dashboard.js
+│   ├── api/                    # YOU add these: API routes
+│   │   └── ...
+│   └── views/                  # YOU add these: templates
+│       └── ...
 └── package.json
 ```
 
+The first group comes from the scaffold and should not be reshaped: `app.js` is the entry
+point and service code lives under `services/` — **there is no `src/` directory**. The
+`pages/`, `api/` and `views/` directories are yours; the layout inside them is your call.
+Keeping the scaffold's shape is what lets the service keep inheriting platform behaviour
+(see `guides/microservice-pattern.md`).
+
 ## Configuration (`workspace.json`)
 
 ```json
@@ -79,15 +88,15 @@ descix microservice init
 
 # 2. Add SSR routes to your service
 
-# 3. Deploy to Cloud Run
-descix deploy service
+# 3. Deploy to Cloud Run  (ADMIN/LOCAL ONLY — see note below)
+descix microservice deploy
 
 # 4. Register and vectorize
 descix microservice register
 descix microservice vectorize
 
 # 5. Sync KB
-descix kb sync -c <community> -a <app>
+descix kb corpus sync -c <community> -a <app>
 ```
 
 ## Capabilities
@@ -120,6 +129,12 @@ descix kb sync -c <community> -a <app>
 Dynamic sites deploy to Google Cloud Run as a single container. The service handles both API requests and page rendering.
 
 ```bash
-# Deploy the microservice (includes site)
-descix deploy service
+# Deploy the microservice (includes site)  — ADMIN/LOCAL ONLY
+descix microservice deploy
 ```
+
+> **`descix microservice deploy` is not open to every developer yet.** Its own help
+> marks it `[ADMIN/LOCAL]` — it shells out to the platform deploy script — and the
+> CLI states that public MCP deploy is "coming soon". If you are not a platform
+> admin, expect this step to fail on permissions rather than on your code. Build and
+> run locally with `descix serve` until the public path lands.

package/agent-assets/guides/knowledge-only-pattern.md

@@ -57,22 +57,22 @@ my-docs/
 
 ```bash
 # 1. Pull content from Drive (if any)
-descix kb pull -c <community> -a <app>
+descix drive pull -c <community> -a <app>
 
 # 2. Add local files to staging
 cp my-new-doc.pdf kb/staging/
 
 # 3. Push to Drive (converts to text)
-descix kb push -c <community> -a <app>
+descix drive push -c <community> -a <app>
 
 # 4. Pull converted text back
-descix kb pull -c <community> -a <app>
+descix drive pull -c <community> -a <app>
 
 # 5. Chunk for RAG
-descix kb chunk -c <community> -a <app>
+descix kb corpus sync -c <community> -a <app>
 
 # 6. Sync to Pinecone
-descix kb sync -c <community> -a <app>
+descix kb corpus sync -c <community> -a <app>
 ```
 
 ## Capabilities

package/agent-assets/guides/microservice-pattern.md

@@ -33,19 +33,56 @@ my-service/
 ├── site/                       # Optional frontend
 │   └── ...
 ├── microservice/
+│   ├── app.js                  # Entry point — binds the server, mounts the router
 │   ├── manifest.json           # Command registration
 │   ├── SERVICE_README_myapp.md # Tool discovery docs
 │   ├── package.json
 │   ├── Dockerfile
 │   ├── app.yaml
-│   └── src/
-│       ├── index.js
+│   ├── defaults-config.json    # Layered config: committed defaults
+│   ├── defaults-config-dev.json
+│   ├── scripts/
+│   │   └── register.js         # Registers the service MANIFEST (commands) for discovery
+│   └── services/
+│       ├── utils.js            # Config bootstrap — see below, read this first
 │       ├── apiFront.js
+│       ├── mcpClient.js
 │       └── commandHandlers/
 │           └── myCommands.js
 └── package.json
 ```
 
+## The bootstrap — why a service inherits instead of implements
+
+**Read `services/utils.js` before you write a line of your own.** It is a thin wrapper
+over `@descix/cloud-core` (`createCloudConfig`, `getCloudConfig`, `initializeCloudConfig`)
+and it carries the layered config chain — environment, then `.env`, then
+`workspace.json` — along with Secret Manager resolution and dev port detection. `app.js`
+reaches it through `initializeServiceConfig`.
+
+Its own header states the rule, and the rule is the point:
+
+> This is the ONLY path to config values. Never use process.env directly.
+> Never add fallback values to utils.CONFIG_VALUE — nulls surface misconfigurations.
+
+That is not house style. It is what makes a service **inherit** its platform behaviour
+rather than reimplement it: a service that bootstraps correctly gets the shared
+infrastructure for free, and a service that hand-rolls its own config or reads
+`process.env` opts itself out of it silently — nothing fails at startup, and the gap
+only shows up later, in the environment where it matters.
+
+**This is also why your service is called at its own Cloud Run instance rather than
+through an extra hop at the DeSciX router** (CEO-D-2026-08-21-DIRECT-MICROSERVICE-ROUTING-IS-DESIGN).
+Direct routing is the intended path *because* a service built on the SDK already carries
+the infrastructure the extra hop would otherwise have to add. Read a direct call as the
+architecture working, not as a bypass — the correctness precondition is that the service
+was built this way.
+
+The corollary is worth stating plainly: **correct bootstrap usage is self-enforcing and
+self-extending.** Services that inherit gain new platform behaviour as the SDK gains it.
+A service that forked the mechanism keeps whatever it forked, forever, and no one finds
+out until something depends on the difference.
+
 ## Configuration (`workspace.json`)
 
 ```json
@@ -75,16 +112,23 @@ descix microservice init
 
 # 2. Implement your commands in commandHandlers/
 
-# 3. Register service with gateway
+# 3. Publish the service MANIFEST so its commands are discoverable
 descix microservice register
 
 # 4. Vectorize SERVICE_README for discovery
 descix microservice vectorize
 
 # 5. Sync KB
-descix kb sync -c <community> -a <app>
+descix kb corpus sync -c <community> -a <app>
 ```
 
+**What registration is, and is not.** It publishes your `manifest.json` — the command list —
+so `tell_me_how` can discover your tools. `scripts/register.js` writes that manifest and logs
+the commands it published. It is a DISCOVERY step.
+
+It is not how your service becomes reachable, and nothing here asks you to declare a route or
+a URL. Do not read this step as wiring up addressing.
+
 ## Capabilities
 
 | Capability | Enabled |

package/agent-assets/guides/static-site-pattern.md

@@ -34,6 +34,8 @@ my-site/
 │   ├── index.html
 │   ├── styles.css
 │   ├── app.js
+│   ├── DeSciXAppSDK.js         # The DeSciX bridge — GENERATED, see below
+│   ├── README.md
 │   └── dist/                   # Build output (if using bundler)
 ├── src/                        # Source files (not deployed)
 │   └── ...
@@ -104,6 +106,12 @@ This copies the site template with:
 - `index.html` - Main entry point
 - `styles.css` - Basic styling
 - `app.js` - Client-side JavaScript
+- `DeSciXAppSDK.js` - The DeSciX bridge: reaches `DeSciX.view`, `DeSciX.chat` and the rest
+  of the shell's bus, resolving the frame level for you. **Do not hand-edit it.** It is
+  GENERATED from `descix-app-sdk/templates/DeSciXAppSDK.template.js`, which inlines the one
+  owner of level detection (`descix-app-sdk/src/util/bridgeResolver.js`); a `--check` drift
+  gate keeps the copies identical. Edit the template, regenerate — a local patch forks the
+  bridge and silently stops inheriting its fixes.
 - `README.md` - Usage instructions
 
 ## Deployment

package/agent-assets/instructions/app-asset-validation.md

@@ -124,7 +124,7 @@ This app does not yet have a web UI.
 ## To Add a Site
 1. Add HTML/CSS/JS files directly here, OR
 2. Configure your build tool to output to `site/dist/`
-3. Run `descix update site` to deploy
+3. Run `descix site upload` to deploy
 
 ## Supported Content
 - Static HTML files
@@ -334,7 +334,7 @@ This folder doesn't appear to be configured as a DeSciX app.
 
 Options:
 1. Run `descix init` to configure this folder as a new app
-2. Run `descix setup` to configure the entire workspace
+2. Run `descix mcp quickstart` to configure the entire workspace
 3. Check if this is the correct folder
 
 Which would you like to do?
@@ -366,7 +366,7 @@ Please check:
 
 ## Integration with Workflows
 
-### Before `descix update app`
+### Before `descix app sync-assets`
 
 Always run validation:
 1. Check `assets/` folder structure
@@ -374,14 +374,14 @@ Always run validation:
 3. Warn about missing icon
 4. Confirm app_description has meaningful content
 
-### Before `descix update kb`
+### Before `descix kb corpus sync`
 
 1. Check `kb/General/` exists
 2. Verify at least one document exists
 3. Warn if no README.md
 4. Report total document count and size
 
-### Before `descix update site`
+### Before `descix site upload`
 
 1. Check `site/` exists
 2. Verify either index.html or dist/index.html exists

package/agent-assets/instructions/onboarding-flow.md

@@ -264,7 +264,7 @@ Created:
 ✓ site/README.md (placeholder)
 ✓ microservice/README.md (placeholder)
 
-Your app structure is now ready. Run `descix update app` to sync.
+Your app structure is now ready. Run `descix app sync-assets` to sync.
 ```
 
 ## Key Principles
@@ -300,10 +300,10 @@ Once configured, guide user to:
 
 ### Sync Commands (in order)
 
-1. **Sync app assets**: `descix update app`
+1. **Sync app assets**: `descix app sync-assets`
    - Uploads app_description.md, icon.png, system_instructions.md to Drive
    
-2. **Sync knowledge base**: `descix update kb`
+2. **Sync knowledge base**: `descix kb corpus sync`
    - Indexes documents to Pinecone for RAG
    
 3. **Deploy static site** (if applicable): `descix site upload`
@@ -374,7 +374,7 @@ All done! Your app is configured.
 **What you can do now:**
 - Use `tell_me_how` to discover tools
 - Ask me to sync content when you make changes
-- Run `descix kb sync` to update RAG index
+- Run `descix kb corpus sync` to update RAG index
 
 Anything else I can help with?
 ```

package/agent-assets/instructions/standard-folder-structure.md

@@ -33,12 +33,19 @@ DeSciX uses a "Mono-Repo" style structure where multiple communities and apps ca
 │       │
 │       ├── site/               # Frontend UI (Optional)
 │       │   ├── index.html
-│       │   └── src/
+│       │   ├── styles.css
+│       │   ├── app.js
+│       │   └── DeSciXAppSDK.js # The DeSciX bridge — GENERATED, do not hand-edit
 │       │
 │       └── microservice/       # Backend Logic (Optional)
+│           ├── app.js          # Entry point
 │           ├── Dockerfile
 │           ├── package.json
-│           └── src/
+│           ├── scripts/
+│           └── services/       # NOT src/ — see below
+│               ├── utils.js    # Config bootstrap — read this first
+│               ├── apiFront.js
+│               └── commandHandlers/
 ```
 
 ## Folder Purposes
@@ -61,17 +68,17 @@ Self-contained folder for a single application.
 
 #### `kb/` - Knowledge Base
 The KB folder supports both local-first (Git mode) and Drive-based workflows:
-- **`staging/`**: Place raw files here (PDFs, images) to push them to Drive via `descix kb push`.
-- **`General/`**: The canonical source of text content. Files here are pulled from Drive and converted to Markdown via `descix kb pull`.
-- **`chunks/`**: Processed JSON chunk files ready for vectorization via `descix kb sync`.
+- **`staging/`**: Place raw files here (PDFs, images) to push them to Drive via `descix drive push`.
+- **`General/`**: The canonical source of text content. Files here are pulled from Drive and converted to Markdown via `descix drive pull`.
+- **`chunks/`**: Processed JSON chunk files ready for vectorization via `descix kb corpus sync`.
 
 **CLI-Centric Processing (Git Mode):**
 ```bash
-descix kb push   # Push staging/ -> Drive
-descix kb pull   # Pull Drive -> General/ (converted to markdown)
-descix kb chunk  # Generate chunks from General/ -> chunks/
-descix kb sync   # Push chunks to Pinecone via service layer
-descix kb build  # Convenience: pull → chunk → sync
+descix drive push   # Push staging/ -> Drive
+descix drive pull   # Pull Drive -> General/ (converted to markdown)
+descix kb corpus sync  # Generate chunks from General/ -> chunks/
+descix kb corpus sync   # Push chunks to Pinecone via service layer
+descix kb corpus sync  # Convenience: pull → chunk → sync
 ```
 
 #### `site/` - Frontend
@@ -81,7 +88,9 @@ descix kb build  # Convenience: pull → chunk → sync
 #### `microservice/` - Backend
 - Contains the server-side logic.
 - **`Dockerfile`**: Defines the runtime environment.
-- **`src/`**: Source code.
+- **`services/`**: Service code. **There is no `src/` directory** in a scaffolded
+  microservice — the entry point is `app.js` at the root and the code lives under
+  `services/`, with `services/utils.js` as the config bootstrap over `@descix/cloud-core`.
 
 ## Configuration Files
 

package/agent-assets/reference/app-creation.md

@@ -45,7 +45,7 @@ This separation ensures:
 
 **Location:** Google Drive, owned by `dip@descix.net`  
 **SDK Reference:** `DeSciX_Core/descix-cli/templates/drive/`  
-**Template IDs:** Configured in `DeSciX_Cloud/defaults-config.json`
+**Template IDs:** Configured in `DeSciX_Cloud/microservice/defaults-config.json`
 
 ```json
 {
@@ -79,31 +79,53 @@ templates/drive/app/
 
 ### Git Scaffolds
 
-**Location:** `DeSciX_Core/descix-cli/templates/scaffolds/`
+**Location:** microservice — `DeSciX_Core/descix-cli/templates/scaffolds/`;
+site — `DeSciX_Core/descix-app-sdk/scaffold/` (owned there, and exported as `SITE_SCAFFOLD_DIR`
+from `@descix/app-sdk/scaffold`, so no caller re-derives the path).
 
 **Site Scaffold:**
 ```
-templates/scaffolds/site/
+descix-app-sdk/scaffold/site/
 ├── index.html        # Entry point
 ├── styles.css        # Basic styling
 ├── app.js            # Client-side JavaScript
+├── DeSciXAppSDK.js   # The DeSciX bridge — GENERATED, do not hand-edit
 └── README.md         # Usage instructions
 ```
 
+`DeSciXAppSDK.js` ships IN the scaffold; it is not something you add afterwards. It is
+generated from `descix-app-sdk/templates/DeSciXAppSDK.template.js` (which inlines
+`descix-app-sdk/src/util/bridgeResolver.js`, the one owner of frame-level detection) and a
+`--check` drift gate keeps the copies identical. Patch the template and regenerate — never
+the copy.
+
 **Microservice Scaffold:**
 ```
 templates/scaffolds/microservice/
+├── app.js                      # Entry point — binds the server, mounts the router
 ├── package.json
 ├── Dockerfile
 ├── app.yaml
 ├── manifest.json
-├── SERVICE_README_TEMPLATE.md
-└── src/
-    ├── index.js
-    ├── apiFront.js
-    └── utils.js
+├── defaults-config.json        # Layered config: committed defaults
+├── defaults-config-dev.json
+├── setup-schema.json
+├── SERVICE_README_sdk.md
+├── scripts/
+│   └── register.js             # Registers the service MANIFEST (commands) for discovery
+├── services/
+│   ├── utils.js                # Config bootstrap over @descix/cloud-core — read first
+│   ├── apiFront.js
+│   ├── mcpClient.js
+│   └── commandHandlers/
+└── templates/
+    └── SERVICE_README_TEMPLATE.md
 ```
 
+There is no `src/` directory. The entry point is `app.js` at the root and the service code
+lives under `services/`. See `guides/microservice-pattern.md` for why `services/utils.js` is
+the file to open first.
+
 ### Adding Scaffolds to Apps
 
 After an app is created via PWA, add code scaffolds via CLI:
@@ -232,7 +254,7 @@ The PWA Workspace Builder allows users to configure which apps to sync to their
 ### Setup Command
 
 ```bash
-descix setup [--dev]
+descix mcp quickstart
 ```
 
 **Flow:**
@@ -272,10 +294,10 @@ After initial setup, users can hydrate specific apps:
 
 ```bash
 # Pull entire app from Drive
-descix kb pull -c community -a app
+descix drive pull -c community -a app
 
 # Or use the build command for full pipeline
-descix kb build
+descix kb corpus sync
 ```
 
 ---
@@ -352,15 +374,15 @@ The CLI does not create apps directly. Users should:
 
 1. Go to PWA dashboard
 2. Create app/community
-3. Run `descix setup` or `descix login --setup` to hydrate
+3. Run `descix mcp quickstart` or `descix login --setup` to hydrate
 
 ### Post-Creation Commands
 
 ```bash
 # After app is created via PWA:
-descix setup --dev            # Hydrate workspace (first time)
-descix kb build               # Pull, chunk, sync KB
-descix sync site              # Deploy static site
+descix mcp quickstart                  # Hydrate workspace (first time)
+descix kb corpus sync               # Pull, chunk, sync KB
+descix site upload -a app   # Deploy static site
 ```
 
 ---
@@ -369,13 +391,13 @@ descix sync site              # Deploy static site
 
 | Component | Path | Description |
 |-----------|------|-------------|
-| Community Management | `DeSciX_Cloud/services/communityManagement.js` | Community/App creation |
-| App Commands | `DeSciX_Cloud/services/commandHandlers/appCommands.js` | Server-side app ops |
-| Google Storage Service | `DeSciX_Cloud/services/googleStorageService.js` | Drive/GCS operations |
-| Template Config | `DeSciX_Cloud/defaults-config.json` | Template folder IDs |
+| Community Management | `DeSciX_Cloud/microservice/services/communityManagement.js` | Community/App creation |
+| App Commands | `DeSciX_Cloud/microservice/services/commandHandlers/appCommands.js` | Server-side app ops |
+| Google Storage Service | `DeSciX_Cloud/microservice/services/googleStorageService.js` | Drive/GCS operations |
+| Template Config | `DeSciX_Cloud/microservice/defaults-config.json` | Template folder IDs |
 | Drive Templates | `DeSciX_Core/descix-cli/templates/drive/` | Content templates |
 | Git Scaffolds | `DeSciX_Core/descix-cli/templates/scaffolds/` | Code scaffolds |
 | Hydrator | `DeSciX_Core/descix-cli/lib/core/Hydrator.js` | Workspace hydration |
 | WorkspaceConfig | `DeSciX_Core/descix-cli/lib/workspace-config.js` | CLI configuration |
-| Setup Command | `DeSciX_Core/descix-cli/lib/commands/setup.js` | Initial setup |
+| Setup Command | `DeSciX_Core/descix-cli/lib/wizard/setup.js` | Initial setup |
 | Scaffold Command | `DeSciX_Core/descix-cli/bin/descix.js` | CLI scaffolds |

package/agent-assets/reference/architecture.md

@@ -122,9 +122,11 @@ All core SDK logic resides in `DeSciX_Core/descix-cli/lib/core/`.
 │       ├── research.chunks.json
 │       └── notes.chunks.json
 ├── site/                       # Static site files (push-only)
-│   └── index.html
+│   ├── index.html
+│   └── DeSciXAppSDK.js         # The DeSciX bridge (generated)
 └── microservice/               # Service code (push-only)
-    └── src/index.js
+    ├── app.js                  # Entry point
+    └── services/               # Service code — there is no src/
 ```
 
 ### Folder Purposes
@@ -186,10 +188,10 @@ These commands auto-detect app context from `workspace.json` based on the curren
 | Command | Description |
 |---------|-------------|
 | `descix update` | Auto-detect what to update based on current folder |
-| `descix update app` | Sync app assets (icon, description, instructions) to Drive |
-| `descix update kb` | Full three-stage sync (Local → Drive → GCS → Pinecone) |
-| `descix update site` | Deploy CodeSite to GCS |
-| `descix update all` | Update all resources (App, KB, Site) in sequence |
+| `descix app sync-assets` | Sync app assets (icon, description, instructions) to Drive |
+| `descix kb corpus sync` | Full three-stage sync (Local → Drive → GCS → Pinecone) |
+| `descix site upload` | Deploy CodeSite to GCS |
+| ~~`descix update all`~~ | **Deleted.** There is no single all-resources verb. Run the three canonical commands: `descix app sync-assets`, `descix kb corpus sync`, `descix site upload`. |
 
 ### 4.2 KB Processing Commands (`descix kb`)
 
@@ -197,12 +199,12 @@ These commands provide granular control over the V2 local-first pipeline.
 
 | Command | Description |
 |---------|-------------|
-| `descix kb pull` | Download from Drive, convert to text in `kb/General/` |
-| `descix kb push` | Upload files from `kb/staging/` to Drive |
-| `descix kb chunk` | Generate JSON chunks from `kb/General/` to `kb/chunks/` |
-| `descix kb sync` | Push chunks to Pinecone via backend API |
-| `descix kb build` | Convenience: pull → chunk → sync |
-| `descix kb status` | Show sync status (local vs Pinecone) |
+| `descix drive pull` | Download from Drive, convert to text in `kb/General/` |
+| `descix drive push` | Upload files from `kb/staging/` to Drive |
+| `descix kb corpus sync` | Generate JSON chunks from `kb/General/` to `kb/chunks/` |
+| `descix kb corpus sync` | Push chunks to Pinecone via backend API |
+| `descix kb corpus sync` | Convenience: pull → chunk → sync |
+| `descix kb corpus status` | Show sync status (local vs Pinecone) |
 
 ### Scaffold Commands
 
@@ -229,7 +231,7 @@ These commands provide granular control over the V2 local-first pipeline.
 ### Setup Command
 
 ```bash
-descix setup [--dev]
+descix mcp quickstart
 ```
 
 Flow:
@@ -318,15 +320,15 @@ flowchart LR
 ### Detailed Flow
 
 1. **Stage:** User adds `paper.pdf` to `kb/staging/`
-2. **Push:** `descix kb push` uploads to Drive `kb/General/`
-3. **Pull:** `descix kb pull` downloads and converts:
+2. **Push:** `descix drive push` uploads to Drive `kb/General/`
+3. **Pull:** `descix drive pull` downloads and converts:
    - Sees `paper.pdf` in Drive
    - Copies with `convert=true` → temp Google Doc
    - Exports as Markdown → `kb/General/paper.md`
    - Deletes temp doc
-4. **Chunk:** `descix kb chunk` processes `paper.md`:
+4. **Chunk:** `descix kb corpus sync` processes `paper.md`:
    - Generates `kb/chunks/paper.chunks.json`
-5. **Sync:** `descix kb sync` pushes to backend:
+5. **Sync:** `descix kb corpus sync` pushes to backend:
    - Backend validates metadata
    - Forwards to Pinecone
    - Pinecone embeds and stores
@@ -345,7 +347,7 @@ gcloud auth application-default login \
 ```
 
 **Verification:**
-- `descix setup` checks ADC before proceeding
+- `descix mcp quickstart` checks ADC before proceeding
 - `Hydrator` calls `verifyDriveAuth()` before operations
 
 ### Backend Authentication
@@ -399,8 +401,8 @@ Both modes start with content on Google Drive (users create documents there). Th
 | Chunker | `DeSciX_Core/descix-cli/lib/core/Chunker.js` | KB chunking |
 | Syncer | `DeSciX_Core/descix-cli/lib/core/Syncer.js` | Pinecone sync |
 | KB Commands | `DeSciX_Core/descix-cli/lib/commands/kb.js` | Git-mode KB processing |
-| Setup Command | `DeSciX_Core/descix-cli/lib/commands/setup.js` | Initial workspace setup |
+| Setup Command | `DeSciX_Core/descix-cli/lib/wizard/setup.js` | Initial workspace setup |
 | Drive ADC | `DeSciX_Core/descix-cli/lib/google-storage-adc.js` | Google Drive API wrapper |
-| Backend KB API | `DeSciX_Cloud/services/commandHandlers/appCommands.js` | Server-side processing |
-| Pinecone Service | `DeSciX_Cloud/services/pineconeService.js` | Vector database |
-| Server Chunking | `DeSciX_Cloud/services/chunkingUtils.js` | Drive-mode chunking |
+| Backend KB API | `DeSciX_Cloud/microservice/services/commandHandlers/appCommands.js` | Server-side processing |
+| Pinecone Service | `DeSciX_Cloud/microservice/services/pineconeService.js` | Vector database |
+| Server Chunking | `DeSciX_Cloud/microservice/services/chunkingUtils.js` | Drive-mode chunking |