[steipete]

Why

Commit 990a6aa0 changed source text from release-candidate state to published state, but no Peekaboo 4 publication occurred. The source therefore claimed a release that does not exist.

Live evidence as of 2026-08-10:

• GitHub Release v4.0.0 returns 404, and the latest Release remains v3.10.0.
• Git tag v4.0.0 returns 404; git ls-remote returns no matching tag.
• npm registry entry for 4.0.0 returns 404; npm latest remains 3.10.0.
• appcast.xml contains no 4.0.0 item.

Change

Exactly revert 990a6aa0 so the source returns to the #371 state:

• both changelogs: 4.0.0 - Unreleased
• README and changelog: upcoming-release tense
• release/release-notes.md: last actually published release, 3.10.0

Version metadata remains 4.0.0. No appcast, tag, GitHub Release, npm package, notarization, or credential state is touched.

Proof

• exact four-file tree matches 102be49f (fix(release): keep v4 source claims honest #371)
• pnpm run test:release-preflight — 7/7
• pnpm run prepare-release -- --dry-run --bin Apps/CLI/.build/debug/peekaboo
• pnpm run lint:docs
• pnpm run docs:site
• pnpm run test:safe — 759 Core CLI tests and 72 runtime tests
• autoreview clean; TruffleHog clean

[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 10, 2026, 8:38 AM ET / 12:38 UTC.

ClawSweeper review

What this changes

The PR changes the two 4.0.0 changelog headings, README wording, and release notes back from published-release text to the unpublished candidate state.

Regression provenance

Possible regression — suspected (reviewed change). No predecessor PR is attributed.

Merge readiness

⚠️ Ready for maintainer review - 1 item remains

Keep open. This focused collaborator PR exactly restores the documented pre-publication state after current main marked 4.0.0 as released despite no local tag containing that publication commit and the supplied release evidence showing v3.10.0 remains latest.

Priority: P2
Reviewed head: 62fd8a54c939634a33db2c4af3659ff67d089cd9

Review scores

Measure	Result	What it means
Overall readiness	🦞 diamond lobster (5/6)	The patch is a small, exact, policy-aligned reversion with clear current-main provenance.
Proof confidence	🌊 off-meta tidepool	Not applicable: This collaborator PR corrects release documentation and metadata; the external-contributor real-behavior-proof gate does not apply.
Patch quality	🦞 diamond lobster (5/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This collaborator PR corrects release documentation and metadata; the external-contributor real-behavior-proof gate does not apply.
Evidence reviewed	5 items	Release policy: The release checklist requires candidate changelog sections to remain Unreleased through preparation and validation, and says dates belong only in the publication commit; it also requires a tag and non-draft GitHub Release during verification. Exact restoration: The four files at the PR head are byte-identical to their state in merged PR 371, before current main's publication-text commit. History provenance: Current-main blame attributes the published-looking 4.0.0 release-notes heading to the immediately preceding publication-text commit; the PR is its exact inverse.
Findings	None	None.
Security	None	None.

How this fits together

Peekaboo’s changelogs, README, and release notes communicate release state to users and release operators. The release-preflight tooling consumes the changelog state before publication, while published artifacts add the tag, GitHub release, npm package, and appcast entry.

flowchart LR
  A[Candidate source text] --> B[Changelogs and README]
  B --> C[Release preflight]
  C --> D[Publication workflow]
  D --> E[Tag npm appcast and GitHub release]
  E --> F[Published release state]

Loading

Before merge

• Complete next step (P2) - No repair lane is needed: this collaborator PR already contains the narrow, exact reversion and has no actionable review defect.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Release-documentation scope	4 files affected; 12 additions and 117 deletions	The patch is limited to reversing the release-facing text introduced by the immediately preceding main commit.

Technical review

Best possible solution:

Merge the exact reversion so source documentation remains in the candidate state until the complete public 4.0.0 publication workflow has run.

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

Not applicable: this is a source and release-metadata correction rather than a runtime defect. Current history and the release-preflight contract establish the relevant verification path.

Is this the best way to solve the issue?

Yes. Given the supplied absence of public 4.0.0 artifacts, an exact inverse of the publication-text commit is the narrowest way to restore the repository’s documented candidate state.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 990a6aa0e4f2.

Labels

Label changes:

• add P2: Incorrect public release state can mislead users and release operators, but the correction is limited to unpublished release metadata.
• add rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🌊 off-meta tidepool and patch quality is 🦞 diamond lobster.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This collaborator PR corrects release documentation and metadata; the external-contributor real-behavior-proof gate does not apply.

Label justifications:

• P2: Incorrect public release state can mislead users and release operators, but the correction is limited to unpublished release metadata.
• rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🌊 off-meta tidepool and patch quality is 🦞 diamond lobster.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This collaborator PR corrects release documentation and metadata; the external-contributor real-behavior-proof gate does not apply.

Evidence

What I checked:

• Release policy: The release checklist requires candidate changelog sections to remain Unreleased through preparation and validation, and says dates belong only in the publication commit; it also requires a tag and non-draft GitHub Release during verification. (docs/RELEASING.md:20, 990a6aa0e4f2)
• Exact restoration: The four files at the PR head are byte-identical to their state in merged PR 371, before current main's publication-text commit. (release/release-notes.md:1, 62fd8a54c939)
• History provenance: Current-main blame attributes the published-looking 4.0.0 release-notes heading to the immediately preceding publication-text commit; the PR is its exact inverse. (release/release-notes.md:1, 990a6aa0e4f2)
• Preflight contract: The release contract deliberately accepts Unreleased during preparation and requires a dated heading only for full publication preflight; its test covers that distinction. (scripts/release-preflight-contract.mjs:244, 990a6aa0e4f2)
• Release provenance check: No local tag contains the current publication-text commit; the latest supplied release is v3.10.0 at 99209e3. (990a6aa0e4f2)

Likely related people:

• steipete: Current history shows the same contributor authored the preceding release-source correction and the current-main publication-text commit. (role: introduced and recently revised the release-state behavior; confidence: high; commits: 102be49f25a1, 990a6aa0e4f2; files: CHANGELOG.md, Apps/CLI/CHANGELOG.md, README.md)

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.

[steipete]

Heads up before this merges: a release run is in flight right now and is past the point your evidence was gathered.

Your premise was correct when you wrote it — every earlier run failed, so 990a6aa0 did claim a release that did not exist. The blockers were, in order:

1. the OpenClaw release keychain had auto-locked, so Foundation signing returned errSecInternalComponent;
2. the login shell exports a personal SIGN_IDENTITY, which scripts/copy-swift-runtime-libraries.sh picks up as a fallback and which silently replaced the Foundation identity in the preflight;
3. the shared op-work tmux server had been bootstrapped outside the Aqua session, so no private-key signing could succeed inside it at all;
4. codesign-run could not read the keychain item, which lives in OpenClaw-Core and is unreachable by the Molty service account;
5. this Mac had no openclaw-release notarytool profile.

All five are fixed. The current run has produced a signed universal CLI, passed CLI notarization, built and signed the Mac app, and is now waiting on DMG notarization, with the GitHub Release and npm publish still to come.

So the choice is timing, not correctness. If the run finishes, merging this would leave a published 4.0.0 marked Unreleased, which is the same honesty problem inverted. If it fails, this revert is right and should land. I will report the outcome here either way before doing anything else with it.

[steipete]

Outcome, as promised: the release completed. ed3aaa47 re-applies this revert's four files because 4.0.0 now exists.

Proof:

• npm: @steipete/peekaboo@4.0.0 published, dist-tags.latest is 4.0.0; npm exec from /tmp against the registry copy prints Peekaboo 4.0.0.
• GitHub Release v4.0.0: published, not draft, not prerelease, marked latest, with all five assets.
• Tag v4.0.0 resolves to ed3aaa47, the publication commit itself.
• appcast.xml carries the signed 4.0.0 Sparkle item and passes xmllint.

Your revert was right for the window it covered, and it cost nothing — the artifacts were already built and notarized, so only npm publish and undrafting remained. The last two blockers after your evidence were the npm OTP requirement in a non-interactive shell, and this Mac having no openclaw-release notarytool profile; the profile is now provisioned from the same App Store Connect key.

One thing worth fixing separately: scripts/copy-swift-runtime-libraries.sh falls back to a bare SIGN_IDENTITY, so an operator's exported personal Developer ID silently replaces the Foundation identity in the preflight. It failed loudly here, but the same fallback in a signing lane could ship a wrongly-signed object. I would make the release lanes require MAC_RELEASE_CODESIGN_IDENTITY and ignore an inherited SIGN_IDENTITY.