# Kling docs-to-implementation workboard

Status: active workboard
Captured: 2026-03-29
Updated: 2026-03-30

## Purpose
Bridge the gap between:
- documentation completeness
- code implementation completeness
- safe next live verification steps

This board is intentionally operational: it says what still needs extraction, what still needs code sync, and what the expanded Phase 3 verification phase actually is.

---

# A. Documentation work after closeout

## A1. Closeout reading
These are already closed for the current target:
- Phase 1 documentation-first field-level scope
- Phase 2 Omni-first narrow code-sync scope

## A2. Remaining documentation refinement
- deeper nested child-row cleanup
- capability/support-range interpretation where preserved tables stay partial
- stronger provenance notes where doc-derived and live-confirmed evidence differ
- keep non-Omni wording explicit: documented/historically evidenced is not the same as default-synchronized
- keep current-production docs narrowed to production-relevant routes only; move mixed-generation or legacy candidates out of the current layer when they are unlikely to be real production choices

---

# B. Code sync after closeout

## B1. Already sufficiently synced for current closeout
- Omni image first-frame builder
- Omni video-list builder
- Omni element-list builder
- validator support for `image_list` / `video_list` / `element_list`
- model policy locked to 3.0 / 3.0 Omni for the narrow safe path
- multi-shot validator enforcement for known live-confirmed structures

## B2. Still intentionally outside the closeout claim
- broader builder/validator cleanup outside the Omni-first narrow scope
- full helper retirement / quarantine pass
- full provenance tagging across every helper branch
- silent non-Omni default policy encoding

---

# C. Expanded Phase 3 verification plan

## C1. Definition
Phase 3 is now the **expanded verification phase**.
It includes both:
1. deeper Omni verification
2. explicit non-Omni verification

## C2. Omni verification track
1. `mode='pro'` quality comparison on one-scene Omni clip
2. scene-to-scene continuation with `video_list(remote url)` under a more deliberate prompt
3. element-backed generation once Create Element contract is field-level extracted enough
4. native-audio / voice workflow once exact field structures are known

## C3. non-Omni verification track
1. `text2video` current payload + model-policy re-check
2. `image2video` current payload + model-policy re-check
3. endpoint-by-endpoint judgment of:
   - what is merely historical evidence
   - what is still provisional
   - what becomes reusable after re-verification

Note:
- `reference2video` is no longer part of the current-production non-Omni track.
- If revisited later, handle it as a legacy/non-current route analysis item, not as part of the main production verification core.

## C4. Success condition
The first pass of expanded Phase 3 is successful when the repo can say, without overclaiming:
- which Omni paths are still recommended
- which non-Omni paths are still provisional
- which non-Omni paths are reusable only with explicit caller intent
- which create patterns remain approval-gated because they are hypothesis-heavy or comparison-oriented

---

# D. Explicit approval boundary
Only these kinds of steps should force a user decision:
1. any new billable create not already budgeted in-context
2. any hypothesis-only payload on a billable endpoint
3. any larger comparison batch (2+ creates for the same immediate purpose)
4. the **first billable create that starts expanded Phase 3**, even if it is doc-derived

Everything else in documentation extraction and code alignment can continue without interruption.

---

# E. Practical next execution order
1. Keep docs/status/readme aligned with the closeout language
2. Keep non-Omni policy explicit and non-default in code/docs
3. Pick the smallest Phase 3 slice worth testing first
4. state endpoint, payload status, expected create count, and why it is worth spending on
5. get explicit user approval
6. only then run the chosen billable verification

---

## Success condition
The workboard is successful when the next implementation or live-verification step can be chosen from a documented, code-aligned set of options rather than by improvisation.