39 lines
1.5 KiB
Markdown
39 lines
1.5 KiB
Markdown
# Request Routing Playbook
|
|
|
|
## Purpose
|
|
|
|
This module exists to help the queue worker turn messy, broad, or slang-heavy requests into a useful first interpretation before the deeper implementation pass begins.
|
|
|
|
## Routing Rules
|
|
|
|
- Prefer existing Worldshaper terminology when a user uses nearby language.
|
|
- Split one submission into multiple request items only when the text clearly asks for separate changes.
|
|
- If a request is broad, still produce a useful interpretation instead of returning an empty or dismissive review.
|
|
- Low confidence should change the recommendation and review notes, not erase the attempt to help.
|
|
|
|
## Ambiguous Request Handling
|
|
|
|
- "Make the game better" is not zero-information. Treat it as a broad improvement request and map it to `General` plus the most likely systems.
|
|
- "Add horses" is a content-plus-runtime request unless the text narrows it down. It may imply:
|
|
- visual assets
|
|
- placement on maps
|
|
- runtime entity support
|
|
- "Fix painting" should first determine whether the user means map tile painting or the Graphics Painter.
|
|
|
|
## What The First Pass Should Produce
|
|
|
|
- matched terms and likely meanings
|
|
- candidate tags
|
|
- likely systems
|
|
- ambiguity level
|
|
- a short rationale safe for admin review
|
|
- possible directions if the user intent could branch
|
|
|
|
## What The Second Pass Should Produce
|
|
|
|
- clean title
|
|
- primary category
|
|
- standardized tags
|
|
- parsed interpretation
|
|
- implementation approach
|
|
- review rationale and options when the request is still uncertain
|