.agents/skills/docs-lifecycle-manager/SKILL.md

@@ -1,116 +0,0 @@
----
-name: docs-lifecycle-manager
-description: Guide the emoon-backend team through its Docs as Code requirement lifecycle. Use when starting a new requirement, assigning or checking a feature_id, deciding the next document to produce, auditing lifecycle gaps, warning about skipped requirement/design/ADR/API/test documents, or acting as a document-based project manager before coding, testing, acceptance, or archive work.
----
-
-# Docs Lifecycle Manager
-
-Use this skill as the project-manager layer for requirements in this repository.
-It keeps a requirement moving through documented stages before the team jumps into code.
-
-## Required Context
-
-Always read these files first:
-
-1. `docs/文档中心.md`
-2. `docs/governance/文档分类.md`
-3. `docs/governance/元数据规范.md`
-4. `docs/governance/生命周期流程.md`
-
-If the user provides a `feature_id`, read:
-
-```text
-docs/initiatives/<feature_id>/专题索引.md
-```
-
-Then read every existing document referenced by that initiative index.
-
-## Lifecycle Order
-
-Use this order when inspecting or advancing a requirement:
-
-1. 需求录入：`需求录入.md`
-2. 需求文档：`需求文档.md`
-3. 概要设计：`概要设计.md`
-4. 详细设计：`详细设计.md`
-5. ADR: `docs/adr/ADR-*.md` when triggered
-6. 接口契约：`接口说明.md`、专题内中文接口文档，或 `docs/api/openapi/*.yaml` when triggered
-7. 开发进度：`开发进度.md` 或 `dev-progress/` 下的中文文件
-8. 测试计划：`测试计划.md`
-9. 测试结果：`测试结果.md`
-10. 归档：更新专题 `专题索引.md`
-
-Small changes may skip some stages only when the initiative `专题索引.md` records the skipped stage,
-reason, risk, replacement record, and whether follow-up is required.
-
-## Triage Procedure
-
-When the user asks what to do next:
-
-1. Identify or create the `feature_id`.
-2. Locate the initiative directory.
-3. Inventory existing lifecycle documents and their `status`.
-4. Compare the inventory against the lifecycle order.
-5. Check trigger conditions for mandatory ADR, API, security, and test documents.
-6. Report the current stage, missing prerequisites, next document, and warning if the requested action skips required context.
-
-Use this response shape:
-
-```text
-当前阶段：...
-已有文档：...
-缺口：...
-下一步：...
-建议动作：...
-警示：...
-```
-
-## Gate Rules
-
-Warn before continuing when any rule is violated:
-
-- No `feature_id`: do not create later-stage documents.
-- No `需求录入.md`: do not jump to detailed design or code.
-- No `需求文档.md`: do not start design.
-- PRD has no acceptance criteria: do not code.
-- Multi-module impact: require outline design or an explicit skip record.
-- Data model, security, exception handling, or deployment changes: require detailed design.
-- Module boundary, dependency direction, long-lived contract, middleware, or major tradeoff: require ADR.
-- External or frontend-facing interface change: require API document and OpenAPI when applicable.
-- No `测试计划.md`: do not claim completion.
-- No `测试结果.md`: do not mark the initiative `implemented`.
-
-## Document Creation
-
-Prefer repository templates under `docs/templates/`. New lifecycle document filenames must be Chinese and human-readable; keep `doc_id`, `type`, and lifecycle status in Front Matter instead of encoding them in English filenames:
-
-- `专题索引模板.md`
-- `需求录入模板.md`
-- `需求文档模板.md`
-- `概要设计模板.md`
-- `详细设计模板.md`
-- `接口说明模板.md`
-- `开发进度模板.md`
-- `测试计划模板.md`
-- `测试结果模板.md`
-- `会议纪要模板.md`
-
-When creating a document:
-
-1. Copy the relevant template structure.
-2. Fill Front Matter with `doc_id`, `feature_id`, `type`, `title`, `status`, `owner`, `created_at`, and `updated_at`.
-3. Link previous-stage documents in `related_docs`.
-4. Add affected code modules to `related_modules`.
-5. Update the initiative `专题索引.md` document index.
-
-## Output Rules
-
-Be strict about lifecycle gaps, but do not block useful exploration.
-
-If prerequisites are missing, offer one of three paths:
-
-- 补齐前置文档
-- 记录跳过原因后继续
-- 将当前任务降级为探索或草案
-
-Do not silently skip documentation stages.

