refactor: 移除 success 字段，简化为 matched 单层判定模型
This commit is contained in:
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-05-09
|
||||
@@ -0,0 +1,121 @@
|
||||
## Context
|
||||
|
||||
当前项目是 Bun + TypeScript 的最小工程，入口文件只有 `index.ts`，尚未形成前端、后端、共享类型、测试和构建的边界。目标是在保持 Bun 单文件部署优势的同时，引入完整的 Vite + React 前端开发体验。
|
||||
|
||||
业界成熟实践通常不是让后端参与前端 HMR，而是开发期让 Vite dev server 独立承载前端，使用 proxy 将 `/api/*` 转发给后端；生产期由前端构建生成静态资源，再由后端服务这些资源。Go/Rust 生态常用类似 `embed` 的方式把 Vite `dist/` 打入单个二进制，Bun 可通过 `bun build --compile` 与 embedded files/full-stack asset 能力实现同类目标。
|
||||
|
||||
```
|
||||
开发期
|
||||
|
||||
Browser
|
||||
|
|
||||
v
|
||||
Vite dev server :5173
|
||||
|-- React HMR
|
||||
|-- /api/* proxy
|
||||
|
|
||||
v
|
||||
Bun API server :3000
|
||||
|
||||
生产期
|
||||
|
||||
Browser
|
||||
|
|
||||
v
|
||||
gateway-checker executable
|
||||
|-- /api/* Bun API
|
||||
|-- /health 健康检查
|
||||
|-- /assets/* Vite 静态资源
|
||||
|-- /* React SPA fallback
|
||||
```
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
|
||||
- 建立 Vite + React + TypeScript 前端应用结构，保留开发期 HMR。
|
||||
- 建立 Bun 后端服务结构，统一承载 API、健康检查和生产前端资源。
|
||||
- 提供一个可运行 demo，前端页面通过 `/api/demo` 调用后端并展示响应。
|
||||
- 建立前后端共享类型边界，避免重复定义基础接口类型。
|
||||
- 建立生产构建链路，输出单个 Bun standalone executable。
|
||||
- 保持前端可拆离：前端只通过 HTTP `/api/*` 依赖后端，不直接 import 后端实现。
|
||||
- 更新 README，记录结构、命令、测试、构建和运行方式。
|
||||
|
||||
**Non-Goals:**
|
||||
|
||||
- 不引入 SSR、React Server Components、Next.js 或其他全栈框架。
|
||||
- 不引入数据库、认证、用户系统或业务功能。
|
||||
- 不要求一次性完成多平台发布矩阵，只定义可扩展的 target 机制。
|
||||
- 不把运行期配置、日志或可变数据嵌入 executable。
|
||||
- 不在开发期强制单端口访问；开发期可以使用 Vite 端口作为浏览器入口。
|
||||
|
||||
## Decisions
|
||||
|
||||
### Decision: 使用 Vite + React 作为前端开发框架
|
||||
|
||||
采用 Vite + React + TypeScript，开发期由 Vite 提供 HMR，生产期由 `vite build` 输出静态资源。React 适合后续构建复杂管理界面、状态页、图表和交互式检测视图。
|
||||
|
||||
替代方案：使用 Bun 原生 HTML imports。该方案更简单、依赖更少，但前端生态、插件、测试和组件体系弱于 Vite。
|
||||
|
||||
替代方案：使用 Next.js。该方案能力更强，但 SSR/路由/部署模型与“Bun 单 executable”目标存在额外摩擦。
|
||||
|
||||
### Decision: 开发期 Vite proxy `/api/*` 到 Bun 后端
|
||||
|
||||
浏览器开发入口默认使用 Vite dev server，前端请求统一使用相对路径 `/api/*`。Vite 负责把这些请求代理到 Bun 后端服务，从而保持同源开发体验，避免 CORS 和硬编码后端地址。
|
||||
|
||||
替代方案：Bun 后端反向代理 Vite dev server。该方案可以让开发期也统一一个端口，但会增加胶水代码，并且容易干扰 Vite HMR 行为。
|
||||
|
||||
### Decision: 生产期由 Bun 服务 Vite `dist/`
|
||||
|
||||
生产构建先执行 Vite build，再让 Bun 后端服务 `index.html`、`assets/*` 和其他静态资源。非 API、非静态资源路径 fallback 到 `index.html`，用于支持 React SPA 路由刷新。
|
||||
|
||||
替代方案：前端独立部署到 CDN。该方案扩展性更好，但不满足当前“一个可执行程序包含前后端”的目标。
|
||||
|
||||
### Decision: 单 executable 是发布形态，不是代码耦合方式
|
||||
|
||||
前端和后端在源码层保持清晰边界，只通过 HTTP API 和共享类型协作。打包层负责将 Vite 产物嵌入 Bun executable。这样未来若需要 CDN、独立前端部署或多客户端复用 API，不需要重写后端业务代码。
|
||||
|
||||
替代方案：后端源码直接 import 前端源码或前端模块。该方案短期简单，但会模糊运行时边界，增加后续拆离成本。
|
||||
|
||||
### Decision: API 路径统一保留在 `/api/*`
|
||||
|
||||
所有业务 API 使用 `/api/*` 前缀，健康检查使用 `/health`。demo API 使用 `/api/demo`，返回前端可展示的 JSON 响应。生产期路由优先级为 API、健康检查、静态资源、SPA fallback。未命中的 `/api/*` 必须返回 JSON 404，不能 fallback 到前端页面。
|
||||
|
||||
替代方案：API 与页面路径混排。该方案不利于 Vite proxy、生产 fallback 和未来前端独立部署。
|
||||
|
||||
### Decision: 运行配置使用环境变量或 CLI 参数
|
||||
|
||||
host、port、日志级别等运行期配置不嵌入 executable，优先从 CLI 参数或环境变量读取。executable 内只包含只读程序代码和前端静态资源。
|
||||
|
||||
替代方案：构建期写死配置。该方案部署简单，但不同环境需要重新构建，且不利于发布同一个二进制。
|
||||
|
||||
### Decision: demo 是验收基线而不是业务功能
|
||||
|
||||
demo 只证明前端开发、后端 API、生产静态服务和 executable 打包链路能跑通。页面应展示来自 `/api/demo` 的后端响应，并在 README 中记录开发期访问方式和 executable 运行后的验证方式。
|
||||
|
||||
替代方案：只搭建空白 React 页面和空 API。该方案能证明结构存在，但不能证明前后端开发和打包后联通链路真实可用。
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- [Risk] Bun standalone executable 与 Vite `dist/` 嵌入方式相对 Go `embed` 更年轻。→ Mitigation: 先实现最小静态资源嵌入和端到端构建测试，再扩展多平台构建。
|
||||
- [Risk] Vite hashed assets、SPA fallback 和 Bun 静态路由可能出现路径映射问题。→ Mitigation: 对 `/`, `/assets/*`, 前端路由刷新和 `/api/*` 404 编写测试或构建后验证。
|
||||
- [Risk] 依赖数量会明显增加。→ Mitigation: 初期只引入 Vite、React、React DOM 和必要类型，不引入 UI 组件库、状态管理或路由库，除非后续需求明确。
|
||||
- [Risk] 单 executable 会把前端资源大小计入二进制。→ Mitigation: 保留 Vite 产物压缩能力，后续可按需启用分离部署或 CDN。
|
||||
- [Risk] 开发期前端和后端是两个进程，启动命令更复杂。→ Mitigation: 提供 `dev:web`、`dev:server` 和 `dev` 聚合脚本，并在 README 中说明。
|
||||
|
||||
## Migration Plan
|
||||
|
||||
1. 保留当前最小入口语义，重构为新的 server 入口。
|
||||
2. 新增 web、server、shared 和 scripts 目录结构。
|
||||
3. 引入最小 Vite + React 依赖并配置开发代理。
|
||||
4. 实现 Bun API、健康检查和生产静态资源服务。
|
||||
5. 增加测试和构建验证。
|
||||
6. 更新 README 作为项目结构和命令的权威说明。
|
||||
|
||||
回滚策略：如果 Vite 集成阻塞，可以保留 Bun 后端结构，移除 web 目录和前端构建脚本，退回 Bun 原生 HTML imports 或后端-only 形态。
|
||||
|
||||
## Open Questions
|
||||
|
||||
- 前端是否需要路由库，例如 React Router，还是先保持单页面组件状态？
|
||||
- 是否需要 UI 组件库，例如 TDesign、shadcn/ui 或保持纯 CSS？
|
||||
- 生产 executable 首期目标平台是当前 macOS，还是同时需要 Linux x64/arm64？
|
||||
@@ -0,0 +1,33 @@
|
||||
## Why
|
||||
|
||||
当前项目只有 Bun + TypeScript 的最小入口，尚不能支撑完整的前后端服务开发。引入 Vite + React 开发体验，并保持 Bun 后端可打包为单个可执行程序，可以同时满足本地快速迭代、前后端同源集成和简单部署的目标。
|
||||
|
||||
## What Changes
|
||||
|
||||
- 新增基于 Vite + React + TypeScript 的前端应用开发能力，开发期保留 Vite HMR。
|
||||
- 新增 Bun 后端服务作为 API 与生产静态资源承载层，API 统一位于 `/api/*`。
|
||||
- 新增开发期前端代理后端 API 的同源调用约定，避免前端写死后端地址。
|
||||
- 新增生产期构建链路：先构建前端静态资源，再将后端与前端产物打包为单个 Bun standalone executable。
|
||||
- 新增可验收 demo：前端页面调用后端 API 并展示响应，开发期和 executable 运行期都能验证前后端联通。
|
||||
- 新增 SPA fallback 行为：生产环境非 API 前端路由返回前端入口页面。
|
||||
- 更新 README，记录项目结构、开发命令、测试命令、构建命令与部署方式。
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `frontend-development-workflow`: 约定 Vite + React 前端开发、API proxy、共享类型和本地开发命令。
|
||||
- `fullstack-app-runtime`: 约定 Bun 服务在运行期同时提供 API、健康检查、静态资源和 SPA fallback。
|
||||
- `single-executable-packaging`: 约定生产构建将 Vite 前端产物和 Bun 后端服务打包为单个可执行程序。
|
||||
|
||||
### Modified Capabilities
|
||||
|
||||
无。当前 `openspec/specs/` 为空，没有既有 capability 需要修改。
|
||||
|
||||
## Impact
|
||||
|
||||
- 代码结构将从单入口 `index.ts` 扩展为前端、后端、共享类型和构建脚本的模块化结构。
|
||||
- 依赖将新增 Vite、React、React DOM 及相关 TypeScript 类型；测试依赖按实现方案最小化引入。
|
||||
- 开发脚本将覆盖前端 dev server、后端 dev server、并行开发、测试和生产构建。
|
||||
- 生产产物将从直接运行 TypeScript 入口变为 `dist/` 下的平台相关 executable。
|
||||
- demo 验收将覆盖开发期联调和生产 executable 运行后的前端页面、API 与健康检查。
|
||||
- README 需要同步说明模块结构、API 路径约定、构建产物和运行参数。
|
||||
@@ -0,0 +1,63 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Vite React 开发服务器
|
||||
系统 SHALL 提供基于 Vite + React + TypeScript 的前端开发工作流，并支持热模块替换。
|
||||
|
||||
#### Scenario: 启动前端开发服务器
|
||||
- **WHEN** 开发者启动前端开发命令
|
||||
- **THEN** 前端 SHALL 由 Vite 提供服务，并启用 React 热模块替换
|
||||
|
||||
#### Scenario: 构建前端静态资源
|
||||
- **WHEN** 开发者运行前端生产构建命令
|
||||
- **THEN** 系统 SHALL 产出可由 Bun 后端服务的前端静态资源
|
||||
|
||||
### Requirement: 前端开发期 API 代理
|
||||
前端开发服务器 SHALL 在本地开发期间将 `/api/*` 请求代理到 Bun 后端服务。
|
||||
|
||||
#### Scenario: 前端开发期调用 API
|
||||
- **WHEN** 浏览器从 Vite 开发源请求 `/api/demo`
|
||||
- **THEN** Vite SHALL 将请求转发到 Bun 后端服务，且不需要浏览器 CORS 配置
|
||||
|
||||
#### Scenario: 开发期访问非 API 前端路由
|
||||
- **WHEN** 浏览器从 Vite 开发源请求非 API 前端路由
|
||||
- **THEN** Vite SHALL 将该请求作为前端应用流量处理，而不是转发到后端
|
||||
|
||||
### Requirement: 前端使用相对 API 路径
|
||||
除非有文档化的部署配置覆盖该行为，前端代码 MUST 通过相对 `/api/*` URL 调用后端 API。
|
||||
|
||||
#### Scenario: 前端获取后端数据
|
||||
- **WHEN** 前端代码调用后端 API
|
||||
- **THEN** 请求 URL 默认 MUST 使用相对 `/api/*` 路径
|
||||
|
||||
#### Scenario: 运行环境变化
|
||||
- **WHEN** host 或 port 在开发环境和生产环境之间变化
|
||||
- **THEN** 前端 API 调用 SHALL 无需修改源码即可继续工作
|
||||
|
||||
### Requirement: 端到端开发 demo
|
||||
项目 SHALL 提供一个可见的开发 demo，用于证明 React 前端可以通过 Vite 代理调用 Bun 后端。
|
||||
|
||||
#### Scenario: Demo 页面展示后端响应
|
||||
- **WHEN** 开发者启动文档化的开发命令并打开前端 URL
|
||||
- **THEN** 页面 SHALL 调用 `/api/demo` 并展示 Bun 后端返回的数据
|
||||
|
||||
#### Scenario: 开发期后端不可用
|
||||
- **WHEN** 前端 demo 无法访问 `/api/demo`
|
||||
- **THEN** 页面 SHALL 展示清晰的错误状态，而不是静默显示为成功
|
||||
|
||||
### Requirement: 集成开发命令
|
||||
项目 SHALL 提供一个文档化命令，用于在 demo 开发期间同时运行前端和后端。
|
||||
|
||||
#### Scenario: 启动全栈开发
|
||||
- **WHEN** 开发者运行文档化的全栈开发命令
|
||||
- **THEN** 系统 SHALL 启动 Vite 前端开发服务器和 `/api/demo` 所需的 Bun 后端服务器
|
||||
|
||||
### Requirement: 共享 TypeScript 契约
|
||||
项目 SHALL 为前端和后端共同使用的请求与响应类型提供共享 TypeScript 边界。
|
||||
|
||||
#### Scenario: 定义 API 响应结构
|
||||
- **WHEN** 前端和后端都需要某个 API 响应类型
|
||||
- **THEN** 该类型 SHALL 定义在 shared 模块中，而不是在两端重复定义
|
||||
|
||||
#### Scenario: 前端导入共享类型
|
||||
- **WHEN** 前端代码导入共享 API 类型
|
||||
- **THEN** 该导入 SHALL 不要求将后端运行时实现打包进前端
|
||||
@@ -0,0 +1,67 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Bun HTTP 运行时
|
||||
系统 SHALL 运行一个 Bun HTTP server，由单个进程提供后端 API、健康检查、生产静态资源和 SPA fallback 行为。
|
||||
|
||||
#### Scenario: 启动运行时服务器
|
||||
- **WHEN** server 进程成功启动
|
||||
- **THEN** 它 SHALL 监听配置的 host 和 port，并记录实际 server URL
|
||||
|
||||
#### Scenario: 提供运行时配置
|
||||
- **WHEN** 通过支持的运行时配置提供 host 或 port
|
||||
- **THEN** server SHALL 使用该值，且不需要重新构建
|
||||
|
||||
### Requirement: API 路由命名空间
|
||||
系统 MUST 将 `/api/*` 保留给后端 API 路由。
|
||||
|
||||
#### Scenario: API 路由匹配
|
||||
- **WHEN** 请求匹配已注册的 `/api/*` 路由
|
||||
- **THEN** Bun server SHALL 返回 API handler 的响应
|
||||
|
||||
#### Scenario: API 路由未命中
|
||||
- **WHEN** 请求访问未注册的 `/api/*` 路由
|
||||
- **THEN** Bun server MUST 返回 JSON 404 响应，而不是前端 HTML 文档
|
||||
|
||||
### Requirement: Demo API 端点
|
||||
系统 SHALL 暴露 `/api/demo` 作为稳定 demo 端点，用于证明前后端集成可用。
|
||||
|
||||
#### Scenario: Demo API 成功响应
|
||||
- **WHEN** 客户端请求 `/api/demo`
|
||||
- **THEN** Bun server SHALL 返回包含可读 message 和 runtime metadata 的 JSON 响应
|
||||
|
||||
#### Scenario: Demo API 内容类型
|
||||
- **WHEN** 客户端请求 `/api/demo`
|
||||
- **THEN** Bun server SHALL 返回 JSON content type 的响应
|
||||
|
||||
### Requirement: 健康检查端点
|
||||
系统 SHALL 在前端 SPA fallback 之外暴露健康检查端点。
|
||||
|
||||
#### Scenario: 健康检查成功
|
||||
- **WHEN** 客户端请求 `/health`
|
||||
- **THEN** Bun server SHALL 返回成功的、机器可读的健康检查响应
|
||||
|
||||
### Requirement: 生产静态资源服务
|
||||
系统 SHALL 在生产模式下由 Bun runtime 服务 Vite 生产资源。
|
||||
|
||||
#### Scenario: 请求构建后的资源
|
||||
- **WHEN** 客户端请求构建后的前端资源，例如 `/assets/app.js`
|
||||
- **THEN** Bun server SHALL 返回该资源并带有适当的 content type
|
||||
|
||||
#### Scenario: 请求前端根路径
|
||||
- **WHEN** 客户端请求 `/`
|
||||
- **THEN** Bun server SHALL 返回前端入口 HTML 文档
|
||||
|
||||
#### Scenario: 生产 demo 页面调用 API
|
||||
- **WHEN** 客户端从生产 Bun runtime 打开前端页面
|
||||
- **THEN** demo 页面 SHALL 能够从同源调用 `/api/demo` 并展示后端响应
|
||||
|
||||
### Requirement: SPA fallback 行为
|
||||
系统 SHALL 在生产环境中为非 API、非静态资源的前端路由返回前端入口 HTML 文档。
|
||||
|
||||
#### Scenario: 刷新前端路由
|
||||
- **WHEN** 客户端请求前端路由，例如 `/dashboard`
|
||||
- **THEN** Bun server SHALL 返回前端入口 HTML 文档
|
||||
|
||||
#### Scenario: 保留 API 错误语义
|
||||
- **WHEN** 客户端请求未知的 `/api/*` 路由
|
||||
- **THEN** Bun server MUST NOT 返回前端入口 HTML 文档
|
||||
@@ -0,0 +1,49 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 生产构建顺序
|
||||
生产构建 MUST 在编译 Bun 后端 executable 之前先构建 Vite 前端。
|
||||
|
||||
#### Scenario: 运行生产构建
|
||||
- **WHEN** 开发者运行生产构建命令
|
||||
- **THEN** 系统 MUST 在调用 Bun standalone executable 编译之前生成前端静态资源
|
||||
|
||||
#### Scenario: 前端构建失败
|
||||
- **WHEN** 前端生产构建失败
|
||||
- **THEN** 系统 MUST 停止生产构建，且不能输出 stale executable
|
||||
|
||||
### Requirement: 单 executable 输出
|
||||
生产构建 SHALL 输出一个 standalone executable，其中包含 Bun 后端、必要 server 依赖和构建后的前端资源。
|
||||
|
||||
#### Scenario: 在目标机器运行 executable
|
||||
- **WHEN** 生成的 executable 在兼容目标平台上运行
|
||||
- **THEN** 它 SHALL 启动全栈应用，且不要求目标机器安装 Node.js、Bun、Vite 或 `node_modules`
|
||||
|
||||
#### Scenario: 服务嵌入的前端
|
||||
- **WHEN** executable 收到前端根路径请求
|
||||
- **THEN** 它 SHALL 从 executable 内包含的资源服务前端，且不需要外部 `dist/` 目录
|
||||
|
||||
#### Scenario: 服务嵌入 demo API 和页面
|
||||
- **WHEN** 生成的 executable 启动，且浏览器打开前端根路径
|
||||
- **THEN** 页面 SHALL 展示同一个 executable 进程中 `/api/demo` 返回的数据
|
||||
|
||||
### Requirement: 外部运行时配置
|
||||
executable MUST 将环境相关运行时配置保留在嵌入的前端和 server bundle 之外。
|
||||
|
||||
#### Scenario: 修改监听端口
|
||||
- **WHEN** 操作者修改受支持的 port 配置
|
||||
- **THEN** 同一个 executable SHALL 在不重新构建的情况下监听新端口
|
||||
|
||||
#### Scenario: 缺少可选配置
|
||||
- **WHEN** 可选运行时配置被省略
|
||||
- **THEN** executable SHALL 使用文档化的默认值
|
||||
|
||||
### Requirement: 构建验证
|
||||
项目 SHALL 提供验证，证明生产 executable 可以服务 API、健康检查、静态资源和 SPA fallback 路由。
|
||||
|
||||
#### Scenario: 验证 executable 路由
|
||||
- **WHEN** 构建验证针对生成的 executable 运行
|
||||
- **THEN** 它 SHALL 检查 `/api/demo`、`/health`、前端根路径、静态资源和前端 fallback 请求
|
||||
|
||||
#### Scenario: 验证失败
|
||||
- **WHEN** 任一代表性生产路由检查失败
|
||||
- **THEN** 验证 SHALL 使构建或测试命令失败
|
||||
@@ -0,0 +1,41 @@
|
||||
## 1. 项目结构与依赖
|
||||
|
||||
- [x] 1.1 创建 `src/server`、`src/web`、`src/shared`、`scripts` 和测试目录结构
|
||||
- [x] 1.2 调整 `package.json` 脚本以覆盖前端开发、后端开发、并行开发、测试和生产构建
|
||||
- [x] 1.3 引入 Vite、React、React DOM 和必要 TypeScript 类型依赖
|
||||
- [x] 1.4 创建或更新 README 记录项目结构、开发规范和命令
|
||||
|
||||
## 2. 前端开发工作流
|
||||
|
||||
- [x] 2.1 创建 Vite + React + TypeScript 前端入口和基础页面
|
||||
- [x] 2.2 配置 Vite 开发服务器将 `/api/*` 代理到 Bun 后端
|
||||
- [x] 2.3 实现前端 demo 页面调用相对路径 `/api/demo` 并展示成功和失败状态
|
||||
- [x] 2.4 建立 `src/shared` 共享类型并确保前端不引入后端运行时实现
|
||||
- [x] 2.5 提供一个 documented fullstack dev command 同时启动 Vite 前端和 Bun 后端
|
||||
|
||||
## 3. Bun 后端运行时
|
||||
|
||||
- [x] 3.1 创建 Bun server 入口并支持 host 和 port 运行期配置
|
||||
- [x] 3.2 实现 `/health` 健康检查响应
|
||||
- [x] 3.3 实现 `/api/demo` JSON 路由并返回前端可展示的 message 和 runtime metadata
|
||||
- [x] 3.4 实现未命中 `/api/*` 路由返回 JSON 404 的行为
|
||||
- [x] 3.5 实现生产环境静态资源服务和 SPA fallback 行为
|
||||
|
||||
## 4. 单可执行程序构建
|
||||
|
||||
- [x] 4.1 创建生产构建脚本，确保先执行 Vite build 再执行 Bun compile
|
||||
- [x] 4.2 将 Vite `dist/` 产物嵌入 Bun executable，运行时不依赖外部 `dist/` 目录
|
||||
- [x] 4.3 配置 executable 输出路径和当前平台默认构建目标
|
||||
- [x] 4.4 确保 executable 运行不依赖本机 Node.js、Bun、Vite 或 `node_modules`
|
||||
|
||||
## 5. 测试与验证
|
||||
|
||||
- [x] 5.1 为 `/api/demo`、`/health`、API 404 和 SPA fallback 增加测试
|
||||
- [x] 5.2 为生产构建脚本增加失败中断或防止 stale executable 的验证
|
||||
- [x] 5.3 增加构建后 executable smoke test 覆盖 `/api/demo`、健康检查、静态资源、前端 fallback 和 demo 页面内容
|
||||
- [x] 5.4 运行完整测试和生产构建，确认所有任务满足 specs
|
||||
|
||||
## 6. 文档收尾
|
||||
|
||||
- [x] 6.1 更新 README 中的运行参数、构建产物、部署方式和已知限制
|
||||
- [x] 6.2 在 README 中记录前端可拆离原则、`/api/*` 路径约定和 demo 验证步骤
|
||||
Reference in New Issue
Block a user