Jira、禅道与 TAPD 项目协作落地手册
看板全绿，发布现场却没有人敢签字
支付回调改造准备上线时，项目看板上的需求已经“完成”，缺陷也全部“关闭”。发布经理追问验收证据，才发现需求只关联到开发任务，没有关联测试用例；缺陷由开发者修复后直接关闭，没有经过测试验证；一个关键字段在中途改名，自动化仍向旧字段写值；真正阻塞上线的外部依赖只存在于聊天记录。平台统计没有撒谎，它只是忠实汇总了团队随手点击的状态。
Jira、禅道和 TAPD 都能管理需求、缺陷、迭代和人员。困难不在于创建第一张卡片，而在于让卡片状态代表真实工程事实：谁可以推动状态，流转前必须补齐什么证据，代码与发布如何回链，机器人失败后怎样重放，离开平台时能否带走对象、历史和附件。
先准备一个可删除的试点项目、三个测试身份和一条虚构业务链路：pm-lab 维护需求，dev-lab 处理任务，qa-lab 验证缺陷；集成使用单独的 bot-lab。测试标题统一带 COLLAB-LAB-7F3A，描述只写合成数据。真实客户名称、生产日志、Token、Cookie、内网地址和未公开漏洞都不进入试点。
先认清三套对象模型
三家界面都能画看板，但对象边界并不相同。错误映射会在统计、权限和迁移时集中暴露。
| 工程概念 | Jira | 禅道 | TAPD | 建模提醒 |
|---|---|---|---|---|
| 管理容器 | Cloud 中逐步称为 space，API 仍普遍使用 project | 产品、项目、执行是不同层级 | 项目在 API 中以 workspace 表示 | 不要把名称相似当成同一语义 |
| 需求 | Epic、Story 或自定义 work type | 需求归产品规划，再关联项目与执行 | story，可有父子层级和需求类别 | 需求完成与上线验收分开 |
| 开发工作 | Task、Subtask | 任务归执行，可关联需求 | task，可关联需求与迭代 | 任务关闭不能自动证明需求交付 |
| 缺陷 | Bug work type | Bug 与产品、项目、执行、版本相关 | bug，有独立工作流与版本字段 | 修复、验证、关闭是不同动作 |
| 时间盒 | Sprint | Scrum 项目通常以执行承载冲刺或迭代 | iteration | 移入迭代不等于承诺一定交付 |
| 发布对象 | Version / Release | 版本、发布 | release | 代码合并、构建、部署、验收分别留证 |
| 状态机制 | workflow、status、transition、resolution | 各对象动作和状态，增强版可提供更强流程配置 | 需求与缺陷工作流、节点和结束状态 | 状态名、状态类别和结束语义不能混用 |
Jira Cloud 的界面术语正在从 issue/project 迁移到 work item/space，但 REST API v3 仍使用 /issue、project、issuetype 等名称，JQL 也保留既有语法。自动化字段契约应锁定 API 字段 ID 和对象 ID，不能跟着界面翻译批量改名。Jira 术语迁移与 JSON 导入说明明确提醒部分新术语尚未覆盖所有查询入口。
禅道的产品回答“做什么”，项目表达交付过程，执行承载具体冲刺、阶段或看板活动。项目和执行的访问控制相互独立，能访问一方不保证能访问另一方；执行中的需求、Bug、团队等又会汇总到项目。这个关系直接影响权限实验和导出计数，详见项目与执行的数据和访问控制。
TAPD API 把项目写成 workspace_id，需求写成 story。需求的 status、module、iteration_id 等候选值由项目配置决定，不能把某个试点项目里的中文状态或内部枚举复制到所有项目。需求对象字段说明要求通过字段候选值接口读取动态配置。
选择一个可回收的启用入口
Jira：Cloud 试点与 Data Center 是两条责任线
Jira Cloud 适合快速建立租户和试点空间，由 Atlassian 负责服务端运行；团队负责组织身份、产品访问、空间配置、数据分级和集成。创建站点后，先在目标租户的Jira 产品与方案页核对成员、自动化、审计、数据治理和支持能力，不能根据旧截图推断套餐边界。
Cloud 空间有 team-managed 与 company-managed 两类。前者把配置权下放给空间管理员，配置通常不跨空间复用；后者由 Jira 管理员维护 workflow、screen、field configuration 与 permission scheme，适合多团队统一字段和流程。两类空间的官方对比是创建前必须阅读的迁移约束。需要跨产品统一报表、共享流程和集中权限时，从 company-managed 试点开始；单一自治团队验证流程时，team-managed 更轻。
Jira Server 已退出支持，自托管新部署应评估 Data Center。单节点可以验证功能，集群则还需要负载均衡、共享 home、每节点 local home、外部数据库、索引一致性、备份恢复和 Data Center 许可。Data Center 安装入口与目标版本的supported platforms必须一起核对。容器或 Helm 只改变交付方式，不减少数据库、共享存储、升级和灾备责任。
禅道：云服务快速验证，自托管控制数据面
云禅道适合不想维护 PHP、数据库、附件和升级链的团队；私有部署适合网络隔离、数据驻留或深度集成要求明确的组织。开源版、企业版、旗舰版和 IPD 版的流程、导入导出、身份集成与治理能力不同，应从版本与产品入口按真实需求核验，不把某个增强版能力写成所有版本共有。
自托管实验优先使用官方容器镜像，并固定经过审批的 tag；latest 只用于发现新版本。官方当前容器指南覆盖 Docker、Compose 与 Kubernetes，并列出 hub.zentao.net/app/zentao 镜像和架构支持，入口见容器化部署手册。一个只监听本机的可删除实例可以这样启动：
export ZENTAO_TAG='<approved-tag>'
docker pull "hub.zentao.net/app/zentao:${ZENTAO_TAG}"
docker volume create zentao-lab-data
docker run -d --name zentao-lab \
--restart unless-stopped \
-p 127.0.0.1:8088:80 \
-v zentao-lab-data:/data \
-e MYSQL_INTERNAL=true \
"hub.zentao.net/app/zentao:${ZENTAO_TAG}"
docker logs --tail 100 zentao-lab
curl -I http://127.0.0.1:8088/预期容器保持运行，浏览器进入初始化向导，HTTP 响应不再是连接拒绝。反复重启或 500 时先看容器日志和 /data 权限，再检查 tag 对应的架构与升级要求。内置数据库适合实验；生产需要把数据库、附件、备份恢复、邮件和反向代理纳入正式架构评审。初始化管理员使用临时强密码，首次登录后创建普通管理组，不让根管理员成为日常机器人。
TAPD：SaaS 是主入口，私有部署按合同验收
TAPD 的常见入口是官网注册企业并创建项目，服务端无需在开发机安装。由公司管理员创建 COLLAB-LAB 项目，启用需求、迭代和缺陷应用，再邀请 pm-lab、dev-lab、qa-lab。TAPD 也提供私有部署，但功能更新节奏、运维投入和可用能力可能不同；产品与方案页明确要求私有部署通过商务入口评估。采购时现场核对成员、项目、自动化、API、审计、存储、身份管理、导出和终止后取回数据的条款，不在架构记录里写死价格。
在 Jira 跑通一条受控需求链
建立空间、工作类型和字段
在 company-managed 试点中创建 COLLAB 空间，先保留 Story、Task、Bug 三种工作类型。字段只保留会参与决策或查询的事实：
| 字段 | 消费者 | 校验时机 |
|---|---|---|
| Summary | 所有人与搜索 | 创建时必填 |
| Assignee | 当前处理责任 | 进入进行中前必填 |
| Acceptance Evidence | 产品与测试 | 进入待验收前必填 |
| Code Change | 开发与发布 | 开发完成前写 PR/MR 或提交链接 |
| Release Evidence | 发布与审计 | 关闭前写构建或发布对象 ID |
| Resolution | 报表与归档 | 只在结束 transition 设置 |
Jira 的字段显示受 field context、field configuration 和 screen 共同影响：字段存在，不代表当前工作类型能看到；能看到，也不代表可编辑或必填。优先复用少量全局字段，并用受限 context 控制适用空间与工作类型。开放文本会产生 已验收、验收完成 等同义脏值，需要统计的字段使用受控选项。自定义字段配置说明解释了集中字段与 team-managed 本地字段的差异。
让 transition 承载规则
把 Story 工作流配置为：
Backlog -> In Progress -> In Review -> Ready for Acceptance -> Done
\-> Reopened <----------------------/transition 是动作，status 是动作后的状态。进入 In Progress 要求 Assignee；进入 In Review 要求 Code Change；进入 Ready for Acceptance 只表示代码证据齐备；进入 Done 要求 qa-lab 或验收角色填写 Acceptance Evidence，并由 transition 设置 Resolution。重开时清除 Resolution，否则 JQL 和完成统计会把一个已重开的工作项继续当作已解决。
Jira workflow 可以配置条件、校验器、触发器和后置动作；workflow scheme 再把不同 work type 映射到流程。workflow 与 scheme 管理说明适合用来检查共享流程的影响范围。修改活跃共享流程前先复制、在试点空间发布并检查草稿差异，避免一次字段规则变更阻塞所有团队。
用 UI 和 API 做正反实验
先让 pm-lab 创建 Story COLLAB-LAB-7F3A 支付回调幂等，写明合成验收条件；dev-lab 接单后关联一个虚构 PR URL；qa-lab 填写验收证据并关闭。预期历史页按顺序记录字段与状态变化，Done 时 Resolution 非空，重开后 Resolution 为空。
随后制造稳定失败：删除 Code Change，尝试从 In Progress 进入 In Review。预期 transition 被拒绝，界面指出缺少字段；历史中不应出现目标状态。若仍能流转，说明校验器未绑定到实际使用的 workflow、字段 screen 不可见，或工作类型被另一个 scheme 映射。
个人临时探测可以使用邮箱加 API token；团队集成优先 OAuth 2.0 3LO 或受管应用身份，并按操作申请最小 scope。API token 只从密钥存储注入：
export JIRA_BASE_URL='https://<tenant>.atlassian.net'
export JIRA_EMAIL='<bot-account@example.invalid>'
export JIRA_API_TOKEN='<inject-from-secret-store>'
export JIRA_KEY='COLLAB-1'
curl --fail-with-body --silent --show-error \
--user "$JIRA_EMAIL:$JIRA_API_TOKEN" \
--header 'Accept: application/json' \
"$JIRA_BASE_URL/rest/api/3/issue/$JIRA_KEY?expand=changelog" \
| jq '{key, status: .fields.status.name, resolution: .fields.resolution, histories: (.changelog.histories | length)}'
curl --fail-with-body --silent --show-error \
--user "$JIRA_EMAIL:$JIRA_API_TOKEN" \
--header 'Accept: application/json' \
"$JIRA_BASE_URL/rest/api/3/issue/$JIRA_KEY/transitions" \
| jq '.transitions[] | {id, name, to: .to.name}'预期第一条返回稳定 key、当前状态、resolution 与变更历史数量，第二条只列当前身份此刻允许执行的 transition。401 指向凭据，403 指向权限或应用 scope，404 还可能表示调用方没有 Browse space 权限而看不到对象。REST API v3 的认证、ADF 字段和权限语义见官方 API 入口。
权限、自动化和审计
全局权限决定谁能管理 Jira 或批量操作；space permission scheme 决定浏览、创建、编辑、transition、指派等动作；work item security 再限制单条敏感工作项可见性。优先给组和项目角色授权，不把个人塞进 scheme。dev-lab 可以编辑开发字段，却不能关闭验收 Story；qa-lab 可以执行验收 transition，却不能修改 workflow；bot-lab 只能浏览试点空间和更新指定字段。Jira 权限层级还指出部分权限方案和安全能力受目标方案影响。
自动化规则使用“transition 成功”“PR 合并”“构建完成”等事件，不使用“有人发了一条消息”作为真相。每条规则记录触发对象 ID、规则 ID、执行结果和失败原因；规则配额、跨空间执行、审计留存和服务限额从目标租户的自动化限制说明与方案页核对。Jira 管理审计日志聚焦配置和权限等管理变化，并不等于完整业务操作历史；可见事件与留存能力见审计活动说明。
在禅道跑通产品到执行的交付链
按产品、项目、执行建模
创建产品 Payment Lab，产品负责人为 pm-lab，测试负责人为 qa-lab；访问控制设为私有并明确白名单。再创建 Scrum 项目 Callback Reliability Lab，关联该产品，创建执行 Iteration Lab A。需求先进入产品，经评审后关联到项目和执行；任务在执行中分解；Bug 关联产品、影响版本、相关需求和执行。
最小链路是：
产品需求 -> 项目范围 -> 执行/迭代 -> 开发任务 -> 构建 -> 测试 -> Bug -> 版本/发布不要为了模仿 Jira 把产品、项目和执行压成一个容器。产品需求可以跨项目实现，项目可以包含多个执行；删除关联和删除对象的后果也不同。创建产品时还要检查访问控制与白名单，产品创建说明给出了负责人、测试负责人和权限入口。
字段配置从“谁消费”开始。需求保留验收标准、评审结果和所属计划；任务保留关联需求、负责人、预计与剩余工时；Bug 保留影响版本、重现步骤、严重程度、解决方案、解决版本和验证结果。禅道允许调整需求概念、必填项、状态和评审规则，但关闭某类需求能力可能移除项目与执行中的关联，属于数据迁移动作，不是界面开关。产品功能配置说明明确提示部分关闭操作不可逆。
用角色动作验证状态
pm-lab 创建研发需求 COLLAB-LAB-7F3A 支付回调幂等，验收标准写“同一幂等键重复请求只产生一个业务结果”；项目经理把需求关联到执行并分解任务；dev-lab 开始、完成任务并提交测试；qa-lab 创建测试单，执行失败时转 Bug，由开发解决后再由测试验证关闭。
预期需求、任务、Bug 和测试结果仍是独立对象，但能沿关联关系互相追踪；项目视图汇总执行数据，执行视图保留本次迭代的责任。Bug 的“已解决”表示开发给出解决方案，不等于测试验证通过。
反向实验分两步。第一步，把 dev-lab 移出执行团队但保留项目成员，尝试修改执行任务；预期因执行权限独立而被拒绝或不可见。第二步，让开发者在没有测试验证时尝试直接关闭 Bug；预期角色权限或动作规则阻止关闭。若两步都成功，检查项目权限分组、执行团队、白名单、受限用户组和对象动作权限，而不是把账号升级成管理员。项目团队和权限维护展示了团队、白名单、干系人与权限分组入口。
API 只继承调用账号能看到的事实
RESTful API v1 从 www/api.php 进入。先用专用实验账号换取短期 Token，再读取产品下的 Bug；不要使用根管理员，也不要把密码写进 Shell history：
export ZENTAO_BASE_URL='http://127.0.0.1:8088'
export ZENTAO_ACCOUNT='bot-lab'
read -rsp 'ZenTao lab password: ' ZENTAO_PASSWORD
echo
ZENTAO_TOKEN="$({
jq -n --arg account "$ZENTAO_ACCOUNT" --arg password "$ZENTAO_PASSWORD" \
'{account: $account, password: $password}'
} | curl --fail-with-body --silent --show-error \
-X POST "$ZENTAO_BASE_URL/api.php/v1/tokens" \
-H 'Content-Type: application/json' --data-binary @- \
| jq -r '.token')"
unset ZENTAO_PASSWORD
curl --fail-with-body --silent --show-error \
"$ZENTAO_BASE_URL/api.php/v1/products/<product-id>/bugs" \
-H "Token: $ZENTAO_TOKEN" \
-H 'Content-Type: application/json' \
| jq '{page, total, bug_ids: [.bugs[].id]}'
unset ZENTAO_TOKEN预期返回分页信息和该账号有权查看的 Bug。{"error":"not found"} 首先检查 URL 与路由；空数组同时可能表示产品 ID 错、没有 Bug 或调用账号无权限。用管理员界面确认对象存在，再用 bot-lab 对照，才能区分数据为空与权限过滤。RESTful API 配置和故障说明给出了 Token 与产品 Bug 的同类调用。
长期集成要把 Token 获取、撤销与账号停用纳入密钥轮换。日志只记录 endpoint 模板、HTTP 状态、对象 ID、分页和请求耗时，不记录 Token、密码、需求正文或缺陷附件。增强版工作流、Excel 导入、LDAP 和审计能力需要按安装版本逐项验证；插件可用不等于当前许可已包含。
备份与清理是自托管的一部分
停止实验前先导出 COLLAB-LAB-7F3A 对象并记录 ID，再做数据库与附件备份。升级时使用原数据卷、经过验证的新镜像 tag 和可恢复备份；官方Docker 升级说明要求升级前备份并核验版本日志。实验完全结束后按依赖清理：
docker rm -f zentao-lab
docker volume rm zentao-lab-data删除 volume 会永久清除数据库和附件，只能在确认导出证据不再需要、容器名与 volume 名都属于实验后执行。若试点已被项目引用，先停止机器人写入、切回旧平台链接并验证，再归档实例，不能直接删卷。
在 TAPD 跑通需求、迭代与缺陷闭环
项目配置先于卡片创建
在 COLLAB-LAB 项目中启用需求、迭代和缺陷。需求工作流设置为“规划中 -> 实现中 -> 待验收 -> 已完成”，缺陷设置为“新建 -> 处理中 -> 已解决 -> 已验证 -> 已关闭”。结束状态必须在项目设置里明确，API 也提供获取工作流起始、结束状态和工作流列表的入口，见TAPD API reference。
为需求增加受控字段 验收证据 与 代码变更，为缺陷增加 验证版本 与 失败证据。自定义字段的内部名可能表现为 custom_field_N，集成必须先读取字段中英文、候选值和配置，再建立“业务字段 -> 平台字段 ID”映射。禁止在代码里猜 custom_field_1 永远代表同一含义。
成员与权限按角色分配：产品角色创建与评审需求，开发角色更新实现字段和解决缺陷，测试角色验证与关闭，项目管理员维护工作流和字段。保密需求、字段保护、流程校验、自动化规则数和审计能力可能受方案影响，从目标项目界面与管理员手册确认实际生效项。
正向闭环与权限反例
pm-lab 创建需求 COLLAB-LAB-7F3A 支付回调幂等 并放入 Iteration Lab A；dev-lab 领取关联任务、填写虚构代码链接，转入待验收；qa-lab 执行验收。若发现重复回调，创建关联缺陷，写清合成重现步骤、影响版本和期望结果；开发解决后填写合入版本，测试在验证版本通过后关闭。
预期需求能追到任务、迭代和缺陷，缺陷历史能区分解决人与验证人，结束状态只在证据齐备后到达。随后让 dev-lab 尝试直接把缺陷从处理中关闭，并让 qa-lab 修改工作流。两个动作都应被拒绝；失败页面、操作者、对象 ID 和动作进入实验记录。成功反而是权限缺口，需要收紧角色动作和管理员范围。
用应用身份读取真实候选值
TAPD 企业 API 账号可使用 HTTP Basic Auth，开放应用还可通过 OAuth 获得 Bearer token；不同接口支持的身份模式并不完全相同。长期跨系统集成优先使用可限定 scope、安装范围和安全 IP 的应用身份。开放应用 API 用法说明了 access token、应用权限和安全 IP 约束。
读取试点需求时只取需要的字段，并处理分页：
export TAPD_ACCESS_TOKEN='<inject-from-secret-store>'
export TAPD_WORKSPACE_ID='<lab-workspace-id>'
curl --fail-with-body --silent --show-error \
--get 'https://api.tapd.cn/stories' \
--header "Authorization: Bearer $TAPD_ACCESS_TOKEN" \
--data-urlencode "workspace_id=$TAPD_WORKSPACE_ID" \
--data-urlencode 'fields=id,name,status,iteration_id,owner,modified' \
--data-urlencode 'limit=30' \
--data-urlencode 'page=1' \
| jq '{status, info, stories: [.data[].Story | {id, name, status, iteration_id, owner}]}'预期顶层 status 为成功语义，data 中只出现授权项目内的需求。HTTP 200 但业务 status 非成功仍是失败；空数据要依次检查 workspace、应用安装范围、scope、筛选字段和分页。若使用企业 API 账号，则按Basic Auth 配置指引从密钥存储注入 api_user 与 api_password，不得把 Base64 当作加密。
Webhook 至少携带事件 ID 或可推导幂等键，接收端验证来源、限制重放，并对同一对象的旧事件做版本判断。TAPD 的 webhook 申请、事件类型和验证密码以Webhook 文档为入口核验。不能稳定取得 webhook 时，使用 modified 游标轮询加周期全量对账，不能靠浏览器 Cookie 抓取页面。
把平台接进真实项目
平台工作项不是代码仓库的替代品。仓库保存可评审和可构建的事实，协作平台保存为什么做、由谁推进、当前处于什么业务状态。团队可以建立下面的最小字段契约：
work_item_contract:
stable_id: platform-native-id
type: requirement | task | defect
owner: exactly-one-current-owner
state: controlled-workflow-state
acceptance_evidence: required-before-business-done
code_change: repository-and-pr-id
build_evidence: immutable-build-id
release_evidence: environment-and-release-id
close_reason: completed | duplicate | cancelled | rejected提交和 PR/MR 引用稳定 key，例如 COLLAB-142；CI 从分支、提交或 PR 元数据读取 key，调用只读 API 确认对象存在且类型允许，再把构建 ID 回写到专用字段。部署系统回写 release ID 和环境，不回写完整日志。事故工单反向链接到原需求和发布对象，才能判断是实现缺陷、验收遗漏还是范围变化。
自动化采用“事件日志 + 幂等处理 + 周期对账”三层：
平台事件 -> 验签与去重 -> 对象读取 -> 规则判断 -> 目标写入
\-> 失败队列 -> 人工修复/重放
周期对账 ---------------------------------> 漂移报告事件通知只是“可能发生了变化”，读取 API 后得到的当前对象才用于决策。写入保存源平台、源对象 ID、源版本或修改时间、目标对象 ID、幂等键和结果。Webhook 重复投递不会重复建单；事件乱序不会把 Done 推回 In Progress；目标 API 限流时进入有上限的退避重试；永久失败进入人工队列。定时对账比较状态、owner、关联和最后成功同步版本，修复漏事件。
状态真实性要靠不变量
颜色和列名只能改善可读性，不能证明进度。每个结束状态都要绑定可查询不变量：
| 状态事实 | 最小证据 | 反例 |
|---|---|---|
| 需求已接受 | 验收角色、验收证据、验收结果 | 开发任务完成 |
| 代码已完成 | 合并后的提交或 PR/MR ID、必需检查结果 | 分支已推送 |
| 缺陷已解决 | 解决方案、修复版本、代码变更 | 开发者说已修复 |
| 缺陷已关闭 | 独立验证人、验证版本、验证结果 | 状态被批量改为关闭 |
| 已发布 | 不可变构建 ID、目标环境、发布结果 | Jira Version 或禅道版本被创建 |
| 已取消 | 取消原因、决策人、未交付影响 | 从看板删除 |
每日统计从平台历史和外部证据重算，不信任手填百分比。重点监测：无 owner 的活跃项、停留时间持续增长的状态、Done 但无验收证据、Closed Bug 但无验证人、发布对象无工作项、工作项无代码回链、机器人连续失败和被跳过的必填规则。阈值由迭代节奏、SLO 和历史分布确定，不使用脱离团队规模的万能数字。
用权限矩阵做一次可重复实验
为每个平台保留同一张测试矩阵：
| 动作 | pm-lab | dev-lab | qa-lab | bot-lab | 证据 |
|---|---|---|---|---|---|
| 创建需求 | 允许 | 拒绝或按团队策略 | 拒绝 | 拒绝 | 对象历史与失败响应 |
| 更新代码字段 | 只读 | 允许 | 只读 | 仅指定字段 | 字段历史 |
| 解决缺陷 | 只读 | 允许 | 只读 | 拒绝 | transition 记录 |
| 验证并关闭缺陷 | 只读 | 拒绝 | 允许 | 拒绝 | 验证版本与操作者 |
| 修改工作流 | 拒绝 | 拒绝 | 拒绝 | 拒绝 | 管理审计日志 |
| 批量导出 | 按数据职责决定 | 拒绝 | 拒绝 | 只读 API | 导出审计与文件清单 |
每次升级、身份源切换或权限模板变化后重跑。正向动作必须成功且留下历史，反向动作必须失败且不改变对象。只看到按钮隐藏不算拒绝，还要尝试直接 URL 或 API；只收到 403 也不够，还要确认对象未发生副作用。
导入导出要验证语义，不只比较行数
迁移先建立字段字典和状态映射，再导入一个 canary 批次。至少包含父子需求、普通任务、跨对象关联、带附件缺陷、非默认工作流、自定义字段、多行描述、评论、历史操作者和已离职用户。导入前把平台原生 ID 保存到 legacy_id，新平台 ID 单独记录，禁止让可变标题承担关联。
Jira Cloud 支持 CSV、JSON 和其他迁移入口。CSV 至少需要 Summary，层级、用户、评论、附件和多值字段有各自映射规则；大批次应拆分并保存详细导入日志。导入既有空间时，目标 status、work type、自定义字段和选项必须先存在，不能期待导入器临时补建配置；因此 canary 应先故意带一个不存在的状态，确认校验阶段失败且目标空间没有半写入，再补齐映射重跑。官方导入导出总入口与CSV 导入说明还提醒 team-managed 与 company-managed 的 work type 映射差异。普通 CSV 导出不是可完整恢复的站点备份。
服务管理空间还要把评论可见性列为迁移不变量。JSON 导入若没有正确携带内部评论属性，评论可能以公开评论落入目标空间；试迁移必须同时准备一条公开评论和一条内部评论，用外部客户身份验证后者不可见，再由管理员检查导入日志与对象历史。Jira JSON 导入说明给出了 sd.public.comment 属性的映射方式。评论数量完全相同而可见性改变，仍然是迁移失败，并且属于数据泄露事件。
禅道导出能力随版本和对象变化。增强版 Excel 导入导出可覆盖需求、任务、Bug、用例，但附件、历史、权限、流程和关系未必落入表格；开源版 CSV 能力也不能由增强版手册反推。Excel/CSV 导入参考说明模板文件无编号会新增、带编号可能更新既有对象，因此回放前必须在隔离实例验证新增与覆盖语义。自托管退出还要保留数据库、附件目录、安装版本、插件清单和恢复步骤。
TAPD 的需求、缺陷和迭代可通过界面导入导出，Jira 迁移、自动化、API 和审计能力按目标方案核验。API 导出必须遍历分页，同时读取字段配置、候选值、工作流、变更历史和关联对象，不能只导出列表接口。TAPD 更新日志可用于确认导入、导出和工作项能力变化；合同退出条款仍要单独验收。
导出包建立 manifest：
mkdir -p collaboration-exit-lab
find collaboration-exit-lab -type f -print | sort \
> collaboration-exit-lab/file-list.txt
grep -R -n 'COLLAB-LAB-7F3A' collaboration-exit-lab \
> collaboration-exit-lab/canary-hits.txt
find collaboration-exit-lab -type f -exec sha256sum {} \; \
> collaboration-exit-lab/sha256sums.txt预期 canary 同时出现在需求、缺陷或关联清单中，附件有本地文件或受控下载映射，manifest 能重算。找不到 canary 可能是权限漏导、分页遗漏或格式不可文本搜索；只有对象当前值而无历史，说明只能迁移结果，不能重建审计；链接仍指向旧租户，说明退出后证据链会断。
隔离恢复后比较对象数量、稳定 ID 映射、父子关系、状态类别、字段值、评论顺序、附件哈希、当前 owner、可见性和搜索命中。任何关键对象无法恢复，都要有保留只读旧平台、专门迁移通道或合规归档方案。
凭证、敏感数据与审计边界
需求描述、评论、附件、历史版本、通知、导出包、API 响应和第三方应用都会复制数据。客户截图先脱敏；生产日志只保存受控观测链接和时间窗口；密码、Token、Cookie、私钥与恢复码只保存在密钥系统。Webhook payload 也可能包含需求正文和人员信息，失败队列、APM 和调试日志必须做字段级脱敏。
管理员、项目管理员、普通成员、外部协作者和机器人分开。机器人凭证有 owner、用途、授权项目、允许动作、创建来源、轮换触发器和撤销入口；离职先转移工作项、过滤器、自动化、项目 owner 和 API 应用，再停账号。共享管理员和个人 Token 都会让审计失去主体。
业务历史与管理审计是两条证据链。对象历史回答“谁改了状态和字段”，管理审计回答“谁改了工作流、权限、字段、应用和导出设置”。平台未提供足够留存时，把允许的管理事件发送到受控日志系统，并验证导出权限不会绕过工作项可见性。TAPD 安全白皮书描述了 API、日志采集与审计控制，但组织仍需在实际版本中验证管理员可见范围、留存和导出方式。
容量和成本从活跃对象算起
座席只是成本的一部分。容量模型至少记录：活跃成员与外部协作者、项目或空间数、活跃与归档工作项数、附件字节、字段和工作流数量、自动化执行量、API 调用与限流、审计留存、导出耗时、恢复耗时，以及管理员和运维投入。
字段、状态和自动化也会形成配置容量。Jira 的全局自定义字段和共享 scheme 过多会放大管理与查询成本；禅道自托管要承担数据库、附件、备份、升级和插件兼容；TAPD 的 SaaS 能减少服务端运维，但 API、自动化、审计、私有部署和项目规模能力受方案与合同影响。采购评审现场打开Jira 方案页、禅道产品页和TAPD 方案页，代入地区、身份治理、数据量和退出要求，不保存容易过期的报价截图作为长期架构依据。
增长实验使用真实分布的合成样本：短需求、长描述、多附件、深层父子关系、大量评论、多个自定义字段和并发自动化。连续导入多轮，观察搜索、看板、批量更新、导出、API 分页和审计查询是否随规模恶化。生产阈值来自趋势、恢复目标和供应商限制，演示数字只能证明流程能跑。
选型看组织边界和失败模式
| 决策信号 | Jira | 禅道 | TAPD |
|---|---|---|---|
| 多团队统一流程与生态集成 | company-managed scheme、REST 和 Atlassian 生态较成熟 | 可通过私有部署与版本能力定制 | 国内 SaaS 协作与开放平台集成方便 |
| 数据驻留与自托管 | Data Center，基础设施和许可责任较重 | 私有部署路径直接，可控制数据库与附件 | 可咨询私有部署，需验收版本差异与运维责任 |
| 产品、项目、执行分层 | 需要用项目、类型、层级和方案建模 | 原生区分产品、项目、执行 | 项目内需求、迭代、任务、缺陷链清晰 |
| 自治团队快速试点 | team-managed 上手快，但跨空间标准化较弱 | 开源版或云服务可快速起步 | SaaS 注册后可快速建项目 |
| 复杂权限与审计 | 多层权限强，但配置来源也更复杂 | 项目、执行、白名单和版本能力需认真核对 | 角色、保密对象、字段和审计按方案核验 |
| 退出主要风险 | scheme、ADF、应用字段、历史和附件映射 | 数据库易持有，插件语义和版本恢复仍有成本 | SaaS 导出、API 能力和合同取回条件是关键 |
Jira 适合已经采用 Atlassian 生态、需要跨团队标准化工作流和复杂集成的组织；代价是 scheme、字段、应用和权限来源多，Cloud 与 Data Center 是两套责任模型。禅道适合重视产品到项目执行分层、需要本地化使用或自托管控制的数据团队；选型不能只看开源版启动速度，还要验证增强能力、升级、备份和插件。TAPD 适合国内研发团队快速采用 SaaS、连接需求迭代缺陷和办公生态；API、自动化、审计、私有部署与退出能力要作为采购验收项。
平台不是敏捷成熟度的替代品。团队无法定义“完成”、没有独立验收角色、代码与发布没有稳定 ID 时，换任何工具都会复制同一种失真。先用同一条 COLLAB-LAB-7F3A 链路跑权限反例、状态不变量、API 读取、导出恢复和离职交接，再比较失败数量、修复时间和长期 owner，结论会比功能清单可靠。
归档、回滚与长期治理
试点清理从外向内进行：停止 webhook、CI 和同步任务；确认失败队列为空；撤销 OAuth 安装、API 账号和 Token；导出最终对象、历史、字段、工作流、权限和附件；移除外部成员；最后归档或删除试点项目。禅道自托管再停止容器并处理 volume，Jira Data Center 还要处理试点数据库、索引和共享目录中的数据边界。
已经被真实项目引用的试点不能直接删除。先冻结新写入，导出增量，把仓库、PR/MR、构建和发布中的 canonical URL 切换到旧平台或新平台；用 ID 映射修复反向链接；验证新平台的搜索、权限、状态与机器人；保留旧平台只读窗口。回滚成功的判据是旧事实源重新可读、自动化恢复写入、没有双写分叉、试点对象不再接收生产事件。
长期运行时，字段和状态有数据字典，workflow 与权限模板有 owner，管理变更走评审；自动化使用应用身份、幂等键、失败队列和周期对账；每次升级重跑权限矩阵与状态实验；每次组织变化演练 owner 转移和凭证撤销；每次采购续约前执行一次隔离恢复。这样，看板上的“完成”才不再是一种颜色，而是能够从需求一路追到代码、验证、发布和审计的工程事实。