chore(release): authorize v0.41.4 source

[steipete]

Summary

Adds the immutable release authorization record binding v0.41.4 to:

• tag object fcfd27062df39f3d4b6689dd786ba2dc96f310cb
• source commit 5390447e3b02f43ba6bfd174ca6d809286c9d65d

This authorization does not create, build, draft, or publish release assets.

Verification

• Remote tag object: fcfd27062df39f3d4b6689dd786ba2dc96f310cb
• Remote peeled commit: 5390447e3b02f43ba6bfd174ca6d809286c9d65d
• Focused release tests: passed
• P1 autoreview: clean; no accepted or actionable findings

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 12, 2026, 3:36 AM ET / 07:36 UTC.

ClawSweeper review

What this changes

The PR adds the immutable v0.41.4 release authorization record that marks its signed-tag identity ready for protected release processing.

Merge readiness

⚠️ Ready for maintainer review - 3 items remain

Keep open for the required release-code-owner decision: the record accurately binds the existing v0.41.4 tag to its peeled source commit and is the documented gate before later release steps.

Priority: P2
Reviewed head: f38e00699992a163fb86e02c2ccc6f3a293cb322
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A tight, history-consistent release record with independently matched source identities; release-owner approval remains the intended gate.
Proof confidence	🐚 platinum hermit (4/6)	Sufficient (terminal): Direct Git inspection independently matched the PR's tag object and peeled commit to v0.41.4 and confirmed the source is ancestral to the PR head.
Patch quality	🦞 diamond lobster (5/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (terminal): Direct Git inspection independently matched the PR's tag object and peeled commit to v0.41.4 and confirmed the source is ancestral to the PR head.
Evidence reviewed	6 items	Record matches verifier contract: The added record supplies the required schema version, repository, tag, tag-object, source-commit, and ready publication state that the protected verifier compares before allowing a publishable release. Exact tag identity confirmed: Local Git resolves v0.41.4 to tag object fcfd27062df39f3d4b6689dd786ba2dc96f310cb and its peeled commit to 5390447, exactly matching the proposed record. Source remains in the authorization history: The tagged source commit is an ancestor of the PR head, satisfying the verifier's protected-history relationship after merge.
Findings	None	None.
Security	None	None.

How this fits together

Release records bind an annotated release tag to its exact source commit. The protected release verifier consumes that record before candidate build, draft creation, or publication can proceed.

flowchart LR
  A[Signed release tag] --> B[Tag object and source commit]
  B --> C[Release authorization record]
  C --> D[Protected source verifier]
  D --> E[Candidate build]
  E --> F[Draft and publication gates]

Loading

Decision needed

Question	Recommendation
Should the protected v0.41.4 source binding be authorized for downstream release processing?	Authorize the verified binding: Approve merge of the record after confirming that fcfd27062df39f3d4b6689dd786ba2dc96f310cb and 5390447 are the intended v0.41.4 identities.

Why: The record is structurally correct, but changing it to ready is a deliberate release-trust decision reserved for the code-owner boundary.

Before merge

• Resolve merge risk (P1) - Merging changes the protected release state to publishable for v0.41.4, so a release-code-owner must confirm that this exact immutable tag/source binding is intended before downstream release gates run.
• Complete next step (P2) - Release-code-owner authorization is required before merging this protected ready-state record; no mechanical repair is indicated.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Release authorization surface	1 record added; 8 lines; 0 executable or workflow files changed	The PR is narrowly limited to the immutable source-identity gate for one release.

Merge-risk options

Maintainer options:

1. Approve the immutable release binding (recommended)
   A release code owner should confirm the checked tag object and peeled source commit before this ready record enables later protected release gates.

Technical review

Best possible solution:

Merge only after the release security code owner confirms the exact v0.41.4 tag object and source commit, then let the existing protected verifier govern all subsequent release stages.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is release authorization metadata, and direct Git inspection confirms that both stored identities resolve to the current v0.41.4 tag and source commit.

Is this the best way to solve the issue?

Yes: a protected immutable record is the documented mechanism for authorizing an already-created signed tag without collapsing later build, draft, and publication gates.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 5390447e3b02.

Labels

Label changes:

• add P2: This is a bounded release workflow gate needed to make the prepared v0.41.4 source eligible for normal protected release processing.
• add merge-risk: 🚨 security-boundary: A ready release record authorizes a later protected publication path, so code-owner confirmation matters even though the values are correct.
• add proof: sufficient: Contributor real behavior proof is sufficient. Direct Git inspection independently matched the PR's tag object and peeled commit to v0.41.4 and confirmed the source is ancestral to the PR head.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🦞 diamond lobster.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): Direct Git inspection independently matched the PR's tag object and peeled commit to v0.41.4 and confirmed the source is ancestral to the PR head.

Label justifications:

• P2: This is a bounded release workflow gate needed to make the prepared v0.41.4 source eligible for normal protected release processing.
• merge-risk: 🚨 security-boundary: A ready release record authorizes a later protected publication path, so code-owner confirmation matters even though the values are correct.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🦞 diamond lobster.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): Direct Git inspection independently matched the PR's tag object and peeled commit to v0.41.4 and confirmed the source is ancestral to the PR head.
• proof: sufficient: Contributor real behavior proof is sufficient. Direct Git inspection independently matched the PR's tag object and peeled commit to v0.41.4 and confirmed the source is ancestral to the PR head.

Evidence

What I checked:

• Record matches verifier contract: The added record supplies the required schema version, repository, tag, tag-object, source-commit, and ready publication state that the protected verifier compares before allowing a publishable release. (scripts/verify-release-source.sh:39, 5390447e3b02)
• Exact tag identity confirmed: Local Git resolves v0.41.4 to tag object fcfd27062df39f3d4b6689dd786ba2dc96f310cb and its peeled commit to 5390447, exactly matching the proposed record. (release/records/v0.41.4.json:5, f38e00699992)
• Source remains in the authorization history: The tagged source commit is an ancestor of the PR head, satisfying the verifier's protected-history relationship after merge. (scripts/verify-release-source.sh:87, f38e00699992)
• Established release-record pattern: Git history shows the immediately preceding v0.41.3 authorization used the same one-record, eight-line form and was authored by the same release-area contributor. (release/records/v0.41.3.json:1, cf99ea8d59e4)
• Protected ownership boundary: Release records are code-owned by the release security team, and release documentation describes the tag-object and peeled-commit identities as immutable trust anchors. (.github/CODEOWNERS:7, 5390447e3b02)
• Autoreview availability: The bundled autoreview helper could not run because TruffleHog is unavailable in this reviewer environment; the manual review does not rely on a claimed clean helper result. (.agents/skills/autoreview/SKILL.md:1, f38e00699992)

Likely related people:

• steipete: Authored this record, the immediately preceding v0.41.3 authorization, and the tagged v0.41.4 source commit. (role: release-record author and recent release-area contributor; confidence: high; commits: f38e00699992, cf99ea8d59e4, 5390447e3b02; files: release/records/v0.41.4.json, release/records/v0.41.3.json)
• openclaw/openclaw-secops: CODEOWNERS assigns the release-record directory to this team, which owns approval of this protected release boundary. (role: required code-owner team; confidence: high; files: .github/CODEOWNERS, release/records/v0.41.4.json)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Obtain release-code-owner confirmation of the immutable v0.41.4 binding before merge.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.