@rikaidev/yomi 0.3.1 → 0.4.1

package/dist/mcp/handlers/login.js

@@ -1,103 +1,24 @@
-/**
- * Yomi MCP `login`/`login_complete` handlers.
- *
- * Split out of handlers.ts purely to keep that file (the general tool
- * handler surface) under the project's 500-scc-line module cap; behavior
- * owned here is otherwise unchanged in spirit from what previously lived
- * inline there.
- *
- * Two login paths exist, dispatched by client capability:
- *
- *   - Elicitation clients: the original single-call flow — elicit phone/
- *     region, elicit PIN acknowledgement, block to completion. Unchanged.
- *
- *   - Non-elicitation clients (e.g. Claude Desktop, confirmed empirically —
- *     it does not support MCP elicitation): the PIN has nowhere to go if we
- *     block, since it is produced mid-flow and stderr is invisible to the
- *     human, but a tool RESULT is visible. So the flow is split across two
- *     tool calls: `login` starts the passwordless flow and returns the PIN
- *     as soon as LINE issues it (bounded wait), then `login_complete`
- *     awaits the same in-flight login to finish once the human has acted
- *     on their phone.
- *
- * Both paths call the ONE shared login sequence in ../cli/login.ts
- * (`runPwlessLogin`) — neither duplicates it.
- */
 import { runPwlessLogin } from '../../cli/login.js';
 import { LINE_PIN_CODE_LIFETIME_MS, PAAK_AUTH_CLIENT_CEILING_MS, PIN_VERIFY_CLIENT_CEILING_MS, } from '../../line/auth/pwless/index.js';
 import { createCliLogger } from '../../util/log.js';
+import { supportsFormElicitation } from '../client-capabilities.js';
 import { supportsMcpApps } from '../ui/capability.js';
+import { buildAcknowledgementForm, buildPreflightForm, certSteps, LOGIN_REGIONS, PRIMARY_DEVICE_SETTING_PATH, pinSteps, prerequisiteNotMetResult, readPreflightForm, } from './login-copy.js';
+import { handleLoginMrtr } from './login-mrtr.js';
+import { finishPendingLogin, getLivePendingLogin, getPendingLogin, PIN_WAIT_TIMEOUT_MS, startPendingLogin, waitForPin, } from './login-session.js';
 import { jsonText, toolError } from './shared.js';
 const log = createCliLogger('Yomi');
-/** LINE region codes offered on the login elicitation form. */
-const LOGIN_REGIONS = ['TW', 'JP', 'TH', 'ID', 'US'];
-/**
- * How long a live `pendingLogin` may be reused by a later `login` call for
- * the same phone/region, before treating it as stale and starting fresh.
- *
- * This is bound to LINE's real PIN code lifetime (~line/auth/pwless/index.ts,
- * an external fact from LINE Help Center, ~3 minutes) — NOT to how long
- * yomi's client is willing to keep polling (~16 minutes). A login started
- * 90 seconds ago is still very much alive and its PIN is still valid; the
- * only thing that actually kills a pending login early is LINE's own code
- * expiring, so that is the correct bound for "is this still worth reusing".
- */
-const PIN_WINDOW_MS = LINE_PIN_CODE_LIFETIME_MS;
 /**
  * How long yomi's client keeps polling for the device-approval step once a
  * PIN has been verified (or skipped via a stored certificate) — the real
- * ceiling `login_complete` blocks for, used only to describe that wait to
+ * ceiling the completing call blocks for, used only to describe that wait to
  * the human, not to bound anything server-side.
  */
 const APPROVAL_WINDOW_MS = PAAK_AUTH_CLIENT_CEILING_MS;
