Expand request review tooling and KB

docs/kb/systems/request-board.md

@@ -1,54 +1,47 @@
 # Request Board
 
-## What It Does
+## What It Owns
 
-The request board lives on the launcher and stores lightweight user submissions. It currently supports pending and active request states, filtering, expansion of active items, and deletion with confirmation.
+The request board is the launcher-side intake, queue, moderation, and review surface for product requests. It stores raw submissions, structured analysis, active request rows, and admin-only review actions.
 
-## Key Files
+## Core Behaviors
 
-- `src/WorldshaperLauncher.tsx`
-- `server.js`
-- `data/launcher_requests.json`
+- Save public request submissions.
+- Keep raw source text alongside normalized active requests.
+- Store structured analysis metadata for pending requests.
+- Filter by status and standardized tags.
+- Protect admin review actions behind server-side password checks.
+- Promote reviewed request items into active request rows.
 
-## Endpoints It Uses
+## Important Endpoints
 
 - `GET /api/launcher-requests`
 - `POST /api/launcher-requests`
 - `PATCH /api/launcher-requests/:requestId`
 - `DELETE /api/launcher-requests/:requestId`
+- `POST /api/launcher-requests/:requestId/process-analysis`
+- `POST /api/launcher-requests/process-pending`
+- `GET /api/launcher-request-meta`
+- `POST /api/admin/auth-check`
 
 ## Important Data Shape
 
-Current request records include:
+Request records can now contain:
 
-- `id`
-- `sourceSubmissionId`
-- `title`
-- `status`
-- `category`
-- `tags`
-- `sourceText`
-- `summary`
-- `implementationNotes`
-- `createdAt`
-- `updatedAt`
+- public fields such as title, category, tags, summary, and implementation notes
+- raw `sourceText`
+- `analysis.state`
+- `analysis.items[]`
+- per-item review rationale
+- per-item possible options
+- structured affected-system and affected-file hints
 
-## Invariants And Constraints
+## Relationships
 
-- New submissions enter as pending unless promoted.
-- One raw submission may contain multiple real feature requests.
-- Active requests should be normalized, titled, and tagged.
-- Deletion is destructive and should remain explicit.
+- Depends on `Launcher Home` for the public site presentation.
+- Depends on the KB under `docs/kb/` for model-grounded request parsing.
+- Depends on the request-analysis worker for automated triage.
 
-## Common Request Themes
+## Triage Hints
 
-- parse and split user submissions
-- request tags and filtering
-- moderation and cleanup
-- queue automation and confidence review
-
-## Triage Questions
-
-- Is the user asking to change request storage, presentation, or parsing behavior?
-- Should one submission become many active requests?
-- Is the request really a bug report or a feature idea?
+Requests about queue automation, moderation, review UI, request splitting, approval workflows, structured tags, and admin tooling should start here.