chore: add maintainer setup baseline

[vincentkoc]

Summary

• add maintainer setup baseline files for this repository\n- add CODEOWNERS, Dependabot, SECURITY.md, CodeQL, stale automation, and Crabbox/autoreview support

Verification

• git diff --check
• ruby YAML.load_file for added/changed YAML files
• actionlint for added/changed workflow files
• private-data scan for added/changed non-skill setup files (fs-safe only false-positive matched PNPM_VERSION 10.33.2)
• verified Crabbox skill SHA-256 matches openclaw/openclaw: ed512c0b0385fae7f6c5c14a7e9e6236ab68936506687a99ca976873492bdc43

Runtime tests were not run; this is setup, policy, and workflow metadata only.

[clawsweeper]

Codex review: needs changes before merge.

Latest ClawSweeper review: 2026-05-22 13:09 UTC / May 22, 2026, 9:09 AM ET.

Workflow note: Future ClawSweeper reviews update this same comment in place.

How this review workflow works

• 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.

Summary
The PR adds repository governance and automation baseline files: CODEOWNERS, Dependabot, SECURITY.md, CodeQL, stale automation, Crabbox configuration, and bundled autoreview/Crabbox skills.

Reproducibility: not applicable. this is repository administration and workflow metadata rather than a runtime bug. The blocking behavior is source-verifiable from the added workflow YAML.

PR rating
Overall: 🧂 unranked krab
Proof: 🌊 off-meta tidepool
Patch quality: 🧂 unranked krab
Summary: The baseline is useful setup work, but the workflow supply-chain issue makes the patch not merge-ready.

Rank-up moves:

• Pin every added workflow action to a full commit SHA with version comments.
• Have maintainers confirm the stale auto-close policy before enabling the scheduled workflow.

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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.

Real behavior proof
Not applicable: The real-behavior-proof gate does not apply to this maintainer/member setup PR; the PR body lists static verification instead of runtime proof.

Risk before merge

• Merging as-is would enable new scheduled, PR, push, and manual workflows that execute mutable GitHub Action major tags, unlike the current SHA-pinned workflow surface.
• The stale workflow has issue and PR write permissions and configures automatic closure policy; maintainers should explicitly confirm that repository administration behavior before enabling it.

Maintainer options:

1. Pin the new workflow actions (recommended)
   Resolve each new workflow uses ref to an immutable full-length commit SHA with version comments, matching the existing workflow style.
2. Approve the new stale policy
   Maintainers should explicitly accept the write-permission stale workflow and its auto-close timing before the repository starts running it on schedule.

Copy recommended automerge instruction

@clawsweeper automerge

Special instructions:
Pin every new GitHub Actions `uses:` reference in `.github/workflows/codeql.yml`, `.github/workflows/crabbox-hydrate.yml`, and `.github/workflows/stale.yml` to immutable full-length commit SHAs with version comments, matching the existing workflow style. Do not otherwise change workflow behavior; validate YAML and actionlint if available.

Next step before merge
A narrow automated repair can pin the added workflow action refs without deciding the broader stale policy.

Security
Needs attention: The PR introduces mutable GitHub Action refs in new workflows, which is a concrete supply-chain regression against the current SHA-pinned workflow pattern.

Review findings

• [P1] Pin the new workflow actions to immutable SHAs — .github/workflows/codeql.yml:23

Review details

Best possible solution:

Land the baseline only after pinning every new workflow action to immutable full-length SHAs and getting maintainer sign-off on the stale/Crabbox automation policy.

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

Not applicable; this is repository administration and workflow metadata rather than a runtime bug. The blocking behavior is source-verifiable from the added workflow YAML.

Is this the best way to solve the issue?

No; the baseline direction may be useful, but using mutable workflow action tags is not the best fit for this repo’s existing SHA-pinned workflow convention.

Label changes:

• add P2: The PR is normal-priority repository setup work, but it has a concrete merge-blocking workflow supply-chain issue.
• add merge-risk: 🚨 security-boundary: The new workflows would execute mutable action tags in repository automation instead of the current SHA-pinned pattern.
• add merge-risk: 🚨 automation: The PR adds scheduled/write-capable stale automation and Crabbox hydration workflows that can affect repository operations after merge.
• add rating: 🧂 unranked krab: Current PR rating is 🧂 unranked krab because proof is 🌊 off-meta tidepool, patch quality is 🧂 unranked krab, and The baseline is useful setup work, but the workflow supply-chain issue makes the patch not merge-ready.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The real-behavior-proof gate does not apply to this maintainer/member setup PR; the PR body lists static verification instead of runtime proof.

Label justifications:

