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 Swift-aware CodeQL and Crabbox 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: 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
Adds maintainer baseline repository metadata: CODEOWNERS, Dependabot, SECURITY.md, CodeQL, stale automation, Crabbox hydrate config, and autoreview/Crabbox skills.

Reproducibility: no. live runner reproduction was established, but the source path is clear: workflow_dispatch inputs feed both runs-on and checkout ref, followed by swift package resolve. That is enough source evidence for the review concern but not a full runtime reproduction.

PR rating
Overall: 🦐 gold shrimp
Proof: 🌊 off-meta tidepool
Patch quality: 🦐 gold shrimp
Summary: Useful repository setup with static verification, but the self-hosted workflow trust boundary needs maintainer review before the patch is quality-ready.

Rank-up moves:

• Confirm or constrain the Crabbox runner/ref dispatch boundary before merge.
• Confirm the stale auto-close windows and protected-label exemptions are the desired 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: The external-contributor proof gate does not apply because this is a member-authored repository setup PR; the body lists static verification but no runtime proof.

Risk before merge

• The Crabbox hydrate workflow introduces a workflow_dispatch path that accepts both the self-hosted runner label and ref, then runs Swift package resolution; maintainers should confirm that only ephemeral Crabbox runners can be targeted before merge.
• The stale workflow will automatically stale and close issues and pull requests on schedule, so the 14/7 and 27/7 day windows plus protected-label exemptions need explicit maintainer approval.

Maintainer options:

1. Constrain Crabbox Dispatch
   Validate the runner label/ref against broker-issued or expected Crabbox values, or split the workflow so arbitrary refs cannot run on generic self-hosted runners.
2. Approve Existing Trust Model
   Maintainers may accept the workflow as-is if repo permissions and the Crabbox broker already guarantee that only ephemeral Crabbox runners can be targeted.
3. Pause Baseline Rollout
   Pause or close this setup branch if stale automation and self-hosted runner policy should be handled through a centralized repository administration pass instead.

Next step before merge
The remaining blocker is maintainer policy/security approval for new repository automation, not a safe automated repair with known infrastructure constraints.

Security
Needs attention: The diff adds a self-hosted workflow_dispatch path whose runner label and ref are caller-controlled and should be reviewed before merge.

Review findings

• [P2] Constrain the self-hosted runner input — .github/workflows/crabbox-hydrate.yml:35-40

Review details

Best possible solution:

Land the setup baseline only after maintainer approval of the stale policy and after constraining or explicitly documenting the Crabbox self-hosted runner/ref dispatch boundary for ephemeral Crabbox use.

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

No live runner reproduction was established, but the source path is clear: workflow_dispatch inputs feed both runs-on and checkout ref, followed by swift package resolve. That is enough source evidence for the review concern but not a full runtime reproduction.

Is this the best way to solve the issue?

Unclear as proposed: the setup baseline is broadly maintainable, but the self-hosted runner/ref dispatch should be constrained or explicitly approved before merge. The narrowest safe path is to preserve the baseline while tightening that trust boundary or documenting the accepted Crabbox-only model.

Label changes:

• add P2: The PR is normal-priority repository automation, but it touches self-hosted runner and auto-close behavior that needs more than routine CI confidence.
• add merge-risk: 🚨 security-boundary: The new workflow can run code from an input ref on a self-hosted runner selected by an input label.
• add merge-risk: 🚨 automation: The PR adds scheduled stale closure, Dependabot, CodeQL, and Crabbox workflows that can affect repository automation after merge.
• add rating: 🦐 gold shrimp: Current PR rating is 🦐 gold shrimp because proof is 🌊 off-meta tidepool, patch quality is 🦐 gold shrimp, and Useful repository setup with static verification, but the self-hosted workflow trust boundary needs maintainer review before the patch is quality-ready.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The external-contributor proof gate does not apply because this is a member-authored repository setup PR; the body lists static verification but no runtime proof.

Label justifications:

• P2: The PR is normal-priority repository automation, but it touches self-hosted runner and auto-close behavior that needs more than routine CI confidence.
• merge-risk: 🚨 security-boundary: The new workflow can run code from an input ref on a self-hosted runner selected by an input label.
• merge-risk: 🚨 automation: The PR adds scheduled stale closure, Dependabot, CodeQL, and Crabbox workflows that can affect repository automation after merge.
• rating: 🦐 gold shrimp: Current PR rating is 🦐 gold shrimp because proof is 🌊 off-meta tidepool, patch quality is 🦐 gold shrimp, and Useful repository setup with static verification, but the self-hosted workflow trust boundary needs maintainer review before the patch is quality-ready.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The external-contributor proof gate does not apply because this is a member-authored repository setup PR; the body lists static verification but no runtime proof.

Full review comments:

• [P2] Constrain the self-hosted runner input — .github/workflows/crabbox-hydrate.yml:35-40
  This workflow lets the dispatcher supply both the ref to check out and the self-hosted runner label, then runs swift package resolve from that checkout. If a non-Crabbox self-hosted label is accepted, branch code can execute on that runner; please validate the label/ref against the Crabbox lease model or otherwise enforce that this workflow only targets ephemeral Crabbox runners.
  Confidence: 0.78

Overall correctness: patch is incorrect
Overall confidence: 0.78

Security concerns:

• [medium] Dynamic self-hosted runner dispatch — .github/workflows/crabbox-hydrate.yml:35
  The hydrate workflow accepts crabbox_runner_label and ref as inputs, uses the label in runs-on, checks out the ref, and resolves Swift packages, which can execute package manifest code on the selected self-hosted runner if the runner scope is not constrained.
  Confidence: 0.78

What I checked:

• Current main setup surface: Current main only has existing ci/pages/release workflows; it does not already contain CODEOWNERS, Dependabot, SECURITY.md, CodeQL, stale automation, .crabbox.yaml, or .agents skill files. (c7ae79c1b195)
• PR file surface: The proposed commit adds ten new setup files, including workflows, repo policy files, Crabbox config, and two bundled skills, for 2121 inserted lines. (4fdf9f22db02)
• Self-hosted workflow trust boundary: The Crabbox hydrate workflow runs on a self-hosted runner label supplied by workflow_dispatch input, checks out a supplied ref, and then runs Swift package resolution from that checkout. (.github/workflows/crabbox-hydrate.yml:35, 4fdf9f22db02)
• Stale automation policy: The new stale workflow would automatically stale and close issues and pull requests on scheduled timers, so the label exemptions and closure windows are maintainer policy choices. (.github/workflows/stale.yml:17, 4fdf9f22db02)
• Existing workflow provenance: The current CI and release workflows on main were introduced in the v0.9.0 release-prep commit, making that history the closest existing automation ownership signal. (.github/workflows/ci.yml:1, b85e701f2b0b)
• Code scanning setup comment: The GitHub Advanced Security bot commented that code scanning has recently been set up or this pull request contains the workflow for code scanning, matching the added CodeQL workflow.

Likely related people:

• Peter Steinberger: Authored the current CI/release workflow baseline and latest main setup/release commits, which are the closest current-main ownership signals for this repository automation surface. (role: recent workflow and release area contributor; confidence: high; commits: b85e701f2b0b, c7ae79c1b195; files: .github/workflows/ci.yml, .github/workflows/release.yml, CHANGELOG.md)

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

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