工具准入与 Owner：从临时试用到可退出的团队资产

工具准入与 Owner高清原图

周一早会后，一位开发者为了生成接口文档安装了浏览器插件；另一位把插件推荐给全组，大家又陆续授权它读取代码仓库和协作平台。两个月后插件升级，导出格式变化导致流水线失败，原推荐人已经转组，管理员不知道谁能决定回滚，也没人说得清插件读取过哪些项目、订阅由哪个成本中心承担。工具本身没有突然“变坏”，真正失效的是从试用到正式使用之间那条责任链。

研发工具进入团队，不应以“安装成功”作为终点。安装只是把二进制、扩展或 SaaS 入口带到用户面前；准入则要证明它解决了明确问题，在限定数据与权限下可以稳定工作，失败时有替代路径，费用和维护投入可接受，并且有人能够作出升级、暂停和退出决定。owner 也不是台账里一个接收提醒的名字，而是对能力边界、运行证据和生命周期决策负责的角色。

事故发生后先停止扩散，再重建事实

发现未知工具已被多人使用时，第一反应不应是全员卸载。粗暴删除可能丢失尚未导出的配置，也可能留下服务端 OAuth 授权、机器人、Webhook 和订阅。先冻结新增安装与扩权，保留当前版本、安装来源、使用者、授权对象和最近成功任务的证据，再判断是补做准入、降级为隔离试用，还是有序退出。

最小事实表至少回答六件事：谁在用、从哪里安装、访问什么、向哪里发送、产生什么持久对象、停止后业务如何继续。桌面应用之外，还要寻找 IDE 扩展、命令行包、后台服务、浏览器授权、Webhook、服务账号、CI action、容器镜像和自动更新通道。只看员工电脑的软件列表，会漏掉最危险的云端授权与无人机器人。

# 只收集本机可见事实，不卸载、不删除，也不回显环境变量的值
Get-Command <tool-command> -ErrorAction SilentlyContinue |
  Select-Object Name, Source, Version

Get-ChildItem Env: |
  Where-Object { $_.Name -match 'TOOL|TOKEN|KEY|CLIENT|PLUGIN' } |
  Select-Object Name

git status --short

预期输出是命令来源和可能相关的变量名，Git 状态保持不变。若命令来自用户临时目录、版本无法识别、变量名称暗示长期 token，或者扫描前后 Git 出现新增文件，应把工具降到隔离状态。这里的证据只能说明本机发生了什么，不能证明云端授权已经撤销；管理员还要在产品的 Connected Apps、OAuth Apps、应用安装或审计入口核对服务端对象。

先写试用假设，避免“大家觉得挺好”

有效试用不是开放体验，而是一项可以被证伪的小实验。把模糊目标“提升研发效率”拆成可观察假设：某类任务当前耗时多少，工具介入哪个步骤，质量不能下降到什么程度，试用多少人、多少项目、持续多久，什么信号会立即停止。没有基线就只有感受，没有停止信号就会让试用自然变成永久使用。

一个文档图示工具的试用假设可以是：在两个不含敏感数据的示例仓库中，由四位开发者连续完成十次架构图变更；从需求确认到评审链接生成的中位时间下降，但生成文件必须进入 Git、离线构建可重现、导出不含外部追踪地址，并且旧工具仍能在十五分钟内恢复。这里的“十五分钟”是团队自己的恢复目标，不是产品承诺。

experiment_id: TOOL-TRIAL-017
problem: "架构图修改依赖单人桌面文件，评审无法追踪差异"
hypothesis: "文本化图示使十次变更的中位交付时间下降，并保持可重现构建"
participants: 4
repositories:
  - demo-service-a
  - demo-service-b
data_classification: synthetic-only
duration_days: 14
success_evidence:
  - ten-reviewed-changes
  - reproducible-export
  - no-unapproved-network-destination
stop_signals:
  - reads-denied-directory
  - requires-shared-admin-account
  - cannot-export-owned-source
  - critical-task-blocked-over-four-hours
fallback: "恢复已锁定版本的原图示生成器"

正向实验应保留任务开始与结束时间、生成物哈希、评审结果和网络目的类别，证明改善来自工具而非换了更简单的任务。反向实验则故意让工具读取一个被拒绝的合成目录、断开网络、撤销普通权限或输入不兼容文件，观察它是否明确失败并保留原数据。若失败后静默丢字段、自动上传全部工作区，或只能靠管理员账号继续，试用应立即停止。

