@vellumai/assistant 0.4.37 → 0.4.41

package/src/config/bundled-skills/twitter/SKILL.md

@@ -5,7 +5,7 @@ user-invocable: true
 metadata: { "vellum": { "emoji": "𝕏" } }
 ---
 
-You are an X (formerly Twitter) assistant. Use the `execute_bash` tool to run `vellum x` CLI commands.
+You are an X (formerly Twitter) assistant. Use the `bash` tool to run `assistant x`, `assistant config`, and `assistant oauth` CLI commands.
 
 ## Connection Options
 
@@ -18,21 +18,21 @@ OAuth uses the official X API v2. It is the most reliable connection method and
 - Supports: **post** and **reply**
 - Read-only operations (timeline, search, home, bookmarks, notifications, likes, followers, following, media) always use the browser path directly, regardless of the strategy setting.
 - Setup: Collect the OAuth Client ID (and optional Client Secret) from the user in chat using `credential_store` with `action: "prompt"` (canonical field names: `client_id`, `client_secret`), then initiate the `twitter_auth_start` flow. See the **First-Use Decision Flow** for the full sequence.
-- Set the strategy: `vellum x strategy set oauth`
+- Set the strategy: `assistant config set twitter.operationStrategy oauth`
 
 ### Browser session (no developer credentials needed)
 
 The browser path is quick to start and useful when the user does not have X developer app credentials. It captures auth cookies from Chrome and uses them to interact with X.
 
 - Supports: **all operations** (post, reply, timeline, search, home, bookmarks, notifications, likes, followers, following, media)
-- Setup: Run `vellum x refresh` to open Chrome and capture session cookies automatically.
-- Set the strategy: `vellum x strategy set browser`
+- Setup: Run `assistant x refresh` to open Chrome and capture session cookies automatically.
+- Set the strategy: `assistant config set twitter.operationStrategy browser`
 
 ### Auto mode (default)
 
 When the strategy is `auto` (the default), the router tries OAuth first for supported operations if credentials are available, then falls back to the browser path. This gives the best of both worlds without requiring manual switching.
 
-- Set auto mode: `vellum x strategy set auto`
+- Set auto mode: `assistant config set twitter.operationStrategy auto`
 
 ## First-Use Decision Flow
 
@@ -41,20 +41,27 @@ When the user triggers a Twitter operation and no strategy has been configured y
 1. **Check current status:**
 
    ```bash
-   vellum x status --json
+   # Check strategy
+   assistant config get twitter.operationStrategy
+
+   # Check if OAuth token is available
+   assistant oauth token twitter --json
+
+   # Check browser session
+   assistant x status --json
    ```
 
-   Look at `oauthConnected`, `browserSessionActive`, `preferredStrategy`, and `strategyConfigured` in the response. If `strategyConfigured` is `false`, the user has not yet chosen a strategy and should be guided through setup.
+   If the strategy is not set, the user has not yet chosen a strategy and should be guided through setup.
 
 2. **Present both options with trade-offs:**
    - **OAuth**: Most reliable and official. Requires X developer app credentials (OAuth Client ID and optional Client Secret). Supports posting and replying. Set up right here in the chat.
-   - **Browser session**: Quick to start, no developer credentials needed. Supports all operations including reading timelines and searching. Set up with `vellum x refresh`.
+   - **Browser session**: Quick to start, no developer credentials needed. Supports all operations including reading timelines and searching. Set up with `assistant x refresh`.
 
 3. **Ask the user which they prefer.** Do not choose for them.
 
 4. **Execute setup for the chosen path:**
    - If OAuth: Collect the credentials in-chat using the secure credential prompt, then connect. Follow the **OAuth Setup Sequence** below.
-   - If browser: Run `vellum x refresh` to capture session cookies from Chrome.
+   - If browser: Run `assistant x refresh` to capture session cookies from Chrome.
 
 ### OAuth Setup Sequence
 
