create-walle 0.9.19 → 0.9.21

package/README.md

@@ -12,7 +12,7 @@ A web dashboard for running and managing AI coding sessions across multiple prov
 - **Prompt Editor** — Save, version, and organize prompts with folders, tags, chains, templates, and AI search
 - **Task Queue** — Queue prompts for sequential execution with auto-advance when the agent finishes, or step through manually
 - **Approval Workflows** — Auto-approve tool-use requests based on learned rules; uncertain cases escalate to you
-- **Remote Phone Access** — Pair your phone with a QR code and use a mobile CTM UI over Microsoft Dev Tunnels, Tailscale, Cloudflare Tunnel, or Walle Remote
+- **Remote Phone Access** — Pair your phone with a QR code and use a mobile CTM UI over Microsoft Dev Tunnels, Tailscale, Cloudflare Tunnel, or Walle Remote, with live prompts and model controls
 - **Code & Doc Review** — Review git diffs and Markdown docs side by side, add anchored comments, and send feedback into an agent session or queue
 - **Model Registry** — Manage providers (Anthropic, OpenAI, Google, DeepSeek, Ollama, LM Studio, MLX, and CLI subscription providers), compare pricing, switch models per session
 - **Session Insights** — Analyze patterns across sessions to optimize prompts and workflows
@@ -62,7 +62,7 @@ On first launch, the browser setup page guides you through:
 1. **Owner name** — auto-detected from `git config`
 2. **API key** — enter manually, or click "Auto-detect" to find it from your shell environment, Claude Code OAuth, or corporate devbox
 3. **Integrations** — connect Slack (OAuth), email and calendar auto-detected on macOS
-4. **Remote phone access** — optional QR pairing with Microsoft Dev Tunnels, Tailscale, Cloudflare Tunnel, or Walle Remote
+4. **Remote phone access** — optional QR pairing with Microsoft Dev Tunnels, Tailscale, Cloudflare Tunnel, or Walle Remote, including phone-friendly prompts and model controls
 
 ## Custom Port
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-walle",
-  "version": "0.9.19",
+  "version": "0.9.21",
   "description": "CTM + Wall-E \u2014 AI coding dashboard and personal digital twin agent. Multi-agent terminal for Claude Code, Codex, Gemini, Aider, OpenCode, and more, plus prompt editor, task queue, remote phone access, code/doc review, and an agent that learns from Slack, email & calendar.",
   "bin": {
     "create-walle": "bin/create-walle.js"

package/template/claude-task-manager/db.js

@@ -1459,6 +1459,47 @@ function migrateSchemaIfNeeded() {
       // column presence before writing title-generation status.
     }
   }