一条准入记录必须能驱动动作

台账不是产品名称清单。一个可执行条目要把控制对象、决策依据和触发器放在一起，使管理员能据此配置，使使用者知道何时停止，使接任者能完成升级或退出。字段可以存入 CMDB、代码仓库中的受控 YAML 或服务目录；关键是变更可审查、敏感值不落入记录。

tool_id: DEVTOOL-042
display_name: "<tool-name>"
publisher: "<official-publisher>"
distribution:
  channel: "official-marketplace"
  package_or_app_id: "<immutable-id>"
  approved_version: "<tested-version-or-policy>"
  update_mode: "owner-approved"
  integrity_evidence: "<signature-or-digest-record>"
business_capability: "diagram-as-code"
status: "trial"
owner_role: "developer-experience-lead"
backup_owner_role: "platform-engineer"
service_consumers: ["backend-team", "architecture-review"]
identity:
  sign_in: "organization-sso"
  provisioning: "named-account"
  emergency_access: "<controlled-runbook-or-none>"
data:
  allowed: ["synthetic", "internal-non-sensitive"]
  denied: ["credentials", "customer-export", "production-log"]
  storage_regions: ["<approved-region>"]
  retention: "<configured-retention-or-provider-boundary>"
  export_format: "<open-format-and-test-record>"
  deletion_verification: "<runbook-reference>"
permissions:
  workspace: "selected-repositories"
  network: "approved-domains"
  organization_admin: false
integrations: ["git-provider-app"]
operations:
  support_channel: "<organization-owned-channel>"
  service_objective: "<support-and-recovery-record>"
  rollback_artifact: "<tested-package-or-config-reference>"
commercial:
  license_model: "<seat-usage-or-hybrid>"
  cost_owner: "engineering-platform"
  budget_signal: "<billing-export-or-threshold>"
  renewal_or_eol: "<contract-and-support-boundary>"
evidence:
  last_review: "<review-record-id>"
  test_report: "<artifact-reference>"
recheck_triggers:
  - "publisher-or-package-id-change"
  - "new-permission-or-domain"
  - "major-update"
  - "owner-change"
exit_record: "<runbook-reference>"

publisher、不可变应用标识和签名或摘要证据共同约束安装对象；安装页面上的显示名称不足以证明来源。approved_version 可以是精确版本，也可以是团队验证过的更新策略，但不能只写“最新版”。allowed 与 denied 必须落到数据类别，保留、区域、导出和删除则决定数据进入服务后是否仍可控制；“遵守公司规定”无法配置。身份字段要说明谁能登录、如何创建和回收账号，而不是只写“支持 SSO”。商业字段也不能只记采购金额，还要能解释座席、调用、存储和续约由谁承担。recheck_triggers 用来避免一次批准永久生效。真实 token、许可证密钥、客户名和内部域名不属于台账字段，只记录秘密所在的受控系统及引用标识。

NIST SP 800-161 Rev.1 把供应链风险管理放进系统全生命周期，并强调角色、责任、供应商和组件风险；这正是为什么准入对象必须精确到发布者、分发通道、更新来源与退出动作，而不能只登记品牌名。NIST SSDF 还要求保护开发环境和工具链，第三方研发工具因此也是工程供应链的一部分。

风险分类必须改变审批、试用环境和退出速度

给工具贴上“低、中、高”标签没有意义，除非标签会改变动作。风险分类至少同时看五个维度：能读取的数据、能执行的动作、身份权限、对研发主链路的阻断程度，以及供应链与退出是否可验证。浏览器取色插件和能够读取所有仓库、执行终端命令的 AI Agent 即使都叫“开发插件”，准入路径也不能相同。

先分别记录各维度事实，再由最高影响项决定最低控制等级，避免用多个低风险项的平均分稀释一个致命风险。下面的演示值用于说明决策结构，不是通用评分标准：

risk_assessment:
  tool_id: DEVTOOL-042
  data: internal-non-sensitive
  execution: workspace-write
  identity: selected-repository-grant
  delivery_dependency: team-non-blocking
  supply_chain: signed-official-marketplace
  exitability: source-export-tested
  resulting_tier: controlled
  required_controls:
    - isolated-project-trial
    - named-account
    - repository-allowlist
    - owner-and-backup
    - deny-test
    - export-and-revoke-test
  decision_owner: tool-governance-board
  residual_risk_owner: engineering-platform