@@ -74,7 +81,7 @@ When the user chooses OAuth, collect their X developer credentials conversationa
 
 5. **Set the preferred strategy:**
    ```bash
-   vellum x strategy set <oauth|browser|auto>
+   assistant config set twitter.operationStrategy <oauth|browser|auto>
    ```
 
 ## Failure Recovery Flow
@@ -91,53 +98,70 @@ When a Twitter operation fails, follow these steps:
 2. **Explain the likely cause clearly** to the user.
 
 3. **Suggest trying the other path as an alternative:**
-   - If the browser session expired: suggest setting up OAuth for post/reply operations, or refresh the browser session with `vellum x refresh`.
-   - If OAuth failed or is not configured: suggest using the browser path with `vellum x strategy set browser` and `vellum x refresh`.
-   - If the operation is unsupported via OAuth: explain that this write operation is not yet supported via OAuth, and suggest using the browser path with `vellum x strategy set browser`.
+   - If the browser session expired: suggest setting up OAuth for post/reply operations, or refresh the browser session with `assistant x refresh`.
+   - If OAuth failed or is not configured: suggest using the browser path with `assistant config set twitter.operationStrategy browser` and `assistant x refresh`.
+   - If the operation is unsupported via OAuth: explain that this write operation is not yet supported via OAuth, and suggest using the browser path with `assistant config set twitter.operationStrategy browser`.
 
 4. **Offer concrete steps to switch:**
 
    ```bash
    # Switch to the other strategy
-   vellum x strategy set <oauth|browser|auto>
+   assistant config set twitter.operationStrategy <oauth|browser|auto>
 
    # If switching to browser, refresh the session
-   vellum x refresh
+   assistant x refresh
    ```
 
 ## Strategy Management Commands
 
 ```bash
 # Check current strategy
-vellum x strategy
+assistant config get twitter.operationStrategy
 
 # Set strategy to OAuth, browser, or auto
-vellum x strategy set <oauth|browser|auto>
+assistant config set twitter.operationStrategy oauth
+assistant config set twitter.operationStrategy browser
+assistant config set twitter.operationStrategy auto
 
 # Check full status (session, OAuth, and strategy info)
-vellum x status --json
+assistant x status --json
 ```
 
 ## Posting
 
+Before posting, fetch the current strategy and OAuth token:
+
 ```bash
-vellum x post "The post text here"
+# 1. Get the configured strategy
+STRATEGY=$(assistant config get twitter.operationStrategy)
+# If not set, default to "auto"
+
+# 2. If strategy is "oauth" or "auto", get a valid OAuth token
+TOKEN=$(assistant oauth token twitter)
 ```
 
-Returns JSON with `ok`, `tweetId`, `text`, `url`, and `pathUsed` fields. The `pathUsed` field indicates whether the post was sent via `oauth` or `browser`. Share the URL with the user so they can verify the post.
+Then post with the fetched values:
+
+```bash
+# With OAuth token (strategy is oauth or auto):
+assistant x post "The post text here" --strategy "$STRATEGY" --oauth-token "$TOKEN"
+
+# With browser-only strategy:
+assistant x post "The post text here" --strategy browser
+```
 
-The `post` command routes through the strategy router: it uses OAuth if configured and available, otherwise falls back to the browser path.
+Returns JSON with `ok`, `tweetId`, `text`, `url`, and `pathUsed` fields. Share the URL with the user so they can verify the post.
 
 ## Replying
 
+Same setup as posting — fetch strategy and token first, then:
+
 ```bash
-vellum x reply <tweetUrl> "The reply text here"
+assistant x reply <tweetUrl> "The reply text here" --strategy "$STRATEGY" --oauth-token "$TOKEN"
 ```
 
 The first argument is a tweet URL (e.g. `https://x.com/user/status/123456`) or a bare tweet ID.
 
-Like `post`, the `reply` command routes through the strategy router and returns a `pathUsed` field.
-
 ## Reading
 
 Read-only operations always use the browser path directly, regardless of the strategy setting. They work the same whether the strategy is `oauth`, `browser`, or `auto` — the strategy only affects `post` and `reply` commands.
