Skip to content

Commit 34af897

Browse files
McMuff86McMuff86
authored
Merge branch 'main' into fix/ui-polling-intervals
2 parents b3f5ae6 + 4c60956 commit 34af897

4,649 files changed

Lines changed: 412780 additions & 155159 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎.agent/workflows/update_clawdbot.md‎

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,8 @@
11
---
2-
description: Update Clawdbot from upstream when branch has diverged (ahead/behind)
2+
description: Update OpenClaw from upstream when branch has diverged (ahead/behind)
33
---
44

5-
# Clawdbot Upstream Sync Workflow
5+
# OpenClaw Upstream Sync Workflow
66

77
Use this workflow when your fork has diverged from upstream (e.g., "18 commits ahead, 29 commits behind").
88

@@ -132,16 +132,16 @@ pnpm mac:package
132132

133133
```bash
134134
# Kill running app
135-
pkill -x "Clawdbot" || true
135+
pkill -x "OpenClaw" || true
136136

137137
# Move old version
138-
mv /Applications/Clawdbot.app /tmp/Clawdbot-backup.app
138+
mv /Applications/OpenClaw.app /tmp/OpenClaw-backup.app
139139

140140
# Install new build
141-
cp -R dist/Clawdbot.app /Applications/
141+
cp -R dist/OpenClaw.app /Applications/
142142

143143
# Launch
144-
open /Applications/Clawdbot.app
144+
open /Applications/OpenClaw.app
145145
```
146146

147147
---
@@ -235,7 +235,7 @@ If upstream introduced new model configurations:
235235
# Check for OpenRouter API key requirements
236236
grep -r "openrouter\|OPENROUTER" src/ --include="*.ts" --include="*.js"
237237