contained 级工具只能处理合成或公开数据，不能获得组织级授权，可以由 owner 在隔离项目中快速试用。controlled 级工具可以进入受限内部项目，但必须有 named account、资源 allowlist、审计、backup 和退出验证。privileged 级工具一旦能读取秘密、修改仓库保护、执行本机命令、进入生产资源或阻断合并发布，就需要安全与平台共同批准，普通任务不得使用永久管理员，升级要先过代表性回归。来源不可验证、拒绝边界不可配置、撤权后仍可长期访问，或关键数据无法导出的工具，不应靠“高风险已知”继续推进，而应保持隔离或拒绝。

风险不是一次性字段。新增 OAuth scope、打开遥测、从只读变为写入、接入更多仓库、成为流水线强制门禁、发布者或包标识变化，都会使原判定失效。变更事件应自动把状态切回 review-required，在复查完成前冻结新增用户和新增授权；不能让旧批准自动覆盖新的执行能力。

安装入口与权限必须在隔离试用中跑通

团队验证应从官方发布页、官方包仓库或经过组织控制的应用市场进入，并保存包标识、签名或校验值、安装命令和版本输出。不要把论坛附件、网盘副本或未经审查的“一键脚本”当作便捷镜像。网络受限时，应由制品仓库代理官方包并记录来源，而不是让每位开发者各自寻找下载站。

对于 SaaS 与扩展，安装动作和授权动作要分开检查。安装一个客户端不代表它可以读取组织数据；同意 OAuth scopes、批准组织应用、创建 Webhook 或授予仓库访问才是风险真正扩大之处。GitHub 的 OAuth App access restrictions 允许组织限制 OAuth App 对组织资源的访问，应用授权与组织批准应作为两份证据。Atlassian 的 Connected Apps 管理 也区分用户安装应用、管理员控制和应用的数据访问；产品默认行为可能随计划和管理模式变化，实施时必须在目标租户确认实际开关。

隔离试用执行顺序
1. 新建只含合成数据的测试项目，不复制真实仓库历史。
2. 使用 named account 登录，不借用管理员或同事账号。
3. 从官方通道安装，记录不可变应用标识与版本输出。
4. 初始只给读取单个测试项目的权限，拒绝组织级和写入权限。
5. 观察网络目的、创建对象、缓存目录和审计事件。
6. 再按一个能力一次扩权，并重复正向、反向任务。
7. 撤销授权、卸载客户端，验证服务端对象和本地残留均可清理。

最小正向任务应是真实工作流的缩小版，例如从合成 OpenAPI 文件生成文档并提交到测试分支。预期证据包括输入文件列表、生成物、退出码、版本、外部请求类别和 Git diff。最小反向任务可以撤销写权限后再次生成，预期是明确拒绝且原文件不变。若工具在权限不足时改用个人目录缓存结果并报告成功，这不是容错，而是证据失真。

Owner、Backup 与管理员承担不同责任

工具 owner 对“为什么继续使用”负责，backup owner 对 owner 不可用时的连续决策负责，平台或安全管理员负责执行组织级配置，成本责任人负责核对消耗。一个人可以同时承担多个角色，但台账必须把职责分开，因为安装权限不等于业务判断权，付款权限也不等于知道升级是否会破坏项目。

owner 至少持续维护五类事实：适用任务和禁止任务；当前批准版本与配置基线；权限和数据边界；可用性、质量和成本信号；替代与退出路径。遇到重大版本、权限新增、发布者变化、事故、owner 转组或长期无人使用时，owner 必须触发复查，而不是等年度盘点。

backup 不能只是抄送人。他需要能访问台账、非敏感配置、测试项目、官方支持入口、恢复包和退出手册，并至少参与一次接管演练。管理员则不能替 owner 猜测业务影响：当 owner 无响应且工具请求新增组织权限时，默认动作应是拒绝或保持现状，而不是为了不阻塞开发直接批准。

连续性也不等于复制超级管理员。GitHub 的组织所有权连续性建议要求避免只有一位 organization owner，这是针对无法接管组织的单点；在支持细粒度委派的工具中，日常 backup 应先获得完成演练所需的最小角色，高权限通过受控接管流程取得。真正的检查项是“第二个人能否在旧 owner 不参与时恢复服务”，不是“管理员人数是否达到两个”。