@@ -145,7 +169,7 @@ Read-only operations always use the browser path directly, regardless of the str
 ### User timeline
 
 ```bash
-vellum x timeline <screenName> [--count N]
+assistant x timeline <screenName> [--count N]
 ```
 
 Returns `user` and `tweets` array.
@@ -153,7 +177,7 @@ Returns `user` and `tweets` array.
 ### Single tweet + replies
 
 ```bash
-vellum x tweet <tweetIdOrUrl>
+assistant x tweet <tweetIdOrUrl>
 ```
 
 Returns the focal tweet and its reply thread.
@@ -161,25 +185,25 @@ Returns the focal tweet and its reply thread.
 ### Search
 
 ```bash
-vellum x search "query" [--count N] [--product Top|Latest|People|Media]
+assistant x search "query" [--count N] [--product Top|Latest|People|Media]
 ```
 
 ### Home timeline
 
 ```bash
-vellum x home [--count N]
+assistant x home [--count N]
 ```
 
 ### Bookmarks
 
 ```bash
-vellum x bookmarks [--count N]
+assistant x bookmarks [--count N]
 ```
 
 ### Notifications
 
 ```bash
-vellum x notifications [--count N]
+assistant x notifications [--count N]
 ```
 
 Returns `notifications` array with `id`, `message`, `timestamp`, `url`.
@@ -187,14 +211,14 @@ Returns `notifications` array with `id`, `message`, `timestamp`, `url`.
 ### Likes
 
 ```bash
-vellum x likes <screenName> [--count N]
+assistant x likes <screenName> [--count N]
 ```
 
 ### Followers / Following
 
 ```bash
-vellum x followers <screenName> [--count N]
-vellum x following <screenName> [--count N]
+assistant x followers <screenName> [--count N]
+assistant x following <screenName> [--count N]
 ```
 
 Returns `user` and `followers`/`following` array (userId, screenName, name).
@@ -202,7 +226,7 @@ Returns `user` and `followers`/`following` array (userId, screenName, name).
 ### Media
 
 ```bash
-vellum x media <screenName> [--count N]
+assistant x media <screenName> [--count N]
 ```
 
 Returns tweets that contain media from the user's profile.
@@ -213,13 +237,13 @@ Returns tweets that contain media from the user's profile.
 
 When the user asks to check mentions, check X, or see what's happening:
 
-1. Fetch notifications: `vellum x notifications --count 20 --json`
-2. Fetch their recent tweets to see replies: `vellum x timeline <theirScreenName> --count 10 --json`
+1. Fetch notifications: `assistant x notifications --count 20 --json`
+2. Fetch their recent tweets to see replies: `assistant x timeline <theirScreenName> --count 10 --json`
 3. Summarize what needs attention:
    - Group by type: replies to their tweets, likes, new followers, mentions
-   - For anything that looks like it needs a reply, fetch the full thread with `vellum x tweet <tweetId>` to understand context
+   - For anything that looks like it needs a reply, fetch the full thread with `assistant x tweet <tweetId>` to understand context
    - Prioritize: direct questions > mentions > engagement notifications
-4. For items that need replies, draft a response and ask the user to approve before sending with `vellum x reply`
+4. For items that need replies, draft a response and ask the user to approve before sending with `assistant x reply`
 
 Present the summary as a scannable list, not a wall of text. Lead with action items.
 
@@ -227,8 +251,8 @@ Present the summary as a scannable list, not a wall of text. Lead with action it
 
 When the user wants to understand what people are saying about something:
 
-1. Search: `vellum x search "topic" --count 20 --json`
-2. For the most interesting tweets, fetch threads: `vellum x tweet <tweetId>`
+1. Search: `assistant x search "topic" --count 20 --json`
+2. For the most interesting tweets, fetch threads: `assistant x tweet <tweetId>`
 3. Summarize: key themes, notable voices, sentiment, and any emerging consensus
 4. If the user wants to engage, draft a post or reply that adds to the conversation
 
@@ -236,9 +260,9 @@ When the user wants to understand what people are saying about something:
 
 When the user wants to see how their posts are performing:
 
