ci: close verification and Central publication gaps

[DavidHLP]

Summary

PR/main/merge-group/manual/tag
  → shared verification → one candidate → Boot consumers + JMH + dependency review
  → strict ci-ok
version tag → verified candidate → signatures → Central PUBLISHED → GitHub Release

Unify CI checks and fail closed on invalid results or missing test evidence. Reuse one verified artifact, add real Sentinel/TLS smoke and dependency security gates, and publish/recover through the Central Portal without rebuilding in credential-bearing jobs.

Declare Boot-managed Micrometer Core as a runtime dependency: a minimal packaged Boot application previously failed to load MeterRegistry without optional Actuator. Actuator and Redisson remain optional; metrics publishing remains opt-in and no registry is created in the minimal consumer. Public Java APIs and coverage thresholds are unchanged.

Evidence

• Before: main had no protection; the gate accepted mandatory skips and malformed JSON prefixes; packaged consumers were not checked; Central upload could precede signing.
• After: current-head CI run 37633304945 passed every check at 8e48b3cafac9442ff9ffc30377703c2aa37e6db6. Full verification executed 992 tests, zero skipped, and coverage passed. Unit, Checkstyle, docs, actionlint/ShellCheck, 14 pipeline regressions, all three packaged Boot consumers, JMH and dependency security passed. Publication regressions use temporary GPG keys and simulated Central responses.
• Local packaged consumers also passed minimal, Redisson and observability profiles, including Redis read/write, sync caching and absence of a registry without an observability provider.
• Main protection was applied and read back: PR required, GitHub Actions ci-ok (app 15368), strict up-to-date checks, administrator enforcement, no force push/deletion, zero required reviewers. Dependabot alerts/security updates are enabled; maven-central permits only v* tag deployments.
• Public Central publication was not attempted. The current 0.0.2 coordinates are occupied; maintainers must configure Portal/GPG access and push a new unused version tag matching the POM and Changelog. Post-merge main CI and manual weekly verification/security, including CodeQL, passed at 450a874e9bb943cba3cc8e49e4fb355a48ea2b1c. Qodana remains optional and its scan was not enabled. Live publication/recovery remains unverified.

Merge Danger

Door: two-way for repository files and protection settings; public Central publication is a separate irreversible tag-triggered operation.

Blast Radius: CI/CD and dependency packaging

Local Maven publication now requires explicit -Prelease. CI publishes the exact verified bundle, confirms PUBLISHED and public repository hashes before creating a GitHub Release, and can resume an existing deployment without uploading again. The explicit Micrometer Core dependency fixes the packaged runtime classpath while retaining optional observability/locking behavior.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-07T14:05:23.105211Z	8e48b3c	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[DavidHLP]

AI-assisted independent review

Conclusion: no confirmed actionable defects introduced by the assessed change. I recommend merge subject to human review. This is an advisory review, with human_review_required; it is not a release approval or a formal GitHub approval. Publication remains a separate operational decision.

Reviewed identity and method

• Base: 6e39ddd8cc00931bb911086b36cb92c07d1d9401
• Head: 8e48b3cafac9442ff9ffc30377703c2aa37e6db6
• Scope: 35 changed files
• Assessed diff SHA-256: 42583053fe393beb3694e728b75da1693387dc56c44188b635f6feb50c46691e

The PR identity was re-read before posting and still matches this assessment. The review covered the immutable diff, surrounding code and base behavior, workflow/job dependencies, packaging contracts, publication/recovery paths, and existing CI evidence. Potential issues were checked against their prerequisites and counterexamples, including whether the behavior was already present in the base. I did not execute the project locally or perform a live Central publication.

The main question was whether the proposed checks actually enforce the intended release boundaries: complete verification, one identified candidate, credential isolation, and proof of public publication before declaring a release successful.

Findings and rationale

1. Runtime dependency correction is justified.
The direct Boot-managed micrometer-core dependency in pom.xml matches the unconditional MeterRegistry type references in ResolvedMetricsConfiguration and CacheHandlerChainFactory. A minimal consumer can need those classes even without optional Actuator. ResolvedMetrics.resolve checks the opt-in setting before retrieving a registry, so making the types available does not itself enable metrics publication or create a registry. The minimal, Redisson, and observability packaged-consumer checks are relevant evidence for this distinction. No production Java implementation, Redis data format, or persisted-state change was identified in this diff.

