Java 代码变更安全助手：通过最小化改动、优先单元测试、验证命令追溯，确保功能/重构/Bugfix 安全合入主干。
说明：
## 核心用法
`java-change-with-tests` 是面向 Java 工程的**结构化变更工作流技能**，覆盖从需求理解到 PR 就绪的全生命周期。其设计哲学是**”最小安全改动”**——在满足验收标准的前提下，优先通过单元测试验证，而非依赖耗时的集成测试套件。
### 标准执行路径
1. **Repo Map**：快速定位模块边界、主入口与测试目录
2. **Plan**：生成 3-6 步的渐进式实现方案
3. **Implement**：执行最小化代码编辑
4. **测试分层**：
– L1：针对性单元测试（首选，秒级反馈）
– L2：必要时补充集成测试
5. **验证闭环**：
– 运行精准测试覆盖变更点
– 执行模块级 `mvn -q test` 或等效命令
6. **输出交付**：Plan + 文件改动清单 + 命令执行证据 + 风险声明
## 显著优点
– **安全边际明确**：强制验收准则前置（1-3 条 bullets），避免范围蔓延
– **测试经济学**：明确区分单元/集成测试适用场景，减少 CI 等待时间
– **可追溯验证**：要求记录” exact commands and results”，形成审计链
– **多构建工具兼容**：Maven/Gradle 均可适配，通过 `module-scoped equivalent` 处理多模块项目
## 潜在局限
– **框架耦合**：深度依赖 JUnit/TestNG 生态，对非标准测试框架支持需人工介入
– **并发场景盲区**：未显式处理多线程测试的 flaky 风险
– **外部依赖mock**：未规定 Mockito/WireMock 等工具的使用层级，可能遗漏边界条件
## 适合人群
– 需要维护遗留 Java 系统的全栈工程师
– 追求”小步快跑”提交策略的敏捷团队
– 多模块 Maven/Gradle 仓库的维护者
## 常规风险
| 风险点 | 缓解建议 |
|——–|———|
| 单元测试通过但集成环境失败 | 强制要求第 5 步的模块级测试作为门禁 |
| 最小改动遗漏兼容性处理 | Plan 阶段必须显式列出”Breaking Changes”评估 |
| 命令记录失真 | 使用 `-q` 静默模式减少噪音，保留 exit code |
—
*来源：技能文档自述，未接入动态安全扫描*
