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

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

Codex review: needs changes 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
This PR adds repository maintainer baseline files: CODEOWNERS, Dependabot, SECURITY.md, CodeQL/stale/Crabbox workflows, and bundled autoreview/Crabbox skills.

Reproducibility: yes. Source inspection shows the stale workflow closes inactive issues and PRs while the exemption lists omit several protected labels; no runtime execution is needed to see that configuration path.

PR rating
Overall: 🧂 unranked krab
Proof: 🌊 off-meta tidepool
Patch quality: 🧂 unranked krab
Summary: The PR is not quality-ready until the stale workflow stops exposing protected work to automatic closure.

Rank-up moves:

• Add protected-label exemptions to every stale issue and PR rule.
• Re-run YAML validation and actionlint for the changed 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: This is a member-authored setup PR, so the external contributor real-behavior proof gate does not apply.

Risk before merge

• Merging as-is would allow stale automation to mark and close security, beta-blocker, or release-blocker PRs unless maintainers manually add a separate no-stale or maintainer label.
• The same workflow omits beta-blocker and release-blocker from issue exemptions, so release-critical issues can be auto-closed after inactivity.

Maintainer options:

1. Protect labeled work first (recommended)
   Add security, beta-blocker, and release-blocker to the stale exemption lists for every issue and PR path before merge.
2. Accept an aggressive stale policy
   Maintainers can intentionally accept that protected work needs a separate no-stale or maintainer label, but that should be an explicit governance decision.
3. Pause stale automation
   If the protected-label policy is not settled, merge the non-stale baseline pieces separately and leave auto-close automation out for now.

Copy recommended automerge instruction

@clawsweeper automerge

Special instructions:
Update .github/workflows/stale.yml so all stale-action exemption lists include the protected labels they can process: issues should exempt security, beta-blocker, release-blocker, maintainer, pinned, no-stale, and any existing enhancement exemption; PRs should exempt security, beta-blocker, release-blocker, maintainer, and no-stale. Keep timing, messages, permissions, and other workflow behavior unchanged.

Next step before merge
A focused repair can update stale exemptions for protected labels; maintainers still own the draft PR merge decision.

Security
Needs attention: The added stale automation has a concrete governance/security concern because security-labeled PRs are not exempt from automatic closure.

Review findings

• [P1] Exempt protected labels from stale closure — .github/workflows/stale.yml:27

Review details

Best possible solution:

Keep the maintainer baseline direction, but exempt protected labels consistently across every stale issue and PR rule before enabling auto-close.

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

Yes. Source inspection shows the stale workflow closes inactive issues and PRs while the exemption lists omit several protected labels; no runtime execution is needed to see that configuration path.

Is this the best way to solve the issue?

No. The setup direction is reasonable, but the stale automation should protect security and release-blocking labels before this becomes the maintainer baseline.

Label changes:

• add P2: This is a repository automation baseline with a concrete merge blocker, but it is a draft setup PR rather than an active production regression.
• add merge-risk: 🚨 automation: The new stale workflow can automatically label, comment on, and close issues or PRs, including protected work that is not currently exempted.
• add rating: 🧂 unranked krab: Current PR rating is 🧂 unranked krab because proof is 🌊 off-meta tidepool, patch quality is 🧂 unranked krab, and The PR is not quality-ready until the stale workflow stops exposing protected work to automatic closure.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: This is a member-authored setup PR, so the external contributor real-behavior proof gate does not apply.

Label justifications:

• P2: This is a repository automation baseline with a concrete merge blocker, but it is a draft setup PR rather than an active production regression.
• merge-risk: 🚨 automation: The new stale workflow can automatically label, comment on, and close issues or PRs, including protected work that is not currently exempted.
• rating: 🧂 unranked krab: Current PR rating is 🧂 unranked krab because proof is 🌊 off-meta tidepool, patch quality is 🧂 unranked krab, and The PR is not quality-ready until the stale workflow stops exposing protected work to automatic closure.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: This is a member-authored setup PR, so the external contributor real-behavior proof gate does not apply.

Full review comments:

• [P1] Exempt protected labels from stale closure — .github/workflows/stale.yml:27
  This stale configuration closes PRs after inactivity but only exempts maintainer,no-stale, so a security, beta-blocker, or release-blocker PR can be marked stale and closed by the new workflow. Add the protected labels to each issue/PR exemption list before enabling auto-close.
  Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.9

Security concerns:

• [medium] Security-labeled PRs can be stale-closed — .github/workflows/stale.yml:27
  The PR stale rules can close inactive PRs but omit security from exempt-pr-labels, which can silently close vulnerability-related work unless another label happens to protect it.
  Confidence: 0.88

Acceptance criteria:

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

What I checked:

• Member-authored draft PR: The provided PR metadata shows authorAssociation MEMBER and draft true, so this review should not auto-close it even though it is repository setup cleanup. (39aa48d609f8)
• Stale workflow can close protected PRs: The added stale workflow grants pull-requests write permission and closes stale PRs, but the unassigned PR exemption list only includes maintainer,no-stale and omits security, beta-blocker, and release-blocker. (.github/workflows/stale.yml:27, 39aa48d609f8)
• Assigned PR stale rule repeats the same gap: The assigned PR stale rule also closes stale PRs after 7 days while exempting only maintainer,no-stale, so protected PR labels remain unprotected in both PR paths. (.github/workflows/stale.yml:75, 39aa48d609f8)
• Current main has only release workflow automation: Current main lists .github/workflows/lobster-npm-release.yml and lacks the new CODEOWNERS, Dependabot, CodeQL, stale, Crabbox, and SECURITY.md baseline files, so the PR is adding new governance/automation surface rather than duplicating existing files. (66cbee58967f)
• Release workflow provenance: The current npm release workflow history points to prior repository automation work in commit a6789c5 and the latest release snapshot 57a9967. (.github/workflows/lobster-npm-release.yml, a6789c50ff52)

Likely related people:

• steipete: The latest main snapshot and release metadata attribute package, changelog, and release workflow state to Peter Steinberger, including current main commits 57a9967 and 66cbee5. (role: recent repository automation and release contributor; confidence: medium; commits: 57a9967d13e8, 66cbee58967f; files: .github/workflows/lobster-npm-release.yml, package.json, CHANGELOG.md)
• Onur: Commit a6789c5 introduced the existing npm release workflow, making this person relevant to repository workflow automation changes. (role: automation introducer; confidence: medium; commits: a6789c50ff52; files: .github/workflows/lobster-npm-release.yml)
• vignesh07: Recent main history includes workflow/runtime and security-hardening commits by Vignesh Natarajan/vignesh07, which is adjacent to repository automation and safe execution policy. (role: adjacent runtime and safety contributor; confidence: medium; commits: 775c32b8058c, 83e115a8bfa9; files: AGENTS.md, src/cli.ts, src/workflows/file.ts)

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

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