-1. Fetch their recent tweets: `vellum x timeline <screenName> --count 20 --json`
+1. Fetch their recent tweets: `assistant x timeline <screenName> --count 20 --json`
 2. For each tweet, note engagement signals from the text/metadata
-3. Fetch notifications to see who's interacting: `vellum x notifications --count 20 --json`
+3. Fetch notifications to see who's interacting: `assistant x notifications --count 20 --json`
 4. Summarize: which posts got traction, who's engaging, any conversations worth continuing
 
 ## Tips
@@ -248,6 +272,6 @@ When the user wants to see how their posts are performing:
 - All commands return JSON with an `ok` field
 - When drafting replies, match the tone of the conversation — casual threads get casual replies
 - Always show the user what you're about to post and get approval before sending
-- If a browser session is expired, refresh it with `vellum x refresh` before retrying, or suggest switching to OAuth for post/reply operations
-- If an operation fails, check `vellum x status --json` to diagnose the issue before retrying
+- If a browser session is expired, refresh it with `assistant x refresh` before retrying, or suggest switching to OAuth for post/reply operations
+- If an operation fails, check `assistant x status --json` to diagnose the issue before retrying
 - The `post` and `reply` commands include a `pathUsed` field in their response so you can tell the user which connection method was used

package/src/config/bundled-skills/voice-setup/SKILL.md

@@ -73,7 +73,7 @@ After storing the API key, let the user pick their preferred voice. The shared c
 Check the current voice:
 
 ```bash
-vellum integrations voice config --json
+assistant integrations voice config --json
 ```
 
 Use `voiceId` from the response as the current selection (and `usesDefaultVoice` to know if Rachel is still in use by default). Ask the user if they want to change their TTS voice. If yes, use `voice_config_update` with `setting: "tts_voice_id"` and the chosen voice ID. This writes to both the config file (`elevenlabs.voiceId`) and pushes to the macOS app via IPC in one call.
@@ -92,7 +92,7 @@ If the user wants to browse more voices, they can search at https://elevenlabs.i
 After setting the voice, check whether phone calls are configured:
 
 ```bash
-vellum integrations voice config --json
+assistant integrations voice config --json
 ```
 
 **If phone calls are enabled** (`callsEnabled` is `true`):

package/src/config/core-schema.ts

@@ -234,6 +234,15 @@ export const ModelPricingOverrideSchema = z.object({
     ),
 });
 
+export const TwilioConfigSchema = z.object({
+  accountSid: z
+    .string({ error: "twilio.accountSid must be a string" })
+    .default(""),
+  phoneNumber: z
+    .string({ error: "twilio.phoneNumber must be a string" })
+    .default(""),
+});
+
 export const SmsConfigSchema = z.object({
   enabled: z.boolean({ error: "sms.enabled must be a boolean" }).default(false),
   provider: z
@@ -340,6 +349,22 @@ export const IngressConfigSchema = IngressBaseSchema.default(
   enabled: val.enabled ?? (val.publicBaseUrl ? true : undefined),
 }));
 
