diff --git a/.github/ISSUE_TEMPLATE/rfc.yml b/.github/ISSUE_TEMPLATE/rfc.yml new file mode 100644 index 00000000..f93786ad --- /dev/null +++ b/.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 diff --git a/convex/lib/skillSlugValidator.ts b/convex/lib/skillSlugValidator.ts index f5e584aa..a139d798 100644 --- a/convex/lib/skillSlugValidator.ts +++ b/convex/lib/skillSlugValidator.ts @@ -105,7 +105,7 @@ const RESERVED_SKILL_SLUGS: ReadonlySet = new Set([ "false", ]); -export interface ValidateSlugOptions { +interface ValidateSlugOptions { /** * Bypass the reserved-word blocklist. * Intended for admin migrations / internal seeding only. diff --git a/rfcs/0001-org-claim-dispute-account-recovery.md b/rfcs/0001-org-claim-dispute-account-recovery.md new file mode 100644 index 00000000..277f556f --- /dev/null +++ b/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? diff --git a/rfcs/README.md b/rfcs/README.md new file mode 100644 index 00000000..cec42176 --- /dev/null +++ b/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.