245 lines
9.1 KiB
Markdown
245 lines
9.1 KiB
Markdown
# VIDEO_WORKBENCH.md
|
|
|
|
## 1. Workspace Identity
|
|
|
|
This project is the local execution workspace for dimensional video and slide-style output.
|
|
|
|
It turns accepted GPT V2 planning Markdown and user-provided sources into project notes, local execution plans, visual-system assets, slide/page execution folders, generated assets, and handoff material. It is optimized for practical continuation, not heavy governance.
|
|
|
|
## 2. Collaboration Roles
|
|
|
|
```text
|
|
GPT / ChatGPT = stage 0-5 planning Markdown, outlines, visual systems, page/shot skeletons
|
|
User = decisions, accepted inputs, source/reference material
|
|
Codex = stage 6+ execution planning, Prompt Advisor work, visual-system materialization, iteration, local assets
|
|
```
|
|
|
|
GPT V2 does not provide final image prompts, Codex JSON, output paths, task lists, or image generation parameters. Codex should not request those from GPT as missing inputs.
|
|
|
|
Codex should not rewrite GPT planning into duplicate project content. The accepted planning files belong in the project `intake/` directory, and Codex turns them into local execution decisions in `execution-plan.md`.
|
|
|
|
## 3. Project Layout
|
|
|
|
All video or slide-style work lives under `projects/`:
|
|
|
|
```text
|
|
projects/
|
|
project-id/
|
|
project.md
|
|
intake/
|
|
execution-plan.md
|
|
visual-system/
|
|
visual-system.md
|
|
refs/
|
|
iterations/
|
|
slides/
|
|
slides.md
|
|
s01/
|
|
s02/
|
|
```
|
|
|
|
Use root-level `handoff/` for repository-level, cross-project, series-level, or context-window handoff notes.
|
|
|
|
Use `docs/cases/` for Codex-side local case patterns extracted from old real GPT cases. These documents preserve reusable structure, granularity, asset layering, speaker-note style, and review dimensions. They do not restore old GPT final prompts, Codex JSON execution packages, output paths, or global text-rendering rules.
|
|
|
|
Do not split projects into `active`, `completed`, `abandoned`, `series`, or `standalone` folders. Status and series membership belong in project files because both can change during real production.
|
|
|
|
If a series needs more structure, create `projects/_series/` when the first real series needs it.
|
|
|
|
## 4. Project Notes
|
|
|
|
`projects/<project>/project.md` is a lightweight Codex-maintained note. It should record:
|
|
|
|
- project status;
|
|
- medium type;
|
|
- source and reference links;
|
|
- which `intake/` files are GPT V2 planning Markdown, source notes, reference notes, or background notes;
|
|
- current execution focus;
|
|
- key local execution files;
|
|
- next action.
|
|
|
|
It should not duplicate the full outline, storyboard, page design, shot design, or execution plan.
|
|
|
|
## 5. Execution Plan
|
|
|
|
Visual projects must have:
|
|
|
|
```text
|
|
projects/<project>/execution-plan.md
|
|
```
|
|
|
|
This is a living Codex-maintained execution control file. It records:
|
|
|
|
- the current medium branch;
|
|
- the current execution focus;
|
|
- which visual-system assets need materialization;
|
|
- the current small-batch iteration strategy;
|
|
- which `sNN` units are in the active batch;
|
|
- the current round;
|
|
- the next decision.
|
|
|
|
It should not repeat the project ID, full intake file index, or project map from `project.md`.
|
|
|
|
## 6. Intake
|
|
|
|
`projects/<project>/intake/` holds material provided or accepted by the user:
|
|
|
|
- GPT V2 stage 0-5 planning Markdown;
|
|
- outlines;
|
|
- storyboards, page skeletons, or shot skeletons;
|
|
- background notes;
|
|
- reference images, audio notes, or source pointers.
|
|
|
|
File naming can be agreed during the first real project. Do not create a rigid naming scheme before the real GPT outputs are known.
|
|
|
|
## 7. Visual System
|
|
|
|
Visual projects use:
|
|
|
|
```text
|
|
projects/<project>/visual-system/
|
|
visual-system.md
|
|
refs/
|
|
iterations/
|
|
```
|
|
|
|
`visual-system.md` is the single record for the project's public visual system. It should cover:
|
|
|
|
- the current accepted visual system;
|
|
- materialization targets;
|
|
- trial prompts and generated reference assets;
|
|
- review notes;
|
|
- failure attribution;
|
|
- next action.
|
|
|
|
Use optional subfolders only when the project needs them:
|
|
|
|
```text
|
|
visual-system/characters/
|
|
visual-system/scenes/
|
|
visual-system/templates/
|
|
visual-system/diagrams/
|
|
visual-system/backgrounds/
|
|
```
|
|
|
|
Do not create a separate `makeup-still/` directory. Character anchors and identity references belong under `visual-system/`.
|
|
|
|
After a character anchor stage is accepted, clean the character workspace before scene generation:
|
|
|
|
- keep only current usable character references under `visual-system/characters/`;
|
|
- record the active references and their intended use in `visual-system/characters/character-reference-registry.md`;
|
|
- move historical candidates, rejected versions, prompt/review process files, previews, masks, chroma sources, and other intermediate files to `archive/characters/`;
|
|
- do not use files under `archive/characters/` as default prompt references unless a repair task explicitly reopens them.
|
|
|
|
For identity-critical shots, prompt specs must choose the person reference from the active character registry. Text description can clarify the role, but it does not replace the active character image reference.
|
|
|
|
## 8. Slides And Shots
|
|
|
|
Use `slides/` as the execution unit area for both video shots and PPT-style pages.
|
|
|
|
`projects/<project>/slides/slides.md` is the unit execution fact table. It records each page or shot's source, batch, current prompt version, current image version, review state, acceptance state, and notes. Project-level iteration strategy belongs in `execution-plan.md`.
|
|
|
|
Each `slides/sNN/` folder keeps one slide, page, or shot together:
|
|
|
|
```text
|
|
slides/
|
|
slides.md
|
|
s01/
|
|
s01-metadata.json
|
|
s01-unit-spec.md
|
|
s01-visual-brief.md
|
|
s01-v1-prompt.md
|
|
s01-v1-image.png
|
|
s01-v1-review.md
|
|
s01-v2-prompt.md
|
|
s01-v2-image.png
|
|
s01-v2-review.md
|
|
```
|
|
|
|
All files inside `sNN/` must carry the `sNN` prefix. Iteration files use `sNN-vN-type.ext`, so files from the same version sort together.
|
|
|
|
## 9. Investigations
|
|
|
|
Use `investigations/` for research reports, experiments, comparisons, draft workflow proposals, and other reviewable evidence.
|
|
|
|
`tmp/` is deprecated and should not receive new durable work. Short-lived scratch material should either be deleted or promoted into `investigations/` when it becomes useful evidence.
|
|
|
|
`garden-gpt-image-2/` remains reserved for tool-level image prompt or workflow traces when that path is used.
|
|
|
|
## 10. Word Budget
|
|
|
|
Use the default standard:
|
|
|
|
```text
|
|
1 minute = about 220 Chinese characters of voiceover
|
|
10 minutes = about 2200 Chinese characters
|
|
```
|
|
|
|
Adjust only when the user specifies a different narration speed.
|
|
|
|
## 11. Asset Policy
|
|
|
|
Image and audio generation can be automated when available skills or APIs are appropriate.
|
|
|
|
Video generation from images remains manual or semi-manual for now because output reliability varies.
|
|
|
|
Editing and publishing are human-controlled unless explicitly automated later.
|
|
|
|
Codex is the default prompt owner for final image prompts in this workspace, but final prompts must be produced through the `gpt-image-2` Skill workflow rather than direct freehand drafting. GPT V2 planning Markdown remains a source specification, not a final prompt.
|
|
|
|
For project-bound image prompts, Codex must:
|
|
|
|
- run the `gpt-image-2` mode check before prompt work;
|
|
- read the relevant Skill template or reference file;
|
|
- save the rendered prompt/spec as a reviewable project file;
|
|
- list the source files actually used;
|
|
- wait for user approval before image generation.
|
|
|
|
Direct prompts may exist only as clearly labeled scratch or non-generation-ready drafts. They must be rebuilt through the `gpt-image-2` Skill workflow before use.
|
|
|
|
## 12. Capability-Request Mode
|
|
|
|
When a required capability is missing, create a supplier ticket and pause the dependent work.
|
|
|
|
Tickets go to:
|
|
|
|
```text
|
|
requirements/ccpe/
|
|
requirements/skills-vault/
|
|
```
|
|
|
|
Use `requirements/ccpe/` for local work agents, CCPE-Lite artifacts, agent specs, runtime rules, model cards, invocation contracts, and governed cognitive assets.
|
|
|
|
Use `requirements/skills-vault/` for deterministic automation tools, scripts, exporters, batch processors, and installable automation skills.
|
|
|
|
## 13. Text Encoding
|
|
|
|
All local project documents are UTF-8 unless a file explicitly declares another encoding.
|
|
|
|
When using PowerShell to read Markdown, JSON, YAML, text, handoff, prompt, or discussion files, use explicit UTF-8:
|
|
|
|
```powershell
|
|
Get-Content -LiteralPath <path> -Encoding UTF8
|
|
Select-String -Path <path> -Pattern <pattern> -Encoding UTF8
|
|
```
|
|
|
|
Do not wait for mojibake or a failed first read before applying UTF-8.
|
|
|
|
## 14. CCPE Consumption
|
|
|
|
Video Workbench consumes CCPE through the single external interface:
|
|
|
|
```text
|
|
C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md
|
|
```
|
|
|
|
When preparing CCPE integration or invocation work, read `Interface.md` first and follow it to:
|
|
|
|
```text
|
|
C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\ccpe-agent-consumer-setup.md
|
|
```
|
|
|
|
Do not duplicate canonical CCPE definitions here. Do not hardcode Agent, Lite, Skill, Runtime, or protocol paths as default entrypoints. Use `ccpe-consumption/` for interface notes and future project-local invocation setup records.
|
|
|
|
Local work prompts and agents belong in CCPE. If this workflow is later packaged as deployable software, production/business agent implementation belongs in the target software project, not in Video Workbench.
|