feat(平台): 补齐服务端持久化和AI拆解契约
This commit is contained in:
101
docs/glossary.md
Normal file
101
docs/glossary.md
Normal file
@@ -0,0 +1,101 @@
|
||||
# 术语表
|
||||
|
||||
按字母/拼音首字母排序。同一术语只在系统的一个语境里有定义,避免歧义。
|
||||
|
||||
## A
|
||||
|
||||
### Agent
|
||||
本系统中指 AI 代理 — 自主完成某项分析/拆解工作的 LLM 调用单元,输出**草案**而非最终数据。所有 Agent 定义见 `agent-spec.md`。
|
||||
|
||||
### AI 草案 (AI Draft)
|
||||
由 Agent 生成、未经用户确认的实体,带 `aiDraft: true` 标记。视觉上在列表里有紫色左边线和「AI 草案」徽章。用户编辑保存后标记自动清除。
|
||||
|
||||
### Assignee
|
||||
任务负责人。在 DevTask / TestCase / Bug 中表示当前承接此任务/用例/缺陷的人员名(不是用户 ID,是 `member.name`)。
|
||||
|
||||
## B
|
||||
|
||||
### Bug
|
||||
缺陷实体。直接挂在版本上(`versionId` 必填),可追溯到 TestCase(`testCaseId` 可选)。状态机:`open → fixing → fixed → verifying → closed/rejected`。
|
||||
|
||||
## C
|
||||
|
||||
### CapsuleStages
|
||||
版本详情页的胶囊式阶段进度条组件。展示调研 → 产品方案 → UI → 开发 → 测试 → 已发布的阶段流转。
|
||||
|
||||
## D
|
||||
|
||||
### DevTask
|
||||
开发任务实体。状态机:`todo → in_progress → testing → submitted`。`submitted` 是终态(开发交付完成)。
|
||||
|
||||
### Drawer
|
||||
侧边抽屉式弹层。系统中所有详情都用 Drawer 呈现,统一 `shadow-2xl`,可在内部完成状态流转。
|
||||
|
||||
## E
|
||||
|
||||
### 引擎(Engine)
|
||||
跨模块的纯函数派生层,避免 store 互相调用。
|
||||
- `linkage-engine.ts`:从 DevTask 状态派生需求"实际进度"
|
||||
- `workspace-engine.ts`:聚合所有 store 数据为统一 WorkItem
|
||||
|
||||
## P
|
||||
|
||||
### Plan / VersionPlan
|
||||
版本下的计划任务(调研 / 产品方案 / UI 设计三类)。状态机:`pending → in_progress → completed`。完成时提交「成果」(链接或文件 + 标题)。
|
||||
|
||||
### Priority
|
||||
优先级标识:P0 / P1 / P2 / P3 / P4。P0 最高,P4 最低。
|
||||
|
||||
### Product
|
||||
产品 — 顶层组织容器。一个产品包含多个项目和需求池。
|
||||
|
||||
### Project
|
||||
项目 — 产品下的子单位。一个项目包含多个版本。
|
||||
|
||||
### Prototype
|
||||
原型 — 产品方案产物,通常是 Axure 导出的 HTML 集合。系统中只保存 URL,不缓存内容。
|
||||
|
||||
### Prototype Note
|
||||
原型批注。Axure 等工具中以 `QY0007` 等编号形式标注的业务规则说明。Agent 拆解任务时的核心输入之一。
|
||||
|
||||
## Q
|
||||
|
||||
### Quality Loop(质量闭环)
|
||||
TestCase + Bug 共同构成的质量验收环路。版本是否能发布的判断维度。
|
||||
|
||||
## R
|
||||
|
||||
### Reference(引用)
|
||||
任务/用例的来源标记,类型为 `requirement` / `prototype_note` / `external`。所有任务/用例必须至少有 1 条引用(人工或 AI 生成都需要)。
|
||||
|
||||
### Requirement
|
||||
需求实体。语义层(解释为什么做),不驱动流程。状态机:`pending_review → adopted → planned → developing → testing → released → closed`(rejected 可回 pending_review)。
|
||||
|
||||
## S
|
||||
|
||||
### Sprint
|
||||
迭代 — 项目内的时间盒(1-4 周)。当前 V1 暂未启用 Sprint 实体,使用 Version 替代。
|
||||
|
||||
### Stage(阶段)
|
||||
版本执行流程的语义段:调研 / 产品方案 / UI 设计 / 开发 / 测试 / 已发布。每个 Stage 可派生进度。
|
||||
|
||||
### 超管
|
||||
拥有 `role.permissions` 含 `'*'` 的用户。可见所有版本(绕过 `version.members` 过滤),可执行所有操作。
|
||||
|
||||
## T
|
||||
|
||||
### TestCase
|
||||
测试用例。主归属版本(`versionId` 必填),需求是可选标签(`requirementId` 可选)。
|
||||
|
||||
## V
|
||||
|
||||
### Version
|
||||
版本 — 项目下的发布单位。**所有任务都归属版本**,是状态流转的执行主线。
|
||||
|
||||
### VersionWithContext
|
||||
派生类型 — 在 Version 基础上扩展 productId/productName/projectId/projectName 等上下文字段,用于跨页面展示。
|
||||
|
||||
## W
|
||||
|
||||
### WorkItem
|
||||
工作台聚合实体。把 DevTask / TestCase / Bug / Plan 等不同实体统一为同一形状,给"与我相关"页面用。
|
||||
Reference in New Issue
Block a user