@vellumai/assistant 0.4.41 → 0.4.43

package/docs/architecture/scheduling.md

@@ -11,13 +11,13 @@ The scheduler supports two recurrence syntaxes for recurring tasks:
 
 ### Supported RRULE Lines
 
-| Line | Purpose | Example |
-|------|---------|---------|
-| `DTSTART` | Start date/time anchor (required) | `DTSTART:20250101T090000Z` |
-| `RRULE:` | Recurrence rule (one or more; multiple lines form a union) | `RRULE:FREQ=WEEKLY;BYDAY=MO,WE,FR` |
-| `RDATE` | Add one-off dates not covered by the RRULE pattern | `RDATE:20250704T090000Z` |
-| `EXDATE` | Exclude specific dates from the recurrence set | `EXDATE:20251225T090000Z` |
-| `EXRULE` | Exclude an entire series defined by a recurrence pattern | `EXRULE:FREQ=YEARLY;BYMONTH=12;BYMONTHDAY=25` |
+| Line      | Purpose                                                    | Example                                       |
+| --------- | ---------------------------------------------------------- | --------------------------------------------- |
+| `DTSTART` | Start date/time anchor (required)                          | `DTSTART:20250101T090000Z`                    |
+| `RRULE:`  | Recurrence rule (one or more; multiple lines form a union) | `RRULE:FREQ=WEEKLY;BYDAY=MO,WE,FR`            |
+| `RDATE`   | Add one-off dates not covered by the RRULE pattern         | `RDATE:20250704T090000Z`                      |
+| `EXDATE`  | Exclude specific dates from the recurrence set             | `EXDATE:20251225T090000Z`                     |
+| `EXRULE`  | Exclude an entire series defined by a recurrence pattern   | `EXRULE:FREQ=YEARLY;BYMONTH=12;BYMONTHDAY=25` |
 
 Bounded recurrence is supported via `COUNT` (e.g., `RRULE:FREQ=DAILY;COUNT=30`) and `UNTIL` (e.g., `RRULE:FREQ=WEEKLY;UNTIL=20250331T235959Z`) parameters on `RRULE` lines.
 
@@ -27,19 +27,19 @@ Bounded recurrence is supported via `COUNT` (e.g., `RRULE:FREQ=DAILY;COUNT=30`)
 
 The `detectScheduleSyntax()` function auto-detects which syntax an expression uses by checking for RRULE markers (`RRULE:`, `DTSTART`, `FREQ=`). When creating or updating a schedule, the caller can explicitly specify `syntax: 'cron' | 'rrule'`, or the system infers it from the expression string via `normalizeScheduleSyntax()`.
 
-### Legacy Compatibility
+### Naming
 
-The database column is named `cron_expression` and the Drizzle table is `cronJobs` for migration compatibility. Code aliases `scheduleJobs` and `scheduleRuns` are preferred in new code. The legacy field names `cron_expression` and `cronExpression` remain supported in API inputs during the transition period. Both `expression` (new) and `cronExpression` (legacy) are accepted when creating or updating schedules.
+The database column is named `cron_expression` and the Drizzle table is `cronJobs` for historical reasons. Code aliases `scheduleJobs` and `scheduleRuns` are preferred in new code. The canonical API field is `expression` with an explicit `syntax` discriminator.
 
 ### Key Source Files
 
-| File | Responsibility |
-|------|---------------|
-| `assistant/src/schedule/recurrence-types.ts` | `ScheduleSyntax` type, `detectScheduleSyntax()`, `normalizeScheduleSyntax()` |
+| File                                          | Responsibility                                                                      |
+| --------------------------------------------- | ----------------------------------------------------------------------------------- |
+| `assistant/src/schedule/recurrence-types.ts`  | `ScheduleSyntax` type, `detectScheduleSyntax()`, `normalizeScheduleSyntax()`        |
 | `assistant/src/schedule/recurrence-engine.ts` | Validation (`isValidScheduleExpression`), next-run computation, RRULE set detection |
-| `assistant/src/schedule/schedule-store.ts` | CRUD operations, claim-based polling, legacy `cronExpression` field support |
-| `assistant/src/schedule/scheduler.ts` | 15-second tick loop, fires due schedules and reminders |
-| `assistant/src/memory/schema.ts` | `cronJobs` / `scheduleJobs` table, `scheduleSyntax` column |
+| `assistant/src/schedule/schedule-store.ts`    | CRUD operations, claim-based polling                                                |
+| `assistant/src/schedule/scheduler.ts`         | 15-second tick loop, fires due schedules and reminders                              |
+| `assistant/src/memory/schema.ts`              | `cronJobs` / `scheduleJobs` table, `scheduleSyntax` column                          |
 
 ---
 
@@ -51,10 +51,10 @@ Reminders support optional routing metadata that controls how the notification p
 
 Two columns on the `reminders` table carry routing metadata:
 
