# 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
