chore: add maintainer setup baseline

[vincentkoc]

Summary

• add maintainer setup baseline files for this repository
• add CODEOWNERS, Dependabot, SECURITY.md, CodeQL, stale automation, and Crabbox/autoreview support
• configure mixed Go and pnpm maintainer hydrate checks

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; PNPM_VERSION hits, where present, were false positives
• 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: found issues before merge.

Latest ClawSweeper review: 2026-05-22 14:44 UTC / May 22, 2026, 10:44 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 maintainer setup files: CODEOWNERS, Dependabot, SECURITY.md, CodeQL, stale automation, Crabbox hydrate workflow/config, and autoreview/Crabbox agent skills.

Reproducibility: not applicable. this is an admin/setup PR, not a runtime bug report. The merge risk is source-reviewable from the added workflow YAML and current main automation pattern.

PR rating
Overall: 🧂 unranked krab
Proof: 🌊 off-meta tidepool
Patch quality: 🧂 unranked krab
Summary: Not merge-ready until the privileged workflow Action refs are pinned or maintainers explicitly accept the tag-tracking risk.

Rank-up moves:

• Pin all newly added third-party Action refs to audited commit SHAs, keeping version comments for readability.
• Confirm whether the proposed stale close windows are intentional repository policy.

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: Real behavior proof is not required for this member-authored setup/policy PR; the relevant review evidence is workflow and repository metadata inspection.

Risk before merge

• New workflows run mutable third-party Action tags with security-events, issue, or pull-request write permissions; a tag retarget or compromised upstream action would execute unreviewed code in repository automation.
• The stale workflow would start automatically marking and closing issues and PRs on short inactivity windows, so maintainers should explicitly accept that repository policy before merge.
• The PR is draft and member-authored, so cleanup automation should not close or bypass maintainer review.

Maintainer options:

1. Pin workflow actions first (recommended)
   Pin every newly added third-party Action ref to an audited commit SHA, with version comments, matching the current CI and shared setup action pattern.
2. Accept tag tracking explicitly
   Maintainers may choose Dependabot-managed version tags, but that should be an explicit security decision because these workflows carry write permissions.
3. Pause stale automation
   If the repository is not ready for automatic stale labeling and closure, hold or remove the stale workflow from this baseline PR.

Next step before merge
Draft member-authored automation and policy changes need maintainer/security review, especially around Action pinning and stale automation policy.

Security
Needs attention: The PR adds security-sensitive workflow automation but does not pin third-party Actions to immutable SHAs.

Review findings

• [P1] Pin the new workflow action refs — .github/workflows/codeql.yml:23

Review details

Best possible solution:

Land a maintainer-approved setup baseline only after security-sensitive workflow refs are pinned or explicitly accepted and the stale policy is confirmed for this repository.

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

Not applicable: this is an admin/setup PR, not a runtime bug report. The merge risk is source-reviewable from the added workflow YAML and current main automation pattern.

Is this the best way to solve the issue?

No, not yet. The setup baseline is plausible, but the workflow refs should either be pinned to audited SHAs like current main or explicitly accepted by maintainers as a policy change.

Label changes:

• add P2: This is a normal-priority maintainer setup PR with a concrete automation security concern but no urgent user-facing regression.
• add merge-risk: 🚨 security-boundary: Merging mutable third-party Action refs into workflows with write scopes could weaken repository automation supply-chain boundaries.
• add merge-risk: 🚨 automation: The PR adds stale and Crabbox/CodeQL automation that can affect repository workflow behavior beyond what CI alone proves.
• add rating: 🧂 unranked krab: Current PR rating is 🧂 unranked krab because proof is 🌊 off-meta tidepool, patch quality is 🧂 unranked krab, and Not merge-ready until the privileged workflow Action refs are pinned or maintainers explicitly accept the tag-tracking risk.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: Real behavior proof is not required for this member-authored setup/policy PR; the relevant review evidence is workflow and repository metadata inspection.

Label justifications:

• P2: This is a normal-priority maintainer setup PR with a concrete automation security concern but no urgent user-facing regression.
• merge-risk: 🚨 security-boundary: Merging mutable third-party Action refs into workflows with write scopes could weaken repository automation supply-chain boundaries.
• merge-risk: 🚨 automation: The PR adds stale and Crabbox/CodeQL automation that can affect repository workflow behavior beyond what CI alone proves.
• rating: 🧂 unranked krab: Current PR rating is 🧂 unranked krab because proof is 🌊 off-meta tidepool, patch quality is 🧂 unranked krab, and Not merge-ready until the privileged workflow Action refs are pinned or maintainers explicitly accept the tag-tracking risk.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: Real behavior proof is not required for this member-authored setup/policy PR; the relevant review evidence is workflow and repository metadata inspection.

Full review comments:

• [P1] Pin the new workflow action refs — .github/workflows/codeql.yml:23
  Current CI and the shared setup action pin third-party Actions to commit SHAs, but the new workflows use mutable version tags such as actions/checkout@v6, actions/setup-go@v6, github/codeql-action@v4, and actions/stale@v10 while granting write scopes like security-events and issue/PR writes. A tag retarget would run new code with those permissions, so pin the added refs to audited SHAs or route through the existing pinned setup action before merging.
  Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.86

Security concerns:

• [high] Mutable Actions run with write-scoped tokens — .github/workflows/codeql.yml:23
  The added workflows use version tags for third-party Actions while granting security-events: write or issue/PR write permissions, diverging from current main's SHA-pinned workflow pattern and leaving automation exposed to tag retargeting or upstream compromise.
  Confidence: 0.9

What I checked:

• Protected author/workflow state: The provided GitHub context shows this PR is draft and the author association is MEMBER, so ClawSweeper cleanup should keep it open for explicit maintainer handling. (7b5baf79663e)
• Current main pins Actions by SHA: Current CI checks out with a commit-pinned actions/checkout ref, showing the existing automation pattern for third-party Actions is SHA pinning. (.github/workflows/ci.yml:19, eb3bd3c44844)
• Shared setup action pins toolchain Actions: The shared setup action pins actions/setup-node and actions/setup-go to commit SHAs, reinforcing that the new workflows diverge from the existing security posture. (.github/actions/setup-ci-env/action.yml:31, eb3bd3c44844)
• PR adds mutable Action refs: The added CodeQL workflow uses mutable version tags for actions/checkout, actions/setup-go, and github/codeql-action while granting security-events: write. (.github/workflows/codeql.yml:23, 7b5baf79663e)
• PR adds mutable stale automation: The added stale workflow uses actions/stale@v10 with issue and pull-request write permissions. (.github/workflows/stale.yml:18, 7b5baf79663e)

Likely related people:

• Peter Steinberger: Blame and history show the current CI workflow, shared setup action, release workflow, and wacli agent skill were introduced or recently maintained through these commits. (role: current CI/release automation introducer and recent setup owner; confidence: high; commits: 8b725754b368, 878364747147, 2a9193e91cb8; files: .github/workflows/ci.yml, .github/workflows/release.yml, .github/actions/setup-ci-env/action.yml)
• Dovocoder: Recent history shows an adjacent release workflow update, so they may be useful context for workflow policy but are not the primary owner of the setup baseline. (role: recent adjacent release workflow contributor; confidence: medium; commits: f919b14d5e1b; files: .github/workflows/release.yml)

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

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