responsibility_matrix:
  admission_decision:
    accountable: tool-owner
    consulted: [security-reviewer, platform-admin, cost-owner]
  tenant_configuration:
    accountable: platform-admin
    consulted: [tool-owner]
  version_upgrade:
    accountable: tool-owner
    responsible: backup-owner
    consulted: [representative-users]
  emergency_disable:
    accountable: platform-oncall
    informed: [tool-owner, security-reviewer]
  subscription_review:
    accountable: cost-owner
    consulted: [tool-owner]
  final_exit:
    accountable: tool-owner
    responsible: [platform-admin, backup-owner]

失败证据也要有责任人。构建失败由谁初判、数据访问异常由谁冻结、费用突增由谁停用、发布者安全公告由谁接收，都应能从记录反查。若所有事件都指向同一个个人邮箱，说明团队并没有建立责任结构，只是把单点故障写进了台账。

先分清 SLA、服务目标与响应流程

SLA 是服务提供方与使用方之间可追责的承诺，通常还包含统计口径、排除项和未达标处理；SLO 是团队希望达到的可测目标；值班与升级路径则是操作流程。把“群里有人回复”写成 SLA，既无法计算，也无法说明失败后谁有决策权。内部研发工具未必需要合同式 SLA，但必须记录支持窗口、事件等级、首次响应目标、恢复或降级目标、数据恢复点、测量来源、排除项和升级路径。采购型 SaaS 还要把供应商承诺与团队端到端目标分开：供应商 API 可用，不代表本地代理、身份系统和项目插件组成的整条链路可用。

把工具分级比“一律 99.9%”更务实。只影响个人格式化的工具可以容忍长时间不可用；阻断全公司合并的代码托管检查需要明确旁路与审计；唯一能解密构建配置的工具还涉及恢复密钥和灾难接管。等级来自业务影响，不来自采购价格。

等级	典型影响	首次响应目标	可接受降级	必备证据
辅助	单人效率下降	下一工作日	暂停使用或手工处理	安装与清理说明
团队	多人协作受阻	工作时段内	锁定旧版、只读或备用工具	恢复包、兼容测试
门禁	合并、构建或发布阻断	值守窗口内	经审批的限时旁路	旁路事件、补检结果
核心	身份、秘密或制品不可用	按事件级别响应	受控灾备入口	恢复演练、接管记录

这里的时间必须由组织根据人员与成本确定，并明确从哪个事件开始计时、用哪个日志判断恢复、计划维护是否计入。若没有值守能力，就不能把一款只有 owner 个人会维护的工具标为全天核心服务。供应商控制台的绿色状态也不能替代团队测量；代表任务持续失败时，应按端到端证据升级。架构师需要在功能收益、运维投入和故障半径之间取舍：将工具降为非阻断辅助，有时比购买更昂贵版本更可靠。

服务目标还要绑定一个真实的用户动作和清晰分母。只统计 HTTP 200 会把“接口成功但生成物不可用”算成健康；只统计供应商 API 又会漏掉 SSO、本地代理、扩展和仓库权限。Google 的 SRE Workbook 将 SLO 建立在用户可感知的服务级指标上，并用错误预算连接可靠性与变更决策。工具团队可以把“代表性构建任务在限定时间内产出可复核制品”作为 SLI，再明确哪些任务进入分母、超时怎样计算、维护窗口怎样处理。

service_objective:
  journey: "受控 runner 使用批准版本生成并提交测试制品"
  indicator:
    good: "退出码为 0，制品校验通过，且未访问拒绝域名"
    total: "所有已进入执行阶段的代表任务"
    source: "runner-event-plus-artifact-verification"
  target: "<team-measured-objective>"
  window: "<rolling-window>"
  exclusions:
    - "approved-maintenance-with-record"
  response:
    budget_warning: "freeze-nonessential-upgrades"
    budget_exhausted: "disable-new-integrations-and-start-review"
    recovery_evidence: "three-consecutive-representative-tasks"

目标值必须来自基线和业务容忍度，不能把示例数字或供应商 SLA 直接复制进来。错误预算也不是允许忽略故障的额度：它用于决定何时冻结非必要升级、降低工具阻断级别或启动替换。恢复不能只看状态页转绿；至少要让连续的代表任务重新通过，并确认积压、失败重试和费用没有继续增长。

正反实验要验证失败方式，而不只是成功按钮