.agents/skills/docs-lifecycle-manager/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Docs Lifecycle Manager"
-  short_description: "Guide a requirement through the team's Docs as Code lifecycle."
-  default_prompt: "Use this skill to inspect the current requirement documents, identify lifecycle gaps, and tell me the next document or decision to produce."

.agents/skills/requirement-lifecycle-manager/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: requirement-lifecycle-manager
+description: Guide the emoon-backend team through its Docs as Code and Git branch lifecycle. Use when starting or advancing a requirement, assigning or checking a feature_id, auditing document gaps, deciding whether work may enter development or merge, creating or checking docs/feature/hotfix/closeout branches, or coordinating requirement documents, reviews, tests, acceptance, and archive records with Git gates.
+---
+
+# Requirement Lifecycle Manager
+
+Act as the project-manager layer for requirements. Keep documents, lifecycle state, and Git branches aligned without imposing detailed commit conventions.
+
+## Required Context
+
+Always read:
+
+1. `docs/文档中心.md`
+2. `docs/governance/文档分类.md`
+3. `docs/governance/元数据规范.md`
+4. `docs/governance/生命周期流程.md`
+
+When explaining or operating the team workflow, also read `开发协作说明.md` in this skill directory.
+
+When a `feature_id` is known, read `docs/initiatives/<feature_id>/专题索引.md` and every existing document it references.
+
+Before any Git action, inspect the current branch, worktree, remotes, and divergence from `origin/master`. Do not treat a locally-ahead `master` as the stable baseline.
+
+## Document Lifecycle
+
+Inspect stages in this order:
+
+1. `需求录入.md`
+2. `需求文档.md`
+3. `概要设计.md`
+4. `详细设计.md`
+5. ADR when triggered
+6. API contract when triggered
+7. implementation plan and `开发进度.md`
+8. `测试计划.md`
+9. `测试结果.md`
+10. closeout in `专题索引.md`
+
+Allow a stage to be skipped only when the initiative index records the reason, risk, replacement record, and follow-up requirement.
+
+## Branch Lifecycle
+
+Use one shared feature branch per requirement:
+
+```text
+docs/FEAT-YYYYMM-NNN-short-name
+  -> master
+  -> feature/FEAT-YYYYMM-NNN-short-name
+  -> master
+  -> docs/FEAT-YYYYMM-NNN-short-name-closeout
+  -> master
+```
+
+- Protect `master`: never commit directly to it.
+- Prepare and review initial requirement documents on `docs/<feature_id>`.
+- Merge approved documents to `master` before development.
+- Create the shared `feature/<feature_id>` only after `ready_for_development` passes, from the recorded `origin/master` commit.
+- Let team members commit directly to the shared feature branch. Do not require task branches or detailed commit-message conventions.
+- Never rebase or force-push a published shared feature branch. Merge `master` into it when synchronization is needed.
+- Before final review, merge the latest `origin/master` into the feature branch and rerun required verification.
+- Merge `feature/<feature_id>` to `master` through a reviewed PR using a merge commit; do not squash or rebase.
+- After merge, use `docs/<feature_id>-closeout` to record the merge SHA, final status, test conclusion, and remaining issues. Then the remote feature branch may be deleted with explicit authorization.
+
+Feature branches must not merge into each other. Record cross-feature dependencies by `feature_id`; normally wait for the dependency to reach `master`. For necessary parallel verification, use a disposable `integration/<feature-a>-<feature-b>` branch that never merges directly to `master`.
+
+## Development Gate
+
+Treat `ready_for_development` as a hard gate. Require:
+
+- approved intake and PRD with acceptance criteria and non-goals;
+- all triggered outline design, detailed design, ADR, API, and security documents approved;
+- approved test plan and an actionable implementation plan;
+- no blocking unresolved question in the initiative index;
+- clean worktree and confirmed synchronization with `origin/master`;
+- proposed branch name and exact baseline commit SHA recorded in the initiative index.
+
+If the gate fails, do not create or push the feature branch. Report the missing prerequisites and offer to complete them, formally record a permitted skip, or keep the work exploratory.
+
+## Merge Gate
+
+Treat `ready_for_merge` as a hard gate. Require:
+
+- latest `origin/master` merged into the feature branch with no unresolved conflict;
+- requirements, acceptance criteria, implementation, and required documents aligned;
+- planned tests executed and `测试结果.md` records passes, failures, residual risks, and conclusion;
+- required Maven compile, module tests, and applicable `AiPlatformArchitectureTest` passed;
+- no blocking defect, security issue, or unresolved interface-contract difference;
+- human review of the feature-to-master PR.
+
+Do not use commit style, commit count, or history tidiness as merge gates.
+
+## Change, Pause, and Exception Rules
+
+- Keep minor implementation-time document corrections on the feature branch.
+- For material scope, acceptance, API, data, security, or architecture changes, pause affected implementation, update documents on the feature branch, and rerun the applicable gate.
+- Create a new `feature_id` when a change becomes an independent requirement.
+- Use initiative state `paused` for resumable work and keep its remote feature branch. On resume, synchronize `master` and revalidate documents and gates.
+- Use initiative state `cancelled` for abandoned work. Never merge incomplete code to `master`; normally delete its feature branch after preserving any explicitly required record.
+- For production emergencies, allow `hotfix/<short-name>` from `master` with a lightweight gate: incident description, fix scope, and verification result. Merge through PR, then backfill or link the appropriate `feature_id` records.
+
+## Git Authorization
+
+Read-only inspection and gate evaluation need no extra confirmation. Generating names and commands is also safe.
+
+Require explicit user authorization before creating a branch, committing, pushing, creating or merging a PR, deleting a branch, or otherwise changing remote state. Never automatically merge `master`, force-push, or delete a remote branch. A general instruction to advance the lifecycle authorizes ordinary safe steps, but obtain confirmation again for push, PR merge, and remote branch deletion.
+
+## Triage and Output
+
+When asked what to do next:
+
+1. Identify the `feature_id` and initiative.
+2. Inventory document types, statuses, required triggered artifacts, branch state, and recorded SHAs.
+3. Evaluate the current document stage and the applicable Git gate.
+4. Report the smallest next action and any prohibited transition.
+
+Use this response shape:
+
+```text
+当前阶段：...
+当前分支：...
+已有文档：...
+Gate 状态：...
+缺口：...
+下一步：...
+建议动作：...
+警示：...
+```
+
+## Document Creation
+
+Use templates under `docs/templates/`. Keep Chinese human-readable filenames; keep identifiers and lifecycle state in Front Matter. Fill `doc_id`, `feature_id`, `type`, `title`, `status`, `owner`, `created_at`, `updated_at`, related documents, and affected modules, then update `专题索引.md`.
+
+Never silently skip a document or Git gate.

