# Kling next raw extraction order

Status: active extraction sequence
Captured: 2026-03-29

## Purpose
Define the exact order for the next raw Qingque extraction passes so documentation work continues systematically rather than opportunistically.

---

# Guiding rule
Choose the next extraction target based on:
1. implementation risk if missing
2. proximity to current pipeline needs
3. likelihood of preventing future billable mistakes

---

# Pass 1 — Finish Tier 1 create-body rows
## Why first
These are the most immediate implementation surfaces and still contain important field-level gaps.

## Order
1. Text to Video — Create Task request-body rows
2. Image to Video — Create Task request-body rows
3. Omni-Video — Query Single response-body rows (only if useful fields beyond current live knowledge exist)
4. Omni-Video — Query List rows (only if useful fields beyond current live knowledge exist)

## Success condition
Tier 1 create/query family can be referenced field-by-field without reopening the raw capture for common implementation questions.

---

# Pass 2 — Finish Tier 2 upstream element schemas
## Why second
Element workflows are the strongest likely path for production-grade continuity/identity, but their upstream create contracts are still too vague.

## Order
1. General — Create Element request-body rows
2. General — Create Element response-body rows
3. Create Multi-Image Elements example body
4. Create Video Character Elements example body
5. Query Custom Element (Single) exact path/body/response rows
6. Query Custom Element (List) exact query/body/response rows
7. Query Presets Element (List) rows
8. Delete Custom Element rows

## Success condition
Element creation and retrieval are documented tightly enough that a future live element test would not require payload improvisation.

---

# Pass 3 — Finish audio / voice structures
## Why third
Audio is strategically important, but current field-level certainty is still weaker than Tier 1 and Tier 2 core continuity surfaces.

## Order
1. Search for exact `voice_list` rows
2. Search for voice-tag-related request structures if present
3. Search for audio-binding request fields
4. Search for native-audio mode/control fields
5. Search for image/video generation fields that explicitly attach voice or sound controls

## Success condition
Audio/voice is upgraded from blog-guided concept to at least partial field-level reference.

---

# Pass 4 — Finish Tier 3 image-generation bodies
## Why fourth
Important for future high-quality frame anchors and reusable visual assets, but less urgent than Tier 1/Tier 2 continuity-critical surfaces.

## Order
1. Omni-Image — Create Task request-body rows
2. Omni-Image — Query Single/List useful rows
3. Image Generation — Create Task request-body rows
4. Image Generation — Query Single/List useful rows
5. Any quality/resolution/image-attachment fields that support higher-quality anchor workflows

## Success condition
Tier 3 is documented tightly enough to support future anchor-generation or asset-generation design work.

---

# Pass 5 — Cleanup / reconciliation pass
## Purpose
After the four extraction passes above, reconcile:
- field status register
- approved payload guide
- gap log
- implementation handoff
- workboard

## Success condition
All cross-doc references stay aligned and no major stale contradiction remains.

---

# Immediate next move
Start with:
- Text to Video — Create Task request-body rows
- then Image to Video — Create Task request-body rows

That is the highest-value next extraction step.


## Extraction-method note
If naive `page.html` scanning continues to hide field rows, the next extraction method should shift toward the preserved network layer indicated in `requests.json`, especially document-loading endpoints such as `word/api/load` and related metadata endpoints.