Skip to main content

maven-multi-branch-license-gate-hardening

Use when hardening or auditing license evidence, SBOM generation, full Maven Reactor verification, commit and push proof, or CI completion across multiple maintenance branches.

Aller à l'installation

Informations de source

Dépôt
full-stack-skills/java-skills
Dernière activité de la source
11 septembre 2026 à 06:42
Langue détectée de SKILL.md
chinois
Étoiles
5
Forks
3

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

Explorateur de fichiers
5 fichiers

Affichage de SKILL.md

SKILL.md
Instructions source · Aperçu en lecture seule
name
maven-multi-branch-license-gate-hardening
description
Use when hardening or auditing license evidence, SBOM generation, full Maven Reactor verification, commit and push proof, or CI completion across multiple maintenance branches.
# Multi-branch License Gate Hardening ## 核心原则 把每条维护分支视为独立发布线。只有同一分支最终 SHA 上的许可证、SBOM、完整 Reactor、远端 SHA 与必需 CI 全部闭合,才可声明该分支通过;只有所有目标分支通过,才可声明整体完成。 本 Skill 面向 Maven 多分支发布维护者、发布工程师和审计人员。它不替代项目自己的 JDK/Maven/POM 契约、许可证政策或 CI 必需检查配置。 ## 快速开始 可直接提出: - “审计这三条维护分支的 license gate,并给出缺口矩阵。” - “检查 SBOM、Reactor、push 与 CI 证据能否闭合到同一 SHA。” - “这个临时端口冲突后的模块重跑,能否作为完整 Reactor 证据?” 先读取项目指令、现有计划/规格和每条分支的工具链契约,再建立一行一个分支的证据矩阵。用户只要求分析时保持只读;commit、push、重跑 CI 或修改许可证配置都需要处于明确授权范围。 ## 能力边界 ### 擅长 - 审计多条维护分支的许可证来源证据、选择表、排除表和生成报告。 - 验证 CycloneDX/SPDX SBOM 与实际依赖图、最终提交和发布范围一致。 - 区分完整 Maven Reactor、目标模块复验、`-rf` 恢复执行和 CI 等价验证。 - 核对本地 HEAD、tracking ref、远端 SHA 与该 SHA 触发的必需 CI。 ### 需要素材 - 分支/工作树清单,以及每条线规定的 JDK、Maven/Wrapper 和构建命令。 - 项目许可证政策、SBOM 配置、必需 CI 名称及授权的变更/推送范围。 - 命令日志、报告路径、远端 SHA 或 CI run/job 标识;缺失时先输出 `unknown` 缺口,不猜测。 ### 超出范围 - 不把法律判断伪装成工程结论;许可证兼容性存在争议时转交法务或项目治理者。 - 不自动选择许可证、伪造证据 URL、放宽必需 CI,或把安全扫描 `skipped` 写成 `passed`。 - 不在未经授权时创建/切换分支、改写历史、commit、push、重跑或取消 CI。 ## 工作流 ### 1. 冻结范围与分支契约 对每条线记录:仓库根、工作树、分支、目标 SHA、JDK、Maven/Wrapper、POM 拓扑、发布范围、必需 CI。先检查 `git status`,保护用户未提交修改。多仓库或多工作树不得把路径、日志或 SHA 混线。 若项目已有正式规格或执行计划,从当前阶段继续;不要为同一变更重复创建事实源。 ### 2. 建立证据矩阵 状态只允许:`passed`、`failed`、`in_progress`、`blocked`、`skipped`、`unknown`。`skipped` 必须附授权与风险,永不等于 `passed`。 | 分支 | SHA | 工具链 | 依赖来源 | 许可证策略 | SBOM | 完整 Reactor | local/tracking/remote | 必需 CI | 总结 | |---|---|---|---|---|---|---|---|---|---| | `<line>` | `<sha>` | `<state>` | `<state>` | `<state>` | `<state>` | `<state>` | `<state>` | `<state>` | `<state>` | 每格附可复核证据:实际命令、退出码、报告/日志路径、依赖坐标与版本、URL 及响应语义、run/job URL 或 ID、观察时间。HTTP 200 只证明可访问,不单独证明许可证语义正确。 ### 3. 处理许可证与 SBOM 1. 从依赖树或解析后的模型定位精确 `groupId:artifactId:version` 与引入路径。 2. 先检查代码是否直接依赖相关 API,再选择精确排除、上游修复或经治理批准的许可证选择。 3. 许可证来源必须可追溯到该精确版本;优先固定版本、不可变的 POM/源码标签或官方仓库内容。 4. 变更后重新生成许可证报告与 SBOM,并证明旧坐标/陈旧选择已消失、预期依赖仍存在。 5. 跨分支共享脚本时比较内容、调用方式和文件模式;共享实现一致不代表各分支验证可以复用。 不要为让门禁变绿而选择没有可靠依据的许可证。若排除传递依赖,必须补充依赖树、契约/集成测试和新 SBOM 证明其不再进入交付物。 ### 4. 闭合完整 Reactor 每条线使用其真实工具链执行项目定义的完整 Reactor。记录命令、工具版本、起止时间、模块/测试计数和最终退出码。 - 目标模块重跑只支持诊断,不自动替代完整 Reactor。 - 一次全新的完整 Reactor 成功,是环境瞬态失败后最清晰的闭合证据。 - 只有能证明失败前已成功模块、恢复点、后续所有模块、源码/SHA/参数未变化时,才可接受 `-rf` 证据链;否则状态仍不是 `passed`。 - “失败前部分成功 + 单模块成功”不得拼成全绿。 ### 5. 提交与推送 提交前逐分支检查 diff、意外文件、生成物、脚本字节一致性和文件模式。提交后冻结 SHA;任何修改都会使该线先前基于旧 SHA 的 SBOM、Reactor 或 CI 证据需要重新判定。 推送证明至少包含:本地 `HEAD`、tracking ref、远端分支 SHA 三者一致。`git push` 返回成功只证明传输,不证明远端最终状态或 CI 通过。 ### 6. 等待 CI 只跟踪由最终 SHA 触发的必需 workflow/job。状态机: ```mermaid flowchart LR A[最终 SHA 已推送] --> B{必需 CI 最终结论} B -->|queued / in_progress| C[继续等待并保持 in_progress] C --> B B -->|failure / cancelled| D[保留日志并分类根因] D --> E{需要修改源码或配置?} E -->|是| F[产生新 SHA 并使旧证据失效] F --> A E -->|否,允许重跑| B B -->|success| G[该 SHA 的 CI 证据闭合] ``` 使用条件等待并降低轮询频率;报告实质状态变化。`queued`、`in_progress`、job 已启动、步骤正在安装依赖或暂时没有失败信号,都不是通过。 ### 7. 给出结论 结论先写判定,再写证据和缺口: ```text 判定:passed | partial | failed | blocked 范围:<分支与最终 SHA> 已闭合:<逐项列出> 未闭合:<状态、缺少的具体证据、如何补充> 异常分类:change-related | environment-transient | infrastructure | unknown 剩余风险:<skipped/例外/法律争议/未复核项> 下一动作:<最小且可执行的动作> ``` 整体完成条件是所有目标行的必需格均为 `passed`。否则使用 `partial`、`failed` 或 `blocked`,明确“已提交并推送”与“已通过 CI”是不同阶段。 ## 证据拼接规则 | 场景 | 是否可拼接 | 条件 | |---|---|---| | 同一分支的本地门禁、远端 SHA、CI | 可以 | 同一最终 SHA、正确工具链、范围一致 | | 多分支共用不可变许可证原始来源 | 有条件 | 精确坐标相同;每条线仍独立生成 SBOM 和跑策略 | | 失败 Reactor + `-rf` | 有条件 | 能证明完整模块覆盖且代码/参数/SHA 未变 | | 失败 Reactor + 单模块复验 | 不可以 | 只能支持根因分类 | | 旧 SHA 报告 + 新 SHA CI | 不可以 | 证据身份不一致 | | CI started/in_progress + 无失败 | 不可以 | 尚无最终成功结论 | ## 常见错误与红旗 - 看到 HTTP 200 就宣称许可证证据有效。 - 把生成过 SBOM 当成 SBOM 与最终依赖图一致。 - 用错误 JDK/Maven 的成功结果替代维护线契约。 - 用一个分支成功代表所有分支成功。 - 用 push 输出、CI 启动或局部测试宣布整体完成。 - 将临时环境故障直接忽略,而不闭合完整 Reactor。 - 日志路径没有分支标识,导致证据串线。 出现任一红旗时,停止“完成”声明,回到证据矩阵定位首个非 `passed` 单元格。 ## FAQ **Q1:三条线能并行验证吗?** 可以,只要工具链、缓存、端口、日志和工作树隔离,并且输出能映射回各自 SHA。 **Q2:CI 能替代本地 Reactor 吗?** 仅当项目门禁允许且该 CI 在最终 SHA 上执行等价或更强的完整范围;许可证/SBOM job 名称本身不能证明覆盖完整 Reactor。 **Q3:CI 一直运行时怎么交付状态?** 写 `in_progress`,说明已闭合项、正在执行的 job、最近实质进展和仍不可宣布完成的原因。 **Q4:可以复用旧许可证 URL 吗?** 只有精确版本和内容身份仍匹配且来源可复核;仍需在当前分支重新跑政策和 SBOM。 **Q5:Security 被明确豁免怎么办?** 记录 `skipped`、授权来源和残余风险;不得写成安全扫描通过。 **Q6:用户只要审计,不要修改怎么办?** 只读产出矩阵与建议,不生成报告、不改 POM、不提交、不推送、不重跑 CI。 ## 深度参考 - 需要逐门禁的证据字段、异常分类和验收规则时,读取 [references/evidence-contract.md](references/evidence-contract.md)。 - 遇到局部重跑、跨 SHA、CI 等待或安全/隐私边界时,读取 [references/anti-patterns.md](references/anti-patterns.md)。 - 处理边缘场景或自定义组织门禁时,读取 [references/faq-deep.md](references/faq-deep.md)。
Voir sur GitHub