# 技术栈（Tech Stack）

> “用什么”的统一速查表。选型与理由在此集中维护；“怎么把它们搭起来”见 [架构设计](04-architecture.md)。
> 未定项必须标为待定，不要让 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 如有差异，单独列出：

```powershell
# 示例
npm install
npm run dev
npm test
```

## 四、验证矩阵与构建产物

项目必须把验证分层写清，任务文件再按改动范围引用对应层级。不要让 agent 自行猜测“相关测试”或“完整验证”分别包含什么。

| 层级 | 触发条件 | 命令 / 操作 | 通过证据 |
| --- | --- | --- | --- |
| 任务相关验证 | 每个任务必跑 | `【受影响模块的测试 / 静态检查 / 构建命令】` | 【退出码、测试数或关键断言】 |
| 完整门禁 | 发布前；修改共享契约、依赖、构建配置或跨模块基础设施时；或任务明确要求时 | `【全量测试 / 全量 lint / 发布构建命令】` | 【退出码、测试数、构建产物】 |
| 人工 / 设备验收 | 自动化无法替代的真机、硬件、外部账号、主观体验或受控环境验收 | `【操作步骤、执行角色、设备 / 环境】` | 【人工结论、截图 / 日志 / 记录位置】 |

- 任务相关验证不能省略；是否触发完整门禁，必须依据上表和任务验收要点判断，不要求所有小改动无差别跑全量。
- 必需的人工 / 设备验收未完成时，任务保持 `DOING` 或标为 `BLOCKED` 并写明等待事项，不得标记 `DONE`。
- 若构建产物需要部署、交接或比较新旧版本，记录产物路径、生成命令和项目选定的指纹（例如 SHA-256）；版本号不能单独证明部署的是本次构建。
- 标准启动 / 验证入口仍以根目录 `init.sh` 或 `init.ps1` 为准；本表负责说明不同验证层级何时触发。

## 五、依赖纪律

- 新增第三方依赖前，先说明用途、替代方案和维护成本。
- 不确定的技术选型先更新本文，再进入代码。
- 不允许同一职责并存两套框架或两套状态管理方案。