-| Column | Type | Default | Description |
-|--------|------|---------|-------------|
-| `routing_intent` | TEXT | `'single_channel'` | Controls channel coverage: `single_channel`, `multi_channel`, or `all_channels` |
-| `routing_hints_json` | TEXT (JSON) | `'{}'` | Free-form hints for the decision engine (e.g. preferred channels) |
+| Column               | Type        | Default            | Description                                                                     |
+| -------------------- | ----------- | ------------------ | ------------------------------------------------------------------------------- |
+| `routing_intent`     | TEXT        | `'single_channel'` | Controls channel coverage: `single_channel`, `multi_channel`, or `all_channels` |
+| `routing_hints_json` | TEXT (JSON) | `'{}'`             | Free-form hints for the decision engine (e.g. preferred channels)               |
 
 ### Trigger-Time Data Flow
 
@@ -88,11 +88,11 @@ sequenceDiagram
 
 The `enforceRoutingIntent()` step runs after the LLM produces a channel selection but before deterministic checks. It acts as a post-decision guard:
 
-| Intent | Enforcement Rule |
-|--------|-----------------|
-| `single_channel` | No override. The LLM's channel selection stands. |
-| `multi_channel` | If the LLM selected < 2 channels and 2+ are connected, expand to at least two connected channels. |
-| `all_channels` | Replace the LLM's selection with all connected channels. |
+| Intent           | Enforcement Rule                                                                                  |
+| ---------------- | ------------------------------------------------------------------------------------------------- |
+| `single_channel` | No override. The LLM's channel selection stands.                                                  |
+| `multi_channel`  | If the LLM selected < 2 channels and 2+ are connected, expand to at least two connected channels. |
+| `all_channels`   | Replace the LLM's selection with all connected channels.                                          |
 
 When enforcement changes the decision, the updated `selectedChannels` and annotated `reasoningSummary` are re-persisted to `notification_decisions` so the audit trail reflects what was actually dispatched.
 
@@ -112,15 +112,15 @@ If a channel becomes unavailable between reminder creation and fire time, it is
 
 ### Key Source Files
 
-| File | Responsibility |
-|------|---------------|
-| `assistant/src/tools/reminder/reminder-store.ts` | CRUD with `routingIntent` and `routingHints` fields |
-| `assistant/src/memory/schema.ts` | `reminders` table schema with `routing_intent` and `routing_hints_json` columns |
-| `assistant/src/schedule/scheduler.ts` | Claims due reminders and passes routing metadata to the notifier |
-| `assistant/src/daemon/lifecycle.ts` | Wires the reminder notifier to `emitNotificationSignal()` with routing metadata |
-| `assistant/src/notifications/emit-signal.ts` | Orchestrates the full pipeline including routing intent enforcement |
-| `assistant/src/notifications/decision-engine.ts` | `enforceRoutingIntent()` post-decision guard |
-| `assistant/src/notifications/signal.ts` | `RoutingIntent` type and `NotificationSignal` fields |
+| File                                             | Responsibility                                                                  |
+| ------------------------------------------------ | ------------------------------------------------------------------------------- |
+| `assistant/src/tools/reminder/reminder-store.ts` | CRUD with `routingIntent` and `routingHints` fields                             |
+| `assistant/src/memory/schema.ts`                 | `reminders` table schema with `routing_intent` and `routing_hints_json` columns |
+| `assistant/src/schedule/scheduler.ts`            | Claims due reminders and passes routing metadata to the notifier                |
+| `assistant/src/daemon/lifecycle.ts`              | Wires the reminder notifier to `emitNotificationSignal()` with routing metadata |
+| `assistant/src/notifications/emit-signal.ts`     | Orchestrates the full pipeline including routing intent enforcement             |
+| `assistant/src/notifications/decision-engine.ts` | `enforceRoutingIntent()` post-decision guard                                    |
+| `assistant/src/notifications/signal.ts`          | `RoutingIntent` type and `NotificationSignal` fields                            |
 
 ---
 
@@ -179,13 +179,13 @@ graph TD
 
 **Key design decisions:**
 
-| Decision | Rationale |
-|----------|-----------|
-| Watermark-based polling | Efficient change detection without webhooks; each provider defines its own cursor format |
-| Background conversations | LLM retains context across polls (e.g. "already replied to this thread"); invisible to user's chat |
-| Circuit breaker (5 errors → disable) | Prevents runaway polling when credentials expire or APIs break |
-| Provider interface | Extensible: implement `WatcherProvider` for any external API (Gmail, Stripe, Gong, Salesforce, etc.) |
-| Optimistic claim locking | Prevents double-polling in concurrent scheduler ticks |
+| Decision                             | Rationale                                                                                            |
+| ------------------------------------ | ---------------------------------------------------------------------------------------------------- |
+| Watermark-based polling              | Efficient change detection without webhooks; each provider defines its own cursor format             |
+| Background conversations             | LLM retains context across polls (e.g. "already replied to this thread"); invisible to user's chat   |
+| Circuit breaker (5 errors → disable) | Prevents runaway polling when credentials expire or APIs break                                       |
+| Provider interface                   | Extensible: implement `WatcherProvider` for any external API (Gmail, Stripe, Gong, Salesforce, etc.) |
+| Optimistic claim locking             | Prevents double-polling in concurrent scheduler ticks                                                |
 
 **Data tables:** `watchers` (config, watermark, status, error tracking) and `watcher_events` (detected events, dedup on `(watcher_id, external_id)`, disposition tracking).
 
