chore(release): prepare 1.1.0

[steipete]

Prepare 1.1.0 for the accumulated session/surface APIs, Gateway protocol support, teardown and credential-handling fixes, and room build repairs. The new public APIs make this a minor release. Finalize all 17 changelog entries with highlights and contributor credit, retain an empty Unreleased section, and align delivery documentation with the core registry package and full source release.

Host validation on AWS Crabbox passed: 112 script tests with no skips; five real filesystem scenarios; 19 Talk routing/adapter cases; 24 pthread lifetime cases and public-layout checks; 12 exchanges through the actual ESP-IDF Linux HTTP client, with no requests following any redirect. The release checker’s 11 tests and public 1.1.0 absence preflight passed. Codex autoreview is scoped-clean at P0–P2.

After this PR passes all firmware jobs and release validation, publication uses the existing manual OIDC workflow on main. The registered ZIP’s version, repository, component path, and commit SHA must match before creating the matching GitHub tag and Release with the changelog section verbatim.

Hardware qualification was not performed: no flashing, on-device Unity execution, live Gateway pairing/reconnect, acoustic wake/Talk, display/Canvas, camera/DMA, SD-card removal, or C6 coprocessor qualification. Firmware CI plus host checks are the accepted release gate.

Final gate: all five firmware jobs, release validation, and CodeQL passed at exact head 9f2719f5fe74fb5aef641f12045463b31686c9c3.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

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

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge. Reviewed September 24, 2026, 5:09 AM ET / 09:09 UTC.

ClawSweeper review

What this changes

Bumps the ESP-IDF component manifest to 1.1.0, finalizes the accumulated changelog, and documents registry and source-release delivery.

Merge readiness

⛔ Blocked before merge - 3 items remain

Keep open. The 1.1.0 preparation is absent from main, but the getting-started guide presents the source release as available before the required manual publication has occurred.

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

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	Focused release preparation has a correctable availability claim and still needs the planned release authorization.
Proof confidence	🌊 off-meta tidepool	Not applicable: The MEMBER-authored release-preparation PR is exempt from contributor proof. Its body reports host validation of accumulated behavior, while the first live 1.1.0 publication remains a separately approved release step; no stored-data contract changes here.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: The MEMBER-authored release-preparation PR is exempt from contributor proof. Its body reports host validation of accumulated behavior, while the first live 1.1.0 publication remains a separately approved release step; no stored-data contract changes here.
Evidence reviewed	9 items	Introduced release preparation: The pinned PR changes three documentation files and the component manifest; it adds no firmware source changes. Premature availability statement: The new guide says the v1.1.0 source release and matching registry version are available, although publication is planned after this PR. Publication remains manual: The upload job runs only for a manual dispatch on main, checks the expected version, and verifies the registered archive. The new release guide calls for tagging after that verification.
Findings	1 actionable finding	[P2] Describe 1.1.0 artifacts as pending until publication
Security	None	None.

How this fits together

The component manifest identifies the ESP32 node library version. After release approval, a manual workflow uploads the core component to Espressif’s registry; a matching GitHub tag supplies the full source and room examples.

flowchart TD
  A[Source and release notes] --> B[Versioned component manifest]
  B --> C{Release approved and qualified?}
  C -->|Yes| D[Manual registry upload]
  D --> E[Verify package identity]
  E --> F[GitHub source release]
  F --> G[User delivery guidance]

Loading

Decision needed

Question	Recommendation
Does the release owner approve 1.1.0 as the first manually published version under the accepted host and firmware qualification gate?	Approve after qualification: Approve 1.1.0 after the five firmware jobs pass and the availability wording is corrected, then verify the manual upload before tagging.

Why: The merged release-workflow decision requires separate approval for a new version and leaves the first live OIDC upload and archive verification to this release.

Before merge

• Describe 1.1.0 artifacts as pending until publication (P2) - The existing workflow requires a manual upload, archive verification, and then a GitHub tag and Release. No v1.1.0 tag or Release exists yet, so this guide would tell readers that an unavailable source release is already published. Use conditional wording until those artifacts are verified.
• Complete next step (P2) - Correct the guide’s premature availability claim, confirm the five firmware builds, and obtain release-owner approval before publication.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Findings

• [P2] Describe 1.1.0 artifacts as pending until publication — docs/getting-started.md:46-47

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Release scope	17 changelog entries; 1 version bump; 0 firmware source files changed	This PR packages accumulated mainline behavior for publication without introducing runtime code.

Technical review

Best possible solution:

Keep the 1.1.0 preparation, describe artifacts as available only after publication, and have the release owner verify the registered archive before tagging the same source commit.

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

Not applicable as a runtime bug. The premature release-availability claim is directly checkable: main still says 1.0.0, and GitHub has no v1.1.0 tag or Release.

Is this the best way to solve the issue?

No, as written. The manual release sequence fits the existing policy, but the getting-started guide must make artifact availability conditional until publication.

Full review comments:

• [P2] Describe 1.1.0 artifacts as pending until publication — docs/getting-started.md:46-47
  The existing workflow requires a manual upload, archive verification, and then a GitHub tag and Release. No v1.1.0 tag or Release exists yet, so this guide would tell readers that an unavailable source release is already published. Use conditional wording until those artifacts are verified.
  Confidence: 0.97

Overall correctness: patch is incorrect
Overall confidence: 0.95

AGENTS.md: not found in the target repository.

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

Labels

Label changes:

• add P2: This is a bounded release preparation with a user-facing documentation error and a separate release approval.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The MEMBER-authored release-preparation PR is exempt from contributor proof. Its body reports host validation of accumulated behavior, while the first live 1.1.0 publication remains a separately approved release step; no stored-data contract changes here.

Label justifications:

• P2: This is a bounded release preparation with a user-facing documentation error and a separate release approval.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The MEMBER-authored release-preparation PR is exempt from contributor proof. Its body reports host validation of accumulated behavior, while the first live 1.1.0 publication remains a separately approved release step; no stored-data contract changes here.

Evidence

What I checked:

• Introduced release preparation: The pinned PR changes three documentation files and the component manifest; it adds no firmware source changes. (components/esp-openclaw-node/idf_component.yml:1, 9f2719f5fe74)
• Premature availability statement: The new guide says the v1.1.0 source release and matching registry version are available, although publication is planned after this PR. (docs/getting-started.md:46, 9f2719f5fe74)
• Publication remains manual: The upload job runs only for a manual dispatch on main, checks the expected version, and verifies the registered archive. The new release guide calls for tagging after that verification. (.github/workflows/upload_component.yml:39, b8c918d99b4f)
• Main still has version 1.0.0: The main-parent manifest identifies version 1.0.0, so this PR's version bump is still distinct work. (components/esp-openclaw-node/idf_component.yml:1, b8c918d99b4f)
• No published GitHub release: The repository releases endpoint returned an empty list.
• No source tag: The repository tags endpoint returned an empty list.

Likely related people:

• Vincent Koc: Raw commit 675485e adds docs/component-releases.md:3 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: 675485e6b388; files: docs/component-releases.md)
• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rank-up moves

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

• Make the getting-started availability text conditional until the registry artifact and matching source release exist.

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.