3.4 KiB
3.4 KiB
技术栈（Tech Stack）
“用什么”的统一速查表。选型与理由在此集中维护；“怎么把它们搭起来”见 架构设计。 未定项必须标为待定，不要让 agent 在代码里自行决定。
一、技术栈一览
| 维度 | 选型 | 状态 | 理由 / 说明 |
|---|---|---|---|
| 前端框架 | 【例如 React / Vue / go-app / 原生】 | 【已定 / 待定】 | 【理由】 |
| UI 样式方案 | 【例如 CSS / Tailwind / 组件库】 | 【已定 / 待定】 | 【理由】 |
| 状态管理 | 【例如框架内置 / Zustand / Redux】 | 【已定 / 待定】 | 【理由】 |
| 后端 | 【例如 Go net/http / FastAPI / NestJS】 | 【已定 / 待定】 | 【理由】 |
| 数据库 | 【例如 SQLite / Postgres / MySQL】 | 【已定 / 待定】 | 【理由】 |
| 鉴权方式 | 【例如 Session Cookie / JWT / 无账号】 | 【已定 / 待定】 | 【理由】 |
| 部署方式 | 【例如单二进制 / Docker / Vercel】 | 【已定 / 待定】 | 【理由】 |
| 测试 | 【例如 go test / pytest / vitest】 | 【已定 / 待定】 | 【理由】 |
二、决策记录与演进
- 【选型 1】：现在选择【方案】，因为【理由】。未来在【条件】出现时再评估【替代方案】。
- 【选型 2】：当前不引入【工具 / 框架】，避免【复杂度】。
三、构建与运行命令
| 用途 | 命令 |
|---|---|
| 安装依赖 | 【命令】 |
| 本地开发 | 【命令】 |
| 构建 | 【命令】 |
| 测试 | 【命令】 |
| 格式化 / 静态检查 | 【命令】 |
Windows PowerShell 如有差异，单独列出：
# 示例
npm install
npm run dev
npm test
四、验证矩阵与构建产物
项目必须把验证分层写清，任务文件再按改动范围引用对应层级。不要让 agent 自行猜测“相关测试”或“完整验证”分别包含什么。
| 层级 | 触发条件 | 命令 / 操作 | 通过证据 |
|---|---|---|---|
| 任务相关验证 | 每个任务必跑 | 【受影响模块的测试 / 静态检查 / 构建命令】 |
【退出码、测试数或关键断言】 |
| 完整门禁 | 发布前；修改共享契约、依赖、构建配置或跨模块基础设施时；或任务明确要求时 | 【全量测试 / 全量 lint / 发布构建命令】 |
【退出码、测试数、构建产物】 |
| 人工 / 设备验收 | 自动化无法替代的真机、硬件、外部账号、主观体验或受控环境验收 | 【操作步骤、执行角色、设备 / 环境】 |
【人工结论、截图 / 日志 / 记录位置】 |
- 任务相关验证不能省略；是否触发完整门禁，必须依据上表和任务验收要点判断，不要求所有小改动无差别跑全量。
- 必需的人工 / 设备验收未完成时，任务保持
DOING或标为BLOCKED并写明等待事项，不得标记DONE。 - 若构建产物需要部署、交接或比较新旧版本，记录产物路径、生成命令和项目选定的指纹（例如 SHA-256）；版本号不能单独证明部署的是本次构建。
- 标准启动 / 验证入口仍以根目录
init.sh或init.ps1为准；本表负责说明不同验证层级何时触发。
五、依赖纪律
- 新增第三方依赖前，先说明用途、替代方案和维护成本。
- 不确定的技术选型先更新本文，再进入代码。
- 不允许同一职责并存两套框架或两套状态管理方案。