【免费下载链接】plannotatorAnnotate and review coding agent plans and code diffs visually, share with your team, send feedback to agents with one click.项目地址https://gitcode.com/gh_mirrors/pl/plannotator点击查看免费下载Plannotator 的 Plan 文档评审与 Code Review 产品原本是桌面优先的多窗格工作区通过 Tailscale 暴露到 iPhone/iPad 后暴露出「可达性已解决、移动性未解决」的根本矛盾。本篇以adr/research/synthesis-mobile-feedback-triage-20260812.md为核心结合SPIKE-mobile-web-compatibility研究、Phase 1/2 规格与packages/ui、packages/editor、packages/review-editor源码系统讲解 Plannotator 如何把物理设备评审反馈转化为可执行的阶段序列Phase 1C → 2A → 2B → 3如何在不破坏桌面偏好的前提下落地紧凑触控 Shellcompact touch shell以及 44 px 触摸目标、可见视口对话框、会话级 diff 样式等关键机制的真实实现。读完本文你将掌握 Plannotator 移动改造的分诊方法论、各阶段边界与验收门、以及源码级证据对应的实现缝隙implementation seam可直接用于二次开发或移植同类 touch-first 改造。背景Tailscale 解决了可达性但没有解决移动性SPIKE 研究SPIKE-mobile-web-compatibility-20260812.md在基线ef49c701c23b867cec2a5d78343813ba89d2a025v0.27.1上通过双 Agent 审计得出核心结论Tailscale 只负责把本地同一个单文件 React 应用暴露到 tailnet不会选择任何移动端渲染路径或路由Plan/文档阅读是「视觉上响应式、但尚未触控优先」——控件高度普遍只有 17–28 px触屏设备会展开每个工具条标签Code Review 是「被压缩进窄视口的桌面组合」——390 px 宽度下默认 256 px 文件树只给 Pierre diff 留下 134 px再打开固定 288 px 右侧栏只剩 102 pxGuided Review 是现存最强的移动产品原型——它已把变更集变成有序叙事流、隐藏文件树、在手机宽度下堆叠章节并复用真实 Pierre diff。而最严重的兼容性问题不是视觉多文件/文件夹注解在lg以下被阻断MOB-001。文件夹空状态提示用户「从侧边栏选择文件」但SidebarTabs与SidebarContainer在该宽度下是hidden lg评审者根本无法选中文件。从源码结构看Plan/文档应用根组件为 packages/editor/App.tsxReview 应用根组件为 packages/review-editor/App.tsx两者共用packages/ui的组件与 tokendiff 渲染依赖 Dockview 与pierre/diffs。Vite vite-plugin-singlefile将 JS/CSS/字体/资源与 Pierre 高亮 worker 全部内联进单个 HTML由 Bun 服务器常驻内存并按 SPA 返回——Tailscale 不改变这套 API 与渲染契约见 apps/hook/vite.config.ts、packages/server/index.ts。决策与推进顺序把「共享机制安全」与「信息架构」分开综合文档给出的核心决策是物理设备评审已充分不必让评审者重跑 Phase 1B 的 composer 检查清单。Safari 阶段失败是阻断性缺陷而最终的 iPhone 通过确认了其修正。后续工作严格按下列顺序推进Phase 1C —— 共享触摸与对话框契约在不重排任何产品表面的前提下完成小规模、能力门控capability-gated的基础设施。Phase 2A —— 移动 Code Review Shell 与到达用「一个主手机表面 瞬态次级导航/上下文」替换被压缩的桌面组合。Phase 2B —— 移动 Plan Shell 与导航削减持久 Plan chrome恢复被阻断的文件夹/多文件路径稳定编辑与完成控件。Phase 3 —— 触摸选择与注解语义把多块 Plan 选择与多行 Pierre 选择作为独立交互原型并验证。这个顺序并非单纯按产品重要性排序而是先分离共享机制安全与信息架构再分离布局与更困难的选择语义——这样每个评审门都清晰可理解也防止「手机端临时绕过方案」反过来污染桌面偏好例如在手机上改写了桌面保存的 Split/Tree 偏好。已关闭或已在并行的区域哪些问题不用再改综合文档维护了一张「处置表」标明哪些项已经工作、关闭或保留区域处置证据/约束Tailscale 安装与 HTTPS Serve可用通过 tailnet 打开的物理 iPhone 会话返回了真实 Plan 与 Review 反馈。Mobile Safari 页面阶段1B 关闭body 滚动 非粘性紧凑 Plan chrome 让 Safari 上下控制区都能收起用户通过了结果。主评论撰写1B 关闭16 px 作者文本、刻意触摸聚焦、可见视口边界、草稿恢复与显式 Save 均已实现。发布/首次使用噪音并行栈已实现发布推广变成紧凑 Grid/Clean 决策Vim、Ask AI 与分析层启动公告不再挂载功能保留在 Settings 与真实表面。新用户 Code Review 面板默认值独立合并origin/main已包含 Tree-first 变更移动端展示不得覆盖该桌面优先产品默认值。Guided Review 介绍保留评审者认为初始 Guide 解释有用Guide 是移动理解的强候选不是应删除的噪音。Edit Code to Suggest保留被测对话框可接受建议编辑不拉入下一布局阶段。All Files保留并学习它是手机上观察到的最干净的 Code Review 展示。Phase 2B 物理反馈一个紧凑文档-chrome 契约第一次 2B.1 手机评审揭示仅恢复文件夹导航不够——选中文件后Plan 仍暴露整个桌面注解矩阵外加 Wide / Focus / Edit 微链接评审者还要求 Plan 完成决策遵循 Code Review 模式移入 Options。这些反馈被分配给 2B.2并以一个紧凑文档-chrome 契约实现到达时只显示一个Annotate · method入口而不是 Select / Pinpoint 与 Markup / Comment / Redline / Label 并列紧凑定位始终通过 Markup 语义呈现Select text 与 Pinpoint 是仅有的两个前置采集选择紧凑方法选择仅限会话内生效保护桌面偏好Wide 与 Focus 从紧凑触摸中完全移除Edit 移入 Options激活时获得常规流程的 Save / Done / Cancel 行终端决策移入 Options同时调用完全相同的既有处理器与警告路径。Phase 2B.2 明确不声明任何 Phase 3 的多块/多行选择语义——Pinpoint 单块定位与原生拖拽选择仍是 2B.2 物理门的已知输入基础。2B.1 还暴露了一个状态转换缺陷并已修复文件选择关闭了导航器随后异步链接文档激活重放了桌面「打开 Files 侧边栏」行为把紧凑导航器重新唤醒导致可见闪烁并迫使评审者先按 X 才能看到选中文档。现在紧凑激活抑制该桌面端副作用——选中文件名与文档正常渲染且导航器保持关闭而细指针桌面保留原有侧边栏激活行为。规格文档 mobile-plan-shell-phase2b-20260813.md 记录了后续的Opening…标记与加载失败重试语义。分诊矩阵Now / Next / Later 的归属逻辑综合文档用一张矩阵把全部 MOB 编号按「修复单元」重新分组原则是属于同一失效模式的条目一起做而不是按面板逐个修补。OwnerFindings严重度为何归组处置Phase 1B 关闭MOB-010, MOB-031P1Safari 页面阶段与主 composer 缺陷已通过物理 iPhone 门它们是回归契约而非开放设计工作。Closed / protectPhase 1C: 共享触摸/对话框MOB-005、MOB-012 共享部分、MOB-014/MOB-030/MOB-032 的共享对话框部分P1过小的共享控件与无边界共享对话框是机械平台缺陷先修原语后续布局才能获得安全组件而不必决定其 IA。NowPhase 2A: Review Shell/到达MOB-002, MOB-003, MOB-017, MOB-020, MOB-021, MOB-030, MOB-032, MOB-033P1它们是同一个失败桌面工作区区域在手机上同时存在。分开修面板会保留错误组合。NextPhase 2B: Plan Shell/导航MOB-001, MOB-004, MOB-013, MOB-015, MOB-016, MOB-018, MOB-019, MOB-028P0/P1Plan 阅读已可用但导航、编辑完成、辅助到达状态与持久注解 chrome 仍失败或占主导文件夹导航是当前唯一 P0。After 2APhase 3A: Plan 触摸选择MOB-008, MOB-009, MOB-029P1Pinpoint 证明点按可工作但普通原生选择与 Safari 冲突多块意图没有交互模型需要原型而非 CSS。Later, prototype firstPhase 3B: Review 触摸选择MOB-006, MOB-007P1单行选择可用扩展范围不行Pierre 渲染与行映射对回归敏感需要独立受保护的物理设备门。Later, Pierre-guarded表面加固MOB-011 次级输入、MOB-014 Settings、MOB-022 HTML、MOB-024 诊断P2真实存在但应在各自所属表面内采纳共享契约而非扩大第一个结构阶段。Later交付/性能/信任MOB-023, MOB-025, MOB-026, MOB-027P1/P2载荷、tailnet 信任、hook 交接与重连是横切交付工作而非布局工作可在不改变当前移动 IA 的前提下并行研究。Independent track严重度定义来自 SPIKEP0 为受支持的移动旅程无法完成P1 为核心评审/反馈不可用、不可靠或危险易错P2 为实质摩擦、噪音、无障碍风险或可避免的低效P3 为打磨/一致性/前瞻性问题。置信度分为 High渲染证据与源码一致、Medium源码支撑的平台风险、Low未测试概念。Phase 1C 落地44 px 触摸目标、可见视口对话框与能力门控Phase 1C 是「下一个立即实施」的检查点其结果目标是共享按钮与共享对话框关闭控件在触摸下物理安全共享对话框保持在可见 Safari 视口内可到达细指针桌面几何不变。范围与边界范围内引入共享--pn-touch-targettoken 与data-pn-touch-target标记对两个既有共享按钮原语与共享对话框关闭控件应用粗指针 44×44 最小命中区将共享对话框原语绑定到 1A/1B 建立的可见视口与安全区契约在触及的原语中将仅悬停效果门控到可悬停的细指针提供即时、克制的按下反馈与 reduced-motion 路径只转换足以证明契约的代表性共享对话框验证 iPhone 与 iPad 几何包括 iPad 混合「触摸 指针」。显式排除不批量扩大每个手写 Plan/Review 工具条控件不改 Plan toolstrip、底部操作栏或移动导航不改 Code Review 面板、Dockview、header、Guide 或 diff 组合不基于视口写 Split/Unified 偏好不改 Pierre、DiffViewer、行选择或建议编辑不引入新 sheet 系统或视觉语言。源码级实现缝隙综合文档给出的预期源码边界与实际仓库一致packages/ui/theme.css定义--pn-touch-target: 2.75rem即 44 px以及--pn-safe-top/right/bottom/left四个env(safe-area-inset-*)变量.pn-app-viewport以var(--pn-viewport-height, 100vh)作为根高度并消费顶部/内联安全区.pn-viewport-bounded把覆盖层高度限制为「可见视口高度 − 安全区」html:has([data-pn-compact-touch-layouttrue]) [data-pn-touch-target]与图标态[data-pn-touch-target-icon]分别强制最小块/内联尺寸按下态:active提供即时反馈且不会遗留粘性 hover。packages/ui/components/ui/button.tsx 与 packages/ui/components/core/button.tsx两个既有共享按钮原语默认采纳触摸目标契约。packages/ui/components/ui/dialog.tsx共享对话框关闭控件套用触摸契约并居中于可见视口 安全区舞台内。packages/ui/components/ConfirmDialog.tsx迁移到该共享原语同时保留不可点透的 backdrop 与 Command/CtrlEnter 行为并有意改善桌面无障碍——包含焦点、优先聚焦安全的 Cancel、恢复打开控件。「如果正确的 44 px 目标破坏了某行密集的手写控件就为其所属表面阶段记录问题而不是引入未文档化的紧凑特例」——这是贯穿整个改造的纪律不设隐藏逃生舱。几何验证证据响应式浏览器预检未发现水平溢出真实 Plan 确认弹窗在 320×568、390×844、390×500 键盘高度、844×390 手机横屏、768×1024 iPad 竖屏与 1180×820 iPad 横屏下都保持在 16 px 可见舞台内边距中。1280×720 细指针下既有 Plan header 控件保持 138.17×28 px 与 92.54×28 px与改前测量一致。文档明确声明浏览器模拟不暴露粗输入设备因此 44×44 命中区、按下态与混合 iPad 路径是有意的物理设备验收项而非声称的浏览器结果。1C 联合评审门检查点就绪标准包括代表性按钮与对话框关闭命中框在粗指针下 ≥44×44 且不重叠共享对话框在 320×568、390×844 与键盘缩减高度下关闭控件与主操作仍可到达按下反馈出现在 touch-down 而无粘性 hover 样式reduced-motion 与硬件键盘关闭仍可用iPad 横竖屏及触摸触控板路径可用桌面截图与计算几何在细指针下无布局变化生产 Plan/Review 构建、聚焦测试与 typecheck 通过。评审者只应做一个简短物理设备抽查而非又一次端到端评审。Phase 2A 预览让评审产物而非桌面工作区拥有手机视口Phase 2A 是第一次结构重设计其任务是把评审产物变成手机视口的主人。固定原则手机上一次只呈现一个全宽主表面Tree 仍是最佳新用户桌面默认值移动展示决策永不覆盖它文件导航、PR 上下文、注解、AI 与 Agent 变为瞬态手机表面而不是挤压 diff 的 flex 兄弟空 PR 段落不为宣布「缺席」而渲染结构手机 header 只暴露位置、导航与一个上下文动作仅桌面控件移入渐进披露手机友好的 Unified 呈现可以是会话/设备级覆盖但不得改写用户保存的桌面 Split 偏好Guide 与 All Files 是两个最强的移动起点观察入口决策应通过工作原型与物理评审做出而非响应式截图推断。2A 评审门与实施检查点实施前需用同一 GitHub PR 对比至少两个手机组合artifact-first 的 All Files / Unified 到达与 Guide-first 到达含直达原始 diff 的路径。选中组合必须保留桌面行为、在不收窄产物前提下让文件/PR 上下文可达、保持目的地决策完全可见并支持完整的单行评论与 approve/send 旅程。首版实现在codex-mobile-phase-2a-review-shell分支完成但首次物理 iPhone 评审未通过阶段门它确认了 artifact-first 方向却暴露了响应式 Chromium 无法复现的 review chrome 与 Safari-stage 问题。迭代保留了同一 artifact-first 选项同时让既有 Guided Review takeover 可从紧凑 Options 菜单直达从而可对比两种阅读组合。紧凑 Shell 的激活条件是视口宽度 ≤1024 px 且设备暴露粗指针窄细指针桌面窗口保留桌面工作区具体行为包括PR 与本地评审以全宽 All Files 到达而非在 diff 旁打开树或 PR 概览Unified 是初始会话呈现但手机上更改仅限会话永不写保存的桌面 Split/Unified 偏好Git status、Tree、Commits、PR 上下文与文件导航共用一个全舞台瞬态导航器选择目的地后关闭注解、AI 与 Review Agents 占用独立全舞台瞬态表面而非固定 flex 兄弟header 是 52 px 三列行导航、几何居中的评审位置与 Options目的地、Exit、Send/Post、Approve、Guide 与次级工具移入菜单33 px dock 条在紧凑触摸下只含标签此前 44 px 齿轮目标物理溢出到第一个文件头紧凑文件头是 44 px 行只含折叠、路径、状态与变更数Viewed、Git Add、语义/调用流徽章、实验性 Edit 与 Open-in-app 留在桌面目的地 coachmark 不在紧凑触摸挂载目的地决策已直接进入 Options平台提交对话框使用共享可见视口 Dialog到达时不弹软件键盘作者文本保持 16 px长恢复详情可滚动终端操作固定展开的评审 composer 空闲时上限 28 rem仅按可见键盘视口需要展开PR overview 用 Summary/Comments 作为互斥紧凑区域空讨论完全不渲染 Comments 区域顺带消除了一个空结构面板改善了桌面。滚动架构的两次试错最值得记录的是page-scroll proxy 的失败紧凑端页面滚动代理在物理 iPhone 评审中把文档推进而 Pierre 虚拟窗口停住产生冻结 diff 后跟大片空白且粘性 review stage 保留了不透明 Safari 顶部扩展该代理被立即移除以恢复可靠文件滚动。评审者随后评价恢复的 Pierre-owned scroller「much, much better」连续文件滚动恢复工作整体应用行为「pretty good」Safari 顶部 chrome 行为被接受为延后的隔离实验而非再次渲染器迁移的理由。文档明确指示Phase 2B 不得重开被否决的滚动架构未来任何 document-native Pierre Virtualizer 实验必须隔离并凭完整交互对等 物理测试赢得晋级。文件名问题的收尾是把硬性的 14–32 字符 basename 截断换成 Diffshub 风格的全路径 前置省略号处理这是唯一剩余的微门。2A 物理评审脚本可复用验收清单通过 Tailscale 在 iPhone有条件再上 iPad打开同一 GitHub PR确认到达是 All Files、全宽、Unified树与 PR 面板未预先打开连续滚动多个文件不得出现冻结虚拟窗口、大空白尾部、回跳开头或触摸滚动丢失确认手机 header 只有 Review 导航、居中评审位置与 Options在 Options 中验证目的地、Exit、Send/Post有反馈时与 Approve 可达确认 dock 标签行没有与第一个文件重叠的 cog/折叠簇紧凑文件头只显示折叠、路径、状态与变更数打开 Review 导航在文件、All Files 与 PR overview 间移动每次选择都回到全宽主表面PR overview 中空讨论无 Comments 控件有讨论时 Summary/Comments 切换不分割屏幕Options → Guided Review读一章后返回原始 diff从 Options 打开 Annotations及可用时的 AI/Agents确认表面替换而非挤压 diff然后关闭选中一行代码打开评论聚焦 textarea 前展开的 composer 应是合适的卡片高度而非整屏聚焦后让位键盘、文本保持 16 px、终端操作可达保存评论后打开 Post Comments 或 Approve旋转一次确认无 rail 或先前瞬态表面重现桌面刷新后 Tree 与保存的 diff 样式不变。范围累积与多行触摸选择在本门中仅作观察仍属 Phase 3。Phase 2B.1Plan 阅读优先的紧凑前台状态Phase 2B.1 在codex/mobile-phase-2b-plan-shell分支实现保留 Phase 1 的文档滚动主人引入会话级紧凑前台状态而非复用桌面 rail 布尔量即使记住的桌面右侧面板已打开紧凑触摸也先到达产物注解与 AI 按钮/面板不进入紧凑到达组合其专属前台状态属于 2B.3前导Plan披露打开一个全舞台导航器受观察可见视口与安全区约束包含 focus/Escape显式关闭恢复触发器标签与目的地行使用 44 px 触摸目标导航器复用SidebarContainer、TableOfContents、FileBrowser、VersionBrowser、MessagesBrowser与ArchiveBrowser——桌面保留粘性/可调呈现没有第二套浏览器模型Contents、文件、消息、归档与链接文档目的地返回产物标签切换留在导航器内文件加载监听紧凑 Files 状态而不写sidebar.activeTab手机上打开 Files 不改变桌面侧边栏状态文件夹注解空状态不再指示手机用户找隐藏侧边栏而是提供触摸安全的Choose a file动作打开 Files紧凑触摸下 Plan header 保持普通页面流无固定/粘性移动边缘条、Safari 滚动代理、选择语义、服务器、Tailscale 或 Pierre 代码改动。聚焦证据覆盖前台 reducer、紧凑到达桌面面板门、header 披露、共享导航器桌面/覆盖层呈现、可见视口与触摸 CSS、焦点与标签行为、文件夹空状态。1440×900 细指针浏览器控制保留了 48 px 粘性 header、240 px 粘性 Contents rail、288 px 右侧面板与零根/主水平溢出。文档再次强调响应式 Chromium 不暴露粗指针因此物理 Safari 才是权威紧凑检查点。2B.1 物理评审脚本iPhone 打开文件夹检查点到达应显示空产物与Choose a file而非侧边栏或 Ask AI点Choose a file选任意 fixture确认导航器关闭到所选文档再点Plan回 Files 选第二个文件重复同样的关闭行为Plan→ Contents 选标题确认回到同一文档该标题处且不改变 Safari 接受的页面滚动用关闭按钮关闭导航器、重开并旋转一次无右 rail、AI 面板或陈旧导航器挤压产物单独打开普通文档检查点文档——而非 Ask AI、注解或导航——必须是第一表面。本门只评导航与到达持久注解 chrome、直接编辑控件、辅助表面、完成与多块选择分别属于 2B.2、2B.3 与 Phase 3。为什么选择语义不能捆绑进布局阶段用户的 Plan 反馈确立了Pinpoint 目前是唯一可靠的触摸路径——点按打开其上下文工具栏Comment 再打开 composer普通 Select 点按无反应原生拖拽选择唤起 iOS Copy / Find Selection 菜单Plan 与 Code Review 都没有可信的多目标累积方式。综合文档明确这不是命中框 bug而是未解决的姿势与状态模型。选择阶段必须原型化显式累积、可见范围状态、取消/撤销、滚动共存与辅助技术行为Review 选择还必须保留 Pierre 的行映射与桌面鼠标范围选择。把它当作布局 PR 内的附带工作会让两个变更都更难评审、更容易回归。桌面保留契约每个阶段的不变量所有阶段始终维护以下不变量移动呈现状态是临时的或设备/会话作用域的桌面 Tree/Split/面板偏好永不因手机宽度被改写细指针几何与键盘快捷键保持现状除非阶段明确点名某个桌面缺陷共享变更是能力门控的并在严格的plannotator/uiconsumer 中测试在物理与桌面对等确认前不删除任何现有工作表面。这些不变量在源码中有直接对应useCompactTouchLayout使用(max-width: 1024px) and (pointer: coarse)媒体查询packages/ui/hooks/useIsMobile.ts特意用pointer: coarse而非any-pointer避免触屏笔记本被误判useViewportEnvironment通过 CSS 自定义属性发布可见视口几何、以单动画帧合并事件、引用计数消费者并恢复既有属性packages/ui/hooks/useViewportEnvironment.tspackages/review-editor/App.tsx 中的compactDiffStyle是会话级 stateeffectiveDiffStyle isCompactTouchLayout ? compactDiffStyle : diffStyle从实现上保证了手机上的 Unified 切换不会写回持久化 diff 偏好。阶段全景与验收方法论要点综合文档把整个移动改造组织为「先机械安全、再信息架构、再布局、最后选择语义」的四段式每段都有独立的物理设备门。贯穿始终的方法论源自 SPIKE包括冻结基线并记录 commit/版本先映射可达性再评判响应式按完整旅程而非单屏审计使用设备与输入矩阵320×568 手机竖屏、390×844 主审计、844×390 横屏、768–1194 iPad、≥1280 桌面控制分离「Observed/Measured/Source-confirmed/Platform risk/Design hypothesis」五级证据以document.scrollingElement让正文滚动收起 Safari 双端控制区物理设备证据优先于桌面模拟冲突时修订 brief 再继续。无论你关注的是 Code Review 的 artifact-first Shell、Plan 的阅读优先前台状态还是 44 px 触摸契约与 16 px 输入防聚焦缩放本仓库的packages/ui/theme.css、packages/ui/components/ui/*、packages/editor/App.tsx、packages/review-editor/App.tsx及其配套.mobile.test.tsx测试如 packages/ui/components/ui/mobile-foundation.test.tsx、packages/ui/components/sidebar/SidebarContainer.mobile.test.tsx、packages/editor/components/AppHeader.mobile.test.tsx都是可直接追踪的实现与回归证据。物理 Safari 的权威性、「无隐藏紧凑特例」「桌面偏好只读」三条纪律则是这套阶段推进能被反复验证而不塌方的根本原因。赞分享【免费下载链接】plannotatorAnnotate and review coding agent plans and code diffs visually, share with your team, send feedback to agents with one click.项目地址https://gitcode.com/gh_mirrors/pl/plannotator点击查看免费下载相关推荐Kmin/php-raylib移动端触控优化与移动设备适配Kmin/php raylib移动端触控优化与移动设备适配 痛点移动端游戏开发的触控挑战 还在为移动端游戏开发中的触控输入处理而烦恼吗传统桌面游戏移植到移游戏开发dnd-kit移动设备触摸反馈震动效果实现dnd kit移动设备触摸反馈震动效果实现 为什么需要触摸震动反馈 在移动设备上使用拖放功能时用户常常难以判断操作是否已被系统识别。特别是在复杂界面中缺乏前端UI组件TinyEXR核心功能解析从LoadEXR到SaveEXR的终极API手册TinyEXR核心功能解析从LoadEXR到SaveEXR的终极API手册 TinyEXR是一款轻量级的EXR图像加载/保存库提供了从LoadEXR到Sav创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Plannotator 移动端触控优先改造：物理设备反馈分诊、阶段排序与移动 Shell 落地指南
【免费下载链接】plannotatorAnnotate and review coding agent plans and code diffs visually, share with your team, send feedback to agents with one click.项目地址https://gitcode.com/gh_mirrors/pl/plannotator点击查看免费下载Plannotator 的 Plan 文档评审与 Code Review 产品原本是桌面优先的多窗格工作区通过 Tailscale 暴露到 iPhone/iPad 后暴露出「可达性已解决、移动性未解决」的根本矛盾。本篇以adr/research/synthesis-mobile-feedback-triage-20260812.md为核心结合SPIKE-mobile-web-compatibility研究、Phase 1/2 规格与packages/ui、packages/editor、packages/review-editor源码系统讲解 Plannotator 如何把物理设备评审反馈转化为可执行的阶段序列Phase 1C → 2A → 2B → 3如何在不破坏桌面偏好的前提下落地紧凑触控 Shellcompact touch shell以及 44 px 触摸目标、可见视口对话框、会话级 diff 样式等关键机制的真实实现。读完本文你将掌握 Plannotator 移动改造的分诊方法论、各阶段边界与验收门、以及源码级证据对应的实现缝隙implementation seam可直接用于二次开发或移植同类 touch-first 改造。背景Tailscale 解决了可达性但没有解决移动性SPIKE 研究SPIKE-mobile-web-compatibility-20260812.md在基线ef49c701c23b867cec2a5d78343813ba89d2a025v0.27.1上通过双 Agent 审计得出核心结论Tailscale 只负责把本地同一个单文件 React 应用暴露到 tailnet不会选择任何移动端渲染路径或路由Plan/文档阅读是「视觉上响应式、但尚未触控优先」——控件高度普遍只有 17–28 px触屏设备会展开每个工具条标签Code Review 是「被压缩进窄视口的桌面组合」——390 px 宽度下默认 256 px 文件树只给 Pierre diff 留下 134 px再打开固定 288 px 右侧栏只剩 102 pxGuided Review 是现存最强的移动产品原型——它已把变更集变成有序叙事流、隐藏文件树、在手机宽度下堆叠章节并复用真实 Pierre diff。而最严重的兼容性问题不是视觉多文件/文件夹注解在lg以下被阻断MOB-001。文件夹空状态提示用户「从侧边栏选择文件」但SidebarTabs与SidebarContainer在该宽度下是hidden lg评审者根本无法选中文件。从源码结构看Plan/文档应用根组件为 packages/editor/App.tsxReview 应用根组件为 packages/review-editor/App.tsx两者共用packages/ui的组件与 tokendiff 渲染依赖 Dockview 与pierre/diffs。Vite vite-plugin-singlefile将 JS/CSS/字体/资源与 Pierre 高亮 worker 全部内联进单个 HTML由 Bun 服务器常驻内存并按 SPA 返回——Tailscale 不改变这套 API 与渲染契约见 apps/hook/vite.config.ts、packages/server/index.ts。决策与推进顺序把「共享机制安全」与「信息架构」分开综合文档给出的核心决策是物理设备评审已充分不必让评审者重跑 Phase 1B 的 composer 检查清单。Safari 阶段失败是阻断性缺陷而最终的 iPhone 通过确认了其修正。后续工作严格按下列顺序推进Phase 1C —— 共享触摸与对话框契约在不重排任何产品表面的前提下完成小规模、能力门控capability-gated的基础设施。Phase 2A —— 移动 Code Review Shell 与到达用「一个主手机表面 瞬态次级导航/上下文」替换被压缩的桌面组合。Phase 2B —— 移动 Plan Shell 与导航削减持久 Plan chrome恢复被阻断的文件夹/多文件路径稳定编辑与完成控件。Phase 3 —— 触摸选择与注解语义把多块 Plan 选择与多行 Pierre 选择作为独立交互原型并验证。这个顺序并非单纯按产品重要性排序而是先分离共享机制安全与信息架构再分离布局与更困难的选择语义——这样每个评审门都清晰可理解也防止「手机端临时绕过方案」反过来污染桌面偏好例如在手机上改写了桌面保存的 Split/Tree 偏好。已关闭或已在并行的区域哪些问题不用再改综合文档维护了一张「处置表」标明哪些项已经工作、关闭或保留区域处置证据/约束Tailscale 安装与 HTTPS Serve可用通过 tailnet 打开的物理 iPhone 会话返回了真实 Plan 与 Review 反馈。Mobile Safari 页面阶段1B 关闭body 滚动 非粘性紧凑 Plan chrome 让 Safari 上下控制区都能收起用户通过了结果。主评论撰写1B 关闭16 px 作者文本、刻意触摸聚焦、可见视口边界、草稿恢复与显式 Save 均已实现。发布/首次使用噪音并行栈已实现发布推广变成紧凑 Grid/Clean 决策Vim、Ask AI 与分析层启动公告不再挂载功能保留在 Settings 与真实表面。新用户 Code Review 面板默认值独立合并origin/main已包含 Tree-first 变更移动端展示不得覆盖该桌面优先产品默认值。Guided Review 介绍保留评审者认为初始 Guide 解释有用Guide 是移动理解的强候选不是应删除的噪音。Edit Code to Suggest保留被测对话框可接受建议编辑不拉入下一布局阶段。All Files保留并学习它是手机上观察到的最干净的 Code Review 展示。Phase 2B 物理反馈一个紧凑文档-chrome 契约第一次 2B.1 手机评审揭示仅恢复文件夹导航不够——选中文件后Plan 仍暴露整个桌面注解矩阵外加 Wide / Focus / Edit 微链接评审者还要求 Plan 完成决策遵循 Code Review 模式移入 Options。这些反馈被分配给 2B.2并以一个紧凑文档-chrome 契约实现到达时只显示一个Annotate · method入口而不是 Select / Pinpoint 与 Markup / Comment / Redline / Label 并列紧凑定位始终通过 Markup 语义呈现Select text 与 Pinpoint 是仅有的两个前置采集选择紧凑方法选择仅限会话内生效保护桌面偏好Wide 与 Focus 从紧凑触摸中完全移除Edit 移入 Options激活时获得常规流程的 Save / Done / Cancel 行终端决策移入 Options同时调用完全相同的既有处理器与警告路径。Phase 2B.2 明确不声明任何 Phase 3 的多块/多行选择语义——Pinpoint 单块定位与原生拖拽选择仍是 2B.2 物理门的已知输入基础。2B.1 还暴露了一个状态转换缺陷并已修复文件选择关闭了导航器随后异步链接文档激活重放了桌面「打开 Files 侧边栏」行为把紧凑导航器重新唤醒导致可见闪烁并迫使评审者先按 X 才能看到选中文档。现在紧凑激活抑制该桌面端副作用——选中文件名与文档正常渲染且导航器保持关闭而细指针桌面保留原有侧边栏激活行为。规格文档 mobile-plan-shell-phase2b-20260813.md 记录了后续的Opening…标记与加载失败重试语义。分诊矩阵Now / Next / Later 的归属逻辑综合文档用一张矩阵把全部 MOB 编号按「修复单元」重新分组原则是属于同一失效模式的条目一起做而不是按面板逐个修补。OwnerFindings严重度为何归组处置Phase 1B 关闭MOB-010, MOB-031P1Safari 页面阶段与主 composer 缺陷已通过物理 iPhone 门它们是回归契约而非开放设计工作。Closed / protectPhase 1C: 共享触摸/对话框MOB-005、MOB-012 共享部分、MOB-014/MOB-030/MOB-032 的共享对话框部分P1过小的共享控件与无边界共享对话框是机械平台缺陷先修原语后续布局才能获得安全组件而不必决定其 IA。NowPhase 2A: Review Shell/到达MOB-002, MOB-003, MOB-017, MOB-020, MOB-021, MOB-030, MOB-032, MOB-033P1它们是同一个失败桌面工作区区域在手机上同时存在。分开修面板会保留错误组合。NextPhase 2B: Plan Shell/导航MOB-001, MOB-004, MOB-013, MOB-015, MOB-016, MOB-018, MOB-019, MOB-028P0/P1Plan 阅读已可用但导航、编辑完成、辅助到达状态与持久注解 chrome 仍失败或占主导文件夹导航是当前唯一 P0。After 2APhase 3A: Plan 触摸选择MOB-008, MOB-009, MOB-029P1Pinpoint 证明点按可工作但普通原生选择与 Safari 冲突多块意图没有交互模型需要原型而非 CSS。Later, prototype firstPhase 3B: Review 触摸选择MOB-006, MOB-007P1单行选择可用扩展范围不行Pierre 渲染与行映射对回归敏感需要独立受保护的物理设备门。Later, Pierre-guarded表面加固MOB-011 次级输入、MOB-014 Settings、MOB-022 HTML、MOB-024 诊断P2真实存在但应在各自所属表面内采纳共享契约而非扩大第一个结构阶段。Later交付/性能/信任MOB-023, MOB-025, MOB-026, MOB-027P1/P2载荷、tailnet 信任、hook 交接与重连是横切交付工作而非布局工作可在不改变当前移动 IA 的前提下并行研究。Independent track严重度定义来自 SPIKEP0 为受支持的移动旅程无法完成P1 为核心评审/反馈不可用、不可靠或危险易错P2 为实质摩擦、噪音、无障碍风险或可避免的低效P3 为打磨/一致性/前瞻性问题。置信度分为 High渲染证据与源码一致、Medium源码支撑的平台风险、Low未测试概念。Phase 1C 落地44 px 触摸目标、可见视口对话框与能力门控Phase 1C 是「下一个立即实施」的检查点其结果目标是共享按钮与共享对话框关闭控件在触摸下物理安全共享对话框保持在可见 Safari 视口内可到达细指针桌面几何不变。范围与边界范围内引入共享--pn-touch-targettoken 与data-pn-touch-target标记对两个既有共享按钮原语与共享对话框关闭控件应用粗指针 44×44 最小命中区将共享对话框原语绑定到 1A/1B 建立的可见视口与安全区契约在触及的原语中将仅悬停效果门控到可悬停的细指针提供即时、克制的按下反馈与 reduced-motion 路径只转换足以证明契约的代表性共享对话框验证 iPhone 与 iPad 几何包括 iPad 混合「触摸 指针」。显式排除不批量扩大每个手写 Plan/Review 工具条控件不改 Plan toolstrip、底部操作栏或移动导航不改 Code Review 面板、Dockview、header、Guide 或 diff 组合不基于视口写 Split/Unified 偏好不改 Pierre、DiffViewer、行选择或建议编辑不引入新 sheet 系统或视觉语言。源码级实现缝隙综合文档给出的预期源码边界与实际仓库一致packages/ui/theme.css定义--pn-touch-target: 2.75rem即 44 px以及--pn-safe-top/right/bottom/left四个env(safe-area-inset-*)变量.pn-app-viewport以var(--pn-viewport-height, 100vh)作为根高度并消费顶部/内联安全区.pn-viewport-bounded把覆盖层高度限制为「可见视口高度 − 安全区」html:has([data-pn-compact-touch-layouttrue]) [data-pn-touch-target]与图标态[data-pn-touch-target-icon]分别强制最小块/内联尺寸按下态:active提供即时反馈且不会遗留粘性 hover。packages/ui/components/ui/button.tsx 与 packages/ui/components/core/button.tsx两个既有共享按钮原语默认采纳触摸目标契约。packages/ui/components/ui/dialog.tsx共享对话框关闭控件套用触摸契约并居中于可见视口 安全区舞台内。packages/ui/components/ConfirmDialog.tsx迁移到该共享原语同时保留不可点透的 backdrop 与 Command/CtrlEnter 行为并有意改善桌面无障碍——包含焦点、优先聚焦安全的 Cancel、恢复打开控件。「如果正确的 44 px 目标破坏了某行密集的手写控件就为其所属表面阶段记录问题而不是引入未文档化的紧凑特例」——这是贯穿整个改造的纪律不设隐藏逃生舱。几何验证证据响应式浏览器预检未发现水平溢出真实 Plan 确认弹窗在 320×568、390×844、390×500 键盘高度、844×390 手机横屏、768×1024 iPad 竖屏与 1180×820 iPad 横屏下都保持在 16 px 可见舞台内边距中。1280×720 细指针下既有 Plan header 控件保持 138.17×28 px 与 92.54×28 px与改前测量一致。文档明确声明浏览器模拟不暴露粗输入设备因此 44×44 命中区、按下态与混合 iPad 路径是有意的物理设备验收项而非声称的浏览器结果。1C 联合评审门检查点就绪标准包括代表性按钮与对话框关闭命中框在粗指针下 ≥44×44 且不重叠共享对话框在 320×568、390×844 与键盘缩减高度下关闭控件与主操作仍可到达按下反馈出现在 touch-down 而无粘性 hover 样式reduced-motion 与硬件键盘关闭仍可用iPad 横竖屏及触摸触控板路径可用桌面截图与计算几何在细指针下无布局变化生产 Plan/Review 构建、聚焦测试与 typecheck 通过。评审者只应做一个简短物理设备抽查而非又一次端到端评审。Phase 2A 预览让评审产物而非桌面工作区拥有手机视口Phase 2A 是第一次结构重设计其任务是把评审产物变成手机视口的主人。固定原则手机上一次只呈现一个全宽主表面Tree 仍是最佳新用户桌面默认值移动展示决策永不覆盖它文件导航、PR 上下文、注解、AI 与 Agent 变为瞬态手机表面而不是挤压 diff 的 flex 兄弟空 PR 段落不为宣布「缺席」而渲染结构手机 header 只暴露位置、导航与一个上下文动作仅桌面控件移入渐进披露手机友好的 Unified 呈现可以是会话/设备级覆盖但不得改写用户保存的桌面 Split 偏好Guide 与 All Files 是两个最强的移动起点观察入口决策应通过工作原型与物理评审做出而非响应式截图推断。2A 评审门与实施检查点实施前需用同一 GitHub PR 对比至少两个手机组合artifact-first 的 All Files / Unified 到达与 Guide-first 到达含直达原始 diff 的路径。选中组合必须保留桌面行为、在不收窄产物前提下让文件/PR 上下文可达、保持目的地决策完全可见并支持完整的单行评论与 approve/send 旅程。首版实现在codex-mobile-phase-2a-review-shell分支完成但首次物理 iPhone 评审未通过阶段门它确认了 artifact-first 方向却暴露了响应式 Chromium 无法复现的 review chrome 与 Safari-stage 问题。迭代保留了同一 artifact-first 选项同时让既有 Guided Review takeover 可从紧凑 Options 菜单直达从而可对比两种阅读组合。紧凑 Shell 的激活条件是视口宽度 ≤1024 px 且设备暴露粗指针窄细指针桌面窗口保留桌面工作区具体行为包括PR 与本地评审以全宽 All Files 到达而非在 diff 旁打开树或 PR 概览Unified 是初始会话呈现但手机上更改仅限会话永不写保存的桌面 Split/Unified 偏好Git status、Tree、Commits、PR 上下文与文件导航共用一个全舞台瞬态导航器选择目的地后关闭注解、AI 与 Review Agents 占用独立全舞台瞬态表面而非固定 flex 兄弟header 是 52 px 三列行导航、几何居中的评审位置与 Options目的地、Exit、Send/Post、Approve、Guide 与次级工具移入菜单33 px dock 条在紧凑触摸下只含标签此前 44 px 齿轮目标物理溢出到第一个文件头紧凑文件头是 44 px 行只含折叠、路径、状态与变更数Viewed、Git Add、语义/调用流徽章、实验性 Edit 与 Open-in-app 留在桌面目的地 coachmark 不在紧凑触摸挂载目的地决策已直接进入 Options平台提交对话框使用共享可见视口 Dialog到达时不弹软件键盘作者文本保持 16 px长恢复详情可滚动终端操作固定展开的评审 composer 空闲时上限 28 rem仅按可见键盘视口需要展开PR overview 用 Summary/Comments 作为互斥紧凑区域空讨论完全不渲染 Comments 区域顺带消除了一个空结构面板改善了桌面。滚动架构的两次试错最值得记录的是page-scroll proxy 的失败紧凑端页面滚动代理在物理 iPhone 评审中把文档推进而 Pierre 虚拟窗口停住产生冻结 diff 后跟大片空白且粘性 review stage 保留了不透明 Safari 顶部扩展该代理被立即移除以恢复可靠文件滚动。评审者随后评价恢复的 Pierre-owned scroller「much, much better」连续文件滚动恢复工作整体应用行为「pretty good」Safari 顶部 chrome 行为被接受为延后的隔离实验而非再次渲染器迁移的理由。文档明确指示Phase 2B 不得重开被否决的滚动架构未来任何 document-native Pierre Virtualizer 实验必须隔离并凭完整交互对等 物理测试赢得晋级。文件名问题的收尾是把硬性的 14–32 字符 basename 截断换成 Diffshub 风格的全路径 前置省略号处理这是唯一剩余的微门。2A 物理评审脚本可复用验收清单通过 Tailscale 在 iPhone有条件再上 iPad打开同一 GitHub PR确认到达是 All Files、全宽、Unified树与 PR 面板未预先打开连续滚动多个文件不得出现冻结虚拟窗口、大空白尾部、回跳开头或触摸滚动丢失确认手机 header 只有 Review 导航、居中评审位置与 Options在 Options 中验证目的地、Exit、Send/Post有反馈时与 Approve 可达确认 dock 标签行没有与第一个文件重叠的 cog/折叠簇紧凑文件头只显示折叠、路径、状态与变更数打开 Review 导航在文件、All Files 与 PR overview 间移动每次选择都回到全宽主表面PR overview 中空讨论无 Comments 控件有讨论时 Summary/Comments 切换不分割屏幕Options → Guided Review读一章后返回原始 diff从 Options 打开 Annotations及可用时的 AI/Agents确认表面替换而非挤压 diff然后关闭选中一行代码打开评论聚焦 textarea 前展开的 composer 应是合适的卡片高度而非整屏聚焦后让位键盘、文本保持 16 px、终端操作可达保存评论后打开 Post Comments 或 Approve旋转一次确认无 rail 或先前瞬态表面重现桌面刷新后 Tree 与保存的 diff 样式不变。范围累积与多行触摸选择在本门中仅作观察仍属 Phase 3。Phase 2B.1Plan 阅读优先的紧凑前台状态Phase 2B.1 在codex/mobile-phase-2b-plan-shell分支实现保留 Phase 1 的文档滚动主人引入会话级紧凑前台状态而非复用桌面 rail 布尔量即使记住的桌面右侧面板已打开紧凑触摸也先到达产物注解与 AI 按钮/面板不进入紧凑到达组合其专属前台状态属于 2B.3前导Plan披露打开一个全舞台导航器受观察可见视口与安全区约束包含 focus/Escape显式关闭恢复触发器标签与目的地行使用 44 px 触摸目标导航器复用SidebarContainer、TableOfContents、FileBrowser、VersionBrowser、MessagesBrowser与ArchiveBrowser——桌面保留粘性/可调呈现没有第二套浏览器模型Contents、文件、消息、归档与链接文档目的地返回产物标签切换留在导航器内文件加载监听紧凑 Files 状态而不写sidebar.activeTab手机上打开 Files 不改变桌面侧边栏状态文件夹注解空状态不再指示手机用户找隐藏侧边栏而是提供触摸安全的Choose a file动作打开 Files紧凑触摸下 Plan header 保持普通页面流无固定/粘性移动边缘条、Safari 滚动代理、选择语义、服务器、Tailscale 或 Pierre 代码改动。聚焦证据覆盖前台 reducer、紧凑到达桌面面板门、header 披露、共享导航器桌面/覆盖层呈现、可见视口与触摸 CSS、焦点与标签行为、文件夹空状态。1440×900 细指针浏览器控制保留了 48 px 粘性 header、240 px 粘性 Contents rail、288 px 右侧面板与零根/主水平溢出。文档再次强调响应式 Chromium 不暴露粗指针因此物理 Safari 才是权威紧凑检查点。2B.1 物理评审脚本iPhone 打开文件夹检查点到达应显示空产物与Choose a file而非侧边栏或 Ask AI点Choose a file选任意 fixture确认导航器关闭到所选文档再点Plan回 Files 选第二个文件重复同样的关闭行为Plan→ Contents 选标题确认回到同一文档该标题处且不改变 Safari 接受的页面滚动用关闭按钮关闭导航器、重开并旋转一次无右 rail、AI 面板或陈旧导航器挤压产物单独打开普通文档检查点文档——而非 Ask AI、注解或导航——必须是第一表面。本门只评导航与到达持久注解 chrome、直接编辑控件、辅助表面、完成与多块选择分别属于 2B.2、2B.3 与 Phase 3。为什么选择语义不能捆绑进布局阶段用户的 Plan 反馈确立了Pinpoint 目前是唯一可靠的触摸路径——点按打开其上下文工具栏Comment 再打开 composer普通 Select 点按无反应原生拖拽选择唤起 iOS Copy / Find Selection 菜单Plan 与 Code Review 都没有可信的多目标累积方式。综合文档明确这不是命中框 bug而是未解决的姿势与状态模型。选择阶段必须原型化显式累积、可见范围状态、取消/撤销、滚动共存与辅助技术行为Review 选择还必须保留 Pierre 的行映射与桌面鼠标范围选择。把它当作布局 PR 内的附带工作会让两个变更都更难评审、更容易回归。桌面保留契约每个阶段的不变量所有阶段始终维护以下不变量移动呈现状态是临时的或设备/会话作用域的桌面 Tree/Split/面板偏好永不因手机宽度被改写细指针几何与键盘快捷键保持现状除非阶段明确点名某个桌面缺陷共享变更是能力门控的并在严格的plannotator/uiconsumer 中测试在物理与桌面对等确认前不删除任何现有工作表面。这些不变量在源码中有直接对应useCompactTouchLayout使用(max-width: 1024px) and (pointer: coarse)媒体查询packages/ui/hooks/useIsMobile.ts特意用pointer: coarse而非any-pointer避免触屏笔记本被误判useViewportEnvironment通过 CSS 自定义属性发布可见视口几何、以单动画帧合并事件、引用计数消费者并恢复既有属性packages/ui/hooks/useViewportEnvironment.tspackages/review-editor/App.tsx 中的compactDiffStyle是会话级 stateeffectiveDiffStyle isCompactTouchLayout ? compactDiffStyle : diffStyle从实现上保证了手机上的 Unified 切换不会写回持久化 diff 偏好。阶段全景与验收方法论要点综合文档把整个移动改造组织为「先机械安全、再信息架构、再布局、最后选择语义」的四段式每段都有独立的物理设备门。贯穿始终的方法论源自 SPIKE包括冻结基线并记录 commit/版本先映射可达性再评判响应式按完整旅程而非单屏审计使用设备与输入矩阵320×568 手机竖屏、390×844 主审计、844×390 横屏、768–1194 iPad、≥1280 桌面控制分离「Observed/Measured/Source-confirmed/Platform risk/Design hypothesis」五级证据以document.scrollingElement让正文滚动收起 Safari 双端控制区物理设备证据优先于桌面模拟冲突时修订 brief 再继续。无论你关注的是 Code Review 的 artifact-first Shell、Plan 的阅读优先前台状态还是 44 px 触摸契约与 16 px 输入防聚焦缩放本仓库的packages/ui/theme.css、packages/ui/components/ui/*、packages/editor/App.tsx、packages/review-editor/App.tsx及其配套.mobile.test.tsx测试如 packages/ui/components/ui/mobile-foundation.test.tsx、packages/ui/components/sidebar/SidebarContainer.mobile.test.tsx、packages/editor/components/AppHeader.mobile.test.tsx都是可直接追踪的实现与回归证据。物理 Safari 的权威性、「无隐藏紧凑特例」「桌面偏好只读」三条纪律则是这套阶段推进能被反复验证而不塌方的根本原因。赞分享【免费下载链接】plannotatorAnnotate and review coding agent plans and code diffs visually, share with your team, send feedback to agents with one click.项目地址https://gitcode.com/gh_mirrors/pl/plannotator点击查看免费下载相关推荐Kmin/php-raylib移动端触控优化与移动设备适配Kmin/php raylib移动端触控优化与移动设备适配 痛点移动端游戏开发的触控挑战 还在为移动端游戏开发中的触控输入处理而烦恼吗传统桌面游戏移植到移游戏开发dnd-kit移动设备触摸反馈震动效果实现dnd kit移动设备触摸反馈震动效果实现 为什么需要触摸震动反馈 在移动设备上使用拖放功能时用户常常难以判断操作是否已被系统识别。特别是在复杂界面中缺乏前端UI组件TinyEXR核心功能解析从LoadEXR到SaveEXR的终极API手册TinyEXR核心功能解析从LoadEXR到SaveEXR的终极API手册 TinyEXR是一款轻量级的EXR图像加载/保存库提供了从LoadEXR到Sav创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考