2. The aggregate CI gate is meaningfully fail-closed.
The combination of shared verification, pipeline classification, and require-all-green.sh checks a complete expected job inventory rather than accepting whichever successful results happen to be supplied. Invalid JSON, missing results, failed/cancelled jobs, and unapproved skips fail the gate. The explicit docs-only skip allowance is bounded; unknown files, wrapper changes, and CI changes require full validation. This addresses a concrete counterexample to a weak aggregate gate: a skipped mandatory job must not turn into a successful overall check merely because no failing result exists.

3. Candidate provenance is preserved across the credential boundary.
The candidate's file inventory, Maven coordinates/version, source SHA, and hashes are checked before downstream use. The release workflow publishes the verified candidate without rebuilding Maven artifacts in the credential-bearing job. This reduces the opportunity for tested bytes and published bytes to diverge, while keeping signing and Portal credentials outside the build path. These controls improve provenance; their effectiveness still depends on the surrounding workflow permissions and release access controls.

4. Publication and recovery have appropriate terminal-state checks.
central.py and check-recovery.py were assessed together with the release workflow. Recovery binds to the original release workflow run ID and its successfully verified candidate. GitHub Release creation follows Central's PUBLISHED state and a hash comparison against publicly retrievable artifact bytes. An upload timeout does not trigger a blind duplicate upload. This matters because an ambiguous network outcome can represent a deployment that already exists.

The Portal interaction is consistent with the official Sonatype Publisher API documentation. Simulated responses and temporary-key signing tests support the implementation's control flow, but they cannot establish that this repository's live credentials, namespace permissions, or first recovery attempt will work.

5. Suspected issues were checked against existing behavior.
The Sentinel fixture's bridge-IP reachability premise in RedisTopologyIntegrationTest.java is consistent with the Linux/Docker test environment and an existing Cluster fixture in the base. It was not substantiated as a newly introduced cross-platform defect. Separately, version 0.0.2 already being occupied is a documented release prerequisite: the preflight rejects reuse. A new unused version is required before publication; this is not evidence of a hidden regression in the proposed check.

CI and dependency evidence

Run 37633304945 completed with all 11 jobs green. The reviewed evidence includes:

• Full verification: 992 tests, zero failures, errors, or skipped tests; coverage passed.
• 14 pipeline regression cases, plus workflow validation, Checkstyle, and documentation checks.
• Three real packaged Boot consumers: minimal, Redisson, and observability.
• JMH validation and dependency-security checks.

The actual checked-out CI commit was ed8fba0cb06f6ba9fb76c7e44d6c152f031db9e7. Its tree matches the assessed head at tree 775d4a931fd752ae2051ae03eac5add1bf943728. This supports applying the observed CI results to the reviewed source tree without incorrectly claiming the runner checked out the head commit directly.

The dependency gate reported no newly introduced HIGH-or-higher issues. The OSV evidence covered 153 packages and contained 80 existing advisory records, with zero new high/unknown entries under the gate's classification. Existing advisory records remain relevant; this result does not establish that the dependency graph is vulnerability-free.

Risk assessment and recovery

Dimension	Assessment
Potential impact	High: broad CI/CD changes reach signing credentials and public Maven artifacts.
Likelihood	Moderate: multiple controls and green tests reduce risk, but live release conditions remain unproven.
Protection coverage	Partial: automated gates and provenance checks help; human review is still needed at release boundaries.
Recoverability	Repository changes can be reverted. An immutable Central publication is much harder to recover from and normally requires a corrected version.
Confidence	Moderate, bounded by static inspection, observed CI, and simulated publication/recovery evidence.

A merge itself does not publish the artifact. For an interrupted publication, inspect the existing deployment and use the bound recovery path; do not assume a failed client request means nothing was uploaded. Reverting repository files cannot retract an already consumed public artifact.

Remaining pre-release checks

1. Verify live Portal namespace access, signing configuration, credential scope, and release-environment controls.
2. Select unused coordinates and align the version tag, POM, and changelog. Do not attempt to reuse 0.0.2.
3. Observe post-merge main/weekly and applicable merge-group execution; these event paths were not established by this PR run.
4. Have a maintainer supervise the first live release and any recovery, checking candidate identity, deployment state, and public hashes before treating publication as complete.

On the evidence above, I found no substantiated introduced defect that should block this head from merging. The remaining items define the limits of the evidence and the separate release-readiness work; they do not justify automatic merge or unsupervised publication.