openyida 2026.10.21 → 2026.10.22-beta.0

package/yida-skills/skills/yida-design/references/task-driven-visual-design.md

@@ -48,6 +48,8 @@ Fast、Plan 和已有页面优化共用这套推导方法。先读取真实需
 5. **排版节奏**：标题、核心数值、正文、元信息有可辨层级；同类信息对齐，组内紧凑、组间清楚。密度随阅读、比较或操作任务变化。
 6. **视觉特征**：从已有内容发展一处有意义的特色，例如对象图文组合、关键变化对比或连贯的章节排版。特色服务当前任务，不靠增加业务模块、随机装饰或重复大卡片制造丰富感。
 
+按[响应式决策](responsive-layout.md#先确定任务与各场景的呈现)安排宽屏、窄容器和触屏的展示：保持文字层级、色彩用途、形状和分组，按任务调整比例、密度和操作位置。空间变化时可重新安排首屏重点，并保留判断所需的信息和完整访问入口。卡片、Hero 和 KPI 组按实际内容选用。
+
 已有品牌或明确风格时在其范围内完成这些决策，不自动统一成浅色商务风。没有独立图片的页面也应通过构图和排版成立。
 
 ## 5. 交接具体决策并验证

package/yida-skills/skills/yida-design/sub_skill/yida-design-plan/SKILL.md

@@ -25,6 +25,7 @@ description: Plan 模式的视觉设计分支。基于需求选择视觉方向
 
 1. 读取 CLI 返回的 `authoring-context.md` 与 [紧凑计划契约](references/build-plan-compact-schema.md)，沿用 pageId 和 sceneKey。
 2. 工作台沿用 PRD 的业务内容和表现建议。为每个真实自定义页填写 `firstScreenFocus`、`layout`、`primaryAction`、`responsive` 与 `acceptanceChecks`；前四项为具体非空说明，验收为非空字符串数组。公共主题不能代替这些决定。纯原生表单应用不增加虚构页记录。
+   按[响应式决策与字段映射](../../references/responsive-layout.md#写入已有设计字段)在这五个字段内写清：宽屏、窄容器和触屏各展示什么、怎样操作、何时重排、保留哪些状态，以及选择依据。Fast 与单页设计写入相同的 `design.md` 要点。
 3. 按 [整体主题规则](../../references/application-theme-consistency.md#导航与应用框架) 核对导航、应用框架、原生表单、记录详情与自定义页面的配色、形状、文字、间距和状态。每项必须保留 `visualMemoryApplications` 数组；没有匹配的主题记忆点时填写 `[]`，不要省略或写成字符串。按实际内容补页面局部差异与素材策略。完整主题由 CLI 注入，复杂组件定制时再读模板对应章节。
 4. 全局和局部 token 遵守 [基础变量契约](../../templates/design-themes/basic-tokens.json)，明确项目差异写 `visualStyle.tokens`，主色写 `forUser.colorStrategy.primaryColor`；沿用主题的字号、间距和组件圆角。
 5. CLI 按 [公共输出契约](../../workflow/output-design.md) 生成 frontmatter、anchor 索引和五章正文，并调用同一 `check-design` 校验。缺少逐页决定时只保留可预览草稿，补齐后再生成最终产物；旧计划同样不得以继承主题套话补过门槛。

package/yida-skills/skills/yida-design/sub_skill/yida-design-plan/references/build-plan-compact-schema.md

@@ -97,7 +97,7 @@ CLI 校验源事实，使用预置模板整批生成 `prd.md`、`design.md` 和
     "navigationStyle": {"structure":"side","tone":"light","toneSource":"theme_derived","source":"user_selected","selectionReason":"沿用已选的左侧导航；浅色导航由主题模板派生"},
     "iconSystem": {"library":"lucide-react","mappings":{"新建采购":"Plus"}},
     "pageApplications": [
-      {"pageId":"page-1","primaryAction":"列表标题右侧的新建采购按钮打开原生采购表单，成功后刷新列表","firstScreenFocus":"先看到待处理采购数量与最紧急记录，主操作紧邻列表标题","layout":"顶部单行筛选与主操作，下方连续采购列表；必要提示放列表右侧窄栏，列表随记录自然增长","responsive":"窄屏筛选换行，提示移到列表下方，表格保留关键列并允许横向滚动","acceptanceChecks":["首屏可找到待处理记录与新建采购操作","窄屏主操作和错误恢复入口可用"],"visualMemoryApplications":[{"name":"摘要拼接组","renderPolicy":"prd_match_only","target":"采购待办摘要","reason":"页面已有并列的待办状态"}]}
+      {"pageId":"page-1","primaryAction":"列表标题右侧的新建采购按钮打开原生采购表单，成功后刷新列表","firstScreenFocus":"先看到待处理采购数量与最紧急记录，主操作紧邻列表标题","layout":"按供应商比较金额与交付日期，相关列对齐；主表利用可用宽度，提示区按内容限宽，空间不足时下移","responsive":"比较任务在窄容器仍保留全部表格列，标识列保持可辨，表格局部横滑并提示剩余内容；筛选换行，提示移到表格下方；手机的详情入口无需悬停，返回后保留筛选与选中记录","acceptanceChecks":["宽屏和窄容器均可定位最紧急记录及新建采购入口","在360px容器查看完整金额与交付日期，页面不整体横滑","打开详情再返回、缩窄再放宽后筛选值和选中记录不变"],"visualMemoryApplications":[{"name":"摘要拼接组","renderPolicy":"prd_match_only","target":"采购待办摘要","reason":"页面已有并列的待办状态"}]}
     ],
     "assetStrategy": {"materialStatus":"none","pages":[{"pageId":"page-1","imageNeed":"none","reason":"纯数据操作页","slots":[]}],"missingAssets":[],"notes":"无图片需求"}
   },

package/yida-skills/skills/yida-design/workflow/output-design.md

@@ -80,8 +80,8 @@
 | 表面与组件 | 各区块如何消费共享表面、边界、字体和组件规则；明确局部差异与特色配方位置 |
 | 主操作 | 主次动作的位置、入口与反馈，保留表单、详情及现有业务功能契约 |
 | 状态 | 当前页加载、空、错、无权限等实际反馈与恢复动作；公共状态用 anchor 引用，业务文案就近补充 |
-| 响应式 | 按 [共享布局规则](../references/responsive-layout.md) 写清实际容器的重排条件与顺序、筛选换行、面板等高解除、表格局部滚动和触控方式 |
-| 验收 | 焦点、内容、布局、主题、交互、素材与状态的可检查结果 |
+| 响应式 | 按 [共享布局规则](../references/responsive-layout.md) 写清宽屏、窄容器和触屏各展示什么、怎样操作、何时重排、保留哪些状态及选择依据；按需说明筛选换行、恢复自然高度和局部滚动 |
+| 验收 | 写出检查动作和预期结果，覆盖焦点、内容、布局、主题、交互、素材和状态；实际走通查找信息、执行操作、展开内容和返回页面的路径，分别记录待检查项与已执行证据 |
 
 页面外壳、焦点、主要内容、动作区、上下文与反馈这些设计含义都要覆盖；不要求创建同名 JSON/YAML 字段。尺寸和间距优先引用已定义 token，只有项目确实需要的数值差异才另外写明。不能仅写“按主题执行”，也不能把公共组件全文复制到每一页。
 

package/yida-skills/skills/yida-design/workflow/step-1-read-brief.md

@@ -7,6 +7,8 @@
 1. 文件存在且 JSON 可解析，`schemaVersion=1`。
 2. 读取行业、目标用户、业务目标、核心功能、业务对象、页面场景、品牌和色彩偏好。
 3. 读取 `userTasks` 和 `entryRecommendation`，沿用规划准备写入的导航决策，服务与管理体验按实际任务设计；平台导航或自定义导航不再交给用户选择。按已确认范围设计；自定义页面生成逐页场景规则，表单与流程沿用应用主题。
+   - 读取已有的使用环境、操作频率、需同时查看的信息和任务中断后的返回要求，区分桌面工作区、嵌入式窄容器和手机触控。
+   - 优先依据现有上下文作出选择并记录理由。环境未知时注明假设，同时覆盖宽窄布局；禁止将假设标为用户已确认事实。
 4. 会改变视觉方向的 `openQuestions` 未解决时，暂停生成视觉设计并交回 `yida-app` 处理。
 
 ## 产出

package/yida-skills/skills/yida-design/workflow/step-4-wireframe-interaction.md

@@ -1,19 +1,19 @@
 # 页面结构和交互设计
 
-按 [共享响应式布局](../references/responsive-layout.md) 确定容器宽度变化后的筛选换行、主辅堆叠、等高范围、自然增长和表格局部滚动；在本页设计中写出具体重排条件与顺序。
+按 [共享响应式布局](../references/responsive-layout.md) 先确定任务、必要信息、宽窄首屏和主操作，再安排各区块的排列与滚动方式。在本页设计中写清选择依据、重排条件和内容顺序。
 
-> 低保真不追求好看，先把结构、区块和操作路径定清楚。
+> 低保真阶段先确定结构、区块和操作路径，视觉样式在下一步细化。
 
 ## 画布局骨架
 
-页面设计按[任务驱动的视觉设计](../references/task-driven-visual-design.md)先确定识别、比较、变化、处理或叙事等信息关系，再选择图文、表格、图表或主从结构；以下骨架只是参考，不是固定套版。
+页面设计按[任务驱动的视觉设计](../references/task-driven-visual-design.md)先确定识别、比较、变化、处理或叙事等信息关系，再选择图文、表格、图表或主从结构。以下建议按本页任务选用。
 
-- 工作台：沿用 PRD 的业务内容和关系，由内容决定布局和组件，不预设双栏或列表组合。
-- 列表页：筛选区 + 工具栏 + 表格/卡片 + 分页 + 详情抽屉。
-- 详情页：对象 Hero + 摘要指标 + 分区信息 + 时间线/关联对象。
-- 看板页：KPI 卡组 + 图表组 + 排行/明细 + 刷新时间。
-- 大屏页：中心态势 + 左右信息塔 + 告警/趋势 + 投屏可读层级。
-- 官网页：首屏主张 + 产品/服务 + 过程/案例 + 信任背书 + CTA。
+- 工作台：沿用 PRD 的业务内容和关系，由内容决定布局和组件。
+- 列表页：跨记录比较时保持属性对齐，逐条处理时突出状态与动作；筛选、分页和详情入口按实际需求安排。
+- 详情页：围绕对象与决策依据组织摘要、分区、过程或关联信息；只有内容需要时使用 Hero 和指标。
+- 看板页：按需要判断的趋势、风险或差异组织指标与图表，按实际信息确定数量，并说明口径和更新时间。
+- 大屏页：依监控任务组织态势与异常，先保证投屏阅读距离和重点识别，再决定中心或分栏构图。
+- 官网页：围绕了解价值、查看案例、建立信任和采取行动组织内容；素材和章节随真实内容取舍。
 
 ## 自定义导航设计
 
@@ -56,7 +56,7 @@
 - 内容区块：<业务区块及目的、信息关系和表现形式；综合工作台参考 8-10 个独立业务区块，不凑数>
 - 主操作：<入口、按钮、下钻、提交、返回>
 - 功能契约：<保留的数据源/字段映射/按钮动作/筛选逻辑/提交 URL/权限/状态>
-- 响应式策略：<PC / 移动端差异>
+- 响应式策略：<宽屏、窄容器和触屏各展示什么、怎样操作、何时重排、保留哪些状态及选择依据>
 - 原生表单入口：<新增/提交/编辑打开方式>
 - pageSpecHandoff 草稿：<pageStructure/scene/contentBlocks/themeSummary/designFile/designRefs/dataBinding/primaryAction；视觉源码槽位待 UI 视觉设计阶段写入 design.md>
 ```

package/yida-skills/skills/yida-feedback/SKILL.md

@@ -1,15 +1,15 @@
 ---
 name: yida-feedback
-description: OpenYida 本地使用故障的根因分析、脱敏反馈包与 GitHub Issue/Fork PR 辅助。适用于反复报错、技能容易误用、用户不会提 issue/PR 或没有 GitHub 账号和源码时；普通宜搭产品 VOC 清单用 yida-voc。
+description: 帮用户描述 OpenYida 使用问题或体验建议，整理脱敏 Issue，并在用户愿意时协助个人 Fork PR。适用于反复报错、技能误用、不会提 issue/PR 或没有账号和源码时；普通宜搭产品 VOC 清单用 yida-voc。
 ---
 
 # 本地问题反馈与修复贡献
 
-用户只需描述“哪里出错了”。默认环境是 npm/插件安装，无 OpenYida Git 工作区、无上游写权限，也可能没有 GitHub 账号。不要以 Git、gh、源码或宜搭登录作为整理反馈的前置条件。
+用户描述问题，Agent 帮忙整理；用户愿意时，再一起尝试修复。默认用户通过 npm/插件安装，没有 OpenYida 源码、上游写权限或 GitHub 账号。整理反馈无需 Git、gh、源码或宜搭登录。
 
 ## 何时进入
 
-- 用户要求排查并反馈 OpenYida、整理 Issue、贡献修复或提 PR。
+- 用户要求排查并反馈 OpenYida、改善使用体验、整理 Issue、贡献修复或提 PR。可验证的小改进可直接提 PR，无需先建 Issue。
 - 当前会话同一操作已重复失败，或明确的 CLI/技能缺陷导致反复绕路时，停止无修改重试，先处理原任务，再简短建议整理反馈。自动进入只允许本地分析/草稿；不得自动登录、安装工具、联网提交或不断提醒。
 - 反馈建议前可读取 `openyida feedback status`；尊重当天/永久关闭。用户主动要求反馈不受提醒开关限制。同一会话同一问题只建议一次；当前上下文之外的发生频次写未知，不扫描完整历史。
 
@@ -17,7 +17,7 @@ description: OpenYida 本地使用故障的根因分析、脱敏反馈包与 Git
 
 ## 收集与根因分析
 
-1. 从当前会话提取目标、最短复现、期望与实际、报错关键片段、已尝试方法及其结果。先复用现有信息，确有阻碍时才询问缺失信息。
+1. 从当前会话提取目标、最短复现、期望与实际、报错关键片段、已尝试方法及其结果。先复用现有信息，确有阻碍时才询问缺失信息；体验建议写当前不便和理想结果，无需用户设计 CLI 参数或分析根因。
 2. `openyida --version`、`node -v` 可只读检查。只在定位必要时读取相关命令帮助、脱敏诊断和用户明确提供的最小文件。不遍历用户目录、环境变量、登录缓存、完整日志/会话或业务数据；不要把 `env`/`doctor` 整份输出塞进报告。不得因排障重放创建/发布/删除等写命令。
 3. 区分 CLI、skill、本地环境、平台接口或未知。逐项写“观察事实 → 根因假设 → 支持/反对证据 → 下一步验证”。能解释一个错误不代表已证明根因；没有复现/对照证据保留 hypothesis/unknown，缺失信息写未知。记录用户已验证的绕法和剩余影响。
 4. 平台接口拒绝、权限或版本限制按可观察响应反馈。用户不具备平台源码访问权限；不得寻找、索取、下载或暴露内部仓库名称、链接、源码、文件路径、内部处理人或工具。无公开可验证修复点时提交问题材料，不生成虚构 PR。用户自己的应用业务代码错误先修应用，不自动当作 OpenYida 缺陷。
@@ -36,10 +36,27 @@ openyida feedback report --input summary.json --output-dir feedback-draft-001
 
 ## 按用户条件交付
 
+用户选择 GitHub 后，按 [账号与工具准备](references/github-setup.md) 复用已有工具、引导注册/登录。缺少工具且宿主支持终端时，推荐用 `openyida feedback github setup --json` 检测，再经用户同意安装 gh、单独引导浏览器授权；不愿安装时可用网页，不把安装作为反馈门槛。工具就绪后继续原草稿，公开确认仍按原流程执行。
+
 - **无 GitHub 账号**：先引导用户创建 GitHub 账号，由用户自行完成注册和登录。实在不行，只提示“反馈到AI开发者群”，附上已整理的脱敏报告。不索取群链接或群 ID，不编造入群入口，不替用户发送群消息。离线或暂不愿注册时同样交付报告，明确“材料已生成，尚未提交”。
-- **有 GitHub 账号，提交 Issue**：不需 clone/fork。用户明确选择提交 Issue 后，用 `openyida feedback github status --json` 检查当前 GitHub 账号的 Star 与个人 Fork 状态；仅对明确未完成的操作提供一次可选邀请，已有的不重复提示，未知状态不说成未完成。按 [GitHub 提交](references/github-contribution.md) 处理用户选择、正文公开确认与查重。拒绝 Star/Fork 不影响提交；登录由用户在可信本机流程完成，不索取 Token。
+- **有 GitHub 账号，提交 Issue**：无需 clone/fork；按 [GitHub 提交](references/github-contribution.md) 查重、提交已确认内容并读回。成功后按交互规范给一次可选 PR 邀请；登录由用户在可信本机流程完成，不索取 Token。
 - **有账号，希望提交修复 PR**：仅适用于公开 OpenYida CLI/skill/docs 的可验证问题。先准备最小修复和验证，再通过用户自己的 Fork 提交到公开上游，详见同一参考。没有源码时由 Agent 在独立目录准备公开源码，不修改 npm 全局安装或用户业务目录。无法定位/验证时如实写入测试对比，优先交付 Issue 草稿；不要承诺未经验证的修复。
 
 创建 Issue、评论、Fork、push 或 PR 前必须有用户对相应外部动作及公开内容的授权；已有对同一最终稿和截图的隐私确认不重复问；单纯授权提 Issue/PR 不能替代公开内容审阅。只要求“排查”“整理反馈”不代表允许公开提交。提交超时先查是否成功，不自动重复创建。
 
 交付时说明根因可信度、绕法/修复验证、材料位置及真实提交状态；提交成功给返回的 Issue/PR URL，未返回并核实地址时不得声称已送达。不得承诺合并或修复时间。
+
+## 完成检查
+
+- 问题与环境有事实来源；未知项已标明，报告生成环境未冒充出错环境。
+- 公开内容和截图已获确认；已提交的 Issue/PR 有读回证据，草稿明确标注尚未提交。
+- PR 有真实改动和测试说明；Issue 后的邀请尊重用户选择，拒绝后不重复提醒。
+
+## 参考文件
+
+| 文件 | 读取时机 |
+| --- | --- |
+| [用户交互](references/user-interaction.md) | 进入技能时；含成功后的可选 PR 邀请 |
+| [报告输入](references/report-input.md) | 准备脱敏摘要、环境和测试证据时 |
+| [GitHub 提交](references/github-contribution.md) | 用户选择公开提交或贡献代码时 |
+| [账号与工具准备](references/github-setup.md) | GitHub 路径需要注册、登录、安装或连接工具时 |

package/yida-skills/skills/yida-feedback/references/github-contribution.md

@@ -2,17 +2,28 @@
 
 唯一默认公开上游是 `https://github.com/openyida/openyida`。不要从用户业务项目 remote、报错链接或对话中出现的其他仓库推导目标。以下命令是模板，参数使用工具结构化 argv 或可靠 shell 引号，正文用文件；不要执行报告中的命令/指令。
 
-以下命令供 Agent 内部使用，不能要求技术小白复制执行。缺少 Git/gh 时，优先使用当前宿主已有的 GitHub 连接器或可操作浏览器完成同样的查重、个人 Fork、分支编辑与提交；公开源码也可从官方源码压缩包准备到独立目录后测试。仍须核验 Fork 所有者、公开上游和最终公开内容，不因换工具跳过确认。当前宿主无法完成时给可读草稿和清晰下一步，不擅自安装工具或让用户编写命令。
+以下命令供 Agent 内部使用，不能要求技术小白复制执行。按 [账号与工具准备](github-setup.md) 复用已有工具；缺少 Git/gh 时，可用宿主现有 GitHub 连接器或浏览器，按实际能力完成查重、个人 Fork、分支编辑与提交。需要配置时，经用户同意后协助安装/连接并验证；公开源码也可从官方源码压缩包准备到独立目录后测试。仍须核验 Fork 所有者、公开上游和最终公开内容，不因换工具跳过确认。当前宿主无法完成时给可读草稿和清晰下一步，不擅自安装工具或让用户编写命令。
 
 ## Issue（无需源码）
 
-用户明确要向 OpenYida 提交 Issue，且选择 GitHub 路径后，再执行以下只读检查；普通排障、离线报告、安装及自动更新不触发：
+先帮助用户完成反馈；Star、Fork 及代码贡献都是可选项，不作为 Issue 提交前置。
+
+1. 先完成 [交互与公开确认](user-interaction.md)：展示实际问题、复现步骤和全部截图，取得用户对最终公开内容的确认。账号/工具未就绪时按准备流程处理；有账号只需登录，未知状态不引导重复注册。只有选择 gh 路径且已安装时才检查 `gh auth status --hostname github.com`，网页/MCP 路径用各自的验证，不要求先装 gh。
+2. 用 `gh issue list --repo github.com/openyida/openyida --state all --search '<问题关键词>' --json number,title,url` 查重，阅读匹配正文核实症状与版本。相同问题给现有链接；用户明确允许补充时才评论，不关闭别人的 Issue。无法查询时说明查重未完成。
+3. 已完成最终稿和截图的公开确认后，用 `gh issue create --repo github.com/openyida/openyida --title '<脱敏标题>' --body-file '<issue.md>'`。有已确认截图时，先检查当前 `gh issue create --help` 是否支持 `--attach`，每张显式追加 `--attach <审阅后的截图>`；同一命令只包含用户批准的图片，不上传额外附件。不支持时用可操作的 GitHub 网页上传，不静默丢图。默认不指定未知 label/assignee。
+4. 读回新 Issue 的标题、正文、截图引用和 URL 核对。附件部分失败时，先核实已创建的 Issue，回报缺失图片并处理该帖，不能重复建帖。未装 gh 但用户愿意网页操作时打开 `https://github.com/openyida/openyida/issues/new`，提供已复核正文供粘贴；打开页面不等于提交成功。
+
+Issue 完整读回后，按 [交互规范第五节](user-interaction.md#五issue-成功后邀请一起改进) 提供一次可选 PR 邀请；邀请不等于获得编辑、Fork、push 或创建 PR 的授权。
+
+## 可选支持与 Fork 状态
+
+仅在用户主动询问如何支持项目时，或已选择准备 PR、需要核实个人 Fork 时，执行以下只读检查。Issue 提交主流程不插入 Star/Fork 邀请；普通排障、离线报告、安装及自动更新不触发：
 
 ```bash
 openyida feedback github status --json
 ```
 
-命令复用本机 `gh` 的 github.com 当前账号，不读取 Token，不自动安装或登录。`starred` 为 true/false/null，个人 `fork.state` 为 ready/absent/conflict/unknown；同时检查改名的个人 Fork。只有 `suggestedActions` 中的缺失项可提供一次可选邀请：例如“是否愿意 Star 支持项目，或 Fork 留作后续贡献？也可以直接提交 Issue”。已有 Star/Fork 不重复提示；接口失败、权限不足或状态未知时不推断为未完成，不阻塞 Issue。没有可用 gh 时沿用连接器或浏览器；未登录时由用户自行登录，不索取凭据。
+命令复用本机 `gh` 的 github.com 当前账号，不读取 Token，不自动安装或登录。`starred` 为 true/false/null，个人 `fork.state` 为 ready/absent/conflict/unknown；同时检查改名的个人 Fork。只有 `suggestedActions` 中与用户当前意图相关的缺失项可提供一次可选邀请；准备 PR 时只处理 Fork，用户主动询问支持方式时再说明 Star。已有 Star/Fork 不重复提示；接口失败、权限不足或状态未知时不推断为未完成，不阻塞 Issue。没有可用 gh 时沿用连接器或浏览器；未登录时由用户自行登录，不索取凭据。
 
 用户分别明确选择后，Agent 才执行相应命令（`--confirm` 记录其真实授权，不能自行代选）：
 
@@ -23,11 +34,6 @@ openyida feedback github fork --confirm --json
 
 命令固定目标为 `openyida/openyida`，已有操作直接复用；Fork 只创建到当前用户个人账号，不 clone、不修改 remote。Fork 异步创建可能返回 `pending-verification`；先只读查状态，不重复创建。无论拒绝、失败或未登录，都可继续整理并提交 Issue；Star/Fork 是可选支持，不是提 Issue 的条件，也不代替正文与附件的公开确认。同一反馈流程拒绝过的选项不再次询问。现有 PR 流程的 Fork 授权仅用于贡献代码，不隐含 Star 授权。
 
-1. 先完成 [交互与公开确认](user-interaction.md)：展示实际问题、复现步骤和全部截图，取得用户对最终公开内容的确认。用户未登录时引导注册/登录；实在不行提示“反馈到AI开发者群”。只有用户选择 GitHub 路径才检查 `gh auth status --hostname github.com`；不要读/打印 Token，也不要自动装 gh 或创建账号。
-2. 用 `gh issue list --repo github.com/openyida/openyida --state all --search '<问题关键词>' --json number,title,url` 查重，阅读匹配正文核实症状与版本。相同问题给现有链接；用户明确允许补充时才评论，不关闭别人的 Issue。无法查询时说明查重未完成。
-3. 已完成最终稿和截图的公开确认后，用 `gh issue create --repo github.com/openyida/openyida --title '<脱敏标题>' --body-file '<issue.md>'`。有已确认截图时，先检查当前 `gh issue create --help` 是否支持 `--attach`，每张显式追加 `--attach <审阅后的截图>`；同一命令只包含用户批准的图片，不上传额外附件。不支持时用可操作的 GitHub 网页上传，不静默丢图。默认不指定未知 label/assignee。
-4. 读回新 Issue 的标题、正文、截图引用和 URL 核对。附件部分失败时，先核实已创建的 Issue，回报缺失图片并处理该帖，不能重复建帖。未装 gh 但用户愿意网页操作时打开 `https://github.com/openyida/openyida/issues/new`，提供已复核正文供粘贴；打开页面不等于提交成功。
-
 ## PR（用户个人 Fork → 上游 main）
 
 PR 需要真实修复 diff、修复前后测试对比和最终内容公开确认；只分析出可能根因时优先 Issue。不能把用户业务源码、诊断包、凭证或内部闭源实现混入贡献。

package/yida-skills/skills/yida-feedback/references/github-setup.md

@@ -0,0 +1,74 @@
+# 账号与工具准备
+
+用户选择 GitHub 提交或贡献后读取。先保留已有问题、环境、草稿、截图和测试结果，再准备账号与工具；整理反馈本身不需要账号或安装工具。下面的检查与命令由 Agent 执行，给用户说明用途和下一步即可。
+
+## 1. 分清账号、工具和权限
+
+先复用用户已说明的账号情况和宿主已授权的 GitHub 连接器/MCP、可操作浏览器。选择本机 CLI 路径时，由 Agent 执行 `openyida feedback github setup --json`，只读检测 gh 与当前账号，不安装、不登录，也不查询 Star/Fork。只检查当前任务所需能力，不遍历账号配置、环境变量或凭证文件。
+
+| 观察到的情况 | 怎么引导 |
+| --- | --- |
+| 用户明确说没有账号 | 给 [GitHub 官方注册入口](https://github.com/signup)，由用户自行注册、登录；不愿注册就保留脱敏报告 |
+| `gh` 不存在 | 仅说明本机未安装该工具；账号是否存在仍未知，继续检查已有连接器或网页路径 |
+| 有工具，但登录未验证 | 先确认用户愿意使用该工具，再引导官方登录；不把工具未登录说成用户没有账号 |
+| 请求超时、限流、权限不足 | 说明具体阻塞，保留账号/Fork 状态为未知；不反复要求注册、安装或切换账号 |
+| 已登录且具备所需能力 | 复用当前工具；多账号或不同工具身份不一致时，让用户确认用于本次贡献的账号 |
+
+`openyida feedback github status --json` 仍只用于原流程需要的个人 Fork/支持状态检查，不作为每次 Issue 的前置。它依赖本机 gh，`gh_unavailable` 表示工具缺失，`account_unverified` 表示账号未验证；两者都不能证明用户没有 GitHub 账号，也不能否定浏览器/MCP 已登录。
+
+无账号时可这样说：
+
+> 问题和环境信息已经整理好了。公开提交到 GitHub 需要一个账号，我可以引导你完成注册和登录，你在官方页面操作即可。现在不想注册也没关系，反馈材料会保留下来。
+
+账号密码、验证码和 Token 只由用户在官方页面或宿主安全授权界面处理；不向用户索取，也不读取、输出或写入报告。无法使用 GitHub 时按[用户交互](user-interaction.md#四账号与提交结果)交付本地报告。
+
+## 2. 选择最省事的可用路径
+
+用户选目标，Agent 选工具；不要求小白判断 CLI 和 MCP 的区别。
+
+| 当前目标与条件 | 推荐路径 |
+| --- | --- |
+| 已有工具已授权且能完成当前操作 | 直接复用；Issue 需要查重、创建和读回，PR 还需要核验个人 Fork、准备分支改动及创建和读回 PR |
+| 希望 AI 协助提交反馈/需求，缺少工具且宿主支持终端 | 推荐 GitHub CLI，先用 setup 检测并展示安装计划，再征求同意；不想安装或只提一次 Issue 时可直接使用网页，无需 Git 或源码 |
+| 希望 AI 协助修复并提 PR，宿主支持终端 | 缺少必要工具时，经用户同意后协助配置官方 GitHub CLI；Git、依赖安装及本地测试能力按实际需要单独核实 |
+| 宿主已有方便的 GitHub 连接入口 | 经用户同意连接官方 GitHub MCP/连接器；只在宿主实际支持时推荐，不虚构入口或配置 |
+| 无法安装、连接或使用终端 | 使用可用网页能力；无法编辑或验证时保留草稿、修改成果和未验证说明，不宣称已提交或测试通过 |
+
+MCP 配置在用户当前使用的 AI 工具中，不是新增 OpenYida 命令。已连接不等于具备写权限；只读连接可用于查重，不能冒充可提交。也不把 GitHub MCP 或 gh 当作本地 Git、构建和测试环境的替代品。
+
+## 3. 需要配置时，先说明再执行
+
+结合实际环境，推荐一个具体选项，说明工具名称、官方来源、包管理器默认安装位置及必要依赖、用途和所需授权。复用已安装的包管理器和已有宿主配置；需要额外工具时另行说明并征求同意，不扩大原安装授权。
+
+> 目前还没有可用的 GitHub 提交工具。我建议配置官方 GitHub CLI，方便我协助你准备修改和提交 PR；它会安装到你的电脑，登录授权由你在浏览器中完成。提交前，我仍会先给你看修改和将公开的内容。
+>
+> 选项：“帮我配置并继续”“使用网页方式”“先保留成果，稍后继续”。
+
+这是 CLI 路径的话术；推荐宿主连接器时，改为真实的连接名称、授权范围和配置位置。用户明确同意后才开始安装或修改配置；拒绝或未回答时保留成果，不自动代选、不反复邀请。
+
+- **GitHub CLI 检测与安装**：先运行下方只读命令，按返回的 `tool/account/installation/nextStep` 解释当前状态。缺少 gh 且 `installation.plan.available` 为 true 时，向用户展示具体包管理器、包名、安装影响和协议；用户同意后才运行安装命令。macOS/Linux 复用已有 Homebrew，安装 `homebrew/core/gh`；Windows 复用已有 WinGet 的 `winget` 源，安装精确包 `GitHub.cli`，会接受来源与软件协议，系统权限由用户自己批准。已有 gh 直接复用，不升级。没有支持的包管理器时提供[官方安装说明](https://github.com/cli/cli#installation)或网页路径；命令不安装包管理器、不加软件源、不执行提权或远程脚本。
+- **浏览器授权**：setup 仅提供引导，不自动启动登录。用户同意登录后，Agent 在用户可见的交互终端运行 `gh auth login --hostname github.com --web --skip-ssh-key`，由用户在官方浏览器页面完成。无交互终端则选网页/安全连接器，不在后台挂起登录。不要替用户回答 Git 凭证配置或协议切换问题，不自动修改全局 Git 配置、添加 SSH key 或追加权限；OAuth 权限以实际授权页为准，不能把 `--scopes` 描述为只读/写入权限开关。若安全存储不可用，gh 可能回退为明文保存；提前说明风险，优先选择网页或宿主安全授权，不使用 `--insecure-storage`，也不读取或回传凭证文件。
+- **宿主 MCP/连接器**：读取当前宿主的连接说明及 [GitHub 官方 MCP 文档](https://github.com/github/github-mcp-server)，使用实际提供的连接/授权入口。优先使用宿主支持的浏览器授权，只申请本次操作需要的权限；若只能手填 Token，由用户在安全设置中自行填写，不通过对话传递。修改配置只改已同意的 GitHub 项，保留其他连接；不顺带安装本地服务或覆盖整份配置。
+- **受限环境**：遵守宿主权限和受管 Run 约束；受管环境不能使用个人 GitHub 能力时，交付脱敏草稿并说明到个人本机会话继续。不以换成浏览器/MCP、提权、关闭安全检查或扩大权限来绕过限制。
+
+安装、登录或连接失败时说明实际完成到哪一步，保留材料，提供网页或稍后继续的选择；用户未选择重试时停止配置。配置授权只覆盖说明过的安装/连接，不等于授权 Star、Fork、push、Issue/PR 提交或公开内容。
+
+以下命令由 Agent 执行；`--confirm` 只记录用户已明确同意安装，不代替对话确认：
+
+```bash
+openyida feedback github setup --json
+# 用户看过安装计划并同意后：
+openyida feedback github setup --install --confirm --json
+```
+
+仅 `tool.state=missing` 才可安装；`unverified` 先检查执行权限或环境。账号的 `login_required` 进入登录引导，`unverified` 先检查网络、授权或限流，不要求重装/重复注册。安装超时、失败或结束后仍找不到 gh 时，先用只读 setup、包管理器状态或重新打开终端核实 PATH；不把包管理器退出成功当成工具就绪，也不自动重试。所有 setup 输出仅供本机引导，不直接附到 Issue。
+
+## 4. 验证后接着处理原草稿
+
+1. **只读验证**：CLI 再运行 `openyida feedback github setup --json`；它用固定 github.com 的只读 API 核实当前用户，仅返回验证后的账号名，不输出原始诊断或凭证。必要时检查 `gh auth status --hostname github.com`，不使用 `--show-token` 或 `gh auth token`。MCP/连接器读取当前用户和可用工具，浏览器核对登录账号。账号验证不代表有写权限；所需权限尚未证实时标为待验证，不创建测试 Issue、Star 或 Fork 来试权限。
+2. **复用已有材料**：继续原问题、出错环境、草稿、截图及测试记录，不重新问一遍。仅因安装 gh 或登录成功，不修改 `incidentEnvironment`，也不把新安装信息加入原问题报告。账号、授权输出和工具配置不写入公开材料。
+3. **保留公开确认**：未改动的最终稿沿用原确认；正文、图片、diff 或测试结果有变动时重新展示并确认。安装成功、登录成功和工具就绪，都不代表用户已同意公开提交。
+4. **按原提交流程继续**：回到 [GitHub 提交](github-contribution.md)，核实目标仓库与账号；PR 仍通过已验证的个人 Fork。若中断前提交结果未知，先查询已有 Issue/PR/分支，避免重复创建。结果仍未知就保留待核实状态，不换工具盲目重发。
+5. **如实交付**：分别说明“工具已配置”“登录已验证”“草稿已准备”或“已提交并读回”。只有核实真实 Issue/PR 地址和内容后，才给提交成功结论；Issue 完整读回后的可选 PR 邀请沿用交互规范，不因配置工具重复邀请。
+
+官方参考：[CLI 登录](https://cli.github.com/manual/gh_auth_login)、[登录状态](https://cli.github.com/manual/gh_auth_status)。

package/yida-skills/skills/yida-feedback/references/report-input.md

@@ -5,7 +5,7 @@
 ```json
 {
   "title": "发布失败后错误提示缺少处理建议",
-  "summary": "当前会话两次出现相同错误，无法继续发布。",
+  "summary": "想把页面发布给同事使用，目前卡在发布步骤。",
   "command": "openyida publish（省略业务参数）",
   "steps": ["使用最小示例执行发布", "观察错误提示"],
   "expected": "说明失败原因并给出可执行的下一步",
@@ -39,10 +39,18 @@
 
 - category：`cli|skill|environment|platform|unknown`；status：`confirmed|hypothesis|unknown`。confirmed 必须有 summary 和 evidence，CLI 只检查结构，不替 Agent 证明根因。
 - occurrenceCount：已观察的正整数；未知省略。fingerprint 按脱敏后的 title/command/actual 生成，不等于跨用户统计或已完成查重。
-- 单字段最多 12000 字符；数组最多 40 个字符串；输入最多 1 MiB。未列出的字段被丢弃；字段不能嵌套对象（cause、screenshots、comparison 除外）。CLI 只补包版本、Node、系统类型和架构，不补环境变量、账号、组织、应用或项目路径。
+- 单字段最多 12000 字符；数组最多 40 个字符串；输入最多 1 MiB。未列出的字段被丢弃；字段不能嵌套对象（cause、screenshots、comparison、incidentEnvironment 除外）。CLI 只补报告生成时的包版本、Node、系统类型和架构，不补环境变量、账号、组织、应用或项目路径。
 - 自动过滤常见凭证、绝对路径、URL、应用/表单标识、邮箱、手机号与身份证号，并转义 Markdown。正则不是保密保证；人工复核业务数据、间接身份信息、内部名称和未匹配的凭证。
 - 用文件工具写入 JSON，避免把报错拼成 shell 命令。命令只读这一个显式输入；输出目录父目录须存在，目标目录须不存在，避免覆盖已有材料。
 
+## 问题发生环境与报告生成环境
+
+复用顶层 `tool`（工具名及已知版本）、`model`。新增可选 `incidentEnvironment` 对象只接收字符串白名单：`openyida`、`node`、`platform`、`arch`、`installation`、`browser`、`deployment`、`organizationContext`。前四项为问题发生时的版本、系统和架构；安装方式可写 npm/插件/源码/未知；浏览器与部署形态仅在相关时填写；组织上下文只描述单组织/多组织切换，不含组织 ID 或名称。
+
+例如用户明确说升级前出错，可填 `{"incidentEnvironment":{"openyida":"用户确认的旧版本","installation":"npm"}}`；未知字段省略，不根据报告命令运行环境推断。Agent 将来源和升级差异放进现有 `evidence`，避免新增重复的诊断字段。
+
+输出 `environment` 保持原有结构，始终表示报告生成器的包版本和运行环境；Markdown 单独标为“报告生成环境（不代表问题发生时）”。缺少 `incidentEnvironment` 的旧输入继续可用，出错环境显示未知；不能用生成报告的新版 OpenYida 冒充出错时版本。所有新输入值同样脱敏、转义并参与公开稿的 `reviewDigest`。
+
 ## 截图与测试对比
 
 `screenshots` 最多 5 张，每张至多 10 MiB，仅接受 PNG/JPEG/WebP 文件头。相对路径按摘要 JSON 所在目录解析。CLI 只复制明确选择的原图，输出 `screenshot-01.png` 等通用文件名；不复制原文件名/路径到报告，不上传、不改图、不移除元数据。原图和最终正文必须一并审阅后才公开。无图片时省略，不能用示例或生成图片充当真实截图。

package/yida-skills/skills/yida-feedback/references/user-interaction.md

@@ -4,7 +4,9 @@
 
 ## 一、先解决“我想反馈什么”
 
-复用当前对话，只补关键缺口。用日常语言问“你原本想完成什么，实际卡在哪一步？”，区分：实际故障、功能建议、希望 AI 帮忙修复。实际故障必须写明当前遇到的问题、最短复现、期望/实际、影响和真实排查结果，不能只写一句抽象需求。
+复用当前对话，只补关键缺口。给用户三个容易理解的入口：“遇到问题了”“希望体验更好”“想一起改进”。询问“你原本想完成什么？实际发生了什么？你希望看到什么结果？”；已知答案直接复用，不一次追问整张技术表。Agent 整理最短复现、影响和真实排查结果，缺失项写未知。体验建议用现有 `summary/actual/expected` 表达当前场景、不便和理想结果，不要求用户设计命令或先找到根因。
+
+环境信息按 [报告输入](report-input.md) 填写：只读检查可获得的 OpenYida、Node.js、系统和架构，复用已知的 AI 工具及版本、安装方式；浏览器、设备、公有云/私有化和多组织切换仅在相关时补充。只将确认属于问题发生时的值写入 `incidentEnvironment`。已升级或换机器时分开记录，不用当前版本覆盖历史事实；未知不阻塞反馈，不要求粘贴整份诊断。
 
 说明下一步：“我会先整理问题和截图，再给你确认；确认后才公开提交。”不要先要求注册账号或下载源码来打断排查。
 
@@ -44,7 +46,22 @@
 
 ## 四、账号与提交结果
 
-- 没有 GitHub 账号：材料准备好后，引导用户创建 GitHub 账号，并给官方 [创建账号入口](https://github.com/signup)。用户自行完成注册、登录；Agent 不索取密码或 Token。
+- 材料准备好、用户选择 GitHub 后，按 [账号与工具准备](github-setup.md) 区分没有账号、工具未安装、未登录和权限/网络问题。先复用已有工具；推荐 CLI 时先执行只读 `feedback github setup --json`，说明安装计划并取得同意后才使用 `--install --confirm`。注册、登录由用户在官方页面或宿主安全入口完成，配置完成后继续原草稿。
 - 实在不行，只提示“反馈到AI开发者群”，附本地脱敏报告供用户自行反馈；不再索要群信息、不编造群链接、不替用户发送消息。
 - 用户愿意用 GitHub：Agent 按 [GitHub 提交](github-contribution.md) 查重、处理公开代码和 Fork、提交已确认材料。gh 缺失或不支持附件时，使用宿主可操作的 GitHub 网页引导，不要求用户记技术命令；无法完成时交付可粘贴的正文及已检查截图，不默默省略附件。
 - 成功后给可点击的 Issue/PR 链接，读回核对正文和截图是否完整。附件上传失败或结果未知时先查已创建的帖子，说明实际完成部分，不重复建帖。没有核实的 URL 时，只能说“草稿已准备”。
+
+## 五、Issue 成功后，邀请一起改进
+
+仅在 Issue 创建成功且读回完整后，给一次可选邀请；失败、仅有草稿或附件缺失时先处理提交结果。若读回已有仓库欢迎评论中的 PR 邀请，直接引用它，不再追加第二段邀请。用户已拒绝贡献时跳过，不追问理由。复用同一会话的问题和环境，不重新做一次问卷。
+
+> 问题已提交：[Issue 链接]，感谢你帮我们发现它！
+> 如果你愿意，我们还可以一起尝试修复，并提交一份修改建议（PR）。不需要你会 Git 或写代码，AI 会协助准备修改和检查，你确认后才公开提交。只反馈问题也完全可以。
+
+选项：“让 AI 试着修复”“先看看需要改什么”“只反馈问题”。用户未回答时保持 Issue 已提交状态，不默认开始代码工作。
+
+- 让 AI 试着修复：在公开代码中尝试定位、准备最小改动和验证；找到真实修复后按 PR 流程展示 diff 与最终稿，再确认远端操作。
+- 先看看需要改什么：只读分析，解释预计改动、风险和验证方式；等用户选择继续再编辑。
+- 只反馈问题：交付链接并结束，不再推荐 Star、Fork 或 PR。
+
+有关联 Issue 时在 PR 中引用；只有确实解决问题才写 `Closes #编号`。原因不明、平台内部限制或无法找到公开修复点时，补充 Issue 材料与限制，不制造无关 PR。文档和 Skill 的小改进同样欢迎，验证按改动类型安排；本地检查通过不代表平台、浏览器或真机已验证。

package/yida-skills/skills/yida-flow-node-config/SKILL.md

@@ -24,7 +24,7 @@ description: 配置流程和自动化里的处理步骤，包括审批、办理
 
 | 配置项 | 何时读取 |
 | --- | --- |
-| [人员选择](references/actors.md) | 指定成员、角色、主管，或按金额等条件选人；审批/办理/抄送分别使用对应参数 |
+| [人员选择](references/actors.md) | 指定成员、角色、主管、表单成员字段、发起人自选，或按金额等条件选人；审批/办理/抄送分别使用对应参数 |
 | [字段权限](references/fields.md) | 可编辑、只读、隐藏及子表；发起用顶层 `startFormConfig`，人工节点用 `formConfig` |
 | [操作按钮](references/actions.md) | 审批、办理、旧版多人审批的加签/转交；抄送和自动化不适用 |
 | [条件与变量](references/conditions-variables.md) | 字段与固定值、字段与字段比较；触发条件、分支和取数各用对应格式 |

package/yida-skills/skills/yida-flow-node-config/references/actors.md

@@ -91,6 +91,10 @@
 
 直属主管使用 `type: directLeader`，来源和层级仍用 `source/level`；替补参数使用 `needDeptLeaderReplace`，不要把部门主管的两个替补参数直接套入。
 
+## 表单成员与发起人自选
+
+字段选人、发起时自选及逐级指定下一级经办人，读取 [动态人员来源](dynamic-actors.md)。审批／办理支持两种来源，抄送与旧版多人审批支持成员字段；自选的节点范围、权益与兼容性边界见该文档。
+
 ## 按条件选人
 
 审批、办理、抄送分别使用 `approver/executor/receiver`，共用 `kind: conditional`。先查询真实字段、人员和角色。

package/yida-skills/skills/yida-flow-node-config/references/dynamic-actors.md

@@ -0,0 +1,84 @@
+# 表单成员与发起人自选
+
+## 先区分两个场景
+
+- 发起流程时选择后续审批人／办理人：用 `kind:selfSelect`。
+- 当前办理人指定下一级经办人：用 `kind:formField`，由当前节点填写成员组件，下一节点读取这个成员字段。它不会凭空增加“选择下一处理人”按钮。
+
+先用 `openyida get-schema APP_XXX FORM_XXX --field-map-json` 取得真实字段 ID。保存仍走 `configure-process`；已有流程先读取、保留完整配置，再按用户授权使用 `--replace`。这些人员来源只用于流程人工节点，不直接套进自动化的消息接收人。
+
+## 表单内成员字段
+
+```json
+{
+  "nodes": [
+    {"type":"approval","name":"成员字段审批","approver":{"kind":"formField","fieldId":"<真实成员字段ID>","approvalMode":"all"}},
+    {"type":"operator","name":"指定成员办理","executor":{"kind":"formField","fieldId":"<真实成员字段ID>"}},
+    {"type":"carbon","name":"通知表单成员","receiver":{"kind":"formField","fieldId":"<真实成员字段ID>"}}
+  ]
+}
+```
+
+`fieldId` 是一个顶层 `EmployeeField`，不是姓名、部门字段或子表成员字段。多个成员组件用 `fieldIds:["<真实ID1>","<真实ID2>"]`，不能同时写 `fieldId`。`approvalMode` 为 `all/or/oneByOne`，默认 `all`；旧版 `multiApproval` 也可将此来源放在 `approver`，节点上的 `mode` 控制多人会审方式。
+
+CLI 同时生成运行层 `ext_target_approval_variable` 与设计器的 `formMember`；保存前读取真实表单字段，检查存在性、组件类型和子表归属。不要猜测 `ext_target_approval_field` 等枚举，未知原始人员类型会在远端写入前报错。
+
+### 逐级指定下一级经办人
+
+例如“发起人指定一级经办人，一级经办人指定二级经办人”：准备两个真实成员组件，定义如下。
+
+```json
+{
+  "startFormConfig":{"behaviorList":[
+    {"fieldId":"<一级经办人成员字段ID>","fieldBehavior":"NORMAL"},
+    {"fieldId":"<二级经办人成员字段ID>","fieldBehavior":"HIDDEN"}
+  ]},
+  "nodes":[
+    {"type":"operator","name":"一级办理",
+      "executor":{"kind":"formField","fieldId":"<一级经办人成员字段ID>"},
+      "formConfig":{"behaviorList":[
+        {"fieldId":"<一级经办人成员字段ID>","fieldBehavior":"READONLY"},
+        {"fieldId":"<二级经办人成员字段ID>","fieldBehavior":"NORMAL"}
+      ]}},
+    {"type":"operator","name":"二级办理",
+      "executor":{"kind":"formField","fieldId":"<二级经办人成员字段ID>"},
+      "formConfig":{"behaviorList":[
+        {"fieldId":"<二级经办人成员字段ID>","fieldBehavior":"READONLY"}
+      ]}}
+  ]
+}
+```
+
+在表单设计中按业务需要将成员组件设为隐藏并开启“始终提交”，流程节点权限再将当前需要填写的字段设为可编辑。**“始终提交”是表单组件属性，不是上面 `formConfig` 的属性**；先读取真实组件配置，不能只配节点权限就声称隐藏成员能正确提交。给需要选人的节点增加必填校验，防止未填下一经办人导致无人处理。
+
+验收依次检查：发起时选甲 → 只有甲收到一级任务；甲填写乙并提交 → 只有乙收到二级任务；成员字段为空、多人和退回重提各按业务规则测试。配置回读成功与真实任务投递成功分别报告。
+
+## 发起人自选
+
+审批放 `approver`，办理放 `executor`。默认全组织范围，也可限制为指定成员或指定角色：
+
+```json
+{
+  "nodes":[
+    {"type":"approval","name":"组织内自选","approver":{"kind":"selfSelect","range":{"type":"ALL"}}},
+    {"type":"operator","name":"候选成员自选","executor":{"kind":"selfSelect","range":{"type":"USER","users":[{"id":"<真实userId>","name":"候选人"}]}}},
+    {"type":"approval","name":"角色内自选","approver":{"kind":"selfSelect","approvalMode":"or","range":{"type":"ROLE","roles":[{"id":"<真实角色ID>","roleType":"YIDA"}]}}}
+  ]
+}
+```
+
+`USER/ROLE` 必须提供非空真实 ID 列表；钉钉角色用 `roleType:DINGTALK`。`ALL` 不填写 `users/roles`。这里的“自选”指**发起人**，不能用来承诺每个当前办理人都能在提交时重新指定下一级；逐级选择使用上方成员字段方案。
+
+## 权益和兼容性边界
+
+| 场景 | 已核实的边界 |
+| --- | --- |
+| 审批／办理的表单成员、自选 | 原生设计器列为常规人员来源，不能仅据此保证每个租户和旧应用均可用；以目标环境选项和服务端结果为准 |
+| 发起人自选在旧应用中不可见 | 旧应用及锁定资源的应用可能受前端资源兼容性影响，先核对应用版本与设计器选项，不直接要求购买套餐 |
+| 抄送的发起人自选 | 官方文档列为支持；本次接入依据的设计器实现另有非免费版和功能开关判断，目标环境尚未核验。当前简化 DSL 明确拒绝，不能绕过开关或静默改成发起人本人 |
+| 旧版 `multiApproval` 的自选 | 原生设计器排除此来源，CLI 拒绝；普通审批节点的多人处理方式不等于旧版多人审批节点 |
+| `kind:conditional` 条件选人 | 是独立能力，官方标注“专属—OA 增强包”；不能据此推断普通表单成员选人也需要该权益。本次两种新来源不嵌套进条件人员规则 |
+
+套餐与开关是不同维度。平台提示“不支持”时，保留错误码与目标环境信息，分别确认权限、套餐、开关和应用资源版本，不编造可开通的权益或修改平台开关。
+
+参考：[官方逐级指定人员方案](https://docs.aliwork.com/docs/yida_qalist/_1/_4/uqq8fy5gedskzs4f)、[审批节点与自选范围](https://docs.aliwork.com/docs/yida_support/_2/trbqg6/rq8i94)、[抄送节点](https://docs.aliwork.com/docs/yida_support/_2/trbqg6/cntvp8)。

package/yida-skills/skills/yida-integration/SKILL.md

@@ -22,6 +22,7 @@ description: 配置宜搭自动化的执行时机和处理步骤，修改已有
 
 ## 严格要求 (MUST DO)
 
+- 定时任务按实际结束条件选择 `count`（触发次数）或 `time`（指定时间），spec 分别填写 `schedule.maxCount` 或 `schedule.expireDate`。需要“一直执行”或长期持续运行时，建议选择指定时间，将截止日期设得较远，并在配置摘要中展示实际日期；详见 [触发设置](references/triggers.md#结束条件)。
 - **创建/发布前必须确认**：执行集成自动化创建或发布操作前，必须向用户展示逻辑流配置摘要（触发条件、节点列表、通知对象），获得用户明确同意后再执行。
 - 创建前先确认触发表单的 `formUuid` 和相关字段 ID。
 - 创建成功后记录逻辑流 ID 到 `<projectRoot>/.cache/<项目名>-schema.json`。

package/yida-skills/skills/yida-integration/references/triggers.md

@@ -57,10 +57,23 @@
 }
 ```
 
-时间按平台 Asia/Shanghai（UTC+8）输入，秒必须为 00。`repeat` 支持 ONCE、DAILY、WORKDAY、WEEKLY、BI_WEEKLY、MONTHLY、LAST_DAY_PER_MONTH。非 ONCE 可选 `maxCount` 或毫秒时间戳 `expireDate`，二者互斥。创建绑定类型为 3，运行触发类型为 TimerEvent，设计器保留定时配置。当前不提供日期字段定时、法定工作日和 CUSTOM 的简写。
+时间按平台 Asia/Shanghai（UTC+8）输入，秒必须为 00。`repeat` 支持 ONCE、DAILY、WORKDAY、WEEKLY、BI_WEEKLY、MONTHLY、LAST_DAY_PER_MONTH。非 ONCE 须选择 `maxCount` 或毫秒时间戳 `expireDate`，二者互斥。创建绑定类型为 3，运行触发类型为 TimerEvent，设计器保留定时配置。当前不提供日期字段定时、法定工作日和 CUSTOM 的简写。
 
 定时不能混用 events、changedFields、表单触发过滤或审批节点动作；定时没有当前提交记录，应显式取数后再引用。必须等到真实触发后读取日志和目标数据，才可报告定时运行通过。
 
+### 结束条件
+
+指定时间开始的重复任务，按实际结束条件选择以下两种方式：
+
+| 界面选项 | spec 字段 | 设计器字段 | 运行态字段 |
+| --- | --- | --- | --- |
+| 触发次数 | `schedule.maxCount`，1–100 的整数 | `overTimeType = "count"`、`overCount` | `inputs.end.maxCount` |
+| 指定时间 | `schedule.expireDate`，晚于开始时间的毫秒时间戳 | `overTimeType = "time"`、`overTime` | `inputs.end.expireDate` |
+
+需要“一直执行”或长期持续运行时，建议选择指定时间，将截止日期设得较远，在配置摘要中展示实际截止时间。例如业务选择北京时间 2036-10-20 09:30 截止时，将该日期转换成毫秒时间戳后填写 `schedule.expireDate`。具体截止日期按用户确认的业务安排填写。
+
+结束条件缺失时，CLI 会在认证和远端操作前提示补充 `maxCount` 或 `expireDate`。一次性任务仍使用下方 ONCE 配置，运行态只执行一次，设计器结束方式保留为 `count`、次数为 1。
+
 ### 只执行一次
 
 ```json

package/yida-skills/skills/yida-login/SKILL.md

@@ -123,6 +123,18 @@ openyida auth refresh
 
 如果运行环境没有注入 token，auth snapshot 会返回 `failure_reason=env_token_missing`；停止任务，让 Codex、yida-agent 等宿主补齐 token 注入，不要触发 OAuth。
 
+## 千问云端身份诊断
+
+仅在用户明确要求接入或诊断千问云端身份时，运行：
+
+```bash
+openyida auth qwenwork user-info --json
+```
+
+命令读取 `QWENWORK_AGENT_TOKEN`（兼容 `MULE_AGENT_TOKEN` / `AGENT_TOKEN`），向 `QWENWORK_GATEWAY_URL`（兼容 `MULE_GATEWAY_URL`）兑换用户凭证，再查询同一地址的 `/user/info`。不打印或持久化凭证；返回用户身份与凭证来源等元信息，并校验已注入的预期用户 ID。
+
+这不是宜搭登录成功结果，不会创建或覆盖 OpenYida auth profile，也不能作为资源写操作的登录凭据。千问 `biz_org_id` 不直接等于宜搭 `corpId`。宿主身份与宜搭身份的映射及宜搭登录态兑换由后续服务端接口负责。默认 OAuth 和 env token 登录流程保持不变。
+
 ## 禁止
 
 - 不要硬编码或打印 `access_token`、`refresh_token`、Cookie 或 CSRF。

package/yida-skills/skills/yida-prd/SKILL.md

@@ -32,6 +32,7 @@ PRD 编写、修改与确认均保留 brief 的 `visualSelection`、已选 theme
 - 用户存在 `explicitScope` 时，以该范围规划页面、表单、流程、报表和本轮交付。
 - 真实 `appType`、`formUuid`、`fieldId`、`processCode` 以资源证据为准；实现阶段产生的 ID 写入 `.cache/<项目名>-schema.json`。
 - 每个 display 页面提供 `pageSpecHandoff`，包含场景、区块、数据来源、主操作，以及指向对应 `design.md` 的 `designFile` / `designRefs`。视觉细则由 `yida-design` 维护。
+- 在已有页面任务、区块说明和验收中写清使用环境、操作频率、行动前必需的信息，以及返回页面时需要保留的状态。证据不足时标明假设，仅对会改变业务范围的缺口澄清。PRD 按比较、逐条处理或录入等任务确定信息需求；宽窄布局由设计阶段决定，复用已有字段记录。
 - 导航结构、菜单顺序和默认入口由业务任务确定；导航外观与应用框架、表单、记录详情和自定义页面交给 `yida-design` 统一设计。PRD 保留整体风格摘要与设计引用，完整 token 和消费规则只在 `design.md` 维护。
 
 任务涉及对象识别、证据或外观比较时，核对真实图片/附件字段与对象的关联，将其纳入已有数据来源与字段映射；没有字段时记录缺口，不凭美化新增字段。图文呈现与无图降级交给[任务驱动的视觉设计](../yida-design/references/task-driven-visual-design.md)，不把网络示意图当作真实对象资料。

package/yida-skills/skills-index.json

@@ -1066,14 +1066,16 @@
       "name": "yida-data-management",
       "path": "skills/yida-data-management/SKILL.md",
       "display_name": "宜搭数据管理",
-      "description": "查询、新增、更新宜搭表单、子表、流程和任务数据，按当前审批人查询流程实例或统计条数，精确删除普通表单单条记录。查询包含日期为空、区间端点、业务计数、子表条件和服务端分页。",
+      "description": "查询、新增、更新宜搭表单、子表、流程和任务数据，按当前审批人查询流程实例或统计条数，精确删除普通表单单条记录，查询流程当前任务并执行管理员转交。查询包含日期为空、区间端点、业务计数、子表条件和服务端分页。",
       "category": "yida-skills/form",
       "tags": [
         "数据查询",
         "数据新增",
         "表单实例",
         "流程实例",
-        "数据删除"
+        "数据删除",
+        "流程任务查询",
+        "管理员转交"
       ],
       "aliases": [
         "数据管理",
@@ -1092,6 +1094,10 @@
         "日期区间筛选",
         "表单空值查询",
         "子表条件查询",
+        "查询流程当前任务",
+        "管理员转交",
+        "流程审批转交",
+        "把流程转交给",
         "按当前审批人查询流程",
         "指定审批人的待审批数据条数",
         "查询关联流程详情和审批历史",
@@ -1109,7 +1115,7 @@
         "get-schema",
         "sample"
       ],
-      "done_when": "目标数据查询或写入完成，并用 query/get 抽查真实记录；删除仅在 deleted=true 且 readbackVerified=true 时完成。"
+      "done_when": "目标数据查询或写入完成，并用 query/get 抽查真实记录；删除仅在 deleted=true 且 readbackVerified=true 时完成；转交以 transferred=true 且 readbackVerified=true 为准，ALREADY_ASSIGNED 为已分配且未再次写入。"
     },
     {
       "name": "yida-data-source-connectors",
@@ -1857,7 +1863,10 @@
         "造数",
         "日期为空",
         "日期区间筛选",
-        "表单空值查询"
+        "表单空值查询",
+        "流程任务查询",
+        "管理员转交",
+        "流程审批转交"
       ]
     },
     {