feat: add frontend development guidelines and structure documentation
- Introduced API guidelines for interface contracts and request handling. - Added design tokens usage guidelines for consistent styling across the project. - Established DTO guidelines for defining request parameters and response data types. - Created frontend structure guidelines to clarify directory organization and code placement rules. - Compiled a comprehensive frontend development guideline document covering various aspects of the development process. - Implemented quality guidelines to ensure code maintainability and adherence to best practices.
This commit is contained in:
+37
@@ -0,0 +1,37 @@
|
||||
---
|
||||
id: RA-20260629-001
|
||||
case_id: REQ-20260629-001-example
|
||||
type: requirement-analysis
|
||||
stage: user-requirement
|
||||
owner_role: PM
|
||||
status: draft
|
||||
source_ids:
|
||||
- UR-20260629-001
|
||||
derived_ids:
|
||||
- OR-20260629-001
|
||||
created: 2026-06-29
|
||||
updated: 2026-06-29
|
||||
---
|
||||
|
||||
# 需求分析:AI 研发工作流研究区
|
||||
|
||||
## 问题拆解
|
||||
|
||||
- 需求链路容易断裂,需要统一 artifact 模型。
|
||||
- skill 容易散落,需要独立源目录。
|
||||
- 真实需求和规范资产容易混淆,需要分层目录。
|
||||
|
||||
## 约束
|
||||
|
||||
- 当前阶段以 vault 内 Markdown 为主。
|
||||
- 不要求一次完成所有 skill。
|
||||
- 需要支持后续反复调优。
|
||||
|
||||
## 风险
|
||||
|
||||
- 过早细化字段会导致维护成本高。
|
||||
- skill 如果直接做成正式安装版,迭代成本会变高。
|
||||
|
||||
## 决策点
|
||||
|
||||
- 先用本目录维护 skill 草稿,稳定后再安装到 Codex skill 目录。
|
||||
+33
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: SA-20260629-001
|
||||
case_id: REQ-20260629-001-example
|
||||
type: scenario-analysis
|
||||
stage: user-requirement
|
||||
owner_role: PM
|
||||
status: draft
|
||||
source_ids:
|
||||
- UR-20260629-001
|
||||
- RA-20260629-001
|
||||
derived_ids:
|
||||
- OR-20260629-001
|
||||
created: 2026-06-29
|
||||
updated: 2026-06-29
|
||||
---
|
||||
|
||||
# 场景分析:AI 研发工作流研究区
|
||||
|
||||
## 主场景
|
||||
|
||||
用户提出一个新需求后,在 `50-cases/` 下创建 case,并按阶段生成 UR、RA、SA、OR、DR、DS、TASK、TP、TC。
|
||||
|
||||
## 替代场景
|
||||
|
||||
用户只想打磨某一个 skill,则在 `20-skills/` 中修改草稿,并用 `60-evaluations/` 中的评测样本验证。
|
||||
|
||||
## 异常场景
|
||||
|
||||
如果某个下游产物找不到上游来源,则需要在追踪矩阵中标记为 `missing` 或补齐 `source_ids`。
|
||||
|
||||
## 边界场景
|
||||
|
||||
如果只是零散想法,还不进入正式 case,可以先放入现有 `AI Coding/inbox/`,成熟后再转入本工作区。
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
---
|
||||
id: UR-20260629-001
|
||||
case_id: REQ-20260629-001-example
|
||||
type: user-requirement
|
||||
stage: user-requirement
|
||||
owner_role: PM
|
||||
status: draft
|
||||
source_ids:
|
||||
- INTAKE-20260629-001
|
||||
derived_ids:
|
||||
- RA-20260629-001
|
||||
- SA-20260629-001
|
||||
created: 2026-06-29
|
||||
updated: 2026-06-29
|
||||
---
|
||||
|
||||
# 用户需求:建立 AI 研发工作流研究区
|
||||
|
||||
## 一句话需求
|
||||
|
||||
作为 AI 研发工作流研究者,我希望建立一套可长期迭代的目录、规范、模板和 skill 草稿,以便逐步沉淀从需求到测试的完整链路。
|
||||
|
||||
## 用户目标
|
||||
|
||||
- 能按阶段组织需求产物。
|
||||
- 能追踪每个需求从输入到最终测试的链路。
|
||||
- 能逐步调优 PM、SE、RD、测试侧 skill。
|
||||
|
||||
## 业务价值
|
||||
|
||||
降低 AI 参与研发时的上下文断裂,提高需求、设计、编码、测试之间的一致性。
|
||||
|
||||
## 范围
|
||||
|
||||
### 包含
|
||||
|
||||
- 目录结构。
|
||||
- 初始规范。
|
||||
- 初始模板。
|
||||
- 初始 skill 草稿。
|
||||
- 示例 case。
|
||||
|
||||
### 不包含
|
||||
|
||||
- 一次性完成所有正式 skill。
|
||||
- 直接接入外部项目管理系统。
|
||||
|
||||
## 验收方向
|
||||
|
||||
能在 vault 中看到完整骨架,并能基于示例 case 继续完善下一阶段产物。
|
||||
Reference in New Issue
Block a user