-/** How long `login` waits for LINE to issue a PIN before reporting a failure. */
-const PIN_WAIT_TIMEOUT_MS = 20000;
-/**
- * Elicit `phone`/`region` from the human in one form, pre-filling whatever
- * the caller already supplied.
- *
- * @param server - MCP Server instance (elicitation already capability-gated
- * by the caller).
- * @param phone - Phone already supplied by the tool call, if any.
- * @param region - Region already supplied by the tool call, if any.
- * @returns The collected phone/region, or `null` if the human declined/cancelled.
- */
-async function elicitPhoneRegion(server, phone, region) {
-    const collected = await server.elicitInput({
-        message: 'Yomi needs your LINE phone number and region to start passwordless login.',
-        requestedSchema: {
-            type: 'object',
-            properties: {
-                phone: {
-                    type: 'string',
-                    title: 'Phone number',
-                    description: 'E.164 form, e.g. +8869XXXXXXXX.',
-                    ...(phone ? { default: phone } : {}),
-                },
-                region: {
-                    type: 'string',
-                    title: 'Region',
-                    enum: LOGIN_REGIONS,
-                    ...(region ? { default: region } : {}),
-                },
-            },
-            required: ['phone', 'region'],
-        },
-    });
-    if (collected.action !== 'accept') {
-        return null;
-    }
-    const collectedPhone = String(collected.content?.phone ?? '');
-    const collectedRegion = String(collected.content?.region ?? '');
-    if (!collectedPhone || !collectedRegion) {
-        return null;
-    }
-    return { phone: collectedPhone, region: collectedRegion };
-}
 /**
  * Elicit acknowledgement of the login PIN — fire-and-forget from the
- * caller's perspective (must not block `startPwlessLogin`, which is
- * already running concurrently and waiting on phone biometric approval).
+ * caller's perspective (must not block `runPwlessLogin`, which is already
+ * running concurrently and waiting on phone biometric approval).
  *
  * @param server - MCP Server instance.
  * @param pin - The PIN LINE just issued.
@@ -107,19 +28,7 @@ async function elicitPhoneRegion(server, phone, region) {
  */
 function elicitPinAcknowledgement(server, pin, onDeclined) {
     server
-        .elicitInput({
-        message: `LINE PIN: ${pin}\n\nEnter this PIN in the LINE app on your primary phone, then approve ` +
-            'the new device from there. Acknowledge below once you have done this.',
-        requestedSchema: {
-            type: 'object',
-            properties: {
-                entered: {
-                    type: 'boolean',
-                    title: 'I entered the PIN and approved the device on my phone',
-                },
-            },
-        },
-    })
+        .elicitInput(buildAcknowledgementForm(pin))
         .then((result) => {
         if (result.action !== 'accept') {
             onDeclined();
@@ -132,12 +41,13 @@ function elicitPinAcknowledgement(server, pin, onDeclined) {
     });
 }
 /**
- * Handle `login` for a client that supports MCP elicitation — drive the
- * passwordless flow entirely through elicitation, with no out-of-band
- * channel required. Phone/region are elicited when missing, and the PIN is
+ * Handle `login` on a LEGACY-era connection whose client supports form
+ * elicitation — drive the passwordless flow entirely through pushed
+ * elicitation requests, with no out-of-band channel required. A pre-flight
+ * form confirms the 允許自其他裝置登入 prerequisite (and collects
+ * phone/region when missing) BEFORE any PIN is issued; the PIN is then
  * surfaced through a second elicitation fired without blocking
- * `startPwlessLogin`, which keeps running while the human acts on their
- * phone. See ../cli/login.ts for the shared login sequence.
+ * `runPwlessLogin`, which keeps running while the human acts on their phone.
  *
  * @param server - MCP Server instance (for elicitInput).
  * @param service - LineProtocolService (not yet authenticated).
@@ -145,15 +55,19 @@ function elicitPinAcknowledgement(server, pin, onDeclined) {
  * @returns MCP tool result describing the logged-in profile.
  */
 async function handleLoginElicitation(server, service, args) {
-    let { phone, region } = args;
-    if (!phone || !region) {
-        const collected = await elicitPhoneRegion(server, phone, region);
-        if (!collected) {
-            return toolError('Login was cancelled by the user.');
+    const collected = await server.elicitInput(buildPreflightForm(args.phone, args.region));
+    if (collected.action !== 'accept') {
+        return toolError('Login was cancelled by the user.');
+    }
+    const preflight = readPreflightForm(collected.content, args.phone, args.region);
+    if (!preflight.ok) {
+        if (preflight.reason === 'prerequisite') {
+            log.warn('login.prerequisite', { answer: preflight.answer });
+            return prerequisiteNotMetResult(preflight.answer);
         }
-        ;
-        ({ phone, region } = collected);
+        return toolError('Login was cancelled by the user.');
     }
+    const { phone, region } = preflight;
     let pinDeclined = false;
     const onPin = (pin) => {
         log.warn('login.pin', { action: 'elicit_acknowledgement' });
@@ -188,90 +102,12 @@ async function handleLoginElicitation(server, service, args) {
         return toolError(error?.message ?? String(error));
     }
 }
-let pendingLogin = null;
-/**
- * Start a new passwordless login in the background and register it as the
- * one in-flight pending login.
- *
- * The stored promise is the actual `runPwlessLogin` promise, so
- * `login_complete` can await it and see the real success/failure. A
- * `.catch()` is attached immediately (its result discarded, not stored) so
- * an abandoned login — one nobody ever calls `login_complete` for — never
- * surfaces as an unhandled rejection; this does not affect what
- * `pendingLogin.promise` itself resolves/rejects with.
- *
- * @param service - LineProtocolService (not yet authenticated).
- * @param phone - Phone number in E.164 form.
- * @param region - Region code.
- * @returns The newly registered pending-login record.
- */
-function startPendingLogin(service, phone, region) {
-    let resolvePinReady = () => { };
-    const pinReady = new Promise((resolve) => {
-        resolvePinReady = resolve;
-    });
-    const pending = {
-        phone,
-        region,
-        pin: null,
-        certSkippedPin: false,
-        startedAt: Date.now(),
-        pinReady,
-    };
-    const onPin = (pin) => {
-        pending.pin = pin;
-        resolvePinReady();
-    };
-    const onBiometric = () => {
-        log.warn('login.waiting_biometric', {
-            action: 'approve the new device on your phone',
-        });
-        // Reaching biometric wait with no PIN ever set means a valid stored
-        // certificate skipped the PIN step entirely (see LinePwlessLogin.login,
-        // step 2-3) — resolve `pinReady` now so `waitForPin` doesn't block out
-        // its full timeout waiting for a PIN that will never arrive.
-        if (!pending.pin) {
-            pending.certSkippedPin = true;
-            resolvePinReady();
-        }
-    };
-    const promise = runPwlessLogin(service, phone, region, {
-        onPin,
-        onWaitingBiometric: onBiometric,
-    });
-    promise.catch(() => {
-        // Swallow here only to prevent an unhandled-rejection warning for a
-        // login nobody completes; the real error still surfaces to whoever
-        // awaits `pending.promise` (login_complete) below.
-    });
-    pending.promise = promise;
-    return pending;
-}
-/**
- * Wait for a pending login's PIN to arrive, bounded by a timeout.
- *
- * @param pending - The pending login to wait on.
- * @param timeoutMs - Maximum time to wait.
- * @returns The PIN, or `null` if it did not arrive within `timeoutMs`.
- */
-async function waitForPin(pending, timeoutMs) {
-    if (pending.pin) {
-        return pending.pin;
-    }
-    const outcome = await Promise.race([
-        pending.pinReady.then(() => pending.pin ?? null),
-        new Promise((resolve) => {
-            setTimeout(() => resolve(null), timeoutMs);
-        }),
-    ]);
-    return outcome;
-}
 /**
- * Handle `login` for a client that does NOT support MCP elicitation
- * (confirmed empirically for Claude Desktop). Splits the flow into two
- * tool calls since the PIN cannot be prompted for in-band: this call
- * starts (or reuses) the passwordless flow and returns the PIN as soon as
- * LINE issues it; `login_complete` finishes it once the human has acted.
+ * Handle `login` for a client that supports no form of elicitation at all
+ * (confirmed empirically for Claude Desktop). Splits the flow into two tool
+ * calls since the PIN cannot be prompted for in-band: this call starts (or
+ * reuses) the passwordless flow and returns the PIN as soon as LINE issues
+ * it; `login_complete` finishes it once the human has acted.
  *
  * The MCP Apps view (./ui/login-app.ts) has never been observed to render on
  * any deployed client (see that file's header) — resources/read succeeds
@@ -322,6 +158,9 @@ async function handleLoginNoElicitation(service, args, supportsUi) {
                         type: 'text',
                         text: 'Ask the human for their LINE phone number (E.164 form, e.g. +8869XXXXXXXX) and region ' +
                             `(one of ${LOGIN_REGIONS.join(', ')}), then call \`login\` again with those as arguments. ` +
+                            'In the same message, tell them yomi signs in as a SECOND device, which requires ' +
+                            `${PRIMARY_DEVICE_SETTING_PATH} to be enabled on the phone already logged in — if it is ` +
+                            'off, LINE never prompts that phone and the login cannot finish. ' +
                             'A login form may also appear for the human to fill in directly — if they use it, the ' +
                             'login proceeds on its own and there is nothing further for you to do — but do not wait ' +
                             'for that; if no form appears, asking the human directly is how this login makes progress.',
@@ -335,14 +174,13 @@ async function handleLoginNoElicitation(service, args, supportsUi) {
             missing.push('phone');
         if (!region)
             missing.push('region');
-        return toolError(`Missing ${missing.join(' and ')} for login. This MCP client does not support elicitation, so ` +
+        return toolError(`Missing ${missing.join(' and ')} for login. This MCP client does not support form elicitation, so ` +
             `${missing.join('/')} must be supplied as a tool argument, or persisted by running ` +
-            '`npx @rikaidev/yomi login` once in a terminal.');
+            '`npx @rikaidev/yomi login` once in a terminal. Also tell the human that yomi signs in as a ' +
+            `SECOND device, which requires ${PRIMARY_DEVICE_SETTING_PATH} enabled on the phone already ` +
+            'logged in — with it off, LINE never prompts that phone and no login can succeed.');
     }
-    const now = Date.now();
-    const active = pendingLogin && now - pendingLogin.startedAt < PIN_WINDOW_MS
-        ? pendingLogin
-        : null;
+    const active = getLivePendingLogin(Date.now());
     if (active && (active.phone !== phone || active.region !== region)) {
         // A live login for a DIFFERENT number is still in flight. Never hand
         // back its PIN under this call's identity, and never silently start a
@@ -352,10 +190,8 @@ async function handleLoginNoElicitation(service, args, supportsUi) {
             'before starting a login for another number.');
     }
     // Reuse the in-flight login only when it matches this number; otherwise
-    // start a fresh one. `pending` is non-null either way, so no narrowing of
-    // the module-level `pendingLogin` is needed downstream.
+    // start a fresh one.
     const pending = active ?? startPendingLogin(service, phone, region);
-    pendingLogin = pending;
     const pin = await waitForPin(pending, PIN_WAIT_TIMEOUT_MS);
     if (!pin) {
         if (pending.certSkippedPin) {
@@ -368,14 +204,7 @@ async function handleLoginNoElicitation(service, args, supportsUi) {
                 pin: null,
                 clientApprovalPollCeilingSeconds: Math.round(APPROVAL_WINDOW_MS / 1000),
             };
-            const certSteps = 'No PIN needed — LINE recognized a stored login certificate from a previous login, ' +
-                'so the PIN step was skipped.\n\n' +
-                '0. This only works if the primary phone has 設定 > 我的帳號 > 允許自其他裝置登入 ' +
-                'enabled — without it LINE will not offer this device a sign-in prompt at all.\n' +
-                '1. Bring the LINE app to the foreground on your primary phone — it should prompt you ' +
-                'to approve this new device signing in.\n' +
-                '2. Approve the device from there.\n\n';
-            const certText = certSteps +
+            const certText = certSteps() +
                 'Call the `login_complete` tool (no arguments) IMMEDIATELY now — do not wait for ' +
                 'confirmation that the approval happened first. `login_complete` blocks by itself while ' +
                 `you approve (up to about ${Math.round(APPROVAL_WINDOW_MS / 60000)} minutes) and returns ` +
@@ -399,16 +228,7 @@ async function handleLoginNoElicitation(service, args, supportsUi) {
         clientPinPollCeilingSeconds: Math.round(PIN_VERIFY_CLIENT_CEILING_MS / 1000),
         clientApprovalPollCeilingSeconds: Math.round(APPROVAL_WINDOW_MS / 1000),
     };
-    const pinSteps = 'LINE PIN:\n\n' +
-        `    ${pin}\n\n` +
-        '0. This only works if the primary phone has 設定 > 我的帳號 > 允許自其他裝置登入 enabled — ' +
-        'without it LINE will not offer this device a sign-in prompt at all.\n' +
-        '1. Open LINE on the primary phone. If a verification prompt does not appear immediately, ' +
-        'bringing the app to the foreground surfaces it.\n' +
-        `2. Enter this PIN and tick the device that is signing in, then tap 「用戶確認」 — LINE gives ` +
-        `you ${pinCodeLifetimeSeconds} seconds (about 3 minutes) from when the code was shown to do this.\n` +
-        '3. LINE will then ask that same phone to approve this new device signing in — approve it there.\n\n';
-    const pinText = pinSteps +
+    const pinText = pinSteps(pin) +
         `Call the \`login_complete\` tool (no arguments) IMMEDIATELY now — do not wait until you have ` +
         'entered the PIN or approved the device. `login_complete` blocks by itself through both of ' +
         `those steps: it keeps waiting up to about ${clientPinPollCeilingMinutes} minutes for step 2 and ` +
@@ -422,41 +242,50 @@ async function handleLoginNoElicitation(service, args, supportsUi) {
     };
 }
 /**
- * Handle `login` — dispatches to the elicitation flow when the connected
- * client supports it, otherwise the two-phase flow that finishes via
- * `login_complete`.
+ * Handle `login` — dispatches to the path the connected client can actually
+ * complete. See this module's header for the three paths.
+ *
+ * Elicitation is gated on the FORM sub-capability specifically, not on the
+ * presence of an `elicitation` object: since MCP 2026-07-28 a client may
+ * declare `elicitation: { url: {} }` alone, and both elicitation paths send
+ * a `requestedSchema` that such a client would reject. See
+ * ../client-capabilities.ts, which also owns WHERE the capabilities are read
+ * from — the accessor is empty on a modern-era stdio connection.
  *
- * @param server - MCP Server instance (for elicitInput/getClientCapabilities).
+ * @param server - MCP Server instance (for elicitInput on the legacy path).
  * @param service - LineProtocolService (not yet authenticated).
  * @param args - Tool arguments.
- * @returns MCP tool result.
+ * @param context - Era, client capabilities, and the multi-round-trip input
+ * responses a retried `tools/call` carried (`ctx.mcpReq.inputResponses`).
+ * @returns MCP tool result, or an `input_required` result on the MRTR path.
  */
-export async function handleLogin(server, service, args) {
-    if (server.getClientCapabilities()?.elicitation) {
-        return handleLoginElicitation(server, service, args);
+export async function handleLogin(server, service, args, context = {}) {
+    const { era = 'legacy', capabilities = server.getClientCapabilities(), inputResponses, } = context;
+    if (supportsFormElicitation(capabilities)) {
+        return era === 'legacy'
+            ? handleLoginElicitation(server, service, args)
+            : handleLoginMrtr(service, args, inputResponses);
     }
-    return handleLoginNoElicitation(service, args, supportsMcpApps(server.getClientCapabilities()));
+    return handleLoginNoElicitation(service, args, supportsMcpApps(capabilities));
 }
 /**
  * Handle `login_complete` — finish a login started by a prior `login` call
- * on a non-elicitation client. Awaits the same in-flight `runPwlessLogin`
- * promise `login` started, so the real success/failure surfaces here.
- * Never touches credentials on the failure path.
+ * on a client with no elicitation. Awaits the same in-flight
+ * `runPwlessLogin` promise `login` started, so the real success/failure
+ * surfaces here.
  *
  * @returns MCP tool result describing the logged-in profile, or an honest error.
  */
 export async function handleLoginComplete() {
-    if (!pendingLogin) {
+    const pending = getPendingLogin();
+    if (!pending) {
         return toolError('No login is pending. Call `login` first to start a passwordless login. ' +
             '(If you already called `login`, a previous attempt may have finished or its PIN code may have ' +
             `expired — LINE only gives the human about ${Math.round(LINE_PIN_CODE_LIFETIME_MS / 1000)} seconds ` +
             '(about 3 minutes) to act on a shown code. Calling `login` again is safe.)');
     }
-    const pending = pendingLogin;
     try {
-        const { mid, displayName } = await pending.promise;
-        pendingLogin = null;
-        log.info('login.complete', { mid });
+        const { mid, displayName } = await finishPendingLogin(pending);
         return {
             content: [
                 {
@@ -467,7 +296,6 @@ export async function handleLoginComplete() {
         };
     }
     catch (error) {
-        pendingLogin = null;
         return toolError(error?.message ?? String(error));
     }
 }