IDE 工程治理
团队治理 IDE，不是要求所有人使用相同主题、字体和快捷键。真正需要统一的是会影响代码结果、数据边界和故障恢复的工程事实：项目如何导入，SDK 从哪里选择，运行配置是否含秘密，插件能执行什么，设置同步会把哪些数据带到账号和云端。
四个治理对象
项目模型
项目模型、索引与缓存治理解释 folder、workspace、project、module、solution、SDK、external model 和生成目录之间的关系。
治理目标不是“索引永不出错”，而是当索引、依赖模型或缓存出现分歧时，团队能够证明 CLI 与 IDE 分别看到了什么，并能从干净 clone 重建。
任务、运行与调试
任务、运行与调试配置治理区分任务编排、进程启动和调试连接，解释 launch / attach、debug adapter、JDWP、Node inspect、浏览器调试、source map 和路径映射。
治理目标是让共享配置只保存入口和无密钥参数模板，个人和环境差异通过受控注入解决；停止调试后还要确认目标进程、监听端口和临时数据是否清理。
扩展与插件
扩展与插件供应链治理处理发布者、签名、权限、allowlist、blocklist、私有源、离线源、版本锁定、升级回滚和退场。
插件与 IDE 进程同权限运行时，能够读取源码、访问网络、启动外部进程和修改文件。推荐清单不是准入控制，插件市场评分也不是安全审查。
设置同步与团队基线
设置同步与团队基线把配置分为个人、项目、机器和组织四层，解释账号同步、工作区设置、格式化、inspection、证书和敏感信息边界。
治理目标是让新成员在干净机器上恢复团队基线，同时不会把个人证书、内部地址、生产连接和访问凭证同步到仓库或个人云账号。
责任矩阵
| 角色 | 主要责任 | 不应承担 |
|---|---|---|
| 项目 owner | 项目根、SDK、构建和运行模板 | 替每个人维护私有 IDE 状态 |
| 工具链 owner | 版本基线、插件准入、升级和回滚 | 绕过安全与采购流程直接强推插件 |
| 安全 / 合规 | 数据边界、扩展来源、遥测和审计要求 | 用抽象禁令替代可执行策略 |
| 开发者 | 按基线验证、保护个人凭证、报告差异 | 把本机绝对路径和秘密提交进仓库 |
| 平台 / IT | 软件分发、账号、许可证和企业策略 | 对业务运行配置和项目模型全权负责 |
一条最小治理闭环
团队建立 IDE 基线时，先选一个真实但无敏感信息的代表仓库：
用 CLI 完成依赖获取、构建和测试，保存预期结果。在受支持 IDE 中从正确项目根导入，不手工重建仓库已有模型。完成一次运行和断点调试，验证参数、环境和源码映射。
在干净账号或干净 profile 中恢复批准插件和无密钥设置。禁用一个关键插件或故意切换错误 SDK，记录可观察症状和修复证据。执行升级演练，再验证构建、调试、格式化和插件兼容。
执行回滚或干净重建，确认没有依赖无法解释的个人缓存。
这条闭环通过后，团队才有资格把该 IDE 入口标记为“受支持”。截图能打开项目、插件安装数量很多、个人机器长期没出问题，都不能替代可重复验收。
配置提交前检查
IDE 配置进入 Git 前，至少扫描：
本机盘符、home 目录和用户名。内网域名、真实 API、数据库和集群地址。token、密码、Authorization header、私钥和证书路径。
生产 profile、生产 kubeconfig 和远程 attach 端口。自动执行脚本、post-create 命令和未知插件建议。会造成全仓库重排的格式化或换行设置。
IDE 专属配置是否会与项目通用构建事实冲突。
不能公开的值应改成占位符、环境变量或受控 secret 引用，并在最小验证中证明缺少凭证时会明确失败，而不是静默连接到错误环境。