• P2: The PR is normal-priority repository setup work, but it has a concrete merge-blocking workflow supply-chain issue.
• merge-risk: 🚨 security-boundary: The new workflows would execute mutable action tags in repository automation instead of the current SHA-pinned pattern.
• merge-risk: 🚨 automation: The PR adds scheduled/write-capable stale automation and Crabbox hydration workflows that can affect repository operations after merge.
• rating: 🧂 unranked krab: Current PR rating is 🧂 unranked krab because proof is 🌊 off-meta tidepool, patch quality is 🧂 unranked krab, and The baseline is useful setup work, but the workflow supply-chain issue makes the patch not merge-ready.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The real-behavior-proof gate does not apply to this maintainer/member setup PR; the PR body lists static verification instead of runtime proof.

Full review comments:

• [P1] Pin the new workflow actions to immutable SHAs — .github/workflows/codeql.yml:23
  The added workflows use mutable major tags such as actions/checkout@v6, actions/setup-go@v6, github/codeql-action@v4, and actions/stale@v10, while current workflows pin actions to full commit SHAs with version comments. These new workflows run on PR/push/schedule/manual paths, including repository write-capable stale automation, so merging them would add a mutable third-party code execution path. Please pin the added uses: refs before enabling the automation.
  Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.88

Security concerns:

• [high] Mutable workflow action refs — .github/workflows/codeql.yml:23
  New workflow actions are referenced by mutable major tags instead of immutable commit SHAs, including workflows that run on PR/push/schedule/manual events and stale automation with repository write permissions.
  Confidence: 0.9

Acceptance criteria:

• git diff --check
• ruby -e 'require "yaml"; ARGV.each { |f| YAML.load_file(f) }' .github/dependabot.yml .github/workflows/codeql.yml .github/workflows/crabbox-hydrate.yml .github/workflows/stale.yml .crabbox.yaml
• actionlint .github/workflows/codeql.yml .github/workflows/crabbox-hydrate.yml .github/workflows/stale.yml

What I checked:

• Maintainer-authored draft PR: The provided GitHub context shows authorAssociation MEMBER and draft=true, so this workflow should not auto-close it even though it can still review the diff.
• Added workflows use mutable action tags: The added CodeQL workflow uses actions/checkout@v6, actions/setup-go@v6, and github/codeql-action@v4 mutable major-version tags. (.github/workflows/codeql.yml:23, f7a0f3d2cd9e)
• All new workflow action refs are mutable: The PR adds mutable uses refs in codeql.yml, crabbox-hydrate.yml, and stale.yml, including actions/stale@v10. (f7a0f3d2cd9e)
• Current workflow pinning pattern: Current main pins existing workflow actions to full commit SHAs with version comments, for example actions/checkout and actions/setup-go in ci.yml. (.github/workflows/ci.yml:15, f4dbfd5cbf95)
• Workflow history provenance: git blame ties the existing pinned workflow action refs to release commit 7c511d8 by Peter Steinberger, showing the current workflow area convention and likely routing owner. (.github/workflows/ci.yml:15, 7c511d8dd731)
• Stale automation writes to issues and PRs: The new stale workflow grants issues:write and pull-requests:write and configures automatic stale/close behavior, so the policy should be explicitly accepted by maintainers before merge. (.github/workflows/stale.yml:12, f7a0f3d2cd9e)

Likely related people:

• Peter Steinberger: Existing workflow files on main blame to this author, and the release commit introduced the pinned workflow-action pattern used across current CI, release, Docker, Pages, and post-release workflows. (role: recent workflow area contributor; confidence: high; commits: 7c511d8dd731, f4dbfd5cbf95; files: .github/workflows/ci.yml, .github/workflows/release.yml, .github/workflows/docker.yml)

Codex review notes: model gpt-5.5, reasoning high; reviewed against f4dbfd5cbf95.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[clawsweeper]

ClawSweeper PR egg

🔥 Warming up: real-behavior proof passed; findings, security review, or rank-up moves are still in progress.

Hatch command

Comment @clawsweeper hatch when this PR is hatchable.

Hatchability rules:

• Merged PRs are hatchable.
• Open PRs are hatchable when they are status: 👀 ready for maintainer look, status: 🚀 automerge armed, or labeled clawsweeper:automerge.
• Closed unmerged PRs are hatchable only when one of those hatchable labels is still present in the durable record.

What is this egg doing here?

• Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
• The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
• Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
• The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
• Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.

[steipete]

Closing this in favor of the shared public skill source at https://github.com/openclaw/agent-skills.

We do not want to vendor the same maintainer skills into every repo. Repos that need zero-setup guidance should add a small pointer to openclaw/agent-skills; shared skill content should be updated there first and synced only where a vendored snapshot is intentionally required.