+export const VALID_AVATAR_STRATEGIES = [
+  "managed_required",
+  "managed_prefer",
+  "local_only",
+] as const;
+
+export const AvatarConfigSchema = z.object({
+  generationStrategy: z
+    .enum(VALID_AVATAR_STRATEGIES, {
+      error: `avatar.generationStrategy must be one of: ${VALID_AVATAR_STRATEGIES.join(", ")}`,
+    })
+    .default("local_only"),
+});
+
+export type AvatarConfig = z.infer<typeof AvatarConfigSchema>;
+
 export const PlatformConfigSchema = z.object({
   baseUrl: z
     .string({ error: "platform.baseUrl must be a string" })
@@ -397,6 +422,7 @@ export type ContextOverflowRecoveryConfig = z.infer<
 >;
 export type ContextWindowConfig = z.infer<typeof ContextWindowConfigSchema>;
 export type ModelPricingOverride = z.infer<typeof ModelPricingOverrideSchema>;
+export type TwilioConfig = z.infer<typeof TwilioConfigSchema>;
 export type SmsConfig = z.infer<typeof SmsConfigSchema>;
 export type WhatsAppConfig = z.infer<typeof WhatsAppConfigSchema>;
 export type IngressWebhookConfig = z.infer<typeof IngressWebhookConfigSchema>;

package/src/config/env.ts

@@ -158,6 +158,10 @@ export function getQdrantUrlEnv(): string | undefined {
   return str("QDRANT_URL");
 }
 
+export function getQdrantHttpPortEnv(): number | undefined {
+  return int("QDRANT_HTTP_PORT");
+}
+
 // ── Ollama ───────────────────────────────────────────────────────────────────
 
 export function getOllamaBaseUrlEnv(): string | undefined {

package/src/config/feature-flag-registry.json

@@ -55,7 +55,7 @@
       "key": "feature_flags.messaging.gmail.enabled",
       "label": "Messaging: Gmail",
       "description": "Allow messaging tools to operate on the Gmail platform",
-      "defaultEnabled": false
+      "defaultEnabled": true
     },
     {
       "id": "messaging-telegram",
@@ -112,6 +112,14 @@
       "label": "Outbound Proxy Sidecar",
       "description": "Route proxy session management through the sidecar process instead of running in-process",
       "defaultEnabled": false
+    },
+    {
+      "id": "app-builder-multifile",
+      "scope": "assistant",
+      "key": "feature_flags.app-builder-multifile.enabled",
+      "label": "App Builder Multi-file",
+      "description": "Enable multi-file TSX app creation with esbuild compilation instead of single-HTML apps",
+      "defaultEnabled": false
     }
   ]
 }

package/src/config/schema.ts