准入实验应覆盖能力、边界和退出三个面。能力实验确认工具能完成目标任务；边界实验确认它不能访问未批准对象；退出实验确认撤销后不再留下有效身份、自动任务或不可迁移数据。每次实验写明输入、动作、预期、实际证据和清理，不把自然语言总结当结果。

{
  "case": "deny-unapproved-repository",
  "identity": "trial-user-02",
  "input": "synthetic-repo-denied",
  "action": "list-and-export",
  "expected": {
    "decision": "deny",
    "unchanged_objects": true,
    "audit_event": true
  },
  "cleanup": [
    "revoke-trial-grant",
    "delete-synthetic-export",
    "confirm-no-background-job"
  ]
}

正向实验给账号读取允许仓库、创建一个可删除的测试对象，预期对象带操作者、时间和来源标记。反向实验把仓库换成拒绝列表，预期在访问之前被拒绝，并生成不含业务内容的审计事件。若反向任务仍能列出文件名，即使无法读取正文，也说明元数据边界可能过宽。

再做网络失败实验：通过测试代理阻断一个非关键上游，观察工具是否超时、重试、离线降级或静默切换备用域名。无限重试会放大费用与队列，静默切换会绕过域名 allowlist，缓存旧结果会让用户误以为最新任务成功。每种现象都应对应停止阈值和恢复动作。

从试用转正式使用，需要一份可复核决策

试用结束时只有三种合理状态：拒绝、延长隔离试用、正式准入。正式准入不是把 status 改成 approved，还要把测试配置固化为团队入口：受控安装源、版本策略、权限模板、项目接入脚本、支持入口、监控信号、费用标签和退出手册。无法自动化的步骤应有双人复核，而不是埋在聊天记录。

决策记录需要同时保留收益和代价。收益可用任务时长、失败率、评审返工或等待时间表示；代价包括座席、调用、存储、出口流量、管理员时间、培训、迁移和退出成本。不要把供应商宣传的效率数字直接写成团队收益，也不要用一个熟练用户的演示代替多人试用。

正式准入判定
- 目标任务：至少完成约定数量的代表性任务，质量不低于基线。
- 数据边界：允许与拒绝类别可配置，并经反向实验验证。
- 权限边界：普通任务无需共享账号或永久管理员。
- 供应链：发布者、包标识、更新源和安全通知入口明确。
- 连续性：owner 与 backup 完成一次故障或接管演练。
- 可恢复：配置、源文件和关键数据可导出，替代路径可运行。
- 成本：座席、用量、存储与维护投入有 owner 和阈值。
- 退出：撤销身份、停任务、导出、删除和复核动作可执行。

可补偿缺项才能进入限时例外：缺什么、为何暂时接受、补偿控制、到期日、批准人和失效动作都要明确。来源无法验证、敏感数据无法限制、普通任务必须使用共享管理员、关键数据既不能导出也不能重建、撤权后仍可持续访问等问题，在验证通过前应拒绝正式准入，不能靠风险接受把技术事实改成“已安全”。没有到期日的例外会变成新默认；没有可验证补偿控制的例外只是风险转移。

常见失败要从现象反推控制缺口

“插件突然不能用”可能是版本、许可证、网络、身份、权限或上游 API 变化。排查时按证据层次推进：先确认批准版本和安装标识，再看身份是否有效、权限是否变化、网络目的是否可达、审计是否有拒绝、上游状态是否异常。不要一开始就重装；重装会覆盖版本和缓存证据。

“工具还能用，但 owner 已离职”比立即宕机更危险。服务继续运行会掩盖支付卡、恢复邮箱、个人 OAuth、私有包账号和唯一知识已经失效。触发 owner 变化时，应暂停高风险升级和新增集成，由 backup 按交接清单接管，重绑组织身份，并重新验证撤销旧 owner 后的正向任务。

“费用没有异常，但没人使用”意味着成本证据与使用证据没有关联。座席清单、活跃事件、自动任务、存储量和调用量应以同一 tool_id 聚合。供应商控制台显示登录不代表产生价值，CI 机器人调用也不能归到某个个人活跃度。长期零任务且无合规保留需要的工具，应进入退出评审。

现象	优先证据	常见根因	恢复动作
更新后输出变化	版本、diff、兼容报告	自动更新越过批准基线	锁回旧版，重跑代表任务
普通用户突然越权	角色差异、应用授权事件	默认组或新 scope 扩张	冻结授权，恢复最小模板
无人响应故障	owner/backup 可达性	责任绑定个人且未演练	启动接管，降低工具等级
卸载后仍有事件	Webhook、OAuth、后台任务	只清理客户端	先撤销服务端对象再复核
试用自然转长期	状态与到期触发器	没有停止条件	暂停新增用户，补做决策

