chore: add maintainer setup baseline

[vincentkoc]

Summary

• add maintainer setup baseline files for this repository\n- add CODEOWNERS, 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
• 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 10:24 UTC / May 22, 2026, 6:24 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 for CODEOWNERS, SECURITY.md, CodeQL, stale automation, Crabbox hydration, and local autoreview/Crabbox skills.

Reproducibility: yes. for the review finding: the risky runner selection is visible directly in the changed workflow source and the intended fixed labels are visible in the new Crabbox config. There is no separate runtime bug report to reproduce.

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

Rank-up moves:

• Constrain the Crabbox Hydrate runs-on labels to the fixed Crabbox runner set plus the dynamic lease label.
• Have maintainers explicitly accept or adjust the stale automation windows and exemptions before merge.

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 external-contributor real-behavior proof gate does not apply to this MEMBER-authored repository setup PR.

Risk before merge

• The hydrate workflow can be dispatched with an arbitrary self-hosted runner label because it does not include the fixed Crabbox labels from .crabbox.yaml; that broadens where repository workflow code can run.
• The stale workflow is a repository policy change that will auto-close inactive issues and PRs, so maintainers should explicitly accept the timing and exemptions before merge.

Maintainer options:

1. Constrain Crabbox Runner Targeting (recommended)
   Require the fixed crabbox, openclaw, and crabpot labels in the hydrate job runs-on array while keeping the dynamic lease label as an additional selector.
2. Own Broad Self-Hosted Dispatch
   Maintainers could intentionally allow dispatchers to choose any self-hosted label, but that should be explicit because it expands the runner trust boundary.
3. Split Unsettled Policy Work
   If the runner boundary or stale policy is not settled, split low-risk files like SECURITY.md and CODEOWNERS from Crabbox/stale automation so each policy can be reviewed independently.

Copy recommended automerge instruction

@clawsweeper automerge

Special instructions:
Update `.github/workflows/crabbox-hydrate.yml` so the hydrate job `runs-on` array includes the fixed Crabbox labels from `.crabbox.yaml` (`crabbox`, `openclaw`, `crabpot`) in addition to `self-hosted` and `${{ inputs.crabbox_runner_label }}`; keep the existing workflow_dispatch inputs and add no new secrets.

Next step before merge
A narrow workflow repair can add the fixed Crabbox runner labels; broader stale/CODEOWNERS policy can remain for normal maintainer review after that blocker.

Security
Needs attention: The diff introduces a concrete self-hosted runner targeting concern in the new Crabbox Hydrate workflow.

Review findings

• [P1] Constrain the hydrate job to Crabbox runner labels — .github/workflows/crabbox-hydrate.yml:35

Review details

Best possible solution:

Ship the baseline only after the hydrate workflow is constrained to Crabbox-only self-hosted runners and maintainers accept the stale/ownership policy.

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

Yes for the review finding: the risky runner selection is visible directly in the changed workflow source and the intended fixed labels are visible in the new Crabbox config. There is no separate runtime bug report to reproduce.

Is this the best way to solve the issue?

No, not as-is; the baseline direction is reasonable, but the hydrate workflow should enforce static Crabbox runner labels before merge, and stale automation remains a maintainer policy choice.

Label changes:

• add P2: This is a normal-priority maintainer setup PR with limited blast radius, but it has a merge-blocking workflow safety issue.
• add merge-risk: 🚨 security-boundary: The new hydrate workflow lets a dispatch input select the self-hosted runner label without requiring the fixed Crabbox runner labels.
• add merge-risk: 🚨 automation: The PR adds repository automation for Crabbox hydration and stale handling, and those workflows can affect CI routing and automatic issue/PR closure.
• 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 self-hosted runner boundary 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 external-contributor real-behavior proof gate does not apply to this MEMBER-authored repository setup PR.

Label justifications:

• P2: This is a normal-priority maintainer setup PR with limited blast radius, but it has a merge-blocking workflow safety issue.
• merge-risk: 🚨 security-boundary: The new hydrate workflow lets a dispatch input select the self-hosted runner label without requiring the fixed Crabbox runner labels.
• merge-risk: 🚨 automation: The PR adds repository automation for Crabbox hydration and stale handling, and those workflows can affect CI routing and automatic issue/PR closure.
• 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 self-hosted runner boundary 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 external-contributor real-behavior proof gate does not apply to this MEMBER-authored repository setup PR.

Full review comments:

• [P1] Constrain the hydrate job to Crabbox runner labels — .github/workflows/crabbox-hydrate.yml:35
  The workflow_dispatch input is the only label besides self-hosted, so an operator allowed to dispatch this workflow can point it at any matching self-hosted runner instead of the Crabbox/OpenClaw/Crabpot runner set declared in .crabbox.yaml. Add the fixed labels to runs-on and keep the dynamic lease label as an additional selector.
  Confidence: 0.87

Overall correctness: patch is incorrect
Overall confidence: 0.86

Security concerns:

• [medium] Workflow dispatch can target arbitrary self-hosted labels — .github/workflows/crabbox-hydrate.yml:35
  The hydrate job uses only self-hosted and a workflow_dispatch input in runs-on, so dispatchers can select unrelated self-hosted runners instead of being constrained to the fixed Crabbox runner labels declared in .crabbox.yaml.
  Confidence: 0.87

Acceptance criteria:

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

What I checked:

• PR metadata: The provided GitHub context identifies this as a draft PR by a MEMBER with one setup-baseline commit, so it is not eligible for conservative auto-close cleanup. (075765e39b89)
• Hydrate runner selection: The added Crabbox Hydrate workflow uses only self-hosted plus the workflow_dispatch input as runner labels, making the dispatch input the only runner selector beyond self-hosted. (.github/workflows/crabbox-hydrate.yml:35, 075765e39b89)
• Crabbox fixed labels: The new Crabbox config declares fixed runner labels crabbox, openclaw, and crabpot, which the hydrate workflow should also require before applying the dynamic lease label. (.crabbox.yaml:19, 075765e39b89)
• Current-main baseline: Current main already has several CI workflows but no CODEOWNERS, SECURITY.md, .agents skills, or .crabbox.yaml, so this is new admin and workflow surface rather than already-implemented work. (2680adb3aaf9)
• History routing: Workflow and package history on current main is concentrated in Vincent Koc commits, including check workflow blame and recent CI/dashboard changes, making him the clearest routing candidate. (.github/workflows/check.yml:1, 9d8c0f473d31)

Likely related people:

• Vincent Koc: Current-main workflow/package history and check workflow blame are concentrated under this author, so he is the clearest owner for the new repository automation baseline. (role: recent area contributor; confidence: high; commits: 9d8c0f473d31, fb2264049c7a, 8eb3d2165847; files: .github/workflows/check.yml, .github/workflows/track-dashboard.yml, .github/workflows/dependabot-auto-merge.yml)

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

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