dsh-zen-remote 2.2.5 → 2.2.6

package/src/client/settings/SettingsSection.tsx

@@ -71,6 +71,7 @@ import type {
   ZenRemoteSettingsForm,
 } from '../../client-data/settings-form.ts'
 import { NS } from '../locales.ts'
+import { remoteDropDiagnostics } from '../effects/remote-drop.ts'
 import { describeShare } from '../../client-data/shares.ts'
 import type { ShareEntryView, SharesStore } from '../../client-data/shares.ts'
 
@@ -315,6 +316,11 @@ function SettingsSectionPage({ config, shares, t }: SettingsSectionProps) {
   // The client group's rendered view, hoisted for the countdown ticker and
   // the retry-follow refresh below (T43).
   const clientView = clientLoad.state === 'ready' || clientLoad.state === 'stale' ? clientLoad.view : undefined
+  // RD-3: the remote drop guard's browser-side counters, read at render
+  // time — no snapshot state of its own: the initial mount, the 15s
+  // connected-status poll and the countdown ticker all re-render this page,
+  // and each render takes the values as they are right then.
+  const dropDiag = remoteDropDiagnostics()
   const clientRetryAt = clientView?.nextRetryAt
   const clientCountingDown = clientRetryAt !== undefined
 
@@ -1158,7 +1164,7 @@ function SettingsSectionPage({ config, shares, t }: SettingsSectionProps) {
               earlier servers answer neither, and the section itself only
               exists when there is at least one line to show. PB-5 adds the
               bridge rows and the rerouting note on the same presence gate. */}
-          {clientView !== undefined && (clientView.lastError !== '' || clientView.intercept !== undefined || clientView.compat !== undefined || (clientView.pluginBridge?.length ?? 0) > 0 || clientView.pluginRouteIntercept !== undefined) && (
+          {clientView !== undefined && (clientView.lastError !== '' || clientView.intercept !== undefined || clientView.compat !== undefined || (clientView.pluginBridge?.length ?? 0) > 0 || clientView.pluginRouteIntercept !== undefined || dropDiag.installed || dropDiag.notInstalledReason !== undefined) && (
             <>
               <h3 className="zr-settings-card-title">{t('settings.client.diagTitle')}</h3>
               {clientView.lastError !== '' && (
@@ -1195,6 +1201,60 @@ function SettingsSectionPage({ config, shares, t }: SettingsSectionProps) {
                   )}
                 </>
               )}
+              {/* RD-3: the remote drop guard's own line — installed state
+                  plus the five counters. Browser-side values, so unlike the
+                  rows above it never rides the client/status body. */}
+              {(dropDiag.installed || dropDiag.notInstalledReason !== undefined) && (
+                <div className="zr-settings-field">
+                  <div className="zr-settings-head">
+                    <label>{t('settings.client.diagRemoteDrop')}</label>
+                  </div>
+                  <p className="zr-settings-hint">
+                    {dropDiag.installed
+                      ? t('settings.client.diagRemoteDropOk', {
+                        intercepted: dropDiag.intercepted,
+                        redispatched: dropDiag.redispatched,
+                        blocked: dropDiag.blockedDirectories,
+                        passthrough: dropDiag.passthrough,
+                        failed: dropDiag.rewrapFailed,
+                      })
+                      : t('settings.client.diagRemoteDropOff', { reason: dropDiag.notInstalledReason ?? '—' })}
+                  </p>
+                </div>
+              )}
+              {/* RD-6: the upload-redirect (fetch-route intercept) line — rides
+                  the client/status body's serviceProbe. One row answers the
+                  question this diagnosis was built for: whether the redirect
+                  is installed, refused (with the shape reason), or its service
+                  inject never fired — and which of the two services is
+                  missing when so. */}
+              {clientView?.uploadProbe !== undefined && (() => {
+                const probe = clientView.uploadProbe as {
+                  uploadInjectSeen?: unknown
+                  connectionService?: unknown
+                  fileUploadsService?: unknown
+                  fetchRoute?: { installed?: unknown; uploadWrapped?: unknown; shape?: { reasons?: unknown } }
+                }
+                const seen = probe.uploadInjectSeen === true
+                const refused = seen && probe.fetchRoute?.shape?.reasons instanceof Array && (probe.fetchRoute.shape.reasons as string[]).length > 0
+                const wrapped = probe.fetchRoute?.uploadWrapped === true
+                const text = wrapped
+                  ? t('settings.client.diagUploadRedirectOk')
+                  : refused
+                    ? t('settings.client.diagUploadRedirectRefused', { reason: (probe.fetchRoute?.shape?.reasons as string[]).join('; ') })
+                    : t('settings.client.diagUploadRedirectPending', {
+                      connection: typeof probe.connectionService === 'string' ? probe.connectionService : '—',
+                      fileUploads: typeof probe.fileUploadsService === 'string' ? probe.fileUploadsService : '—',
+                    })
+                return (
+                  <div className="zr-settings-field">
+                    <div className="zr-settings-head">
+                      <label>{t('settings.client.diagUploadRedirect')}</label>
+                    </div>
+                    <p className="zr-settings-hint">{text}</p>
+                  </div>
+                )
+              })()}
               {clientView.compat !== undefined && (
                 <>
                   {clientView.compat.mismatchedGroups.length > 0 && (

package/src/client/styles/compat.css.ts

@@ -299,31 +299,62 @@ export const COMPAT_CSS = `  /* ---------- dsh-web-ui family compatibility -----
      one row with a thin scrollbar keeps every tab reachable and returns
      that space to the options area (user feedback 2026-08-16). An earlier
      one-row attempt had no scroll affordance and silently cut the last
-     tab off; the thin scrollbar IS the affordance. Scoped to the frame
-     marker: the desktop dialog keeps its official vertical nav column. */
-  [data-mobile-nav="frame"] [aria-modal="true"]:has(> :first-child > :last-child > button):not(:has([role="navigation"])):not(:has([class*="ZuhsRW"])) > :first-child [class$="_navList"] {
+     tab off; the thin scrollbar IS the affordance.
+
+     2026-10-21 (DSH 0.2.1-rc.2, measured on a real phone shell): the whole
+     block below had silently stopped matching. The settings dialog no longer
+     renders inside the app frame — it is a PORTAL on body
+     (body > [class$="_overlay"] > [class$="_panel"]), so a
+     [data-mobile-nav="frame"] [aria-modal="true"] … prefix can never match
+     it, and the panel depth the old :has(> :first-child > :last-child >
+     button) gate was written against is no longer the shape the sheet has
+     (now panel > nav > (navTitle, navList, header)). Symptom: four nav cells
+     fell back to the host's wrapping grid (measured 209x132 for the list
+     instead of one 40px row) and the "open config file" action came back
+     into the header. Keep the same phone gate from the ancestor side
+     (html:has([data-mobile-nav="frame"]) — the marker only exists outside
+     the desktop gate) and identify the dialog by the nav list it owns, not
+     by a guessed depth. Desktop untouched.
+
+     This rule is the only place that declares the row's wrap/overflow now:
+     layout.css.ts's navList rule has a higher specificity and used to force
+     "flex-wrap: wrap; overflow: visible", so the one-row intent below never
+     actually rendered (see the note in layout.css.ts).
+
+     Every selector below is gated on :has([class$="_navList"]) — the one
+     stable feature of the settings sheet. The ancestor marker alone is not
+     enough: once the dialog is a body portal, [aria-modal="true"] matches
+     EVERY dialog on the phone (session export, directory picker, plugin
+     sheets), which is how the first cut of this block ended up hiding the
+     top-right action button of all of them (review, 2026-10-22). */
+  html:has([data-mobile-nav="frame"]) [aria-modal="true"]:has([class$="_navList"]) [class$="_navList"] {
     display: flex !important;
     flex-wrap: nowrap !important;
+    /* The nav row is [navList][header(close)]: min-width:0 + flex-basis auto
+       lets the list shrink to the width left over by the ✕ and scroll inside
+       itself — without it the nowrap content widens the row and pushes the
+       close button off-screen. */
+    flex: 1 1 auto !important;
+    min-width: 0 !important;
     overflow-x: auto !important;
     overflow-y: hidden !important;
     gap: 6px !important;
-    width: 100% !important;
     scrollbar-width: thin !important;
     -webkit-overflow-scrolling: touch !important;
   }
   /* Hairline scrollbar for the tab row: the default WebKit scrollbar reads
      fat on a phone; 2px keeps the scroll affordance without the bulk. */
-  [data-mobile-nav="frame"] [aria-modal="true"] [class$="_navList"]::-webkit-scrollbar {
+  html:has([data-mobile-nav="frame"]) [aria-modal="true"]:has([class$="_navList"]) [class$="_navList"]::-webkit-scrollbar {
     height: 2px !important;
   }
-  [data-mobile-nav="frame"] [aria-modal="true"] [class$="_navList"]::-webkit-scrollbar-thumb {
+  html:has([data-mobile-nav="frame"]) [aria-modal="true"]:has([class$="_navList"]) [class$="_navList"]::-webkit-scrollbar-thumb {
     background: var(--dsw-alias-border-l2, rgba(0, 0, 0, .22)) !important;
     border-radius: 1px !important;
   }
-  [data-mobile-nav="frame"] [aria-modal="true"] [class$="_navList"]::-webkit-scrollbar-track {
+  html:has([data-mobile-nav="frame"]) [aria-modal="true"]:has([class$="_navList"]) [class$="_navList"]::-webkit-scrollbar-track {
     background: transparent !important;
   }
-  [data-mobile-nav="frame"] [aria-modal="true"] [class$="_navCell"] {
+  html:has([data-mobile-nav="frame"]) [aria-modal="true"]:has([class$="_navList"]) [class$="_navCell"] {
     flex: 0 0 auto !important;
     white-space: nowrap !important;
     padding: 6px 8px !important;
@@ -331,7 +362,7 @@ export const COMPAT_CSS = `  /* ---------- dsh-web-ui family compatibility -----
     font-size: 13px !important;
     justify-content: flex-start !important;
   }
-  [data-mobile-nav="frame"] [aria-modal="true"] [class$="_navCell"] svg {
+  html:has([data-mobile-nav="frame"]) [aria-modal="true"]:has([class$="_navList"]) [class$="_navCell"] svg {
     width: 14px !important;
     height: 14px !important;
     flex: none !important;
@@ -339,11 +370,11 @@ export const COMPAT_CSS = `  /* ---------- dsh-web-ui family compatibility -----
   /* Content toolbar: the "Open configuration file" button is hidden on
      mobile — it is rarely needed on a phone and steals ~180px from the
      tab row's scroll area (user feedback 2026-08-16). Only the close ✕
-     stays, flush right in the nav row. Desktop untouched (frame scoped). */
-  [data-mobile-nav="frame"] [aria-modal="true"] [class$="_header"] [class$="_actions"] {
+     stays, flush right in the nav row. Desktop untouched (phone gate). */
+  html:has([data-mobile-nav="frame"]) [aria-modal="true"]:has([class$="_navList"]) [class$="_header"] [class$="_actions"] {
     display: none !important;
   }
-  [data-mobile-nav="frame"] [aria-modal="true"] [class$="_header"] [class$="_actions"] [class$="_action"] {
+  html:has([data-mobile-nav="frame"]) [aria-modal="true"]:has([class$="_navList"]) [class$="_header"] [class$="_actions"] [class$="_action"] {
     font-size: 13px !important;
     padding: 6px 12px !important;
     min-height: 0 !important;

package/src/client/styles/header.css.ts

@@ -19,6 +19,13 @@
 //                               hidden below, our workbench button routes to
 //                               its controls instead)
 //     div.tabs[role="tablist"]  Chat/Trajectory, only when there is >1 view
+//                               (DSH <= 0.2.1-rc.2)
+//     div.tabs                  DSH 0.2.1-rc.3: the row lost its role and
+//       div.viewTabs[role="tablist"][data-conversation-tabs]
+//       div.viewsMoreAnchor     "More conversation views" (…) menu launcher,
+//                               present while conversation.session.header.
+//                               views.actions has registrations (the web app
+//                               ships dsh-client-ui-entry-customization)
 
 export const HEADER_CSS = `/* ---------- session header five-piece reflow (< 768px) ---------- */
 
@@ -78,27 +85,39 @@ export const HEADER_CSS = `/* ---------- session header five-piece reflow (< 768
        above. */
     z-index: 2;
     padding: 0 8px 28px !important;
+    border-bottom: none !important;
   }
   /* No header bottom line — fade instead (real-device round 2, 2026-08-17).
-     The official header draws its border as a \`::after\` 1px bar (the
-     \`border-bottom\` on the header itself is transparent, just a layout
-     reserve — dsh-client-ui-conversation lib/client.js ".wSkVaW_header{
-     border-bottom:1px solid #0000}.wSkVaW_header:after{...height:1px;
-     position:absolute;bottom:1px...}", verified live 2026-08-17), so the
-     bar is repurposed rather than hidden: restyled into a 20px strip
-     hanging just below the header that fades the messages in — the same
-     look the scroller's mask-image used to produce, without a mask on a
-     scroll container (iOS WebKit renders that as fog over the header, see
-     composer.css.ts "no divider above OR below the message list",
-     2026-08-23). color-mix instead of the transparent keyword: the host
-     writes its own seat gradient that way, and plain \`transparent\` is
-     rgba(0,0,0,0) — WebKit interpolates it through grey. */
-  [data-phase] header::after {
-    height: 20px !important;
+     The official header in rc.2 drew its border as a \`::after\` 1px bar; in
+     rc.3 (2026-10-25) the host replaced that pseudo-element with a plain 0.5px
+     border-bottom (cleared above) and added a blank 0px header in the hero
+     phase (\`_headerBlank\`). Declaring \`content: ''\` + \`position: absolute;
+     left: 0; right: 0\` explicitly on \`[data-phase="active"] header:not([class$="_headerBlank"])::after\`
+     keeps the 20px fade strip anchored right below the real session header on
+     both rc.2 and rc.3 without touching the scroll container:
+     - When the session header is display:none on the list page, ::after is
+       not generated at all (unlike _scrollBody::before, which stayed in flow
+       at y=0 whenever the header was hidden or blank and showed up at the top
+       of the window on iOS standalone PWA launch before data-view mutated).
+     - :not([class$="_headerBlank"]) excludes the 0-height blank header.
+     - color-mix instead of the transparent keyword: plain \`transparent\` is
+       rgba(0,0,0,0) — WebKit interpolates it through grey. */
+  [data-phase="active"] header:not([class$="_headerBlank"])::after {
+    content: '';
+    position: absolute;
+    left: 0;
+    right: 0;
     top: 100% !important;
     bottom: auto !important;
+    height: 20px !important;
+    pointer-events: none;
     background: linear-gradient(to bottom, var(--dsw-alias-bg-base), color-mix(in srgb, var(--dsw-alias-bg-base) 0%, transparent)) !important;
   }
+  [data-mobile-nav="frame"]:not([data-mobile-view="session"]) [data-phase] header::after,
+  body:has([data-mobile-nav="home"]:not([data-view="session"])) [data-phase] header::after {
+    content: none !important;
+    display: none !important;
+  }
   /* grid-row: 1 on every item is load-bearing, not decoration (S2.1 fix for
      the "标题被挤下去" report). The three items are placed with explicit
      grid-column but arrive in DOM order crumbs(2) → headerActions(1) →
@@ -440,6 +459,35 @@ export const HEADER_CSS = `/* ---------- session header five-piece reflow (< 768
   [data-phase] header [class$="_tabs"][role="tablist"] {
     display: none;
   }
+  /* DSH 0.2.1-rc.3 split the row: div._tabs (no role) now wraps the
+     tablist (div._viewTabs[role=tablist][data-conversation-tabs]) and the
+     new "More conversation views" launcher, so the rule above matches
+     nothing there and the official row — plus a stray (…) More button —
+     came back under our view-switch band. It cannot simply be display:none
+     either: while the More menu has registrations the header folds every
+     View past floor((row.clientWidth - 48) / 120) into More, and a
+     display:none row measures 0, which would leave only Chat as a
+     [role=tab] for readViewTabs() (MobileSessionHeader.tsx) to mirror.
+     So the row keeps a wide layout box that paints nothing: absolute (out
+     of the header's flow, no band), 2048px wide (room for 16 tabs before
+     anything folds), scale(0) so it adds no scrollable overflow (clientWidth
+     ignores transforms), visibility:hidden + pointer-events:none so it is
+     never seen or hit. Its tabs still take the synthetic .click() the view
+     switcher sends — the same reasoning as the display:none rule above. */
+  [data-phase] header [class$="_tabs"]:has(> [data-conversation-tabs]) {
+    position: absolute !important;
+    top: 0;
+    left: 0;
+    width: 2048px !important;
+    max-width: none !important;
+    height: 0 !important;
+    margin: 0 !important;
+    overflow: hidden !important;
+    transform: scale(0);
+    transform-origin: 0 0;
+    visibility: hidden !important;
+    pointer-events: none !important;
+  }
 
   /* View-switch row: "current view name + dots", replacing the (still
      present, still clickable) official tablist visually. It renders inside

package/src/client/styles/home.css.ts

@@ -91,7 +91,17 @@ export const HOME_CSS = `/* ---------- phone app shell (< 768px) ---------- */
   [data-mobile-nav="home"] {
     position: absolute;
     inset: 0;
-    z-index: 5;
+    /* rc.3 raise (real-device report 2026-10-25 "top strip leaking the
+       conversation through"): this shell layer mounts INSIDE the host's
+       PIRFFq_overlayLayer (z-index:20, new in rc.3 — the conversation
+       content itself moved under it too), so the old z:5 let host session
+       content (STRONG/CODE rows measured at viewport y=4) paint over the
+       shell's top bar on BOTH pages, reading as a faint fixed strip at the
+       window top. z:30 puts the whole shell above everything the host
+       stacks inside that layer; the shell's own transparent middle and
+       pointer-events passthrough keep the conversation visible and tappable
+       (verified live via console injection before landing). */
+    z-index: 30;
     display: flex;
     flex-direction: column;
     pointer-events: auto;
@@ -136,6 +146,34 @@ export const HOME_CSS = `/* ---------- phone app shell (< 768px) ---------- */
       opacity .3s var(--ds-ease-in-out, ease-in-out),
       visibility 0s .3s;
   }
+  /* The host's SESSION header must not sit on top of this list page.
+     Real-device report (2026-10-22, DSH 0.2.0-rc.2, dsh-web-mobile 3.2.1,
+     360x792 phone): on the list page the top strip showed the LAST SESSION's
+     header — its title plus the session's tab row — and the workspace switcher
+     underneath was neither visible nor tappable, so "switch workspace" did
+     nothing at all. Measured with elementFromPoint(150,30) on the phone
+     viewport: span.wSkVaW_crumbCurrent, i.e. the host header's crumb, while
+     our own workspace button sat at [46,8,208,44] underneath it.
+
+     Why z-index is not the fix: this page is position:absolute; z-index:5
+     inside the shell overlay layer, and the host header carries its own
+     stacking context, so raising us above its z-index:30 changed nothing
+     (measured: the crumb still won the hit test). The session header has to
+     leave the hit tree while the list page is up — the list page draws its
+     own top bar (home-top, with the workspace switcher).
+
+     The gate is this page's own marker: data-view="session" means a session
+     is open, so the rule lapses exactly when the host header is wanted again
+     (verified: entering a session restores display:grid, the back button in
+     that header stays tappable, and going back hides it once more). Two
+     selectors on purpose — the class suffix survives CSS-module hash renames,
+     the structural one survives a rename of the class itself. */
+  [data-mobile-nav="frame"]:not([data-mobile-view="session"]) header[class*="_header"],
+  [data-mobile-nav="frame"]:not([data-mobile-view="session"]) header:has([class*="_titleRow"]),
+  body:has([data-mobile-nav="home"]:not([data-view="session"])) [data-mobile-nav="frame"] header[class*="_header"],
+  body:has([data-mobile-nav="home"]:not([data-view="session"])) [data-mobile-nav="frame"] header:has([class*="_titleRow"]) {
+    display: none !important;
+  }
   @media (prefers-reduced-motion: reduce) {
     [data-mobile-nav="home"],
     [data-mobile-nav="home"][data-view="session"] {

package/src/client/styles/layout.css.ts

@@ -394,7 +394,14 @@ export const LAYOUT_CSS = `/* ---------- mobile-only layout ---------- */
      display:none rule below, and the user can no longer type a path
      (issue #12, 2026-08-16). The picker family keeps the official layout
      on mobile in every mode. */
-  [aria-modal="true"]:has(> :first-child > :last-child > button):not(:has([role="navigation"])):not(:has([class*="ZuhsRW"])) {
+  /* DSH 0.2.1-rc.2 renders this dialog as a body PORTAL
+     (body > overlay > panel), so the placement below must key off the nav
+     list the panel owns, not off a guessed child depth: that is both the
+     stable "this is the settings sheet" anchor and the reason the safe-area
+     offset below still applies inside the portal (the constants live on
+     :root, so they cross the portal boundary). The bottom inset is
+     subtracted too — a tall panel must not run under the home indicator. */
+  [aria-modal="true"]:has(> :first-child > :last-child > button):not(:has([role="navigation"])):not(:has([class*="ZuhsRW"])):has([class$="_navList"]) {
     position: absolute !important;
     left: 8px !important;
     /* Fixed top (no translateY): a transform on the panel combined with the
@@ -405,11 +412,11 @@ export const LAYOUT_CSS = `/* ---------- mobile-only layout ---------- */
     width: calc(100vw - 16px) !important;
     max-width: calc(100vw - 16px) !important;
     /* Height follows the content (no dead space under a short page); it
-       caps at 100dvh-24 (less the safe-area top) and the options area
+       caps at 100dvh-24 (less both safe-area insets) and the options area
        scrolls only then. */
     height: auto !important;
-    max-height: min(800px, calc(100vh - 24px - var(--mnav-sat))) !important;
-    max-height: min(800px, calc(100dvh - 24px - var(--mnav-sat))) !important;
+    max-height: min(800px, calc(100vh - 24px - var(--mnav-sat) - var(--mnav-sab))) !important;
+    max-height: min(800px, calc(100dvh - 24px - var(--mnav-sat) - var(--mnav-sab))) !important;
     flex-direction: column !important;
     border-radius: 14px !important;
     animation: dsh-mobile-nav-sheet-in .22s var(--ds-ease-out, ease-in-out);
@@ -457,14 +464,24 @@ export const LAYOUT_CSS = `/* ---------- mobile-only layout ---------- */
      (config file + close) is reparented INTO this nav row by a client
      effect (MobileNavOverlay), so the tab list must be anchored by its
      class, NOT by :last-child (the reparented toolbar becomes the nav's
-     new last child). */
+     new last child).
+
+     2026-10-21 (DSH 0.2.1-rc.2): this rule used to declare
+     "flex-wrap: wrap; overflow: visible" on top of the flex/min-width/gap
+     above. Because it is one class-anchored compound selector with a much
+     higher specificity than compat.css.ts's portal-scoped navList rule, it
+     silently won the tie and the tab list wrapped into two rows — with the
+     reparented ✕ vertically centred across both of them. Measured on a
+     phone shell: the list was 86px tall (two rows) instead of one 40px row,
+     and it scrolled nowhere. The wrap was a 2026-08-16 trade-off (show every
+     tab, no hidden scroll cut-off); with the thin scrollbar affordance now
+     in compat.css.ts the single scrolling row is the better trade, so the
+     two declarations live there and this rule no longer contradicts them. */
   [aria-modal="true"]:has(> :first-child > :last-child > button):not(:has([role="navigation"])):not(:has([class*="ZuhsRW"])) > :first-child [class$="_navList"] {
     flex: 1 1 auto !important;
     min-width: 0 !important;
     flex-direction: row !important;
-    flex-wrap: wrap !important;
     gap: 6px !important;
-    overflow: visible !important;
   }
   /* Content toolbar (Open configuration file + close): grouped flush to
      the right edge, and reparented INTO the nav row on mobile so it shares

package/src/client/styles/remote-session.css.ts

@@ -310,4 +310,42 @@ option[value^="zr~"] {
 html[data-zr-remote-session="1"] [data-slot="conversation.session.header.utilities"] [class$="_moreButton"] ~ [role="menu"] > [role="presentation"] > :first-child {
   display: none !important;
 }
+
+/* ---------- remote session: the "save to this machine" action (2.2.6) ----------
+   One class, owned by this plugin (no host module class, no hash): the
+   deliverable-card entry renders it in the card's own actions cell, the
+   document-preview entry in the preview header where open-in-app's control
+   sits (that one is hidden remotely by the [data-open-target] rule above,
+   so this is the only action left there). Both entries only MOUNT for a
+   virtual session, so the html attribute gate is belt-and-braces, not the
+   decision.
+   The palette variables are the host's own (label-secondary / border-l1 /
+   interactive-bg-hover / state-error), which keeps light/dark identical to
+   the cards around it without copying a theme. */
+html[data-zr-remote-session="1"] .zr-download-action {
+  box-sizing: border-box;
+  flex: none;
+  font: inherit;
+  font-size: 12px;
+  line-height: 18px;
+  color: var(--dsw-alias-label-secondary, #6b7280);
+  background: transparent;
+  border: 0.5px solid var(--dsw-alias-border-l1, #d9dde3);
+  border-radius: var(--dsw-radius-sm, 4px);
+  padding: 1px 8px;
+  cursor: pointer;
+  white-space: nowrap;
+}
+html[data-zr-remote-session="1"] .zr-download-action:hover {
+  color: var(--dsw-alias-label-primary, #111827);
+  background: var(--dsw-alias-interactive-bg-hover, rgba(0, 0, 0, 0.05));
+}
+html[data-zr-remote-session="1"] .zr-download-action[data-phase="busy"] {
+  cursor: progress;
+  opacity: 0.7;
+}
+html[data-zr-remote-session="1"] .zr-download-action[data-phase="error"] {
+  color: var(--dsw-alias-state-error-primary, #dc2626);
+  border-color: var(--dsw-alias-state-error-primary, #dc2626);
+}
 `

package/src/client-data/remote-drop.ts

@@ -0,0 +1,127 @@
+/**
+ * Remote-session drag-and-drop decision core (RD-1): the DOM-free, readable
+ * half of the document-level drop guard (src/client/effects/remote-drop.ts).
+ *
+ * Why this exists: the desktop app's attachment pipeline has a same-machine
+ * zero-copy fast path — the Electron preload exposes `__DSH_HOST_PATHS__`,
+ * and the host's `addFiles` turns a File that still carries a real disk path
+ * into an `@/absolute/path` mention chip WITHOUT uploading any bytes. In a
+ * remote session (`zr~<serverId>~<id>`) that path names a file on the
+ * SUB-CLIENT's machine; the server-side session can never read it, so the
+ * mention lands broken. The fix re-shapes the drop before the host sees it:
+ * strip the internal path by re-wrapping each File (`new File([f], ...)`) and
+ * redispatch a synthetic, untrusted DragEvent carrying them in a fresh
+ * DataTransfer. The host's own drop handler then treats it as an ordinary
+ * browser drag — the byte-upload branch — which the T51 fetch-route
+ * interception already relays to the server for staging.
+ *
+ * This module only DECIDES; it never touches the DOM:
+ * - `isRemoteSessionId` — the current-session gate, judged by the same
+ *   `zr~` skeleton (virtual-id.ts) every other remote gate in this plugin
+ *   keys on, so the two ends cannot drift;
+ * - `decideRemoteDrop` — the three trigger gates plus the directory rule,
+ *   as a pure function over injectable data so the whole truth table is
+ *   assertable in Node (scripts/check-remote-drop.mjs);
+ * - `rewrapFiles` — the File re-wrap itself (Node >= 20 has File).
+ *
+ * Misjudgement direction is safe by construction: every gate failing open
+ * lands on `passthrough` = today's behavior. The only wrong action a stale
+ * current-session signal can produce is re-shaping a LOCAL session's drop
+ * into an upload — bytes travel that did not have to, but nothing is lost.
+ * The reverse (a remote drop reaching the host untouched) is what loses the
+ * attachment, which is why all three gates must affirmatively pass.
+ */
+
+import { isVirtual } from '../virtual-id.ts'
+
+/** True when the id is one of this plugin's virtual (relay) session ids —
+ * the `zr~<serverId>~<id>` form. `undefined` (no readable current-session
+ * signal) is deliberately NOT remote: the conservative gate reads a missing
+ * signal as a local session and never intervenes. */
+export function isRemoteSessionId(id: string | undefined): boolean {
+  return typeof id === 'string' && isVirtual(id)
+}
+
+/** One drag item, reduced to what the decision needs. `kind` mirrors the
+ * DataTransferItem kind — only `file` items can carry attachment bytes.
+ * `isDirectory` comes from `webkitGetAsEntry().isDirectory`; a file item
+ * whose entry cannot be read counts as NOT a directory (the host applies
+ * the same default). */
+export interface RemoteDropItemDescriptor {
+  kind: 'file' | 'other'
+  isDirectory: boolean
+}
+
+/** Everything the decision may look at, injectable so no DOM is needed. */
+export interface RemoteDropInput {
+  /** `__DSH_HOST_PATHS__` exists — the Electron preload's zero-copy bridge.
+   * False on phone / plain-browser hosts, which already upload bytes. */
+  hasHostPaths: boolean
+  /** The currently open session id, or `undefined` when no signal. */
+  currentSessionId: string | undefined
+  /** `event.isTrusted` — our own redispatched events are untrusted; this
+   * gate is the re-entry guard. */
+  trusted: boolean
+  /** Descriptor per file-kind drag item. `undefined` means the entry API
+   * (`webkitGetAsEntry`) is unavailable, so directories cannot be detected —
+   * the host's own semantics treat that as "no directories". */
+  items: readonly RemoteDropItemDescriptor[] | undefined
+}
+
+export type RemoteDropAction = 'passthrough' | 'redispatch' | 'block-directories'
+
+/** Stable machine-readable why, one per action branch. Ordered by the gate
+ * sequence below. */
+export type RemoteDropReason =
+  | 'untrusted-event'
+  | 'no-host-paths'
+  | 'not-remote-session'
+  | 'no-entry-api'
+  | 'contains-directory'
+  | 'no-files'
+  | 'remote-files'
+
+export interface RemoteDropDecision {
+  action: RemoteDropAction
+  reason: RemoteDropReason
+}
+
+/**
+ * The three trigger gates, then the directory rule. Every gate must
+ * affirmatively pass before anything is intervened on:
+ * 1. `trusted` — synthetic (our own) events pass straight through, which is
+ *    what makes the redispatch loop-free;
+ * 2. `hasHostPaths` — without the Electron bridge the host is already on
+ *    the byte-upload branch and there is nothing to fix;
+ * 3. remote session — a missing/failed current-session read counts as local
+ *    (conservative: passthrough keeps today's behavior);
+ * 4. no entry API — redispatch (no directory knowledge, same default as the
+ *    host);
+ * 5. any directory — `block-directories`, which takes precedence over
+ *    redispatch: a folder cannot be fixed by single-file upload, so the
+ *    whole drop is stopped with a toast rather than silently reduced;
+ * 6. no file items at all — passthrough (the host's own `Files`-in-types
+ *    gate would ignore the drop; there is nothing to re-shape);
+ * 7. otherwise — `redispatch`.
+ */
+export function decideRemoteDrop(input: RemoteDropInput): RemoteDropDecision {
+  if (!input.trusted) return { action: 'passthrough', reason: 'untrusted-event' }
+  if (!input.hasHostPaths) return { action: 'passthrough', reason: 'no-host-paths' }
+  if (!isRemoteSessionId(input.currentSessionId)) return { action: 'passthrough', reason: 'not-remote-session' }
+  if (input.items === undefined) return { action: 'redispatch', reason: 'no-entry-api' }
+  if (input.items.some((item) => item.isDirectory)) return { action: 'block-directories', reason: 'contains-directory' }
+  if (!input.items.some((item) => item.kind === 'file')) return { action: 'passthrough', reason: 'no-files' }
+  return { action: 'redispatch', reason: 'remote-files' }
+}
+
+/**
+ * Re-wrap files so they stop carrying their disk paths. A File the browser
+ * constructed from an OS drop keeps a hidden reference the Electron
+ * `getPathForFile` can read; `new File([f], ...)` builds a JS-constructed
+ * File with no such backing — `getPathForFile` returns "" for it, which
+ * sends the host's `addFiles` down the byte-upload branch. name / type /
+ * lastModified are preserved so the staged upload keeps its filename.
+ */
+export function rewrapFiles(files: Iterable<File>): File[] {
+  return Array.from(files, (file) => new File([file], file.name, { type: file.type, lastModified: file.lastModified }))
+}

package/src/client-data/settings-form.ts

@@ -163,6 +163,9 @@ export interface ClientStatusBody {
    * a host role or a refused install may still answer it; a server without
    * the field never does). */
   pluginRouteIntercept?: unknown
+  /** RD-6: the upload-redirect service probe (presence-gated — an older
+   * plugin answers without it). */
+  serviceProbe?: unknown
 }
 
 /** One remote-call failure line in the diagnostics lists. `time` is epoch
@@ -217,6 +220,10 @@ export interface ClientConnectionView {
    * renders the 本机改道未启用 line with the shape reasons; undefined when
    * the body carried none). */
   pluginRouteIntercept: { installed: boolean; reasons: string[] } | undefined
+  /** RD-6: the upload-redirect service probe from the same body, passed
+   * through tolerantly (undefined when the body carried none — an older
+   * plugin — and the diagnostics row stays hidden). */
+  uploadProbe: Readonly<Record<string, unknown>> | undefined
 }
 
 const CLIENT_STATES: readonly ClientConnectionView['state'][] = ['unpaired', 'connected', 'revoked', 'unreachable', 'unexpected', 'invalid-url', 'incompatible']
@@ -333,6 +340,9 @@ export function deriveClientStatusView(body: ClientStatusBody): ClientConnection
     compat: deriveCompatView(safe.compat),
     pluginBridge: derivePluginBridgeStatuses(safe.pluginBridge),
     pluginRouteIntercept: derivePluginRouteInterceptView(safe.pluginRouteIntercept),
+    uploadProbe: safe.serviceProbe !== null && typeof safe.serviceProbe === 'object'
+      ? Object.freeze({ ...(safe.serviceProbe as Record<string, unknown>) })
+      : undefined,
   }
 }
 

package/src/client-routes.ts

@@ -104,6 +104,12 @@ export interface ClientHandlerOptions {
   getRowConfig: () => unknown
   /** Outbound fetch, defaulting to the global one. */
   fetchImpl?: FetchLike
+  /** Upload-redirect service probe (RD-6): lazily reflects `connection` /
+   * `fileUploads` from a context that already resolved, plus whether the
+   * fetch-route inject callback ever fired. Answers WHY the upload
+   * redirection is absent on compositions where one of the two services
+   * never becomes available (cordis keeps such injects silently PENDING). */
+  getServiceProbe?: () => Record<string, unknown>
   /** The live relay client (T23a), once apply() built one. When it has LEFT
    * its initial `unpaired` state — a connection attempt ran — the status
    * route reports ITS verdict (state + handshake server name) and skips the
@@ -469,6 +475,7 @@ export function createClientHandler(options: ClientHandlerOptions): ClientHandle
         // that.
         const intercept = options.getIntercept?.()
         const fetchRouteIntercept = options.getFetchRouteIntercept?.()
+        const serviceProbe = options.getServiceProbe?.()
         const pluginRouteIntercept = options.getPluginRouteIntercept?.()
         const compatRelay = options.getRelayClient?.()
         const compat =
@@ -487,6 +494,7 @@ export function createClientHandler(options: ClientHandlerOptions): ClientHandle
           let next: Record<string, unknown> = { ...body, pluginBridge: options.getPluginBridgeStatus?.() ?? [] }
           if (intercept !== undefined) next = { ...next, intercept }
           if (fetchRouteIntercept !== undefined) next = { ...next, fetchRouteIntercept }
+          if (serviceProbe !== undefined) next = { ...next, serviceProbe }
           if (pluginRouteIntercept !== undefined) next = { ...next, pluginRouteIntercept }
           return compat === undefined ? next : { ...next, compat }
         }