Jira 工作项、工作流与权限治理手册
Jira 的治理核心是工作项在明确空间、类型和工作流中流转。看板只是查询视图，颜色和列不能替代状态语义。Jira Cloud 当前使用 space 与 work item 等术语，旧资料中的 project 与 issue 仍可能出现在 API 和既有配置里；迁移或自动化时必须按目标实例实际字段核对。
先选择空间与管理模式
启用 Jira 时先判断 company-managed 与 team-managed 的责任边界。前者适合共享工作流、字段和权限方案，后者适合团队自治，但跨空间统一治理能力不同。试点使用隔离空间、测试群组和非生产通知，不能直接复制历史实例的全部自定义字段。
工作项类型只表达稳定业务对象，例如需求、缺陷和工程任务。组件、版本、标签与自定义字段各自承担正交维度；同一含义不应同时出现在类型、标签和状态里。
工作流是受控状态机
状态需要进入条件、退出条件和允许角色，transition 通过 condition、validator 与 post function 执行。Done 只有绑定 resolution、验收证据和必要的代码或发布链接时才有意义。
Open -> In Progress -> Ready for Review -> Done
\-> Blocked -> In Progress配置影响应在草稿工作流上验证，再发布到目标方案。共享工作流变更会影响多个空间，发布前查询关联范围；无法解释的全局修改应拆成新方案，不在原方案上试错。
字段和自动化需要消费者
字段只有被查询、验证、报告或集成消费时才值得存在。必填规则放在真正需要的 transition，而不是把创建页面变成问卷。自动化规则记录触发器、条件、actor、目标动作、幂等键和失败日志；全局规则拥有更大作用域，也会消耗执行容量。
触发：工作项进入 Ready for Review
条件：存在代码变更链接
动作：请求评审并记录 automation actor
失败：写入审计日志，保持原状态正向验证创建一条测试工作项，跑通字段校验、状态转换、通知和代码回链。反例由无权限用户尝试 transition、缺少验收字段时尝试关闭，预期稳定被拒绝。
权限方案与数据边界
Jira 权限分为站点或全局能力、空间权限方案、工作项安全以及工作流属性等层次。成员通过群组和空间角色取得权限，敏感工作项使用安全方案，不靠模糊标题隐藏。管理员、空间 owner、普通成员、访客和自动化身份分别验证搜索、阅读、编辑、转移与导出。
API Token 和应用凭证通过 secret 管理注入，自动化只访问必要空间。评论、附件、历史和通知同样可能含敏感数据；导出与日志要脱敏并限制保留期。
项目接入和运行证据
仓库分支、提交与 PR/MR 引用稳定工作项 key，构建和部署再回写不可变链接。合并不等于发布，发布不等于验收，不能用一个自动 transition 压平这些事实。Webhook 处理事件 ID、重试和乱序，回写动作保持幂等。
故障先查工作流条件与 validator，再查权限方案和自动化 actor。按钮不可见与 transition 被拒绝不是同一问题；规则执行成功但状态没变，则看目标字段、并发更新和审计日志。
清理、迁移与长期治理
清理字段前查询使用它的筛选器、看板、自动化和 API；归档空间前停止写入并保留只读查询。迁移需要验证工作项、关系、评论、附件、用户映射、权限和历史，不只比较行数。回滚配置时恢复方案版本，同时保留变更审计。
团队 owner 定期审查无消费者字段、长期停滞状态、全局自动化和管理员范围。成本与容量同时看活跃成员、自动化执行、附件、应用和管理复杂度。可解释的少量方案比无限定制更能支撑长期维护。