@@ -203,22 +203,22 @@ The Task Queue provides an ordered execution pipeline with human-in-the-loop rev
 
 The `work_items` table links to the existing `tasks` table and tracks execution state:
 
-| Column | Type | Description |
-|--------|------|-------------|
-| `id` | text (PK) | Unique work item identifier |
-| `task_id` | text (FK → `tasks`) | The Task template to execute |
-| `title` | text | Display title (may differ from the Task's title) |
-| `notes` | text | Optional user-provided notes or context |
-| `status` | text | Lifecycle state (see below) |
-| `priority_tier` | integer (0–3) | Priority bucket; lower = higher priority |
-| `sort_index` | integer | Manual ordering within a priority tier |
-| `last_run_id` | text | Most recent `task_runs.id` for this item |
-| `last_run_conversation_id` | text | Conversation used by the last run |
-| `last_run_status` | text | Status of the last run (`completed`, `failed`, etc.) |
-| `source_type` | text | Reserved — origin type (e.g., `watcher`, `manual`) |
-| `source_id` | text | Reserved — origin identifier |
-| `created_at` | integer | Epoch ms |
-| `updated_at` | integer | Epoch ms |
+| Column                     | Type                | Description                                          |
+| -------------------------- | ------------------- | ---------------------------------------------------- |
+| `id`                       | text (PK)           | Unique work item identifier                          |
+| `task_id`                  | text (FK → `tasks`) | The Task template to execute                         |
+| `title`                    | text                | Display title (may differ from the Task's title)     |
+| `notes`                    | text                | Optional user-provided notes or context              |
+| `status`                   | text                | Lifecycle state (see below)                          |
+| `priority_tier`            | integer (0–3)       | Priority bucket; lower = higher priority             |
+| `sort_index`               | integer             | Manual ordering within a priority tier               |
+| `last_run_id`              | text                | Most recent `task_runs.id` for this item             |
+| `last_run_conversation_id` | text                | Conversation used by the last run                    |
+| `last_run_status`          | text                | Status of the last run (`completed`, `failed`, etc.) |
+| `source_type`              | text                | Reserved — origin type (e.g., `watcher`, `manual`)   |
+| `source_id`                | text                | Reserved — origin identifier                         |
+| `created_at`               | integer             | Epoch ms                                             |
+| `updated_at`               | integer             | Epoch ms                                             |
 
 **Ordering:** `priority_tier ASC, sort_index ASC, updated_at DESC`. Items with a lower priority tier appear first; within a tier, manual `sort_index` controls order; ties broken by most-recently-updated.
 
@@ -229,14 +229,14 @@ queued → running → awaiting_review → done → archived
                  ↘ failed ↗
 ```
 
-| Status | Meaning |
-|--------|---------|
-| `queued` | Waiting to be executed |
-| `running` | Task is currently executing |
+| Status            | Meaning                                                |
+| ----------------- | ------------------------------------------------------ |
+| `queued`          | Waiting to be executed                                 |
+| `running`         | Task is currently executing                            |
 | `awaiting_review` | Task ran successfully; output is ready for user review |
-| `failed` | Task execution failed (can be retried → `running`) |
-| `done` | User reviewed and accepted the output |
-| `archived` | Completed item moved out of active view |
+| `failed`          | Task execution failed (can be retried → `running`)     |
+| `done`            | User reviewed and accepted the output                  |
+| `archived`        | Completed item moved out of active view                |
 
 ### Data Flow
 

package/docs/architecture/security.md

@@ -154,7 +154,7 @@ For `bash` and `host_bash` tool invocations, the permission system uses parser-d
 
 ### Prompt UX
 
-When a permission prompt is sent to the client (via `confirmation_request` IPC message), it includes:
+When a permission prompt is sent to the client (via `confirmation_request` SSE event), it includes:
 
 | Field              | Content                                             |
 | ------------------ | --------------------------------------------------- |
@@ -189,7 +189,7 @@ File tool candidates include canonical (symlink-resolved) absolute paths via `no
 
 ### Permission Simulation (Tool Permission Tester)
 
-The `tool_permission_simulate` IPC message lets clients dry-run a tool invocation through the full permission evaluation pipeline without actually executing the tool or mutating daemon state. The macOS Settings panel exposes this as a "Tool Permission Tester" UI.
+The `tool_permission_simulate` HTTP endpoint lets clients dry-run a tool invocation through the full permission evaluation pipeline without actually executing the tool or mutating daemon state. The macOS Settings panel exposes this as a "Tool Permission Tester" UI.
 
 **Simulation semantics:**
 
@@ -312,7 +312,7 @@ The `allowOneTimeSend` config gate (default: `false`) enables a secondary "Send
 
 ## Channel-Agnostic Scoped Approval Grants
 
-Scoped approval grants are a channel-agnostic primitive that allows a guardian's approval decision on one channel (e.g., Telegram) to authorize a tool execution on a different channel (e.g., voice). Each grant authorizes exactly one tool execution and is consumed atomically.
+Scoped approval grants are a channel-agnostic primitive that allows a guardian's approval decision on one channel (e.g., Telegram) to authorize a tool execution on a different channel (e.g., phone). Each grant authorizes exactly one tool execution and is consumed atomically.
 
 ### Scope Modes
 

package/docs/runbook-trusted-contacts.md

@@ -13,10 +13,9 @@ Operational procedures for inspecting, managing, and debugging the trusted conta
 # Base URL — assistant runtime (adjust if using a non-default port)
 BASE=http://localhost:7821
 
-# Bearer token: if running via the assistant's shell tools, $GATEWAY_AUTH_TOKEN
-# is injected automatically. For manual operator use, mint a token via the CLI
-# or use one from the daemon (e.g. from a recent shell env export).
-TOKEN=$GATEWAY_AUTH_TOKEN
+# Bearer token: for operator use, retrieve from the daemon process environment
+# or use `assistant` CLI commands which handle auth automatically.
+TOKEN=<your-bearer-token>
 ```
 
 ## 1. Inspect Trusted Contacts
@@ -35,8 +34,8 @@ curl -s "$BASE/v1/contacts?role=contact" \
 curl -s "$BASE/v1/contacts?channelType=telegram" \
   -H "Authorization: Bearer $TOKEN" | jq
 
-# SMS contacts only
-curl -s "$BASE/v1/contacts?channelType=sms" \
+# Voice contacts only
+curl -s "$BASE/v1/contacts?channelType=phone" \
   -H "Authorization: Bearer $TOKEN" | jq
 ```
 
@@ -117,14 +116,14 @@ sqlite3 ~/.vellum/workspace/data/db/assistant.db \
 
 ## 3. Inspect Pending Verification Sessions
 
-Verification challenges are stored in `channel_guardian_verification_challenges`. Active sessions have `status = 'awaiting_response'` and `expires_at > now`.
+Verification challenges are stored in `channel_verification_sessions`. Active sessions have `status = 'awaiting_response'` and `expires_at > now`.
 
 ```bash
 sqlite3 ~/.vellum/workspace/data/db/assistant.db \
   "SELECT id, channel, status, identity_binding_status, \
    expected_external_user_id, expected_chat_id, expected_phone_e164, \
    expires_at, created_at \
-   FROM channel_guardian_verification_challenges \
+   FROM channel_verification_sessions \
    WHERE status IN ('awaiting_response', 'pending_bootstrap') \
    AND expires_at > $(date +%s)000 \
    ORDER BY created_at DESC;"
@@ -200,7 +199,7 @@ sqlite3 ~/.vellum/workspace/data/db/assistant.db \
   "SELECT id, channel, status, identity_binding_status, \
    expected_external_user_id, expected_chat_id, expected_phone_e164, \
    expires_at, consumed_by_external_user_id \
-   FROM channel_guardian_verification_challenges \
+   FROM channel_verification_sessions \
    WHERE expected_external_user_id = 'TARGET_USER_ID' \
    OR expected_chat_id = 'TARGET_CHAT_ID' \
    ORDER BY created_at DESC LIMIT 5;"
@@ -274,7 +273,7 @@ curl -s -X POST "$BASE/v1/contacts" \
   }' | jq
 ```
 
-For SMS contacts, use the E.164 phone number as the address and external user/chat ID:
+For voice contacts, use the E.164 phone number as the address and external user/chat ID:
 
 ```bash
 curl -s -X POST "$BASE/v1/contacts" \
@@ -284,7 +283,7 @@ curl -s -X POST "$BASE/v1/contacts" \
     "displayName": "Bob",
     "role": "contact",
     "channels": [{
-      "type": "sms",
+      "type": "phone",
       "address": "+15551234567",
       "externalUserId": "+15551234567",
       "externalChatId": "+15551234567",
@@ -302,7 +301,7 @@ Expired sessions are already invisible to the verification flow (filtered by `ex
 
 ```bash
 sqlite3 ~/.vellum/workspace/data/db/assistant.db \
-  "DELETE FROM channel_guardian_verification_challenges \
+  "DELETE FROM channel_verification_sessions \
    WHERE expires_at < $(date +%s)000 \
    AND status IN ('awaiting_response', 'pending_bootstrap');"
 ```

package/docs/trusted-contact-access.md

@@ -35,7 +35,7 @@ Design doc defining how unknown users gain access to a Vellum assistant via chan
 5. **Guardian receives the verification code.** The assistant delivers the code to the guardian's verified channel (Telegram chat, SMS, etc.).
 6. **Guardian gives the code to the requester out-of-band** (in person, text message, phone call, etc.). This out-of-band transfer is the trust anchor: it proves the requester has a real-world relationship with the guardian.
 7. **Requester enters the code** back to the assistant on the same channel. The inbound message handler intercepts bare 6-digit codes when a pending verification session exists for that channel.
-8. **Assistant verifies the code and activates the user.** `validateAndConsumeChallenge()` hashes the code, matches it against the pending session, verifies identity binding (the code must come from the expected channel identity), consumes the challenge, and calls `upsertContactChannel()` with `status: 'active'` and `policy: 'allow'`.
+8. **Assistant verifies the code and activates the user.** `validateAndConsumeVerification()` hashes the code, matches it against the pending session, verifies identity binding (the code must come from the expected channel identity), consumes the session, and calls `upsertContactChannel()` with `status: 'active'` and `policy: 'allow'`.
 9. **All subsequent messages are accepted normally.** The ingress ACL finds an active member record and allows the message through.
 
 ## Lifecycle States
@@ -44,18 +44,18 @@ Design doc defining how unknown users gain access to a Vellum assistant via chan
 requested -> pending_guardian -> verification_pending -> active | denied | expired
 ```
 
-| State                  | Description                                                                                                        | Store representation                                                                                                                                                                                        |
-| ---------------------- | ------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `requested`            | Unknown user messaged the assistant and was rejected. The system records the access attempt.                       | No member record exists. The rejection is logged in `channel_inbound_events`. A notification signal is emitted via `emitNotificationSignal()`.                                                              |
-| `pending_guardian`     | The guardian has been notified and a decision is pending.                                                          | A `channel_guardian_approval_requests` record exists with `status: 'pending'`, `toolName: 'ingress_access_request'`.                                                                                        |
-| `verification_pending` | The guardian approved. A verification session is active with a 6-digit code waiting for the requester to enter.    | `channel_guardian_verification_challenges` record with `status: 'awaiting_response'`, identity-bound to the requester's expected channel identity. The approval request is updated to `status: 'approved'`. |
-| `active`               | The requester entered the correct code. They are now a trusted contact.                                            | `contact_channels` record with `status: 'active'`, `policy: 'allow'`. The verification session is `status: 'consumed'`.                                                                                     |
-| `denied`               | The guardian explicitly denied the request.                                                                        | The approval request has `status: 'denied'`. No member record is created (or if one existed, it remains unchanged).                                                                                         |
-| `expired`              | The guardian never responded (approval TTL elapsed) or the requester never entered the code (session TTL elapsed). | Approval request: `status: 'expired'` (set by `sweepExpiredGuardianApprovals()`). Verification session: expires naturally when `expiresAt < Date.now()`.                                                    |
+| State                  | Description                                                                                                        | Store representation                                                                                                                                                                             |
+| ---------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `requested`            | Unknown user messaged the assistant and was rejected. The system records the access attempt.                       | No member record exists. The rejection is logged in `channel_inbound_events`. A notification signal is emitted via `emitNotificationSignal()`.                                                   |
+| `pending_guardian`     | The guardian has been notified and a decision is pending.                                                          | A `channel_guardian_approval_requests` record exists with `status: 'pending'`, `toolName: 'ingress_access_request'`.                                                                             |
+| `verification_pending` | The guardian approved. A verification session is active with a 6-digit code waiting for the requester to enter.    | `channel_verification_sessions` record with `status: 'awaiting_response'`, identity-bound to the requester's expected channel identity. The approval request is updated to `status: 'approved'`. |
+| `active`               | The requester entered the correct code. They are now a trusted contact.                                            | `contact_channels` record with `status: 'active'`, `policy: 'allow'`. The verification session is `status: 'consumed'`.                                                                          |
+| `denied`               | The guardian explicitly denied the request.                                                                        | The approval request has `status: 'denied'`. No member record is created (or if one existed, it remains unchanged).                                                                              |
+| `expired`              | The guardian never responded (approval TTL elapsed) or the requester never entered the code (session TTL elapsed). | Approval request: `status: 'expired'` (set by `sweepExpiredGuardianApprovals()`). Verification session: expires naturally when `expiresAt < Date.now()`.                                         |
 
 ## Identity Binding Rules
 
-Identity binding ensures the verification code can only be consumed by the intended recipient on the intended channel. The binding fields are set on the `channel_guardian_verification_challenges` record when the session is created.
+Identity binding ensures the verification code can only be consumed by the intended recipient on the intended channel. The binding fields are set on the `channel_verification_sessions` record when the session is created.
 
 | Channel  | Identity fields                                                                  | Binding behavior                                                                                                                                                                                                                          |
 | -------- | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -76,42 +76,42 @@ Identity binding ensures the verification code can only be consumed by the inten
 
 ### Stage: `pending_guardian` (guardian notified, awaiting decision)
 
-| Store                       | Table                                | Record                                                                                                                                                                                                                                                                                   |
-| --------------------------- | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `channel-guardian-store.ts` | `channel_guardian_approval_requests` | `status: 'pending'`, `toolName: 'ingress_access_request'`, `requesterExternalUserId`, `requesterChatId`, `guardianExternalUserId`, `guardianChatId` (resolved from the `contacts`/`contact_channels` tables where `role = 'guardian'`), `expiresAt` (GUARDIAN_APPROVAL_TTL_MS from now). |
-| `notification_events`       | `notification_events`                | Event with `sourceEventName: 'ingress.access_request'`, links to the conversation.                                                                                                                                                                                                       |
-| `notification_decisions`    | `notification_decisions`             | Decision engine output: which channels to notify, confidence, reasoning.                                                                                                                                                                                                                 |
-| `notification_deliveries`   | `notification_deliveries`            | Per-channel delivery records (Telegram, vellum, etc.).                                                                                                                                                                                                                                   |
+| Store                                                        | Table                                | Record                                                                                                                                                                                                                                                                                   |
+| ------------------------------------------------------------ | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `guardian-approvals.ts` / `channel-verification-sessions.ts` | `channel_guardian_approval_requests` | `status: 'pending'`, `toolName: 'ingress_access_request'`, `requesterExternalUserId`, `requesterChatId`, `guardianExternalUserId`, `guardianChatId` (resolved from the `contacts`/`contact_channels` tables where `role = 'guardian'`), `expiresAt` (GUARDIAN_APPROVAL_TTL_MS from now). |
+| `notification_events`                                        | `notification_events`                | Event with `sourceEventName: 'ingress.access_request'`, links to the conversation.                                                                                                                                                                                                       |
+| `notification_decisions`                                     | `notification_decisions`             | Decision engine output: which channels to notify, confidence, reasoning.                                                                                                                                                                                                                 |
+| `notification_deliveries`                                    | `notification_deliveries`            | Per-channel delivery records (Telegram, vellum, etc.).                                                                                                                                                                                                                                   |
 
 ### Stage: `verification_pending` (guardian approved, code issued)
 
-| Store                       | Table                                      | Record                                                                                                                                                                                                                                                                              |
-| --------------------------- | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `channel-guardian-store.ts` | `channel_guardian_approval_requests`       | Updated to `status: 'approved'`, `decidedByExternalUserId` set.                                                                                                                                                                                                                     |
-| `channel-guardian-store.ts` | `channel_guardian_verification_challenges` | New record: `status: 'awaiting_response'`, `identityBindingStatus: 'bound'`, `expectedExternalUserId`/`expectedChatId`/`expectedPhoneE164` set to the requester's identity, `challengeHash` = SHA-256 of the 6-digit code, `expiresAt` = 10 minutes from creation, `codeDigits: 6`. |
+| Store                                                        | Table                                | Record                                                                                                                                                                                                                                                                              |
+| ------------------------------------------------------------ | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `guardian-approvals.ts` / `channel-verification-sessions.ts` | `channel_guardian_approval_requests` | Updated to `status: 'approved'`, `decidedByExternalUserId` set.                                                                                                                                                                                                                     |
+| `guardian-approvals.ts` / `channel-verification-sessions.ts` | `channel_verification_sessions`      | New record: `status: 'awaiting_response'`, `identityBindingStatus: 'bound'`, `expectedExternalUserId`/`expectedChatId`/`expectedPhoneE164` set to the requester's identity, `challengeHash` = SHA-256 of the 6-digit code, `expiresAt` = 10 minutes from creation, `codeDigits: 6`. |
 
 ### Stage: `active` (code verified, trusted contact created)
 
-| Store                       | Table                                      | Record                                                                                                                                                                                                      |
-| --------------------------- | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `contacts-write.ts`         | `contacts` / `contact_channels`            | Upserted via `upsertContactChannel()`: creates a contact record and a `contact_channels` entry with `status: 'active'`, `policy: 'allow'`, channel type, `externalUserId`, `externalChatId`, `displayName`. |
-| `channel-guardian-store.ts` | `channel_guardian_verification_challenges` | Updated to `status: 'consumed'`, `consumedByExternalUserId`, `consumedByChatId` set.                                                                                                                        |
-| `channel-guardian-store.ts` | `channel_guardian_rate_limits`             | Reset via `resetRateLimit()` on successful verification.                                                                                                                                                    |
+| Store                                                        | Table                           | Record                                                                                                                                                                                                      |
+| ------------------------------------------------------------ | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `contacts-write.ts`                                          | `contacts` / `contact_channels` | Upserted via `upsertContactChannel()`: creates a contact record and a `contact_channels` entry with `status: 'active'`, `policy: 'allow'`, channel type, `externalUserId`, `externalChatId`, `displayName`. |
+| `guardian-approvals.ts` / `channel-verification-sessions.ts` | `channel_verification_sessions` | Updated to `status: 'consumed'`, `consumedByExternalUserId`, `consumedByChatId` set.                                                                                                                        |
+| `guardian-approvals.ts` / `channel-verification-sessions.ts` | `channel_guardian_rate_limits`  | Reset via `resetRateLimit()` on successful verification.                                                                                                                                                    |
 
 ### Stage: `denied` (guardian rejected)
 
-| Store                       | Table                                | Record                                                        |
-| --------------------------- | ------------------------------------ | ------------------------------------------------------------- |
-| `channel-guardian-store.ts` | `channel_guardian_approval_requests` | Updated to `status: 'denied'`, `decidedByExternalUserId` set. |
+| Store                                                        | Table                                | Record                                                        |
+| ------------------------------------------------------------ | ------------------------------------ | ------------------------------------------------------------- |
+| `guardian-approvals.ts` / `channel-verification-sessions.ts` | `channel_guardian_approval_requests` | Updated to `status: 'denied'`, `decidedByExternalUserId` set. |
 
 No member record is created. No verification session is created.
 
 ### Stage: `expired`
 
-| Store                       | Table                                      | Record                                                                                            |
-| --------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------- |
-| `channel-guardian-store.ts` | `channel_guardian_approval_requests`       | Updated to `status: 'expired'` by `sweepExpiredGuardianApprovals()` (runs every 60s).             |
-| `channel-guardian-store.ts` | `channel_guardian_verification_challenges` | Expires naturally: `expiresAt < Date.now()` makes it invisible to `findPendingChallengeByHash()`. |
+| Store                                                        | Table                                | Record                                                                                          |
+| ------------------------------------------------------------ | ------------------------------------ | ----------------------------------------------------------------------------------------------- |
+| `guardian-approvals.ts` / `channel-verification-sessions.ts` | `channel_guardian_approval_requests` | Updated to `status: 'expired'` by `sweepExpiredGuardianApprovals()` (runs every 60s).           |
+| `guardian-approvals.ts` / `channel-verification-sessions.ts` | `channel_verification_sessions`      | Expires naturally: `expiresAt < Date.now()` makes it invisible to `findPendingSessionByHash()`. |
 
 ### Invites (alternative path)
 
@@ -171,7 +171,7 @@ sequenceDiagram
 
         U->>A: Send "847293" on same channel
         A->>A: parseGuardianVerifyCommand() → bare 6-digit code
-        A->>A: validateAndConsumeChallenge()
+        A->>A: validateAndConsumeVerification()
         A->>A: Identity check: actorId matches expected
         A->>A: Hash matches, not expired → consume
         A->>A: upsertContactChannel(status: 'active', policy: 'allow')
@@ -211,20 +211,20 @@ sequenceDiagram
 ### Verification code expires
 
 - Verification sessions have a 10-minute TTL (`CHALLENGE_TTL_MS`).
-- After expiry, `findPendingChallengeByHash()` filters by `expiresAt > now`, so the code silently becomes invalid.
+- After expiry, `findPendingSessionByHash()` filters by `expiresAt > now`, so the code silently becomes invalid.
 - The requester receives the generic "code is invalid or has expired" message.
 - The guardian can re-initiate the flow by approving again, which creates a new session (auto-revoking any prior pending sessions).
 
 ### Wrong code entered
 
-- `validateAndConsumeChallenge()` hashes the input and looks for a matching challenge. No match returns a generic failure.
+- `validateAndConsumeVerification()` hashes the input and looks for a matching session. No match returns a generic failure.
 - The invalid attempt is recorded via `recordInvalidAttempt()` with a sliding window (`RATE_LIMIT_WINDOW_MS = 15 min`).
 - After `RATE_LIMIT_MAX_ATTEMPTS = 5` failures within the window, the actor is locked out for `RATE_LIMIT_LOCKOUT_MS = 30 min`.
 - The lockout message is identical to the "invalid code" message (anti-oracle).
 
 ### Identity mismatch
 
-- If the code is entered from a different channel identity than expected (e.g., a different Telegram user ID), the identity check in `validateAndConsumeChallenge()` fails.
+- If the code is entered from a different channel identity than expected (e.g., a different Telegram user ID), the identity check in `validateAndConsumeVerification()` fails.
 - The error message is identical to "invalid or expired" to prevent identity oracle attacks.
 - The attempt counts toward the rate limit.
 
@@ -250,9 +250,9 @@ sequenceDiagram
 
 ### Code reuse prevention
 
-- Each verification session creates a single `channel_guardian_verification_challenges` record.
-- `consumeChallenge()` atomically sets `status: 'consumed'`, making the code permanently unusable.
-- `findPendingChallengeByHash()` only matches challenges with `status IN ('pending', 'pending_bootstrap', 'awaiting_response')`, so consumed challenges are invisible.
+- Each verification session creates a single `channel_verification_sessions` record.
+- `consumeSession()` atomically sets `status: 'consumed'`, making the code permanently unusable.
+- `findPendingSessionByHash()` only matches sessions with `status IN ('pending', 'pending_bootstrap', 'awaiting_response')`, so consumed sessions are invisible.
 
 ### Session supersession
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vellumai/assistant",
-  "version": "0.4.41",
+  "version": "0.4.43",
   "type": "module",
   "bin": {
     "assistant": "./src/index.ts"
@@ -10,13 +10,8 @@
     "daemon:restart:http": "RUNTIME_HTTP_PORT=7821 bun run src/index.ts daemon restart",
     "db:generate": "drizzle-kit generate",
     "db:push": "drizzle-kit push",
-    "ipc:inventory": "bun run scripts/ipc/check-contract-inventory.ts",
-    "ipc:inventory:update": "bun run scripts/ipc/check-contract-inventory.ts --update",
-    "generate:ipc": "bun run scripts/ipc/generate-swift.ts",
-    "check:ipc-generated": "bun run scripts/ipc/generate-swift.ts --check",
     "format": "prettier --write .",
     "format:check": "prettier --check .",
-    "ipc:check-swift-drift": "bun run scripts/ipc/check-swift-decoder-drift.ts",
     "lint": "eslint",
     "typecheck": "bunx tsc --noEmit",
     "test": "bash scripts/test.sh",
@@ -24,12 +19,13 @@
     "test:stable": "EXCLUDE_EXPERIMENTAL=true bash scripts/test.sh",
     "test:bench": "find src/__tests__ -maxdepth 1 -type f -name '*.benchmark.test.ts' -print0 | xargs -0 -P 1 -I {} bun test {}",
     "test:filesystem-tools": "bash scripts/test-filesystem-tools.sh",
-    "postinstall": "cd .. && git config core.hooksPath .githooks 2>/dev/null || true"
+    "postinstall": "cd .. && git config core.hooksPath || git config core.hooksPath .githooks 2>/dev/null || true"
   },
   "dependencies": {
     "@anthropic-ai/claude-agent-sdk": "^0.2.42",
     "@anthropic-ai/sdk": "^0.39.0",
     "@google/genai": "^1.40.0",
+    "@hono/node-server": "^1.19.11",
     "@modelcontextprotocol/sdk": "^1.15.1",
     "@qdrant/js-client-rest": "^1.16.2",
     "@sentry/node": "^10.38.0",
@@ -40,6 +36,7 @@
     "dotenv": "^17.3.1",
     "drizzle-orm": "^0.38.4",
     "esbuild": "^0.24.0",
+    "hono": "^4.12.5",
     "ink": "^6.7.0",
     "jszip": "^3.10.1",
     "minimatch": "^10.2.4",
@@ -47,8 +44,8 @@
     "pino": "^9.6.0",
     "pino-pretty": "^13.1.3",
     "playwright": "^1.58.2",
-    "preact": "^10.25.0",
     "postgres": "^3.4.8",
+    "preact": "^10.25.0",
     "qrcode": "^1.5.4",
     "react": "^19.2.4",
     "rrule": "^2.8.1",

package/src/__tests__/access-request-decision.test.ts

@@ -57,12 +57,12 @@ mock.module("../runtime/gateway-client.js", () => ({
   },
 }));
 
+import { getDb, initializeDb, resetDb } from "../memory/db.js";
 import {
   createApprovalRequest,
   getApprovalRequestById,
-} from "../memory/channel-guardian-store.js";
-import { getDb, initializeDb, resetDb } from "../memory/db.js";
-import { findActiveSession } from "../runtime/channel-guardian-service.js";
+} from "../memory/guardian-approvals.js";
+import { findActiveSession } from "../runtime/channel-verification-service.js";
 import {
   deliverVerificationCodeToGuardian,
   handleAccessRequestDecision,
@@ -91,7 +91,7 @@ const GUARDIAN_APPROVAL_TTL_MS = 5 * 60 * 1000;
 function resetState(): void {
   const db = getDb();
   db.run("DELETE FROM channel_guardian_approval_requests");
-  db.run("DELETE FROM channel_guardian_verification_challenges");
+  db.run("DELETE FROM channel_verification_sessions");
   deliverReplyCalls.length = 0;
 }