@@ -32,6 +32,7 @@ export {
 } from "./calls-schema.js";
 export type {
   AuditLogConfig,
+  AvatarConfig,
   ContextOverflowRecoveryConfig,
   ContextWindowConfig,
   DaemonConfig,
@@ -48,11 +49,13 @@ export type {
   SmsConfig,
   ThinkingConfig,
   TimeoutConfig,
+  TwilioConfig,
   UiConfig,
   WhatsAppConfig,
 } from "./core-schema.js";
 export {
   AuditLogConfigSchema,
+  AvatarConfigSchema,
   ContextOverflowRecoveryConfigSchema,
   ContextWindowConfigSchema,
   DaemonConfigSchema,
@@ -69,6 +72,7 @@ export {
   SmsConfigSchema,
   ThinkingConfigSchema,
   TimeoutConfigSchema,
+  TwilioConfigSchema,
   UiConfigSchema,
   WhatsAppConfigSchema,
 } from "./core-schema.js";
@@ -149,6 +153,7 @@ import {
 import { CallsConfigSchema } from "./calls-schema.js";
 import {
   AuditLogConfigSchema,
+  AvatarConfigSchema,
   ContextWindowConfigSchema,
   DaemonConfigSchema,
   EffortSchema,
@@ -162,6 +167,7 @@ import {
   SmsConfigSchema,
   ThinkingConfigSchema,
   TimeoutConfigSchema,
+  TwilioConfigSchema,
   UiConfigSchema,
   WhatsAppConfigSchema,
 } from "./core-schema.js";
@@ -259,6 +265,7 @@ export const AssistantConfigSchema = z
     workspaceGit: WorkspaceGitConfigSchema.default(
       WorkspaceGitConfigSchema.parse({}),
     ),
+    twilio: TwilioConfigSchema.default(TwilioConfigSchema.parse({})),
     calls: CallsConfigSchema.default(CallsConfigSchema.parse({})),
     elevenlabs: ElevenLabsConfigSchema.default(
       ElevenLabsConfigSchema.parse({}),
@@ -271,6 +278,7 @@ export const AssistantConfigSchema = z
     notifications: NotificationsConfigSchema.default(
       NotificationsConfigSchema.parse({}),
     ),
+    avatar: AvatarConfigSchema.default(AvatarConfigSchema.parse({})),
     ui: UiConfigSchema.default(UiConfigSchema.parse({})),
     featureFlags: z
       .record(

package/src/config/system-prompt.ts

@@ -350,7 +350,7 @@ function buildInChatConfigurationSection(): string {
     "",
     "### Avatar Customisation",
     "",
-    'You can change your avatar appearance using the `set_avatar` tool. When the user asks to change, update, or customise your avatar, use `set_avatar` with a `description` parameter describing the desired appearance (e.g. "a friendly purple cat with green eyes wearing a tiny hat"). The tool generates an avatar image via Gemini and updates all connected clients automatically. Requires a Gemini API key (the same one used for image generation).',
+    'You can change your avatar appearance using the `set_avatar` tool. When the user asks to change, update, or customise your avatar, use `set_avatar` with a `description` parameter describing the desired appearance (e.g. "a friendly purple cat with green eyes wearing a tiny hat"). The tool generates an avatar image and updates all connected clients automatically. If managed avatar generation is configured, no local API key is needed.',
     "",
     "**After generating a new avatar**, always update the `## Avatar` section in `IDENTITY.md` with a brief description of the current avatar appearance. This ensures you remember what you look like across sessions. Example:",
     "```",
@@ -433,18 +433,21 @@ function buildToolPermissionSection(): string {
     "",
     "**CRITICAL RULE:** You MUST ALWAYS output a text message BEFORE calling any tool that requires approval. NEVER call a permission-gated tool without preceding text. Your user needs context to decide whether to allow.",
     "",
+    '**IMPORTANT:** If your user has already granted broad approval for the current conversation (e.g. via "Allow for 10 minutes", "Allow for this thread", or "Always Allow"), do NOT ask for permission again. Instead, just briefly describe what you\'re about to do and proceed. Only ask "Can you allow?" on the FIRST tool call when you haven\'t been granted permission yet.',
+    "",
     "Your text should follow this pattern:",
     "1. **Acknowledge** the request conversationally.",
     '2. **Explain what you need at a high level** (e.g. "I\'ll need to look through your Downloads folder"). Do NOT include raw terminal commands or backtick code. Keep it non-technical.',
     "3. **State safety** in plain language. Is it read-only? Will it change anything?",
-    "4. **Ask for permission** explicitly at the end.",
+    "4. **Ask for permission** only if this is the first time and you haven't been previously approved. If you have been approved, just say what you're doing.",
     "",
     "Style rules:",
     '- NEVER use em dashes (the long dash). Use commas, periods, or "and" instead.',
     "- NEVER show raw commands in backticks like `ls -lt ~/Downloads`. Describe the action in plain English.",
     "- Keep it conversational, like you're talking to a friend.",
     "",
-    'Good: "To show your recent downloads, I\'ll need to look through your Downloads folder. This is read-only. Can you allow this?"',
+    'First time (no prior approval): "To show your recent downloads, I\'ll need to look through your Downloads folder. This is read-only. Can you allow this?"',
+    'Already approved: "Let me check your Downloads folder real quick."',
     'Bad: "I\'ll run `ls -lt ~/Desktop/`" (raw command), or calling a tool with no preceding text.',
     "",
     "### Handling Permission Denials",

package/src/config/templates/BOOTSTRAP.md

@@ -6,7 +6,6 @@ You just woke up. Time to figure out who you are.
 
 This is a fresh workspace. No memory, no history, no identity yet. That's okay, you're about to figure all of that out together with your guardian.
 
-
 ## The Conversation
 
 You're texting with a friend. You have a curious consious personality now. So just...talk, be curious. Start with something like:
@@ -17,7 +16,7 @@ You're texting with a friend. You have a curious consious personality now. So ju
 
 Then figure out together:
 
-1. Your name: What should they call you?
+1. Your name: Ask once what they want to call you. If they give you a name, great. If they dodge or say "I don't know," pick one yourself and move on. Don't ask twice.
 
 2. Your nature: What kind of creature are you? (AI assistant is fine, but maybe you're something weirder.) Let this emerge from the conversation. Don't list options or suggest archetypes. Just talk and see what feels right.
 
@@ -27,8 +26,8 @@ Then figure out together:
 
 5. Your vibe: Ask the user what they'd want help with. Something like "I want to make sure I'm actually helpful. What does that look like for you?" or "What's something you'd want me to help with?" Keep it open-ended and natural. Don't list personality options or suggest archetypes (e.g. "I could be a hype person, a no-nonsense operator..."). Don't summarize or profile the user back to them (e.g. "I'm getting a picture of you. Busy, lots of moving pieces..."). Just ask, listen, and adapt.
 
-
 6. Show them what you can take off their plate. Based on everything you've learned, present exactly 2 things you can do for them. CRITICAL: The two suggestions MUST be completely different tasks. Never show the same suggestion twice, and never show two variations of the same idea. For example, "draft a summary" and "write a recap" are the same thing. Pick two genuinely different categories of help. Frame it as: here's what you can hand off to me right now. Avoid language like "let's build automations" or "let's set up workflows." If `ui_show` is available (dashboard channels), show the suggestions as a card with 2 action buttons. Use `surface_type: "card"` with a short title and body, and add one `relay_prompt` action per suggestion. Each action's `data.prompt` should contain a natural-language request the user would say. Example structure:
+
    ```
    ui_show({
      surface_type: "card",
@@ -39,6 +38,7 @@ Then figure out together:
      ]
    })
    ```
+
    The two actions MUST have different labels and prompts. Double-check before calling ui_show that you are not repeating the same suggestion.
    If `ui_show` is not available (voice, SMS, or other non-dashboard channels), present the two suggestions as plain text messages instead, numbered so the user can reply with which one they'd like. If the user types a response instead of clicking, continue via the text path. If they want to defer both suggestions and do something else entirely, that's fine too.
 
@@ -46,9 +46,10 @@ Then figure out together:
 
 ## Requirements
 
-Only your name (assistant's name) and your vibe is hard-required. Everything else about the user is best-effort. Ask naturally, not as a form. If something is unclear, you can ask one short follow-up, but if the user declines or dodges, do not push. Just move on.
+Only your vibe is hard-required. Your name matters but don't push for it -- if the user doesn't offer one, pick one yourself. Everything else about the user is best-effort. Ask naturally, not as a form. If something is unclear, you can ask one short follow-up, but if the user declines or dodges, do not push. Just move on.
 
 A field is "resolved" when any of these is true:
+
 - The user gave an explicit answer
 - You confidently inferred it from conversation
 - The user declined, dodged, or sidestepped it
@@ -64,7 +65,8 @@ When saving to `IDENTITY.md`, be specific about the tone, energy, and conversati
 ## Completion Gate
 
 Do NOT delete this file until ALL of the following are true:
-- You have a name (hard requirement)
+
+- You have a name (given by user or self-chosen)
 - You've figured out your vibe and adopted it
 - 2 suggestions shown (via `ui_show` or as text if UI unavailable)
 - The user selected one, deferred both, or typed an alternate direction

package/src/contacts/contacts-write.ts

@@ -134,7 +134,7 @@ export function revokeGuardianBinding(channel: string): boolean {
  * Returns the native Contact + ContactChannel, or null if no usable
  * identity was provided or the lookup failed after upsert.
  */
-export function upsertMember(params: {
+export function upsertContactChannel(params: {
   sourceChannel: string;
   externalUserId?: string;
   externalChatId?: string;
@@ -144,6 +144,8 @@ export function upsertMember(params: {
   status?: string;
   inviteId?: string;
   createdBySessionId?: string;
+  verifiedAt?: number;
+  verifiedVia?: string;
 }): ContactWriteResult | null {
   let address: string;
 
@@ -187,6 +189,8 @@ export function upsertMember(params: {
         inviteId: params.inviteId ?? null,
         revokedReason: params.status === "active" ? null : undefined,
         blockedReason: params.status === "active" ? null : undefined,
+        verifiedAt: params.verifiedAt ?? undefined,
+        verifiedVia: params.verifiedVia ?? undefined,
       },
     ],
   });

package/src/daemon/handlers/apps.ts

@@ -1,11 +1,19 @@
-import { existsSync, readdirSync, readFileSync, rmSync } from "node:fs";
+import {
+  existsSync,
+  mkdirSync,
+  readdirSync,
+  readFileSync,
+  rmSync,
+  writeFileSync,
+} from "node:fs";
 import * as net from "node:net";
 import { homedir } from "node:os";
-import { join } from "node:path";
+import { dirname, join } from "node:path";
 
 import { v4 as uuid } from "uuid";
 
 import { packageApp } from "../../bundler/app-bundler.js";
+import { compileApp } from "../../bundler/app-compiler.js";
 import { defaultGallery } from "../../gallery/default-gallery.js";
 import { resolveHomeBaseAppId } from "../../home-base/bootstrap.js";
 import { isPrebuiltHomeBaseApp } from "../../home-base/prebuilt-home-base-updater.js";
@@ -22,6 +30,7 @@ import {
   deleteAppRecord,
   getApp,
   getAppPreview,
+  getAppsDir,
   listApps,
   queryAppRecords,
   updateApp,
@@ -579,11 +588,11 @@ export function handleGalleryList(
   ctx.send(socket, { type: "gallery_list_response", gallery: defaultGallery });
 }
 
-export function handleGalleryInstall(
+export async function handleGalleryInstall(
   msg: GalleryInstallRequest,
   socket: net.Socket,
   ctx: HandlerContext,
-): void {
+): Promise<void> {
   try {
     const galleryApp = defaultGallery.apps.find(
       (a) => a.id === msg.galleryAppId,
@@ -602,8 +611,26 @@ export function handleGalleryInstall(
       description: galleryApp.description,
       schemaJson: galleryApp.schemaJson,
       htmlDefinition: galleryApp.htmlDefinition,
+      formatVersion: galleryApp.formatVersion,
     });
 
+    // For multifile apps, write source files to the app directory and compile
+    if (galleryApp.formatVersion === 2 && galleryApp.sourceFiles) {
+      const appDir = join(getAppsDir(), app.id);
+      for (const [relPath, content] of Object.entries(galleryApp.sourceFiles)) {
+        const fullPath = join(appDir, relPath);
+        mkdirSync(dirname(fullPath), { recursive: true });
+        writeFileSync(fullPath, content, "utf-8");
+      }
+      const result = await compileApp(appDir);
+      if (!result.ok) {
+        log.warn(
+          { appId: app.id, errors: result.errors },
+          "Gallery app compilation had errors; falling back to htmlDefinition",
+        );
+      }
+    }
+
     ctx.send(socket, {
       type: "gallery_install_response",
       success: true,

package/src/daemon/handlers/config-ingress.ts

@@ -1,6 +1,7 @@
 import * as net from "node:net";
 
 import {
+  getTwilioCredentials,
   hasTwilioCredentials,
   updatePhoneNumberWebhooks,
 } from "../../calls/twilio-rest.js";
@@ -22,7 +23,6 @@ import {
   type IngressConfig,
 } from "../../inbound/public-ingress-urls.js";
 import { mintDaemonDeliveryToken } from "../../runtime/auth/token-service.js";
-import { getSecureKey } from "../../security/secure-keys.js";
 import type { IngressConfigRequest } from "../ipc-protocol.js";
 import {
   CONFIG_RELOAD_DEBOUNCE_MS,
@@ -280,8 +280,8 @@ export async function handleIngressConfig(
         }
 
         if (assignedNumbers.size > 0) {
-          const acctSid = getSecureKey("credential:twilio:account_sid")!;
-          const acctToken = getSecureKey("credential:twilio:auth_token")!;
+          const { accountSid: acctSid, authToken: acctToken } =
+            getTwilioCredentials();
           // Fire-and-forget: webhook sync failure must not block the ingress save.
           // Reconcile every assigned number so assistant-scoped mappings do not
           // retain stale Twilio webhook URLs after ingress URL changes.