docs: add RFC community review process (#2092)

* docs: add RFC community review process

* chore: keep slug validator options internal

.github/ISSUE_TEMPLATE/rfc.yml

@@ -0,0 +1,104 @@
+name: RFC
+description: Propose a ClawHub policy, product, trust, or interface decision for feedback.
+title: "RFC: "
+labels:
+  - "type: rfc"
+  - "status: review"
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Use RFCs for decisions that need visible feedback before they become policy, product behavior, or public API contract. Accepted repo RFC files live under `rfcs/`, not `docs/`, so draft/decision records do not publish to the docs site. Keep sensitive enforcement details, private reports, exploit specifics, and scanner thresholds out of the public issue.
+  - type: dropdown
+    id: area
+    attributes:
+      label: Area
+      description: Pick the primary area this RFC affects.
+      options:
+        - Moderation / policy
+        - Security / trust
+        - Product / UX
+        - API / CLI
+        - Documentation
+        - Other
+    validations:
+      required: true
+  - type: textarea
+    id: context
+    attributes:
+      label: Context
+      description: What problem, decision, or ambiguity does this RFC address?
+      placeholder: |
+        ClawHub needs a clearer policy for...
+    validations:
+      required: true
+  - type: textarea
+    id: goals
+    attributes:
+      label: Goals
+      description: What should this RFC achieve?
+      placeholder: |
+        - Make enforcement expectations understandable to users.
+        - Give moderators a consistent decision boundary.
+    validations:
+      required: true
+  - type: textarea
+    id: non_goals
+    attributes:
+      label: Non-goals
+      description: What is intentionally out of scope?
+      placeholder: |
+        - This RFC does not expose internal scanner thresholds.
+        - This RFC does not decide implementation details for every moderation tool.
+    validations:
+      required: true
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposal
+      description: Describe the proposed policy, behavior, or decision.
+      placeholder: |
+        ClawHub should...
+    validations:
+      required: true
+  - type: textarea
+    id: examples
+    attributes:
+      label: Examples
+      description: Give concrete allowed, not allowed, or edge-case examples.
+      placeholder: |
+        Allowed:
+        - Defensive security review with explicit scope and evidence.
+
+        Not allowed:
+        - Account takeover, evasion, or non-consensual surveillance workflows.
+
+        Edge cases:
+        - ...
+  - type: textarea
+    id: user_impact
+    attributes:
+      label: User impact
+      description: How does this affect authors, users, moderators, API consumers, or external contributors?
+      placeholder: |
+        Authors will...
+        Users will...
+        Moderators will...
+  - type: textarea
+    id: open_questions
+    attributes:
+      label: Open questions
+      description: What feedback would be most useful before a decision?
+      placeholder: |
+        - Should appeals be handled in-product, through GitHub, or both?
+        - What examples would make this clearer?
+    validations:
+      required: true
+  - type: input
+    id: feedback_deadline
+    attributes:
+      label: Feedback deadline
+      description: Use an absolute date. Normal RFCs should stay open for 7-14 days unless urgent.
+      placeholder: "YYYY-MM-DD"
+    validations:
+      required: true

convex/lib/skillSlugValidator.ts

@@ -105,7 +105,7 @@ const RESERVED_SKILL_SLUGS: ReadonlySet<string> = new Set([
   "false",
 ]);
 
-export interface ValidateSlugOptions {
+interface ValidateSlugOptions {
   /**
    * Bypass the reserved-word blocklist.
    * Intended for admin migrations / internal seeding only.

rfcs/0001-org-claim-dispute-account-recovery.md

@@ -0,0 +1,36 @@
+# RFC 0001: Org Claim Disputes and Account Recovery After Owner-Initiated Deletion
+
+Status: Draft
+
+Audience: Community review
+
+Canonical docs target: TBD
+
+## Context
+
+ClawHub needs a transparent process for two related trust and ownership questions:
+
+- how organization or owner namespace claims are evaluated and disputed
+- how account recovery works after an owner-initiated account deletion
+
+This RFC is a lightweight discussion record. It is not the final policy, and it should eventually be replaced by a public docs page once the decision is accepted.
+
+## Goals
+
+- Give the community a clear place to review and comment before policy is finalized.
+- Make owner namespace claims, disputes, and account recovery predictable.
+- Separate public policy from private reviewer-only checks or sensitive evidence handling.
+
+## Non-goals
+
+- Define every internal moderator or admin runbook step.
+- Publish private account, identity, or dispute evidence.
+- Decide implementation details for every API, CLI, or admin-console change.
+
+## Open Questions
+
+- What evidence should be required to claim an organization or owner namespace?
+- What evidence should be required to dispute an existing claim?
+- What should happen when a namespace maps to a deleted or inactive owner account?
+- What recovery path should exist after an owner intentionally deletes their account?
+- Which decisions should be public docs, and which details should stay in an internal reviewer runbook?

rfcs/README.md

@@ -0,0 +1,65 @@
+# RFC Process
+
+An RFC is the feedback funnel for a decision. The accepted docs, code, or issue comments become the source of truth after the RFC is resolved.
+
+This folder is intentionally outside `docs/` so RFC drafts and decision records do not publish to the docs site.
+
+## When to use an RFC
+
+Use an RFC for changes that should be understood before they ship:
+
+- moderation and acceptable-usage policy
+- security, trust, or appeal workflows
+- public API or CLI contracts
+- user-visible product behavior
+- decisions that need external contributor feedback
+
+Do not use an RFC for small bug fixes, routine docs edits, private incident handling, or internal-only reviewer tactics.
+
+## Public vs private scope
+
+Public RFCs should include the user-facing decision, goals, examples, open questions, and expected impact.
+
+Keep these out of public RFCs:
+
+- private reports, reporter identities, or user-specific enforcement details
+- exploit instructions or abuse-enabling implementation detail
+- exact scanner thresholds, evasion indicators, or vendor-private signals
+- reviewer-only operational playbooks
+
+If private context changes the outcome, summarize the principle in a maintainer comment without exposing sensitive details.
+
+## Lifecycle
+
+1. Draft the shape internally when the topic is sensitive or ambiguous.
+2. Open a GitHub issue with the RFC template.
+3. Keep normal RFCs open for 7-14 days. Use shorter windows only for urgent trust or safety decisions.
+4. A maintainer posts a synthesis comment covering major feedback, accepted changes, rejected changes, and remaining risks.
+5. Close the RFC as accepted, declined, withdrawn, or superseded.
+6. Land the accepted result in docs or code through a linked PR.
+
+## Labels
+
+Create these labels in GitHub if they do not already exist:
+
+```sh
+gh label create "type: rfc" --repo openclaw/clawhub --color "5319E7" --description "Request for comments on a product, policy, trust, or interface decision"
+gh label create "status: review" --repo openclaw/clawhub --color "FBCA04" --description "Open for maintainer/community feedback"
+gh label create "status: accepted" --repo openclaw/clawhub --color "0E8A16" --description "Decision accepted; implementation or docs follow-up expected"
+gh label create "status: declined" --repo openclaw/clawhub --color "D93F0B" --description "Decision declined after review"
+gh label create "status: withdrawn" --repo openclaw/clawhub --color "C5DEF5" --description "Closed by the proposer before acceptance or decline"
+gh label create "status: superseded" --repo openclaw/clawhub --color "BFDADC" --description "Replaced by a newer RFC, issue, or PR"
+gh label create "area: moderation" --repo openclaw/clawhub --color "C2E0C6" --description "Moderation, acceptable usage, reporting, appeals, or enforcement"
+gh label create "area: security" --repo openclaw/clawhub --color "D4C5F9" --description "Security, abuse prevention, or trust and safety"
+```
+
+## Moderation RFCs
+
+For moderation guidelines:
+
+- public policy belongs in `docs/acceptable-usage.md`
+- moderator and system mechanics belong in `docs/security.md`
+- API or CLI changes belong in `docs/http-api.md` and `docs/cli.md`
+- implementation details should link to the RFC and final docs in the PR summary
+
+Good moderation RFCs include concrete allowed, not allowed, and edge-case examples. They should explain user-visible enforcement and appeals without exposing detection thresholds or private review tactics.