WIP / RFC

This section contains in-progress design work.

Nothing in this section is authoritative.

Purpose

The WIP section exists to:

• explore design space safely
• document trade-offs before committing
• prevent half-decisions from leaking into system specs

This is not a scratchpad. This is structured design work.

Rules

All WIP pages must:

1. Use the standard WIP template
2. Clearly state goals and non-goals
3. Present at least one alternative
4. Identify open questions
5. Define acceptance criteria

What Belongs Here

Examples:

• data model exploration
• permissions design
• identity or presentation concepts
• scaling or sharding strategies
• moderation workflows
• monetization mechanics

What Does NOT Belong Here

• implementation guides
• finalized specs
• historical documentation
• TODO lists
• personal notes

Lifecycle

Every WIP must eventually end in one of:

• Accepted → promoted to system documentation
• Rejected → archived with rationale
• Blocked → explicitly waiting on external dependency

No WIP should live here indefinitely.

Promotion Rules

When a WIP is accepted:

1. Move its conclusions into:
   • chat-backend/* for data / authority
   • chat-frontend/* for rendering / UX
   • main-site/* for auth or routing concerns
2. Replace the WIP content with a tombstone linking to the final docs
3. Mark status as Accepted

Active WIPs

• Chat identity & presentation
• Roles, flairs, badges
• Moderation escalation
• Permissions & trust levels