refactor: 切换 OpenSpec workflow 从 spec-driven 到 fast-drive
- 新增 fast-drive 自定义 schema 及模板（design.md、tasks.md） - 更新 config.yaml schema 为 fast-drive，调整 rules - 重构 proposal-review 和 apply-review 提示词适配 fast-drive - 删除 spec-review 提示词（fast-drive 不需要 spec 审查） - 删除 openspec/specs/ 下的稳定规范文件 - 更新 README 和 DEVELOPMENT.md 相关描述
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
schema: spec-driven
|
||||
schema: fast-drive
|
||||
|
||||
context: |
|
||||
- 使用中文（注释、文档、交流），面向中文开发者
|
||||
@@ -20,8 +20,8 @@ context: |
|
||||
- 本项目为 Bun 全栈应用模板，README.md记录模板使用方法，DEVELOPMENT.md记录模板使用的技术细节
|
||||
|
||||
rules:
|
||||
proposal:
|
||||
- 仔细审查每一个过往spec判断是否存在Modified Capabilities
|
||||
explore:
|
||||
- 本项目openspec使用fast-drive自定义schema，变更文档只包含design.md和tasks.md，无proposal.md和specs
|
||||
design:
|
||||
- 先前的讨论技术方案要尽可能体现在设计文档中，便于指导实现阶段不偏离已定的技术路线
|
||||
tasks:
|
||||
|
||||
181
openspec/schemas/fast-drive/schema.yaml
Normal file
181
openspec/schemas/fast-drive/schema.yaml
Normal file
@@ -0,0 +1,181 @@
|
||||
name: fast-drive
|
||||
version: 1
|
||||
description: Fast OpenSpec workflow - design -> tasks -> apply
|
||||
artifacts:
|
||||
- id: design
|
||||
generates: design.md
|
||||
description: Self-contained solution brief and execution plan
|
||||
template: design.md
|
||||
instruction: |
|
||||
Create design.md as the self-contained source of truth for what will
|
||||
change, why it is changing, and how the work will be executed.
|
||||
|
||||
This workflow does not use proposal or specs artifacts. design.md MUST
|
||||
preserve the important outcomes from prior exploration and user
|
||||
discussion so a later apply phase can proceed correctly even after
|
||||
context compression or in a new session.
|
||||
|
||||
Write for someone who cannot see the earlier conversation. Keep simple
|
||||
changes concise, but include enough detail to make execution
|
||||
unambiguous. Add more detail when any apply:
|
||||
|
||||
- Cross-cutting change across multiple systems, teams, workstreams, or
|
||||
artifacts
|
||||
|
||||
- New dependency, integration, vendor, tool, policy, or external input
|
||||
|
||||
- Significant information model, process model, data model, or ownership
|
||||
changes
|
||||
|
||||
- Security, privacy, compliance, performance, operational, or migration
|
||||
complexity
|
||||
|
||||
- Ambiguity that benefits from decisions before execution
|
||||
|
||||
- Prior discussion settled non-obvious requirements, constraints, or
|
||||
rejected alternatives
|
||||
|
||||
Required sections:
|
||||
|
||||
- **Context**: Problem, current state, relevant references, and the user
|
||||
request that triggered this change
|
||||
|
||||
- **Discussion Notes**: Key points from exploration or prior discussion
|
||||
that must not be lost. Include agreed conclusions, user preferences,
|
||||
constraints, and important rejected ideas.
|
||||
|
||||
- **Requirements**: Expected outcomes, behavior/process/interface/content
|
||||
changes, continuity expectations, and acceptance criteria.
|
||||
|
||||
- **Goals / Non-Goals**: What this change will achieve and what is
|
||||
explicitly out of scope.
|
||||
|
||||
- **Execution Guardrails**: Must-follow constraints, forbidden approaches,
|
||||
preserved behavior/processes, dependency limits, and project- or
|
||||
workflow-specific boundaries.
|
||||
|
||||
- **Affected Areas**: Concrete artifacts, references, stakeholders,
|
||||
systems, workstreams, documents, configurations, assets, or handoffs that
|
||||
are relevant to the change.
|
||||
|
||||
- **Decisions**: Key choices with rationale (why X over Y?). For each
|
||||
important decision, include alternatives considered and why they were not
|
||||
chosen.
|
||||
|
||||
- **Execution Plan**: Main workstreams or artifacts to change, integration
|
||||
or handoff points, sequencing, and any rollout notes.
|
||||
|
||||
- **Verification Plan**: Validation checks, reviews, approvals,
|
||||
acceptance checks, documentation checks, communication checks, and manual
|
||||
checks needed to prove the change is complete.
|
||||
|
||||
- **Risks / Trade-offs**: Known limitations and things that could go
|
||||
wrong.
|
||||
Format: [Risk] -> Mitigation
|
||||
|
||||
- **Open Questions**: Outstanding decisions, assumptions, or unknowns to
|
||||
resolve before execution. Separate blocking questions that must pause
|
||||
apply from non-blocking follow-ups. Use "None" if there are no open
|
||||
questions.
|
||||
|
||||
Optional sections when relevant:
|
||||
|
||||
- **Migration / Rollout Plan**: Rollout steps, communication, ownership,
|
||||
rollback, or continuity strategy.
|
||||
|
||||
Focus on preserving requirements, rationale, constraints, and approach.
|
||||
Avoid line-by-line or step-by-step details unless a detail is a deliberate
|
||||
decision from the discussion.
|
||||
|
||||
Prefer durable summaries over chat transcripts. Use concrete artifact
|
||||
names, data/information shapes, examples, stakeholders, ownership, and
|
||||
edge cases when they affect execution.
|
||||
|
||||
Do not use task checkboxes in design.md; checkboxes belong only in
|
||||
tasks.md.
|
||||
|
||||
Final design.md must not contain unresolved template comments, empty
|
||||
table rows, or placeholder text.
|
||||
|
||||
If information is missing, state assumptions and open questions instead
|
||||
of inventing hidden requirements. Do not rely on unstated chat context.
|
||||
requires: []
|
||||
- id: tasks
|
||||
generates: tasks.md
|
||||
description: Trackable execution checklist derived from design.md
|
||||
template: tasks.md
|
||||
instruction: |
|
||||
Create tasks.md by breaking design.md into executable work.
|
||||
|
||||
**IMPORTANT: Follow the template below exactly.** The apply phase parses
|
||||
checkbox format to track progress. Tasks not using `- [ ]` will not be
|
||||
tracked.
|
||||
|
||||
Guidelines:
|
||||
|
||||
- Derive tasks from design.md. Do not depend on proposal.md or specs
|
||||
artifacts; any relevant prior discussion must already be captured in
|
||||
design.md.
|
||||
|
||||
- Group related tasks under `##` numbered headings
|
||||
|
||||
- Each task MUST be a single-line checkbox: `- [ ] X.Y Task description`
|
||||
|
||||
- Tasks should be small enough to complete in one session
|
||||
|
||||
- Order tasks by dependency (what must be done first?)
|
||||
|
||||
- Start with context review tasks when execution depends on guardrails,
|
||||
affected areas, or open questions
|
||||
|
||||
- Include validation tasks for checks, reviews, approvals, acceptance,
|
||||
documentation, communication, and manual checks when required
|
||||
|
||||
- Do not include repository, version-control, or release operation tasks
|
||||
unless they are explicitly part of the change scope
|
||||
|
||||
- Final tasks.md must not contain unresolved template comments, empty
|
||||
table rows, or placeholder task text
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
## 1. Context Review
|
||||
|
||||
- [ ] 1.1 Read design.md and identify scope, requirements, decisions, guardrails, and open questions
|
||||
- [ ] 1.2 Review relevant artifacts and references listed in Affected Areas
|
||||
|
||||
## 2. Execution
|
||||
|
||||
- [ ] 2.1 Execute first concrete work item from design.md
|
||||
- [ ] 2.2 Execute next concrete work item from design.md
|
||||
|
||||
## 3. Validation
|
||||
|
||||
- [ ] 3.1 Run required validation from Verification Plan
|
||||
- [ ] 3.2 Perform quality checks required by the project or workflow
|
||||
- [ ] 3.3 Perform required manual review or acceptance checks from Verification Plan
|
||||
|
||||
## 4. Documentation / Communication
|
||||
|
||||
- [ ] 4.1 Update relevant documentation, runbooks, communication materials, or project references if behavior, process, interface, configuration, or usage changed
|
||||
```
|
||||
|
||||
Reference design.md for scope, requirements, decisions, execution
|
||||
direction, and verification expectations.
|
||||
|
||||
Each task should be verifiable: it must be clear when the task is done.
|
||||
requires:
|
||||
- design
|
||||
apply:
|
||||
requires:
|
||||
- design
|
||||
- tasks
|
||||
tracks: tasks.md
|
||||
instruction: |
|
||||
Read design.md first, then tasks.md.
|
||||
Also follow workflow context/configuration, such as openspec/config.yaml when available, and any relevant project or workflow documentation referenced by design.md.
|
||||
Treat design.md as the source of truth for scope, requirements, decisions, guardrails, execution direction, and verification expectations.
|
||||
Work through pending tasks in dependency order and mark complete as you go.
|
||||
Mark a task complete only after its execution and required verification are done.
|
||||
Pause if tasks conflict with design.md, if design.md has blocking open questions, or if clarification is needed.
|
||||
77
openspec/schemas/fast-drive/templates/design.md
Normal file
77
openspec/schemas/fast-drive/templates/design.md
Normal file
@@ -0,0 +1,77 @@
|
||||
## Context
|
||||
|
||||
<!-- Problem, current state, relevant references, and triggering user request -->
|
||||
|
||||
## Discussion Notes
|
||||
|
||||
<!-- Key conclusions from exploration or prior discussion that apply must preserve -->
|
||||
|
||||
- Agreed conclusions:
|
||||
- User preferences:
|
||||
- Constraints:
|
||||
- Rejected ideas:
|
||||
|
||||
## Requirements
|
||||
|
||||
<!-- Expected outcomes, behavior/process/interface/content changes, continuity expectations, and acceptance criteria -->
|
||||
|
||||
| Requirement | Acceptance Criteria |
|
||||
| ----------- | ------------------- |
|
||||
| | |
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
<!-- What this design aims to achieve -->
|
||||
|
||||
**Non-Goals:**
|
||||
<!-- What is explicitly out of scope -->
|
||||
|
||||
## Execution Guardrails
|
||||
|
||||
<!-- Must-follow constraints, forbidden approaches, preserved behavior/processes, dependency limits, and project- or workflow-specific boundaries -->
|
||||
|
||||
- Dependencies:
|
||||
- Constraints:
|
||||
- Quality Bar:
|
||||
- Stakeholders:
|
||||
- Documentation / Communication:
|
||||
- Compatibility / Continuity:
|
||||
|
||||
## Affected Areas
|
||||
|
||||
<!-- Concrete artifacts, references, stakeholders, systems, workstreams, documents, configurations, assets, or handoffs relevant to this change -->
|
||||
|
||||
| Area | Artifacts / References | Expected Change | Notes |
|
||||
| ---- | ---------------------- | --------------- | ----- |
|
||||
| <!-- Area --> | <!-- Artifacts / References --> | <!-- Expected Change --> | <!-- Notes --> |
|
||||
|
||||
## Decisions
|
||||
|
||||
<!-- Key decisions, rationale, and alternatives considered -->
|
||||
|
||||
| Decision | Rationale | Alternatives Rejected |
|
||||
| -------- | --------- | --------------------- |
|
||||
| | | |
|
||||
|
||||
## Execution Plan
|
||||
|
||||
<!-- Main workstreams or artifacts to change, integration or handoff points, sequencing, and rollout notes -->
|
||||
|
||||
## Verification Plan
|
||||
|
||||
<!-- Validation checks, reviews, approvals, acceptance checks, documentation checks, communication checks, and manual checks needed -->
|
||||
|
||||
| Requirement / Risk | Verification |
|
||||
| ------------------ | ------------ |
|
||||
| | |
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
<!-- Format: [Risk] -> Mitigation -->
|
||||
|
||||
## Open Questions
|
||||
|
||||
| Status | Question | Decision Needed |
|
||||
| ------ | -------- | --------------- |
|
||||
| None | No open questions. | None |
|
||||
19
openspec/schemas/fast-drive/templates/tasks.md
Normal file
19
openspec/schemas/fast-drive/templates/tasks.md
Normal file
@@ -0,0 +1,19 @@
|
||||
## 1. Context Review
|
||||
|
||||
- [ ] 1.1 Read design.md and identify scope, requirements, decisions, guardrails, and open questions
|
||||
- [ ] 1.2 Review relevant artifacts and references listed in Affected Areas
|
||||
|
||||
## 2. Execution
|
||||
|
||||
- [ ] 2.1 Execute first concrete work item from design.md
|
||||
- [ ] 2.2 Execute next concrete work item from design.md
|
||||
|
||||
## 3. Validation
|
||||
|
||||
- [ ] 3.1 Run required validation from Verification Plan
|
||||
- [ ] 3.2 Perform quality checks required by the project or workflow
|
||||
- [ ] 3.3 Perform required manual review or acceptance checks from Verification Plan
|
||||
|
||||
## 4. Documentation / Communication
|
||||
|
||||
- [ ] 4.1 Update relevant documentation, runbooks, communication materials, or project references if behavior, process, interface, configuration, or usage changed
|
||||
@@ -1,139 +0,0 @@
|
||||
## Requirements
|
||||
|
||||
### Requirement: 企业 Admin 后台布局
|
||||
|
||||
系统 SHALL 实现 Header + 侧边栏 + 内容区的企业 Admin 后台布局，使用 TDesign Layout 组件。
|
||||
|
||||
#### Scenario: 布局结构
|
||||
|
||||
- **WHEN** 用户访问应用
|
||||
- **THEN** 系统 SHALL 渲染包含 Header、Aside、Content 的 Layout 结构
|
||||
|
||||
#### Scenario: Layout 嵌套结构
|
||||
|
||||
- **WHEN** 布局渲染
|
||||
- **THEN** 系统 SHALL 使用嵌套 Layout 结构：`Layout > (Header + Layout > (Aside + Content))`
|
||||
|
||||
### Requirement: Header 布局
|
||||
|
||||
Header SHALL 包含折叠按钮、页面标题、主题切换控件。
|
||||
|
||||
#### Scenario: Header 左侧折叠按钮
|
||||
|
||||
- **WHEN** Header 渲染
|
||||
- **THEN** 系统 SHALL 在左侧显示侧边栏折叠/展开按钮
|
||||
|
||||
#### Scenario: Header 页面标题
|
||||
|
||||
- **WHEN** Header 渲染
|
||||
- **THEN** 系统 SHALL 显示当前路由对应的页面标题（从 menu 获取）
|
||||
- **AND** 若当前路由无匹配菜单项，SHALL 显示 `APP.title` 作为 fallback
|
||||
|
||||
#### Scenario: Header 右侧主题切换
|
||||
|
||||
- **WHEN** Header 渲染
|
||||
- **THEN** 系统 SHALL 在右侧显示主题切换 RadioGroup（系统/明亮/黑暗）
|
||||
|
||||
### Requirement: 侧边栏菜单
|
||||
|
||||
系统 SHALL 提供侧边栏菜单组件（Sidebar），使用 TDesign Menu 组件，支持折叠/展开。
|
||||
|
||||
#### Scenario: 侧边栏渲染菜单项
|
||||
|
||||
- **WHEN** 侧边栏渲染
|
||||
- **THEN** 系统 SHALL 根据 `menu.tsx` 渲染所有菜单项
|
||||
|
||||
#### Scenario: 菜单项点击导航
|
||||
|
||||
- **WHEN** 用户点击菜单项
|
||||
- **THEN** 系统 SHALL 使用 React Router 的 `navigate` 跳转到对应路径
|
||||
|
||||
#### Scenario: 菜单项激活状态
|
||||
|
||||
- **WHEN** 当前路由与菜单项路径匹配
|
||||
- **THEN** 系统 SHALL 高亮显示该菜单项
|
||||
|
||||
### Requirement: 侧边栏折叠
|
||||
|
||||
侧边栏 SHALL 支持折叠/展开，折叠状态持久化到 localStorage。
|
||||
|
||||
#### Scenario: 侧边栏折叠交互
|
||||
|
||||
- **WHEN** 用户点击 Header 左侧的折叠按钮
|
||||
- **THEN** 系统 SHALL 切换侧边栏折叠状态
|
||||
|
||||
#### Scenario: 侧边栏折叠宽度
|
||||
|
||||
- **WHEN** 侧边栏折叠
|
||||
- **THEN** Aside 宽度 SHALL 变为 80px，Menu 仅显示图标
|
||||
|
||||
#### Scenario: 侧边栏展开宽度
|
||||
|
||||
- **WHEN** 侧边栏展开
|
||||
- **THEN** Aside 宽度 SHALL 变为 232px，Menu 显示图标和文字
|
||||
|
||||
#### Scenario: 折叠状态持久化
|
||||
|
||||
- **WHEN** 用户切换侧边栏折叠状态
|
||||
- **THEN** 系统 SHALL 将状态存储到 localStorage key `"sidebar.collapsed"`
|
||||
|
||||
#### Scenario: 折叠状态恢复
|
||||
|
||||
- **WHEN** 应用初始化
|
||||
- **THEN** 系统 SHALL 从 localStorage 读取 `"sidebar.collapsed"` 并恢复折叠状态
|
||||
|
||||
### Requirement: 侧边栏主题跟随全局
|
||||
|
||||
侧边栏 Menu 的主题 SHALL 跟随全局主题设置，不单独设置 `theme` prop。
|
||||
|
||||
#### Scenario: 侧边栏跟随全局主题
|
||||
|
||||
- **WHEN** 全局主题切换为 dark
|
||||
- **THEN** 侧边栏 SHALL 自动应用 dark 主题样式
|
||||
|
||||
### Requirement: 菜单配置单一数据源
|
||||
|
||||
系统 SHALL 在 `src/web/menu.tsx` 定义菜单项配置，包含 `value`、`label`、`path`、`icon` 字段。
|
||||
|
||||
#### Scenario: 菜单配置类型安全
|
||||
|
||||
- **WHEN** 定义菜单配置
|
||||
- **THEN** 系统 SHALL 使用 `as const` 保证字面量类型推断
|
||||
|
||||
#### Scenario: Sidebar 引用菜单配置
|
||||
|
||||
- **WHEN** Sidebar 渲染
|
||||
- **THEN** 系统 SHALL 遍历 `MENU_ITEMS` 渲染 MenuItem
|
||||
|
||||
### Requirement: 示例页面
|
||||
|
||||
系统 SHALL 提供示例页面组件：Dashboard、Users、Settings、NotFound。
|
||||
|
||||
#### Scenario: Dashboard 页面
|
||||
|
||||
- **WHEN** 用户访问 `/`
|
||||
- **THEN** 系统 SHALL 渲染 Dashboard 页面（包含原 app.tsx 的欢迎语和 /health 展示）
|
||||
|
||||
#### Scenario: Users 页面占位
|
||||
|
||||
- **WHEN** 用户访问 `/users`
|
||||
- **THEN** 系统 SHALL 渲染用户管理占位页面
|
||||
|
||||
#### Scenario: Settings 页面占位
|
||||
|
||||
- **WHEN** 用户访问 `/settings`
|
||||
- **THEN** 系统 SHALL 渲染系统设置占位页面
|
||||
|
||||
#### Scenario: NotFound 页面
|
||||
|
||||
- **WHEN** 用户访问未定义路径
|
||||
- **THEN** 系统 SHALL 渲染 404 页面，提供返回首页按钮
|
||||
|
||||
### Requirement: CSS 类名迁移
|
||||
|
||||
原 `.dashboard-*` CSS 类名 SHALL 变更为 `.app-*`。
|
||||
|
||||
#### Scenario: 布局类名
|
||||
|
||||
- **WHEN** 样式应用
|
||||
- **THEN** 系统 SHALL 使用 `.app-layout`、`.app-header`、`.app-content`、`.app-sidebar` 类名
|
||||
@@ -1,75 +0,0 @@
|
||||
## Purpose
|
||||
|
||||
定义应用全局常量，作为应用元信息（name、title、subtitle、description、version）的唯一真实来源，供前后端及构建脚本统一引用，消除硬编码散落。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 应用元信息唯一来源
|
||||
|
||||
系统 SHALL 在 `src/shared/app.ts` 中定义应用全局常量 `APP`，包含以下字段：
|
||||
- `name`：机器标识（kebab-case 格式）
|
||||
- `title`：人类可读标题
|
||||
- `subtitle`：副标题
|
||||
- `description`：应用描述（用于 SEO meta）
|
||||
- `version`：语义版本号
|
||||
|
||||
`APP` SHALL 使用 `as const` 声明，保证字面量类型推断。
|
||||
|
||||
#### Scenario: 后端引用应用名称
|
||||
|
||||
- **WHEN** 后端代码需要应用名称（如 CLI 帮助文本、health 响应、启动日志）
|
||||
- **THEN** 系统 SHALL 从 `src/shared/app.ts` 导入 `APP.name`
|
||||
|
||||
#### Scenario: 前端引用应用标题
|
||||
|
||||
- **WHEN** 前端代码需要应用标题（如 Header logo、欢迎文本）
|
||||
- **THEN** 系统 SHALL 从 `src/shared/app.ts` 导入 `APP.title`
|
||||
|
||||
#### Scenario: 构建脚本引用应用名称
|
||||
|
||||
- **WHEN** 构建脚本需要确定可执行文件名
|
||||
- **THEN** 系统 SHALL 从 `src/shared/app.ts` 导入 `APP.name`
|
||||
|
||||
### Requirement: 前端 HTML 元信息动态设置
|
||||
|
||||
系统 SHALL 在 React 应用挂载时动态设置 HTML 元信息：
|
||||
- `document.title` SHALL 设置为 `APP.title`
|
||||
- `<meta name="description">` 内容 SHALL 设置为 `APP.description`
|
||||
|
||||
#### Scenario: 页面标题显示应用名称
|
||||
|
||||
- **WHEN** 用户访问应用
|
||||
- **THEN** 浏览器标签页标题 SHALL 显示 `APP.title`
|
||||
|
||||
#### Scenario: meta description 设置
|
||||
|
||||
- **WHEN** 搜索引擎爬取页面
|
||||
- **THEN** meta description SHALL 包含 `APP.description`
|
||||
|
||||
### Requirement: localStorage key 语义化命名
|
||||
|
||||
主题偏好存储 key SHALL 为 `"theme.preference"`，不包含应用名前缀。
|
||||
|
||||
#### Scenario: 主题偏好持久化
|
||||
|
||||
- **WHEN** 用户选择主题偏好（system/light/dark）
|
||||
- **THEN** 系统 SHALL 将偏好值存储到 localStorage key `"theme.preference"`
|
||||
|
||||
#### Scenario: 主题偏好读取
|
||||
|
||||
- **WHEN** 应用初始化时读取用户主题偏好
|
||||
- **THEN** 系统 SHALL 从 localStorage key `"theme.preference"` 读取
|
||||
|
||||
### Requirement: 侧边栏折叠状态 localStorage key
|
||||
|
||||
侧边栏折叠状态存储 key SHALL 为 `"sidebar.collapsed"`，不包含应用名前缀。
|
||||
|
||||
#### Scenario: 折叠状态持久化
|
||||
|
||||
- **WHEN** 用户切换侧边栏折叠状态
|
||||
- **THEN** 系统 SHALL 将状态存储到 localStorage key `"sidebar.collapsed"`
|
||||
|
||||
#### Scenario: 折叠状态读取
|
||||
|
||||
- **WHEN** 应用初始化时读取侧边栏折叠状态
|
||||
- **THEN** 系统 SHALL 从 localStorage key `"sidebar.collapsed"` 读取
|
||||
@@ -1,57 +0,0 @@
|
||||
## Requirements
|
||||
|
||||
### Requirement: 前端 SPA 路由
|
||||
|
||||
系统 SHALL 使用 React Router v7 (Declarative mode) 实现前端 SPA 路由，支持多页面导航。
|
||||
|
||||
#### Scenario: 应用启动时初始化路由
|
||||
|
||||
- **WHEN** 应用启动
|
||||
- **THEN** 系统 SHALL 在 `main.tsx` 中使用 `BrowserRouter` 包裹根组件
|
||||
|
||||
#### Scenario: 路由匹配渲染对应页面
|
||||
|
||||
- **WHEN** 用户访问路径 `/`
|
||||
- **THEN** 系统 SHALL 渲染 Dashboard 页面
|
||||
|
||||
#### Scenario: 用户管理页面路由
|
||||
|
||||
- **WHEN** 用户访问路径 `/users`
|
||||
- **THEN** 系统 SHALL 渲染用户管理页面
|
||||
|
||||
#### Scenario: 系统设置页面路由
|
||||
|
||||
- **WHEN** 用户访问路径 `/settings`
|
||||
- **THEN** 系统 SHALL 渲染系统设置页面
|
||||
|
||||
#### Scenario: 未知路径返回 404 页面
|
||||
|
||||
- **WHEN** 用户访问未定义的路径（如 `/unknown`）
|
||||
- **THEN** 系统 SHALL 渲染 NotFound 页面
|
||||
|
||||
### Requirement: 路由定义独立文件
|
||||
|
||||
路由定义 SHALL 抽离为独立文件 `src/web/routes.tsx`，`app.tsx` 引用该文件。
|
||||
|
||||
#### Scenario: 路由配置集中管理
|
||||
|
||||
- **WHEN** 开发者需要新增或修改路由
|
||||
- **THEN** 系统 SHALL 在 `routes.tsx` 中统一管理所有 `<Route>` 定义
|
||||
|
||||
### Requirement: 路由守卫预留
|
||||
|
||||
系统 SHALL 预留路由守卫接口（`ProtectedRoute` 组件），但暂不实现认证逻辑。
|
||||
|
||||
#### Scenario: 路由守卫组件存在
|
||||
|
||||
- **WHEN** 需要实现认证保护
|
||||
- **THEN** 系统 SHALL 提供 `ProtectedRoute` wrapper 组件供 Routes 使用
|
||||
|
||||
### Requirement: Vite code splitting 包含路由库
|
||||
|
||||
`vite.config.ts` 的 code splitting 配置 SHALL 新增 `vendor-router` 组，包含 `react-router`。
|
||||
|
||||
#### Scenario: 路由库独立分包
|
||||
|
||||
- **WHEN** 执行生产构建
|
||||
- **THEN** `react-router` SHALL 被打包到独立的 `vendor-router` chunk 中
|
||||
Reference in New Issue
Block a user