交接要证明接任者能独立恢复

交接不是分享一个文档目录。离任 owner 应提供台账位置、安装源、配置基线、权限模板、管理员入口、官方支持渠道、未决风险、费用信号、最近一次验证、回滚包和退出手册；接任者则应在不依赖旧 owner 的情况下完成一次代表任务和一次失败恢复。

Owner 交接演练
1. 接任者从服务目录找到工具记录和测试项目。
2. 用自己的 named account 获得普通维护角色。
3. 验证批准版本、数据边界和一个正向任务。
4. 人为撤销测试项目写权限，完成失败定位。
5. 恢复权限后重跑任务，证明结果可重现。
6. 导出非敏感配置并校验哈希。
7. 撤销旧 owner 的直接授权，确认服务仍工作。
8. 更新 owner、backup、复查日期与未决风险。

交接失败时，不要继续让旧 owner 的个人授权托底。将工具降级为只读或非阻断，冻结版本和新增集成，直到组织身份和 backup 能力恢复。关键工具若没有第二位能执行恢复的人，其真实可用性上限就是那位个人的可用性。

退出从停止新动作开始，以残留复核结束

退出条件应在准入前写好：试用目标未达成、权限无法收敛、发布者或安装来源变化、重大漏洞无法缓解、费用越过阈值、关键能力被弃用、owner 在约定接管窗口内无人补位、连续多个测量窗口不满足服务目标、数据导出或删除验证失败，或替代工具已经稳定。每个条件还要绑定“暂停新增、降为只读、启动迁移、立即隔离”中的动作和决策人，否则阈值只是一条提醒。等到合同结束才设计退出，通常已经失去数据导出、管理员和迁移窗口。

正确顺序是先阻止新写入和新用户，导出归组织所有的源数据与配置，切换依赖，撤销 OAuth、token、Webhook、机器人和管理员授权，再卸载客户端、删除缓存与测试对象，最后核对审计、账单和网络事件不再出现。删除动作必须使用产品支持的精确对象标识，不能对模糊目录或共享租户做递归清理。

exit_runbook:
  freeze:
    - disable-new-installations
    - stop-scheduled-jobs
    - announce-read-only-window
  preserve:
    - export-owned-source
    - export-non-secret-configuration
    - record-object-count-and-hash
  revoke:
    - oauth-grants
    - api-tokens
    - webhooks
    - service-accounts
  remove:
    - clients-and-extensions
    - approved-local-cache-paths
    - synthetic-test-data
  verify:
    - no-successful-authentication
    - no-background-event
    - no-new-charge
    - successor-workflow-passes
  close:
    - owner-signoff
    - backup-review
    - residual-risk-record

反向退出实验可以保留一个计划任务但先撤销其 token，预期任务明确失败且不会回退到个人凭证；随后删除计划任务，确认审计中不再出现调用。若卸载后仍持续计费或产生事件，沿着服务账号、Webhook、云资源、存储和订阅逐层查找，不能把“桌面图标消失”当成退出完成。

架构师用生命周期信号决定继续、降级或替换

工具治理的核心不是让审批更多，而是让决策更早、更有证据。高收益、低权限、可导出、可替换的工具可以快速准入；高权限、强锁定、不可审计且只有单一 owner 的工具，即使功能突出，也应限制在隔离环境。把工具放在“业务阻断程度、数据敏感度、执行权限、供应链可验证性、可退出性”五个轴上，比按品牌或价格分类更接近真实风险。

长期复查至少关注版本与发布者是否变化、权限和网络目的是否扩大、代表任务是否仍通过、故障与支持目标是否满足、owner/backup 是否有效、成本是否对应使用、退出手册是否仍能执行。复查不是重新抄产品介绍，而是重跑最少的一组正向、反向和退出验证，并对差异作出决定。

成熟团队不会因为治理而拒绝所有新工具，也不会因为效率而把试用当准入。它让试用足够小、证据足够真、责任足够清楚、失败足够可恢复。当一项工具从第一次安装开始就拥有 tool_id、owner、backup、边界、触发器和退出动作，团队获得的才不是又一个账号，而是一项可以长期维护的工程能力。