openyida 2026.9.21 → 2026.9.22-beta.2

package/yida-skills/skills/yida-requirement-analysis/references/experience-groups.md

@@ -1,79 +0,0 @@
-# 判断是否分前后台
-
-收到有效功能选择后，需要新增或修正入口判断时读取。这里的前台和后台都是用户使用系统的页面（访问态）；开发者修改字段、流程和应用配置的 `/admin` 另行交付。
-
-## 判断依据
-
-- **只有访问后台**：本次只给工作人员提供录入、受理、处理或维护业务的页面。办事人通过电话、外部平台或已有入口发起业务，或者本次不需要办事入口。
-- **只有访问前台**：本次只提供办理、查询或展示页面。纯展示、查询可能无需人工处理；提交后需要处理的业务，要明确由已有系统、已有人员入口或自动流程承接。
-- **不分前后台**：大家使用同一套业务页面，按职责看到不同菜单、数据和操作。适合围绕同一批项目、客户或记录开展工作的情况。
-- **分前后台**：办事的人和处理业务的人分别进入适合自己的页面。前台用户能直接办理、查看结果；后台人员处理收到的业务。两边的主要任务、查看内容或操作步骤有明显差异时，建议分开。
-
-不同角色可以使用同一套页面，分别配置权限；同一个人也可以同时使用前台和后台。根据实际任务判断是否分开，系统名称和角色数量只作为背景信息。
-
-“只有访问后台”和“不分前后台”都可以用一套页面加权限实现。前者强调工作人员受理、运营或处理业务，后者强调大家围绕项目、任务等共同工作。需求没有明显的受理或运营关系时，使用“不分前后台”的说法。前后台的划分也不代表公开访问、匿名访问或应用管理权限。
-
-| 已确认的实际用法 | 建议 | 谁使用、看到什么、能做什么 |
-| --- | --- | --- |
-| 项目成员处理任务，负责人分配任务、查看进度 | 不分前后台 | 使用项目和任务页面，按职责显示数据与操作 |
-| 销售维护自己的客户，主管查看团队客户 | 不分前后台 | 使用客户列表和详情，按权限区分数据范围 |
-| 客户自己预约，员工安排和处理预约 | 分前后台 | 客户看可预约服务和自己的预约；员工看待处理预约和排期 |
-| 员工报修、查进度，维修人员接单、处理 | 分前后台 | 员工看“我要报修、我的报修”；维修人员看“待处理工单、我的工单” |
-| 只有维修人员登记、处理和统计外部渠道收到的工单 | 只有访问后台 | 直接使用工单列表、处理页面和所需统计 |
-| 员工登记电话预约，或处理外部商城同步的订单 | 只有访问后台 | 员工登记、排期，或审核订单、发货 |
-| 本次提供活动报名，工作人员在已有入口处理 | 只有访问前台 | 报名人填写、提交信息，处理沿用已有入口 |
-| 本次只展示产品或查询已有进度 | 只有访问前台 | 用户浏览或查询，数据来源按实际需求接入 |
-| 团队成员预订会议室，负责人维护可用资源 | 不分前后台 | 共用会议室和预订页面，按职责显示操作 |
-
-## 判断顺序
-
-1. 列出本次实际使用者和任务，明确哪些办理或处理功能已在其他渠道完成。
-2. 本次只提供业务受理、运营或维护页面，办理发生在别处或不在本次范围内时，选择“只有访问后台”。仅凭“内部员工使用”不足以判断为后台。
-3. 本次只有办理、查询或展示任务时，选择“只有访问前台”。需要处理的提交，须在已有 `entryRecommendation.reason` 和业务流程中说明由谁承接；尚未明确时记入 `openQuestions`，补问实际处理方式，不擅自扩建后台，也不声称业务已完整。
-4. 办理和处理都在本次范围内时，比较双方所需页面：任务和内容明显不同，选择“分前后台”；共用业务页面即可完成工作，选择“不分前后台”。
-5. 没有明确的办事与受理关系，大家共同维护项目、客户或任务时，选择“不分前后台”，按职责配置菜单、数据和操作。
-
-用户明确只交付某一端时沿用范围，说明它与已有业务的关系。四种说法描述本次交付范围，不要求每个应用都搭建两端。
-
-## 向用户怎么说
-
-直接说明是否分前后台，再列出谁使用、看到什么、能做什么。例如：
-
-- “这个项目管理系统不分前后台，成员处理任务，负责人分配任务、查看团队进度，菜单和数据按权限显示。”
-- “这个预约系统分为客户预约前台和员工处理后台，两边共享预约数据。”
-- “这个系统只有员工使用的业务后台，员工登记电话预约并安排时间。”
-- “本次只做活动报名前台，报名人填写并提交信息，工作人员在已有报名管理页面处理。”
-
-用法不明确且会影响页面规划时，补问具体用法，例如“这个预约系统是让客户自己预约、员工处理，还是只供员工内部登记预约？”已有答案直接复用，用户委托决定时说明建议依据。
-
-## 首页按任务选择
-
-业务后台或不分前后台的系统，先满足实际使用者的高频任务，不因“管理系统”“后台”“暗黑风格”推导出驾驶舱。Fast 与 Plan 使用同一判断：
-
-前台也要确定默认页面和菜单顺序：展示、发现、办理或进度查询，按实际首要任务选择。前后台分别记录“进入后先到哪一页、先看到什么、接下来去哪里”，具体交接见 [每个入口都确定首页与菜单顺序](../../yida-app/references/entry-navigation.md#每个入口都确定首页与菜单顺序)。
-
-| 主要任务 | 入口建议 | 首屏重点 |
-| --- | --- | --- |
-| 处理多个相关业务任务 | 业务工作台，可采用门户式组织；自定义页 scene 为 `workbench` | 待办、操作队列、业务列表与常用入口，按角色和处理优先级排列 |
-| 主要维护一类记录或办理单项任务 | 直接打开原生管理列表、表单或流程入口 | 找到记录并完成当前操作，无需额外创建首页 |
-| 已确认的经营分析、指标判断、趋势比较 | 分析页，scene 为 `dashboard`；明确需要投屏监控时为 `screen` | 指标口径、趋势与分析结论；只有分析确为该角色的首要任务时才设为默认首页 |
-
-工作台的“门户式”指将办事入口与当前工作集中组织，不要求再建一套导航，也不固定模块数量。只选择需求中有依据的内容：待处理事项说明对象、状态、优先级及办理入口；操作队列支持需求所需的筛选与处理；常用入口连接真实业务页面。公告、日程、最近访问等仅在有用途时加入。没有汇总价值就直接进入业务列表。
-
-待办数量、逾期数量可作为任务入口的辅助摘要，能跳到对应处理列表；出现这些数字或一张辅助图表，不把整页改为驾驶舱。按业务命名，例如“采购工作台”“待处理订单”，不把所有首页命名为“XX 驾驶舱”。待办来源、处理权限和完成后的状态更新都要有真实依据，不编造任务或接入能力。
-
-在现有 `userTasks`、`entryRecommendation.reason`、页面 `purpose` 中写清“谁进入后先做什么、为什么选择该入口”。分析需求须能追溯到有效功能或用户任务；只有系统名称、管理者身份或视觉偏好时，不自动新增经营分析。方案说明首要任务和办理路径，不让用户回答技术场景枚举。
-
-验收时按角色从首页走完一条真实任务路径，并确认处理后的队列或状态更新。`/workbench` 只是平台入口路径，不证明已经实现业务工作台；改标题也不能代替操作能力。
-
-## 与导航和资源分开
-
-分前后台时，默认在同一个应用内提供两套入口，共用业务数据。是否分前后台与是否创建两个应用分别判断；访问范围与权限按用户要求单独配置。
-
-入口建议确定后，下游 AI 按 [导航决策](../../yida-design/references/navigation-decision.md) 选择各入口的页面承载和菜单。
-
-业务后台处理订单、工单等已选业务；`/admin` 用于应用开发管理。
-
-## 交接要求
-
-在 brief 中用 `userTasks` 关联使用者与有效功能，用 `entryRecommendation` 记录入口建议和依据。用法证据不足时保留待定并补问关键用法；用户委托时记录依据并标记 AI 推导。完成后直接交给下游规划。

package/yida-skills/skills/yida-requirement-analysis/references/handoff.md

@@ -1,68 +0,0 @@
-# requirement-brief 交接契约
-
-保存或更新 brief 时读取。写入 `.cache/openyida/<项目名>/requirement-brief.json`，供 PRD 与视觉设计共用。
-
-## 兼容现有字段
-
-保留 `schemaVersion: 1`、根级 `projectName` 和已有字段形态，按已有事实补充新关系字段。
-
-| 字段 | 内容与阶段 |
-| --- | --- |
-| `appName` / `industry` | 应用名称候选、业务领域；真实应用标识写入 `resourceContext.app.appType`，不把业务类型当真实 ID |
-| `targetUsers` / `businessGoals` | 使用者和目标，保持字符串数组；单个目标也写数组 |
-| `coreFunctions` / `businessObjects` | 当前有效功能与对象，保持数组及原有细项；新建功能项可用 `{key,name,purpose}`，不强制改写旧字符串项 |
-| `pageScenes` | 用户明确要求的页面及下游规划补齐的场景，使用 `{key,name,kind,purpose}`；kind 为 `custom-page/form/process-form/report`。首轮未知时为 `[]`，不把功能选择等同于页面选择 |
-| `intake` | `firstBuild`、`sourceDetail: detailed/brief`、`designMode: fast/plan/null`、`confirmed`；confirmed 仅表示关键前置澄清完成 |
-| `visualSelection` | 首轮保留 `visualDirection` 与已有主题/颜色要求；下游补齐主题映射。Plan 初始化前必须含非空 `themeId` |
-| `navigation` | 应用工作区导航；首轮保留用户要求或既有决策，未知时 type 为 null；规划字段见下方“前后台导航交接” |
-| `resourceContext` | 有证据的 app/page/form/process 复用上下文，不编造 ID；后续创建出的 ID 写入执行上下文或 schema |
-| `explicitScope` | 用户明确页面、表单、流程、报表、导航与交付；窄范围含 `allowInferredResources:false`，无明确资源边界时为 null |
-| `brandHints` / `colorHints` | 品牌、参考页面、主题、偏好色及避用色 |
-| `constraints` | 组织、设备、权限、交付限制；`prohibitedActions` 同时保留禁止原文和规范化动作 `theme-file/page-source/publish` |
-| `assumptions` / `openQuestions` | 分别记录可调整的建议，以及影响业务范围或实际用法的关键待答问题 |
-| `userTasks` | `{key,user,functionRefs,source,reason}` 数组；functionRefs 引用有效功能的稳定 key，旧字符串项引用原文，不重复复制功能内容 |
-| `entryRecommendation` | `{mode,source,reason,entries}`；mode 为 `unified`（不分前后台）、`service-management`（分前后台）、`frontend-only`（只有访问前台）、`backend-only`（只有访问后台）、`undetermined`（实际用法待明确），每项 `{key,name,taskRefs}` 引用 userTasks；可补 `role: service/management/workspace`、`sceneKey` 和 `presentationHint`。backend-only 的入口 role 使用 management；新建不分前后台的入口通常使用 workspace。旧 unified 记录保留原值和角色，不自动改分类 |
-| `evidence` | 必要时用 `{path,source,reason}` 数组为旧字段保留简短来源；path 使用 JSON Pointer 指向当前有效值，数组变化后同步更新 |
-
-来源统一区分 `user_explicit`（用户直接说明）、`user_selected`（可见选项的回答）、`ai_inferred`（有业务依据的推导）、`ai_default`（技能默认建议）。导航沿用既有兼容规则：AI 决策写 `ai_default` 并在 reason 说明依据，用户明确指定归属才写 `user_selected`。用户委托的具体方案仍是 AI 推导，reason 保留委托依据。
-
-## 保留式更新
-
-- 按首轮分析得到的有效范围更新变化字段，保留其余已确认内容，同步移除失效角色、关系、入口及来源引用。
-- `intake.designMode` 保留用户最后一次明确选择；用户改选时更新，尚未确定时为 null。具体路由按 [模式规则](../../yida-design/references/design-mode.md) 执行。
-- 短需求保存简短事实及关系；已有字段、流程与页面细项完整保留。
-- 用户禁止事项作为执行约束；与要求的结果直接冲突时说明并澄清。
-- 明确只完成一个表单并交付链接时，`explicitScope.pages=[]`，仅保留对应 forms/delivery，Plan 按此资源范围执行。
-- 中断恢复可保存 `confirmed=false` 草稿；收到关键问题的实际回答或明确委托后，按完成条件更新状态。
-
-## 规划阶段补齐
-
-由 `yida-app` 按 [规划准备](../../yida-app/workflow/step-2-design.md#规划准备) 补齐页面场景、导航和主题，AI 新增内容记录来源并遵守 explicitScope。
-
-Plan 在 `design-plan init` 前必须补齐合法的导航结构（见下节）及 `visualSelection.themeId`。视觉沿用 `visualSelection` 的 `themeId/visualDirection/colorStrategy/navigationStyle.structure`，AI 补齐颜色或主题时标记 `ai_default`。`navigationStyle.tone` 不在 brief 中推导，由 CLI 从所选主题模板的 `navTheme` 派生；Fast 共用同一规则。主题 ID 尚未确定时，通过 `openyida design-plan catalog --json` 查询合法主题及页面模式，复用本轮查询结果。
-
-补齐主题和颜色前，按[设计方向比较](../../yida-design/references/theme-selection.md#设计方向比较)生成共用的三套方向；Fast 内部选择，Plan 在没有明确完整风格时通过 `ask_human` 选择。保留用户明确的风格，AI 建议记录具体业务依据。
-
-`visualSelection.colorStrategy` 使用对象：`primaryColor` 填本项目选定的 6 位 HEX 色值，`primaryColorName` 填对应色名，`usage` 写配色依据及背景、主操作和强调色的关系。只有文字配色要求时也可先保存字符串；CLI 将原文放入 `usage`，并提示补齐 `primaryColor`。
-
-只有访问前台且提交后需要处理时，在 `entryRecommendation.reason` 和业务流程中记录承接方式，未明确的内容保留在 `openQuestions`；无需新增字段。PRD 将 userTasks 与入口建议转为页面的访问路径、任务和权限；Plan 的 business.json 使用现有 facts 契约，视觉设计共用入口和导航记录。
-
-## 前后台导航交接
-
-入口通过 sceneKey 关联页面，同一场景的多个业务视图共用一个页面资源。需求阶段保存建议，规划准备填写：
-
-- 根级 `navigation`：应用工作区导航，包含 `type/source/reason`；type 为 `platform-l-shape/platform-top/platform-side/custom`，custom 另含 `variant: side/top/mixed/dock`。
-- `pageScenes[].pageSpecHandoff.entryMode`：平台工作区为 `platform-shell`，独立入口为 `standalone`。
-- 独立入口的 `pageScenes[].pageSpecHandoff.navigation` 仅含菜单字段：`{type:"custom",variant:"top",reason:"员工只需报修与查询"}`，variant 支持 top/side/mixed/dock；无菜单时为 `{type:"none",reason:"单步办理"}`；省略时沿用既有页面契约。
-
-管理端采用自定义页面也默认使用 `platform-shell`；其 menu 描述平台任务，不直接渲染为页面导航。只读交接中的 `navigationPolicy` 由 CLI 派生，不写回 brief 或 pageSpecHandoff。导航按[方案讨论与确认](../../yida-design/references/navigation-decision.md#方案讨论与确认)随业务方案说明。
-
-例如：报修前台为 standalone + custom，维修后台为根级 platform-side。Plan 初始化保留 pageSpecHandoff，PRD、design 和计划分别展示各入口方案。导航执行和验证按 [导航壳配置](../../yida-nav-shell/SKILL.md#必做配置) 完成；页面访问范围和数据权限按用户要求独立配置。
-
-规划阶段按 [访问态入口契约](../../yida-app/references/entry-navigation.md) 补齐 entryRecommendation.entries 的 role、menu、defaultMenuKey 和权限依赖。Plan 初始化保留建议并要求业务片段补齐；Fast PRD 使用同一结构。
-
-## 保存校验
-
-检查 JSON 与集合类型、稳定 key、功能/任务引用、来源标记及用户约束。`intake.confirmed` 按 [需求完成条件](../workflow/prepare-brief.md#3-依据有效功能推导入口) 设置；计划批准由计划版本状态记录。
-
-需求未变化时直接复用，后续仅更新实际变化涉及的字段。