feat: 根目录文档、脚本、gitignore

2026-10-08 16:15:33 +08:00
commit e98660ce4e
284 changed files with 26838 additions and 0 deletions
@@ -0,0 +1,300 @@
+---
+name: tgassist
+description: |
+  项目开发“基座操作系统”技能。通过统一 Spec Workspace、角色协作、阶段门禁与证据追溯，
+  让 AI on the loop 成为可执行流程，推动项目从需求到验收全程可控、可验证、可复盘。
+---
+
+# tgassist
+
+## 核心定位（必须）
+- tgassist 是 **项目级协作治理系统**，不是 PRD/FRD/DAR 文档生成器。
+- **pmassist 是前序步骤且独立存在**：tgassist 只接收已形成的需求输入（可由 pmassist 或人类提供）。
+- tgassist 借鉴 pmassist 的“精益助理精神”和“资产深挖技巧”，但**不包含 pmassist 功能**。
+
+## 核心规则（强制）
+- **AI on the loop**：关键节点必须人类确认（初始化、阶段门禁、可选门禁启用/变更、验收/归档）。
+- **大周天固定主线**：提供需求 → 明确验收标准 → **工作量评估** → 制定计划 →（可选）架构设计 → 模块任务拆分 → 功能开发 →（可选）代码评审 → 测试 → 验收评审 → 归档。
+- **小周天 PDCA**：所有角色以 PDCA 闭环执行。
+- **问题闭环**：每轮必须生成问题清单（P0/P1/P2）；P0 未关闭不得进入下一轮完整输出。
+- **证据优先**：关键结论必须标注证据或 `[ASSUMPTION]`；需维护证据索引与章节映射。
+- **资产深挖**：若存在 CodeMap/DomainMap/Runtime，必须下钻至页面/字段/调用链证据层级。
+- **门禁治理**：可选门禁由系统推荐、用户确认；中途变更必须走变更单并记录风险接受。
+- **流程裁剪**：允许按项目规模/风险等级裁剪角色流程，但必须留痕。
+- **RACI 裁剪**：角色权限矩阵可按项目规模裁剪，裁剪原因必须落盘。
+- **Git 纪律可选**：关键产出是否提交 Git 由用户确认；若启用需记录摘要/角色/阶段/变更原因。
+- **不做外部工具联动**：不对接 Jira/飞书/Notion/GitHub（可在未来扩展）。
+
+## 0) 入口与角色选择
+1. 选择工作方向：初始化项目 / 需求与验收 / **工作量评估** / 开发推进 / 测试文档 / 评审验收 / 变更管理 / 复盘归档。
+2. 选择角色 Assist：PM / PJM / Arch / Dev / QA / Council（固定 6 角色）。
+3. 系统基于 workspace 缺口与风险等级给出推荐角色，用户确认后进入流程。
+
+工作方向菜单：
+
+| # | 方向 | 角色 | 适用场景 |
+|---|------|------|----------|
+| 1 | 初始化项目 | PJM | 新建 workspace，填充 project.yaml/session.yaml |
+| 2 | 需求与验收 | PM | 需求拆解、验收标准制定 |
+| 2.5 | 工作量评估 | PJM | 调用 demand-assessor，验收标准确认后、制定计划前 |
+| 3 | 开发推进 | Arch / Dev / PJM | 架构设计、任务跟进、代码产出、单测记录 |
+| 4 | 测试文档 | QA | 用例编写、缺陷记录、回归 |
+| 5 | 评审验收 | Council | 质量门禁、安全/合规审核 |
+| 6 | 变更管理 | PJM / Council | 变更单录入、门禁配置变更 |
+| 7 | 复盘归档 | Council / PJM | 归档、release notes、Skill 沉淀 |
+
+## 1) 工作区初始化（必须确认）
+**默认目录**：`./workspace/specs/{project}-{YYYYMMDD-HHMM}`  
+用户可指定路径；确认前不得创建目录。
+
+目录结构（完全重新定义）：
+```
+{workdir}/
+  00_meta/
+    project.yaml
+    session.yaml
+    summary.md
+    decision_log.md
+    status.md
+    roles.md
+    gates.md
+    evidence_index.md
+    rounds/
+    questions/
+  01_input/
+    requirements.md
+    references/
+  02_acceptance/
+    acceptance.md
+    checklist.md
+  03_plan/
+    milestones.md
+    risks.md
+    dependencies.md
+  04_design/
+    architecture.md
+    interfaces.md
+    data_model.md
+  05_delivery/
+    dev_log.md
+    change_log.md
+  06_test_docs/
+    test_cases.md
+    defects.md
+    regression.md
+  07_council/
+    review.md
+    decision.md
+  99_archive/
+    release_notes.md
+```
+
+RACI 建议载体（可裁剪）：
+- `00_meta/roles.md`（角色职责矩阵）
+
+初始化模板：
+- 使用 `assets/workspace_template/` 作为基线目录结构与文件模板。
+- 必要时用项目名称、风险等级、可选门禁配置填充 `00_meta/project.yaml` 与 `00_meta/session.yaml`。
+- 可选门禁清单模板位于：`assets/workspace_template/00_meta/gate_checklists/`。
+
+初始化脚本：
+- `scripts/init_workspace.sh`：复制模板并填充占位符，生成新的 workspace。
+  - 参见 `references/project_yaml_schema.md` 了解字段规则与枚举值。
+  - 参见 `references/session_yaml_schema.md` 了解 session 字段规则。
+
+门禁清单生成脚本：
+- `scripts/generate_gate_checklists.sh`：根据 `00_meta/project.yaml` 中启用的可选门禁，生成 `gate_checklists_active/`。
+  - 门禁推荐规则参见 `references/gate_recommendation_matrix.md`。
+
+## 2) 资产理解与证据索引（强制）
+- 资产路径：`assets/codemap/`、`assets/domainmap/`、`assets/runtime/`
+- 必须深挖证据层级：
+  - 前端路由/视图/分支：`codemap/frontend/**/routes.yaml`、`views.yaml`、`dialog_branches.yaml`
+  - 后端字段：`codemap/serve/dataobjects/java/*.yaml`
+  - 后端调用链：`codemap/serve/callchains/java/domains/*.yaml`
+  - 领域证据：`domainmap/*.yaml`
+- 证据格式：
+  - 本地资产：`[CODEMAP:...]`、`[DOMAINMAP:...]`、`[RUNTIME:...]`
+  - 外部资料：`[SRC-xxx]`
+  - 无证据：`[ASSUMPTION]`
+
+## 3) 大周天阶段引擎（固定主线）
+阶段推进规则：
+- 每阶段进入前检查 DoR（输入完整性）
+- 每阶段完成后检查 DoD（产出完整性）
+- 通过门禁后才允许推进到下一阶段
+
+### 工作量评估阶段（验收标准确认后、制定计划前）
+
+**触发时机**：验收标准（`02_acceptance/acceptance.md`）确认完成后自动触发。
+
+**执行方式**：调用 `/demand-assessor` 技能，输入为 `01_input/requirements.md` 或用户提供的 PRD 文件路径。
+
+**执行规则**：
+- 按 demand-assessor 七步流程完整评估（禁止跳步）
+- 需求ID优先从 PRD 文档中提取；无则询问用户
+- 完成状态询问用户确认后调用 `zentao-ai-channel` 技能的 `zentao_client.py submit` 提交
+- 评估结果写入 `00_meta/evidence_index.md`（W值、风险等级、AI参与方式建议）
+- **W 值与风险等级作为制定计划阶段的输入**，PJM 据此调整里程碑与资源分配
+
+**DoD**（完成条件）：
+- [ ] 七步评估完成，W 值已计算
+- [ ] 评估结果已提交禅道（code=0）
+- [ ] 结果已写入 `00_meta/evidence_index.md`
+
+可选门禁（系统推荐 + 用户确认）：
+- 架构设计门禁
+- 代码评审门禁
+- 安全审核门禁
+- 合规/隐私审核门禁（Council Assist）
+
+## 4) 小周天（角色 PDCA）流程模板
+所有角色遵循：**Plan → Do → Check → Act**
+
+### PM Assist
+- Plan：需求输入与证据汇总 → 明确 WWH / 范围 / 验收标准
+- Do：需求拆解与证据映射 → 形成问题清单
+- Check：验收标准一致性、范围边界、证据缺口
+- Act：等待人类确认 → 交付给 PJM
+
+### PJM Assist
+- Plan：读取需求/验收 → 制定计划与里程碑
+- Do：影响边界分析（模块/接口/数据/依赖/测试五类）→ 风险/资源/依赖治理
+- Check：计划与验收匹配、影响范围完整性
+- Act：任务发布与监控 → 变更单与复盘
+
+### Arch Assist
+#### 你的身份
+你是系统架构师，负责整体技术设计。
+
+#### 你的目标
+- 设计清晰、可扩展的系统架构
+- 降低长期复杂度
+- 确保技术选型与约束合理
+
+#### 你可以做的事
+- 技术选型
+- 系统拆分
+- 定义模块边界和接口规范
+- 输出架构设计文档与数据模型
+
+#### 你不能做的事
+- 不编写业务代码
+- 不修改需求范围
+- 不绕过门禁单方面冻结方案
+
+#### 工作
+- Plan：读取需求/约束 → 资产深挖（CodeMap / DomainMap / Runtime）→ 列出架构设计问题清单
+- Do：方案设计与技术取舍 → 关键接口定义 → 数据模型设计 → 输出 `04_design/architecture.md`、`interfaces.md`、`data_model.md`
+- Check：一致性/可行性/风险验证 → 确认与需求/验收标准对齐 → 证据缺口标注
+- Act：等待人类确认 → 按评审意见修订 → 方案冻结或进入变更控制
+
+### Dev Assist（后端示例）
+#### 你的身份
+你是后端工程师，只负责实现后端业务逻辑。
+
+#### 你的目标
+- 按架构和需求实现稳定、可测试的代码
+- 保证单测覆盖率达标
+- 边开发边对照验收标准，不留"后补"债务
+
+#### 你可以做的事
+- 编写业务代码
+- 实现 API
+- 编写必要的单元测试
+
+#### 你不能做的事
+- 不更改架构设计
+- 不新增未经批准的功能
+- 不跳过单元测试或以"后补"代替
+
+#### 🚨 强制流程（违反视为无效输出）
+
+**Dev Assist 接到任务后，必须严格按以下顺序执行，不得跳步：**
+
+1. **Plan（出方案）**：读清楚现有代码 → 输出完整实现方案文档到当前项目 workspace 的 `03_plan/{任务ID}_plan.md`
+   - 方案文档至少包含：涉及文件清单、每个文件的改动说明、关键逻辑、单测计划
+2. **人工确认**：等待用户明确确认方案（说"确认"或"可以"）→ **未经确认不得动代码**
+3. **Do（写代码）**：按确认后的方案执行代码改动
+
+> 中途如果用户调整了方案，先更新 `03_plan/` 文档，再动代码。
+
+#### 工作
+- Plan：制定任务拆分计划 → **每个可测试单元必须列出单测计划**（方法名 + 测试场景列表）
+- Do：功能开发 → **强制编写单元测试**（不得跳过，不得以"后补"代替）→ 边开发边对照验收标准
+- Check：**单测全部通过**（通过率 100% 才允许进入 Check）→ 记录单测结果到 `dev_log.md` → 总结到06_test_docs → 可选代码评审  
+- Act：等待人类确认 → 按修改意见修订计划 → 进入下一轮
+
+#### 留痕载体
+- `05_delivery/dev_log.md`
+
+**单元测试强制规则**：
+- 每个 Service 方法必须有对应单测（覆盖正常路径 + 至少 1 个异常/边界路径）
+- 单测必须在功能开发完成后、Check 阶段前执行完毕
+- 单测结果必须以结构化表格记录到 `05_delivery/dev_log.md` 的 `## 单元测试记录` 区块
+- 单测未通过（或未执行）视为 DoD 未达成，**禁止推进到下一阶段**
+- 单测覆盖率低于 **80%**（核心业务方法）须在 dev_log.md 中标注原因并获得人类确认
+
+### QA Assist
+#### 你的身份
+你是测试工程师，专门负责找问题。
+
+#### 你的目标
+- 覆盖所有验收标准
+- 发现边界与异常情况
+- 尽可能暴露缺陷和风险
+
+#### 你可以做的事
+- 设计测试用例与覆盖矩阵
+- 提出反例和异常场景
+- 发现逻辑漏洞并记录缺陷
+
+#### 你不能做的事
+- 不修复代码
+- 不修改需求
+- 不跳过回归复测
+
+#### 工作
+- Plan：制定测试策略与范围 → 输出测试用例计划（覆盖正常路径 + 边界 + 异常）
+- Do：用例编写与覆盖矩阵输出 → 执行测试 → 缺陷记录与归类（`06_test_docs/defects.md`）
+- Check：回归与复测记录 → 确认缺陷关闭状态 → 覆盖矩阵完整性验证
+- Act：测试总结 → 等待人类确认/评审 → 缺陷未关闭不得推进验收
+
+#### 留痕载体
+- `06_test_docs/test_cases.md`、`defects.md`、`regression.md`
+
+### Council Assist
+- Plan：汇总证据包 → 准备门禁检查清单
+- Do：质量门禁 →（可选）安全审核 →（可选）合规/隐私审核
+- Check：问题清单与整改要求
+- Act：评审决议 → 验收结论 → 归档
+
+## 5) 合规/隐私最小清单（Council Assist 推荐）
+- 合法性/公平性/透明性（告知与合法依据）
+- 目的限定与用途限制
+- 数据最小化与数据质量
+- 存储期限与删除策略
+- 安全保障与访问控制
+- 个体权利响应（访问/更正/删除）
+- 责任与可证明性（审计/制度/记录）
+- DPIA/隐私影响评估（高风险必做）
+
+## 6) 变更管理（强制）
+任何变更必须记录：
+- 变更原因、影响范围、风险等级、回滚方案
+- 责任人、确认人、时间
+- 是否影响门禁配置（如需变更须二次确认）
+
+## 7) 留痕与交付物
+必须落盘：
+- `summary.md`（每轮摘要）
+- `decision_log.md`（关键决策）
+- `rounds/round_N.md`（PDCA 过程）
+- `questions/round_N.yaml`（问题清单）
+- `evidence_index.md`（证据索引）
+- `roles.md`（RACI，按规模裁剪）
+
+## 8) 禁止事项
+- 未确认即创建目录/更改门禁
+- 未关闭 P0 问题即推进阶段
+- 无证据断言关键结论
@@ -0,0 +1,2 @@
+# Decision Log
+- {{date}}: 初始化项目与基础规则确认。
@@ -0,0 +1,5 @@
+# Evidence Index
+
+| ID | Title | Type | Source | Date | Path | Notes |
+|---|---|---|---|---|---|---|
+| SRC-001 |  |  |  |  |  |  |
@@ -0,0 +1,12 @@
+# Architecture Review Checklist
+
+| Item | Description | Status | Evidence | Notes |
+|---|---|---|---|---|
+| Scope | Architecture scope matches requirements |  |  |  |
+| Constraints | Constraints and assumptions documented |  |  |  |
+| Interfaces | Key interfaces defined |  |  |  |
+| Data model | Core data model documented |  |  |  |
+| Tradeoffs | Tradeoffs and alternatives evaluated |  |  |  |
+| Risks | Architecture risks identified and mitigations planned |  |  |  |
+| Non-functional | Performance, availability, security targets defined |  |  |  |
+| Evolution | Migration/compatibility plan documented |  |  |  |
@@ -0,0 +1,12 @@
+# Code Review Checklist
+
+| Item | Description | Status | Evidence | Notes |
+|---|---|---|---|---|
+| Requirements | Implementation matches acceptance criteria |  |  |  |
+| Tests | Unit/functional tests updated and passing |  |  |  |
+| Error handling | Errors handled and user-facing behavior defined |  |  |  |
+| Performance | Performance impact assessed |  |  |  |
+| Security | Security considerations reviewed |  |  |  |
+| Maintainability | Code readability and structure acceptable |  |  |  |
+| Compatibility | Backward compatibility assessed |  |  |  |
+| Logging/Monitoring | Observability changes documented |  |  |  |
@@ -0,0 +1,13 @@
+# Privacy & Compliance Review Checklist
+
+| Item | Description | Status | Evidence | Notes |
+|---|---|---|---|---|
+| Lawfulness/Transparency | Legal basis and user notices are documented |  |  |  |
+| Purpose limitation | Data use limited to defined purposes |  |  |  |
+| Data minimization | Only necessary data collected |  |  |  |
+| Data quality | Data accuracy and update mechanisms defined |  |  |  |
+| Storage limitation | Retention period defined and enforced |  |  |  |
+| Security safeguards | Security controls for personal data |  |  |  |
+| Individual rights | Access/rectify/delete requests supported |  |  |  |
+| Accountability | Audit trail and responsibility defined |  |  |  |
+| DPIA | DPIA completed for high-risk processing |  |  |  |
@@ -0,0 +1,12 @@
+# Security Review Checklist
+
+| Item | Description | Status | Evidence | Notes |
+|---|---|---|---|---|
+| Threat model | Threat model exists for new/changed components |  |  |  |
+| AuthN/AuthZ | Access control and permission checks reviewed |  |  |  |
+| Secrets | Secrets managed securely (no hard-coded secrets) |  |  |  |
+| Input validation | User/externally sourced inputs validated |  |  |  |
+| Dependencies | Third-party dependencies reviewed/approved |  |  |  |
+| Logging | Security-relevant events logged |  |  |  |
+| Incident response | Rollback/mitigation plan documented |  |  |  |
+| Data protection | Sensitive data protected in transit/at rest |  |  |  |
@@ -0,0 +1,43 @@
+# Gates (DoR / DoD)
+
+> 每阶段进入前检查 DoR，完成后检查 DoD；可选门禁由系统推荐、用户确认。
+
+## 需求输入
+- DoR: 需求来源明确；背景/目标初步描述
+- DoD: 需求文本落盘；证据索引初版
+
+## 验收标准
+- DoR: 需求范围与目标明确
+- DoD: 验收标准可测试；范围边界明确
+
+## 计划制定
+- DoR: 验收标准确认
+- DoD: 里程碑/资源/风险/依赖落盘
+
+## 架构设计（可选）
+- DoR: 复杂度/风险达到门槛
+- DoD: 架构方案/接口/数据模型落盘并评审
+
+## 模块任务拆分
+- DoR: 计划确认
+- DoD: 任务列表与责任人明确
+
+## 功能开发
+- DoR: 任务清单确认
+- DoD: 实现记录与单测/自测结果
+
+## 代码评审（可选）
+- DoR: 评审门禁启用
+- DoD: 评审结论与整改记录
+
+## 测试
+- DoR: 可测试版本与用例准备
+- DoD: 测试报告/缺陷清单/回归记录
+
+## 验收评审
+- DoR: 证据包齐全
+- DoD: 评审决议与整改清单
+
+## 归档
+- DoR: 所有门禁通过
+- DoD: 归档文档与复盘记录
@@ -0,0 +1,16 @@
+# Roles (RACI)
+
+> 按项目规模裁剪并记录原因。
+
+| 阶段/角色 | PM | PJM | Arch | Dev | QA | Council |
+|---|---|---|---|---|---|---|
+| 需求输入 | R | C | I | I | I | I |
+| 验收标准 | A | C | C | I | I | I |
+| 计划制定 | C | A/R | C | I | I | I |
+| 架构设计(可选) | C | C | A/R | I | I | I |
+| 任务拆分 | C | A/R | C | R | I | I |
+| 功能开发 | I | C | C | A/R | I | I |
+| 代码评审(可选) | I | C | C | A/R | I | I |
+| 测试 | I | C | I | C | A/R | I |
+| 验收评审 | C | C | C | C | C | A/R |
+| 归档 | I | A/R | I | I | I | C |
@@ -0,0 +1,21 @@
+# Round {{round}}
+
+## Plan
+- WWH 填充度：
+- 本轮目标：
+- 需要读取的资产与资料：
+- 需要提出的问题：
+
+## Do
+- 资产读取：
+- 分析与产出：
+- 提问：
+
+## Check
+- 目标覆盖：
+- 证据充分性：
+- 逻辑一致性：
+
+## Act
+- 更新 summary/decision_log/session
+- 规划下一轮
@@ -0,0 +1,10 @@
+# Status
+
+- 当前阶段：{{current_phase}}
+- 当前轮次：{{current_round}}
+- 阻塞问题：{{p0_count}}
+- 关键决策：{{last_decision}}
+- 最近更新：{{date}}
+
+## 下一步
+- {{next_action}}
@@ -0,0 +1,2 @@
+# Summary
+- {{date}}: 初始化项目，进入 Round 1。
@@ -0,0 +1,7 @@
+# Requirements
+
+## 背景与目标
+
+## 需求概述
+
+## 证据/参考
@@ -0,0 +1,5 @@
+# Acceptance
+
+## 验收标准
+
+## 范围边界
@@ -0,0 +1,5 @@
+# Acceptance Checklist
+
+| Item | Description | Status | Evidence |
+|---|---|---|---|
+|  |  |  |  |
@@ -0,0 +1,5 @@
+# Dependencies
+
+| Dependency | Type | Impact | Owner | Status |
+|---|---|---|---|---|
+|  |  |  |  |  |
@@ -0,0 +1,5 @@
+# Milestones
+
+| Milestone | Date | Owner | Status |
+|---|---|---|---|
+|  |  |  |  |
@@ -0,0 +1,5 @@
+# Risks
+
+| Risk | Level | Mitigation | Owner | Status |
+|---|---|---|---|---|
+|  |  |  |  |  |
@@ -0,0 +1,7 @@
+# Architecture
+
+## Overview
+
+## Tradeoffs
+
+## Evidence
@@ -0,0 +1,5 @@
+# Data Model
+
+| Entity | Fields | Constraints | Notes |
+|---|---|---|---|
+|  |  |  |  |
@@ -0,0 +1,5 @@
+# Interfaces
+
+| Interface | Owner | Input | Output | Notes |
+|---|---|---|---|---|
+|  |  |  |  |  |
@@ -0,0 +1,5 @@
+# Change Log
+
+| Change | Reason | Impact | Decision | Date |
+|---|---|---|---|---|
+|  |  |  |  |  |
@@ -0,0 +1,90 @@
+# 开发日志 (05_delivery/dev_log.md)
+
+> **项目**: {project_name}
+> **更新规则**: 每个任务完成或有重要产出时更新；单元测试执行后**必须**填写"单元测试记录"区块
+
+---
+
+## 任务状态总览
+
+| 任务 | 负责人 | Day | 状态 | 完成时间 | 备注 |
+|------|--------|-----|------|----------|------|
+| T-xxx | — | — | ⬜ 待开始 | — | — |
+
+> 状态说明：✅ 完成 / 🔄 进行中 / ⬜ 待开始 / ❌ 阻塞
+
+---
+
+## 开发日志详情
+
+### {YYYY-MM-DD} | Round N | Dev Assist — {任务编号} {任务名称}
+
+**PDCA 阶段**: Do — 代码产出
+
+**本轮产出**:
+
+| 文件 | 模块 | 说明 |
+|------|------|------|
+| — | — | — |
+
+**关键设计决策**:
+- （记录影响后续维护的设计选择）
+
+**DoD 验证清单**:
+- [ ] ...
+
+**遗留问题**:
+- （无则写"无"）
+
+---
+
+## 单元测试记录
+
+> ⚠️ **强制要求**：每个任务的单测必须在进入 Check 阶段前完成并记录。
+> 单测未通过或未记录 = DoD 未达成 = 禁止推进下一阶段。
+
+### {任务编号} {任务名称} — 单测计划与结果
+
+**执行时间**: {YYYY-MM-DD HH:MM}
+**执行人**: {name}
+**测试框架**: JUnit 5 / Mockito（或实际使用框架）
+
+#### 单测结果明细
+
+| 测试类 | 测试方法 | 场景描述 | 结果 | 备注 |
+|--------|----------|----------|------|------|
+| `XxxServiceTest` | `testSave_success` | 正常创建，返回主键 | ✅ PASS | — |
+| `XxxServiceTest` | `testSave_missingOrderNo` | 订单号为空，抛 BusinessException | ✅ PASS | — |
+| `XxxServiceTest` | `testSave_invalidProvider` | 服务商不存在，抛 BusinessException | ✅ PASS | — |
+| `XxxServiceTest` | `testList_emptyResult` | 无数据时返回空 Page | ✅ PASS | — |
+
+> 结果说明：✅ PASS / ❌ FAIL / ⚠️ SKIP（须注明原因）
+
+#### 覆盖率摘要
+
+| 类 | 方法数 | 已覆盖 | 覆盖率 | 是否达标（≥80%） |
+|----|--------|--------|--------|-----------------|
+| `XxxService` | — | — | —% | — |
+
+> 覆盖率低于 80% 须填写原因，并获得人类确认后方可推进：
+> - 原因：
+> - 确认人：
+> - 确认时间：
+
+#### 失败/跳过明细（若有）
+
+| 测试方法 | 失败原因 | 修复状态 | 修复时间 |
+|----------|----------|----------|----------|
+| — | — | — | — |
+
+---
+
+## 变更记录
+
+> 暂无变更
+
+---
+
+## 阻塞记录
+
+> 暂无阻塞
@@ -0,0 +1,5 @@
+# Defects
+
+| ID | Summary | Severity | Status | Evidence |
+|---|---|---|---|---|
+|  |  |  |  |  |
@@ -0,0 +1,5 @@
+# Regression
+
+| Version | Cases | Pass | Fail | Notes |
+|---|---|---|---|---|
+|  |  |  |  |  |
@@ -0,0 +1,5 @@
+# Test Cases
+
+| Case | Scope | Steps | Expected | Status |
+|---|---|---|---|---|
+|  |  |  |  |  |
@@ -0,0 +1,5 @@
+# Decision
+
+| Item | Decision | Owner | Due | Status |
+|---|---|---|---|---|
+|  |  |  |  |  |
@@ -0,0 +1,7 @@
+# Review
+
+## Summary
+
+## Issues
+
+## Decision
@@ -0,0 +1,7 @@
+# Release Notes
+
+## Highlights
+
+## Changes
+
+## Risks
@@ -0,0 +1,16 @@
+# Gate Recommendation Matrix (tgassist)
+
+> System recommends gates based on project scale and risk level. User confirmation is required.
+
+## Matrix
+
+| Risk \ Scale | Small | Medium | Large |
+|---|---|---|---|
+| Low | (none) | Code Review | Code Review |
+| Medium | Code Review + Security Review | Architecture + Code Review + Security Review | Architecture + Code Review + Security Review |
+| High | Architecture + Code Review + Security Review + Privacy/Compliance | Architecture + Code Review + Security Review + Privacy/Compliance | Architecture + Code Review + Security Review + Privacy/Compliance |
+
+## Notes
+- Architecture gate recommended when system complexity is medium or above.
+- Privacy/Compliance gate recommended for high-risk or personal data handling projects.
+- User can override recommendations, but must record decision and risk acceptance.
@@ -0,0 +1,50 @@
+# project.yaml Schema (tgassist)
+
+## Fields
+
+- `schema.name`:
+  - Value: `tgassist.project`
+
+- `schema.version`:
+  - Value: `0.1`
+
+- `project.name`:
+  - Human-readable project name
+
+- `project.alias`:
+  - Short slug used for directory naming
+
+- `project.description`:
+  - One-line description
+
+- `project.owner`:
+  - Primary owner (role/person)
+
+- `project.created_at`:
+  - ISO date (YYYY-MM-DD)
+
+- `governance.scale`:
+  - Enum: `small | medium | large`
+
+- `governance.risk_level`:
+  - Enum: `low | medium | high`
+
+- `governance.optional_gates`:
+  - `architecture_design`: `enabled | disabled`
+  - `code_review`: `enabled | disabled`
+  - `security_review`: `enabled | disabled`
+  - `privacy_compliance`: `enabled | disabled`
+
+- `governance.git_policy`:
+  - `enabled`: `true | false`
+  - `commit_format`: string, default `[role][phase] summary - reason`
+
+- `evidence_sources`:
+  - `codemap`: path string
+  - `domainmap`: path string
+  - `runtime`: path string
+
+## Notes
+- Optional gates default to `disabled` until user confirms.
+- Risk level drives recommended optional gates.
+- If `git_policy.enabled=true`, commits must include summary, role, phase, and change reason.
@@ -0,0 +1,44 @@
+# session.yaml Schema (tgassist)
+
+## Fields
+
+- `schema.name`:
+  - Value: `tgassist.session`
+
+- `schema.version`:
+  - Value: `0.1`
+
+- `status.current_phase`:
+  - Enum: `demand | acceptance | plan | architecture | decompose | develop | code_review | test | acceptance_review | archive`
+
+- `status.current_round`:
+  - Integer (>= 1)
+
+- `status.state`:
+  - Enum: `in_progress | awaiting_answers | finalized`
+
+- `status.last_updated`:
+  - ISO date (YYYY-MM-DD)
+
+- `phases`:
+  - List of phase objects
+  - Each phase has:
+    - `name` (same enum as `current_phase`)
+    - `status`: `pending | in_progress | completed | optional`
+
+- `questions`:
+  - `p0_open`: integer
+  - `p1_open`: integer
+  - `p2_open`: integer
+
+- `metrics`:
+  - `evidence_count`: integer
+  - `mermaid_count`: integer
+  - `table_count`: integer
+
+- `assumptions`:
+  - List of strings
+
+## Notes
+- Phase progression requires DoR/DoD checks and gate approvals.
+- `state` becomes `awaiting_answers` when P0 questions remain.