.agents/skills/requirement-lifecycle-manager/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Requirement Lifecycle Manager"
+  short_description: "Coordinate requirements, documents, branches, and gates."
+  default_prompt: "Use $requirement-lifecycle-manager to inspect this requirement's lifecycle and Git state, evaluate its current gate, and identify the next safe action."

.agents/skills/requirement-lifecycle-manager/开发协作说明.md

@@ -0,0 +1,166 @@
+# 需求生命周期与 Git 协作说明
+
+本文面向开发同事和 AI，说明一个需求如何从提出、设计、开发、测试走到稳定分支。
+详细 Gate 规则以同目录的 [SKILL.md](SKILL.md) 和仓库
+[生命周期流程](../../../docs/governance/生命周期流程.md) 为准。
+
+## 核心原则
+
+- `master` 是稳定基线，禁止直接提交。
+- 一个需求使用一个 `feature_id` 和一个共享 feature 分支。
+- 需求和设计先进入 `master`，通过开发 Gate 后再拉 feature 分支。
+- 已推送的共享 feature 分支只允许 merge，不允许 rebase 或 force-push。
+- feature 分支通过测试和评审后，以 merge commit 合入 `master`。
+- 团队不强制普通提交格式、提交粒度或个人任务分支。
+
+## 完整生命周期
+
+```mermaid
+flowchart TD
+    A["提出需求并分配 feature_id"] --> B["docs/FEAT-... 编写需求、设计、测试与开发计划"]
+    B --> C{"文档评审通过?"}
+    C -->|否| B
+    C -->|是| D["通过 PR 合入 master"]
+    D --> E{"ready_for_development Gate"}
+    E -->|未通过| B
+    E -->|通过| F["从已记录的 origin/master SHA 创建 feature/FEAT-..."]
+    F --> G["团队在共享 feature 分支开发"]
+    G --> H["合入最新 origin/master 并执行测试"]
+    H --> I{"ready_for_merge Gate"}
+    I -->|未通过| G
+    I -->|通过| J["feature PR 以 merge commit 合入 master"]
+    J --> K["docs/FEAT-...-closeout 记录合并 SHA 与最终结论"]
+    K --> L["需求完成并删除远程 feature 分支"]
+```
+
+## 分支关系
+
+```mermaid
+gitGraph
+    commit id: "稳定 master"
+    branch docs/FEAT
+    checkout docs/FEAT
+    commit id: "需求与设计"
+    commit id: "测试与开发计划"
+    checkout main
+    merge docs/FEAT id: "文档评审通过"
+    branch feature/FEAT
+    checkout feature/FEAT
+    commit id: "开发提交 A"
+    commit id: "开发提交 B"
+    checkout main
+    commit id: "其他稳定变更"
+    checkout feature/FEAT
+    merge main id: "同步 master"
+    commit id: "测试结果"
+    checkout main
+    merge feature/FEAT id: "需求合并"
+    branch docs/FEAT-closeout
+    checkout docs/FEAT-closeout
+    commit id: "收尾记录"
+    checkout main
+    merge docs/FEAT-closeout id: "生命周期完成"
+```
+
+图中的 `main` 表示本仓库实际使用的 `master`。部分 Mermaid 渲染器将主线固定显示为
+`main`，不影响真实分支名称。
+
+## 分支命名
+
+| 用途 | 名称 |
+|---|---|
+| 需求和设计文档 | `docs/FEAT-YYYYMM-NNN-short-name` |
+| 共享开发 | `feature/FEAT-YYYYMM-NNN-short-name` |
+| 合并后收尾 | `docs/FEAT-YYYYMM-NNN-short-name-closeout` |
+| 生产紧急修复 | `hotfix/<short-name>` |
+| 跨需求临时联调 | `integration/<feature-a>-<feature-b>` |
+
+## 开始开发
+
+开发负责人确认 `ready_for_development` Gate 通过后，记录准确的
+`origin/master` 基线 SHA，再创建共享分支：
+
+```bash
+git fetch origin
+git switch master
+git pull --ff-only origin master
+git switch -c feature/FEAT-YYYYMM-NNN-short-name
+git push -u origin feature/FEAT-YYYYMM-NNN-short-name
+```
+
+创建分支和 push 必须获得明确授权。不要从尚未同步的本地 `master` 创建需求分支。
+
+## 日常开发
+
+首次拉取共享分支：
+
+```bash
+git fetch origin
+git switch --track origin/feature/FEAT-YYYYMM-NNN-short-name
+```
+
+已有本地分支时，在开始工作和 push 前同步团队提交：
+
+```bash
+git switch feature/FEAT-YYYYMM-NNN-short-name
+git pull --no-rebase origin feature/FEAT-YYYYMM-NNN-short-name
+```
+
+完成一个可工作的改动后正常提交和推送：
+
+```bash
+git add <本次相关文件>
+git commit -m "简要说明本次改动"
+git push origin feature/FEAT-YYYYMM-NNN-short-name
+```
+
+普通提交信息不要求固定前缀。不要使用 `git push --force`，也不要对已共享的 feature
+分支执行 rebase。
+
+## 同步 master
+
+最终评审前必须把最新稳定代码合入 feature 分支：
+
+```bash
+git fetch origin
+git switch feature/FEAT-YYYYMM-NNN-short-name
+git merge origin/master
+```
+
+解决冲突后重新执行改动模块的编译、测试和适用的架构测试。同步完成后再 push feature
+分支并发起 `feature/FEAT-... -> master` PR。
+
+## 两个硬 Gate
+
+### 进入开发 `ready_for_development`
+
+- 需求录入和 PRD 已批准，验收标准与非目标明确。
+- 必需的概要设计、详细设计、ADR、接口和安全文档已批准。
+- 测试计划已批准，开发计划可执行。
+- 没有阻塞性待确认项。
+- 已确认 `origin/master` 并记录基线 SHA。
+
+### 合入稳定分支 `ready_for_merge`
+
+- 已合入最新 `origin/master`，不存在未解决冲突。
+- 需求、设计、实现和接口契约一致。
+- 测试结果已记录，规定的编译、测试和架构检查通过。
+- 没有阻塞缺陷、安全问题或接口差异。
+- feature 到 master 的 PR 已通过人工评审。
+
+## 特殊情况
+
+- **需求暂停**：专题状态改为 `paused`，保留 feature 分支；恢复时重新同步
+  `master` 并检查 Gate。
+- **需求取消**：专题状态改为 `cancelled`，未完成代码不得合入 `master`。
+- **需求实质变化**：暂停相关实现，更新需求或设计并重新过 Gate；独立范围建立新的
+  `feature_id`。
+- **跨需求依赖**：feature 分支不得互相合并。依赖需求先合入 `master`；确需并行联调时
+  使用一次性 integration 分支，该分支不能直接合入 `master`。
+- **生产紧急修复**：使用 `hotfix/<short-name>`，至少记录故障、修复范围和验证结果，
+  仍通过 PR 合入 `master`，事后补齐需求记录。
+
+## AI 执行边界
+
+AI 可以自动检查文档、分支、工作区、远程同步状态和 Gate，也可以给出推荐命令。
+创建分支、提交、push、创建或合并 PR、删除远程分支前，必须获得用户明确授权。

