Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,63 +1,63 @@
|
||||
---
|
||||
title: "Jira Workflow Steward Agent Personality"
|
||||
type: source
|
||||
tags: ["project-management", "jira", "git-workflow", "delivery-traceability", "agent-personality"]
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/project-management/project-management-jira-workflow-steward.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Jira Workflow Steward——软件交付可追溯性管理 Agent，通过 Jira-Git 全链路绑定，确保每一次代码变更都能从 Jira 任务追踪到分支、提交、PR 直至关线发布
|
||||
- 问题域：团队代码交付过程中分支命名混乱、提交信息不规范、PR 缺乏 ticket 上下文、发布链路不可审计等交付治理难题
|
||||
- 方法/机制：Jira Gate（Jira ID 强制前置检查）→ 分支策略（feature/bugfix/hotfix/release 分流）→ Gitmoji 规范提交 → PR 模板 → Commit Hook 自动化验证
|
||||
- 结论/价值：使代码交付可审查、可回滚、可审计，将 Jira-linked commits 定位为质量工具而非合规打勾
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Jira Task ID 是所有 Git 工作流输出的前提：分支名、提交信息、PR 标题均必须包含有效 Jira ID，无 ID 则停止工作流
|
||||
- 分支策略需遵循仓库意图：feature/bugfix 从 develop 分支；hotfix 从 main 分支；release 用于发布准备，各路径互不混淆
|
||||
- 提交信息遵循 `<Gitmoji> JIRA-ID: 简短描述` 格式，选择 Gitmoji 需参照官方 catalog（gitmoji.dev / carloscuesta/gitmoji）
|
||||
- PR 是 main、release/*、大型重构和关键基础设施变更的强制门控，任何合并均需经过 review
|
||||
- 秘密/凭证/客户数据严禁出现在分支名、提交信息、PR 标题或描述中
|
||||
- Jira-linked commits 的价值在于提升 review 上下文、代码结构、发布说明质量和事故溯源能力，而非仅为合规
|
||||
|
||||
## Key Quotes
|
||||
> "If a change cannot be traced from Jira to branch to commit to pull request to release, you treat the workflow as incomplete." — 核心原则：可追溯性即质量
|
||||
> "Jira-linked commits as a quality tool, not just a compliance checkbox" — 提交绑定 Jira 的定位重塑：质量工具而非合规工具
|
||||
> "Protect repository clarity: the commit message should say what changed, not that you 'fixed stuff'." — 提交信息质量标准
|
||||
|
||||
## Key Concepts
|
||||
- [[Jira-Git-Traceability]]：通过 Jira ID 将 Jira 任务、分支、提交、PR、发布五个环节串联为完整可追溯链路的实践
|
||||
- [[Atomic-Commit]]：每次提交仅包含一个逻辑变更，易于审查、回滚和溯源的提交粒度原则
|
||||
- [[Branch-Strategy]]：基于功能/缺陷/热修复/发布类型的分支分层管理模型（feature/bugfix/hotfix/release）
|
||||
- [[Gitmoji-Commit]]：使用标准化 Emoji 前缀标注提交类型的提交规范（✨ 新功能、🐛 缺陷修复、♻️ 重构等）
|
||||
- [[Jira-Gate]]：强制要求所有 Git 工作流输出必须携带有效 Jira Task ID 的门控机制，无 ID 则停止工作流
|
||||
- [[Pull-Request-Governance]]：通过 PR 模板、安全审查、风险记录保护分支合并质量的工作流规范
|
||||
- [[Delivery-Traceability]]：从需求到代码发布全链路的可重建、可审计交付记录体系
|
||||
|
||||
## Key Entities
|
||||
- [[Gitmoji]]：标准化 Emoji 提交规范工具（来源：gitmoji.dev / carloscuesta/gitmoji）；Jira Workflow Steward 使用其作为提交类型的视觉标签
|
||||
- [[GitHub]]：PR 托管和分支策略执行平台；PR 模板和安全门控在此实现
|
||||
- [[Project-Management-Project-Shepherd]]：同为项目管理领域的 Agent；Project Shepherd 负责整体项目协调，Jira Workflow Steward 专注交付可追溯性，两者互补
|
||||
- [[Project-Management-Studio-Operations]]：同为 The Agency 项目管理层级中的 Agent；Studio Operations 负责运营流程，Jira Workflow Steward 负责技术交付链路
|
||||
|
||||
## Connections
|
||||
- [[Jira-Gate]] ← 是 [[Delivery-Traceability]] 的第一步门控
|
||||
- [[Branch-Strategy]] ← 支撑 [[Jira-Git-Traceability]] 的分支层
|
||||
- [[Atomic-Commit]] ← 支撑 [[Jira-Git-Traceability]] 的提交层
|
||||
- [[Pull-Request-Governance]] ← 支撑 [[Jira-Git-Traceability]] 的审查层
|
||||
- [[Gitmoji-Commit]] ← 提供 [[Atomic-Commit]] 的标准化视觉表达
|
||||
- [[Project-Management-Project-Shepherd]] ← 上游协调者，提供 Jira 任务；[[Jira-Workflow-Steward]] 负责将任务转化为可追溯代码交付
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Project-Management-Project-Shepherd]] 在职责边界上存在互补但需协调的张力：
|
||||
- 冲突点：Project Shepherd 生成 Jira 任务，Jira Workflow Steward 要求任务必须存在才能工作——两者均强调任务先行，但无主动对接机制
|
||||
- 当前观点：Steward 严格 gate，要求任务 ID 前置；若缺失则停止工作流并请求补充
|
||||
- 对方观点：Project Shepherd 可能期望 Agent 能自动创建或推断 Jira 任务 ID
|
||||
- 建议协调：在 Project Shepherd 的工作流中增加 Jira 任务预创建步骤，确保交接给 Steward 时 ID 已就绪
|
||||
- 与 [[Project-Management-Studio-Producer]] 在交付粒度上存在层级差异：
|
||||
- Studio Producer 关注组合级（Portfolio）ROI 和战略优先级，Jira Workflow Steward 关注原子级代码提交
|
||||
- 当前观点：Steward 坚持每个 commit 对应一个 Jira ID，保持最小粒度可追溯
|
||||
- 对方观点：Producer 可能在聚合分析时需要更高粒度的任务层级（Epic/Story vs Task）
|
||||
- 无直接冲突，属不同抽象层级的关注点差异
|
||||
---
|
||||
title: "Jira Workflow Steward Agent Personality"
|
||||
type: source
|
||||
tags: ["project-management", "jira", "git-workflow", "delivery-traceability", "agent-personality"]
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/project-management/project-management-jira-workflow-steward.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Jira Workflow Steward——软件交付可追溯性管理 Agent，通过 Jira-Git 全链路绑定，确保每一次代码变更都能从 Jira 任务追踪到分支、提交、PR 直至关线发布
|
||||
- 问题域：团队代码交付过程中分支命名混乱、提交信息不规范、PR 缺乏 ticket 上下文、发布链路不可审计等交付治理难题
|
||||
- 方法/机制：Jira Gate（Jira ID 强制前置检查）→ 分支策略（feature/bugfix/hotfix/release 分流）→ Gitmoji 规范提交 → PR 模板 → Commit Hook 自动化验证
|
||||
- 结论/价值：使代码交付可审查、可回滚、可审计，将 Jira-linked commits 定位为质量工具而非合规打勾
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Jira Task ID 是所有 Git 工作流输出的前提：分支名、提交信息、PR 标题均必须包含有效 Jira ID，无 ID 则停止工作流
|
||||
- 分支策略需遵循仓库意图：feature/bugfix 从 develop 分支；hotfix 从 main 分支；release 用于发布准备，各路径互不混淆
|
||||
- 提交信息遵循 `<Gitmoji> JIRA-ID: 简短描述` 格式，选择 Gitmoji 需参照官方 catalog（gitmoji.dev / carloscuesta/gitmoji）
|
||||
- PR 是 main、release/*、大型重构和关键基础设施变更的强制门控，任何合并均需经过 review
|
||||
- 秘密/凭证/客户数据严禁出现在分支名、提交信息、PR 标题或描述中
|
||||
- Jira-linked commits 的价值在于提升 review 上下文、代码结构、发布说明质量和事故溯源能力，而非仅为合规
|
||||
|
||||
## Key Quotes
|
||||
> "If a change cannot be traced from Jira to branch to commit to pull request to release, you treat the workflow as incomplete." — 核心原则：可追溯性即质量
|
||||
> "Jira-linked commits as a quality tool, not just a compliance checkbox" — 提交绑定 Jira 的定位重塑：质量工具而非合规工具
|
||||
> "Protect repository clarity: the commit message should say what changed, not that you 'fixed stuff'." — 提交信息质量标准
|
||||
|
||||
## Key Concepts
|
||||
- [[Jira-Git-Traceability]]：通过 Jira ID 将 Jira 任务、分支、提交、PR、发布五个环节串联为完整可追溯链路的实践
|
||||
- [[Atomic-Commit]]：每次提交仅包含一个逻辑变更，易于审查、回滚和溯源的提交粒度原则
|
||||
- [[Branch-Strategy]]：基于功能/缺陷/热修复/发布类型的分支分层管理模型（feature/bugfix/hotfix/release）
|
||||
- [[Gitmoji-Commit]]：使用标准化 Emoji 前缀标注提交类型的提交规范（✨ 新功能、🐛 缺陷修复、♻️ 重构等）
|
||||
- [[Jira-Gate]]：强制要求所有 Git 工作流输出必须携带有效 Jira Task ID 的门控机制，无 ID 则停止工作流
|
||||
- [[Pull-Request-Governance]]：通过 PR 模板、安全审查、风险记录保护分支合并质量的工作流规范
|
||||
- [[Delivery-Traceability]]：从需求到代码发布全链路的可重建、可审计交付记录体系
|
||||
|
||||
## Key Entities
|
||||
- [[Gitmoji]]：标准化 Emoji 提交规范工具（来源：gitmoji.dev / carloscuesta/gitmoji）；Jira Workflow Steward 使用其作为提交类型的视觉标签
|
||||
- [[GitHub]]：PR 托管和分支策略执行平台；PR 模板和安全门控在此实现
|
||||
- [[Project-Management-Project-Shepherd]]：同为项目管理领域的 Agent；Project Shepherd 负责整体项目协调，Jira Workflow Steward 专注交付可追溯性，两者互补
|
||||
- [[Project-Management-Studio-Operations]]：同为 The Agency 项目管理层级中的 Agent；Studio Operations 负责运营流程，Jira Workflow Steward 负责技术交付链路
|
||||
|
||||
## Connections
|
||||
- [[Jira-Gate]] ← 是 [[Delivery-Traceability]] 的第一步门控
|
||||
- [[Branch-Strategy]] ← 支撑 [[Jira-Git-Traceability]] 的分支层
|
||||
- [[Atomic-Commit]] ← 支撑 [[Jira-Git-Traceability]] 的提交层
|
||||
- [[Pull-Request-Governance]] ← 支撑 [[Jira-Git-Traceability]] 的审查层
|
||||
- [[Gitmoji-Commit]] ← 提供 [[Atomic-Commit]] 的标准化视觉表达
|
||||
- [[Project-Management-Project-Shepherd]] ← 上游协调者，提供 Jira 任务；[[Jira-Workflow-Steward]] 负责将任务转化为可追溯代码交付
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Project-Management-Project-Shepherd]] 在职责边界上存在互补但需协调的张力：
|
||||
- 冲突点：Project Shepherd 生成 Jira 任务，Jira Workflow Steward 要求任务必须存在才能工作——两者均强调任务先行，但无主动对接机制
|
||||
- 当前观点：Steward 严格 gate，要求任务 ID 前置；若缺失则停止工作流并请求补充
|
||||
- 对方观点：Project Shepherd 可能期望 Agent 能自动创建或推断 Jira 任务 ID
|
||||
- 建议协调：在 Project Shepherd 的工作流中增加 Jira 任务预创建步骤，确保交接给 Steward 时 ID 已就绪
|
||||
- 与 [[Project-Management-Studio-Producer]] 在交付粒度上存在层级差异：
|
||||
- Studio Producer 关注组合级（Portfolio）ROI 和战略优先级，Jira Workflow Steward 关注原子级代码提交
|
||||
- 当前观点：Steward 坚持每个 commit 对应一个 Jira ID，保持最小粒度可追溯
|
||||
- 对方观点：Producer 可能在聚合分析时需要更高粒度的任务层级（Epic/Story vs Task）
|
||||
- 无直接冲突，属不同抽象层级的关注点差异
|
||||
|
||||
Reference in New Issue
Block a user