Multi-branch License Gate Hardening
Core Principles
Treat every maintenance branch as an independent release line. A branch may be declared passed only when the license, SBOM, full Reactor, remote SHA, and required CI all close on the same final SHA of that branch; overall completion may be declared only when all target branches pass.
This Skill is intended for Maven multi-branch release maintainers, release engineers, and auditors. It does not replace the project's own JDK/Maven/POM contract, license policy, or required CI check configuration.
Quick Start
You can directly ask:
- “Audit the license gate for these three maintenance branches and provide a gap matrix.”
- “Check whether the SBOM, Reactor, push, and CI evidence can all close on the same SHA.”
- “Can this rerun of the module after a temporary port conflict serve as evidence of a full Reactor run?”
First read the project instructions, existing plans/specifications, and the toolchain contract for each branch, then build an evidence matrix with one row per branch. Remain read-only when the user requests analysis only; committing, pushing, rerunning CI, or modifying license configuration requires explicit authorization.
Capability Boundaries
Strong At
- Auditing license provenance evidence, license selection tables, exclusion tables, and generated reports across multiple maintenance branches.
- Verifying that CycloneDX/SPDX SBOMs align with the actual dependency graph, final commit, and release scope.
- Distinguishing a full Maven Reactor run, target module revalidation, resume execution, and equivalent CI verification.
- Reconciling the local HEAD, tracking ref, remote SHA, and required CI triggered by that SHA.
Required Inputs
- A branch/worktree inventory and the JDK, Maven/Wrapper, and build commands specified for each line.
- The project license policy, SBOM configuration, required CI names, and authorized scope for changes and pushes.
- Command logs, report paths, remote SHAs, or CI run/job identifiers. When any are missing, report an gap first rather than making assumptions.
Out of Scope
- Disguising legal judgments as engineering conclusions. Refer disputed license compatibility to legal counsel or project governance.
- Automatically selecting licenses, fabricating evidence URLs, relaxing required CI checks, or reporting a security scan as when it was .
- Creating or switching branches, rewriting history, committing, pushing, rerunning, or canceling CI without authorization.
Workflow
1. Freeze Scope and Branch Contracts
For each line, record the repository root, worktree, branch, target SHA, JDK, Maven/Wrapper, POM topology, release scope, and required CI. Check
first and protect the user's uncommitted changes. Across multiple repositories or worktrees, do not mix paths, logs, or SHAs.
If the project already has an official specification or execution plan, continue from the current stage. Do not create a second source of truth for the same change.
2. Build the Evidence Matrix
Only these statuses are allowed:
,
,
,
,
, and
. A
status must include its authorization and risk and must never be treated as
.
| Branch | SHA | Toolchain | Dependency Sources | License Policy | SBOM | Full Reactor | local/tracking/remote | Required CI | Summary |
|---|
| | | | | | | | | |
Attach reviewable evidence to every cell: the actual command, exit code, report/log path, dependency coordinates and versions, URL and response semantics, run/job URL or ID, and observation time. HTTP 200 proves accessibility only; it does not independently establish that the license semantics are correct.
3. Handle Licenses and SBOMs
- Locate the exact
groupId:artifactId:version
- First determine whether the code directly depends on the relevant API, then select a precise exclusion, an upstream fix, or a governance-approved license selection.
- License provenance must be traceable to that exact version. Prefer pinned versions, immutable POMs/source tags, or official repository content.
- After making changes, regenerate the license report and SBOM, and prove that old coordinates and stale selections have disappeared while expected dependencies remain.
- When sharing scripts across branches, compare their content, invocation methods, and file modes. Consistent shared implementations do not mean that validation results can be reused across branches.
Do not select an unsupported license merely to turn the gate green. If excluding a transitive dependency, include the dependency tree, contract/integration tests, and a new SBOM proving that the dependency no longer enters the deliverable.
4. Close the Full Reactor
Run the project's defined full Reactor on each line using its actual toolchain. Record the command, tool versions, start and end times, module/test counts, and final exit code.
- A target module rerun supports diagnosis only and does not automatically replace a full Reactor run.
- A fresh, successful full Reactor run provides the clearest closure evidence after an environment-transient failure.
- Accept an evidence chain only when it proves which modules had already succeeded before the failure, identifies the resume point, confirms all subsequent modules, and establishes that the source code, SHA, and parameters did not change. Otherwise, the status still cannot be .
- “Partial success before the failure + successful single module” must not be combined into an all-green result.
5. Commit and Push
Before committing, inspect the diff, unexpected files, generated artifacts, script byte consistency, and file modes for each branch. After committing, freeze the SHA. Any subsequent modification requires previously collected SBOM, Reactor, or CI evidence based on the old SHA to be reassessed.
Push proof must include agreement among the local
, tracking ref, and remote branch SHA. A successful
proves only that the transfer succeeded; it does not prove the final remote state or CI completion.
6. Wait for CI
Track only the required workflows/jobs triggered by the final SHA. State machine:
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 证据闭合]
Use conditional waits and reduce polling frequency. Report substantive status changes.
,
, a started job, a step installing dependencies, and the temporary absence of a failure signal are not passes.
7. Provide the Conclusion
State the determination first, followed by the evidence and gaps:
text
判定：passed | partial | failed | blocked
范围：<分支与最终 SHA>
已闭合：<逐项列出>
未闭合：<状态、缺少的具体证据、如何补充>
异常分类：change-related | environment-transient | infrastructure | unknown
剩余风险：<skipped/例外/法律争议/未复核项>
下一动作：<最小且可执行的动作>
Overall completion requires every required cell in every target row to be
. Otherwise, use
,
, or
, and clearly distinguish “committed and pushed” from “passed CI.”
Evidence Stitching Rules
| Scenario | May Evidence Be Combined? | Conditions |
|---|
| Local gate, remote SHA, and CI for the same branch | Yes | Same final SHA, correct toolchain, and aligned scope |
| Immutable license source shared across multiple branches | Conditional | Exact coordinates are identical; each line must still independently generate its SBOM and run the policy |
| Failed Reactor + | Conditional | Full module coverage can be proven, and the code, parameters, and SHA are unchanged |
| Failed Reactor + single-module revalidation | No | Supports root-cause classification only |
| Old SHA report + new SHA CI | No | Evidence identities do not match |
| CI started/in_progress + no failure | No | There is no final successful conclusion yet |
Common Errors and Red Flags
- Declaring license evidence valid merely because the response was HTTP 200.
- Treating SBOM generation as proof that the SBOM matches the final dependency graph.
- Replacing a maintenance line's contract with a successful result obtained using the wrong JDK/Maven version.
- Treating success on one branch as success across all branches.
- Declaring overall completion based on push output, CI startup, or partial tests.
- Ignoring a temporary environment failure without closing a full Reactor run.
- Omitting branch identifiers from log paths and causing evidence to be mixed across branches.
If any red flag appears, stop making a “completed” declaration and return to the evidence matrix to locate the first non-
cell.
FAQ
Q1: Can the three lines be validated in parallel? Yes, provided that toolchains, caches, ports, logs, and worktrees are isolated and that outputs can be mapped back to their respective SHAs.
Q2: Can CI replace the local Reactor? Only when the project gate permits it and the CI executes an equivalent or stronger full scope on the final SHA. The names of license/SBOM jobs alone do not prove full Reactor coverage.
Q3: How should status be delivered while CI is still running? Write
and explain the closed items, the job currently executing, the latest substantive progress, and why completion still cannot be declared.
Q4: Can an old license URL be reused? Only when the exact version and content identity still match and the source remains reviewable. The policy and SBOM must still be rerun on the current branch.
Q5: What if a security scan is explicitly waived? Record
, the authorization source, and the residual risk. Do not report the security scan as passed.
Q6: What if the user only wants an audit and no modifications? Produce a read-only matrix and recommendations. Do not generate reports, modify POMs, commit, push, or rerun CI.
Deep References
- For gate-by-gate evidence fields, anomaly classification, and acceptance rules, read references/evidence-contract.md.
- For partial reruns, cross-SHA issues, CI waiting, and security/privacy boundaries, read references/anti-patterns.md.
- For edge cases or custom organizational gates, read references/faq-deep.md.