.gitignore

@@ -62,8 +62,8 @@ openspec
 .agents/*
 !.agents/skills/
 .agents/skills/*
-!.agents/skills/docs-lifecycle-manager/
-!.agents/skills/docs-lifecycle-manager/**
+!.agents/skills/requirement-lifecycle-manager/
+!.agents/skills/requirement-lifecycle-manager/**
 
 back-info/*
 .env

AGENTS.md

@@ -16,9 +16,9 @@
 
 单上下文布局：`CONTEXT.md` + `docs/adr/`。详见 `docs/agents/domain.md`。
 
-### Docs lifecycle
+### Requirement lifecycle
 
-需求生命周期以 `docs/文档中心.md` 为总入口，并由 `.agents/skills/docs-lifecycle-manager/` 提供 Agent 执行规则。
+需求生命周期以 `docs/文档中心.md` 为总入口，并由 `.agents/skills/requirement-lifecycle-manager/` 提供 Agent 执行规则。
 当用户提出新需求、询问下一步、要求补需求/设计/ADR/API/测试文档、或准备跳过文档直接编码时，
 必须先按该生命周期检查当前阶段和缺口。
 
@@ -38,7 +38,7 @@
 
 | 场景 | 自动执行/提议的 Skill | 说明 |
 |------|---------------------|------|
-| 新需求录入/需求生命周期推进/询问下一步产出 | `docs-lifecycle-manager` | 先检查 `feature_id`、阶段文档和缺口 |
+| 新需求录入/需求生命周期推进/询问下一步产出 | `requirement-lifecycle-manager` | 先检查 `feature_id`、阶段文档、Git 分支和 Gate 缺口 |
 | 写新功能/新模块/新接口 | `tdd` | 先写测试→红→绿→重构 |
 | 修改现有代码/重构 | `tdd` + `review` | 先读现有测试，改代码，跑全量测试，再 review diff |
 | 用户要求审查代码 | `review` | 读取 diff，检查正确性/安全性/测试覆盖 |

docs/governance/元数据规范.md

@@ -66,6 +66,31 @@ source:
 | `deprecated` | 已废弃 |
 | `superseded` | 已被其他文档替代 |
 
+以上 `status` 用于单篇文档。专题索引还可以使用以下需求级状态：
+
+| 专题状态 | 含义 |
+|---|---|
+| `draft` | 需求或方案准备中 |
+| `reviewing` | 正在评审 |
+| `ready_for_development` | 开发 Gate 已通过 |
+| `developing` | 共享 feature 分支正在开发 |
+| `ready_for_merge` | 合并 Gate 已通过 |
+| `implemented` | 已合入稳定分支并完成收尾 |
+| `paused` | 暂停，允许后续恢复 |
+| `cancelled` | 已取消，不再合入未完成代码 |
+
+专题索引应使用独立字段记录 Git 状态，避免把分支信息塞入文档 `status`：
+
+```yaml
+baseline_branch: master
+baseline_commit:
+docs_branch:
+feature_branch:
+merge_commit:
+development_gate: pending
+merge_gate: pending
+```
+
 ## 规则
 
 - 标题不承载编号、日期和状态，这些信息放在 Front Matter。

docs/governance/生命周期流程.md

@@ -16,6 +16,58 @@
 12. 验收后创建或更新 `测试结果.md`
 13. 上线或交付后更新专题 `专题索引.md` 状态
 
+## 文档与 Git 分支联动
+
+`master` 是稳定基线，禁止直接提交。新需求使用以下主流程：
+
+```text
+docs/<feature_id> -> master
+master -> feature/<feature_id> -> master
+master -> docs/<feature_id>-closeout -> master
+```
+
+1. 在 `docs/<feature_id>` 完成需求、设计、测试计划和开发计划并通过 PR 合入 `master`。
+2. `ready_for_development` Gate 通过后，从已记录的 `origin/master` 提交创建并推送唯一的共享 `feature/<feature_id>` 分支。
+3. 团队成员直接向共享 feature 分支提交；不强制任务分支、提交格式或提交粒度。
+4. 已推送的共享 feature 分支禁止 rebase 和 force-push，只能通过 merge 同步 `master`。
+5. 最终评审前必须合入最新 `origin/master` 并重新执行规定验证。
+6. `ready_for_merge` Gate 通过后，以 PR 和 merge commit 合入 `master`，不 squash、不 rebase。
+7. 使用 `docs/<feature_id>-closeout` 更新合并 SHA、最终状态、测试结论和遗留项。
+
+### `ready_for_development` Gate
+
+- 需求录入和需求文档已批准，验收标准、非目标完整。
+- 按触发条件要求的概要设计、详细设计、ADR、接口和安全文档已批准。
+- 测试计划已批准，开发实施计划可执行。
+- 专题索引没有阻塞性待确认项。
+- 工作区干净，已确认与 `origin/master` 的同步关系。
+- 专题索引已记录分支名和准确的基线提交 SHA。
+
+Gate 未通过时不得创建或推送 feature 分支。
+
+### `ready_for_merge` Gate
+
+- feature 分支已合入最新 `origin/master`，没有未解决冲突。
+- 需求、验收标准、实现和必需文档一致。
+- 已执行测试计划，测试结果记录通过项、失败项、遗留风险和结论。
+- 改动模块的 Maven 编译、测试及适用的架构测试已通过。
+- 不存在阻塞缺陷、安全问题或未处理的接口契约差异。
+- feature 到 master 的 PR 已通过人工评审。
+
+提交格式、提交数量和历史整洁度不作为 Gate。
+
+### 并行、变更与异常
+
+- feature 分支不得互相合并。跨需求依赖记录 `feature_id`，依赖先进入 `master`；必要时使用不得直接合入 `master` 的一次性 `integration/<feature-a>-<feature-b>` 分支联调。
+- 普通调整在 feature 分支同步文档；范围、验收、接口、数据、安全或架构发生实质变化时，暂停相关实现、更新文档并重新过 Gate。
+- 暂停需求标记为 `paused` 并保留远程 feature 分支；恢复时同步 `master` 并重新检查 Gate。
+- 取消需求标记为 `cancelled`，未完成代码不得合入 `master`。
+- 生产紧急故障可从 `master` 创建 `hotfix/<short-name>`，最低要求为故障描述、修复范围和验证结果；仍通过 PR 合入，事后补齐或关联需求记录。
+
+### 自动化权限
+
+Agent 可以自动检查分支、工作区、远程同步状态、文档状态和 Gate，也可以生成推荐名称和命令。创建分支、提交、push、创建或合并 PR、删除分支及其他远程变更必须获得用户明确授权；不得自动合并 `master`、force-push 或删除远程分支。
+
 ## 评审规则
 
 | 文档 | 最低评审要求 |

docs/templates/专题索引模板.md

@@ -5,6 +5,13 @@ status: draft
 owner: 负责人
 created_at: YYYY-MM-DD
 updated_at: YYYY-MM-DD
+baseline_branch: master
+baseline_commit:
+docs_branch: docs/FEAT-YYYYMM-NNN-short-name
+feature_branch: feature/FEAT-YYYYMM-NNN-short-name
+merge_commit:
+development_gate: pending
+merge_gate: pending
 tags:
   - 标签
 ---
@@ -40,6 +47,18 @@ tags:
 
 记录当前推进状态、阻塞项和下一步动作。
 
+## Git 生命周期
+
+| 项目 | 记录 |
+|---|---|
+| 文档分支 | `docs/FEAT-YYYYMM-NNN-short-name` |
+| 稳定基线 | `master` / `<baseline_commit>` |
+| 共享开发分支 | `feature/FEAT-YYYYMM-NNN-short-name` |
+| 开发 Gate | `pending` |
+| 合并 Gate | `pending` |
+| 合并提交 | `<merge_commit>` |
+| 收尾分支 | `docs/FEAT-YYYYMM-NNN-short-name-closeout` |
+
 ## 流程裁剪
 
 | 阶段 | 是否跳过 | 原因 | 风险 | 替代记录 |