+  if (getSchemaVersion() < 6) {
+    try {
+      migrateToV6();
+    } catch (e) {
+      console.error('[db] Schema migration to v6 FAILED:', e.message);
+      console.error('[db] Stack:', e.stack);
+      // Non-fatal: Wall-E can still fall back to startup_tasks/model defaults,
+      // but per-session model preferences will not persist until this succeeds.
+    }
+  }
+}
+
+/**
+ * Schema v6: Persist session-scoped model preferences.
+ *
+ * startup_tasks.model_id is a restore hint and intentionally has no provider
+ * identity. Wall-E session model changes need a CTM-owned durable preference so
+ * one tab's model switch cannot mutate Wall-E global defaults or another tab.
+ */
+function migrateToV6() {
+  const d = getDb();
+  d.exec(`
+    CREATE TABLE IF NOT EXISTS session_model_preferences (
+      ctm_session_id TEXT PRIMARY KEY,
+      agent_type TEXT NOT NULL DEFAULT 'walle',
+      provider_type TEXT NOT NULL DEFAULT '',
+      provider_id TEXT NOT NULL DEFAULT '',
+      model_id TEXT NOT NULL DEFAULT '',
+      registry_id TEXT NOT NULL DEFAULT '',
+      scope TEXT NOT NULL DEFAULT 'session',
+      source TEXT NOT NULL DEFAULT 'user',
+      pinned INTEGER NOT NULL DEFAULT 1,
+      created_at TEXT DEFAULT (datetime('now')),
+      updated_at TEXT DEFAULT (datetime('now')),
+      FOREIGN KEY (ctm_session_id) REFERENCES ctm_sessions(id) ON DELETE CASCADE
+    );
+    CREATE INDEX IF NOT EXISTS idx_session_model_preferences_agent
+      ON session_model_preferences(agent_type, updated_at DESC);
+  `);
+  setSchemaVersion(6);
+  console.log('[db] Schema migrated to v6 (session model preferences)');
 }
 
 /**
@@ -3268,6 +3309,95 @@ function getInsightsData(includeInternal) {
   };
 }
 
+// --- Session Model Preferences ---
+function _cleanSessionModelPreferenceInput(input = {}) {
+  const clean = (value, max) => String(value || '').trim().slice(0, max);
+  return {
+    ctmSessionId: clean(input.ctmSessionId || input.ctm_session_id || input.sessionId || input.id, 160),
+    agentType: clean(input.agentType || input.agent_type || 'walle', 60) || 'walle',
+    providerType: clean(input.providerType || input.provider_type || input.model_provider || input.provider, 120),
+    providerId: clean(input.providerId || input.provider_id, 160),
+    modelId: clean(input.modelId || input.model_id || input.model, 256),
+    registryId: clean(input.registryId || input.registry_id || input.model_registry_id, 256),
+    scope: clean(input.scope || 'session', 40) || 'session',
+    source: clean(input.source || 'user', 80) || 'user',
+    pinned: input.pinned === false || input.pinned === 0 ? 0 : 1,
+  };
+}
+
+function upsertSessionModelPreference(input = {}) {
+  const item = _cleanSessionModelPreferenceInput(input);
+  if (!item.ctmSessionId) throw new Error('ctmSessionId is required');
+  if (!item.modelId) {
+    clearSessionModelPreference(item.ctmSessionId);
+    return null;
+  }
+  const d = getDb();
+  d.prepare(
+    "INSERT OR IGNORE INTO ctm_sessions (id, provider, updated_at) VALUES (?, ?, datetime('now'))"
+  ).run(item.ctmSessionId, item.agentType || 'walle');
+  d.prepare(`
+    INSERT INTO session_model_preferences (
+      ctm_session_id, agent_type, provider_type, provider_id, model_id,
+      registry_id, scope, source, pinned, updated_at
+    )
+    VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, datetime('now'))
+    ON CONFLICT(ctm_session_id) DO UPDATE SET
+      agent_type = excluded.agent_type,
+      provider_type = excluded.provider_type,
+      provider_id = excluded.provider_id,
+      model_id = excluded.model_id,
+      registry_id = excluded.registry_id,
+      scope = excluded.scope,
+      source = excluded.source,
+      pinned = excluded.pinned,
+      updated_at = excluded.updated_at
+  `).run(
+    item.ctmSessionId, item.agentType, item.providerType, item.providerId,
+    item.modelId, item.registryId, item.scope, item.source, item.pinned
+  );
+  flushWal();
+  return getSessionModelPreference(item.ctmSessionId);
+}
+
+function getSessionModelPreference(ctmSessionId) {
+  const id = String(ctmSessionId || '').trim();
+  if (!id) return null;
+  const row = getDb().prepare(
+    'SELECT * FROM session_model_preferences WHERE ctm_session_id = ?'
+  ).get(id);
+  if (!row) return null;
+  return {
+    ctm_session_id: row.ctm_session_id,
+    ctmSessionId: row.ctm_session_id,
+    agent_type: row.agent_type || 'walle',
+    agentType: row.agent_type || 'walle',
+    provider_type: row.provider_type || '',
+    providerType: row.provider_type || '',
+    provider_id: row.provider_id || '',
+    providerId: row.provider_id || '',
+    model_id: row.model_id || '',
+    modelId: row.model_id || '',
+    registry_id: row.registry_id || '',
+    registryId: row.registry_id || '',
+    scope: row.scope || 'session',
+    source: row.source || 'user',
+    pinned: row.pinned !== 0,
+    created_at: row.created_at || '',
+    updated_at: row.updated_at || '',
+  };
+}
+
+function clearSessionModelPreference(ctmSessionId) {
+  const id = String(ctmSessionId || '').trim();
+  if (!id) return 0;
+  const changes = getDb().prepare(
+    'DELETE FROM session_model_preferences WHERE ctm_session_id = ?'
+  ).run(id).changes || 0;
+  if (changes) flushWal();
+  return changes;
+}
+
 // --- Startup Tasks (crash-safe session restore) ---
 const CTM_INSTANCE_ID = `${require('os').hostname()}:${process.pid}:${Date.now()}`;
 
@@ -5013,6 +5143,7 @@ module.exports = {
   replaceInsightRecommendations, listInsightRecommendations,
   startAnalysisRun, completeAnalysisRun, getLastAnalysisRun,
   getInsightsData,
+  upsertSessionModelPreference, getSessionModelPreference, clearSessionModelPreference,
   addStartupTask, updateStartupTaskLabel, updateStartupTaskClaudeSession, updateStartupTaskAgentSession, updateStartupTaskBranch, updateStartupTaskCwd, removeStartupTask, markStartupTaskExited, heartbeatStartupTasks, getStartupTask, listStartupTasks, clearStartupTasks,
   createSessionWithStartupTask,
   appendScrollbackBatch, cleanupScrollbackChunkSeqIntegrity, getNextScrollbackSeq, loadScrollback, loadScrollbackTail, clearScrollback,

package/template/claude-task-manager/docs/microsoft-dev-tunnel-phone-access-design.md

@@ -1,7 +1,7 @@
 # Microsoft Dev Tunnel Phone Access Design
 
-Status: Draft for implementation review
-Date: 2026-05-10
+Status: Implementation update
+Date: 2026-05-19
 Owner: CTM / Wall-E
 Related docs:
 - `claude-task-manager/docs/phone-access-design.md`
@@ -30,11 +30,12 @@ product direction. It should sit in `Setup -> Access` as a practical fallback:
 
 ```text
 iPhone browser
-  -> devtunnels.ms browser URL
+  -> private devtunnels.ms browser URL
+  -> Microsoft/GitHub Dev Tunnels login gate
   -> Azure Dev Tunnels service
   -> devtunnel host process on Mac
   -> local CTM on 127.0.0.1:3456
-  -> CTM mobile device claim + passkey pairing
+  -> CTM mobile device claim + optional passkey step-up
 ```
 
 The design goal is to make the flow feel like "sign in on the Mac, start
@@ -67,23 +68,23 @@ It is not best when:
 - the user requires relay-blind E2E payload privacy;
 - long-running production availability is required;
 - company policy blocks Microsoft Dev Tunnels domains;
-- the user cannot accept a public browser tunnel that is protected at the CTM
-  application layer.
+- the user cannot sign into the same Microsoft/GitHub identity on the phone;
+- company policy blocks Microsoft Dev Tunnels domains or browser sign-in.
 
 ## Design Principles
 
-1. **Keep Microsoft/GitHub sign-in on the Mac.** The user signs in once to
-   manage Dev Tunnels. The phone should not need a second Microsoft/GitHub
-   browser login.
-2. **Use a port-scoped browser access rule.** CTM enables anonymous `connect`
-   only for the CTM tunnel port, because normal mobile Safari/Chrome navigation
-   cannot attach Dev Tunnel access headers. CTM auth remains the security
-   boundary.
+1. **Keep the tunnel private.** Microsoft Dev Tunnels are private by default.
+   CTM must not create anonymous `connect` access automatically. The phone
+   signs into Microsoft/GitHub before Dev Tunnels forwards anything to CTM.
+2. **Use CTM auth after the Microsoft gate.** Microsoft/GitHub login decides
+   whether the phone can reach the tunnel. CTM device pairing, scopes, audit,
+   and revocation decide what that browser is allowed to do after it reaches
+   CTM.
 3. **Use a stable tunnel origin.** CTM device cookies and WebAuthn passkeys are
    origin-scoped. Temporary tunnel URLs create confusing re-pairing failures.
 4. **Make Microsoft gate failures diagnosable.** If Microsoft returns 401 or an
-   auth redirect, the phone request has not reached CTM and the access rule must
-   be repaired.
+   auth redirect, the phone request has not reached CTM. In private mode that
+   is expected until the phone signs in with the same tunnel identity.
 5. **Separate tunnel readiness from phone pairing.** A running tunnel only
    means the network path exists. The phone still needs CTM pairing and local
    Mac approval.
@@ -114,8 +115,8 @@ It is not best when:
    - `Use device code`
 8. CTM creates or reuses a persistent CTM tunnel ID.
 9. CTM creates or verifies port `3456` with protocol `http`.
-10. CTM creates or verifies an anonymous `connect` access entry scoped to port
-    `3456`.
+10. CTM resets port access to the Dev Tunnels default so stale anonymous access
+    is removed.
 11. CTM starts `devtunnel host <tunnel-id>` as a managed child process.
 12. CTM parses the `https://...devtunnels.ms` URL from stdout.
 13. CTM updates the phone origin allowlist for that exact URL.
@@ -131,8 +132,9 @@ It is not best when:
    URL.
 3. Microsoft may show:
    - anti-phishing interstitial;
-   - a tunnel auth error if the port-scoped access entry was removed or expired.
-4. Microsoft forwards the browser to CTM.
+   - Microsoft/GitHub sign-in;
+   - access denied if the phone signs into the wrong account.
+4. After the private gate passes, Microsoft forwards the browser to CTM.
 5. CTM mobile claim page says:
 
    ```text
@@ -140,7 +142,8 @@ It is not best when:
    This phone still needs CTM pairing.
    ```
 
-6. User registers Face ID/passkey for this CTM origin.
+6. CTM issues a device token for this phone. Passkey registration is used for
+   high-risk step-up, not as the primary proof that the phone can reach CTM.
 7. Mac shows:
 
    ```text
@@ -338,15 +341,16 @@ Quick fallback
 Body:
 
 ```text
-Use a Microsoft-hosted browser tunnel to open CTM from your phone. No DNS, VPN,
-or phone-side Microsoft/GitHub login.
+Use a private Microsoft-hosted browser tunnel to open CTM from your phone. No
+DNS or VPN; the phone signs into the same Microsoft/GitHub tunnel account.
 ```
 
 Security note:
 
 ```text
-This is a tunnel fallback, not Walle Remote. CTM pairing, passkey, and device
-permissions are still required.
+This is a tunnel fallback, not Walle Remote. Keep anonymous access off. CTM
+pairing, device permissions, and passkey step-up still apply after the private
+Microsoft gate.
 ```
 
 Primary button by state:
@@ -437,7 +441,7 @@ This account manages the tunnel on this Mac only.
 
 Default settings:
 
-- Access: `Port-scoped browser access`
+- Access: `Private Microsoft/GitHub account access`
 - Tunnel kind: `Persistent`
 - Port: `3456`
 - Protocol: `http`
@@ -453,26 +457,27 @@ Running state:
 
 ```text
 Tunnel running
-Phone access is protected by CTM pairing and passkey.
+Phone access requires the same Microsoft/GitHub account plus CTM pairing.
 ```
 
-Do not offer broad tunnel-level public mode. CTM should create only the
-port-scoped anonymous `connect` rule required for browser navigation.
+Do not offer broad tunnel-level public mode. CTM should reset stale anonymous
+rules back to Microsoft Dev Tunnels defaults rather than creating new anonymous
+rules.
 
 ### Step: Pair Phone
 
-Show only after the tunnel is running, the CTM port access rule is present, and
-CTM has an exact allowed origin.
+Show only after the tunnel is running, the tunnel access is private, and CTM has
+an exact allowed origin.
 
 Content:
 
 ```text
-Scan with iPhone. Face ID/passkey pairing protects this device.
+Scan with iPhone. First sign into the tunnel account below if Microsoft asks.
 
 Use this account:
 user@example.com
 
-Then CTM will ask this Mac to approve the phone.
+Then CTM pairs this browser and records its device permissions.
 ```
 
 QR payload:
@@ -524,7 +529,7 @@ Tunnel account: user@example.com
 Mac: User's MacBook
 Access: Read, Respond
 
-[Pair with Face ID]
+[Pair this phone]
 ```
 
 If the user is on an unexpected origin:
@@ -560,7 +565,8 @@ not the task.
 | --- | --- | --- |
 | CLI missing | `Microsoft devtunnel CLI is not installed.` | Install, then refresh |
 | Auth missing | `Sign into Microsoft or GitHub before starting a tunnel.` | Sign in / device code |
-| Access rule missing | `Microsoft tunnel access is blocking the phone URL.` | Recover Now re-applies the port-scoped access rule |
+| Microsoft sign-in required | `Microsoft is asking the phone to sign in before CTM can load.` | Sign in on the phone with the account shown on the Mac |
+| Anonymous access found | `This tunnel has public browser access enabled.` | CTM resets the port access to private before showing Ready |
 | Tunnel start failed | `Tunnel did not start.` | Retry, copy diagnostics |
 | Temporary URL changed | `This phone link belongs to an old tunnel.` | Reuse persistent tunnel or re-pair |
 | Origin not allowed | `CTM has not trusted this tunnel URL yet.` | Refresh setup, save origin |
@@ -573,14 +579,16 @@ not the task.
 
 ### Required
 
-- Microsoft/GitHub account required on the Mac for tunnel management only.
-- The phone can open the browser URL without Microsoft/GitHub tunnel sign-in.
-- CTM device claim and passkey pairing still required.
+- Microsoft/GitHub account required on the Mac for tunnel management.
+- The phone must pass the Microsoft/GitHub private tunnel gate before CTM sees
+  the request.
+- CTM device claim is still required so CTM can name, scope, revoke, and audit
+  the browser/device.
 - Local Mac approval required for first phone pairing.
 - CTM route authorization registry still applies.
-- High-risk CTM actions still require step-up.
-- Anonymous access is port-scoped to the CTM tunnel and is not a substitute for
-  CTM device auth.
+- High-risk CTM actions still require passkey step-up when the browser has a
+  CTM passkey registered for this origin.
+- Anonymous access is disabled by default and should not be created by CTM.
 - No tunnel access tokens in QR codes.
 - No inspect URL shown in the primary UI.
 
@@ -593,10 +601,10 @@ trusted transport path.
 
 That is acceptable for a fallback tunnel if:
 
+- the Microsoft/GitHub private gate remains on;
 - CTM app-layer auth remains strong;
-- only the CTM port has anonymous browser connect access;
-- the user understands that the tunnel URL is publicly reachable but not usable
-  without CTM pairing/passkey/device auth;
+- the user understands that Dev Tunnels is a Microsoft-hosted relay, not an E2E
+  blind relay;
 - sensitive long-running remote access moves to Walle Remote once available.
 
 ## Implementation Notes
@@ -610,7 +618,7 @@ Store:
 - port;
 - protocol;
 - signed-in account display;
-- port-scoped anonymous connect access status;
+- private access status and whether stale anonymous access was removed;
 - expiration timestamp if available;
 - managed process PID;
 - last stdout/stderr lines for diagnostics;
@@ -639,7 +647,7 @@ the Cloudflare fallback process model:
 - user signed in;
 - persistent tunnel exists;
 - port `3456` configured;
-- port `3456` has an anonymous browser `connect` access entry;
+- stale anonymous browser `connect` access is absent;
 - host process running;
 - CTM allowed origin includes the tunnel URL;
 - CTM device claim can be generated for that origin.
@@ -677,7 +685,7 @@ Negative cases:
 - tunnel host process crash;
 - tunnel URL changes;
 - CTM allowed origin missing;
-- Microsoft Dev Tunnel access entry removed or expired;
+- stale anonymous access left by an older CTM build;
 - high-risk action without CTM step-up.
 
 ## MVP Cut Line
@@ -688,7 +696,7 @@ MVP includes:
 - CLI detection;
 - sign-in status and account display;
 - persistent tunnel create/reuse;
-- port-scoped anonymous `connect` access create/reuse;
+- private access reset/check so stale anonymous browser access is removed;
 - managed `devtunnel host` process;
 - exact origin allowlist;
 - phone pairing QR;
@@ -697,7 +705,7 @@ MVP includes:
 
 MVP excludes:
 
-- broad tunnel-level anonymous mode;
+- anonymous browser access;
 - team/tenant/org access controls;
 - tunnel access tokens for phone;
 - traffic inspection UI;
@@ -708,5 +716,5 @@ MVP excludes:
 Build Microsoft Dev Tunnel as a polished fallback because it removes most of
 the Cloudflare setup burden. Do not position it as the primary Walle Remote
 solution. The UI should be honest: it is fast and browser-only, but it is still
-a Microsoft-hosted public browser tunnel protected by CTM's own auth, not an
-E2E typed relay.
+a Microsoft-hosted private browser tunnel plus CTM device auth, not an E2E
+typed relay.

package/template/claude-task-manager/docs/phone-access-design.md

@@ -25,6 +25,12 @@ browser fallback that avoids VPN, DNS, and Cloudflare setup, but it is still a
 tunnel transport rather than the Walle Relay product path. See
 `claude-task-manager/docs/microsoft-dev-tunnel-phone-access-design.md`.
 
+2026-05-19 private Microsoft Tunnel update: Microsoft Dev Tunnel must stay
+private by default. CTM no longer creates anonymous Dev Tunnel browser access.
+The phone signs into the same Microsoft/GitHub identity used by `devtunnel` on
+the Mac before Microsoft forwards traffic to CTM. CTM still issues its own
+device token for scopes, revocation, audit, and optional passkey step-up.
+
 ---
 
 ## 1. Goals, non-goals, success criteria
@@ -457,6 +463,9 @@ The QR flow must never put the raw long-lived device token in the URL.
 WebAuthn RP ID rule:
 - A passkey registered on `https://<tailnet-host>:3456` is scoped to that
   tailnet hostname. It will not automatically work on `https://ctm.example.com`.
+- A passkey registered on `https://<tunnel>.devtunnels.ms` is scoped to that
+  Dev Tunnel hostname. It verifies a CTM-registered credential for this origin;
+  it does not prove which Microsoft/GitHub account passed the Dev Tunnel gate.
 - If Cloudflare fallback is enabled, the phone must enroll a second credential
   for the Cloudflare origin, tied to the same `device_token_id`.
 - Store `rp_id` and `origin` per credential and pick the verification options
@@ -489,9 +498,12 @@ explicit upgrade. The desktop loopback is always all-scope.
 
 ### 5.4 WebAuthn passkey for mutations (G3)
 
-Even with a valid token, **mutating** routes require a fresh WebAuthn
+Even with a valid token, **high-risk** routes require a fresh WebAuthn
 assertion (a "step-up" challenge). The phone's iOS Face ID / Secure Enclave
-makes this near-frictionless.
+makes this near-frictionless. In private Microsoft Tunnel mode, passkey is not
+the primary login proof; Microsoft/GitHub gates reachability before CTM sees the
+request. Passkey is an app-layer confirmation for sensitive CTM actions and a
+backup if a CTM device token/cookie is copied out of the browser.
 
 **Library**: `@simplewebauthn/server` + `@simplewebauthn/browser` (mature,
 Node-native, used by Auth.js).
@@ -506,15 +518,17 @@ Node-native, used by Auth.js).
 6. Mutating routes require both `ctm_token` AND `ctm_step_up`.
 
 **Operations that require step-up**
-- Every remote WS `input`.
-- Every remote approval / denial / permission response.
-- Every `walle-message` that can invoke tools or skills.
+- Remote approval / denial / permission response.
+- `walle-message` only when Wall-E will execute tools, skills, or external
+  actions rather than plain chat.
 - Spawn, kill, restart, cancel.
 - Worktree create / delete / merge / create-pr.
 - Settings, token, notification, and Cloudflare Access configuration changes.
 
-Read-only routes (status, search, messages, watch streams) do **not** require
-step-up. The friction budget belongs to actions that can change machine state.
+Read-only routes (status, search, messages, watch streams) and low-risk replies
+do **not** require step-up when the transport is private and the CTM device
+token is valid. The friction budget belongs to actions that can change machine
+state or approve privileged agent behavior.
 
 Step-up UX:
 - The phone presents an inline "Confirm with Face ID" sheet only after the user
@@ -1216,6 +1230,8 @@ banner appears within 5 s; tap → unlocks → opens to detail.
 | R14 | Idle hook creates noisy or false high-priority notifications        | High-priority push only from `waiting_input`, approval detection, crash, or explicit task transition |
 | R15 | Offline phone replays stale mutation after reconnect                | Do not queue mutations offline; user must re-open action and step up again |
 | R16 | Passkey registered on tailnet origin fails on Cloudflare origin     | Store `rp_id`/origin per credential; require separate credential enrollment per origin |
+| R17 | Anonymous Dev Tunnel access exposes CTM pairing and app auth to the public internet | Do not create anonymous access; reset stale port access to Dev Tunnels defaults; UI labels Microsoft Tunnel as private |
+| R18 | User mistakes passkey for Microsoft account verification            | UI and docs say Microsoft/GitHub identity is checked by Dev Tunnels; CTM passkey only proves a registered credential for this origin |
 
 ### 10.2 Decisions from review
 

package/template/claude-task-manager/docs/walle-session-model-preferences.md

@@ -0,0 +1,119 @@
+# Wall-E Session Model Preferences
+
+## Problem
+
+Wall-E coding sessions need model switches to behave like session state, not
+global Wall-E configuration. A user changing one CTM Wall-E tab from DeepSeek to
+Kimi must not change the model used by any other Wall-E tab, future Wall-E chat,
+or the Wall-E brain default provider.
+
+The current CTM paths keep only partial state:
+
+- The browser stores the picker selection in `walleState`.
+- Each Wall-E JSONL turn records the provider/model used for that turn.
+- `startup_tasks.model_id` may preserve a model restore hint, but it has no
+  provider column and is lifecycle cache rather than session truth.
+- Wall-E brain metadata stores global defaults such as `walle_provider` and
+  `walle_model`.
+
+These are useful but not the right owner for a durable per-tab preference.
+
+## Ownership
+
+CTM owns the tab and its session-scoped model preference.
+
+Wall-E owns provider registry, provider credentials, scorecards, global defaults,
+and the chat runtime. Wall-E should receive an explicit provider/model when CTM
+has a session preference, but CTM must not mutate Wall-E global defaults from the
+session picker.
+
+Wall-E JSONL owns audit history. It records which provider/model was used for a
+turn, but it is not the preference source of truth.
+
+`startup_tasks` owns crash restore lifecycle. It may mirror a model id for
+backward compatibility, but it must not become the authoritative provider/model
+mapping.
+
+## Data Model
+
+CTM persists Wall-E session preferences in `session_model_preferences`:
+
+```sql
+CREATE TABLE session_model_preferences (
+  ctm_session_id TEXT PRIMARY KEY,
+  agent_type TEXT NOT NULL DEFAULT 'walle',
+  provider_type TEXT NOT NULL DEFAULT '',
+  provider_id TEXT NOT NULL DEFAULT '',
+  model_id TEXT NOT NULL DEFAULT '',
+  registry_id TEXT NOT NULL DEFAULT '',
+  scope TEXT NOT NULL DEFAULT 'session',
+  source TEXT NOT NULL DEFAULT 'user',
+  pinned INTEGER NOT NULL DEFAULT 1,
+  created_at TEXT DEFAULT (datetime('now')),
+  updated_at TEXT DEFAULT (datetime('now')),
+  FOREIGN KEY (ctm_session_id) REFERENCES ctm_sessions(id) ON DELETE CASCADE
+);
+```
+
+The source-of-truth columns are `ctm_session_id`, `provider_type`, `model_id`,
+and optional `registry_id`. `provider_id` is kept for exact provider-route
+diagnostics when a provider type has multiple routes.
+
+## Resolution Order
+
+When CTM sends a Wall-E prompt, model selection resolves in this order:
+
+1. Explicit per-message override from the client.
+2. CTM `session_model_preferences` for the `ctm_session_id`.
+3. Hydrated in-memory session model fields.
+4. Wall-E global default for new/unconfigured sessions.
+5. Wall-E scorecard/provider fallback.
+
+Pinned manual session preferences disable provider fallback for that turn unless
+the user explicitly opts into fallback.
+
+## Events
+
+The Wall-E model picker emits a session-scoped `model-change` message:
+
+```json
+{
+  "type": "model-change",
+  "id": "ctm-session-id",
+  "agent_type": "walle",
+  "model_id": "kimi-k2.6",
+  "model_provider": "moonshot",
+  "model_registry_id": "moonshot-default:kimi-k2.6",
+  "scope": "session"
+}
+```
+
+The server validates and persists the preference, updates only that in-memory
+session, refreshes the startup restore hint, and broadcasts `walle-model` to the
+affected session clients.
+
+## Invariants
+
+- Changing the model in Wall-E session A never updates Wall-E brain keys
+  `walle_provider`, `walle_model`, or `walle_model_*`.
+- Changing the model in Wall-E session A never changes session B's
+  `session_model_preferences` row.
+- Restore hydrates provider and model from CTM session preference before using a
+  lifecycle hint or Wall-E global default.
+- JSONL turn metadata can explain historical routing but does not overwrite the
+  session preference.
+- `startup_tasks.model_id` is a compatibility hint only; missing provider
+  information there must not cause cross-provider routing.
+
+## Tests
+
+Coverage should include:
+
+- DB preference upsert/read/delete with cascade behavior.
+- Wall-E picker sends provider-native model id plus provider type.
+- A manual selection persists in CTM and is reused on the next prompt.
+- Restored Wall-E sessions hydrate provider/model from
+  `session_model_preferences`, not only `startup_tasks`.
+- Two Wall-E sessions can choose different providers without cross-session
+  mutation.
+- Wall-E global default keys remain unchanged by session picker changes.