238-
# Update clawdbot.json with fallback chains
238+
# Update openclaw.json with fallback chains
239239
# Add model fallback configurations as needed
240240
```
241241

‎.agents/skills/openclaw-ghsa-maintainer/SKILL.md‎

Lines changed: 87 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
---
2+
name: openclaw-ghsa-maintainer
3+
description: Maintainer workflow for OpenClaw GitHub Security Advisories (GHSA). Use when Codex needs to inspect, patch, validate, or publish a repo advisory, verify private-fork state, prepare advisory Markdown or JSON payloads safely, handle GHSA API-specific publish constraints, or confirm advisory publish success.
4+
---
5+
6+
# OpenClaw GHSA Maintainer
7+
8+
Use this skill for repo security advisory workflow only. Keep general release work in `openclaw-release-maintainer`.
9+
10+
## Respect advisory guardrails
11+
12+
- Before reviewing or publishing a repo advisory, read `SECURITY.md`.
13+
- Ask permission before any publish action.
14+
- Treat this skill as GHSA-only. Do not use it for stable or beta release work.
15+
16+
## Fetch and inspect advisory state
17+
18+
Fetch the current advisory and the latest published npm version:
19+
20+
```bash
21+
gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
22+
npm view openclaw version --userconfig "$(mktemp)"
23+
```
24+
25+
Use the fetch output to confirm the advisory state, linked private fork, and vulnerability payload shape before patching.
26+
27+
## Verify private fork PRs are closed
28+
29+
Before publishing, verify that the advisory's private fork has no open PRs:
30+
31+
```bash
32+
fork=$(gh api /repos/openclaw/openclaw/security-advisories/<GHSA> | jq -r .private_fork.full_name)
33+
gh pr list -R "$fork" --state open
34+
```
35+
36+
The PR list must be empty before publish.
37+
38+
## Prepare advisory Markdown and JSON safely
39+
40+
- Write advisory Markdown via heredoc to a temp file. Do not use escaped `\n` strings.
41+
- Build PATCH payload JSON with `jq`, not hand-escaped shell JSON.
42+
43+
Example pattern:
44+
45+
```bash
46+
cat > /tmp/ghsa.desc.md <<'EOF'
47+
<markdown description>
48+
EOF
49+
50+
jq -n --rawfile desc /tmp/ghsa.desc.md \
51+
'{summary,severity,description:$desc,vulnerabilities:[...]}' \
52+
> /tmp/ghsa.patch.json
53+
```
54+
55+
## Apply PATCH calls in the correct sequence
56+
57+
- Do not set `severity` and `cvss_vector_string` in the same PATCH call.
58+
- Use separate calls when the advisory requires both fields.
59+
- Publish by PATCHing the advisory and setting `"state":"published"`. There is no separate `/publish` endpoint.
60+
61+
Example shape:
62+
63+
```bash
64+
gh api -X PATCH /repos/openclaw/openclaw/security-advisories/<GHSA> \
65+
--input /tmp/ghsa.patch.json
66+
```
67+
68+
## Publish and verify success
69+
70+
After publish, re-fetch the advisory and confirm:
71+
72+
- `state=published`
73+
- `published_at` is set
74+
- the description does not contain literal escaped `\\n`
75+
76+
Verification pattern:
77+
78+
```bash
79+
gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
80+
jq -r .description < /tmp/ghsa.refetch.json | rg '\\\\n'
81+
```
82+
83+
## Common GHSA footguns
84+
85+
- Publishing fails with HTTP 422 if required fields are missing or the private fork still has open PRs.
86+
- A payload that looks correct in shell can still be wrong if Markdown was assembled with escaped newline strings.
87+
- Advisory PATCH sequencing matters; separate field updates when GHSA API constraints require it.

‎.agents/skills/openclaw-parallels-smoke/SKILL.md‎

Lines changed: 58 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,58 @@
1+
---
2+
name: openclaw-parallels-smoke
3+
description: End-to-end Parallels smoke, upgrade, and rerun workflow for OpenClaw across macOS, Windows, and Linux guests. Use when Codex needs to run, rerun, debug, or interpret VM-based install, onboarding, gateway smoke tests, latest-release-to-main upgrade checks, fresh snapshot retests, or optional Discord roundtrip verification under Parallels.
4+
---
5+
6+
# OpenClaw Parallels Smoke
7+
8+
Use this skill for Parallels guest workflows and smoke interpretation. Do not load it for normal repo work.
9+
10+
## Global rules
11+
12+
- Use the snapshot most closely matching the requested fresh baseline.
13+
- Gateway verification in smoke runs should use `openclaw gateway status --deep --require-rpc` unless the stable version being checked does not support it yet.
14+
- Stable `2026.3.12` pre-upgrade diagnostics may require a plain `gateway status --deep` fallback.
15+
- Treat `precheck=latest-ref-fail` on that stable pre-upgrade lane as baseline, not automatically a regression.
16+
- Pass `--json` for machine-readable summaries.
17+
- Per-phase logs land under `/tmp/openclaw-parallels-*`.
18+
- Do not run local and gateway agent turns in parallel on the same fresh workspace or session.
19+
20+
## macOS flow
21+
22+
- Preferred entrypoint: `pnpm test:parallels:macos`
23+
- Target the snapshot closest to `macOS 26.3.1 fresh`.
24+
- `prlctl exec` is fine for deterministic repo commands, but use the guest Terminal or `prlctl enter` when installer parity or shell-sensitive behavior matters.
25+
- On the fresh Tahoe snapshot, `brew` exists but `node` may be missing from PATH in noninteractive exec. Use `/opt/homebrew/bin/node` when needed.
26+
- Fresh host-served tgz installs should install as guest root with `HOME=/var/root`, then run onboarding as the desktop user via `prlctl exec --current-user`.
27+
- Root-installed tgz smoke can log plugin blocks for world-writable `extensions/*`; do not treat that as an onboarding or gateway failure unless plugin loading is the task.
28+
29+
## Windows flow
30+
31+
- Preferred entrypoint: `pnpm test:parallels:windows`
32+
- Use the snapshot closest to `pre-openclaw-native-e2e-2026-03-12`.
33+
- Always use `prlctl exec --current-user`; plain `prlctl exec` lands in `NT AUTHORITY\\SYSTEM`.
34+
- Prefer explicit `npm.cmd` and `openclaw.cmd`.
35+
- Use PowerShell only as the transport with `-ExecutionPolicy Bypass`, then call the `.cmd` shims from inside it.
36+
- Keep onboarding and status output ASCII-clean in logs; fancy punctuation becomes mojibake in current capture paths.
37+
38+
## Linux flow
39+
40+
- Preferred entrypoint: `pnpm test:parallels:linux`
41+
- Use the snapshot closest to fresh `Ubuntu 24.04.3 ARM64`.
42+
- Use plain `prlctl exec`; `--current-user` is not the right transport on this snapshot.
43+
- Fresh snapshots may be missing `curl`, and `apt-get update` can fail on clock skew. Bootstrap with `apt-get -o Acquire::Check-Date=false update` and install `curl ca-certificates`.
44+
- Fresh `main` tgz smoke still needs the latest-release installer first because the snapshot has no Node or npm before bootstrap.
45+
- This snapshot does not have a usable `systemd --user` session; managed daemon install is unsupported.
46+
- `prlctl exec` reaps detached Linux child processes on this snapshot, so detached background gateway runs are not trustworthy smoke signals.
47+
48+
## Discord roundtrip
49+
50+
- Discord roundtrip is optional and should be enabled with:
51+
- `--discord-token-env`
52+
- `--discord-guild-id`
53+
- `--discord-channel-id`
54+
- Keep the Discord token only in a host env var.
55+
- Use installed `openclaw message send/read`, not `node openclaw.mjs message ...`.
56+
- Set `channels.discord.guilds` as one JSON object, not dotted config paths with snowflakes.
57+
- Avoid long `prlctl enter` or expect-driven Discord config scripts; prefer `prlctl exec --current-user /bin/sh -lc ...` with short commands.
58+
- For a narrower macOS-only Discord proof run, the existing `parallels-discord-roundtrip` skill is the deep-dive companion.

‎.agents/skills/openclaw-pr-maintainer/SKILL.md‎

Lines changed: 75 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
---
2+
name: openclaw-pr-maintainer
3+
description: Maintainer workflow for reviewing, triaging, preparing, closing, or landing OpenClaw pull requests and related issues. Use when Codex needs to validate bug-fix claims, search for related issues or PRs, apply or recommend close/reason labels, prepare GitHub comments safely, check review-thread follow-up, or perform maintainer-style PR decision making before merge or closure.
4+
---
5+
6+
# OpenClaw PR Maintainer
7+
8+
Use this skill for maintainer-facing GitHub workflow, not for ordinary code changes.
9+
10+
## Apply close and triage labels correctly
11+
12+
- If an issue or PR matches an auto-close reason, apply the label and let `.github/workflows/auto-response.yml` handle the comment/close/lock flow.
13+
- Do not manually close plus manually comment for these reasons.
14+
- `r:*` labels can be used on both issues and PRs.
15+
- Current reasons:
16+
- `r: skill`
17+
- `r: support`
18+
- `r: no-ci-pr`
19+
- `r: too-many-prs`
20+
- `r: testflight`
21+
- `r: third-party-extension`
22+
- `r: moltbook`
23+
- `r: spam`
24+
- `invalid`
25+
- `dirty` for PRs only
26+
27+
## Enforce the bug-fix evidence bar
28+
29+
- Never merge a bug-fix PR based only on issue text, PR text, or AI rationale.
30+
- Before landing, require:
31+
1. symptom evidence such as a repro, logs, or a failing test
32+
2. a verified root cause in code with file/line
33+
3. a fix that touches the implicated code path
34+
4. a regression test when feasible, or explicit manual verification plus a reason no test was added
35+
- If the claim is unsubstantiated or likely wrong, request evidence or changes instead of merging.
36+
- If the linked issue appears outdated or incorrect, correct triage first. Do not merge a speculative fix.
37+
38+
## Handle GitHub text safely
39+
40+
- For issue comments and PR comments, use literal multiline strings or `-F - <<'EOF'` for real newlines. Never embed `\n`.
41+
- Do not use `gh issue/pr comment -b "..."` when the body contains backticks or shell characters. Prefer a single-quoted heredoc.
42+
- Do not wrap issue or PR refs like `#24643` in backticks when you want auto-linking.
43+
- PR landing comments should include clickable full commit links for landed and source SHAs when present.
44+
45+
## Search broadly before deciding
46+
47+
- Prefer targeted keyword search before proposing new work or closing something as duplicate.
48+
- Use `--repo openclaw/openclaw` with `--match title,body` first.
49+
- Add `--match comments` when triaging follow-up discussion.
50+
- Do not stop at the first 500 results when the task requires a full search.
51+
52+
Examples:
53+
54+
```bash
55+
gh search prs --repo openclaw/openclaw --match title,body --limit 50 -- "auto-update"
56+
gh search issues --repo openclaw/openclaw --match title,body --limit 50 -- "auto-update"
57+
gh search issues --repo openclaw/openclaw --match title,body --limit 50 \
58+
--json number,title,state,url,updatedAt -- "auto update" \
59+
--jq '.[] | "\(.number) | \(.state) | \(.title) | \(.url)"'
60+
```
61+
62+
## Follow PR review and landing hygiene
63+
64+
- If bot review conversations exist on your PR, address them and resolve them yourself once fixed.
65+
- Leave a review conversation unresolved only when reviewer or maintainer judgment is still needed.
66+
- When landing or merging any PR, follow the global `/landpr` process.
67+
- Use `scripts/committer "<msg>" <file...>` for scoped commits instead of manual `git add` and `git commit`.
68+
- Keep commit messages concise and action-oriented.
69+
- Group related changes; avoid bundling unrelated refactors.
70+
- Use `.github/pull_request_template.md` for PR submissions and `.github/ISSUE_TEMPLATE/` for issues.
71+
72+
## Extra safety
73+
74+
- If a close or reopen action would affect more than 5 PRs, ask for explicit confirmation with the exact count and target query first.
75+
- `sync` means: if the tree is dirty, commit all changes with a sensible Conventional Commit message, then `git pull --rebase`, then `git push`. Stop if rebase conflicts cannot be resolved safely.

‎.agents/skills/openclaw-release-maintainer/SKILL.md‎

Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
---
2+
name: openclaw-release-maintainer
3+
description: Maintainer workflow for OpenClaw releases, prereleases, changelog release notes, and publish validation. Use when Codex needs to prepare or verify stable or beta release steps, align version naming, assemble release notes, check release auth requirements, or validate publish-time commands and artifacts.
4+
---
5+
6+
# OpenClaw Release Maintainer
7+
8+
Use this skill for release and publish-time workflow. Keep ordinary development changes and GHSA-specific advisory work outside this skill.
9+
10+
## Respect release guardrails
11+
12+
- Do not change version numbers without explicit operator approval.
13+
- Ask permission before any npm publish or release step.
14+
- Use the private maintainer release docs for the actual runbook and `docs/reference/RELEASING.md` for public policy.
15+
16+
## Keep release channel naming aligned
17+
18+
- `stable`: tagged releases only, with npm dist-tag `latest`
19+
- `beta`: prerelease tags like `vYYYY.M.D-beta.N`, with npm dist-tag `beta`
20+
- Prefer `-beta.N`; do not mint new `-1` or `-2` beta suffixes
21+
- `dev`: moving head on `main`
22+
- When using a beta Git tag, publish npm with the matching beta version suffix so the plain version is not consumed or blocked
23+
24+
## Handle versions and release files consistently
25+
26+
- Version locations include:
27+
- `package.json`
28+
- `apps/android/app/build.gradle.kts`
29+
- `apps/ios/Sources/Info.plist`
30+
- `apps/ios/Tests/Info.plist`
31+
- `apps/macos/Sources/OpenClaw/Resources/Info.plist`
32+
- `docs/install/updating.md`
33+
- Peekaboo Xcode project and plist version fields
34+
- “Bump version everywhere” means all version locations above except `appcast.xml`.
35+
- Release signing and notary credentials live outside the repo in the private maintainer docs.
36+
37+
## Build changelog-backed release notes
38+
39+
- Changelog entries should be user-facing, not internal release-process notes.
40+
- When cutting a mac release with a beta GitHub prerelease:
41+
- tag `vYYYY.M.D-beta.N` from the release commit
42+
- create a prerelease titled `openclaw YYYY.M.D-beta.N`
43+
- use release notes from the matching `CHANGELOG.md` version section
44+
- attach at least the zip and dSYM zip, plus dmg if available
45+
- Keep the top version entries in `CHANGELOG.md` sorted by impact:
46+
- `### Changes` first
47+
- `### Fixes` deduped with user-facing fixes first
48+
49+
## Run publish-time validation
50+
51+
Before tagging or publishing, run:
52+
53+
```bash
54+
node --import tsx scripts/release-check.ts
55+
pnpm release:check
56+
pnpm test:install:smoke
57+
```
58+
59+
For a non-root smoke path:
60+
61+
```bash
62+
OPENCLAW_INSTALL_SMOKE_SKIP_NONROOT=1 pnpm test:install:smoke
63+
```
64+
65+
## Use the right auth flow
66+
67+
- Core `openclaw` publish uses GitHub trusted publishing.
68+
- Do not use `NPM_TOKEN` or the plugin OTP flow for core releases.
69+
- `@openclaw/*` plugin publishes use a separate maintainer-only flow.
70+
- Only publish plugins that already exist on npm; bundled disk-tree-only plugins stay unpublished.
71+
72+
## GHSA advisory work
73+
74+
- Use `openclaw-ghsa-maintainer` for GHSA advisory inspection, patch/publish flow, private-fork validation, and GHSA API-specific publish checks.

0 commit comments

Comments
 (0)