administrator/Worldshaper
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Expand request review tooling and KB

Browse source
This commit is contained in:
Andraxion 2026-06-27 01:12:35 -04:00
parent ab1dfbf029
commit cae21b61b7
16 changed files with 1258 additions and 241 deletions
Download patch file Download diff file Expand all files Collapse all files

14
docs/kb/README.md
View file

@ -16,8 +16,12 @@ The goal is to give request-processing tools stable system summaries instead of
- Machine-readable system index.
- `request-analysis-schema.json`
- JSON schema for structured request parsing output.
- `tags.json`
- Standardized request tags for queue analysis and admin review.
- `queue-workflow.md`
- First-pass automation and review flow.
- `editor-capabilities.md`
- Shorthand capability matrix for common request-analysis questions.
- `systems/*.md`
- Human-readable system notes, organized by editor subsystem.
@ -44,10 +48,11 @@ Suggested queue flow:
1. Pull a raw request submission from the launcher request store.
2. Retrieve likely systems from `systems.json` using tags, aliases, and file names.
3. Provide the matching `systems/*.md` files to the local model as context.
4. Ask the model to split the submission into atomic requests.
5. Require output that matches `request-analysis-schema.json`.
6. Validate the JSON before storing anything back into the app.
7. Auto-promote only high-confidence items. Keep low-confidence items in review.
4. Require the model to use only tags from `tags.json`.
5. Ask the model to split the submission into atomic requests.
6. Require output that matches `request-analysis-schema.json`.
7. Validate the JSON before storing anything back into the app.
8. Auto-promote only high-confidence items. Keep low-confidence items in review.
## Recommended Next Additions
@ -98,6 +103,7 @@ $env:REQUEST_ANALYZER_MODEL="deepseek-v4-pro"
- If the model produces multiple atomic requests from one submission, keep the original submission id on every derived item.
- If a request touches multiple systems, prefer one primary category and many tags.
- Review rationale should be short, structured, and safe to show in admin UI. Do not rely on hidden model chain-of-thought.
- If the request is really a bug report, preserve the problem statement and write the implementation note as a likely fix path, not a promise.
- If the model cannot confidently map a request, store it as `needs_review` instead of forcing a category.